skip to content

What does the W3C SOAP over JMS binding define in place of what SOAP over HTTP gets from HTTP itself, and what does it leave out?

level: seniorimportance: nice to knowfreq 6%

answer

  1. no headers, no status line
  2. SOAPJMS_ message properties
  3. a jms: URI for the destination
  4. reply queue and correlation ID
  5. same JMS provider on both ends

basics

~20 s

SOAP over JMS carries what HTTP headers and status provide as SOAPJMS_* message properties, names destinations with a jms: URI, and correlates replies via JMSReplyTo and JMSCorrelationID. It leaves out cross-provider interoperation and any wire format.

solid answer

~40 s

JMS has no request line, `Content-Type` or status code, so the W3C SOAP over JMS 1.0 Recommendation (2012) moves each into a **JMS message property**: `SOAPJMS_requestURI` and `SOAPJMS_bindingVersion` (fixed `1.0`) are required, `SOAPJMS_contentType` is required and carries the same media type as over HTTP, `SOAPJMS_soapAction` and `SOAPJMS_targetService` are optional, and `SOAPJMS_isFault` set to `true` marks a fault, replacing the HTTP status. Endpoints are named with the JMS URI scheme of RFC 6167, such as `jms:jndi:...?targetService=...`. The body is a `BytesMessage` or `TextMessage`, and a receiver MUST accept both. A request-response exchange sends the reply to `JMSReplyTo`, matched by `JMSCorrelationID`. The binding explicitly does not make two different JMS providers interoperate and defines no wire format, so both sides need the same messaging product.

go deeper

for a junior

Recall that SOAP can travel over message queues as well as HTTP, and that the W3C SOAP over JMS binding standardises how.

for a middle

Explain which JMS properties replace HTTP's headers and status, how the jms: URI names a destination, and how replies are correlated.

for a senior

Show the operational consequences: shared JMS provider on both ends, reply-queue handling, BytesMessage versus TextMessage memory cost, and topic caveats.

for a principal

Weigh a queue-based SOAP binding against HTTP for a partner integration: availability decoupling against a shared broker dependency and harder cross-organisation operation.

## Why SOAP needs a JMS binding SOAP is transport-neutral, but every transport has to answer the same questions the HTTP binding answers: where does the message go, what media type is it, what is the action, how does a reply find its way back, and how does a receiver tell a fault from a normal response. **JMS** (the Java Message Service API) has queues, topics, message headers and message properties, but nothing equivalent to an HTTP request line, `Content-Type` or status code. Without a shared mapping, each Web services stack is free to invent its own, and a client built on one stack cannot call a service built on another even over the same queue; the specification's stated purpose is interoperability between different Web services vendors' implementations. The W3C **SOAP over Java Message Service 1.0** Recommendation (February 2012) defines that mapping for both SOAP 1.1 and SOAP 1.2. ## What HTTP provided, and what replaces it | Concern | SOAP over HTTP | SOAP over JMS | |---|---|---| | Endpoint address | HTTP URL | JMS URI (RFC 6167), e.g. `jms:jndi:...` | | Media type | `Content-Type` header | `SOAPJMS_contentType` property, required | | Action | `SOAPAction` header or `action` parameter | `SOAPJMS_soapAction` property, optional | | Service selection | path of the URL | `SOAPJMS_targetService` property, optional | | Fault signal | HTTP status | `SOAPJMS_isFault` property set to `true` | | Reply routing | the same connection | `JMSReplyTo` destination | | Correlation | the same connection | `JMSCorrelationID` | The other required properties are `SOAPJMS_requestURI`, derived from the JMS URI with `targetService` and `replyToName` removed, and `SOAPJMS_bindingVersion`, fixed at `1.0`. Missing required properties produce faults with subcodes such as `missingContentType` and `missingRequestURI`. With SOAP 1.2, if `SOAPJMS_contentType` carries an `action` parameter that differs from `SOAPJMS_soapAction`, the receiver MUST fault with `mismatchedSoapAction`. ## The JMS URI RFC 6167 defines the `jms:` scheme. Its variant, such as `jndi`, says how to look up the destination, and the `jndi` variant MUST be supported. Query parameters carry settings such as `targetService`, `replyToName`, `deliveryMode`, `timeToLive`, `priority` and JNDI lookup details. A WSDL 1.1 binding names the transport with a URI under the `http://www.w3.org/2010/soapjms/` namespace and can carry the same properties. ## Message body and exchange patterns - **Body type:** the SOAP payload is a `BytesMessage` or a `TextMessage`. The sender may choose either; the receiver MUST support both. The specification warns that receiving a `TextMessage` can more than double the memory needed, and advises care when attachments travel that way. - **Patterns:** a conforming binding MUST support both **request-response** and **one-way**. - **Request-response:** the requester MUST set `JMSReplyTo`, either from `replyToName` or a queue the implementation chooses, possibly a temporary one. The response is correlated if its `JMSCorrelationID` equals the request's `JMSCorrelationID`, or, when the request set none, the request's `JMSMessageID`. - **Topics:** allowed as destinations, but the specification gives no guidance on how the patterns behave with an unknown number of subscribers, and advises caution. ## What the binding leaves out The specification is explicit about its limits: 1. It does **not** provide interoperation between two different JMS providers. Two SOAP stacks can interoperate, but client and service must share one JMS implementation. 2. It does **not** define a wire format for SOAP/JMS messages; the bytes on the broker's protocol are the provider's business. 3. It does **not** define how services are presented to programmers, for instance how a one-way method looks in code. 4. It does not mandate how credentials for directory lookup or the broker are obtained, and it recommends against putting user IDs or passwords in the URI. ## Why teams chose it Queues give what HTTP does not: the service can be down while requests wait, load spreads across competing consumers, and delivery can be persistent. The trade is a shared broker product, reply-queue management and correlation handled by the binding instead of the connection. Addressing headers and reliable-messaging protocols can add further guarantees, but those are separate specifications. A short checklist when a SOAP-over-JMS call goes unanswered: - Is `SOAPJMS_requestURI` present, and does `SOAPJMS_bindingVersion` read `1.0`? - Does `SOAPJMS_contentType` match the envelope's SOAP version, and with SOAP 1.2 does any `action` parameter agree with `SOAPJMS_soapAction`? - Was `JMSReplyTo` set, and is the requester listening on that destination? - Does the reply's `JMSCorrelationID` match what the requester is waiting for? - Are client and service actually connected to the same JMS provider?

  • How does a SOAP-over-JMS requester know which message on its reply queue answers its request?
    By `JMSCorrelationID`. If the request set one, the response carries the same value; if it did not, the response's `JMSCorrelationID` equals the request's `JMSMessageID`. The requester also MUST set `JMSReplyTo` so the responder knows where to send the reply.
  • Without HTTP status codes, how does a SOAP-over-JMS receiver recognise a fault?
    The sender of a fault MUST set the boolean JMS property `SOAPJMS_isFault` to true. If the property is absent or present with false, the receiver's isFault value is false, so a responder that forgets it hides the fault from any logic that reads only the property.

saying these in an interview costs you the question

  • SOAP over JMS lets a client on one JMS provider call a service on another.
  • SOAP over JMS defines the bytes on the wire between client and broker.
  • A SOAP-over-JMS receiver may accept only TextMessage bodies.
  • Faults over JMS are signalled with an HTTP-style status property.
  • SOAP over JMS supports only one-way messaging.