Re: Change of participants

Assaf, embedded ...


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

I agree that "initiator" is not a role.  But can I say that only certain 
role can be the initiator, and this roles cannot be rebinded during the 
lifecycle of the choreography instance ?


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

I completely agree.  Do you think the number of roles is known in advance 
(ie: there are a finite number of roles) ?  Can there be varying (multiple) 
number of sellers within a choreography ?

One of the challenge of "role rebinding" in multi-party choreography is how 
to ensure that every party (at the same time) knows that a particular "role 
rebind" has happened.  There is a problem if the buyer think that the 
shipper is Fedex while the seller think the shipper is UPS.  Of course, we 
can say it is up to the person who define the choreography to ensure there 
is sufficient message exchange between the buyer and seller to communicate 
that kind of change (role rebinding).  But can the model enforce that this 
cannot happen.  (In other words, should there be a standardized way 
(outside flow definition itself) to communicate role rebinding ?)



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

I would say the binding to shipper happens after the first one (airline or 
truck company) receive it.  Right after that the choreography instance starts.


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

Lets distinguish between "making a bind decision" and "communicating an 
already made bind decision".  I think binding can be implicit in the 
message exchanges (as describe in your example above).  I also think the 
binding step itself can take several message exchange, the seller send a 
request to shipper and the shipper send back an acknowledgement before it 
is successfully binded.


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

I would loosely says the roles are interacting.  Or more precisely, the 
participants who bind to the roles are interacting.



>>>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 agree a general model can support all of these.


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

No.  I haven't said any role rebinding requires a new choreography instance 
(and your example above perfectly illustrate that).  I'm only saying 
rebinding of "certain role" cannot happen (and so requires a new chor 
instance).  In your example, if the buyer decided to switch to a different 
seller (e.g. from Amazon to CDNow), then it has to start a new choreography 
instance.

Otherwise, the buyer unbind "Amazon" and bind "CDNow" which joins in the 
middle of a chor instance.  The "generic" model certainly can support this, 
but I think this is unnecessary complicated.



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

I think sometimes you want to put restriction to a too-generic model to 
avoid its user to make mistake.  And also such extra restrictions can 
introduce new behavior which makes the modeling of a narrower domain much 
simpler.  For example, I can write a C program to do any arbitrary complex 
string pattern matching stuff, but I prefer to use a more restrictive Perl 
language to do that.

Rgds, Ricky

Received on Friday, 18 April 2003 10:41:24 UTC