Another Layer of Indirection
or More JMS Router Use Cases
In response to my last post one of the Oracle product managers for messaging posted the following comment
"It is true that the purpose of the JMS Router often eludes people -
thanks for helping clearing that up! I often summarize the mission of
the JMS Router as being to bridge:
1- destinations (ex: Topic T1 to Queue Q1)
2- vendors (ex: Oracle to IBM - as described in your post)
3- geographies (ex: forward, selectively and over HTTPS, some JMS traffic from the US to EMEA)"
So I thought I would expand on this a little.
Use Case 1 - Bridging Destinations
In this scenario we may use the JMS router to match different types of message destinations. Queues are typically used for point to point message delivery whilst topics are generally used in a publish/subscribe model. Sometimes we want to take messages from one mechanism and transfer them to the other. For example an application may be configured to receive certain stock updates on a queue because it is interested in monitoring market movements rather than current stock prices. Stock prices might be distributed across a topic. We could then use the router with an appropriate message selector to limit our message transfer from the topic to the queue of only those messages of interest to the application. This could be done without any need to touch publishers to the topic or the queue consumer.
Use Case 2 - Bridging Messaging Technologies or Vendors
This is the scenario I described in my previous posting where we might need to bridge two vendors messaging systems. I described how a client needed to bridge Oracle AQ and IBM MQ, taking advantage of the best features of both systems. Another client I am working with has a need to bridge between Oracle Messaging and Tibco Messaging. Again the JMS router can be used to mediate between the two technologies, transferring messages from an Oracle Queue to a Tibco Queue and vice-versa.
Use Case 3 - Bridging Geographies or Messaging Domains
In this scenario we have physically or logically distributed messaging domains. For example a betting system might require Australian, UK and offshore (unregulated) versions of its systems. These systems may have a need to comunicate, for example the Australian system may need access to the Premier League market data in the UK system. The JMS router could be used to loosely couple these different domains.
A Handy Tool
Hopefully like me you can now see the value of the JMS Router as a product that apparently does nothing, but when it comes down to it is yet another proof of the old adage that "every problem in computer science can be solved by another level of indirection".