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

Re: Choreography and REST

From: Paul Prescod <paul@prescod.net>
Date: Sat, 10 Aug 2002 06:32:09 -0400
Message-ID: <3D54EBA9.AB5C6B7C@prescod.net>
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org

"Champion, Mike" wrote:
> 
> ...
> 
> I'm having a little trouble following what the Choreography proposal does or
> does not have to do with REST.  

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.

> ...
> 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.  

No, I didn't mean to say that. I meant to say that properly engineered
services that have access to a shared writale space do not need a
choreograhy language.

> 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. 

Once you have the shared writable space, the choreography issues become
quite minor. Insofar as there are a few that remain (how do you say
don't read after a close) those are no different than all of the other
business process semantic issues that are unresolved. There is no good
reason to deploy a huge, complex infrastructure to solve a tiny fraction
of a problem that our colleagues in the semweb are already supposed to
be working on. And even if they fail, prose text works as it has always.
Java programmers don't feel hard-done-by because there is no declarative
language that says what happens when you read after close. But then they
know that there are WAY MORE semantics than can be expressed in existing
declarative languages anyhow so why should that one minor issue be
privileged?

> 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?

The gist is that we caused the problem choreography languages are trying
to solve when we decided not to promise service implementors that they
will always have access to a shared, writable URI-addressable
information space. (note that only one of the participants needs to be
able to write to the information space and setting up the writable space
is no harder than implementing the few lines of code it takes to launch
an embedded web server)

We caused the problem and our solution will cause more problems.
-- 
XML, Web Services Architecture, REST Architectural Style
Consulting, training, programming: http://www.constantrevolution.com
Come discuss XML and REST web services at the Extreme Markup Conference
Received on Saturday, 10 August 2002 06:34:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:04 GMT