Re: Definition of Choreography

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

Received on Sunday, 20 October 2002 22:27:34 UTC