Re: Change of participants

Assaf, more ...


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

So there is one seller (although it can be binded to different participant 
at different time) ?  or multiple sellers at the same time ?  In other 
words, can I start a choreography instance and buy from Amazon and CDNow 
(both are playing the role "seller" at the same time) ?

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

No, only the buyer and seller (not shipper) need to be binded for the 
choreography instance to start.  In my model, the first 2 bounded roles has 
different semantics then the other roles.


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

I understand your point.

Ricky

Received on Saturday, 19 April 2003 10:15:25 UTC