W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2002

Re: Choreography and REST

From: Mark Baker <distobj@acm.org>
Date: Sat, 10 Aug 2002 00:00:44 -0400
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
Cc: www-ws-arch@w3.org
Message-ID: <20020810000044.C8045@www.markbaker.ca>


On Fri, Aug 09, 2002 at 02:10:29PM -0600, Champion, Mike wrote:
> I'm having a little trouble following what the Choreography proposal does or
> does not have to do with REST.  It seems to be a declarative language for
> specifying, a priori, the message patterns required to implement a
> relatively complex set of web services transactions.  It's layered on SOAP
> and WSDL, so to whatever extent SOAP and WSDL support REST, the Choreography
> proposal supports REST.  Chris gave quite a clear explanation of why this
> kind of thing is useful.
> What have I missed up to this point?  

It's that second last sentence.  From the single read-over I've done of
WSCI, it seems to be centered around choreographing WSDL operations,
which don't have anything to do with REST (at least in WSDL 1.1 - I've
submitted an issue about this for 1.2[1]).

The main characteristic of REST relevant to choreographing processes, or
indeed any change of app state, is "hypermedia as the engine of
application state"(*).  That is, instead of explicitly invoking methods
to change state, the change is implicit by virtue of a URI being
declared together with the knowledge that GET on that URI will effect
the state change.

(*) "The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations. Not surprisingly, this exactly matches the user interface of a hypermedia browser. However, the style does not assume that all applications are browsers. In fact, the application details are hidden from the server by the generic connector interface, and thus a user agent could equally be an automated robot performing information retrieval for an indexing service, a personal agent looking for data that matches certain criteria, or a maintenance spider busy patrolling the information for broken references or modified content."

 -- http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_3_3

> Paul Prescod seemed to be making a couple of points that I picked up on.
> First, the *implementation* of a "choreographed" web service could be done
> effectively with a shared "state" resource, perhaps analogous to a file
> handle in programming languages.  Second, he seemed to be saying that one
> wouldn't need a special choreography language *if* one already had a
> RDF/DAML-based language for declaring the semantics of business processes. I
> think I agree ... but the trouble is we don't have such a thing, or at least
> the people making the Choreography submission (not to mention the BPEL4WS
> folks!) don't seem to believe we do. 
> I found Paul's discussion of using REST principles to coordinate multi-part
> web services quite persuasive, but the rest of his (and this) discussion
> seems to be more about specialized choreography/coordination languages vs
> generalized semantic description languages, not about REST per se.  Again,
> have I missed some important point?

You'll have to ask Paul.  I don't think he's subscribed to this list,
so feel free to drop him a line.  Hopefully the above helps though.

[1] http://lists.w3.org/Archives/Public/public-ws-desc-comments/2002Jul/0000

Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Saturday, 10 August 2002 00:00:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:36 UTC