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.
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
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
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.
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.
Figure 1. Endpoint managers handle reliable message delivery
The endpoint manager encapsulates the complexity of managing the persistence of
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
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.
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.
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.
- 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.
Dig deeper into SOA and web services on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.