In WS-Addressing 1.0, how does a SOAP order service deliver its confirmation asynchronously to a client's callback endpoint, and which headers correlate the reply?
answer
- routing moves out of the transport
- an endpoint reference, not a URL
- ReplyTo versus the anonymous default
- request MessageID comes back in RelatesTo
basics
~20 sWS-Addressing puts routing into SOAP headers: the request carries To, Action, a MessageID and a ReplyTo endpoint reference naming the callback; the service later sends a separate message to that address carrying RelatesTo with the request's MessageID.
solid answer
~40 sWS-Addressing 1.0 moves the routing facts a transport used to supply into SOAP header blocks, so they survive any hop or transport. The request carries `wsa:To`, `wsa:Action` (the one header the XML form makes REQUIRED, an IRI naming the message's intent), a `wsa:MessageID`, and a `wsa:ReplyTo` endpoint reference pointing at the client's callback; `wsa:FaultTo` can route faults elsewhere. Because ReplyTo is not the anonymous URI, the reply does not ride back on the request's own HTTP response: the service accepts the request and later sends a new message to the ReplyTo `Address`, copying in any `ReferenceParameters` from that EPR as header blocks and adding `wsa:RelatesTo` with the request's MessageID. Omit ReplyTo and it defaults to the anonymous URI — an ordinary synchronous reply on the back-channel.
code
xml · 24 lines<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:po="http://example.com/purchasing">
<env:Header>
<wsa:To>http://orders.example.com/purchasing</wsa:To>
<wsa:Action>http://example.com/purchasing/SubmitOrder</wsa:Action>
<wsa:MessageID>urn:uuid:6b29fc40-ca47-1067-b31d-00dd010662da</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://buyer.example.org/order-callbacks</wsa:Address>
<wsa:ReferenceParameters>
<po:BasketKey>B-20417</po:BasketKey>
</wsa:ReferenceParameters>
</wsa:ReplyTo>
<wsa:FaultTo>
<wsa:Address>http://buyer.example.org/order-faults</wsa:Address>
</wsa:FaultTo>
</env:Header>
<env:Body>
<po:SubmitOrder>
<po:Sku>KX-200</po:Sku>
<po:Quantity>40</po:Quantity>
</po:SubmitOrder>
</env:Body>
</env:Envelope>go deeper
Remember the core idea: WS-Addressing puts the destination, the operation's Action and the reply address inside SOAP headers, so routing no longer depends on the HTTP connection.
Walk through a request and its asynchronous reply header by header: To, Action, MessageID, ReplyTo, FaultTo, then RelatesTo pointing back. Explain anonymous versus none and how reference parameters become headers.
Show where the standard stops: duplicate MessageIDs are left unconstrained, a reply to a request without a MessageID is a fault, and non-anonymous replies need a reachable callback and an exchange that allows an empty HTTP response.
Weigh what callback endpoints cost an estate: inbound reachability through partners' firewalls, opaque reference parameters to govern, and whether anonymous request-response plus polling is the simpler contract.
## Why SOAP needed addressing headers A SOAP envelope by itself says nothing about where it is going or where an answer should go. Over plain HTTP the transport fills both gaps: the request URL names the receiver and the reply rides back on the same connection. That stops working when a message crosses a queue or an intermediary, changes transport on the way, or when the answer will take hours to produce. **WS-Addressing 1.0** — three W3C Recommendations: Core, SOAP Binding and Metadata — moves those facts into **SOAP header blocks**, so they travel with the message whatever carries it, and gives the other WS-* standards one shared way to say "send it there". ## The message addressing properties | Header | Abstract property | In the XML form | What it carries | |---|---|---|---| | `wsa:To` | [destination] | optional; absent means the anonymous URI | the intended receiver's address | | `wsa:Action` | [action] | **REQUIRED** | an absolute IRI naming the message's intent, used for dispatch | | `wsa:MessageID` | [message id] | optional | an absolute IRI the sender keeps unique | | `wsa:ReplyTo` | [reply endpoint] | optional; absent means an anonymous EPR | where replies go | | `wsa:FaultTo` | [fault endpoint] | optional | where faults go | | `wsa:RelatesTo` | [relationship] | optional, repeatable | the MessageID of a related message, plus a relationship type | | `wsa:From` | [source endpoint] | optional | where the message came from | The Core RECOMMENDS that the `Action` IRI identify an input, output or fault message of a WSDL interface or port type, which is what lets a receiver dispatch on it. ## Endpoint references and reference parameters `ReplyTo`, `FaultTo` and `From` are not bare URLs but **endpoint references (EPRs)**: a REQUIRED `wsa:Address`, optional `wsa:ReferenceParameters` and optional `wsa:Metadata`. Reference parameters are namespace-qualified elements that the EPR's issuer needs in order to interact with that endpoint — a basket key, a tenant, a conversation handle — and they are opaque to everyone else. When a sender addresses a message to an EPR, the SOAP binding copies **each reference parameter in as its own header block** and marks it `wsa:IsReferenceParameter="true"`. The binding warns against using one to inject a header the rest of the stack controls, such as the security header. ## The asynchronous order confirmation, step by step 1. The buyer's system sends `SubmitOrder` with `wsa:To` (the order service), `wsa:Action`, a fresh `wsa:MessageID`, a `wsa:ReplyTo` whose Address is its callback endpoint and whose reference parameter carries its basket key, and a `wsa:FaultTo` pointing at an error-handling endpoint. 2. The response endpoint is not anonymous, so under SOAP 1.2 the reply SHOULD NOT travel as the response of that same request-response exchange; under SOAP 1.1 over HTTP the request SHOULD use a binding that allows an HTTP response with no envelope, and the reply SHOULD go over a separate connection. The order service simply accepts the request (the WS-I Basic Profile notes that HTTP 202 can signal "submitted for processing"). 3. Later the service formulates the reply: destination = the ReplyTo Address, the basket-key header copied in from the EPR, a new `MessageID`, and a `wsa:RelatesTo` holding the request's MessageID. With no `RelationshipType` attribute the relationship defaults to `http://www.w3.org/2005/08/addressing/reply`. 4. The callback dispatches on `wsa:Action` and matches `RelatesTo` to the order it is waiting for. If processing fails, the fault goes to `FaultTo` when the request supplied one, otherwise to `ReplyTo`. ## The special addresses and the edge rules - **Anonymous** (`http://www.w3.org/2005/08/addressing/anonymous`) marks an endpoint with no meaningful address. As a SOAP 1.2 response endpoint it means the reply MUST be the outbound message of the same request-response exchange — the ordinary synchronous back-channel. It is also what an omitted ReplyTo means. - **None** (`http://www.w3.org/2005/08/addressing/none`): messages sent to it MUST be discarded, so a `ReplyTo` or `FaultTo` set to it says "send nothing back". - If a reply or fault is due and the request carried **no MessageID**, the processor MUST fault. - A **duplicate MessageID** is not handled for you: the Core leaves the receiver's behaviour unconstrained, and the SOAP binding only offers an optional `wsa:DuplicateMessageID` fault subsubcode. - Under SOAP 1.1 over HTTP, the `SOAPAction` header MUST be the quoted Action value or the empty `""`; any other value draws an invalid-addressing-header fault. ## What it standardised for the rest of WS-* WS-ReliableMessaging's `AcksTo` and WS-Coordination's `RegistrationService` are both endpoint references, so those standards inherit WS-Addressing's routing. Whether an endpoint requires the headers, and whether it wants anonymous or non-anonymous responses, is advertised with the `wsam:Addressing` policy assertion and its nested `wsam:AnonymousResponses` or `wsam:NonAnonymousResponses`. Correlation identifiers as a general integration pattern are a wider subject; WS-Addressing is one concrete, standardised header set that carries them for SOAP.
- What must a request carry if it expects a WS-Addressing reply, and what happens without it?It must carry `wsa:MessageID`. The Core's reply rules put the request's message id into the reply's `RelatesTo`, and say that if the related message lacks a message id the processor MUST fault. `MessageID` is optional in general — a one-way notification can omit it — but any exchange that will produce a reply or a fault needs one.
- How does a reference parameter in the ReplyTo endpoint reference show up in the eventual reply?Each element inside `wsa:ReferenceParameters` is copied into the reply as its own SOAP header block, unchanged except that it gains `wsa:IsReferenceParameter="true"`. The replying service treats it as opaque; only the EPR's issuer — here the buyer's callback — interprets it, for example to find the basket a confirmation belongs to. Integrity checks over those headers must allow for the added attribute.
- Under SOAP 1.1 over HTTP, how must the SOAPAction header relate to wsa:Action?The WS-Addressing SOAP Binding says the `SOAPAction` value MUST be the [action] IRI in quotation marks or the empty value `""`; the empty form lets message-level security hide the action. Any other value draws an invalid-addressing-header fault, which may be narrowed with the optional `wsa:ActionMismatch` subsubcode.
A business letter that says "reply to our accounts office, quoting reference B-20417": the answer is a new letter, posted later to the address you gave and quoting your reference, not something handed back across the counter while you wait.
saying these in an interview costs you the question
- Every WS-Addressing message must carry wsa:To, while wsa:Action is optional.
- Omitting wsa:ReplyTo means the service sends no reply at all.
- WS-Addressing obliges receivers to detect and reject duplicate MessageIDs.
- wsa:RelatesTo carries the reply's own new MessageID.
- An endpoint reference is just a URL string placed in a header.