Introduction

The goal of reliable messaging in Web services is to allow applications to send and receive messages simply, reliably, and efficiently even in the face of application, platform, or network failure. The WS-ReliableMessaging specification, recently published by BEA, IBM, Microsoft, and Tibco (see Resources) defines a protocol and a set of mechanisms that allow developers of Web services to ensure that messages are delivered reliably between two endpoints, and supports a broad spectrum of delivery assurance and robustness characteristics.

However, the WS-ReliableMessaging specification alone does not address a number of important considerations that must be taken into account to realize levels of robustness, integrity, and performance that are often required by applications.

This paper discusses some of these considerations and suggests middleware as the most likely and often most suitable implementation strategy for the WS-ReliableMessaging protocol.

Back to top

Implementing the WS-ReliableMessaging protocol

The WS-ReliableMessaging specification defines a Sequence as a shared context for a set of messages that are exchanged between a source and destination application and that share the same delivery assurance requirements. At a minimum, an implementation of the protocol at a source endpoint must be capable of uniquely labeling and resending messages in a Sequence until receipt of all messages has been acknowledged by the destination endpoint. The implementation at the destination endpoint must be capable of tracking received messages in a Sequence and delivering acknowledgments to the source endpoint. The details of a correct implementation of the protocol are specified in the WS-ReliableMessaging specification.

In certain scenarios, it may be quite acceptable that applications participating in a Sequence be incapable of recovering from the failure of either the source or destination application instance.

For instance, the WS-ReliableMessaging protocol might be used to allow reliable delivery of messages over an unreliable transport such as UDP. The application may not require that messages within a Sequence be delivered reliably across the boundary of application or platform failure. It may only require that it be capable of detecting when such a failure has occurred, terminating the Sequence and beginning a new one. In such a scenario, the state of the Sequence and the messages exchanged may be maintained in a volatile, unrecoverable store such as memory rather than on persistent disk.

However, when the requirements of the application are such that the reliable delivery assurances must survive failure of either the sending and/or receiving application, or indeed the platform in which those applications are executing, then each must be capable of reliably persisting messages and the shared state of the Sequence so that they can recover from the point of failure and resume processing the messages in the Sequence. To ensure that the application’s state is consistent with that of the state of the Sequence, the platform in which the Reliable Messaging protocol is implemented will need to be capable of saving and releasing messages as atomic operations, leveraging transactional logic with respect to sending and receiving messages, and participating in coordinated transactions with other resource managers such as the application’s database.

Performing all of these activities efficiently with respect to both latency and throughput can be quite challenging and requires careful consideration by, and is typically beyond the remit of, application developers.

Back to top

The role of middleware

To achieve these performance, robustness, and integrity goals, a proven and widely accepted pattern has been used. This pattern introduces a messaging middleware component at each communication endpoint that we will call an endpoint manager. These endpoint managers can accept message delivery requests from one or more applications, provide for the reliable delivery of the messages to their destination, and deliver received messages to the appropriate applications.

The endpoint manager encapsulates the complexity of managing the persistence of messages and Sequence state. It can participate in resource management activities with other resource managers to enable improved robustness and integrity characteristics while at the same time reducing the complexity of the application code. The endpoint manager can be implemented as a component of the application software itself (for example, as a specialized JAX-RPC handler). Or, it might be implemented as a distributed component (for example, as an IBM WebSphere MQ queue manager), accessed through a remote API such as the Java Message Service APIs (JMS).

Back to top

Programming models

When interacting with their local endpoint managers, applications may choose from a variety of programming models:

• Synchronous Request/Response -- In this case, the application passes its message to its endpoint manager and then waits a specified length of time until the endpoint manager either returns a response from the ultimate recipient application, or a failure result indicating that the message could not be delivered, could not be processed, or that a response could not be received. The application can do nothing else while it is waiting for the endpoint manager to respond.
• Asynchronous One-way -- In this case, the sending application passes its message to its endpoint manager but does not wait for or expect a response. Either the message will be delivered or the endpoint manager will indicate to the application that the message cannot be delivered or could not be processed. For receiving applications, its endpoint manager will inform the application that messages are available for it to process. Such notifications would occur either by the endpoint manager triggering an event or by an application polling its endpoint manager.
• Asynchronous Request/Response -- In this case, the application passes its message to its endpoint manager which replies quickly, indicating that delivery will be attempted. The application then continues its activity until it is ready to check for, or be notified of, a response from its endpoint manager. The endpoint manager indicates that either a response has been received from the destination and is ready to be processed, or that a delivery failure has occurred.

The first model listed is typified by the JAX-RPC APIs for Web services. The second and third programming models are typified by the JMS API, although they are supported by JAX-RPC to a certain degree.

The choice of programming model has very little, if any, impact on the actual processing and reliable delivery of messages between endpoint managers. However, it can have significant impact on the robustness of communication and state management between an application and its associated endpoint manager.

Back to top

WS-ReliableMessaging as middleware interoperability protocol

Over the course of the past decade or so, many enterprises have invested significantly in deployment of message oriented middleware infrastructure as a means of achieving application integration. More recently, some have been leveraging JMS as their application programming model for accessing their message-oriented middleware environments.

However, while JMS provides a standardized API to for message oriented middleware from various vendors, it does not define an interoperability protocol that allows messages sent using one vendor’s JMS service provider to be exchanged reliably with applications that use another’s because each vendor has its own proprietary wire protocol implementation.

We believe that the most important prospect for the WS-ReliableMessaging protocol will be to provide the standard protocol for interoperability between different vendors' message oriented middleware environments. In this scenario, we envisage that WS-ReliableMessaging would be augmented with a set of standardized WSDL portTypes and bindings that would be specific to endpoint managers. These standardized portTypes and bindings would be implemented by vendors of messaging middleware products to enable messages from other middleware environments to be reliably, and interoperably exchanged with their own.

Back to top

Conclusion

We believe that WS-ReliableMessaging represents the next step in bringing Web services to the enterprise. It provides an open protocol allowing enterprise messaging infrastructures to communicate with business partners in a reliable and recoverable manner. The WS-ReliableMessaging protocol will complement message-oriented middleware offerings and we look forward to working together with others as we take the next steps in delivering on the promise of interoperable application integration through Web services technologies.

Resources

• To better understand the role of message delivery, you should read Reliable Message Delivery in a Web services world.
  
  
• The Web Services Reliable Messaging (WS-ReliableMessaging) specification explicitly details how messages can be sent in a reliable fashion between services.
  
  
• The Emerging Technologies ToolKit implements many advanced and experimental Web services protocols.
  
  
• There are alternative thoughts on how asynchronous Web services can operate as described in Asynchronous operations and Web services, Part 1, Part 2, and Part 3.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Implementing the WS-ReliableMessaging protocol
• The role of middleware
• Programming models
• WS-ReliableMessaging as middleware interoperability protocol
• Conclusion
• Resources
• About the authors
• Comments

Dig deeper into SOA and Web services on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers