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.
