Re: Change of participants

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 Wednesday, 23 April 2003 22:14:46 UTC