RE: Definition of Choreography

Paul

See comments in line below.

David

-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net]
Sent: Friday, October 18, 2002 10:53 PM
To: Burdett, David
Cc: Champion, Mike; www-ws-arch@w3.org
Subject: 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?
<DB>See the word document at
http://www.xcbl.org/DevResources/BusinessTransactions.html This describes 10
different ways of placing an order. Althought this document has been
developed by Commerce One, it actually represents our analysis of what
businesses actually do.</DB>

One should never impose an order of messages on a business partner. 
<DB>I would never dream of "imposing" an order of messages on a business
partner, however I would suggest that businesses would **sometimes**
actually **want** to have an order of messages imposed on them since it
would save them development effort (i.e. money) as well as enable them to
connect to others much more quickly. I gave the reason in an earlier email
[1], however I will have another go here ...

One of the main uses for Web Services is to facilitate eCommerce. However to
do eCommerce, the parties (i.e. people, businesses or organizations) at each
end have to understand exactly what to do with the information, i.e.
messages, they have been sent. If they don't then eCommerce doesn't work.

If you have a human at one end then they can understand whatever written
instructions are contained on a web page, and follow them (usually). However
if you have computers at both ends then this doesn't work as computers are
bad at understanding English (or French, or German ...). Instead, the
computers at each end both have to know **in advance** how they should
behave.

Fortunately, in eCommerce, many of the interactions between business are the
same, e.g. place an order, send an invoice, check stock, etc. If every
business implements these interactions differently then one or the other
businesses would have to comply with the rules of the other, and since
computers can't do this automatically, it would have to involve people
(programmers/analysts) at substantial cost. This means, that unless the
benefit of implementing the automated eCommerce link is so overwhelming,
then the automated link won't be implemented and people will rely on other
more cost-effective approaches instead, e.g. fax or phone.

On the other hand, if you both know that you support the same basic
choreography, then your implementation costs can be close to zero. So by
implementing standardized choreographies, you can get the benefits of doing
eCommerce at much lower cost and involve many more of your business
partners. This is why standardized choreographies are important (OK, I know
that you have to agree on more than choreographies).
</DB>

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. 
<DB>I agree this is a choreography, but it is NOT a standardized
choreography nor is it a choreography that would benefit from
standardization.</DB>

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.
<DB>I agree that enforcing an ordering is not necessary in this example, but
that is only because people are involved. I would love to see a similar
example to this that involved computers at both ends.  Paul, can you provide
one? </DB>


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!
<DB>Sorry Paul, I don't agree with you, but I do respect your perspective
and have a lot of respect for REST et al. I agree with Tim Bray's sentiment,
but I think that computer-to-computer interactions **that do not involve
human intelligence as part of the process** require more standards so that
dumb computers can be programmed with a finite set of tasks to do.</DB>

  Paul Prescod

[1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0238.html

Received on Sunday, 20 October 2002 21:01:24 UTC