JMS: An infrastructure for XML-based business-to-business communication

Learn how the Java Messaging Service can provide a flexible, reliable, and secure means of exchanging XML-based transactions

1 2 3 Page 3
Page 3 of 3

XML message type -- where is it?

You may have noticed by now that there is no XML message type specified in JMS. Given our enthusiasm for XML transported by JMS, you may ask, "What gives?" In practice, XML messages can be placed in TextMessage messages, and enjoy all the identified benefits of a messaging infrastructure for their transport -- resilience, security, increased system design flexibility, and so on. A step toward deeper XML support in Java messaging would be to extend the TextMessage object in order to provide additional convenience for XML handling.

Bear in mind, though, that the JMS specification will need to be extended through the Java Community Process (JCP) if XML content itself is to play a role in a messaging system's behavior (without client application involvement, that is). As specified by JavaSoft, the JMS message system itself does not provide programmatic access to the message body. Rather, any content that should be exposed to the subscriber for message selection or routing must be enclosed in the header fields and message properties. Content-based routing can be synthesized within client applications by extracting appropriate XML properties from the body of the message and placing them within the properties of the message header prior to sending it.

The future

Java messaging currently provides an excellent mechanism for the exchange of XML transactions. We have seen that the transport of XML can greatly benefit from awareness of -- and support for -- the loosely coupled, dynamic environments inherent in large-scale deployments. JMS addresses the needs of such environments beautifully, offering an elegant programming model for a wide variety of tightly and loosely coupled scenarios.

Potential enhancements to the JMS specification can deepen the relationship between these two technologies. For example, current JMS implementations provide subject-based routing, without any awareness of the XML being transported. Without this awareness, the XML content of a message cannot directly affect its routing, or any other aspect of messaging-system behavior. This is a strong motivation for the adoption of a full-fledged XML message type -- and value-added semantics around it -- within the JMS specification itself. This is indeed something that should be addressed by the JCP.

In addition, the JMS specification -- as it stands -- does not address wire protocols and non-JMS message interchange (though it is important to note that JMS implementations are already interchangeable at the API level). JMS solution providers are actively working on technology that will bridge their JMS messaging systems and other messaging and nonmessaging infrastructures. With JMS, it will be possible to obtain all the benefits of messaging within a large deployment domain, yet integrate with other legacy messaging systems and XML interchange protocols. Stay tuned -- and don't drop any XML transactions in the meantime!

Gordon Van Huizen is a seasoned software developer with 19 years of industry experience. His background fuses object technology with realtime, operating system, and network software internals experience. He has designed and developed solutions for Website generation, distributed electronic forms systems, network-based object licensing, and realtime data merging and imaging. As principal product manager for Progress Software, Mr. Van Huizen is responsible for the definition of the company's next-generation application server strategies.

Learn more about this topic

  • Other JavaWorld articles related to JMS

1 2 3 Page 3
Page 3 of 3