Chapter 10. JMS-to-JMS Bridge


Abstract

There are two alternative implementations available for implementing a JMS-to-JMS bridge: the Apache Camel JMS-to-JMS bridge (which can be built using Camel route definitions and the JMS and ActiveMQ components for connectivity); or the native ActiveMQ JMS-to-JMS bridge (which can be used only to route JMS messages). In most cases, Apache Camel is the preferred way to build a messaging bridge.

10.1. Bridge Architecture

Overview

The purpose of a JMS-to-JMS bridge is to enable two different JMS providers that speak a different wire protocol to communicate with each other. A bridge consists essentially of two different client libraries strapped together: one client library facilitates communication with the first JMS provider; and the other client library facilitates communication with the second JMS provider.
The basic architecture is illustrated in Figure 10.1, “Architecture of the JMS-to-JMS Bridge”.

Figure 10.1. Architecture of the JMS-to-JMS Bridge

Wire protocols

JMS defines the interfaces for a messaging service and describes how a client interacts with the messaging service. But JMS does not define the details of a messaging implementation and, in particular, JMS does not specify how to implement an on-the-wire protocol for transmitting messages. Because of this, different JMS providers use different wire protocols.
For Java clients, the ActiveMQ broker normally uses the Openwire/TCP protocol, which is not compatible with a third-party JMS provider. Hence, you cannot simply connect an ActiveMQ broker directly to a third-party JMS provider. It is generally necessary to interpose a JMS-to-JMS bridge between the ActiveMQ broker and the third-party JMS provider.

ActiveMQ client libraries

To enable the JMS-to-JMS bridge to talk to the ActiveMQ broker, it is necessary for the ActiveMQ client libraries to be installed in the bridge. These ActiveMQ client libraries are normally installed by default in JBoss A-MQ, so no action is required to make them available.

Third-party client libraries

To enable the JMS-to-JMS bridge to talk to the third-party JMS provider, it is necessary for the third-party client libraries to be installed in the bridge. These third-party client libraries are not available by default in the JBoss A-MQ container. Third-party JMS providers are licensed separately from JBoss A-MQ. After purchasing the relevant licence from a third-party vendor, you can install the relevant client libraries into the JBoss A-MQ container (see Section 10.3.7, “Sample Bridge Configuration”).

JMS API

The JMS API is layered between the JMS-to-JMS bridge and the client libraries. The JMS API enables the bridge to invoke both of the client libraries (ActiveMQ and third-party) using standard method calls.

Router rules

There are two different approaches to defining router rules, depending on which bridge implementation you choose:
  • Apache Camel JMS-to-JMS bridge—a general-purpose routing engine, which includes support for processing messages using enterprise integration patterns, and over 100 integration components (including FTP, HTTP, and Web services).
  • Native ActiveMQ JMS-to-JMS bridge (deprecated)—special-purpose routing engine, which is capable of routing JMS messages between arbitrary JMS providers. This implementation includes automatic proxy support for ReplyTo messages.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.