- From: Alistair Barros <abarros@dstc.edu.au>
- Date: Wed, 17 Mar 2004 13:03:00 +1000
- To: <public-ws-chor@w3.org>
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