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

Deferred Response

Deferred Response addresses the specific requirements for an application layer acknowledgement of the request message and/or the response is expected to be substantially delayed. Because of the specific requirements to have an application level acknowledgement, which can only be supported by two 2-way messaging, IHE has been evaluating the use of Deferred Response in transactions where its capabilities seem most necessary. The Deferred Response approach is specifically enabled in HL7 V3 and so an option for this has been added to the Cross Gateway Patient Discovery transaction in the XCPD profile. This transaction uses the underlying capabilities of HL7 V3 to enable Deferred Response and describes an option on the actors which declare this capability.

When deferred response is applied to a transaction it differs from the default web service transaction in that it converts the single in-out message exchange pattern into two message exchanges, one message exchange for the request and a separate message exchange for the response. The use of an application acknowledgement message in response to the separate message exchanges is required.

Figure 2.3.1-1 illustrates an in-out web service message exchange.

Figure 2.3.1-1

Figure 2.3.1-2 illustrates a deferred message exchange pattern, where the in-out web service message exchange has been converted into two in-out message exchange patterns, where each service request and service response defines an application acknowledgement for the messages.

Figure 2.3.1-2

For a particular IHE transaction to enable support for Deferred Response it must specify the following extra requirements:

1. Trigger: Define the “trigger” in the request message, i.e. how does the responder know that this message should be processed as Deferred Response rather than synchronous or using WS-Addressing ReplyTo. In may cases this will be a specific SOAP action with “Deferred” in the name. For XCPD the synchronous or WS-Addressing ReplyTo SOAP action is org:v3:PRPA_IN201305UV02:CrossGatewayPatientDiscovery and the Deferred Response SOAP Action is org:v3:PRPA_IN201305UV02:Deferred:CrossGatewayPatientDiscovery. The message content may also contain a trigger, HL7 V3 defines the responsePriorityCode element for this use.
2. Response Service Endpoint: Define the service end point where the Transaction Response will be sent. Since the WS-Addressing ReplyTo element will trigger the wrong behavior another mechanism is needed. HL7 V3 defines the respondTo element for this capability. Other messaging formats may have similar capabilities or one may need to be invented. Another possible approach is to use a service registry with a specific name indicating the Deferred Response reply service end point. This assumes the reply service end point remains stable until the transaction is completed, i.e. no new version is made available which could cause confusion.
3. Message Correlation: Define the mechanism to correlate the response message to the request message. This is likely to be done using the WS-Addressing headers, where the RelatesTo WS-Addressing header contains the Message identifier of the request message. HL7 V3 also specifies queryID element to be used for correlation for query type interactions.
4. Acknowledgement Messages: The use of Deferred Response requires two extra messages be defined, the Transaction Request Acknowledgement and the Transacation Response Acknowledgement. Most times the same message format is used for both. HL7 V3 provides a specific application acknowledgement message (MCCI_IN000002UV01) which should be used.
5. SoapAction Values: For each of the four messages in a Deferred Response a specific SoapAction value will likely be needed.

Application of Deferred Response

As of this writing only XCPD has defined the use of Deferred Response, but it could be applied to several other profile's transactions. When such need is clearly identified further work will be considered.

Status of application of Deferred REsponse

• XCPD - Defined in the XCPD Deferred Response Supplement preparing to be released for public comment in September 2010.
• XCA – makes use of Asynchronous Web Services Exchange and no further pressing need has been identified.
• XDR – makes use of Asynchronous Web Services Exchange and no further pressing need has been identified.
• XDS – is consistent with XCA and XDR