W3C home > Mailing lists > Public > public-ws-chor@w3.org > March 2004

Multiple instances of interactions

From: Alistair Barros <abarros@dstc.edu.au>
Date: Wed, 17 Mar 2004 13:03:00 +1000
To: <public-ws-chor@w3.org>
Message-ID: <HIEFLCBPHBOMEAGKKEPICEKMCHAA.abarros@dstc.edu.au>

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 Tuesday, 16 March 2004 22:03:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:22 UTC