0
votes

This question is regarding designing a solution based on IBM MQ.

I have multiple systems (for example say 3) which are going to speak to a single IBM MQ server remotely, i.e the client systems are running in different machines.

What is the best practice for designing the solution,

  • Have 3 Queue Managers running on 3 different ports to have 3 channels dedicated to each system
  • Have a single Queue Manager with 3 different channels, dedicated to each system.

What is a good solution design practice? Any guidance will be very much helpful.

Thanks in advance, Yasothar

1
Are the client systems part of your own organization or external to you? Regardless of if you want with one queue manger or three queue managers you need to ensure that all channels defined on each queue manager are secured. You should use a different user for each client that is granted only permissions to the queues that it requires, this again would be the same advise for 1 or 3 queue managers.JoshMc
Hi Josh, all are part of my organization, and thank you I very much understand your point.Yasothar
Also consider that you want the queue manager to authenticate the inbound client connection in some way. you can have the client present a certificate and have the queue manager validate it and map that to a MCAUSER, or you can have the client send a username/password and have the queue manager validate it with CONNAUTH, in this second case you should still have TLS on the channel to protect the password, but the client would only require a truststore not a Keystore, or you could combine both and validate both a cert and a username/password. This ensures apps can't put to each others queues.JoshMc
Thanks a lot Josh, I'll do the reading on what you guided. Thank u very much.Yasothar

1 Answers

1
votes

Since all systems are within your organization, I would go with 1 queue manager. The big mistake people make is to try and share queues, channels, UserIds, etc. between applications.

The first thing to do is setup channel authentication (CHLAUTH) rules and enable connection authentication (CONNAUTH), so that you have proper MQ security in place. Since all systems are internal, you may or may not want to use TLS/SSL on the channels for data encryption between clients and the queue manager.

Don’t look at everything from 30,000 feet but rather break everything down to individual applications or micro applications. Assign each application their own queue, channel and UserId. Absolutely, positively, do NOT share channels or UserIds between applications.

Create a naming standard for your queues and channels, so that it is easy to identify who they belong to. I like naming things by division/department/group/function/component. Hence, it forms a nice tree of what you have defined and applications are using.

Note: I’m not a big fan of putting queue manager name or hostname or MQ object name (i.e. QUEUE or CHANNEL) in the name of channels or queues.

i.e. Channel names:

HR.PAYROLL
HR.RECRUITMENT
HR.TRAINING

i.e. Queue names:

HR.PAYROLL.TAXES.FEDERAL
HR.PAYROLL.TAXES.STATE
HR.PAYROLL.TAXES.SOCIAL.SECURITY