RE: Definition of Choreography

If you want to use 2 async one-way requests style rather that 1 sync 
request/reply style, then the following will be my representation.

<choreography name="Purchase" startState="waitForPOState">
     <roleDefinition>
         <role name="buyer">
             <portType name="Buyer-PT"/>
         </role>
         <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">
             <request sender="seller" receiver="buyer" portType="Buyer-PT" 
operation="acceptOrder"/>
         </event>
         <event name="rejectPOEvent" nextState="rejectedPOState">
             <request sender="seller" receiver="buyer" portType="Buyer-PT" 
operation="rejectOrder"/>
         </event>
     </state>
     <state name="acceptedPOState"/>
     <state name="rejectedPOState"/>
</choreography>

Rgds, Ricky

At 12:47 PM 10/21/2002 -0700, Jianhua Zhu wrote:
>How about...
>
><choreography name="Purchase" startState="waitForPOState">
>     <roleDefinition>
>         <role name="buyer"/>
>             <portType name="Buyer-PT"/>
>         <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"/>
>             <response sender="seller" receiver="buyer" 
> portType="Buyer-PT" operation="receiveResponse">
>                 <acceptance document="acceptDocument"/>
>                 <rejection document="rejectDocument"/>
>             </response>
>         </event>
>     </state>
></choreography>
>
>Joshua
>-----Original Message-----
>From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On 
>Behalf Of Ricky Ho
>Sent: Monday, October 21, 2002 10:38 AM
>To: walden.mathews@tfn.com; www-ws-arch@w3.org
>Subject: RE: Definition of Choreography
>
>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