BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or get video-only pass to recordings.
QCon London

Discover new ideas and insights from senior practitioners driving change in software. Attend in-person.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Standardization Proposal for SOAP/JMS Binding

Standardization Proposal for SOAP/JMS Binding

Bookmarks

Jan 12, 2007 1 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more
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>

Rate this Article

Adoption
Style

This content is in the Architecture topic

Related Topics:

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.

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

Community comments

  • Good stuff but I think RM is better

    by Paul Fremantle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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!

    Back to top
  • Re: Good stuff but I think RM is better

    by Stefan Tilkov,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

    Back to top
  • Re: Good stuff but it is just a start

    by Boris Lublinsky,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

    Back to top

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

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

BT