RE: Definition of Choreography

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