Web Services Reliable Messaging reloaded

Get updated on the new WS-ReliableMessaging specification

Find out what changed in the recently republished version of the Web Services Reliable Messaging (WS-RM) specification since it was last published in March 2004.

Share:

Chris Ferris (chrisfer@us.ibm.com), Senior Technical Staff Member, EMC

Ferris, ChrisChris 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 chrisfer@us.ibm.com



14 February 2005

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 (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:

http://schemas.xmlsoap.org/ws/2005/02/rm

Reliable Messaging Model

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
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 Identifier.

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 SequenceAcknowledgement message.

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 SequenceAcknowledgement.

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.

Protocol elements

Of the protocol elements defined in Section 3 of the specification, Sequence, SequenceAcknowledgement, and 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 Sequence, SequenceAcknowledgement, and AckRequested elements:

Listing 1. Example: Sequence, SequenceAcknowledgement and AckRequested
<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>

Sequence creation

The CreateSequence and 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 CreateSequence.

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.

An optional 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: CreateSequence message
<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 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:CreateSequence message 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 CreateSequenceResponse 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>

Sequence termination

The 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 TerminateSequence message
<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 (InactivityTimeout, BaseRetransmissionInterval, ExponentialBackoff, and 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 portType, binding, and 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 binding and port.

RM Faults

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.

Appendices

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.


Conclusion

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.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=47202
ArticleTitle=Web Services Reliable Messaging reloaded
publish-date=02142005