Re: Choreography and REST

On Saturday, August 10, 2002, at 06:32  AM, Paul Prescod wrote:

> I just sent a message to Bob Haugen that answers this in part. The 
> other
> part is that the need for a choreography language *plummets* if the
> client and server can agree to share information in what Edwin calls a
> "shared repository". The Web is that shared repository. HTTP is the
> current mechanism for manipulating objects in it.
>
> I claim that if Web Services people presumed a writable Web was
> available to all services, and thought throough the implications of
> that, the idea of a choreography language would not even occur to us.
>
> CORBA obviously is not REST but I would be curious to hear whether 
> CORBA
> people feel they need a "choreography language". If so, I'm no familiar
> with it. Why isn't this a central part of CORBA? Because CORBA presumes
> a shared writable (object) information space.

When I read the first two paragraphs, I found them outrageous, for 
reasons
that I believe others have touched on (e.g. David Levine's comments 
about
modularity and separation of concerns). Then I read the third paragraph,
and realized that there ws actually a deeper issue in play here. Paul
is clearly correct: CORBA has no notion of a "choreography language".
Why not? And why do we contemplate the need for such a thing in
web services?

First, let us be clear: if by "choreography" we mean the creation of
complex interactions out of simpler elements, CORBA folks do this
all the time. Their UML diagrams are full of interactions which reuse
existing interactions, which specialize sterotypes, and which allow you
to describe the semantics of such compositions.

The main difference between the CORBA world and the web services world
has nothing to do with on-the-wire encodings, protocols, IDLs and
so forth. Instead it involves the distinction between public and private
semantics of the interactions.

The only way to verify the correctness of a CORBA interaction is to
examine the source code of the application. I can look at the arguments
and results of the methods defined in IDL and check them for legality,
but there is nothing which describes the legality of a complex
interaction sequence.

In the work that has taken place under the banner of "web 
services", there
has been a consistent trend towards preferring public over private
semantics, starting with XML and the notion of validating a document
against a schema. The role of WSDL, and the various flow and 
choreography
languages is (at least) to describe the legal interaction patterns 
and the
ways that such patterns may be composed, and (at most) to allow 
sophisticated
programs to reason about the possible actions open to them.

(Indeed one of the most attractive features of explicit service 
description
and composition languages is that one can evolve the languages, and 
thus the
value than can be derived from the descriptions, without changing the
underlying interactions. I can migrate my MEPs from simple state 
charts to,
say, coloured Petri nets without disturbing the basic "credit card 
validation"
interaction.)

To return to Paul's paragraphs above: what does a "shared repository"
have to do with choreography? It all depends on whether you take the
public or private stance. With CORBA-like private semantics, you can (if
you wish) use a shared repository as part of the mechanism by which you
control the distributed processing. Of course every potentially 
composable
interaction must be written to use this repository in a consistent
way, but technologies such as LINDA and JavaSpaces have shown that
this is a viable model for distributed computing. [Extra credit
exercise: does JavaSpaces support REST?]

However if one is dealing with public semantics, composability, etc.
it's not clear how a "shared repository" helps you. It certainly doesn't
seem to offer any design-time help. And unless you have a language
capable of expressing the legal state spaces of the repository, it's
doubtful that you can do any verification and validation. [What would
such a language look like? Intuitively it feels that it might resemble
a choreography language, but without a clear notion of action.]

In summary, comparing CORBA and web services choreography is like
comparing chalk and cheese, unless you presume that web services
are chalky (with private semantics). And this seems inconsistent
with everything else that's going on in web services.

Geoff Arnold
Sun Microsystems Laboratories

Received on Saturday, 10 August 2002 22:36:12 UTC