Question

We are working on establishing an architecture where we will have two processing applications needing to receive information from a single queue (They will use the data in entirely different ways). What is considered best practice / path-forward for IBM WebSphere MQ in this situation?

  1. Pub / Sub - One publisher and "n" number of subscribers?
  2. The folks administering our MQ have suggested a fan out (trigger that reads from a named list and distributes to multiple queues) - This doesn't seem like a good idea to us.
  3. Others?

Any suggestions or input would be greatly appreciated.

Was it helpful?

Solution 2

I posed the question to one of the WebShere MQ contacts I have and here was his response. Thought it might help others.

"If the number applications processing the messages is expected to go up and the messaging pattern is not request/response, then go for pub/sub architecture. Otherwise use a namelist containing two queues from which applications receive messages. Please look at amqsptl0.c sample for details on how to put message to a namelist."

--S

OTHER TIPS

Decision to use Pub/Sub doesn't come from the fact that queues doesn't help ...

If your scenario is a request-response type of scenario the Queuing would be a best fit in most cases.

If your scenario will have many consumers dynamically getting added (or removed) then Pub-Sub helps.

I think what you are doing is routing messages to well known consumers. If there lot more of routing and transformation cases need to be dealt in future you can use IBM Integration Bus. If the routing is as simple as this, the sender can send a message to a queue and then a program can read messages from that in a transaction context and send those to 2 different queues. A message listener of JMS can help in aync processing.

Have a look at this pattern http://www.eaipatterns.com/MessageRouter.html . I guess it matches to what you are doing.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top