RE: Scope of Choreography [was Uses of the WS Choreography Spec]

 
comments inline ...

Sanjay Patil 
Distinguished Engineer 
sanjay.patil@iona.com 
------------------------------------------------------- 
IONA Technologies 
2350 Mission College Blvd. Suite 650 
Santa Clara, CA 95054 
Tel: (408) 350 9619 
Fax: (408) 350 9501 
------------------------------------------------------- 
Making Software Work Together TM 

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Monday, March 31, 2003 8:45 AM
To: 'Cummins, Fred A'; Burdett, David; 'public-ws-chor@w3.org '
Subject: RE: Scope of Choreography [was Uses of the WS Choreography Spec]


Fred
 
See comments inline below, marked wiht [David Burdett 2]
 
Regards
 
David

-----Original Message-----
From: Cummins, Fred A [mailto:fred.cummins@eds.com]
Sent: Thursday, March 27, 2003 7:18 PM
To: Burdett, David; 'public-ws-chor@w3.org '
Subject: RE: Scope of Choreography [was Uses of the WS Choreography Spec]


David,
 
Thanks for your comments--sorry for the delayed response.  See my comments, below.
 
Fred

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]

Fred
 
I agree strongly with the approach you suggest below, although I have a few comments described inline.
 
David

-----Original Message-----
From: Cummins, Fred A [mailto:fred.cummins@eds.com]

.............
When a participant sends a message, it's public state is changed to a state 
that reflects the possible responses expected.  
[David Burdett] I am wondering how the public state can have multiple states. Doesn't the choreography imply the possible states that could occur? <<<
[FAC] Yes, the choreograpy specifies the states that will occur, and the state transition that will occur when a message of a particular type is sent.  But it does not specify what causes the participant to send a message of a particular type, nor does it define how to determine the type of the message.  To be compliant, the participant must set it's public state (explicitly or implicitly) to the state appropriate after sending the message as defined by the choreography.  This public state then establishes the potential responses that are appropriate according to the choreography.  
[Patil, Sanjay] +1 
............
 When a response is received,
the message content is not determined within the scope of the choreography
specification, but is delegated to the internal process/application to which
the response is directed.  
[David Burdett] Isn't this an implementation decision? Therefore it is a decision that the role the receivingthe message must make.<<<
[FAC] No.  This takes the determination of the message type out of the scope of the choreography, i.e., it hides this criteria so that it is up to the participant to make this determination.
[David Burdett 2] if you do this, then it means that *only* the application can validate that a message has been received that conforms to the sequence/rules of the choreography. If, on the other hand, the message type is included in the choreography (e.g. in a header) then a separate engine could validate that the choreogrpahy is being followed correctly.  
[Patil, Sanjay] I guess the message type name is different from the message type itself. For example, a Purchase Order defined published by a consortium XYZ may have a XSD schema definition along with a type name for the schema, say XYZ/PurchaseOrder. I guess the type name is within the scope of the choreography, but not the full schema. 
........
Where faults occur in the communication, these must be communicated to
the internal applications for subsequent action. The choreography should be
able to express possible continuation (e.g., retry, re-connect) of the exchange
in spite of faults or delays.  A time-out would be similar to the receipt of a bad
message.  It is probably useful to specify the time-out period in the 
choreography so there is an understanding of how long a participant will wait
for a response.  
[David Burdett] I disagree. The time-out values to use can vary from implementation to implementation. Therefore the timeout should be in the binding of a choreography to an implementation. <<<
 A time-out might be treated differently from a bad message,
but the determination of the resulting public state transition should probably still be
delegated to the internal process/application.
[FAC] My concern is that the sender of a message should be informed by the choreography
specification regarding how long it can take to return a response before the waiting
participant will consider the response to be timed out.  After a certain period of time
the slow responder may simply wait for the other participant to take the time-out
action.
[David Burdett 2]  I agree, but if we include this in the choreography definition, then we will would have one choreography when the you wanted to wait 1 minute for a response, another, effectively identical choreography, when you wanted to wait 2 minutes. As the *only* difference in these choreographies would be the amount of time you wait before you *time-out* you will get tremendous repetition. Wouldn't it be better to bind the timeout to an *implementation* of a choreography rather than to the choreography definition. That way you could have just one choreography definition.
[Patil, Sanjay] I think the choreography language should allow both the possibilities, that is, the timeout value may become either part of the public contract or may be specified as part of implementation details. For example, in a B2B scenario it is important that the timeout values are agreed upon apriori. (RosettaNet PIP is an example here, which generally includes timeout values). In other scenarios, it may be efficient to simply obtain the timeout values in an out-of-band manner and configure the individual systems.