Specifying constraints among "roles"

Assaf,

Do you think the Choreography model should allow constraints being 
specified among roles which is independent of the message exchange ?  For 
example in an "auction" scenario, lets say there is a "potential buyer" 
role and "ultimate buyer" role.  And I want to specify the following 
constraints regardless of the flow (in fact, I want to validate the flow 
conform to such constraint) ....  These are my required constraints

1) There can be multiple entities binded to the role "potential buyer", but 
only one entity binded to the role "ultimate buyer".
2) The entity binded to "ultimate buyer" must be one of the entities who 
previously binded to "potential buyer"
3) Once the "ultimate buyer" is binded, no further binding of "potential 
buyer" should happen

Do you think the choreography model should allow such constraints being 
specified ?

Rgds,
Ricky


At 05:58 PM 4/23/2003 -0700, Assaf Arkin wrote:

>Jon Dart wrote:
>
>>
>>I am not convinced (at least, not yet) that this couldn't be accomplished 
>>by either expanding the number of allowed participants in the 
>>choreography, or making the set of participants open-ended (dynamic 
>>participation in the sense it has been discussed earlier).
>>
>>E.g. if I can start an interaction and then delegate to another party to 
>>finish it, then perhaps the choreography should explicitly allow that 
>>party to "join" mid-conversation, and initiate or respond to one or more 
>>of the possible interactions.
>>
>>Fred actually gives some good reasons why you wouldn't want to 
>>dynamically change the binding of a role during the scope of a 
>>choreography execution, security being one of them .. although depending 
>>on exactly how things were implemented, this might or might not be an 
>>actual problem. E.g. you could make "rebind role" be an explicit step in 
>>the process, and have it imply re-authentication.
>
>+1
>
>>Another comment: per my earlier remark, some business justification for 
>>this facility would be helpful.
>
>The business case is me submitting an order and before the order gets 
>processed I would like to change it. Changing an order may be more cost 
>effective than cancelling the order and starting from fresh.
>
>There are a lot of things I can ask you to change. Some of them affect 
>which products you would send me, others affect how you would package 
>them, or whether you would ship them on the same day or in multiple steps. 
>Some of them affect where you would be sending stuff.
>
>If long-lasting means anywhere between one minute and 24 hours, then worst 
>case if something has to be decided later or change, we'll just abort the 
>choreography and start a new one. But if long-lasting is unconstrained, I 
>want to account for the possibility that some things may happen and be 
>able to accept them and carry on without scrapping everything.
>
>Also, I like to think outside the box. There's an implicit assumption that 
>as a supplier all the services for ordering, invoicing, payment, shipping, 
>etc are handled at the same location (one address). On the other hand 
>there are many companies who would like to outsource these services - they 
>may do the marketing but outsource the inventory to one service provider 
>and the invoicing to another. WS is one of the enabling technologies for 
>service outsourcing, so let's factor that as a use case we want to support 
>not shun from.
>
>arkin
>
>>
>>--Jon
>
>

Received on Thursday, 24 April 2003 00:39:20 UTC