- From: Burdett, David <david.burdett@commerceone.com>
- Date: Sun, 20 Oct 2002 22:19:42 -0700
- To: Christopher B Ferris <chrisfer@us.ibm.com>, "Burdett, David" <david.burdett@commerceone.com>
- Cc: "Burdett, David" <david.burdett@commerceone.com>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, Paul Prescod <paul@prescod.net>, www-ws-arch@w3.org
- Message-ID: <C1E0143CD365A445A4417083BF6F42CC06A1FA97@C1plenaexm07.commerceone.com>
Come on Chris! It has happend before ... at least a couple of times ... David -----Original Message----- From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] Sent: Sunday, October 20, 2002 7:41 PM To: Burdett, David Cc: Burdett, David; Champion, Mike; Paul Prescod; www-ws-arch@w3.org Subject: 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 >
Received on Monday, 21 October 2002 01:19:34 UTC