Reliable Messaging

How can a service communicate reliably with consumers when implemented in an unreliable environment?

Problem Message delivery cannot be guaranteed in service data exchanges carried out using unreliable messaging protocols, which can compromise composition stability.
Solution An intermediate reliability mechanism is introduced into the environment ensuring that the success or failure of each message delivery is acknowledged.
Application Middleware and service agents are deployed to keep track of message deliveries and manage the issuance of positive and negative acknowledgements. Rules can be further added to customize behavior during failure conditions.	Impacts Using a reliability framework adds processing overhead that can affect service activity performance. It also increases composition design complexity and may not be compatible with atomic transaction requirements.
Principles Service Composability	Architecture Inventory, Composition

Table 6.20 – Profile summary for the Reliable Messaging pattern.

Problem

When services are designed to communicate via messages, there is a natural loss of quality of service due to the stateless nature of messaging protocols, such as HTTP. Unlike with binary communication protocols where a persistent connection is maintained until the data transmission between a sender and receiver is completed, with message exchanges the runtime platform may not be able to provide feedback to the sender as to whether or not a message was successfully delivered.

The probability of failure is exacerbated as the service count (and the number of corresponding network links) grows with service compositions increasing in size and complexity. 

Figure 6.87 – During the course of a regular message exchange, there are no guarantees. Various runtime conditions may cause the message delivery to fail.

Solution

The inventory architecture is equipped with a reliability framework that tracks and temporarily persists message transmissions, and issues positive and negative acknowledgements to communicate successful and failed transmissions to message senders.

Application

An middle tier providing the reliability framework is incorporated into the inventory architecture, comprised of a series of runtime service agents that participate in the messaging chain between senders and receivers.

This framework can store messages in transit via a persistent repository (which is often memory-based), as a back-up mechanism for when message transmissions fail. This central storage also eases the management and administration of service-oriented solutions because it allows administrators to track the status of messages and trace the causes behind unresolved delivery problems.

The reliability agents further manage the confirmation of successful and failed message deliveries via positive (ACK) and negative (NACK) acknowledgement notifications, as demonstrated in Figure 6.x. Messages may be transmitted and acknowledged individually or they may be bundled into message sequences that are acknowledged in groups (and may also have sequence-related delivery rules).

Figure 6.88 – A common example of the mechanics behind a reliable messaging framework. The consumer sends a request message (1) and the message is then copied into persistent storage by intermediary service agents (2). An acknowledgement notification is sent back to the consumer (3) and the intermediary agents then deliver the message to the service. The service responds with an acknowledgement notification, allowing the intermediary agents to remove the message from persistent memory.

Impacts

Reliable Messaging introduces a layer of processing that includes runtime message capture, persistence, tracking, and acknowledgement notification issuance. All of these features add moving parts to an inventory architecture that demand additional performance requirements and increase the complexity of service-oriented solutions proportional to the size of service compositions.

Furthermore, due to the temporary storage of messages, the incorporation of positive and negative acknowledgement notifications, and the use of various delivery rules (including those based on group message delivery via sequences), it may not be possible to wrap services using reliability features into atomic transactions, as per the Cross-Service Transaction pattern.

Relationships

Applying this pattern directly affects messaging-related patterns in that it changes how messages are transmitted and delivered. The quality of Service Messaging is improved and Messaging Metadata is commonly utilized to manage and track messages via reliability agents. These agents comprise the bulk of a reliability framework and can be considered specialized implementations of the Service Agent pattern. Considerations arise from the application of Canonical Resources can help ensure that an inventory architecture standardizes on a single reliability framework.

Figure 6.89 – The messaging-centric focus of this pattern makes it naturally affect other messaging-related patterns.

Because of the importance of guaranteeing message delivery and improving the overall QoS of base messaging frameworks, the runtime functionality established by applying Reliable Messaging pattern is common to many ESB platforms (Figure 6.x).

Figure 6.90 – The Reliable Messaging pattern can be applied by itself, but is also a pattern that can be realized via the Enterprise Service Bus compound pattern (as explained in Chapter 9).

Case Study Example

Case study content is not available on this Web site.