RE: Multiple instances of interactions

Okay, but this has implications for the operational
semantics of CDL and the progress of choreography.

Are further instances of a messaging interaction
necessarily idempotent wrt to choreography state?
I doubt it, as bourne out by the use case I described.

Anyway, this issue can be out aside until the semantics
of CDL are being charted out.

Cheers, Alistair.

-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Saturday, 20 March 2004 3:49 AM
To: abarros@dstc.edu.au; public-ws-chor@w3.org
Subject: 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 Sunday, 21 March 2004 20:15:55 UTC