Bridging to Other Messaging Systems
JMS does not provide for interoperability between JMS providers and other non-JMS providers. A JMS client from one vendor cannot talk directly to a JMS server from another vendor. Interoperability between vendors was not a goal of the specification’s creators, since the architecture of messaging vendors can be so vastly different. Since messaging is designed to provide an abstraction layer between a message producer and a message consumer, we ought to be able to send a message with a Java client using JMS and receive that message in a receiver written in C++ or C#. This would require either a JMS provider that contained a message bridge or a separate message bridge to convert the JMS message to a message that could be understood by another messaging system (e.g., MSMQ).
IBM’s WebSphere MQ and the open source ActiveMQ JMS provider are two such messaging vendors that provide the ability to use both JMS and the vendor’s native API, allowing interoperability between languages and platforms. Alternatively, there are open source and commercial messaging bridges available that will perform this function as well. Another solution is to build a connector process that is a client of both providers. Its sole purpose is to act as a pass-through mechanism between the two providers, as shown in Figure 10-3. This is one of the reasons why the message itself is required to be interoperable between vendors. The message need not be recreated as it is passed along ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access