BT

Standardization Proposal for SOAP/JMS Binding

by Stefan Tilkov on Jan 12, 2007 |
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>

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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!

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.

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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT