skip to content

Over WS-ReliableMessaging 1.2, an RM Source receives a SequenceAcknowledgement with ranges 1-4 and 6-9 — what does that prove, and what does it not?

level: seniorimportance: should knowfreq 8%

answer

  1. accepted is not delivered
  2. ranges list only what was accepted
  3. a gap means retransmit
  4. InOrder holds later messages back
  5. durability is the implementation's call

basics

~20 s

It proves the RM Destination accepted messages 1-4 and 6-9 and has not accepted 5, so the RM Source should retransmit 5. It does not prove the application received or processed anything: acknowledgement is between the RM endpoints.

solid answer

~50 s

WS-ReliableMessaging is a protocol between an **RM Source** and an **RM Destination**. Each `wsrm:Sequence` header carries the sequence `Identifier` and a `MessageNumber` starting at 1 and rising by exactly 1, and a range-based acknowledgement MUST list, in non-overlapping `AcknowledgementRange` elements, every number the destination has accepted and exclude every number it has not. So ranges 1-4 and 6-9 say message 5 is missing; the source SHOULD retransmit it while the sequence is open, and can send `AckRequested` to prompt a fresh acknowledgement. What the acknowledgement does not say: that the Application Destination got the message — Accept and Deliver are separate steps — or that the destination's state survives a crash, which is left to implementations. If `InOrder` applies with `AtLeastOnce` or `ExactlyOnce`, messages 6-9 MUST NOT be delivered until 5 arrives or the sequence is closed.

code

xml · 14 lines
xml
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsa="http://www.w3.org/2005/08/addressing"
    xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702">
  <env:Header>
    <wsa:To>http://buyer.example.org/rm-acks</wsa:To>
    <wsa:Action>http://docs.oasis-open.org/ws-rx/wsrm/200702/SequenceAcknowledgement</wsa:Action>
    <wsrm:SequenceAcknowledgement>
      <wsrm:Identifier>http://orders.example.com/rm/seq-7f3a</wsrm:Identifier>
      <wsrm:AcknowledgementRange Lower="1" Upper="4"/>
      <wsrm:AcknowledgementRange Lower="6" Upper="9"/>
    </wsrm:SequenceAcknowledgement>
  </env:Header>
  <env:Body/>
</env:Envelope>

go deeper

for a junior

Recall that WS-ReliableMessaging numbers messages within a sequence and the receiver acknowledges which numbers it has, so the sender knows what to resend.

for a middle

Explain CreateSequence, the Sequence header with Identifier and MessageNumber, AcknowledgementRange, AckRequested, and the four delivery assurances, naming who must retry and who must filter duplicates.

for a senior

Read an acknowledgement precisely, separate Accept from Deliver, and say what a crash does to an in-memory implementation; then explain why the order still needs an application-level confirmation.

for a principal

Decide where reliability belongs in a partner integration: a WS-RM layer both stacks must implement compatibly, a broker, or idempotent application retries, and what each one leaves unproven.

