Re: Change of participants

First, can we view it in a more generic sense as a conversation where 
participants can join and leave?

Second, can we make a distinction between roles and participants. Roles 
are not bound - they should be defined as part of the choreography. A 
seller is always a seller. Participants are bound and they could change. 
It could be Amazon today and CDNow tomorrow.

For the choreography to be defined there need to be at least two roles 
otherwise no one is communicating. No value for services talking to 
themselves ;-)

For the choreography to start you need one participant to be bound to 
one role, otherwise nothing will happen. Everything else is optional.

At some point a participant for some role may have no further 
contribution to the choreography, but the choreography must progress. At 
this point do we force the choreography to stop because a participant 
has no contribution to make? Do we force the participant to send "I am 
alive, I have nothing to say, but I am alive" messages?

Can you explain the value that these restrictions bring to the 
definition of the choreography?

arkin


Ricky Ho wrote:

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


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Thursday, 17 April 2003 20:23:27 UTC