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 (WS-RM), recently republished by IBM®, BEA®, Microsoft®, and Tibco® (see Resources), defines a protocol and a set of mechanisms that help you ensure that messages are delivered reliably between two endpoints and support a broad spectrum of delivery assurance and robust services.
Changes since the March 2004 version
The first notable change to the WS-RM specification since the March 2004 publication is the copyright. The specification authors have released the WS-RM specification under royalty-free (RF) terms. This is good news if you've ever had reservations about implementing the specification despite the authors' publicly-stated assurances that all WS-* specifications would be made available under RF terms.
As to the changes to the technical content of the specification, in truth, the protocol has really not changed all that much. Most of the changes were motivated by feedback from participation and discussion at the Interoperability Workshop (see Resources) and follow-up in subsequent endpoint testing. These changes have led to a much improved specification. Most of the changes relate to the manner in which an RM Sequence is created.
New namespace URI
All of the WS-RM protocol elements have been assigned the following new namespace URI:
Reliable Messaging Model
The Reliable Messaging Model is basically unchanged with one exception: the
CreateSequence handshake exchange and the
message are now required as opposed to optional.
The authors made this change to ensure that the protocol enabled efficient resource reclamation on the part of the RM Destination for terminated RM Sequences. Because the RM Destination assigns the Sequence identifier, once the Sequence has been terminated, the RM Destination can purge all state associated with the terminated Sequence. Further, the RM Destination can safely discard any messages received which contain a Sequence identifier for which it has no knowledge as these messages either belong to a terminated Sequence or belong to an invalid Sequence.
The roles of Application Source and Destination and RM Source and Destination are unchanged since the last revision, as are the supported delivery assurances of At-Most-Once, At-Least-Once, Exactly-Once, and In-Order.
Figure 1. Reliable Messaging Model
As in previous revisions, the essence of the RM protocol is the concept of a Sequence of
messages. The RM Source requests the creation of a Sequence by sending a
CreateSequence message. The RM Destination replies with a
CreateSequenceResponse message which assigns the unique Sequence
Each message that requires reliable delivery assurance includes a Sequence header block.
The Sequence header block contains a unique
Identifier for the Sequence, and
each message in the Sequence is assigned a unique
MessageNumber which starts at
1 and increases monotonically by one for each subsequence message in the Sequence. The RM
Destination acknowledges successful receipt of messages by including a
SequenceAcknowledgement header block, reporting in messages sent back to the
RM Source on the full range of received messages in the Sequence. This allows for the
acknowledgements to be sent unreliably, as the information about a particular message is
carried in each and every
The RM Source identifies the last message in a Sequence by including a
LastMessage child element in the
Sequence header block. At any
time during the life of a Sequence, the RM Source can send a message containing an
AckRequested header block which requests that the RM Destination send a
Once the RM Source has received acknowledgement that all of the messages within a Sequence
have been successfully received, it sends a
terminating the Sequence. As soon as the RM Destination receives the
TerminateSequence message, it can safely discard all of the state related to
Of the protocol elements defined in Section 3 of the specification,
AckRequested header block elements
are basically unchanged with the exception that the namespace of the
element for all three was changed and the optional
Expires element was removed
from Sequence. The Sequence expiration is now established by the
operation (see the section on "Sequence creation" below).
Additionally, a few minor inconsistencies between the schema and the specification prose
were addressed (for example, the previous revision of the specification omitted the
specification of certain extensibility points permitted by the schema).
The following fragments in Listing 1 demonstrate the new format of
Listing 1. Example:
<wsrm:Sequence> <wsrm:Identifier>http://example.com/sequence/564</wsrm:Identifier> <wsrm:MessageNumber>1</wsrm:MessageNumber> </wsrm:Sequence> <wsrm:SequenceAcknowledgement> <wsrm:Identifier>http://example.com/sequence/564</wsrm:Identifier> <wsrm:AcknowledgementRange Upper="3" Lower="1"/> </wsrm:SequenceAcknowledgement> <wsrm:AckRequested> <wsrm:Identifier>http://example.com/sequence/564</wsrm:Identifier> </wsrm:AckRequested>
CreateSequenceResponse response elements
were modified based on feedback from the WS-RM Interoperability Workshop conducted in May
2004. The first of these changes is the addition of an
AcksTo child element in
This element was added so that the endpoint reference to which the RM Destination sends
SequenceAcknowledgement messages could be established at the time of Sequence
creation. The previous revision of the specification had not specified the destination
endpoint that an RM Destination should use to send
messages, and hence implementers had been using a convention of sending
SequenceAcknowledgement messages to the endpoint identified by
wsa:From. While this approach might have worked in some cases, the authors
determined that it would preclude certain use cases in which the endpoint receiving the
SequenceAcknowledgement messages might have a different address than that of
the original message sender (for example, managed endpoint or RM proxy). Further, there was
some discussion as to how to handle the case in which the value of
changed over the course of a Sequence. The authors chose to add the
CreateSequence, since it would avoid the issues regarding the possible
mutability of the
wsa:From element from message to message within a
Expires element, of type
xsd:duration, was added as a
child of the
CreateSequence message. If present, the
element indicates the desired duration of the created Sequence. If absent, or set to zero
(expressed as a value of
PT0S), it implies that the Sequence will never expire.
The authors made this change due to concerns about the using the
Sequence/Expires element. For instance, were its value to change over the
course of a Sequence's lifetime, would the RM Destination be required to honor the change?
Further, because the
Sequence/Expires element was an
it raised concerns regarding the need to synchronize clocks for the RM Source and
Destination endpoints. By changing the type to an
xsd:duration and specifying
the value once in
CreateSequence, these issues were easily resolved.
Finally, in order to support effective composition with the WS-Security family of
CreateSequence element can include a WS-Security
SecurityTokenReference (STR) to identify the security token that the RM
Destination should use to authenticate messages received for the created Sequence. All
messages sent within the Sequence must therefore provide proof that they possess the key
that the STR references, otherwise the RM Destination will discard them.
Listing 2. Example:
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/01/rm"> <S:Header> ... </S:Header> <S:Body> <wsrm:CreateSequence> <wsrm:AcksTo> <wsa:Address>http://example.com/rm/endpoint</wsa:Address> </wsrm:AcksTo> <wsrm:Expires>PT0S</wsrm:Expires> </wsrm:CreateSequence> </S:Body> </S:Envelope>
Bilateral Sequence negotiation
Another change to the
CreateSequence--CreateSequenceResponse exchange is the
addition of support for bilateral Sequence negotiation optimization. In the previous
revision of the WS-RM specification, if two endpoints needed to establish RM Sequences in
each direction, then each endpoint would need to invoke the
operation, thus requiring a total of four messages. The authors added the ability for an
endpoint to optionally offer a corresponding Sequence (in which the roles of RM Source and
Destination are reversed for the two endpoints) by means of the
CreateSequence and a corresponding
Accept child element
CreateSequenceResponse. This optimization allows the endpoints to establish
corresponding RM Sequences with a single message exchange pair.
The example SOAP messages in Listings 3 and 4 below demonstrate the bilateral Sequence negotiation in action. The first message
CreateSequence, requests the creation of
a new Sequence and offers the corresponding Sequence with the
http://example.com/sequence/67. The second message (Listing 4),
CreateSequenceResponse, indicates that the request to create a new Sequence
was accepted. The new Sequence carried an
http://example.org/sequence/42. Additionally, the responding endpoint indicates acceptance
of the offered Sequence by including the
Accept element in the
CreateSequenceResponse message indicating the endpoint to which its
SequenceAcknowledgement messages are to be sent.
Listing 3. Example:
with bilateral Sequence negotiation
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/01/rm"> <S:Header> ... </S:Header> <S:Body> <wsrm:CreateSequence> <wsrm:AcksTo> <wsa:Address>http://example.com/rm/endpoint</wsa:Address> </wsrm:AcksTo> <wsrm:Expires>PT0S</wsrm:Expires> <wsrm:Offer> <wsrm:Identifier>http://example.com/sequence/67</wsrm:Identifier> <wsrm:Expires>PT0S</wsrm:Expires> </wsrm:Offer> </wsrm:CreateSequence> </S:Body> </S:Envelope>
Listing 4. Example
message with bilateral Sequence negotiation
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2004/12/rm"> <S:Header> ... </S:Header> <S:Body> <wsrm:CreateSequenceResponse> <wsrm:Identifier>http://example.org/sequence/42</wsrm:Identifier> <wsrm:Expires>PT0S</wsrm:Expires> <wsrm:Accept> <wsrm:AcksTo> <wsa:Address>http://example.com/rm/endpoint</wsa:Address> </wsrm:AcksTo> </wsrm:Accept> </wsrm:CreateSequenceResponse> </S:Body> </S:Envelope>
TerminateSequence element is basically unchanged with the minor exceptions
of the namespace for the
Identifier element and a few minor inconsistencies
between the schema and the specification prose that were addressed.
Listing 5. Example
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/01/rm"> <S:Header> ... </S:Header> <S:Body> <wsrm:TerminateSequence> <wsrm:Identifier>http://example.com/sequence/67</wsrm:Identifier> </wsrm:TerminateSequence> </S:Body> </S:Envelope>
RM Policy Assertions
The section on RM Policy Assertions in the March 2004 revision of the specification was updated to conform to the recent changes to the WS-Policy family of specifications and relocated to a separate specification: WS-RM Policy Assertion (see Resources).
The revised WS-RM Policy Assertion specification defines a single policy assertion
RMAssertion) and takes the previously-defined RM Policy assertions
AcknowledgementInterval) and places them
as child elements, or properties, of the
RMAssertion, as shown in the example
in Listing 6 below. The semantics of these properties (formerly
assertions) remain unchanged from the previous revision of the WS-RM specification.
Listing 6. Example RM Policy Assertion
<wsp:Policy wsu:Id="MyRMPolicy" > <wsrm:RMAssertion> <wsrm:InactivityTimeout Milliseconds="600000" /> <wsrm:BaseRetransmissionInterval Milliseconds="3000" /> <wsrm:ExponentialBackoff /> <wsrm:AcknowledgementInterval Milliseconds="200" /> </wsrm:RMAssertion> </wsp:Policy>
Additionally, the WS-RM Policy Assertion specification accords the
with Endpoint Policy Subject. WS-PolicyAttachments defines the attachment points for WSDL1.1
for Endpoint Policy Subject as
port. However, because WS-RM is a SOAP protocol, it does not make sense to
RMAssertion to a
wsdl:portType as it could be bound to
a non-SOAP binding. Thus, WS-Policy Attachments that carry Endpoint Policy Subject can
RMAssertion to either of the remaining attachment points defined for
The section on RM Faults is largely unchanged, although it was updated to use a documentation style consistent with that used in the recently republished WS-Addressing specification to define how the fault properties are bound to both SOAP1.1 and SOAP1.2.
The WS-RM specification's appendices were updated to reflect the changes to the specification in the schema and sample message exchanges. Additionally, an abstract WSDL1.1 description of the WS-RM portType operations was included.
The recently updated Web Services Reliable Messaging specification is much improved since its previous publication. The improvements can be largely attributed to implementation experience and the great feedback received during the Interoperability Workshop (see Resources). However, the essential nature of the protocol remains pretty much the same as in the previous revision of the specification.
- Better understand the role of message delivery by reading Reliable Message Delivery in a Web services world (developerWorks, March 2003).
- Get the Web Services Reliable Messaging (WS-ReliableMessaging) specification, which explicitly details how messages can be sent in a reliable fashion between services (developerWorks, February 2005).
- Implement many advanced and experimental Web services protocols using the Emerging Technologies ToolKit (ETTK) from alphaWorks.
- Discover alternative thoughts on how asynchronous Web services can operate in Asynchronous operations and Web services, Part 1 (developerWorks, April 2002), Part 2 (June 2002), and Part 3 (October 2002).
- Find the results of the WS-RM Interoperability Workshop held in May 2004.
- Participate in the development of the WS-* specs. Visit the WS-Spec Workshops Web page for more information.
- Get involved in the developerWorks community by participating in developerWorks blogs.
- Browse for books on these and other technical topics.
- Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
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.