## Four parties, not two WS-ReliableMessaging 1.2 (an OASIS Standard) separates the applications from the reliability machinery that sits between them: | Term | Meaning in the specification | |---|---| | **Application Source** | the endpoint that *Sends* a message | | **RM Source** | *Transmits* it, one or more times, to the RM Destination | | **RM Destination** | *Receives* it, **Accepts** it — makes it eligible for delivery and acknowledgement — and *Acknowledges* it | | **Application Destination** | the endpoint the RM Destination *Delivers* it to | Acknowledgement happens between the two RM endpoints. Delivery to the application is a separate, later step. The specification places no restriction on how either RM endpoint is built: robustness can range from in-memory state scoped to one process lifetime to replicated durable storage, and the wire protocol is the same either way. ## Creating and numbering a sequence 1. The RM Source sends `wsrm:CreateSequence` in the SOAP Body, with a REQUIRED `AcksTo` endpoint reference saying where acknowledgements go, an optional `Expires` duration, and optionally an `Offer` of a sequence for the reverse direction. 2. The RM Destination answers with `CreateSequenceResponse`, carrying the `Identifier` of the sequence it created, or with a `wsrm:CreateSequenceRefused` fault. 3. Every reliable message carries one `wsrm:Sequence` header holding that `Identifier` and a `MessageNumber` that starts at 1 and rises by exactly 1, in the order the Application Source sent the messages. The RM Source MUST set `mustUnderstand` to true on it. 4. The sequence ends with `TerminateSequence`, optionally preceded by `CloseSequence` — after which no new messages are accepted and the final acknowledgement carries `Final`; both SHOULD state `LastMsgNumber`. ## Reading the acknowledgement A `wsrm:SequenceAcknowledgement` header names the sequence and then holds either non-overlapping `AcknowledgementRange` elements (attributes `Lower` and `Upper`), or `None` if nothing has been accepted, or one or more `Nack` elements naming unreceived messages. The invariant is strict: the ranges MUST include every message number the RM Destination has accepted and MUST exclude every one it has not. So ranges 1-4 and 6-9 say exactly one thing about the gap: message 5 has not been accepted. - While the sequence is neither closed nor terminated, the RM Source SHOULD retransmit unacknowledged messages — here, message 5. - The RM Source MAY send `AckRequested` at any time, alone or piggy-backed on another message; the RM Destination MUST then send an acknowledgement to `AcksTo` for a known sequence, or an `UnknownSequence` fault. - The RM Destination MAY piggy-back a `SequenceAcknowledgement` on any message it sends toward the RM Source. - Retransmission timing is not specified; the specification warns that over-aggressive retransmission floods transports and intermediaries and encourages adaptive back-off. ## Delivery assurances are policy, not wire format | Assurance | RM Source | RM Destination | |---|---|---| | `AtLeastOnce` | SHOULD retry until acknowledged | SHOULD retry delivery; no duplicate filtering required | | `AtMostOnce` | MAY retry, not required to | MUST filter out duplicates | | `ExactlyOnce` | SHOULD retry until acknowledged | SHOULD retry delivery and MUST NOT deliver a duplicate | | `InOrder` | numbers MUST match the send order | MUST deliver in message-number order | `InOrder` combines with one of the other three. With `AtLeastOnce` or `ExactlyOnce`, a gap means the RM Destination MUST NOT deliver later messages from that sequence until the missing one arrives or the sequence is closed — so 6-9 wait for 5. The assurances are advertised through the WS-RM Policy specification's `wsrmp:DeliveryAssurance`, nested inside `wsrmp:RMAssertion`, and that specification states plainly that the assurance does not affect the messages transmitted on the wire. ## What the acknowledgement does not prove - **That the application processed anything.** Accepted is not Delivered; the order still needs its own application-level confirmation. - **That the message survives a crash.** Durability is an implementation's choice, invisible to the protocol. - **That duplicates were removed**, unless `AtMostOnce` or `ExactlyOnce` is in force. - **That the ranges are final.** Only an acknowledgement carrying `Final` promises its ranges will not change. General delivery semantics — why exactly-once processing ultimately rests on idempotent handling — are a wider distributed-systems subject; WS-ReliableMessaging is one standardised layer underneath them, between two RM endpoints.

  • What should an RM Source do when acknowledgements stop arriving?
    Send `AckRequested` naming the sequence — alone in an envelope with an empty Body, or piggy-backed on the next message. For a known sequence the RM Destination MUST answer with a `SequenceAcknowledgement` sent to the `AcksTo` endpoint, otherwise with an `UnknownSequence` fault. Meanwhile the source keeps retransmitting unacknowledged messages while the sequence is open, with timing left to the implementation and adaptive back-off encouraged.
  • Why must an RM Destination refuse an Offer whose Endpoint is the anonymous URI?
    An offered sequence carries messages from the RM Destination back to the RM Source. With an anonymous endpoint the destination has no address to connect to, so it cannot retransmit unacknowledged messages on its own initiative — it could only answer on a back-channel when the other side happens to send something. Unless an extension solves this, the specification says the RM Destination MUST NOT accept such an offer.

saying these in an interview costs you the question

  • A WS-RM acknowledgement means the receiving application has processed the message.
  • Ranges 1-4 and 6-9 mean message 5 was rejected as invalid.
  • WS-ReliableMessaging guarantees messages survive a crash of either endpoint.
  • AtLeastOnce also removes duplicates before delivery to the application.
  • The delivery assurance travels in each message's Sequence header.