Re: Change of participants

Ricky Ho wrote:

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

The initiator role is a very special role. It's stable or sticky 
depending on which terminology you want to use. If you are the initiator 
then you are the initiator. But that's an honorary title and I don't see 
the interest in describing it. Roles such as buyer and seller are more 
interesting, and though a buyer may be the initiator it's more 
interesting to talk about what a buyer does. After all, all initiators 
in all choreographies do the same thing - send the first message.

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

The role is sticky - it's part of the choreography definition. If the 
choreography says that some message is sent by the buyer then it will 
always be sent by the buyer. It may be a different buyer at different 
point in times, but it's always a buyer. I don't see the value of 
changing roles, I can only imagine a choreography where all roles are 
known in advance.

What you bind is a participant. So you're not binding a seller, you are 
binding a particular seller, like Amazon. And maybe Amazon says "out of 
stock" and you decide to bind some other participant like CDNow. Both 
are sellers.


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

What about the airline and truck shipper example. They both compete for 
a message and the first one to receive it and respond gets the lucrative 
deal of shipping some product. So when do you bind the participant: when 
the first message is sent, or after that message is received? And if 
that happens after the message is sent, does that mean there is no 
choreography instance yet?

Second question, what does binding mean? Let's say I start a new 
choreography instance as a buyer. Do I have to do any extra step to 
"bind" myself to the choreography? Now I send an order request to Amazon 
which I assume they will receive. Do I have to do any extra step to 
"bind" Amazon to the choreography?  Do I need to communicate anything 
other than my callback address?

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

I perfectly agree about this terminology.

Once the order is in place and shipment arrange, is it the roles that 
are interacting or the participants?


>> 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'm not sure why it makes a difference. Amazon has a specific use case 
for a three-party choreography. That does not lead me to conclude that 
we need a tri-party choreography language. Just leads me to conclude 
that a multi-party choreography can support their use case.

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

Multi party choreography between buyer, seller and shipper. Say buyer 
decides which shipper to use, seller contacts shipper and finds out 
shipper cannot deliver, buyer and seller agree to use a different 
shipper. Time to go back and start a whole new conversation between 
buyer and seller?


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

Agreed. But isn't the mechanism still the same. If Amazon is appointing 
Fedex as the shipper and sending that endpoint (or even multiple 
endpoint or just some generic form of identification) to the buyer, then 
it's passing channels around.

I just wouldn't write a language that has specific mechanism for letting 
you change only roles called "shipper". I would think it's much easier 
to apply this logic symmetrically, i.e. all roles are the same and 
binding rules are equivalen to all roles. From experience, a language 
that is based on the general case is easier to define and use than a 
language that makes a lot of special provisions.

arkin

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


-- 
"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 01:48:16 UTC