Re: Synchronous Messaging Proposal - Some Thoughts

[Henry Lowe <hlowe@omg.org>]

Prasad,

For transport independence reasons, the Header solution is the only 
way to go.

As this is a matter of efficient use of a connection (when you have one),
the rule for the MSH should be "Use it if the underlying transport is 
such that it makes sense, otherwise send the Ack/response in separate 
message".  This way, if you have HTTP, CORBA, DCE or any rpc, you gain 
efficiency; if you have SMTP or similar, you send it in separate message 
unrelated to the original request.

My 2 cents

Best regards,
Henry
---------------------

At 01:01 PM 12/08/2000 -0800, Prasad Yendluri wrote: 
>
> Folks, 
>
> Having bounced this topic off couple of folks, I have realized that there may
> be two main ways of accomplishing this; with arguments to support and against
> both. I am listing below my analysis of both approaches, plus some general
> issues that could be common to both. The  formal proposal  would be based on
> the feedback this ends up generating. 
>
> Model :  The message exchange involves,  the originating  MSH system sending
> an ebXML message ("request message"), that is delivered to the receiving MSH
> system (and processed), after potentially being routed through one or more
> intermediaries, resulting in zero or more acknowledgment messages and / or a
> response ebXML message. At issue is the synchronous communication of the
> response and / or acknowledgment messages (e.g. on the same HTTP connection
> as part of  HTTP response (body)). Please note this model is just to guide
> the following discussion and obviously does not cover all possible scenarios.
>
>
> General: 
>
> The synchronous response should accommodate only an acknowledgment message /
> response message. I don't see value in sending both (e.g. one followed by the
> other in the HTTP body). The acknowledgment could come synchronously and a
> response later asynchronously. 
>
> Should the synchronous nature of expected response or acknowledgment be
> predetermined as part of the CPA (as identified in the TPAId element of the
> ebXML) or should it it possible to request it dynamically on a per message
> basis also (sender driven). I believe the former is desirable with the CPA
> determining everything, as the master control document for the orchestrated
> process occurring between trading partners, capturing what the appropriate
> response style (synch or asynch) is for each step. 
>
> The disadvantage of  having everything cast in the CPA only is, the overload
> of having to the retrieve and inspect the CPA to determine if a synchronous
> response is required (by the ebXML-handler entity on the receiving MSH), 
> prior to handing the message off to the processing logic, so that a transport
> level handshake message (e.g. HTTP 200 OK with no body) isn't sent
> prematurely. Having to do this for all messages to find those that require
> synchronous response (or ack), is indeed an unnecessary overhead. Hence there
> is a need to include the "synchronous response (ack) required" indicator in
> another place outside of the CPA also (on a per message sent basis), with the
> validation against CPA occurring as step in the processing logic rather than
> by the ebXML handler. 
>
> There are two potential choices for this.  (1) As part of the transport /
> communication protocol level bindings or  (2) As new elements in the ebXML
> Header. 
>
> Approach 1:  As part of the transport / communication protocol level
bindings.
>
>
> The idea is that, the requesting MSH would communicate the synchronous
> response / ack requirement as additional headers in the transport level
> bindings. For HTTP, there would be additional HTTP (MIME) headers that are
> optionally present when needed. The receiving HTTP entity (MSH) would use
> these headers as trigger to keep the HTTP connection alive to communicate
> back the Acknowledgment or response message returned by the processing logic,
> instead of sending an immediate HTTP response (e.g. 200 OK with no body),
> that is usually communicated. 
>
> However, this approach requires a specification (by ebXML Messaging Service)
> for each of the transports that can support synchronous response. At this
> point, HTTP is only transport that is known to be able to support this
> capability. Any others that people can suggest? 
>
> Approach 2:  As new elements in the ebXML Header. 
>
> The idea is that, we define new elements in the ebXML Header (probably in the
> Routing Header), that specify if a synchronous response / acknowledgment is
> required. 
>
> The advantage of this approach is, this makes it transport independent and
> needs to be specified in only one place. However, this does require the
> ebXML-handler entity to look into the ebXML header (XML parsing etc.). 
>
> With this approach we will also need to define what it means when the
> elements in the ebXML header indicate a synch response, that is in conflict
> with the CPA etc.  I guess the simple answer is, that would result in an
> error. 
>
> With this approach we will also need to define what it means when the the
> elements in the ebXML header indicate a synch response, but the specific
> transport mechanism being used (e.g. SMTP) does not support it.  I guess the
> simple answer is, it is illegal for the MSH to set the header in the outbound
> message if the transport does not support it (and results in error). 
>   
>
> Back to general issues. 
>
> Either approach 1 or 2 should have enough flexibility to specify whether
> synchronous acknowledgment or response is being requested. 
>
> In addition to the Acknowledgment and response messages error messages would
> also be conveyed synchronously, if the requesting message results in an error
> response. 
>
> Additionally there are messages that do not have a response (one way with Ack
> only). Hence a request  for response message may not be valid always.
> However, whether a request requires a response message or not would be called
> out clearly in the CPA. So sender shall not request a response message or Ack
> unless it is called for in the CPA. 
>
> Synchronous response (or ack) for messages that involve multi-hop or
> intermediary based routing would be tricky. I guess there are no technical
> barriers preventing this other than the potential timeout situation. That is
> the node that sender sent the message needs to keep the connection active
> until the response from the expected node (final recipient's node) gets back.
>
>   
>   
>   
>   
>