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

RE: Definition of Choreography

From: Ricky Ho <riho@cisco.com>
Date: Mon, 21 Oct 2002 10:38:05 -0700
Message-Id: <4.3.2.7.2.20021020215652.01beb700@franklin.cisco.com>
To: walden.mathews@tfn.com, www-ws-arch@w3.org
Let me try to use a concrete example to illustrate using a modified FSN to 
represent a B2B public protocol.

This example use a simple purchase ordering process
1) A buyer place an order to the seller by invoking a synchronous SOAP call
2) The seller can either accepted it (by responding with an "accepted" 
message) or reject it (by responding with a "rejected" message) or throwing 
a SOAP fault, which will also transit to a rejected state

<choreography name="Purchase" startState="waitForPOState">
     <roleDefinition>
         <role name="buyer"/>
         <role name="seller">
             <portType name="Seller-PT"/>
         </role>
     </roleDefinition>
     <state name="waitForPOState">
         <event name="receivePOEvent" nextState="processingPOState">
             <request sender="buyer" receiver="seller" portType="Seller-PT" 
operation="submitOrder"/>
         </event>
     </state>
     <state name="processingPOState">
         <event name="acceptPOEvent" nextState="acceptedPOState">
             <reply sender="seller" receiver="buyer" portType="Seller-PT" 
operation="submitOrder">
                 <condition test="/body/submitOrderResponse/status = 
'accepted' "/>
             </reply>
         </event>
          <event name="rejectPOEvent" nextState="rejectedPOState">
             <reply sender="seller" receiver="buyer" portType="Seller-PT" 
operation="submitOrder"/>
                 <condition test="/body/submitOrderResponse/status = 
'rejected' "/>
             </reply>
         </event>
         <event name="faultPOEvent" nextState="rejectedPOState">
             <reply sender="seller" receiver="buyer" portType="Seller-PT" 
operation="submitOrder" faultName="InvalidPORequest" />
         </event>
     </state>
     <state name="acceptedPOState"/>
     <state name="rejectedPOState"/>
</choreography>


Here are some principles
1) Each communicating party's role and their associated PortType is defined 
upfront.
2) The choreography only defines what message exchanges are possible.  But 
it doesn't expose the decision criteria how a communication party choose 
one from those possibilities.
3) Every "event" must be an externally visible message exchange, which can 
be one party sending a request (request/reply or one-way) to the other 
party, or it can be one party sending a reply to a previous request (only 
in the request/reply case).
4) An event can be optionally qualified by a "condition", which is an XPATH 
boolean expression.
5) Each event will transit to ONE AND ONLY ONE next state.

Critics and counter suggestions are appreciated.

Rgds, Ricky
Received on Monday, 21 October 2002 13:38:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:09 GMT