The scenario
I have an MQ Request queue that takes multiple types of business objects as input. The MQ request queue consumer evaluates the type of the message and routes it to the appropriate downstream service. When the response comes back from the downstream system, it is placed into the single MQ Response queue. Therefore, the MQ Response Queue contains multiple types of response messages.
In my scenario, I need to invoke two services. I do this by placing two distinct message requests onto the request queue: Service invocation 1 and Service Invocation 2.
I create a BPEL process to invoke the two services in serial.
The Anti-Pattern
I create two MQ Imports and two WSDL files representing each operation. One for the invocation of service 1 and a second for the invocation of service 2. I configure each MQ Import to have it’s own unique listener port but I have them use the same queue manager and same physical request and response queues.
The Problem Manifests
What I see is that sometimes, the response message from my invocation of service 2 is picked up by the listener port for service 1. Service 2 never gets the response values and service 1 throws an exception. Eventually the listener ports will shut themselves down from the errors.
Why?
By creating two MQ Imports, I have now created two independent listener ports that are listening for messages on the same queue. They’re in a race condition about which one will get notified about the arrival of a message.
The MQ Import Pattern
Stick with a single listener port for your set of request/response queues. In order to use a single listener port, you need to have a single MQ Import. You could do this by creating a single WSDL for your two operations to the request queue, or I believe you could add multiple wsdl interfaces to a single MQ Import.
Not sure I follow the whole scenario but why not have more than one queue per service instead of this one queue handles all?
The ‘anti-pattern’ is for how you design your WID module. When you create an Import/Export for an MQ queue you are creating server resources that will listen and process messages. You can get yourself into a scenario where you have multiple listeners inside the same ear listening to the same queues and things can blow up in your face 🙂
As for the ‘One-queue-to-rule-them-all’ it’s usually caused by an overeager push to be as ‘dynamic’ as possible without considering the actual value (if any) of the routing mechanism.