RE: Multiple instances of interactions

Alistair,

I believe the following covers your concerns:

"C-CR-5205   
A CDL MUST enable the determination of which collaboration group a
message belongs to. "
   
This requirement implies some correlation mechanism is needed, and is
consciously broad enough to cover synchronous request response, one
ways, and other asynchronous styles.

Cheers,
   Martin.

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of Alistair Barros
> Sent: 17 March 2004 03:03
> To: public-ws-chor@w3.org
> Subject: Multiple instances of interactions
> 
> 
> 
> Steve and the editing team,
> 
> Well done on your efforts in compiling the new version
> of the requirements document. I've just read it after a bit
> of an absense, so please excuse any johnny-come-lately
> in my questions.
> 
> The Travel Agent use case captures in part some of the
> issues I raised in an earlier case study. There's one
> subtlety which appears to be open.
> 
> This is where incoming messages are related in an *interaction
> set* and need to be "synchronized".
> 
> For example, imagine that the Buyer needs at most three 
> quotes for the same component from suppliers for the same 
> variation request - in order to create a purchase order, 
> which gets approved subsequently in the Buyer's workflow.
> 
> Quotes arrive asynchronously at different times and cannot be 
> guaranteed from suppliers (suppliers may ignore requests). 
> The solution from a workflow perspective would be to 
> partially synchronize the responses using a 3-out-n 
> discriminator in the Buyer's workflow. The trick is that 
> multiple variation may have occurred, and therefore multiple 
> interaction sets between the Buyer and Suppliers may exist. 
> They may exist, moreover, simeltaneously since responses in 
> business processes are typically asynchronous and it is hard 
> to interleave requests and responses, one after the other.
> 
> Therefore, the determination of 3-out-n needs
> to pertain to the right interaction set *instance* and not 
> cut across it. Meaning incoming responses of the same request 
> instance need to be discriminated against, in the presence of 
> potentially co-existing requests.
> 
> Two general questions emerge from this for choreography: is 
> there an implied constraint about many times a party may send 
> a message to another party. The case study implies that an 
> interaction must involve a response after a request. What 
> happens if new requests are allowed to be issued without 
> responses having been seen? Is it arbitary at the 
> choreography level, with the underlying web services, 
> workflows etc left to resolve this issue? Relatedly, should 
> the discrimination (as I described it ) be pushed up into 
> choreography (the above situation doesn't need it).
> 
> I hope this makes sense.
> 
> Cheers, Alistair.
> 
>

Received on Thursday, 18 March 2004 18:36:34 UTC