Product Introduction

Version 7.1

December 2012
Trademark Disclaimer
Third Party Acknowledgements

Updated: 07 Jan 2014

Table of Contents

1. What is Fuse MQ Enterprise?
2. Introduction to JMS
Standard JMS Features
JMS Message Basics
JMS Development
3. Fuse MQ Enterprise Features
Centralized Configuration, Deployment, and Management
Fault Tolerance
Scalability and High Performance
Simplified Administration
4. The Major Widgets Use Case
5. Getting More Information
Red Hat Documentation
Other Resources

List of Figures

2.1. Anatomy of a JMS message
2.2. Messaging sequence
3.1. A Fabric
3.2. Network of Brokers Example
4.1. Major Widgets integration solution

List of Tables

2.1. Java message types

List of Examples

2.1. Getting a Connection
2.2. Creating a Session
2.3. Creating a Queue
2.4. Creating a Message Producer
2.5. Creating a Consumer
2.6. Creating a Text Message
2.7. Sending a Message
2.8. Receiving a Message

Persistent messaging ensures no message is lost due to a system failure, a broker failure, or an inactive consumer. This is so because the broker always stores persistent messages in its stable message store before dispatching them to their intended destination. This guarantee comes at a cost to performance. Persistent messages are sent synchronously—producers block until broker confirms receipt and storage of each message. Writes to disk, typical for a message store, are slow compared to network transmissions.

Because non-persistent messages are sent asynchronously and are not written to disk by the broker, they are significantly faster than persistent messages. But non-persistent messages can be lost when the system or broker fails or when a consumer becomes inactive before the broker dispatches the messages to their destination.

The default behavior of JMS brokers and consumers is to use persistent messaging. Fuse MQ Enterprise defaults to storing persistent messages in a lightweight, file-based message store. The default is intended to provide persistence at the lowest cost. If you need to use a more robust message store or want to forgo persistence in favor of performance, you can change the defaults.

There are several ways to alter the default persistence behavior when using Fuse MQ Enterprise:

  • disable persistence from a message producer by changing its default delivery mode to non-persistent

  • disable persistence for a specific message by changing the messages delivery mode to non-persistent

  • change the message store the broker uses to persist messages

    Fuse MQ Enterprise has a number of persistence adapters to connect to different message stores.

  • deactivate the broker's persistence mechanism


    Deactivating the broker's persistence mechanism means that no messages will be persisted even if their delivery mode is set to persistent. This step should only be used for testing or situations where persistence will never be needed.

For details, see Configuring Broker Persistence.

As shown in Figure 2.1, a JMS message consists of three components:

  • headers

  • properties

  • body

A JMS application typically consist of these basic interfaces and classes:

Connection factory

Connection factories are administered objects that clients use to create connections to a message broker. You can optimize some messaging characteristics by enabling, disabling, or otherwise modifying the values of certain connection factory properties.


Connections are the objects clients use to specify a transport protocol and credentials for sustained interaction with a broker.


Sessions are created by a client on a connection established with a broker. They define whether its messages will be transacted and the acknowledgement mode when they are not. Clients can create multiple sessions on a single connection.


Destinations are created by a client on a per-session basis. They are client-side representations of the queue or topic to which messages are sent. The message broker maintains its own representations of the destinations as well.


Producers are client-side objects that create and send messages to a broker. They are instances the MessageProducer interface and are created on a per-session basis.

The MessageProducer interface provides methods not only for sending messages, but also for setting various message headers, including JMSDeliveryMode which controls message persistence, JMSPriority which controls message priority, and JMSExpiration which controls a message's lifespan.


Consumers are client-side objects that process messages retrieved from a broker. They are instances of the MessageConsumer interface and are created on a per-session basis.

The MessageConsumer interface can consume messages synchronously by using one of the MessageConsumer.receive() methods, or asynchronously by registering a MessageListener with the MessageConsumer.setMessageListener() method. With a MessageListener registered on a destination, messages arriving at the destination invoke the consumer's MessageListener.onMessage() method, freeing the consumer from having to repeatedly poll the destination for messages.


