RE: Definition of Choreography

my last comment on this thread...

-----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 1:09 PM
To: jzhu@silkvalleytech.com; walden.mathews@tfn.com; www-ws-arch@w3.org
Subject: RE: Definition of Choreography


  Are giving another example or using a different representation for the
same example ?
  [JZ] the latter
  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).
  [JZ] there is this school of thought that prefers seeing "what" not "how"
in a declarative public collaboration interface,
  [JZ] and considers neither RPC nor conversation mode to be part of "what"

  Joshua

  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