RE: SyncReplyMode as defined in .91 is a misnomer

["Burdett, David" <david.burdett@commerceone.com>]

Prasad

 

I think there is a disconnect between what we are each thinking on this topic as you seem to be thinking that I'm trying to defeat the purpose of reliable messaging (which I'm not), and I think that you are making the specification too non-deterministic which will add unnecessarily to MSH complexity, as well as requiring the addition of header attributes/elements that could be in conflict with other elements that have already been defined.

 

See more comments inline.

 

David

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
Sent: Friday, January 05, 2001 12:41 PM
To: Burdett, David
Cc: ebXML Transport (E-mail)
Subject: SyncReplyMode as defined in .91 is a misnomer

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.  

<DB>This means that a sender of a message will not know if the response they get will be an ack, or an ack and a response together. This is not normally an issue unless you are using a synchronous transport - see more below. I don't think it defeats the purpose of reliable messaging. It's really a question of how tightly/loosely you control what goes into a response to a message.</DB> 

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.  

<DB>I agree. However, I think that returning a response on the same communication protocol level connection is a communication protocol issue, and therefore information that only applies to a particular protocol should not be in the Message Header. In version 0.91 there an HTTP header "ebxmlresponse=synchronous" that is used to indicate whether or not a message sent in reply to an earlier message must come on the HTTP response.

What I am uncomfortable with is the idea that the sequence of messages that are returned will be different in a non-deterministic way depending on whether or not a synchronous transport protocol is being used. For example if we follow your approach and use AcksAndResponse for a message sent over HTTP then the acknowledgement and response would come back together. But if you sent the same message over SMTP, then they might come together but then they might not. This seems to add unneccessary additional complexity IMO to the behavior of a MSH.

I can understand how you might want to be allow a recipient of a message to decide whether or not reply with an ack or an ack and a response, but I also think that the CPA should enable that a response is always in a particular format. So how about the following parameter values"

• AcksOnly - i.e. the first message returned MUST only contain an Ack
• Response Only - i.e. No ack MUST be returned and the first message returned MUST only contain a Response. This also has the problem that it would be inconsistent with DeliveryReceiptRequested set to Signed or Unsigned.
• AcksAndResponse - Ie the acks and the response MUST be returned together. This has a problem in that it would be an error if there was no response to a message.
• ReceivingMSH Decision - this means the receiver of the message decides whether to return an ack, a response or both if the underlying transport protocol is asynchronous.

I am also uncomfortable with having two parameters that imply essentially the same thing. For example if deliveryReceiptRequested or immediateAckRequested are both set to NONE, then a syncReplyMode of AcksOnly or AcksAndResponse would be inconsistent. We really ought be able to avoid this sort of problem with the correct choice of parameters.

</DB> 

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. 

<DB>I disagree, the HTTP parameter allows you to get a RPC like response. I agree though that a name change might apply, would replyMode be a reasonable term?</DB> 

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