Re: Choreography and REST

"Champion, Mike" wrote:
> 
> ...
> 
> I've lost the thread of this thread.  As I understand it, Paul was arguing
> that "choregraphy" is not necessary, I think because web services developers
> can "just know" what state a resource/object needs to be in in order to
> invoke some service that accesses it.

Not quite. Let's say a service consists of a state machine. A
"choreography language" turns this into a bunch of assertions:

"The service starts in state A."
"If the service is in state A then a Foo message will send it to state
B."
"If the service is in state B then a Bar message will send it back to
state A."
"If the service is in state B then a Foo message will send it to state
C."

But what if the service was described in either an object oriented or
REST style. There is no service. There are objects/resources. I'll use
OO terminology rather than REST terminology to be more familiar to
people.

"Given an A object, a Foo message will generate a B object."
"Given a B object, a Bar message will generate an A object."
"Given a B object then a Foo message will generate a C object."

This set of assertions can be verified in *any* *existing* statically
typed programming language. There is no need for a choreography
language: WSDL or IDL or WRDL serves as the choreography language.

interface A{
   B Foo()
}

interface B{
   A Bar()
   C Foo()
}

The "choreography approach" is to share the state machine (choreography
assertions) in advance and have nothing on the wire or in the shared
information space that represents the current state. IMHO, this clearly
violates the principles of web architecture (the state is an important
resource with no URI) and of good distributed software design (state
alignment is more difficult and the conversation is more fragile). If
you can share the state machine in advance, great! Do it. But the state
of the conversation should also be visible in a runtime discoverable way
so that third parties (either intermediaries or new endpoints) can be
brought into the conversation.

>....
> So, 1) Does this summary do justice to what we're discussing in this thread?
> 2) Does Paul or anyone else think that "choreography" (somewhat loosely
> defined, see the thread on terminology) is an intrinsically bad idea, or
> merely a low priority for the WSA WG even if it is a popular idea at the
> mement?  3) Do the objections stem from a "REST" viewpoint, a "semantic web"
> or RDF viewpoint, or what?

Here's the problem with choreography languages: they make a ton of sense
in an architecture where there are no standardized ways to create and
link objects. I don't think we want to live in that architecture. I'd
rather we fixed the bits of the architecture that are failing us (in
particular WSDL) rather than put band-aids over the deeper problem.
-- 
"When I walk on the floor for the final execution, I'll wear a denim 
suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith 
-- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk."
Congressman James Traficant.

Received on Thursday, 15 August 2002 08:19:12 UTC