Re: Change of participants

Ricky Ho wrote:

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

Yes you can. I don't see what the buys you because you can always work 
around it. Let's say that the buyer is a special role that cannot be 
rebinded by fact of being the initiator. Let's say there's some good 
reason to change buyer midway, e.g. because the initiator is not the 
actual buyer but some participant representing the interest to procure 
products. So you write the choreography in terms of orderSubmitter and 
orderReceiver roles. The first one is initiator and never rebinded, the 
second one is not the initiator and you can rebind it. You end up 
achieving the same effect as if you could have just buyer and rebind it. 
So the restriction is really artificial and require some extra level of 
specification.


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

I think the number of roles is known in advance. Also, the number of 
participants can be known in advance in many cases, because the 
choreography must express when/how they are bound. The choreography can 
be writen such that there it has two roles (say buyer and seller) and 
once two participants are bound there is no opportunity to rebind them. 
So once you start it you know the binding will not change. Another 
choreography can allow some participant to be late-bound but only once, 
yet another choreography can allow continuous rebinding until you 
achieve the desired outcome.


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

I don't think that this is a real problem. The principle I prefer here 
is that everything that must be known must be communicated in one way or 
the other, and that all communication should be expressed in the 
choreography. So the choreography is correct if the relevant 
participants learn about other participants because that information is 
communicated rather tha magically assuming some binding. And in reverse, 
any attempt to bind requires that the information be communicated to 
whom it may concern.

If I build a choreography where I don't allow this type of communication 
to occur, then the buyer is going to talk to some shipper and the seller 
is going to talk to some shipper and you can guarantee that it will be 
the same role but how do you guarantee it will be the same actual 
shipper? You need to communicate it at some point or the other, maybe up 
front (submitted order indicates which shipper to user). If you think 
that's the best way to go and you don't mind that you can't change 
shippers later on in life, then just design a choreography in that way.

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

So the buyer talks to the seller and at some point a shipper is brought 
into the picture, which may be the airline or truck company, but only at 
that point does the choreography instance exists?


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

Absolutely.

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

I would definitely design choreographies where the seller is never 
changed, once it has been decided and communicated everybody uses the 
same seller. On the other hand, I may want the shipper to change. So now 
I have two options:

- Define the language by introducing different kind of roles. One that 
allow participant binding once, one that allows participant binding and 
rebinding, and all the other combinations. That would create quite a 
complex specification.

- Define a generic language and use it in a manner that makes sense. 
Even though there is no restricting on which participants can be 
rebinded, since it makes no sense to change supplier in the same 
choreography instance we don't design choreographies that do that.



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

Now, this is a good question and there are two ways to look at the 
problem. Perl is definitely easier to use for specific things than C and 
is more restrictive. But Perl doesn't prevent you from shooting yourself 
in the foot. It's still broad and generic and you still need to apply 
best practices to use it.

Let's assume we have a language that let's you rebind any participant at 
any point but is very precise on what happen so you can define 
choreographies that use this capability a lot, and you can also define 
choreographies that never use that capability because it makes no sense 
for the particular use case. The language is going to be fairly simple. 
It's going to allow you some things you may not be interested in doing, 
but it's going to be a very simple language.

Now let's extend that language to separate between roles that allow 
these rebinding and roles that do not. That language may look similar to 
what the 80% of cases end up doing, and that's a justification for that 
language. And a lot of people in this group hold the opinion that that's 
just what we need. But that language needs to take an extra step to make 
that distinction, which means the language itself is more complicated. 
And it still doesn't prevent you from getting around that limitation it 
just means a slightly more complicated language and a bit more effort to 
get around that imposed restriction. My personal opinion is that there's 
no need to get into that level of complexity because at the end of the 
day you only work harded and achieve the exact same outcome.

arkin

>
> Rgds, Ricky
>

Received on Friday, 18 April 2003 17:22:38 UTC