Re: Definition of Choreography

Mark,

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.

Cheers,

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 
that
> > we should express those business processes in terms of preconditions 
and
> > 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 
messages.
> 
> 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" 
kind="http://some-restaurant.example.org/food/salad/chef"/>
>   <dish in-order="1" 
kind="http://some-restaurant.example.org/food/soup/chowder"/>
>   <dish in-order="2" 
kind="http://some-restaurant.example.org/food/entre/salmon"/>
>   <dish in-order="3" 
kind="http://some-restaurant.example.org/food/dessert/mousse"/>
> </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
>