RE: Definition of Choreography

Are giving another example or using a different representation for the same 
example ?  You have taken out the "acceptedPOState" and 
"rejectedPOState".  I also disagree to put multiple message exchanges 
within a event.  Also don't think <acceptance> <rejection> should be part 
of the language.

My preferred model is
1) An event can only be sending ONE message.
2) The only state change can only be triggered by generating an event.

So dealing with a synchronous RPC will have 3 states (waitForRequest, 
requestReceived, and responseSent) and 2 events (requestArrivalEvent, 
responseGeneratedEvent).

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