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.