RE: Synchronous Messaging Proposal - Some Thoughts

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Prasad,

    I would be favourable to embed the "synchrounous nature of expected response or acknowledgement" into the CPA because, in my understanding, this is more a "behavioral" quality than a "technical" flavour.

In my way of looking at this, the sync/async is logically closer to a choreographic issue, where the "management" of the choreography should be able to:

1. understand how to respond
2. grant that the application properly does its duty
3. especially in case of async, grant a common semantic of the persistency between the MSH and the Application.

So, I would see this implemented in the BusinessServiceInterface.

 

Best regards

/Stefano

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
Sent: Friday, December 08, 2000 10:02 PM
To: Ebxml-Transport (E-mail)
Subject: Synchronous Messaging Proposal - Some Thoughts

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.