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.

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

Received on Monday, 31 March 2003 11:45:02 UTC