Re: Definition of Choreography

Ricky Ho wrote:
>...
> 
> Think about how we define network protocol (e.g. TCP, SMTP, HTTP ... 
> etc.) using a finite state machine.  Can the public protocol be just an 
> XML representation of a state machine.  Each state constraint what event 
> can happen (event can be what SOAP message to send or what SOAP message 
> to receive).  Each event defines the next state.  Effectively, we are 
> defining what are the possible message exchange sequence without 
> describing the internal decision making process.

I think it is smart to define it in terms of a well-known mathematical 
formalism like  a state machine. AND I agree that the private stuff has 
no business being in the public interface.

BUT...there will be circumstances where a particular state change can 
only happen if a certain set of conditions hold. So you are 100% right 
that WSCI's if/else is not really necessary for a public specification 
but "There are two states and you can go to X if condition A and Y if 
condition B" makes sense.

One can imagine the conditions being expressed in terms of 
XPaths[1]...basically Schemeatron.

(To avoid confusing the issue I won't mention that DAML is much more 
powerful than Schematron for this task because it works at a more 
appropriate semantic level. Schematron gets across the point.)

But of course the only state datums that can be incorporated into these 
XPaths are those that are addressable. And the way to make things 
addressable on the Web is to use URIs.

Now once you have this language, you can actually represent your states 
with addressable datums and flatten out your "state machine" into JUST 
conditions. Now I would call this a "business constraint expression" 
language rather than a "choreography language" but the result is the same.

Let me be concrete. Consider the following choreography task. I won't 
use any REST techniques even though they make sense for this example. 
Just RPC-style XML messaging.

Here is a sample session:

Client asks for a shopping cart:

<shopping action="cartRequest"></shopping>

Server returns one:

<shopping><cart cartid="FHEIOFHEOIFHOFHFS"/></shopping>

Client asks for a commitment to deliver a particular item:

<shopping action="itemRequest"><cart cartid="FHEIOFHEOIFHOFHFS"/>
<itemRequest SKU="HFEIOSHFEOSIHF"/>
</shopping>

Server returns one:

<shopping><cart cartid="FHEIOFHEOIFHOFHFS"/>
<item SKU="HFEIOSHFEOSIHF" confirmationID="HFHFOIEHFOSIHF"/>
</shopping>

Client asks to checkout:

<shopping action="checkOut">
<cart cartid="FHEIOFHEOIFHOFHFS"/>
<item SKU="HFEIOSHFEOSIHF" confirmationID="HFHFOIEHFOSIHF"/>
</shopping>

Server:

<error><noCustomerNumberAndPassword/><error>

Client:

<shopping action="checkOut">
<customerNumber num="829374932737492374" password="927492ufi"/>
<cart cartid="FHEIOFHEOIFHOFHFS"/>
<item SKU="HFEIOSHFEOSIHF" confirmationID="HFHFOIEHFOSIHF"/>
</shopping>

====

Business rules:

  1. In order to request something, a shopping cart must be created.

<rule action="itemRequest" context="/shopping" requirement="/cart/@cartid"/>

2. In order to checkout:
  * Each item must have an associated confirmation ID
  * I need at least one item
  * I need a customerNumber and password

Schematron-Choreography Rules:

<rule action="checkout" context="/shopping/item" 
requirement="@confirmationID"/>
<rule action="checkout" context="/shopping" requirement="item"/>
<rule action="checkout" context="/shopping" 
requirement="customerNumber/@num and customerNumber/@password"/>

Come to think of it, you could do this with WXS, but it would just be 
uglier...

  Paul Prescod

Received on Friday, 18 October 2002 23:16:30 UTC