RE: Definition of Choreography

Mark

I agree with you when you say ...

>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.

... as there can be many different ways of implementing a contract, e.g. we
have identified 10 different ways to place an order at [2]

However I think we disagree when you suggest that we do not need to
standardize the messages that are sent. In the example you reference at [1]
below, you focus on describing the client-server approach where a human is
understanding what is going on and working out what to do next. This is
absolutely the correct way to do it in this case as the human brain is very
good at working out what to do, although sometimes web designers get web
pages so wrong that the user gives up.

On the other hand for peer-to-peer, which you do not elaborate, this
flexibility does not work as you do not bring in the power of the human
brain ... you just have dumb 'ol computers at each end doing ALL the work.

I really would like to see explained an example of how to do peer-to-peer,
i.e. without a human being involved, in a way that does not need to
standardize messages. I also challenged Paul to do this in the email at [3].

David

[2] http://www.xcbl.org/DevResources/BusinessTransactions.html
[3] http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0288.html

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Sunday, October 20, 2002 7:29 PM
To: Burdett, David
Cc: www-ws-arch@w3.org
Subject: 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