ISSUE-67: Need a SOAP 1.2-specific SOAP/JMS transport URL value [SOAP-JMS Binding specification]

ISSUE-67: Need a SOAP 1.2-specific SOAP/JMS transport URL value [SOAP-JMS Binding specification]

http://www.w3.org/2002/ws/soapjms/tracker/issues/67

Raised by: Phil Adams
On product: SOAP-JMS Binding specification

Currently, the SOAP/JMS binding spec defines a single value (http://www.w3.org/2010/soapjms/) to be used as the soap:binding transport URL to indicate that the WSDL binding supports SOAP/JMS (see section 3.3.2 of the binding spec).   According to the spec, this single value should be used for both SOAP 1.1 and SOAP 1.2.   [Also, it seems that it is merely a coincidence that this transport URL value is the same as the soapjms binding namespace value, although they don't need to be the same value.   My point is that the value "http://www.w3.org/2010/soapjms/" seems to be serving double duty - it is the soapjms binding namespace value *and* it is also the soap:binding transport URL value that indicates that SOAP over JMS is being used.]

If one restricts their view to only the WSDL document, then this approach works fine, as the soap version associated with the actual binding itself can be used to determine which version of SOAP is being used.   For example, if the soap:binding element name refers to the SOAP 1.1 namespace, then the binding indicates SOAP 1.1, and if the soap:binding element name refers to the SOAP 1.2 namespace, then the binding indicates SOAP 1.2.

Unfortunately, this approach of using a single value to be shared between SOAP 1.1 and SOAP 1.2 leads to a problem when considering a JAX-WS application that does not use a WSDL document.  In this situation, the author of the endpoint
implementation class might use the BindingType annotation like this:

@WebService
@BindingType("http://www.w3.org/2010/soapjms/")
public class MyEndpointImpl {
}

In this case, the author has only the BindingType annotation at his disposal to indicate the SOAP version and transport that should be used by his endpoint.
For the HTTP case, the JAX-WS specification defines separate values for SOAP 1.1 and SOAP 1.2, thereby allowing the endpoint author to differentiate between
them while specifying the BindingType annotation.   But since the SOAP/JMS binding spec defines only a single value, the author can specify only SOAP 1.1 over JMS in this way.

For this reason, I'm proposing that the SOAP/JMS binding spec define the following transport URL value to be used in the BindingType annotation to indicate SOAP 1.2 over JMS:
http://www.w3.org/2010/soap12jms/

I'm also proposing that the binding spec be clarified to indicate that the use of the value "http://www.w3.org/2010/soapjms/" in the BindingType annotation specifically indicates that SOAP 1.1 over JMS should be used for the endpoint.

This proposal does not affect the value that will be used in the WSDL document as we can continue to use the value "http://www.w3.org/2010/soapjms/" as the soap:binding transport, since the soap:binding element name's namespace can be used to define the SOAP version to be used.

To clarify...  if the endpoint author specifies
   @BindingType("http://www.w3.org/2010/soap12jms/")
on his endpoint implementation class, then this equates to the use of SOAP 1.2 over JMS and the corresponding wsdl binding (generated by the JAX-WS wsgen tool) would look like this:
 <wsdl11:binding name="StockQuoteSoapJMSBinding" type="tns:StockQuotePortType" 
              xmlns:soapjms="http://www.w3.org/2010/soapjms/">
15       <wsdl11soap12:binding style="document" 
              transport="http://www.w3.org/2010/soapjms/"/>
  ....

Similarly, if the endpoint author specifies
   @BindingType("http://www.w3.org/2010/soapjms/")
then the corresponding wsdl binding as generated by wsgen would look like this:
 <wsdl11:binding name="StockQuoteSoapJMSBinding" type="tns:StockQuotePortType" 
              xmlns:soapjms="http://www.w3.org/2010/soapjms/">
15       <wsdl11soap11:binding style="document" 
              transport="http://www.w3.org/2010/soapjms/"/>
  ....


Before I propose specific changes to the SOAP/JMS binding spec, let's first agree on this general approach for solving this issue

Received on Monday, 22 November 2010 22:04:44 UTC