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.
Community comments
a bit little, very late
by Gerald Loeffler,
Return fault versus rollback for re-delivery
by Paul Done ,
a bit little, very late
by Gerald Loeffler,
Your message is awaiting moderation. Thank you for participating in the discussion.
i find this spec in a few ways out-of-sync with reality (and some of these issues have also been mentioned in the original posting):
- it essentially (only) standardises the interface between a webservice stack and a JMS provider
- making the WSDL binding optional is a weird decision, as this is the most visible impact of the spec: a way to write portable WSDLs that define SOAP/JMS endpoints
- it is ridiculously late: everyone needing a reliable SOAP transport has long used the numerous vendor-specific implementations of SOAP/JMS
- and then again it's the upstream specs that are even later: there is yet no standard way in Java (i.e. via JAX-WS) to expose or consume SOAP/JMS webservices.
cheers,
gerald
www.gerald-loeffler.net
Return fault versus rollback for re-delivery
by Paul Done ,
Your message is awaiting moderation. Thank you for participating in the discussion.
For request/response pattern, I can't see anything in this spec which talks about how Service implementations indicate that if a problem occurs in the processing a request, whether they want the message de-queue operation to still be acknowledged and a fault sent to the response queue or whether they actually don't want the de-queue to NOT be ack'd and have the request message put back on the request queue for subsequent re-delivery (eg. because of a temporary downstream system glitch).
I guess this is related to Gerald's point in that the spec doesn't address the programming model for implementing SOAP-JMS providers and consumers?
Paul Done