RE: Definition of Choreography

Come on Chris! It has happend before ... at least a couple of times ...
 
David

-----Original Message-----
From: Christopher B Ferris [mailto:[email protected]]
Sent: Sunday, October 20, 2002 7:41 PM
To: Burdett, David
Cc: Burdett, David; Champion, Mike; Paul Prescod; [email protected]
Subject: RE: Definition of Choreography



+1 

David, this is very scary! We agree:) 

Chris 

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: [email protected]
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:[email protected]]
> Sent: Friday, October 18, 2002 10:53 PM
> To: Burdett, David
> Cc: Champion, Mike; [email protected]
> 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
>