Another Layer of Indirection

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

Comments:

Hi, was searching articles on AQ to MQ , good guide on JMS. Well anything to substitute for MQ, could you suggest. Thank you A

Posted by Anirban Chaudhuri on August 25, 2007 at 08:57 AM MDT #

Post a Comment:
Comments are closed for this entry.
About

Musings on Fusion Middleware and SOA Picture of Antony Antony works with customers across the US and Canada in implementing SOA and other Fusion Middleware solutions. Antony is the co-author of the SOA Suite 11g Developers Cookbook, the SOA Suite 11g Developers Guide and the SOA Suite Developers Guide.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today