Re: SyncReplyMode as defined in .91 is a misnomer

[Prasad Yendluri <pyendluri@webmethods.com>]

David,

The CPA/ebXMLHeader based solution *is* a deterministic solution as it is clearly identified in the DeliveryChannel specification and is applicable to the entire message path (all node pairs) including intermediaries uniformly.

With the "ebxmlresponse=synchronous" HTTP level parameter, how do you expect it to be propagated to all the nodes? Plus with the way HTTP transport bindings are specified, there is no clear distinguishing factor between HTTP level MIME headers and ebXML message level MIME headers. These could easily get into the ebXML message level (MIME) headers and things would be confusing. Special handling would be needed by MSHs.

With the HTTP level "ebxmlresponse=synchronous" kind of approach, this needs to specified for each and every transport and needs to be revisited when a new transport support is added or each time transport level bindings are touched.

With the CPA (DeliveryChannel) based approach, we get to use a uniform and simple way specifying the synchronous response requirement, rather than, one way for HTTP, a different way for some other protocol etc.

The HTTP (communication protocol) binding level approach is not going to scale..

Please see follows below in <PY> also.

Prasad

"Burdett, David" wrote:

 PrasadI 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.

           <PY>The
will know what all they expect to comeback. They will not know if they
all comeback in the same message or not. But that does not matter since,
they will know when they get the message what all is in the message. The
message formats permits the flexibility, very desirable IMHO. Lets keep
it that way. </PY>
> > 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> 
           <PY>If
you mandate sending acks and responses together, it does defeat the purpose
since, we are not using the ack mechanism driven retries effectively to
accomplish reliable messaging on asynchronous connections</PY>

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.

<PY> It is a communication protocol issue but, after analysis turns
out it is better to specify it in the DeliveryChannel level in the CPA
and in the ebXMLHeader than at the communication protocol level parameters.
We get to use a uniform and simple way specifying it rather than, one way
for HTTP, a different way for some other protocol etc.  See my response
in the beginning also. </PY>

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.

<PY> I think CPA requiring the reply "format" or packaging together
acks and response for asynchronous exchanges also, goes against the principle
and flexibility of asynchronous reliable messaging and also the flexibility
offered by the current ebXML message header. Why does one want them all
together? What is the advantage? Only in the synchronous exchanges case
this becomes a factor. The reason I called for parameters as follows is
so that, only the ack can comeback synchronously so that basic mechanism
of reliable messaging is still in place.</PY>

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.
<PY> If the message builder does not ask for acks and sets SyncReplyMode
to return acks synchronously that is an error and results in error or warning 
message as with any other errors in the header.</PY>

</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