Re: Definition of Choreography

I know we're not supposed to argue about it but I'm going to try to get 
across how illogical I see this choreography stuff as being.

Burdett, David wrote:
>...
> 
> For the first case you do not need to expose the choreographies you are
> using as the scale of the problem is limited and well defined.
> 
> However for eCommerce, you do. Imagine that you have a really cool product
> that you want to be sell and use eCommerce (by exchanging messages) with
> thousands (or more customers), but before you can do that, you have to tweak
> your implementation for each one as everyone does it differently because
> there is no standardized published choreography being used. It just won't
> happen, and it didn't happen with EDI, which is why EDI is only used widely
> by the top few tiers of a supply chain.

David, please give a *concrete use case* of a service and a prose 
description of its associated choreography. I will show you how to 
transform it into a service that does not require choreography and is 
more scalable, flexible and reliable to boot. If I can do this for all 
cases, and even formalize the methodology, then would that be sufficient 
evidence that choreography is not necessary?

One should never impose an order of messages on a business partner. It 
is prefectly reasonable to make them meet certain preconditions. But 
there is no reason to know or care what order of messages got them to 
the state where they meet your preconditions.

Customer: "Garcon, your service was terrible."
Waiter: "You asked for a coffee and a salad. I brought them to you."
Customer: "No, I asked for a salad and a coffee. But you brought me a 
coffee and THEN a salad."

This is the choreography approach. The customer had in mind a 
"gotCoffee" state and a "gotSalad" state and set up a transition between 
them. But there was no reason to enforce an ordering on those 
operations. The business rule was: "Customer needs salad and coffee." 
That can be expressed in WXS, Schematron, RELAX or DAML.

Okay, sometimes the business rule _implies_ an ordering. You don't pay 
for the meal until you've got your check. But that can be expressed as a 
business rule with a slight change in the protocol. The business rule 
can be: "When you pay you must also submit the check." Once again, that 
can be expressed in any of the schema languages.

Tim Bray says that Web Services are in danger of having more 
specifications than running applications. Like UDDI, this choreography 
stuff is in danger of becoming a solution looking for a problem. I 
encourage you to have the courage to say NO!

  Paul Prescod

Received on Saturday, 19 October 2002 01:53:37 UTC