SyncReplyMode as defined in .91 is a misnomer

[Prasad Yendluri <pyendluri@webmethods.com>]

David,

The way the syncReplyMode attribute is defined in .91 version of the spec is very confusing.  Section 8.4.7.3 reads:

> The syncReplyMode is an optional
> attribute that indicates whether a response to a message must be returned
> at the same time as any acknowledgments. It has two values:

• True which indicates that the MSH that receives the message MUST get the message processed by the application or other process that needs to process it before the MSH sends any response to the original message, or
• False which indicates that an acknowledgment to the message MAY be sent separately before processing of the message by the application or other process.

This is basically defining if a message should be processed before "any"
response is sent back or not. This combined with the deliverReciptRequested
parameter, simply boils down to whether the acks and response are all sent
together or if acks are sent first and then the response.

1.  Since the ebXML message structure is now flexible enough to permit the acks to be sent either in separate ebXML messages or in the same ebXML message as the response, why impose the requirement that all of them should be sent together, as a general case? This defeats the purpose of reliable messaging IMHO, where you have the mechanism of Acks to inform the sender that the message had been received (by the receiver), prior to a response being available. If the receiver was able to process the message within the timeout constraints of sending an acknowledgment, they might be able to send them all in the same message. However, the sender should not be able to mandate it.

2. This is NOT addressing  the issue of sending response (and Acks) "synchronously" on the same communication protocol level connection as the request. Hence the use of the term "Sync" in the "SyncReplyMode" is totally misleading.

3. The only situation where you would want the sender to indicate that both Acks and Responses  should be sent together is, when we have the case of "synchronous exchanges/transactions". Here the response comes back on the same communication protocol level connection and since typically the communication protocol level session ends after the reply comes back, we need to provide for a way to specify, if only the Ack needs to be returned synchronously; only response (no acks); or both acks and response need to be returned synchronously. In my proposal, I call for this to be part of the CPA with headers simply echoing  the CPA for the convenience of processing by the MSHs. I am attaching my proposal for immediate reference here.

4. Since the way you defined the SyncReplyMode in .91 version is not addressing how RPC like responses can be delivered on  HTTP / MessageQueues / LU6.2 etc. connections synchronously. Use of the same attribute name "SyncReplyMode" that I used in my proposal that addresses this case, is really a misnomer and confusing the issue.

5. If there still is a need for the senders to specify that both acks and responses should be sent together irrespective of "synchronous" exchanges, I think we need to use a different name for this attribute. This makes no sense to me however, as this defeats the purpose of reliable messaging.

Regards, Prasad

SynchronousExchanges.doc