OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: SyncReplyMode as defined in .91 is a misnomer


The way the syncReplyMode attribute is defined in .91 version of the spec is very confusing.  Section 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:
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC