Re: State Alignment and Standard Signals

If we were to support signals of any sort, and I view this is named 
message types, then we need to be sure that they have general 
applicability in all domains of interest. If we cannot then we would 
need to consider an ontological approach in which the ontology of the 
domain is loaded and that is what provides the definitions of the named 
message types. This approach would obviate the need to define 
"built-in" named message types and retain all of the expressiveness 
that they provide but rooting it in the applicable domains.

Cheers

Steve T

On 19 Jul 2004, at 20:56, Jean-Jacques Dubray wrote:

> 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
>
> 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
>
>