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

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.