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

David,
 
See my comments, below [FAC 2]

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Monday, March 31, 2003 11: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.

............
 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.  
[FAC 2]  I see no need for a separate engine to validate the choreography.
This exposes the logic that belongs to the participant.  Putting a code in
the message to indicate the type it is supposed to be is no less subject to
errors than the participant changing the public state to reflect the intent.
On the recipient side, the content must still be validated to ensure that it
is the type of message such a code puports it to be.
........
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.
[FAC 2]  The choreography should be about expectations: what a participant
is expected to do and what he should expect the other participant to do.  A
time-out specification would belong to the choreography to define
expectations.  If a participant decides to violate those expectations, then
the participant is adding confusion to the exchange which may be a cause for
unpredictable results.  The time-out specification would simply indicate how
long a waiting participant is expected to wait, i.e., what is reasonable.
Another alternative would be to include it as a variable in the exchange,
but then it becomes rather unilateral, i.e., the requester defines how long
he will wait, but the responder may not have an opportunty to define how
long it is likely to take.