O'Reilly - Java Message Service

Java Message Service
Figure 7.2. Using CLIENT_ACKNOWLEDGE, a JMS consumer can still ensure reliability
when bridging to other protocols
It is important to know that end-to-end quality of service may not be guaranteed when
using bridges to other protocols. In Figure 7.2, the HTTP send may succeed, yet the
acknowledge( ) may fail.
7.5 Bridging to Other Messaging Systems
JMS does not provide for interoperability between 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. One solution to this problem 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 7.3. This is one of the reasons
why the message itself is required to be interoperable between vendors, as explained in
Chapter 3. The message need not be recreated as it is passed along to the other JMS client.
Figure 7.3. Connecting from one JMS provider to another is a simple pass-through process
that is a client of both
End-to-end quality of service should be a consideration when building or using such a
bridge. The robustness of JMS vendor-provided bridges may vary in this respect.
Since JMS is a standard, and it is easy enough to remove one vendor's implementation and
swap in another one, you may ask "Why would anyone want to do this?" The main reason
today is to bridge an IBM MQSeries legacy application with an application that is based on
a more modern JMS provider.
120