# Destination Bridges

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.b` to 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 queue `foo.queue`, messages delivered to any topic matching `foo.*` are sent to `foo.queue`.

Note: Because global topics are routed between servers and global queues are limited to their neighbors, in most cases the best practice is to send messages to a topic and then bridge the topic to a 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 figures illustrate example bridging scenarios.

Bridging a topic to a queue:

Bridging a topic to multiple destinations:

Bridging a queue to multiple destinations:

Note: When a bridge exists between two queues, the message is delivered to both queues. The queues operate independently; if the message is retrieved from one queue, that has no effect on the status of the message in the second queue.

Bridges are not transitive. That is, messages sent to a destination with a bridge are only delivered to the specified bridged destinations and are not delivered across multiple bridges. For example, topic `A.B` has a bridge to queue `Q.B`. Queue `Q.B` has a bridge to topic `B.C`. Messages delivered to `A.B` are also delivered to `Q.B`, but not to `B.C`.

The bridge copies the source message to the target destination, which assigns the copied message a new message identifier. Note that additional storage may be required, depending on the target destination store parameters.

Copyright © Cloud Software Group, Inc. All rights reserved.