JMS SOAP Binding and IRI scheme released from BEA, IBM, Sonic, and Tibco
January 12th, 2007I just ran across this mail from Glen Daniels announcing a public review of a JMS SOAP binding and IRI scheme from BEA, IBM, Sonic and Tibco.
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. While this work has been progressing within the group up until now, we’d like to announce that the specs are now at a point we feel is suitable for public consumption.
A couple interesting notes after glancing through the spec:
- Defines an IRI header so you can address services and use JMS IRIs in the element.
- Defines a content-type header - this will make it easier to support attachments. However, as I understand it, this would be of limited value since JMS providers don’t really provide support for sending very large files.
- It defines a SOAPJMS_soapAction header. “The wsdl11soap11:operation portion of the WSDL specification explicitly disallows use of the
soapActionattribute in non-HTTP bindings. This specification supersedes that requirement, and allows the use ofsoapActionin the<wsdl11soap11:operation> element for SOAP/JMS bindings.” I’m not sure I understand why we would want this, unless they’re trying to support legacy services? - It defines several WSDL elements for configuring your service. For example: <soapjms:connectionFactoryName>sample.jms.ConnectionFactory</soapjms:connectionFactoryName>
It will be interesting to see where this goes! If you have feedback on the specification Glen’s email outlines instructions for submitting it back to the authors.