When is messaging (e.g. JMS) an alternative for multithreading?

Question

I work on a data processing application in which concurrency is achieved by putting several units of work on a message queue that multiple instances of a message driven bean (MDB) listen to. Other than achieving concurrency in this manner, we do not have any specific reason to use the messaging infrastructure and MDBs.

This led me to think why the same could not have been achieved using multiple threads.

So my question is, in what situations can asynchronous messaging (e.g. JMS) be used as an alternative to mutithreading as a means to achieve concurrency ? What are some advantages/disadvantages of using one approach over another.

Answer 1

It can't be used as an alternative to multithreading, it is a way of of implementing multithreading. There are three basic kinds of solutions here:

1. You are responsible for both ends of the queue;
2. You are responsible for sending data; or
3. You are responsible for receiving data.

Receiving data is the kicker here because there's really no way of doing that without some form of multithreading/multiprocessing otherwise you'll only be processing one request at a time. Sending data without multithreading is much more viable but there you're only really pushing the responsibility for dealing with those messages to an external system. So it's not an alternative to multithreading.

In your case with message driven beans, the container is creating and managing threads for you so it's not an alternative to multithreading, you're simply using someone else's implementation.