In a scalable messaging system, brokers can support an increasing number of concurrently connected clients. In a high-performance messaging system, brokers can process messages through the system, from producers to consumers, at a high rate. In a scalable high-performance messaging system, multiple brokers can concurrently process a large volume of messages for a large number of concurrently connected clients.

You can scale up your broker application to provide connectivity for thousands of concurrent client connections and many more destinations.

Besides the obvious components—network and system hardware, transport protocols, message compression—which you can tune to increase application performance, Fuse ESB Enterprise's messaging service provides means for avoiding bottlenecks caused by large messages and for scheduling message dispatches.

As shown in Figure 5, 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[3], 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.

Figure 5. Network of brokers example

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.

For details, see Using Networks of Brokers.

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

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

Fuse ESB Enterprise's messaging service also supports reliable, high-performance load balancing on queues distributed across multiple consumers. If one of the consumers fails, the broker redelivers any unacknowledged messages to another queue consumer. When one consumer is faster than the others, it receives more messages, and when any consumer slows down, other consumers take up the slack. This enables a queue to reliably load balance processing across multiple consumer processes.

Blob messages provide a mechanism for robust transfers of very large files, avoiding the bottlenecks often associated with them. Blobs rely on an external server for data storage. Retrieval of a blob message is atomic. Blob messages are transferred out-of-bounds (outside the broker application) via FTP or HTTP. The blob message does not contain the file. It is only a notification that a blob is available for retrieval. The blob message contains the producer-supplied URL of the blob's location and a helper method for acquiring an InputStream to the actual data.

For details, see ActiveMQ in Action (Snyder, Bosanac, and Davies).

Stream messages also provide a mechanism for efficiently transferring very large files, avoiding the bottlenecks often associated with them. A stream message induces a client to function as a Java IOStream. The broker chunks OutputStream data received from the producer and dispatches each chunk as a JMS message. On the consumer, a corresponding InputStream must reassemble the data chunks.

For details, see ActiveMQ in Action (Snyder, Bosanac, and Davies).

Provides a mechanism for scheduling message dispatch for a later time or at regular intervals.

Using properties in the org.apache.activemq.ScheduledMessage interface, you can schedule when messages are dispatched to a consumer. The broker stores scheduled messages persistently, so they survive broker failure and are dispatched upon broker startup.

For details, see ActiveMQ in Action (Snyder, Bosanac, and Davies).