[MOBY-dev] Re: [MISC] [MOBY-l] Messaging document

Wed Feb 26 16:36:31 UTC 2003

To be honest, I had completely forgotten about this - my apologies!  I
believe that I was supposed to be exploring ontology-representation
languages..??

Sorry!

I'm also now uncertain as to whether I can participate in this
afternoons' call.  Presuming that I can't make it, I was planning to say
that I will try to prepare a "1.0" spec for MOBY before the TAIR
meeting.  There is now sufficient buy-in from a wide range of institutes
(you probably noticed that the European PlaNet consortium has signed on
recently!  that was great news!!) that we REALLY need to nail down
something that these enthusiastic people can safely code against, rather
than treating them all as guinea pigs as we have been so far.  The
hackathon provided a wealth of ideas and went a long way to
crystallizing (at least in my mind) what the "1.0" spec would look
like.  It would be unfair (and possibly destructive to community buy-in)
if we didn't provide something stable and usable in the next couple of
weeks.  I understand that it is largely my responsibility to produce
this spec, and I will be devoting all of my free time to this endeavour.

In this regard - any comments on the various aspects of the spec that
have been described up to now should be made ASAP (Heiko - you should
send me your concerns about the CRIB quickly!!).  I will *try* to get a
rough draft out to the dev list by the end of the week, so that you all
have something to crucify :-) and we can perhaps plan for the TAIR
meeting in two weeks as the time when we will put the final stamp on
this version 1 spec.

How does that sound?

M

On Wed, 2003-02-26 at 10:15, Lincoln Stein wrote:
> 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)
> 
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
-- 
=======================================================================
                                    |--==\
Mark Wilkinson, Ph.D.                \==-|       
Bioinformatics Consultant             \=/        0010010010100101110010
Illuminae Media                       /-\        
727 6th Ave. N.                      /-==|       0010100100111101010010
Saskatoon, SK, Canada               |==-/        
S7K 2S8                              \=/         0100100100010010010101
+1 (306) 373 3841                     /\         
markw at illuminae.com                  /=-\        1101001010100101010101
                                    |--==\
=======================================================================