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

Two points:
1) choreography and state occurs at different levels for processes and
objects
2) Interaction between an internal process/application can go both
ways.  The external state may be dependent on an internal response.
Example, in B2B, you receive a message with payload.  Check for
well-formedness - handoff to parser to check - valid - handoff to
external view where an acknowledgement is generated and sent.

Thanks.



Ricky Ho wrote:

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