Messages are the backbone of a messaging system. They are objects that contain not only the data payload, but also the required header and optional properties needed to transfer them from one client application to another. See JMS Message Basics.

Figure 2.2 shows the typical sequence of events involved in sending or receiving messages in a Fuse MQ Enterprise client application.

The following procedure shows how to implement the sequence of events shown in Figure 2.2:

  1. Get a connection factory.

    The process for getting a connection factory depends on your environment. It is typical to use JNDI to obtain the connection factory. Fuse MQ Enterprise allows you to instantiate connection factories directly in consumer code or obtain connection factories using Spring in addition to using JNDI.

  2. Create a connection from the connection factory as shown in Example 2.1.

  3. Start the connection using the connection's start() method.

  4. Create a session from the connection.

  5. Create a destination from the session.

    Example 2.3 shows code for createing a queue called foo.

  6. Create objects for producing and consuming messages.

    1. Create a producer as shown in Example 2.4.

    2. Create a consumer as shown in Example 2.5.

  7. Create a message from the session object.

    Example 2.6 shows code for creating a text message.

  8. Send and receive messages.

    1. Send messages from the producer as shown in Example 2.7.

    2. Receive messages from the consumer.

      Example 2.8 shows code for synchronously receiving a text message.

  9. Close all JMS resources.

Fuse MQ Enterprise provides a variety network protocols that enable producers and consumers to communicate with a broker:

  • OpenWire—The default wire protocol used to serialize data for transmission over the network connection. It uses a binary encoding format. OpenWire supports native JMS client applications and provides client libraries for C, C++, and .NET.

  • Extensive Messaging and Presence Protocol (XMPP)—Enables instant messaging clients to communicate with the broker.

  • Hypertext Transfer Protocol/Hypertext Transfer Protocol over SSL (HTTP/S)—Favored protocol for dealing with a firewall inserted between the broker and its clients.

  • IP multicast—Provides one-to-many communications over an IP network. It enables brokers to discover other brokers in setting up a network of brokers, and clients to discover and establish connections with brokers.

  • New I/O API (NIO)—Provides better scalability than TCP for client connections to the broker.

  • Secure Sockets Layer (SSL)—Provides secure communications between clients and the broker.

  • Streaming Text Oriented Messaging Protocol (STOMP)—A platform-neutral protocol that supports clients written in scripting languages (Perl, PHP, Python, and Ruby) in addition to clients written in Java, .NET, C, and C++.

  • Transmission Control Protocol (TCP)—For most use cases, this is the default network protocol.

  • User Datagram Protocol (UDP)—Also deals with a firewall inserted between the broker and its clients. However, UDP guarantees neither packet delivery nor packet order.

  • Virtual Machine (VM)—Provides connection between an embedded broker and its clients.

For details, see the Connectivity Guide.

Fuse MQ Enterprise allows you deploy a group of brokers into a fabric. All of the brokers in a fabric are managed by a distributed Fabric Ensemble that stores runtime and configuration information for all of the brokers in the fabric. Using this information the ensemble enables you to manage large deployments by:

  • automating the configuration of failover groups, networks of brokers, and master/slave groups

    The ensemble knows the connection details for all of the brokers in the fabric and uses that information to configure brokers into different configurations. Because the information is updated in real time, the broker configurations are always correct.

  • automating client connection and failover configuration

    When brokers are configured into a fabric, messaging clients can use a special discovery protocol that discovers broker connection details from the fabric's ensemble. The fabric discovery connection will also automatically failover to other brokers in a failover cluster without needing to know any details about what brokers are deployed.

  • centralizing configuration information

    All of the configuration for each container in the fabric, including details about which bundles are deployed, are stored in the ensemble. Any of the configurations can be edited from a remote location and directly applied to any container in the fabric.

  • simplifying the enforcement of common configuration policies

    The ensemble organizes configuration information into profiles that can inherit from each other. This makes it easy to enforce common policies about how brokers need to be configured using base profiles.

  • centralizing management and monitoring functionality

    Using Fuse Management Console, Fuse IDE, or the Fuse MQ Enterprise command console you can update configuration profiles, deploy new containers, shutdown containers, and get runtime metrics for any of the containers in the fabric

