Re: State Alignment and Standard Signals

MessageThanks for the example.

The problem with this approach is that the choreography is now bound to the protocol, and therefore it would not be able to be reused. Ideally we need to be able to do this type of binding at the relationship level, to ensure that the choreography remains abstract.

From a business perspective, it would be nice to be able to simply specify the business protocol as,

<interaction request />
......
<interaction response />

OR 

<interaction request-response /> - if synchronous

and leave the protocol detail to the implementation - i.e. this information would then only be required by an endpoint generation tool, to ensure that the endpoint used the correct protocol, or an endpoint monitoring tool to ensure that it interprets the correct set of "on the wire" messages as an interaction.

The problem (you might reply) is that this does not enable us to do different paths depending on whether the acknowledgement failed, or the acceptance was negative. However, if we look at how a BPSS endpoint might react in this situation, possibly this could be viewed as a exception path in CDL? This may enable us to define the relevant alternate paths, without having to make the different stages of the protocol explicit in the choreography?

Regards
Gary


  ----- Original Message ----- 
  From: Jean-Jacques Dubray 
  To: Gary Brown ; david.burdett@commerceone.com ; tony.fletcher@choreology.com ; public-ws-chor@w3.org 
  Cc: Robin.Milner@cl.cam.ac.uk ; kohei@dcs.qmul.ac.uk ; yoshida@doc.ic.ac.uk 
  Sent: Friday, July 16, 2004 5:02 PM
  Subject: RE: State Alignment and Standard Signals


  This is how I would approach the problem.

   

  I would create a construct called Protocol. A protocol is itself a choreography, and more precisely a choreography template. This choreography is of course performed between abstract roles (let's call them initiating role and responding role).

   

   

  Initiating                                    Responding

              --- Request --->                                      Abstract message

              <---- Receipt ---                                      (concrete) signal

              <---- Acceptance---                                 (concrete) signal

              <---- Response ---                                   Abstract message

              --- Receipt --->                                       (concrete) signal

              --- Acceptance--->                                  (concrete) signal

   

  When this template is used, every abstract message must be associated to a concrete message.

   

  In addition I should be able to associate "states" to this choreography, e.g. 

  -          RequestAccepted = positive request Acceptance signal received, 

  -          ResponseAccepted = positive Response Acceptance signal received. 

  "Positive" acceptance/response represents an XPath expression on a message.

   

  In a choreography, I should be able to specify (apologies, I don't know the syntax by heart):

   

  <choreography . >

              <interaction type="procotol">

                          <protocol ref="myProtocol">

                                      <message name="Request" type="ProcessPO"/>

                                      <message name="Response" type="AckPO"/>

                                      <state name="OrderProcessed" boundTo="RequestAccepted"/>

                                      <state name="OrderAccepted" boundTo="ResponseAccepted" conditionExpression="//PO/@accepted="true"/>

                          </protocol>

              </interaction>

              <choice>

                          <switch value="OrderAccepted">

                             <case value="true">

                                      <interaction type="Request/Response">

                                                  . process payment .

                                      </interaction>

                             </case>

                             <case value="false">

                                      . choreography ends .

                             </case>

                          </switch>

  </choice>

  </choregraphy>

   

   

  I promised David that I will make a formal proposal, I hope within the next couple of weeks. Is this kind of approach acceptable?

   

  Jean-Jacques 

   


------------------------------------------------------------------------------

  From: Gary Brown [mailto:gary@enigmatec.net] 
  Sent: Friday, July 16, 2004 8:25 AM
  To: Jean-Jacques Dubray; david.burdett@commerceone.com; tony.fletcher@choreology.com; public-ws-chor@w3.org
  Cc: Robin.Milner@cl.cam.ac.uk; kohei@dcs.qmul.ac.uk; yoshida@doc.ic.ac.uk
  Subject: Re: State Alignment and Standard Signals

   

  Hi

   

  Do you have an example of how the CDL would look in order to represent this state alignment (e.g. as you have described in your article), in such a manner that the interactions are protocol independent? Would you see a "state aligned" interaction only completing after the second (acceptance) signal in the BPSS case?

   

  For example, 

   

      <interaction A->B />

   

  would only be deemed to have completed once B had sent the acceptance message to A?

   

  Curious to know how such a state alignment protocol could be modelled in CDL in an abstract manner that is decoupled from a particular binding........

   

  Regards

  Gary