WS-ReliableMessaging: Guaranteed SOAP Delivery

WS-ReliableMessaging (WS-RM) is a standardized specification defined by OASIS that ensures reliable message exchange between distributed SOAP-based web services, even in the presence of software, system, or network failures. This article explains the fundamentals of WS-ReliableMessaging, the delivery assurances it provides, and the step-by-step mechanism it uses—such as sequence management, message acknowledgment, and retransmission—to guarantee that SOAP XML payloads reach their intended destinations intact and in the correct order.

What is WS-ReliableMessaging?

WS-ReliableMessaging is an extension to the core SOAP protocol within the WS-* stack. Standard transport protocols like HTTP are inherently stateless and do not guarantee delivery at the application layer; if an intermediate proxy drops a connection or a server restarts mid-transaction, messages can be lost or duplicated.

WS-RM solves this problem by moving reliability logic from the transport layer into the SOAP messaging layer. By embedding reliability metadata directly into the <soap:Header> of XML payloads, WS-RM ensures end-to-end delivery between the original sender and the ultimate receiver, regardless of intermediate transport hops, connections, or protocol transitions.

Key Architectural Roles

WS-ReliableMessaging defines four primary roles involved in a transaction:

1. Application Source (AS): The client or application that sends the original business message.
2. Reliable Messaging Source (RMS): The infrastructure component on the sender side that manages sequences, transmits SOAP messages with reliability headers, and handles retransmissions.
3. Reliable Messaging Destination (RMD): The infrastructure component on the receiver side that receives messages, verifies sequence IDs, sends acknowledgments, and filters duplicates.
4. Application Destination (AD): The target service or endpoint that processes the business payload.

How WS-ReliableMessaging Ensures Guaranteed Delivery

The protocol follows a structured lifecycle to track, acknowledge, and finalize message delivery:

1. Sequence Creation

Before application messages are sent, the RMS initiates a session with the RMD by sending a <CreateSequence> request in a SOAP envelope. The RMD replies with a <CreateSequenceResponse>, which assigns a globally unique Sequence Identifier (URI) to the communication channel.

2. Message Identification and Transmission

When the Application Source submits a message, the RMS assigns it an incremental message number within the established sequence (e.g., Message 1, Message 2). The RMS attaches this information to the SOAP header:

<wsrm:Sequence xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702">
    <wsrm:Identifier>urn:uuid:550e8400-e29b-41d4-a716-446655440000</wsrm:Identifier>
    <wsrm:MessageNumber>1</wsrm:MessageNumber>
</wsrm:Sequence>

The RMS stores a copy of this message in a persistent outbound buffer and transmits the SOAP payload over the network.

3. Acknowledgment (ACK/NACK)

Upon receiving the message, the RMD inspects the <wsrm:Sequence> header and determines if the message is valid and within sequence. It then responds with a <SequenceAcknowledgement> header, either piggybacked on an outgoing SOAP message or sent as a standalone control message:

<wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702">
    <wsrm:Identifier>urn:uuid:550e8400-e29b-41d4-a716-446655440000</wsrm:Identifier>
    <wsrm:AcknowledgementRange Lower="1" Upper="1"/>
</wsrm:SequenceAcknowledgement>

4. Retransmission and Duplicate Elimination

If the RMS does not receive an acknowledgment within a specified timeout, it automatically retransmits the message using the exact same Sequence Identifier and Message Number.

If a network glitch caused the original message to arrive late after a retransmission was sent, the RMD detects the duplicate MessageNumber, discards the duplicate payload to prevent double processing, and resends the acknowledgment to the RMS. Once the RMS receives confirmation, it removes the message from its buffer.

5. Sequence Termination

When all messages in the batch have been successfully transmitted and acknowledged, the RMS sends a <CloseSequence> or <TerminateSequence> request. The RMD confirms sequence closure, freeing up allocated resources and persistent buffers on both ends.

Delivery Assurance Levels

WS-ReliableMessaging allows systems to configure specific delivery guarantees via WS-Policy:

• At-Least-Once: Guarantees every message is delivered to the destination at least once. If duplicates occur, they are delivered to the application.
• At-Most-Once: Guarantees messages are delivered without duplication, though messages may be lost in severe failure scenarios.
• Exactly-Once: Combines At-Least-Once and At-Most-Once. Guarantees every message reaches the destination exactly one time without loss or duplication.
• In-Order: Guarantees that messages are delivered to the destination application in the exact numeric sequence they were sent by the source, holding back later messages if an earlier one is delayed or being retransmitted.