Change of participants

For point 2a, is this related to multi-party choreography ?  I can't 
imagine a use case of participant change in a bi-party choreography.

In multi-party choreography, we need to look into the constraints of such 
changes.  For example, in a buyer/seller/shipper choreography, I see 
"changing a shipper" can still be the same choreography instance.  But I 
have a hard time to understand if the "seller" can be changed, even harder 
if the "buyer" is changed.

So I'm thinking a stricter one ...
1) For a choreography to start, there needs to be at least two roles being 
binded.
2) These two initial role binding cannot be changed

as well as a looser one ...
1) For a choreography to start, there needs to be at least one role (the 
initiator) being binded.
2) The initiator role binding cannot be changed.

Comments ?

Rgds, ricky

At 12:04 PM 4/17/2003 -0700, Martin Chapman wrote:

>As per my action point here is a list of proposed requirements extracted
>from the minutes of the tues 8 April con call.
>
>1. A Choreography should be independent of message formats
>
>2. A Choreography may have run time changes:
>    a. the actual participants can vary
>    b. the actual choreography can vary [ed: I think we ruled this out
>but have listed it for completeness]
>
>3. It should be possible to query the state of a Choreography
>
>4. Error/fault handling and compensation features need to be able to be
>expressed in the language.
>
>5. Choreographies should be composable (into a hierarchy)
>
>
>Martin.
>
>_________________________________________________________________
>Martin Chapman                                 500 Oracle Parkway
>Consulting Member of Technical Staff           Ms 4op990
>Oracle                                         Redwood Shores,
>P: +1 650 506 6941                             CA 94065
>e: martin.chapman@oracle.com                   USA

Received on Thursday, 17 April 2003 16:09:52 UTC