RE: Definition of Choreography

+1

David, this is very scary! We agree:)

Chris

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

David Burdett wrote on 10/20/2002 09:01:33 PM:

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