| Author |
Message
|
| murdeep |
 Posted: Mon May 15, 2006 7:56 am Post subject: Avoiding broker affinity in a multi broker design |
 |
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Hi, I am working on designing a multi broker/wmq configuration that will act as an intermediary processing requests from service consumers and responses from service providers. In this design I want to avoid broker affinity.
What I have so far is this. I cluster my broker request flow input queues. This way service consumers will route to any available broker by referencing the message flow input queue. The request is processed and state data is written to a state managemnet database that is accessible by all brokers. This way when the response comes back the response flow will be able to get the state data regardless of which broker processed the request.
The problem I am having is how do I design the service provider. To avoid broker affinity I think I must do the following:
1. have the service provider queue manager part of the broker cluster
2. expose the response message flow input queue as a cluster queue
3. ensure the service provider does not honor the reply to queue manager information in the request when sending the response, i.e. leave the queue manager name blank in the OD on the open or put1 call of the response.
Ideally I would like to avoid number 3 since this goes against the rules of designing a well behaved MQ application.
So my question is this: is there a way to avoid broker affinity in this model through some kind of clustering design or do I have to meet the 3 requirements above to ensure the reponse flows to any available broker? |
|
| Back to top |
|
 |
| wschutz |
| Posted: Mon May 15, 2006 8:12 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
|
| Back to top |
|
|
| EddieA |
| Posted: Mon May 15, 2006 8:38 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Wayne, would that work if the replying application specifies both Queue and QM under the the "normal" reply model.
You could try a QMAlias at the service provider that changes the ReplyQM to "blank". And if you didn't want to do this "globally" for some reason, then use a "dummy QM" for the ReplyToQM in the Broker that is then aliased by the service provider.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| murdeep |
| Posted: Mon May 15, 2006 9:38 am Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Wayne/Eddie, soi f I understand this what you are saying is:
On the service provider queue manager for each broker queue manager define a remote queue named after the broker queue manager. This remote queue should specify a blank rname and a blank rqmname.
As a result when the service provider specifies the od.qmgr and od.qname when it sends the response queue name resolution will occur and the remote queue named after the broker will be found. Since the rqmname is blank the service provider queue manager will ultimately try to open a local queue named after the od.qname and this will resolve to the response message flow input queue which is a cluster queue.
Correct? |
|
| Back to top |
|
|
| murdeep |
| Posted: Mon May 15, 2006 9:50 am Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Sorry, in my last post I may be mistaken. I think my alias defined on the service provider for each broker would be as follows:
def qr(broker_qmgr) rname(' ') rqmname(service_provider_qmgr). This way when queue name resolution occurs the od.qmgr is replaced with the service provider qmgr and the rname takes the od.qname value. This results in a local queue named od.qname being opened which is a cluster queue.
Is this how it should be done? |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon May 15, 2006 9:57 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| EddieA wrote: |
| Wayne, would that work if the replying application specifies both Queue and QM under the the "normal" reply model. |
Well.. when the message flow sends the message via the MQOutput node, for the replyToQ, it would specify the replToQ-alias object name, which would be defined in the broker's local qmgr. I would think that as long as the replyToQMgr is also the local qmgr name, it should resove to the real replytoQ with a blank qmgr name (but, I haven't actually tried it..)
But why wouldn't the flow just leave the replyToQmgr name blank?
_________________
-wayne |
|
| Back to top |
|
|
| murdeep |
| Posted: Mon May 15, 2006 10:00 am Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| Wayne, if the flow leaves replytoQmgr name blank then this will be filled with the broker qmgr name. Shouldn't the aliasing be occurring at the service provider queue manager? |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon May 15, 2006 11:19 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Okay, say the clustered reply to queue is named REPLYTOQ.
On each qmgr that hosts a broker, you've defined:
| Code: |
DEF QR(REPLYTOQALIAS) RNAME(REPLYTOQ) RQMNAME(' ')
|
Now, your flows set the mqmd.replyToQ = "REPLYTOQALIAS" and leave the qmgr blank. Normally, if there wan't a replytoq-alias definition, the message flowing to your server would have the qmgr name filled in by the qmgr (ie, its own name), but since you have a replytoQ-alias definition, that overrides that behaviour and uses the qmgr name from the definition (which you have set to blank). So when the message arrives at your backend server, it will have a blank replytoQmgr name and use the clustered REPLYTOQ.
Now, if in the future you need to have the replies returing to the same broker, you can change the replytoQ to REPLYTOQ and the replyToQMgr name will be filled in by the qmgr.
_________________
-wayne |
|
| Back to top |
|
|
| murdeep |
| Posted: Mon May 15, 2006 11:34 am Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| Wayne, thanks that clears it up. So the message arrives at the service provider with a blank MD.ReplyToQmgr which then forces the service provider to look for a locally defined queue, in this case a cluster queue exposed by the broker. |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon May 15, 2006 11:37 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Precisely, and I suppose you could make the replytoq alias definition a clustered definition. 
_________________
-wayne |
|
| Back to top |
|
|
|
|