As shown in Figure 3.2, the brokers in a network of brokers are connected together by network connectors, which define the broker-to-broker links that form the basis of the network. Through network connectors, a network of brokers keeps track of all active consumers, receiving notifications whenever a consumer connects to or disconnects from the network. Using the information provided through client registration, brokers can determine where and how to route messages to any consumer in a network of brokers.

The brokers use a store-and-forward delivery method to move messages between them. A broker first stores messages locally before passing them on to another broker in its network. This scheme supports the distribution of queues and topics across a network of brokers.

A network of brokers can be employed in a variety of network topologies, such as hub-and-spoke, daisy chain, or mesh.

For details, see Using Networks of Brokers.


You can incorporate multiple master/slave topologies in networks of brokers to ensure a fault tolerant messaging system.

For details, see Master/Slave in Fault Tolerant Messaging.

Figure 4.1 shows how the Major Widgets integration might be implemented using Fuse MQ Enterprise. Specifically, it shows that:

The first piece in the order processing system consists of a pair of brokers deployed in a shared database master/slave cluster. Each broker in the cluster is configured to host the content-based route used to receive and distribute the orders. The router uses persistent messages when distributing messages. Each broker also maintains five message queues: one for each store in the network and one for bad orders. The combination of a master/slave cluster and persistent messages provide a high-degree of reliability to the system as explained in Fault tolerance.

The second piece of the order processing system is distributed across the four stores in the Major Widgets chain. Each of the stores (A-D) run a back-end order processing application that listens for messages on the store's order queue using a Fuse MQ Enterprise client. This application consumes order messages from the store's order queue, checks the order against the store's inventory, and determines how to process the order. The back-end processing logic can be implemented using any one of the Fuse MQ Enterprise client APIs or a dynamic router with a Fuse MQ Enterprise entry point.

Figure 4.1 shows that the Major Widgets integration plan uses a master/slave cluster as a fault tolerant mechanism to protect against loss of orders due to broker failure.

For this to provide maximum resiliency, each broker would be running on its own server. The shared database would be hosted on a third server or on a dedicated SAN. Separating the brokers and the shared database means that a single hardware failure cannot bring down the order processing system. At least two pieces of hardware would need to fail before the system stopped functioning. Major Widgets could add more brokers to the cluster to provide even more resiliency.

When the brokers initially start up, they determine who is master by attempting to grab a lock on the shared database. The first one to get the lock becomes master and begins listening for messages. The other broker(s) in the cluster become slaves and wait until the lock becomes available. If the master fails, the slave will be able to grab the lock on the shared database and will then start listening for messages. For details on how master/slave clusters work see Master/Slave in Fault Tolerant Messaging.

For this to work smoothly, the back-end order processing clients must be configured to switch to the new master so that they can continue to receive messages. Fuse MQ Enterprise makes this easy by providing a failover transport. The failover transport allows you to provide a Fuse MQ Enterprise client with a list of broker URIs. The client will attempt to connect to the first URI in the list. If it cannot, or if the connection subsequently fails, the client will automatically move to the next URI. For details on using the failover transport see Failover Protocol in Fault Tolerant Messaging.

In addition to the master/slave cluster, the plan uses persistent messaging to ensure that messages are not lost before the back-end processing system can consume them. Every message is stored in the cluster's shared persistence store until it is consumed by a back-end ordering system. If there is a broker failure, or even a cluster failure, all messages that have not been processed will be redelivered when the system recovers.

