TIBCO EMS Bridges and Routes

                                         TIBCO EMS Bridges and Routes

Brief Introduction

TIBCO Enterprise for JMS allows sending messages across applications. Java Message Service is a Java framework specification for messaging between applications. Using a message service allows you to integrate the existing as well as the new   publications within an enterprise.

JMS follows the two messaging paradigms namely Publish/Subscribe and Point to Point

Point-to-point messaging has one producer sending message to the destination and one consumer subscribing per message. Queue follows such kind of point to point messaging to store messages until they are received. The producer sends the message to the queue and the message consumer retrieves the messages from the queue and sends acknowledgement that the message was received. We can have more than one producer and consumer sending and receiving different messages on the same queue.

In a publish and subscribe messaging model the producer i.e. the publisher publishes(sends) the message to the destination and the same message  can be subscribed (retrieved)by multiple subscribers unlike a queue where only one subscriber can subscribe per message. Topic follows such kind of publish/subscribe messaging.

This type of messaging can also be called as “broadcast messaging” because messages are sent over the network and it is received by all subscribers who are active when the message is published.

One of the interesting features in JMS is that we can copy messages from one destination where they are being published to yet another destination where there is a newly defined interest in consuming that message. This can be achieved by the ability of bridges and routes.

2.  Bridges

First, let us understand the concept of Bridge and then let us navigate towards routes.

Bridges can be created between one destination and one or more other destinations

of the same or of different types i.e. 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 to queue B and topic C.

In the figure below, we can see a bridge being created between a topic “TopicA” and a queue “QueueB”. The messages published on TopicA will flow to the queue QueueQ with the same JMS server.

1. Bridges can be configured between one or more destinations within the same JMS server.

2. Bridges can be between topic to queue, topic to topic etc.

3. Bridges are non-transitive i.e. bridge from For example, topic A  has a bridge to queue B .Queue B has a bridge to topic C. Messages delivered to topic A  are also delivered to queue B, but not to topic C.

4. A message published on one destination is available on other destinations also so that many receivers can get the same message.

5. It is a pure Java client.

6. 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 consumer does not have the correct permissions for the bridged destination, the transaction cannot complete, and therefore fails and is rolled back.

7. By default, all the messages are sent to the destination with a bridge are sent to all bridged destinations.  The selectors can be used to filter the messages. Selectors are filters at the server side. The subscribing application only gets the messages it needs. This helps in preserving bandwidth. Before sending the messages the selector is checked. The subscriber specifies the selector.

8. Publisher on the source destination should have the permissions to publish on target destination.

9. Bridges are configured manually and the JMS server has to be restarted.

10. Bridges can also exist between Tibco based JMS destination and Vitria based channels.

11. The server needs to be restarted only for the bridge configuration within JMS server and not between Tibco based JMS destination and Vitria based channels.

12. 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 above would be specified as

the following in bridges.conf:

[topic:TopicA]

queue=QueueB

3. Routes

The route is similar to that of bridges. However, the bridge is configured between destinations within the same server whereas the route is configured between different servers.

1. Routing happens between destinations across different JMS servers. It’s a replication process.

2. The destination names should be the same in both the servers.

3. The destination properties in both should be set to global. This facilitates two way messaging. You would just need to publish on one and it will be replicated on the second one. Communication on the route is bidirectional.

4. The process also supports filtering via selectors. But selectors are not supported in queue routing.

5. Routes can be transitive in case of topics but non-transitive in case of queues.

6. No cyclic loops allowed for routing. Routes for topics can be multi-hop, but must be acyclic. Routes for queues can only be single hop, and must also be acyclic.

7. When a bridge configuration is changed the entire server needs to be restarted whereas in routing it is not needed.

8. To create a route using the administration tool, use the create route command

with the following syntax:

create route <name> url=<URL> [<properties ...>]

where name is the name of the server you wish to route to, URL is the URL for the

remote server, and properties are a space-separated list of connection properties for

the route.

In this example, we have two servers: ServerA and ServerB. ServerA creates a

route to ServerB by issuing the following command in the administration tool:

create route ServerB url=tcp://serverB:7454

You can display this route using the “show routes” command in the administrator

tool:

Eg:

Routing between topic on Server A and topic on Server B

1) Make both topics Global

2) Grant permission for server A on Server B

3) Grant permission for server B on Server A

4) Configure Route

5) Check Logs.