Re: Change of participants

Assaf, thanks for feedback !  My comments embedded.

At 01:40 PM 4/17/2003 -0700, Assaf Arkin wrote:
>First, can we view it in a more generic sense as a conversation where 
>participants can join and leave?

We certainly can take this more generic view.  But I try to explore whether 
certain roles (e.g. initiator) has some distinct behavior, although it is 
not very clear to me at this moment.


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

I mean the same thing as you, maybe just the terminology 
difference.  "Role" is like a named variable and "Participant" is like a 
value.  Binding is like an assigning a value to a variable.  (e.g. seller = 
"Amazon")


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

Of course, but I think the question is whether these two roles need to be 
bound at the creation of the choreography instance, or whether the second 
role can be bound one day later.  And my vote is the former.


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

This one participant must be the initiator who send the first message.  But 
to whom he sends the message... Isn't the participant who receive the 
message also need to bind to another role  ?  Then there must be at least 
two roles being bound when the choreography start.


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

"Inactive" is different from "leaving" (or "unbound").  "Inactive" is to 
describe the "role" while "leaving" is to describe a participant.  For 
example, once the order is place and shipment arrange.  All the 
interactions are between the role "buyer" and role "shipper".  The role 
"seller" is "inactive" but not "unbound".  On the other hand, the role 
"shipper" is very "active" even though the participant "Fedex" has already 
left that role (and replaced by participant "UPS").


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

Back to the Amazon selling use case, should Amazon define each online 
transaction as one choreography instance ? or should Amazon define a 
"RunTheBusiness" choreography which has only one instance running for many 
many years ?

I think this restriction may help to limit the life span of a 
choreography.  And this reflects most real life scenarios.  When a buyer 
switch to a different seller, he is starting a new conversation rather than 
using the existing conversation.  Can you give me a real life example where 
changing the initial two roles doesn't start a new conversation ?

A participant is NOT equivalent to a web service endpoint.  Changing an 
endpoint is not the same as a role rebind.  E.g. Amazon can change its 
endpoint address and pass the endpoint reference around to other 
participants (somewhat like passing channel in mobile process calculus), 
but this is NOT a role rebind.  But Amazon may appoint Fedex as the shipper 
and send the endpoint of Fedex to the buyer.  This is a role binding.

Rgds, Ricky


>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 Friday, 18 April 2003 00:34:42 UTC