Some applications require the same message to be sent to more than one destination, possibly of different types. For example, an application may send messages to a queue for distributed load balancing. That same application, however, may also need the messages to be published to several monitoring applications. Another example is an application that publishes messages to several topics. All messages however, must also be sent to a database for backup and for data mining. A queue is used to collect all messages and send them to the database.
An application can process messages so that they are sent multiple times to the required destinations. However, such processing requires significant coding effort in the application. EMS provides a server-based solution to this problem. You can create bridges between destinations so that messages sent to one destination are also delivered to all bridged destinations.
Bridges are created between one destination and one or more other destinations of the same or of different types. That is, you can create a bridge from a topic to a queue or from a queue to a topic. You can also create a bridge between one destination and multiple destinations. For example, you can create a bridge from topic a.bto queue q.b and topic a.c.
When specifying a bridge, you can specify a particular destination name, or you can use wildcards. For example, if you specify a bridge on topic foo.* to queuefoo.queue, messages delivered to any topic matching foo.* are sent to foo.queue.
When multiple bridges exist, using wildcards to specify a destination name may result in a message being delivered twice. For example, if the queues Q.1 and Q.> are both bridged to QX.1, the server will deliver two copies of sent messages to QX.1.
The following three figures illustrate example bridging scenarios.