CODEWITHSUNDEEP
ibm-mq
user3062622
user3062622

Reputation: 1

Can MQ Support Multiple Separate Clients for the Same Queue While Maintaining Independent Messaging?

We have multiple application environments (development, QA, UAT, etc) that need to connect to fewer provider environments through MQ. For example, the provider only has one test (we'll call it TEST1) environment to which all of the client application environments need to interact. It is imperative that each client environment only receives MQ responses to the messages sent by that respective environment. This is a high volume scenario so correlating message IDs has been ruled out.

Right now TEST1 has a queue set up and is functional, but if one of the client app's environments wants to use it the others have to be shut off so that messaging doesn't overlap.

Does MQ support a model having multiple clients connect to a single queue while preserving the client-specific messaging? If so, where is that controlled (i.e. the channel, queue manager, etc)? If not, is the only solution to set up additional queues for each corresponding client?

Upvotes: 0

Views: 1221

Answers (2)

Roger
Roger

Reputation: 7506

Over the many years I have worked with IBM MQ, I have gone back and forth on this issue. I've come to the conclusion that sharing a queue just makes life more difficult. Queues should be handed out like candy on Halloween. If an application team says that they have 10 components to their application then the MQAdmin should give them 10 queues. To the queue manager or server or CPU or hard disk, there is no difference in resource usage.

Also, use an MQ naming standard that makes sense and is easy to apply security to. i.e. for HR (Human Resource) department

  • HR.PAYROLL.SALARY
  • HR.PAYROLL.DEDUCTIONS
  • HR.PAYROLL.BENEFITS
  • HR.EMPLOYEE.DETAILS
  • HR.EMPLOYEE.REVIEWS
  • etc...

Upvotes: 1

Mark Taylor
Mark Taylor

Reputation: 1027

You could use a selector such as MQGET(where applname="myapp") or based on a specific user-defined property assuming the sender populates such a property but that's likely to be worse performance than any retrieval by msgid or correlid. Though you've not given any information to demonstrate that get-by-correlid is actually problematic.

And of course any difference between a test and production environment - whether it involves code or configuration - is going to be very risky.

You would not normally share a single destination queue between multiple different application types - multiple queues is far more standard.

Upvotes: 0

Related Questions