RE: State Alignment and Standard Signals

Gary:

 

I don't think that the "re-use" is in this dimension. For instance,
either a choreography requires state alignment or it does not. The
proposal I made allows for the state alignment protocol to be changed
independently of the choreography definition, therefore allowing it to
be reused in widely different contexts (ebXML, RN, ...). A particular
protocol can be used, provided that the protocol you use yield the same
"states" (this is the only level of coupling required between the
protocol and the choreography).

 

 

 

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

 

<JJ> I thought this was precisely the proposal I made, because you can
define an interaction template with an embedded protocol, the resulting
usage of that template looks exactly like the statements above. It
simply means that a few more messages are exchanged as part of the
interaction. Did you take a look at BPSS and the concept of Business
Transaction and Business Transaction Activities (usage of a business
transaction in a collaboration definition)? </JJ>

 

 

and leave the protocol detail to the implementation -

<JJ> This is unfortunately not possible, because there is a coupling
between the states of the protocol and the choreography definition,
otherwise it does not make any sense to use a protocol</JJ>

 

 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?

<JJ>The question is on what basis you take the decision to enter an
exception path? Only a protocol failure can do that, hence the coupling
with protocol states (not protocol message interchanges)</JJ>

 

Again, the proposal I made is for CDL not to define a specific protocol
but rather allow us to define interaction templates that include a
protocol message interchange and resulting states. Such choreography
could then be used, say in a BPSS context, where the protocol specific
messages are the BPSS signals bound to the choreography protocol states.

 

Jean-Jacques

 

	----- Original Message ----- 

	From: Jean-Jacques Dubray <mailto:jeanjadu@Attachmate.com>  

	To: Gary Brown <mailto:gary@enigmatec.net>  ;
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