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