Author |
Message
|
dim |
Posted: Mon Mar 07, 2005 2:41 am Post subject: Complex topology networks based on WMQ |
|
|
Newbie
Joined: 26 Jun 2002 Posts: 5
|
Hello, all
Does anybody have an experience in creating complex topology networks with WMQ? For instance, for an organization that has multistaged hierarhical structure.
In traditional WQM network based on remote queue definitions we have to define all routes on each node for all nodes that it should send messages to. With addition of a new node we must reconfigure rqdefs on all nodes that should communicate with it. This not a problem in domain addressing (as in SMTP) when it is possible to route messages on domain/subdomain basis.
Is it possible to implement in WMQ network truly routing servers that make routing decisions by part of domain address?
Evidently it draws us to some new over-WMQ layer/API with abstract addressing scheme (web services?) and WMQ as low level transport layer with async assured delivery.
Does anybody khow about similar solutions?
I know about WebSphere BI Message Broker. Is there any solutions for it? |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Mar 07, 2005 4:33 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
There are two ways around remote queue definition proliferation.
One is to use Queue Manager aliases. This allows you to a) not create remote queue defs for each individual queue, b) create easily modified multi-hop routes to different queue managers.
The other is MQ Clustering. It's not just for load-balancing any more!
For info on basic MQ network topologies and techniques for building them, see the Intercommunications manual.
For info on clustered networks, see the Cluster manual. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
dim |
Posted: Wed Mar 09, 2005 4:09 am Post subject: Complex topology networks based on WMQ |
|
|
Newbie
Joined: 26 Jun 2002 Posts: 5
|
Thank you for your mail
I think qmgr alias do not solve the problem completely.
Please, imagine a central qmgr in headquarters which should route message flows to subordinate offices. Subordinate offices have several qmgrs and possibly their own subordinates (with qmgrs) . If central hub wishes to send messages to any qmgr in subordinate it has to define all qmgr aliases for all subordinate's qmgrs. Also, when a qmgr is added, a qmgr alias on central qmgr has to be added too. It was more stable structure if the central qmgr just knew a route to a single qmgr in subordinate office as a gate to all subordinate's network. I think WMQ itself cannot do this and I need some high level over.
About cluster, I believe that it purpose is to simplify administrative tasks such as lowering quantity of channels and transmission queues in multi qmgr network where each qmgr should communicate with each and it does not solve any routing tasks, right? |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Mar 09, 2005 4:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Clustering does help in this situation.
If all qmgrs are in the same cluster, then all queues are reachable no matter where they are.
If the qmgrs are in different clusters, then either the clusters can be overlapped or have manual gateways created. In either case, messages go to all queues through certain qmgrs.
Again, there's much more indepth on this in both the Intercommunications manual and the Clusters manual. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
PGoodhart |
Posted: Wed Mar 09, 2005 4:47 am Post subject: |
|
|
Master
Joined: 17 Jun 2004 Posts: 278 Location: Harrisburg PA
|
Just as another thing to look into you may want to look into moving to a Publish/Subscribe model if you are able to impact the application architecture. It would help.
Oh and cluster namelists too. _________________ Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
Back to top |
|
 |
malammik |
Posted: Wed Mar 09, 2005 10:16 am Post subject: |
|
|
 Partisan
Joined: 27 Jan 2005 Posts: 397 Location: Philadelphia, PA
|
A good way to organize exchange of the data at the MQ transport level is via hub and spoke architecture using queue manager aliases or clusters w/o hub and spoke. A good way to organize exchange of the data at the application level using mq as transport it via IBM broker technologies which can do smart routing, filtering, web services and most importantly publish/subscribe. All in all this is pretty much what the two other posts above say but I though my 2 cents might help as well. _________________ Mikhail Malamud
http://www.netflexity.com
http://groups.google.com/group/qflex |
|
Back to top |
|
 |
JLRowe |
Posted: Wed Mar 09, 2005 10:23 am Post subject: |
|
|
 Yatiri
Joined: 25 May 2002 Posts: 664 Location: South East London
|
Without clustering you can use the default transmission queue on each spoke to the hub and a remote queue for every spoke on the hub. |
|
Back to top |
|
 |
|