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

At 01:37 PM 3/21/2003 -0600, Cummins, Fred A wrote:
>I believe the concerns about variation in message content and meaning can
>be addressed by a clear definition of scope of the choreography specification.
>The mechanisms of transport and reliable delivery should be abstracted out
>of the choreography, as should the message envelope/packaging.  Furthermore,
>the determinination of the validity and meaning of a message should be
>performed by the participant's internal business logic/process that is also
>abstracted out of the choreography specification.  Let me explain.

+1

>
>Each participant has a public state where possible states and state 
>transitions
>are defined in the choreography.  The public state only changes as a result of
>the receipt or sending of a message.

Not necessary.  The "public state" can change after a timeout-period.  E.g. 
If you don't accept my offer in 2 hours, my offer is automatically invalid.

>
>When a participant sends a message, it's public state is changed to a state
>that reflects the possible responses expected.

I think there will be different levels of choreography.  We can have high 
level business choreography (e.g. sending a PO) or low level one (e.g. RM 
handshaking etc.)  This one you describe can be sitting at the middle level 
(e.g. MEP).  I think choreography should be capable to describe TCP 
handshaking, but lets focus at business level 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.  The only immediate change to the public state
>may be to reflect that the internal process is busy processing the 
>input.  When
>the internal process determines the validity and meaning of the input, it
>formulates an appropriate response (as constrained by the valid state 
>transitions
>from the current public state), it sends the response and it causes the public
>state to change accordingly.
>
>Consequently, while the public states and state transitions, and message
>semantics are referenced by the choreography, the interpretation of the 
>message
>content and the determination of the corresponding public state transition
>are accomplised within the internal process/application, and need not be
>specified in the choreography.

It really depends on whether the decision criteria is a private one or a 
contractual binding.
Yes !  The private decision shouldn't be defined in the choreography.
But the public, "mutually agree-upon" decision should be defined in the 
choreography.  E.g. The order will be rejected if the amount is over 500K 
and doesn't have a valid signature.

>
>It may be useful to indicate the "normal" state transitions expected for each
>message input or output in order to focus on the performance of the exchange,
>but the choreography should express all valid exchanges where the messages
>are expected to be meaningful, whether or not they represent a successful
>business transaction.

I agree !  But the level of message exchange details depends on the level 
of choreography you want to express.  E.g. If I'm expressing a business 
level choreography about order processing, I probably won't specify the 
underlying RM ACK, RM retry message exchange.

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

I'm not sure about the last statement.  Because public state represents a 
"consensus" between collaborating parties, I don't think the internal 
process of one party can unilaterally control the public state 
transition.  I think public state transition is a co-ordination 
handshaking.  Lets look at the following scenarios, assuming the current 
public state is S1

1) PartyA propose moving to S2.  The contract says PartyB don't have any 
choice.  So PartyA move to S2 after sending the proposal message.
2) The contract say PartyB doesn't have to agree.  When she disagree, the 
contract say the public state will be staying at the original state (ie: S1).
3) Alternatively, when PartyB disagree, the contract say the the public 
state will be move to another state S3

Rgds, Ricky

>
>So it doesn't matter to the choreography how the message is communicated
>nor how it is packaged or formatted.  The choreography only deals with the
>semantics of the message (i.e., the business intent of the message, such
>as new order, acknowledgement, rejection, counter-offer) and the possible
>state transitions that will be selected by the internal process/application.
>
>Fred Cummins
>EDS