Standardization Proposal for SOAP/JMS Binding

Posted by Stefan Tilkov on Jan 12, 2007

Sections

Enterprise Architecture

Topics

Web Services ,

SOA

Tags

SOAP ,

IBM ,

BEA ,

Tibco ,

JMS ,

Sonic

In an email to the Apache Axis developers mailing list at apache.org, Sonic's Glen Daniels has announced that IBM, Sonic, TIBCO and BEA have creates a joint proposal for a standardized SOAP/JMS binding. SOAP over JMS is one of the possible choices for Web services-based reliable messaging, relying on a reliable transport instead of a SOAP-level reliability protocol such as WS-Reliable Messaging.

In the email, Glen writes:

As some of you may know, several companies (BEA, IBM, Progress, and TIBCO) have been working on a formal set of specifications for binding SOAP to the Java Message Service API. These specs consist of a) a SOAP binding, and b) a description of the "jms:" IRI scheme which is used for addressing. The specs do NOT cover an interoperable wire-level representation which could bridge different vendors' JMS implementations - though a future version might go there. This version has been designed so that plugging in a different implementation should work seamlessly without recompiling any code; as such we define a BytesMessage encapsulation of SOAP (and MTOM), a "Content-Type" JMS header, and a few other needed parts.

Here's an example of a WSDL file following the proposed specification:

<binding name="StockQuoteSoapJMSBinding" type="tns:StockQuotePortType" xmlns:soapjms="*placeholder*">
   <wsdl11soap11:binding style="document"
        transport="http://www.example.org/2006/06/soap/bindings/JMS/"/>

   <!-- We want this binding to use a particular CF class -->
   <soapjms:connectionFactoryName>
     sample.jms.ConnectionFactory
   </soapjms:connectionFactoryName>
   <!-- Specify PERSISTENT delivery mode -->
   <soapjms:deliveryMode>2</soapjms:deliveryMode>

   <operation name="GetLastTradePrice">
     <wsdl11soap11:operation soapAction="http://example.com/GetLastTradePrice"/>
     <input>
         <wsdl11soap11:body use="literal"/>
     </input>
     <output>
         <wsdl11soap11:body use="literal"/>
      </output>
   </operation>
</binding>

<service name="StockQuoteService">
   <documentation>My first service</documentation>
   <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
       <wsdl11soap11:address location="http://example.com/stockquote"/>
   </port>
   <port name="StockQuotePort_jms" binding="tns:StockQuoteSoapJMSBinding">
       <wsdl11soap11:address location="jms:myQueue?targetService=stockquote"/>
   </port>
</service>

1. Back to top

   Good stuff but I think RM is better

   by Paul Fremantle

   Firstly, JMS not JMI!
   
   But typos aside, I think this is an important and useful piece of work. This will enable WSDL tool authors to approach SOAP/JMS in a consistent manner, and make it easier to use SOAP/JMS.
   
   The comparison between SOAP/JMS and SOAP/WSRM is interesting. Here is my simple summary.
   
   SOAP/JMS strengths are if you have an existing managed, production JMS environment, and you want to expand to be more SOA-focussed, and your tools support SOAP/JMS.
   
   However, the reliance that JMS has on a JNDI directory is a problem. Very few JMS setups and JNDI installations are truly global, or even company-wide. A more usual practise is to have a JNDI specific to an application server cluster. Because the WSDLs defined here are relative to a given JNDI, this makes it hard to define a true cross-department/cross-site SOA using SOAP/JMS. You also end up with a more complex topology than with HTTP because of the number of entities you end up with in a JMS setup (two destinations and a connectionfactory for each req-resp interaction).
   
   WSRM has the disadvantage of being newer, less tried and tested. However, the model is much cleaner. For example you do not need new WSDL tools to use it, because it shares the existing HTTP URLs with no change. This means that its much less of a change to move from SOAP/HTTP to add WSRM. And of course HTTP URLs scale widely and support truly global operations.
   
   All that said, I don't want to detract from the value of this announcement for those who want to move from the messaging world of JMS to the services world of SOAP and WSDL.
   
   Paul
   PS let me announce my bias: I'm co-Chair of the OASIS WS-RX committee standardizing WSRM!

   Reply

2. Back to top

   Re: Good stuff but I think RM is better

   by Stefan Tilkov

   Too bad, a SOAP/JMI binding would have been really innovative :-) Thanks for pointing out the typo.
   
   Is there a specific reason you don't stress the interoperability aspect? Without AMQP, I consider this to be the most important benefit of WSRM.

   Reply

3. Back to top

   Re: Good stuff but it is just a start

   by Boris Lublinsky

   This is very good, but I would rather see messaging binding then JMS. Whether we like it or not SOA is an enterprise wide initiative and modern enterprises are more then Java. There is .Net and there is this mainframe stuff. So standartization for JMS is solving very small part. The whole purpose of web services is interoperability, but JMS binding means what? Interoperability only for java. This will significantly limit adoption.
   Another issue is the one outlined by Paul - JNDI reliance. This also significantly limits enterprise-wide reach
   And finally the interaction style issues. Majority of JMS applications today are asynchronous request/reply - style not quite supported by WS-I. I know, model this as two asynchronous invocations, but this creates tight coupling. The only reasonable options is WS-Addressing, but its adoption is still far from universal. Besides JMS has its own - reply_to.
   So although, this is the great start, there are still a lot of unresoved issues

   Reply

• Older >