Asynchronous Queuing

How can a service and its consumers accommodate isolated failures and avoid unnecessarily locking resources?

Problem When a service capability requires that consumers interact with it synchronously, it can inhibit performance and compromise reliability.
Solution A service can exchange messages with its consumers via an intermediary buffer (such as a queue), allowing service and consumers to process messages independently by remaining temporally decoupled.
Application Queuing technology needs to be incorporated into the surrounding architecture and back-up stores may also be required.	Impacts There may be no acknowledgement of successful message delivery and atomic transactions may not be possible.
Principles Standardized Service Contracts, Service Loose Coupling, Service Statelessness	Architecture Inventory, Composition

Table 6.2 – Profile summary for the Asynchronous Queuing pattern.

Problem

Synchronous communication requires an immediate response to every request and therefore forces two-way data exchange for every service interaction. When services are required to carry out synchronous communication, both service and service consumer must be available and ready to complete the data exchange. This can introduce reliability issues when either the service cannot guarantee its availability to receive the request message or the service consumer cannot guarantee its availability to receive the response to its request.

Because of its sequential nature, synchronous message exchanges can further impose processing overhead, as the service consumer needs to wait until it receives a response from its original request before proceeding to its next action. As shown in Figure 6.x, prolonged responses can introduce latency by temporally locking both consumer and service.

Figure 6.8 –Service A (the service consumer) issues a request message to Service B and because it is part of a synchronous data exchange, Service A is required to wait until Service B processes the request message and then transmits a response. During this waiting period, both service and consumer must be available and continue to use up memory.

Another problem forced synchronous communication can cause is an overload of services required to facilitate a great deal of concurrent access. Because services are expected to process requests as soon as they are received, usage thresholds can be more easily reached, thereby exposing the service to risk of multi-consumer latency or overall failure.

Solution

A queue is introduced as an intermediary buffer that receives request messages and then forwards them on behalf of the service consumers. If the target service is unavailable, the queue acts as a persistent buffer and retains the message. It then periodically attempts retransmission.

Similarly, if there is a response, it can be issued through the same queue that will forward it back to the service consumer when the consumer is available. While either service or consumer is processing message contents, the other can deactivate itself (or move on to other processing) in order to minimize memory consumption.

Figure 6.9 – Service A (the service consumer) sends a message to Service B, which is intercepted and stored by an intermediary queue (1). The queue the forwards the message to Service B (2) and while Service B is processing the message, Service A remains released from memory (3).

Figure 6.10 – After completing its processing, Service B issues a response message back to Service A which is also received and stored by the intermediary queue (4). Service A receives the response (5) and completes processing of the response, all the while Service B is deactivated (6).

Application

In modern ESB platforms, the use of a queue can be completely transparent, meaning that neither consumer nor service may know that it was involved in a data exchange. The queuing framework is supported by intelligent service agents that detect when a queue is required and intercept message transmissions accordingly.

The queue can be configured to process messages in different ways, and is typically set up to poll an unavailable target recipient periodically until it becomes available or until the message transmission is considered to have failed. Queues can further be used to leverage asynchronous message exchange by incorporating topics and message broadcasts to multiple consumers, as per a typical publish-and-subscribe exchange pattern.

Many vendor queues are equipped with a back-up store so that messages in transit are not lost should a system failure occur. Especially when supporting more complex compositions, the Asynchronous Queuing design pattern is commonly applied in conjunction with the Reliable Messaging pattern.

Impacts

The use of intermediary queues allows for creative asynchronous message exchange patterns that can optimize service interaction by eliminating the need for a required response to each request. However, asynchronous message exchanges can also lead to more complex service activities that are difficult to design. It may be challenging to anticipate all of the possible runtime scenarios at design-time, and therefore extra exception handling logic may be necessary.

An asynchronous data exchange that involves a queue can also be more difficult to control and monitor. It may not be possible to wrap asynchronous activities within an atomic transaction because of the time-response constraints usually associated with transactions and their requirements to hold resources in suspension until either commit or rollback instructions are issued.

Despite these issues, an advantage to synchronous messaging is that because a response is always required, it acts as an immediate acknowledgement that the initial request message was successfully delivered and processed. With asynchronous message exchange patterns (such as Òone-wayÓ and ÒsolicitÓ) no response is expected and the message issuer therefore is not notified of successful or failed deliveries. However, most queuing systems allow the monitoring and administration of in-flight message transmissions. Messages in the queue can be furthermore examined and managed during transit which, in larger systems, can greatly simplify administrative control and the isolation of communication faults.

Relationships

Asynchronous Queuing is a design pattern dedicated to accommodating message exchanges and therefore is naturally related to the Service Messaging and Message-Level Security patterns.

Event-driven agents and intercepts form a fundamental part of the queuing framework, which explains the relevance of the Service Agent pattern. Furthermore, Messaging Metadata can play a role in how messages are processed, stored, or routed via these agents (Figure 6.x).

Figure 6.11 – The Asynchronous Queuing patternÕs message-centric focus naturally leads to relationships with other messaging patterns.

Enterprise service bus platforms are fundamentally about decreasing the coupling between different parts of a service-oriented solution, which is why this pattern is a core part of the Enterprise Service Bus compound pattern (Figure 6.x).

Figure 6.12 – Asynchronous Queuing is a design pattern that can be applied independently, but also represents one of the core patterns that comprise the Enterprise Service Bus compound pattern.

As explained in Chapter 9, an optional design pattern associated with the ESB is Reliable Messaging, which is a pattern commonly applied in conjunction with Asynchronous Queuing. Together, these two patterns provide key QoS extensions that make the use of ESB products attractive, especially in support of complex service compositions.

Case Study Example

Case study content is not available on this Web site.