| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Multi-hopping & Queue Manager Aliasing. |
« View previous topic :: View next topic » |
| Author |
Message
|
| roshan.171188 |
 Posted: Thu Jan 03, 2013 3:03 pm Post subject: Multi-hopping & Queue Manager Aliasing. |
 |
|
Apprentice
Joined: 07 Jun 2012
Posts: 35
|
Hi All,
I am sorry if it is a disappointing question but can anyone please let me know what are the pro's n con's of using Multi-Hop setup vs QM Alias setup.
Per my understanding, they both do almost the same thing by hiding the actual destination from the source by a hub in middle and in this case QM Alias setup should be more efficient.
But i have noticed both the setups being used in infrastructures and was curious what the significant difference is.
Thanks!
Manish |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Jan 03, 2013 4:18 pm Post subject: Re: Multi-hopping & Queue Manager Aliasing. |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| roshan.171188 wrote: |
Hi All,
I am sorry if it is a disappointing question but can anyone please let me know what are the pro's n con's of using Multi-Hop setup vs QM Alias setup.
Per my understanding, they both do almost the same thing by hiding the actual destination from the source by a hub in middle and in this case QM Alias setup should be more efficient.
But i have noticed both the setups being used in infrastructures and was curious what the significant difference is.
Thanks!
Manish |
You've mixed a few terms and concepts.
Briefly...
In a hub-and-spoke network, all messages are sent from the source queue-manager to the hub queue-manager for distribution to the destination queue-manager.
Multi-hopping occurs when a message needs to traverse one or more queue-managers in order to reach the destination queue-manager.
So, hub-and-spoke networks multi-hop messages through the one queue-manager, the hub queue-manager. Hub queue-managers often do no real application work; but merely move messages to adjacent queue-managers.
Generally, queue-manager alias is used to resolve a queue-manager name. One of the uses of a queue-manager alias is to move a message down the network to one or more intermediary, non-adjacent, queue-managers. This network arrangement is often called a daisy-chain.
In a daily-chain network arrangement, one queue-manager is networked to the next queue-manager, which is networked to the next queue-manager (QM1 -> QM2 -> QM3 -> QM4 -> QM5). If a message is created on QM1, and the destination queue-manager is on QM5, then the message must traverse QM2, QM3, and QM4. QM2 and QM3 will need a queue-manager aliases since they are non-adjacent (don't have a transmission queue) to the destination queue-manager.
Generally, the fewer hops, the quicker the message arrives, and the more reliable the network.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| roshan.171188 |
| Posted: Thu Jan 03, 2013 4:49 pm Post subject: Re: Multi-hopping & Queue Manager Aliasing. |
|
|
Apprentice
Joined: 07 Jun 2012
Posts: 35
|
| bruce2359 wrote: |
| roshan.171188 wrote: |
Hi All,
I am sorry if it is a disappointing question but can anyone please let me know what are the pro's n con's of using Multi-Hop setup vs QM Alias setup.
Per my understanding, they both do almost the same thing by hiding the actual destination from the source by a hub in middle and in this case QM Alias setup should be more efficient.
But i have noticed both the setups being used in infrastructures and was curious what the significant difference is.
Thanks!
Manish |
You've mixed a few terms and concepts.
Briefly...
In a hub-and-spoke network, all messages are sent from the source queue-manager to the hub queue-manager for distribution to the destination queue-manager.
Multi-hopping occurs when a message needs to traverse one or more queue-managers in order to reach the destination queue-manager.
So, hub-and-spoke networks multi-hop messages through the one queue-manager, the hub queue-manager. Hub queue-managers often do no real application work; but merely move messages to adjacent queue-managers.
Generally, queue-manager alias is used to resolve a queue-manager name. One of the uses of a queue-manager alias is to move a message down the network to one or more intermediary, non-adjacent, queue-managers. This network arrangement is often called a daisy-chain.
In a daily-chain network arrangement, one queue-manager is networked to the next queue-manager, which is networked to the next queue-manager (QM1 -> QM2 -> QM3 -> QM4 -> QM5). If a message is created on QM1, and the destination queue-manager is on QM5, then the message must traverse QM2, QM3, and QM4. QM2 and QM3 will need a queue-manager aliases since they are non-adjacent (don't have a transmission queue) to the destination queue-manager.
Generally, the fewer hops, the quicker the message arrives, and the more reliable the network. |
Thanks Bruce for such a detailed explanation, but again, are they not doing the same work of directing the message to the destination either by using a dedicated QRemote object or via an alias QM?
The eg. you gave for QM Aliasing (QM1 -> QM2 -> QM3 -> QM4 -> QM5) can also be done by creating a dedicated QRemote on each hub (multi hop), but then what would be the difference? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 03, 2013 5:29 pm Post subject: Re: Multi-hopping & Queue Manager Aliasing. |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| roshan.171188 wrote: |
Thanks Bruce for such a detailed explanation, but again, are they not doing the same work of directing the message to the destination either by using a dedicated QRemote object or via an alias QM? |
There is no such thing as an alias QM?
A queue-manager alias definition is a QRemote definition with a null RName attribute.
| roshan.171188 wrote: |
| The eg. you gave for QM Aliasing (QM1 -> QM2 -> QM3 -> QM4 -> QM5) can also be done by creating a dedicated QRemote on each hub (multi hop), but then what would be the difference? |
Let's keep this simple. In a hub-and-spoke, there is one hub. All queue-managers connect to the hub. On each of the spoke queue-managers, there needs to be one QRemote definition that names a transmission queue either explicitly, or implicitly. The one-and-only hop is to the hub. No queue-manager aliases are necessary in this configuration.
In my simple daisy-chain example, when a message is created on QM1, it needs to be moved to QM2, on its way toward QM5. There is no hub in this configuration. QM2 needs a definition to move the message from QM2 to the next hop QM3.
So, when the message arrives on QM2, a queue-manager alias must exist to resolve the queue-manager name in the XQH (transmission queue header): DEF QR(QM5) RQMname(QM5) XMITQ(QM3).
This definition tells the MCA (message channel agent) on QM2 to move the message to transmission queue named QM3, so that the message will be sent to QM3.
When the message arrives on QM3, a queue-manager alias will be needed to move the message to a transmission queue named QM4: DEF QR(QM5) RQMname(QM5) XMITQ(QM4).
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| roshan.171188 |
| Posted: Fri Jan 04, 2013 5:01 am Post subject: |
|
|
Apprentice
Joined: 07 Jun 2012
Posts: 35
|
Thanks you Bruce!
Appreciate your valuable time spent on me.
Cheers!
! Hope someday i will be as Pro as you ! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jan 04, 2013 11:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You would for example use something like what bruce is calling a daisy chain in order to keep the layout of one MQ network private from the layout of another MQ network.
So you define a path from QM1->QM2->QM3 in order to prevent anything at QM1 from knowing anything about QM3.
The only thing and the only route that QM1 knows is how to get to QM2. Everything else is resolved at QM2. So as long as QM2 is *secured*, then no application can send messages to QM3 without going through QM2. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
