JMS Application Design

Hi All,

I am currently designing a JMS application and I have a few questions....

At the following URL .....

I found information telling me that there are two different ways to configure a JMS application.

1. Use triggers function of WebSphere MQ
2. Deploy a Message-Driven Bean to WebSphere App Server connected to the MQ

Most of our existing applications use method 2. However I have been asked to investigate method 1 and to find out how commonly used it is. Can anyone provide me some advice on how hard it is to use this and whether it is standard practice?

Also If I do with option 2. I have been asked to look into architecting the application using a multi-threaded / load balancing architecture. For example. Is it possible to get two instances of the message driven bean listenting for messages  on the same queue? In that way if one of the listeners dies because of unforseen circumstances then at least the other instance will remain alive processing messages.

I'm not sure about this last question. I would think it would be possible but then how do the two applications know how to share to load?

Who is Participating?
Jim CakalicSenior Developer/ArchitectCommented:
Hi. I've used MQ triggers in previous applications. It isn't extraordinarily difficult. We were using MQ on Windows servers. As I recall one of the biggest issues was always correct configuration of the process definition to be sure that it spawned a detached process otherwise it would block the initiation queue until the spawned process completed. Another concern is that, assuming you're writing your triggered processes in Java, each will spin up another JVM instance. This isn't really very efficient if you have a significant number of queues. On Windows the triggering mechanism didn't seem to be very reliable. I'll admit this was 7-8 years ago so I can't speak to the improvements IBM may have made in WMQ since then. In the end, since we were also a WAS shop, we started converting all our triggered processes to MDBs. One advantage of this was that we got XA-transactions for free using MDBs which you wouldn't using triggered processes. An alternative now might be to use an ESB like Mule to handle all the MQ processing.

As for a distributed multi-threaded load-balanced design, yes it is possible to have multiple instance of an MDB and multiple application servers with a deployed MDB that are all listening on the same queue. WMQ knows to deliver the message to just one instance with BMT or CMT determining if the read is committed or not. The "load-balancing" is really a function of message delivery rate and how busy the application server is. The MDB threads compete with all the other server activities for resources. Say you have your application deployed on two app servers running on different hosts. Each app server will have multiple instances of the MDB that can be handling messages in parallel, say 5 instances per server. The MDB needs a finite amount of time to process a message, let's call it 1 second. That means each server will be handling messages at the rate of 5 per second. If server A gets very busy because of some other activity and now it takes 2 seconds per message while server B is still processing at 1 second per message then server B will consume more of the load than server A.


Jim Cakalic
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.