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.