W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

Re: Definition of Choreography

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Sun, 20 Oct 2002 23:13:06 -0400
To: Mark Baker <distobj@acm.org>
Cc: www-ws-arch@w3.org
Message-ID: <OF71088F31.A51C0292-ON85256C59.000EB1AB-85256C59.00118F02@rchland.ibm.com>

Agreed, the messages are likely very similar if not identical. However, 
the order
*does* matter as I have attempted to make clear. In fact, the order is 
quite often
contractual in nature (e.g. there is a binding agreement between the 
parties as to the
predetermined order).

A business that had contracted that it would pay for goods and services
after they have been delivered would be *very* upset to find that it is
being asked to pay *before* they have been received. It might even
be enough to abrogate the agreement and the partnership. That would
be "a bad thing" all around.


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

Mark Baker wrote on 10/20/2002 10:29:21 PM:

> On Sun, Oct 20, 2002 at 06:14:08PM -0700, Burdett, David wrote:
> > 
> > Paul
> > 
> > You said ...
> > 
> > >>>I didn't say that we should all abandon business processes. I said 
> > we should express those business processes in terms of preconditions 
> > postconditions, not in terms of messsaging rituals.<<<
> > 
> > I agree, with the proviso that the preconditions and post conditions 
must be
> > associated with events and that those events are the sending of 
> To elaborate on an earlier example in this thread ...
> Consider the ordering of a meal in a restaurant.  It is quite reasonable
> to observe the interaction between customer and waiter, and want to
> automate that as a choreography.  But I think that's confusing the what
> and the how, as discussed elsewhere in this thread.
> The customer/restaurant interaction as an instance of the
> offer/acceptance pattern[1].  The menu is an offer, and an order is
> an acceptance of the terms in the menu; pay the money, get the food.
> In this view, the Q&A between customer and waiter is just a means to
> communicating the offer and the order.  It's one implementation.  In
> other restaurants, the process of ordering can vary, but what doesn't
> vary is that there is an offer of product and/or service, and an
> explicit acceptance of the terms of that offer.
> Here's an example order;
> <order xmlns="http://some-restaurant.example.org/order/">
>   <dish in-order="1" 
>   <dish in-order="1" 
>   <dish in-order="2" 
>   <dish in-order="3" 
> </order>
> where the "in-order" attribute specifies what comes first, with the same
> value meaning you want them together.  That ordering might be what
> somebody might call a choreography, I suppose.  That's not important.
> What's important is, that even if some standardized language were
> developed for communicating sequences of tasks, and dependancies between
> them, etc.. (a GoodThing!), that it does not in *any way* relate to the
> messages that are sent to implement the contract.
>  [1] http://internet.conveyor.com/RESTwiki/moin.cgi/RestifiedPurchasing
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
> http://www.markbaker.ca             http://www.idokorro.com
Received on Sunday, 20 October 2002 23:13:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:42 UTC