Bridge Services

Message-Oriented Middleware (MOM) systems use a broad spectrum of technologies and standards to provide messaging services. Often, these technologies and standards are incompatible, leading to MOM systems that cannot communicate with each other in a larger enterprise application context.

To alleviate this inability to communicate, Message Queue incorporates bridge services, which are overseen by the Bridge Service Manager, an application that runs in same JVM as a broker. The Bridge Service Manager supports individual bridge services of various types. Each type of bridge service provides connectivity at the broker level to a MOM technology or standard that would otherwise be unavailable in Message Queue.

At present, Message Queue provides two bridge services, the JMS bridge service and the STOMP bridge service.

JMS Bridge Service

Because the JMS specification does not dictate the communication protocol between brokers and clients, each JMS provider (including Message Queue) has defined and uses its own propriety protocol. This situation has led to non-interoperability across JMS providers.

The JMS bridge service in Message Queue closes this gap by enabling a Message Queue broker to map its destinations to destinations in external JMS providers. This mapping effectively allows the Message Queue broker to communicate with clients of the external JMS provider.

The JMS bridge service supports mapping destinations to external JMS providers that:

• Are JMS 1.1 compliant

• Support JNDI administrative objects

• Use connection factories of type javax.jms.ConnectionFactory or javax.jms.XAConnectionFactory

• Support the XA interfaces as a resource manager for transacted mapping

As an administrative and management convenience, the JMS bridge service supports the creation of any number of JMS bridges in a broker. Each JMS bridge in the broker is identified by a unique name, has its own configuration, and is managed separately from other JMS bridges in the broker.

A JMS bridge consists of two primary components:

• One or more links, each of which maps between a destination in the Message Queue broker and a destination in an external JMS provider or in another Message Queue broker.

• A default Dead Message Queue (DMQ) where undeliverable messages are sent. Additional, special-purpose DMQs can also be specified.

To provide destination mapping, each link consists of:

• A source: the destination from which the JMS bridge receives messages. The source consists of a connection factory for creating connections to a JMS provider and a destination in that provider.

• A target: the destination to which the JMS bridge forwards messages received from the source. The target consists of a connection factory for creating connections to a JMS provider and a destination in that provider. Additionally, a target can optionally specify a message transformer that alters messages from the source before forwarding them to the target destination.

Links are unidirectional. Links that have an external JMS provider or another Message Queue broker as their source are called inbound links, and links that have the Message Queue broker as their source are called outbound links.

To provide flexible, high-performing message transfer between mapped destinations, a JMS bridge offers these features:

• Pooled, shared, and dedicated Connections

• Transactional message transfer

• JMS bridges in enhanced (high availability) broker clusters

• Message transformation during message delivery

• JMSReplyTo header processing

• Dead Message Queue (DMQ) processing

STOMP Bridge Service

The STOMP (Streaming Text Oriented Messaging Protocol) open source project at http://stomp.codehaus.org defines a simple communication protocol that clients written in any language can use to communicate with any messaging provider that supports the STOMP protocol.

Message Queue provides support for the STOMP protocol through the STOMP bridge service. This service enables a Message Queue broker to communicate with STOMP clients.

The STOMP bridge service provides the features needed to fully integrate STOMP messaging into the JMS messaging environment of Message Queue:

• Registration with the Message Queue Port Mapper service so that STOMP clients can discover the service dynamically

• Support for TCP and SSL/TLS connections, including SSL/TLS connections requiring client authentication

• Automatic conversion of STOMP frame messages to and from JMS BytesMessage and TextMessage types

• Extensible message handling and transformation (by defining a custom message transformer)

• Support for the full STOMP protocol, including the STOMP JMS bindings