synchronous: use cases

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: synchronous: use cases

Use cases for synchronous messaging, defined here independently from the transport layer, as an ordering between application-level req-resp MEPs (can't send M2 before getting a response to M1), as opposed to a way to map to a lower level req-resp transport, which introduces a dependency to the transport, and muddles the meaning, e.g. depends on transport properties like HTTP pipelining, etc.

(This def of synchronous, that I logged on our requirements wiki, was suggested to me by Suresh Damodaran, former lead on RosettaNet messaging.)

use case #1:
Applications cannot always control the sequencing of message exchange patterns, e.g. a business process triggers different activities A1 and A2 each responsible for preparing/sending respective messages M1 and M2. On teh receiver side, M2 is not expected before the response to M1 has been sent out. But on sender side, it may not be possible or convenient to strictly serialize A1 and A2, and these may not allow fine-grained synchronization. (e.g. where A2 is notified by A1 when the response to M1 is received)

use case #2:
In case business signals such as Receipts (e.g. for non-repudiation) are dispatched to an application component separate from the one that handles regular messages, an application may loose te ability to control the sequencing of exchanges that mix these messages, so that they may not comply anymore with an order expected on the receiver side.

In both cases, assuming that the MSH has some intelligence of correlation between messages of a req-resp pattern, (e.g. with RefToMesgId in ebMS) the problem will be solved if the MSH enforces the serialization of req-resp MEPs.

Jacques