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.
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.
All of the WS-RM protocol elements have been assigned the following new namespace URI:
The Reliable Messaging Model is basically unchanged with one exception: the
CreateSequence handshake exchange and the
TerminateSequence 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
TerminateSequence message, terminating the Sequence. As soon as the RM Destination receives the
TerminateSequence message, it can safely discard all of the state related to that Sequence.
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
Identifier element for all three was changed and the optional
Expires element was removed from Sequence. The Sequence expiration is now established by the
CreateSequence 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 the
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
SequenceAcknowledgement 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
wsa:From changed over the course of a Sequence. The authors chose to add the
AcksTo to the
CreateSequence, since it would avoid the issues regarding the possible mutability of the
wsa:From element from message to message within a Sequence.
Expires element, of type
xsd:duration, was added as a child of the
CreateSequence message. If present, the
Expires 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
xsd:datetime, 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 specifications, the
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>
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
CreateSequence 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
Offer child element in
CreateSequence and a corresponding
Accept child element in
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 (Listing 3),
CreateSequence, requests the creation of a new Sequence and offers the corresponding Sequence with the
Identifier 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
Identifier of 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:
CreateSequencemessage 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
CreateSequenceResponsemessage 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>
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
RMAssertion 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 attach the
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 attach the
RMAssertion to either of the remaining attachment points defined for WSDL1.1, namely
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.
Chris is an Architect with IBM's Emerging e-business Industry Architecture group. He is actively engaged in the development of Web Services and e-business standards. Chris currently represents IBM on the WS-I Basic Profile WG as editor of the Basic Profile 1.1 specification. He also represents IBM on the W3C Web Services Architecture WG and on the OASIS Technical Architecture Board. Prior to joining IBM, Chris served as chair of the Web Services Architecture WG, as Sun representative on the XML Protocols WG, and as a member of the OASIS ebXML Messaging TC. You can contact Chris at email@example.com