Standardization Proposal for SOAP/JMS Binding
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*">
<!-- We want this binding to use a particular CF class -->
<!-- Specify PERSISTENT delivery mode -->
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<port name="StockQuotePort_jms" binding="tns:StockQuoteSoapJMSBinding">
Good stuff but I think RM is better
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.
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
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
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
Ben Linders May 28, 2015