| Author |
Message
|
| alex741 |
 Posted: Fri Jun 06, 2014 1:29 am Post subject: QManager Alias question |
 |
|
Newbie
Joined: 05 Jun 2014
Posts: 7
|
Hello all,
After going through recently updated IBM KB web site, still haven't found an answer to my question:
Basically we are trying to find out if it is possible to use Queue Manager Aliases to "hide" real Queue Manager name from our remote clients who connect to our MQ environment.
I believe it is possible to do if we have queue-to-queue environment, but I have a client who uses client-to-queue environment, i.e. his app connects to our queue and there is no MQ environment on his side... Is it possible to use Queue Manager Aliasing in that case ? I suspect that the answer is no, but would appreciate if anyone can suggest/confirm.
Many thanks,
Alex |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Jun 06, 2014 1:49 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Hopefully THIS will be of use to you. I am assuming that what you mean by "...no MQ environment on his side..." means no MQ Server infrastructure.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| alex741 |
| Posted: Fri Jun 06, 2014 2:13 am Post subject: |
|
|
Newbie
Joined: 05 Jun 2014
Posts: 7
|
| exerk wrote: |
| Hopefully THIS will be of use to you. I am assuming that what you mean by "...no MQ environment on his side..." means no MQ Server infrastructure. |
Thanks for this - much appreciated.
However what i meant is the "inverted" version of what I understand you have suggested - say we have a QManager called "Host" and we have multiple clients who need to connect to it and their own queues there, but what we want them to do is to use QManager names "Host1" or "Host2", etc. but they will be "mapped" to the original Qmanager "Host" ... ?
Hope this makes sense. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jun 06, 2014 2:47 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Basically you can set it up such that the queue manager name the application uses is as simple as *, or be a bit more creative with the name and have *HOST1, *HOST2 etc., and they'll all still be connecting to the same HOST queue manager.
Your Third-Party will still be able to see the real name returned but then they shouldn't be able to connect directly to your back-end infrastructure anyway. The suggested solution is to create a gateway queue manager that they connect to, which you can call whatever you like if you need to obfuscate your internal naming standard, and bounce traffic from/to your back-end queue manager(s).
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| alex741 |
| Posted: Fri Jun 06, 2014 2:56 am Post subject: |
|
|
Newbie
Joined: 05 Jun 2014
Posts: 7
|
| exerk wrote: |
Basically you can set it up such that the queue manager name the application uses is as simple as *, or be a bit more creative with the name and have *HOST1, *HOST2 etc., and they'll all still be connecting to the same HOST queue manager.
Your Third-Party will still be able to see the real name returned but then they shouldn't be able to connect directly to your back-end infrastructure anyway. The suggested solution is to create a gateway queue manager that they connect to, which you can call whatever you like if you need to obfuscate your internal naming standard, and bounce traffic from/to your back-end queue manager(s). |
Thats a cool solution, but the idea behind what we wanted to have is actually to reduce the number of QManagers... Preferably down to one. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jun 06, 2014 3:10 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| alex741 wrote: |
| exerk wrote: |
Basically you can set it up such that the queue manager name the application uses is as simple as *, or be a bit more creative with the name and have *HOST1, *HOST2 etc., and they'll all still be connecting to the same HOST queue manager.
Your Third-Party will still be able to see the real name returned but then they shouldn't be able to connect directly to your back-end infrastructure anyway. The suggested solution is to create a gateway queue manager that they connect to, which you can call whatever you like if you need to obfuscate your internal naming standard, and bounce traffic from/to your back-end queue manager(s). |
Thats a cool solution, but the idea behind what we wanted to have is actually to reduce the number of QManagers... Preferably down to one. |
Brave man - so, do you want to reduce the number of queue managers overall, or the footprint across a number of servers?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 06, 2014 3:23 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
MQ Clients don't have to supply a QM name on the MQ connect call. The combination of hostname and port number is unique - there can only be one QM listening on that combination, so the QM name is not needed.
Don't even tell them the name of your Queue Manager.
But the next time they do an MQPUT all they need to do is look at the returned value in the MQMD's Reply To Queue Manager which will be the actual QM they connected to.
What benefit do you hope to gain by them not knowing the name of the QM, that you are allowing them to connect to and use?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| alex741 |
| Posted: Fri Jun 06, 2014 3:48 am Post subject: |
|
|
Newbie
Joined: 05 Jun 2014
Posts: 7
|
| exerk wrote: |
| alex741 wrote: |
| exerk wrote: |
Basically you can set it up such that the queue manager name the application uses is as simple as *, or be a bit more creative with the name and have *HOST1, *HOST2 etc., and they'll all still be connecting to the same HOST queue manager.
Your Third-Party will still be able to see the real name returned but then they shouldn't be able to connect directly to your back-end infrastructure anyway. The suggested solution is to create a gateway queue manager that they connect to, which you can call whatever you like if you need to obfuscate your internal naming standard, and bounce traffic from/to your back-end queue manager(s). |
Thats a cool solution, but the idea behind what we wanted to have is actually to reduce the number of QManagers... Preferably down to one. |
Brave man - so, do you want to reduce the number of queue managers overall, or the footprint across a number of servers? |
The idea is to reduce the number of QManagers overall... |
|
| Back to top |
|
|
| alex741 |
| Posted: Fri Jun 06, 2014 3:50 am Post subject: |
|
|
Newbie
Joined: 05 Jun 2014
Posts: 7
|
| PeterPotkay wrote: |
MQ Clients don't have to supply a QM name on the MQ connect call. The combination of hostname and port number is unique - there can only be one QM listening on that combination, so the QM name is not needed.
Don't even tell them the name of your Queue Manager.
But the next time they do an MQPUT all they need to do is look at the returned value in the MQMD's Reply To Queue Manager which will be the actual QM they connected to.
What benefit do you hope to gain by them not knowing the name of the QM, that you are allowing them to connect to and use? |
We just wanted to put all queues under the same "roof" and minimise the amount of QManagers... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 06, 2014 5:06 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| alex741 wrote: |
| PeterPotkay wrote: |
MQ Clients don't have to supply a QM name on the MQ connect call. The combination of hostname and port number is unique - there can only be one QM listening on that combination, so the QM name is not needed.
Don't even tell them the name of your Queue Manager.
But the next time they do an MQPUT all they need to do is look at the returned value in the MQMD's Reply To Queue Manager which will be the actual QM they connected to.
What benefit do you hope to gain by them not knowing the name of the QM, that you are allowing them to connect to and use? |
We just wanted to put all queues under the same "roof" and minimise the amount of QManagers... |
OK, but what does that have to do with not wanting them to know the name of QM?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| alex741 |
| Posted: Fri Jun 06, 2014 6:06 am Post subject: |
|
|
Newbie
Joined: 05 Jun 2014
Posts: 7
|
| PeterPotkay wrote: |
| alex741 wrote: |
| PeterPotkay wrote: |
MQ Clients don't have to supply a QM name on the MQ connect call. The combination of hostname and port number is unique - there can only be one QM listening on that combination, so the QM name is not needed.
Don't even tell them the name of your Queue Manager.
But the next time they do an MQPUT all they need to do is look at the returned value in the MQMD's Reply To Queue Manager which will be the actual QM they connected to.
What benefit do you hope to gain by them not knowing the name of the QM, that you are allowing them to connect to and use? |
We just wanted to put all queues under the same "roof" and minimise the amount of QManagers... |
OK, but what does that have to do with not wanting them to know the name of QM? |
Well, I guess that was a "by-product"  as we would rather not allow the client to get to know the real mq manager name... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 06, 2014 6:29 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
After MQCONNecting, an client app can very easily determine the qmgr name with an MQINQuire call.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Fri Jun 06, 2014 6:34 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| bruce2359 wrote: |
| After MQCONNecting, an client app can very easily determine the qmgr name with an MQINQuire call. |
Only if you authorised them to issue MQINQ calls against the QM object.
But even if you restrict the MQINQ calls, there are still ways to figure out the name of the QM you are connected to. If all you can do is put, look at the MQMD's Reply To QM field on the return of the put call. Or the first part of the QM generated Message ID.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| alex741 |
| Posted: Fri Jun 06, 2014 1:43 pm Post subject: |
|
|
Newbie
Joined: 05 Jun 2014
Posts: 7
|
| PeterPotkay wrote: |
| bruce2359 wrote: |
| After MQCONNecting, an client app can very easily determine the qmgr name with an MQINQuire call. |
Only if you authorised them to issue MQINQ calls against the QM object.
But even if you restrict the MQINQ calls, there are still ways to figure out the name of the QM you are connected to. If all you can do is put, look at the MQMD's Reply To QM field on the return of the put call. Or the first part of the QM generated Message ID. |
That's cool guys, but I guess I need to re-phrase my question - hiding the QM name is ok - but it is not too important, what is important - to keep all "virtual" QMgrs under one roof of the "main" QMgr.
If there is a good way of doing that - I'd be happy to listen to any suggestions.
Much appreciate your help ! |
|
| Back to top |
|
|
|
|
