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 - image
QCon San Francisco

Level up your software skills by uncovering the emerging trends you should focus on. Register now.

 QCon London - image
QCon London

Discover emerging trends, insights, and real-world best practices in software development & tech leadership. Join now.

 QCon London - image
InfoQ Dev Summit Boston

Learn how senior software developers are solving the challenges you face. Register now with early bird tickets.

 The Software Architects Newsletter - image
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

Feed your curiosity. Help 550k+ global
senior developers
each month stay ahead.Get in touch
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 Enterprise Architecture topic

Related Topics:
BT