Asynchronous Messaging

Introduction

This page explores different patterns of request-response message interactions. When the processing of the request and formulation of the response is expected to take very little time, for example less than the length of a typical HTTP timeout value, then Synchronous messaging is appropriate. Synchronous messaging carries the request and the response on the same HTTP connection. If the response takes longer than the HTTP timeout value then the connection will be closed by the initiator and the request will be lost. Therefore when using synchronous messaging, there is always a risk that the request will be lost due to unexpected delay on the responding side.

There are a variety of reasons why synchronous messaging is not appropriate. When the processing of the request and formulation of the response is expected to take longer than the length of the HTTP timeout value then synchronous messaging will not work. Other considerations like limitations on the number of connection, memory or CPU usage. In general asynchronous messaging allows the response to be carried within a different HTTP connection than was used for the request and is the approach used for situations which result in a long response delay or other requirements inconsistent with synchronous messaging.

The current IHE ITI approach to asynchronous message exchange, as described in the Asynchronous Web Services Exchange Supplement, makes use of the WS-Addressing specification to handle a delayed response. The approaches discussed here are based on more detailed understanding and feedback from implementers with similar requirements that the Asynchronous Web Services Exchange Supplement was designed to address.

Synchronous and Asynchronous Message Exchange

Overview

When two actors, referred to as Requestor and Provider, need to exchange web services based messages using a request-response message exchange pattern, they can do so synchronously or asynchronously.

With synchronous message exchange, the Requestor sends a request and the transport layer code blocks waiting for a response from the Provider. The Requestor receives the response on the same HTTP connection that the Requestor initially established to send the request. Synchronous exchange is usually easier to implement and requires that the Provider be able to generate a response in a short time, specifically in a time less than the HTTP timeout value.

With asynchronous message exchange, the Requestor is able to release transport specific resources once the request is acknowledged by the responder, knowing that a response will eventually be received. When the Provider completes the processing of the message it sends a response back to the Requestor over a new HTTP connection. Asynchronous message exchange enables support for network infrastructures where avariable or high communication latency is present.

Approaches to Asynchronous Message Exchange

There are several different approaches to implementing asynchronous message exchange, depending on the needs of the application and business environment. Figure 2.2-1 illustrates these patterns.

1. WS-Addressing ReplyTo: The use of the WS-Addressing ReplyTo element supports the ability for the message request initiator to ask that the response be sent through a separate HTTP connection to the service endpoint specified in the ReplyTo element. This capability is required when support for WS-Addressing is declared. This is the approach currently documented in the Asynchronous Web Services Exchange Supplement. This approach hides all details of the asynchronous processing from the application, the correlation and management of the de-coupled request and response is managed within the Web Services Infrastructure layer and the application only needs to be configured properly. On the other hand, if the application needs to know or participate in this de-coupled request/response this mechanism generally does not allow for that.
2. Two 1-way messages: Alternatively, management of the delay of a response can be done by using two 1-way SOAP messages to carry the request and the response. This is called 2 one-way messages because at the SOAP layer it is modeled as independent SOAP requests, one traveling from the initiator to the responder carrying the request message only and there is no SOAP layer response and the second traveling from the responder to the initiator carrying the response message only, also with no SOAP layer response. The correlation of the request and response must be handled by the application layer as the Web Services Infrastructure layer is unaware of this relationship.
3. Two 2-way messages: The use of two 2-way SOAP messages provides additional capabilities that are desirable when an application layer acknowledgement of the request message is required and/or the response is expected to be substantially delayed, for example multiple days or weeks, requiring possible restarts of the responding or initiating system during the message interactions. When the response message is significantly delayed, to the extent that the responding and initiating systems need to maintain persistent status of the message, there is a need for the initiating side to be confident that the responding side has received the message and saved it securely so that it will not be lost. Thus, the primary benefit of two 2-way messages is the ability to carry an application acknowledgement that the request and response messages were completely received and processed by the receiving application.

The above three approaches, along with default synchronous messaging, are presented in Figure 2.2-1, showing the messages traveling to and from the application and Web Services Stack layers.

Figure 2.2-1 - request/response patterns

Enabling IHE transactions for asynchronous messaging

IHE has enabled some of these approaches to asynchronous messaging.

WS-Addressing ReplyTo: IHE has already enabled several transactions for use of the WS-Addressing ReplyTo header as described in the Asynchronous Web Services Exchange Supplement. In fact, any transaction that is based in WS-Addressing can make use of this header without any necessary profiling on IHE’s part.

Two 1-way messages: IHE has not enabled the use of two 1-way messages because at this time it is felt that the overhead of profiling this mechanism is not worth the benefits it provides because it does not carry an application level acknowledgement.

Two 2-way messages: IHE has seen some value in the use of two 2-way messages in cases where significant delay and/or application acknowledgement is desired and has called this “Deferred Response”. The next section describes IHE’s current thinking in the profiling of Deferred Response