RE: State Alignment and Standard Signals

David:

 

Yes, I think this is exactly what I am saying, the coupling is at the
state level not at the message level (type of messages, choreography of
the protocol, ... all this is "context" specific (not just
implementation specific)).

 

JJ-

 

________________________________

From: david.burdett@commerceone.com
[mailto:david.burdett@commerceone.com] 
Sent: Monday, July 19, 2004 12:39 PM
To: Jean-Jacques Dubray; gary@enigmatec.net;
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

 

JJ

 

You said ...

 

>>> 

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>

<<< 

 

Couldn't you have different protocols that could result in the same end
state? Also, I think that you could have different messages, with
different representations, binding to transport protocols, etc, that had
the same semantic.

 

David

	-----Original Message-----
	From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com]
	Sent: Monday, July 19, 2004 10:27 AM
	To: Gary Brown; Burdett, David; 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

	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