| Author |
Message
|
| sfari |
 Posted: Tue Oct 16, 2007 8:24 am Post subject: Temporary Queues in Clusters |
 |
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Hello,
I am wondering if it is somehow possible to create (using JMS) a temporary reply queue, which is visible on other queue managers. For example as a cluster queue (model queue has no cluster attribute  ).
I know that the usual way is to set the ReplyToQ and ReplyToQmgr headers. The Problem is that we do not allow the services, which produce the reply to put on the transmission queues. Thus the ReplyToQmgr will not work. We don't allow that because of our security concept, which does separate the mq applications from each other with allowing them only to access their own queues.
Any other idea than cluster, how we could reach a temp. reply queue on a other queue manger without opening this security restrictions.
Thanks for your ideas! |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Oct 16, 2007 2:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Use a qmgr alias that's unique to the application...? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 17, 2007 3:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
| Use a qmgr alias that's unique to the application...? |
The problem still remains that each qmgr that hosts the receiving application has to have an alias, and that anyone who can put to the alias can put to any queue on the destination qmgr.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 17, 2007 3:22 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well the only way to really lock it down is to allow only fixed reply to queues and have a remote queue specified for each of those. You can then set the remote qmgr and qname on the replyto information. Security can then be setup at the sending qmgr....
Complicated but would prevent the previous problem. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 17, 2007 3:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
At least a permanent dynamic queue, rather than a temporary one.
But then this leads to things like 3,000 queues to manage... 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sfari |
| Posted: Wed Oct 17, 2007 4:43 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Through your discussion an idea came up in my mind. I would be interested in your opinion.
Assuming we have QMA (client side) and QMB (server side). On QMB I define a queue manager alias QMA_S, which points to QMA. QMA_S routes the message over a separate channel. QMA_S and the channel belongs to a specific application.
The client puts a request on a cluster Q on QMA (local Q is on QMB). The client sets ReplyToQM to QMA_S and ReplyToQ to a temporary queue on QMA.
The server just reacts in common way putting the reply to what it says in the request header.
Authorizations for specific applications can be defined on QMA_S. The separate channel allows to set a MCAUSER on the QMA side so I can set up specific authorizations there as well.
I think this would technically work but it's not really manageable for operations. What I also don't like about this is that I can not use the cool feature of reducing object definitions of MQ clustering.
Wow, that's complicated stuff . Any other ideas? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 17, 2007 10:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
With the restrictions in place I think your solution is as good as you are going to get.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
