W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

Change of participants

From: Ricky Ho <riho@cisco.com>
Date: Thu, 17 Apr 2003 13:09:42 -0700
Message-Id: <>
To: "Martin Chapman" <martin.chapman@oracle.com>, <public-ws-chor@w3.org>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:01 UTC