The books listed here provide information about JMS messaging and the basic information needed to develop messaging applications with Fuse MQ Enterprise.

  • Installation Guide

    Provides detailed instructions for installing the Fuse MQ Enterprise software on Windows, Linux, Unix, and OS X platforms, using the binary distributions or building from source code. It also lays out the prerequisites needed to ensure a successful installation.

  • Migrating Guide

    Describes all changes made to the Fuse MQ Enterprise software and provides instructions for integrating the changes into existing applications.

  • Connectivity Guide

    Describes each of the supported transport options and connectivity protocols in detail and includes code examples.

  • Configuring Broker Persistence

    Describes the basic concepts of message persistence and provides detailed information on the supported message stores: KahaDB and JDBC database with/without journaling. It also describes how to use message cursors to improve the scalability of the message store.

  • Using Networks of Brokers

    Describes basic network of brokers concepts and topologies, network connectors, discovery protocols for dynamically discovering and reconnecting to brokers in a network, and balancing consumer and producer loads.

  • Fault Tolerant Messaging

    Describes how to implement fault tolerance using a master/slave cluster.

  • Fuse IDE Documentation

    Describes how to use Fuse IDE to develop and test messaging applications.

  • Tuning Guide

    Describes techniques for fine tuning your broker's performance.

    You must register at before you can use this document.

  • Security Guide

    Describes how to secure the communications between your client applications and the broker. It also describes how to secure access to the broker's administrative interfaces.

    You must register at before you can use this document.

  • API Reference

    Links to the Fuse MQ Enterprise 7.1 Javadoc.

  • Fuse MQ Enterprise XML Schema Reference

    Links to Fuse MQ Enterprise 7.1 XML Schema Reference, where, for each namespace, all available components are listed.

The books listed here provide information and instructions to support system administrator functions.

  • Installation Guide

    Provides detailed instructions for installing the Fuse MQ Enterprise software on Windows, Linux, Unix, and OS X platforms, using the binary distributions or building from source code. It also lays out the prerequisites needed to ensure a successful installation.

  • Migrating Guide

    Describes all of the latest changes made to the Fuse MQ Enterprise software and, where necessary, provides instructions for integrating the changes into existing systems.

  • Managing and Monitoring a Broker

    Provides detailed instructions for managing a Fuse MQ Enterprise deployment.

  • Security Guide

    Describes how to secure transport protocols and Java clients, how to set up JAAS authentication on broker-to-broker configurations, and how to secure Fuse MQ Enterprise JMX connectors.

  • Fuse Management Console Documentation

    Describes how to use Fuse Management Console to monitor distributed Fuse MQ Enterprise deployments.

  • Fuse HQ Documentation

    Describes how to use Fuse HQ to monitor and manage Fuse MQ Enterprise.

The books and reference materials listed here provide detailed information and instructions for designing, building, and deploying enterprise integration solutions and for using the tools that make it easier to do so. The books and reference materials in this list were authored by leading experts in this domain.


active consumers, Network of brokers
ActiveMQ.Agent topic, Command Agent
Fuse HQ, Fuse HQ
Fuse IDE, Fuse IDE
Fuse Management Console, Fuse Management Console
third-party tools, Other 3rd party administrative tools
Web console, Web Console
advisory messages, Advisory messages
authentication interceptors, Interceptor plug-ins


blob (binary large objects) messages, Blob messages
advisory topics, Advisory messages
described, Broker
feature set, Features


central timestamp interceptor, Interceptor plug-ins
client-side APIs, Client-side APIs
clients, Messaging clients
active consumers, Network of brokers
broadcasting messages through a topic to a pool of queue subscribers, Virtual destinations
consumer, Basic application components
multiple destinations, concurrently sending the same message to, Composite destinations
producer, Basic application components
publishers, Publish/subscribe messaging
receivers, Point-to-point messaging
senders, Point-to-point messaging
subscribers, Publish/subscribe messaging
command agent, Command Agent
composite destinations, Composite destinations
profiles, Profiles
versions, Profiles
connection, Basic application components
creating, Development steps
connection factory, Basic application components
connectivity options, Connectivity options
consumer, Basic application components
creating, Development steps
MessageConsumer interface, Basic application components
receiving messages, Basic application components, Development steps
consumer clusters, Consumer clusters
container options, Container options


