W3C has just released W3C Candidate Recommendation SOAP over Java Message Service 1.0 which specifies how SOAP (both SOAP 1.1 and SOAP 1.2) should bind to a messaging system that supports the Java Message Service (JMS). The main purpose of this recommendation:
... is to ensure interoperability between the implementations of different Web services vendors. It should also enable customers to implement their own Web services for part of their infrastructure, and to have this interoperate with vendor provided Web services.
The specification consists of two major parts: SOAP/JMS underlying protocol binding - required by conformant implementations - and WSDL (both 1.1 and 2.0) usage for SOAP/JMS binding - optional for conformant implementations.
SOAP Underlying Transport Binding defines the rules by which SOAP messages are sent and received using the Java Message Service. SOAP/JMS underlying protocol binding covers which JMS features/properties are "visible" at the SOAP format level and which JMS calls have to be made to support them, the message content, including how properties and headers, such as priority, soapAction and targetService, should be handled, and connecting details to the JMS service.
The specification generalizes the connection to a service destination through the soapjms:lookupVariant, which specifies the technique used for looking up the given destination name. The only lookupVariant required by the specification is JNDI-based - jms-variant: jndi. The rest of the connection properties - soapjms:destinationName, soapjms:jndiConnectionFactoryName, soapjms:jndiInitialContextFactory, soapjms:jndiURL and soapjms:jndiContextParameterType - are there to support JNDI-based lookupVariant. In the case of non-JNDI lookup, it is up to the implementer to do the appropriate mapping.
The specification also introduces a set of SOAP parameters, allowing to expose JMS-specific message headers. This includes soapjms:deliveryMode, soapjms:timeToLive, soapjms:priority, soapjms:replyToName and soapjms:topicReplyToName. The last two seem to be completely out of place because they belong to WS-Addressing not the base SOAP definition.
Additional flexibility is provided by defining SOAP specific JMS message properties:
- soapjms:targetService - which can be used by a target implementation to dispatch a service request. This allows to multiplex multiple service accesses over a single queue.
- soapjms:bindingVersion - which is used to denote version of the SOAP binding used.
- soapjms:contentType - which allows to specify MIME type of a primary message payload. It also identifies whether the message payload uses SOAP 1.1, SOAP 1.2, SOAP Messages With Attachments or MTOM as the primary payload.
- soapjms:soapAction - which is used exactly the same way as in SOAP/HTTP.
- soapjms:isFault - which allows to indicate that a message is a fault message.
- soapjms:requestURI - which allows to specify JMS URI of a service. The specification defines this URI as a JMS destination URI with query parameters, representing destination and parameters attributes.
The specification also discusses JMS message types, security concerns and message exchange patterns.
The second section of the specification describes how WSDL can be used to indicate the use and control the operation of JMS binding.
In the case of WSDL 1.1, the specification defines the following extensions:
- The transport attribute of the wsdl11soap11:binding element gets a new URL reflecting a JMS transport.
- Allows use of SOAPAction header, even though it is explicitly disallowed by WSDL specification.
- Defines how to set various properties to control the behavior (connection parameters, runtime setting) of the binding.
- Locates the service using a JMS URI.
And in the case of WSDL 2.0 the extensions are as following:
- The wsoap:protocol attribute of the binding element gets a new URL reflecting a JMS transport.
- Defines how to set various properties to control the behavior (connection parameters, runtime setting) of the binding.
- Locates the service using a JMS URI.
Although SOAP over HTTP allows for interoperable messaging implementations, in many mission-critical systems that need to achieve zero down time and zero data loss, messaging can be a more appropriate underlying transportation support. As a result, many Web Services implementations, in both Java and .NET, provide proprietary support for SOAP over messaging. From this point of view, a specification for SOAP binding to messaging was long overdue.
On another hand, the specification for mapping SOAP to JMS does not seem to provide a solution to the specification’s goal "... ensure interoperability between the implementations of different Web services vendors". First of all, it binds SOAP to JMS, which alone leaves out .NET and/or mainframe implementations. Also, it ties SOAP to JNDI, which can create interoperability issues even within a single enterprise - typically multiple different application server clusters have their own JNDIs. Finally, unless Advanced Message Queuing Protocol (AMQP) is used, there is no on the wire interoperability between messaging implementations from different vendors.