RE: Multiple instances of interactions

Alistair,

At this stage I don’t think there was any intention to constrain
multiple parallel instances of an interaction i.e. there is no
requirement to restrict. 
Cheers,
   Martin. 

> -----Original Message-----
> From: Alistair Barros [mailto:abarros@dstc.edu.au] 
> Sent: 19 March 2004 01:26
> To: Martin Chapman; public-ws-chor@w3.org
> Subject: RE: Multiple instances of interactions
> 
> 
> Martin,
> 
> It answers it in part, but the question remains, that under 
> asynchronous request-response, do you want to constrain at 
> the choreography level, the number of *parallel* instances 
> that a given interaction can have (one/some)? For while I 
> cited a case where it is appropriate to have more than one, 
> there are other cases where more than one will create a 
> problem, eg. double requests or double responses.
> 
> To stretch the question further, is such a constraint a 
> matter for the lower level web service to resolve, with chor. 
> allowing an arbitrary number of parallel instances of 
> interactions of the same type?
> 
> Or should a global model choreography expose this constraint?
> 
> Cheers, Alistair.
> 
> 
> -----Original Message-----
> From: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: Friday, 19 March 2004 9:37 AM
> To: abarros@dstc.edu.au; public-ws-chor@w3.org
> Subject: 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 Friday, 19 March 2004 12:49:18 UTC