[MOBY-l] Messaging document

[Lincoln Stein]

Gosh, I'm not going to get my messaging technical report done in
time for the conference call.  Here's what I've got so far.  I'll write
more this afternoon and hopefully give you an update.

Lincoln


MOBY PROJECT: TECHNICAL REPORT ON WEB MESSAGING LAYER

Date: February 24, 2003
Author: Lincoln Stein
Version: early

This report concerns the messaging layer of the Moby project, that
point at which semantic information is exchanged between the
data consumer (i.e. the biologist) and the data provider (i.e. the
model organism system administrator).

There are a wide variety of possible messaging systems.  Here are a
number of prominent ones listed in rough chronological order.

      1) Custom messaging system using raw TCP/IP
      2) Custom messaging system using BEEP (an IEEE applications
      protocol framework)
      3) ASN.1 exchange
      4) Microsoft DCOM
      5) REST
      6) CORBA
      7) XML-RPC
      8) SOAP

For the purposes of this assessment, I ignored 1, 2, 3 and 4.  I
rejected custom messaging because it is a fallback position.  We
should only reinvent the wheel if we are absolutely certain that none
of the other will meet our requirements.  Exchange of messages via
ASN.1 streams and Microsoft DCOM can rightly be treated as legacy
solutions that have found important places in niche applications but
are not accepted as solutions for enabling the exchange of semantic
information across administrative domains.  SOAP arises from, and
supersedes, XML-RPC, and so are folded together.  This leaves REST,
CORBA, and SOAP.

I will now consider these in chronological order.

REST
----

REST stands for REpresentation State Transfer, and is a term coined by
Roy Fielding in his graduate thesis to describe a style of information
architecture that had already become the de facto standard for the
World Wide Web.  According to Fielding, REST is suited for scaleable
applications in which relatively large hypermedia representations of
information resources are exchanged within the "anarchic network."

The key concepts of REST are:

a) Resources are identified using stable addresses, the URI.

b) Resources are never exchanged themselves.  Instead representations
of resources are exchanged.  A particular resource, such as a database
entry, may be represented in multiple ways, e.g. as an HTML file or a
postscript file.  Resources are viewed as changing with time.

c) REST has many nouns, but very few verbs.  Its verbs follow the CRUD
paradigm, and consist of PUT, GET, POST and DELETE.  Its nouns are an
extensible set of hypermedia representations.

d) REST is stateless, and places the burden of maintaining session
information squarely on the client.

e) REST is close to the transport layer, and allows but does not
require applications to be concerned with performance issues
such as caching, parsing, and rendering latency.

Probably the most unique aspect of REST is its use of URIs to address
each resource.  For example, in a DAS application, a URI can be used
to identify a particular segment of a genome:

   http://my.site/das/d-melanogaster/r3.1/2R/60000/80000

This identifies the genome of drosophila melanogaster, assembly
release version 3.1, chromosome arm 2R from the position 60,000 to
80,000 base pairs.



CORBA
-----

SOAP
----



------------------------------




Bibliography:

REST = REpresentational State Transfer

REST + SOAP
http://www.intertwingly.net/stories/2002/07/20/restSoap.html

Roy Fielding's Dissertation:
Architectural Styles and the Design of Network-based Software
Architectures

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

REST definitions:

"Resource" -- A Thingy
"Representation" -- A materialized version of a resource containing
		 data, metadata, and meta-metadata.

"Control data" -- The purpose of a message between software
components.

"Connector" -- infrastructural library component such as BIND, libwww.

"Component" -- application such as netscape or Apache


Principles:

	1) URIs should change as infrequently as possible.
	2) A resource is the semantic of what the author intends to identify,
	not the value corresponding to the semantic at the time the reference
	is created.
	3) The things that the user manipulates is a representation of a
	resource, not the resource itself!
	

FrontPage RESTwiki
http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage


Roots of the REST/SOAP Debate
Paul Prescod 
ConstantRevolution Consulting
paul at prescod.net 

http://www.prescod.net/rest/rest_vs_soap_overview/
-- 
Lincoln Stein
lstein at cshl.org
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
(516) 367-8380 (voice)
(516) 367-8389 (fax)