dead letter queue, Dead letter queue
Destination, Basic application components
creating, Development steps
durable subscribers, Durable subscribers


enhanced logging interceptor, Interceptor plug-ins
ensemble, Fabric Ensemble
exclusive consumers, Exclusive consumers


agent, Fabric Agents
ensemble, Fabric Ensemble
profiles, Profiles
versions, Profiles
Fabric Agent, Fabric Agents
Fabric Ensemble, Fabric Ensemble
failover protocol, Failover protocol
fault tolerance, Fault Tolerance, Major Widgets integration solution, Fault tolerance
master/slave broker topologies, Master/Slave topologies
network of brokers, Network of brokers
Fuse HQ, Fuse HQ
Fuse IDE, Fuse IDE
Fuse Management Console, Fuse Management Console


horizontal scaling, Overview


interceptor plug-ins, Interceptor plug-ins


JMS application components, Basic application components
JMS message headers, Message headers
JMSDeliveryMode, Persistent and non-persistent messages
JMSReplyTo, Request/reply messaging
JMSXGroupID, Message groups, Stream messages
send(), Message headers
JMS message properties, Message properties
JMS-defined, Message properties
JMSCorrelationID, Request/reply messaging
user-defined, Message properties
vendor-specific, Message properties
JMS messages, Messages, Overview, Basic application components
anatomy, Message anatomy
body, Message body
creating, Development steps
headers, Message headers
properties, Message properties
receiving, Development steps
sending, Development steps
types, Message body
JMS transactions, JMS transactions


master/slave broker topologies, Master/Slave topologies
network of brokers, Network of brokers
shared file system, Master/Slave topologies
shared JDBC database, Master/Slave topologies
message groups, Message groups
JMSXGroupID header, Stream messages
stream messages, Stream messages
message redelivery, Message redelivery
MessageConsumer, Basic application components
MessageProducer, Basic application components
messages, Messages
messaging clients (see clients)
messaging domains
point-to-point, Point-to-point messaging
publish/subscribe (Pub/Sub), Publish/subscribe messaging


network connectors, Network of brokers
network of brokers, Network of brokers
non-persistent messages, Persistent and non-persistent messages
non-persistent messaging, Persistent and non-persistent messages


persistent messages, Persistent and non-persistent messages
persistent messaging, Persistent and non-persistent messages
point-to-point messaging, Point-to-point messaging
destination, Advisory messages
redelivery, Message redelivery
producer, Basic application components
creating, Development steps
default destination, Basic application components
described, Point-to-point messaging
MessageProducer interface, Basic application components
sending messages, Basic application components, Development steps
setting JMS headers and properties, Basic application components
publish/subscribe (Pub/Sub) messaging, Publish/subscribe messaging


queue-based messaging, Point-to-point messaging


reliability, Overview
reliable messaging system, Overview
request/reply messaging, Request/reply messaging
JMSCorrelationID message property, Request/reply messaging
JMSReplyTo message header, Request/reply messaging
retroactive consumers, Retroactive consumers


scheduled message delivery, Scheduled message delivery
Session, Basic application components
creating, Development steps
statistics interceptor, Interceptor plug-ins
store and forward delivery mode, Network of brokers
stream messages, Stream messages
vs blob messages, Blob messages


topic-based messaging, Publish/subscribe messaging
JMS, JMS transactions
XA, XA transactions


vertical scaling, Overview
virtual destinations, Virtual destinations
visualization interceptors, Interceptor plug-ins


Web console, Web Console
composite destinations, Composite destinations


XA transactions, XA transactions