> 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.

> | 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.

> The following three figures illustrate example bridging scenarios.
> Figure 11 Bridging a topic to a queue
> Figure 12 Bridging a topic to multiple destinations
> Figure 13 Bridging a queue to multiple destinations

> | 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.
> Creating a Bridge
> Bridges are configured in the bridges.conf configuration file. You specify a bridge using the following syntax:
> [destinationType:destinationName]
> destinationType=destinationToBridgeTo selector="messageSelector"
> where destinationType is the type of the destination (either topic or queue), destinationName is the name of the destination from which you wish to create a bridge, destinationToBridgeTo is the name of the destination you wish to create a bridge to, and selector="messsgeSelector" is an optional message selector to specify the subset of messages the destination should receive.
> Each destinationName can specify wildcards, and therefore any destination matching the pattern will have the specified bridge. Each destinationName can specify more than one destinationToBridgeTo.
> For example, the bridge illustrated in Figure 11 and Figure 12 would be specified as the following in bridges.conf:
> [topic:A.B]
> queue=queue.B
> topic=C.B
> Specifying a message selector on a bridged destination is described in the following section.
> Selecting the Messages to Bridge
> By default, all messages sent to a destination with a bridge are sent to all bridged destinations. This can cause unnecessary network traffic if each bridged destination is only interested in a subset of the messages sent to the original destination. You can optionally specify a message selector for each bridge to determine which messages are sent over that bridge.
> Message selectors for bridged destinations are specified as the selector property on the bridge. The following is an example of specifying a selector on the bridges defined in the previous section:
> [topic:A.B]
> queue=queue.B
> topic=C.B selector="urgency in(’medium’, ’high’)"
> For detailed information about message selector syntax, see the documentation for the Message class in the relevant EMS API reference document.
> Access Control and Bridges
> Message producers must have access to a destination to send messages to that destination. However, a bridge automatically has permission to send to its target destination. Special configuration is not required.
> Transactions
> When a message producer sends a message within a transaction, all messages sent across a bridge are part of the transaction. Therefore, if the transaction succeeds, all messages are delivered to all bridged destinations. If the transaction fails, no consumers for bridged destinations receive the messages.
> If a message cannot be delivered to a bridged destination because the message producer does not have the correct permissions for the bridged destination, the transaction cannot complete, and therefore fails and is rolled back.

Copyright © TIBCO Software Inc. All Rights Reserved.