Why not use Session Beans instead of Message Driven Beans ?

Question

I'm wondering, why not use Session Beans instead of Message Driven Beans ?

If you can call remote methods from EJBs, so why bother sending/receiving messages with Message Driven Beans (which is more difficult to develop than session beans) ?

In which scenarios Message Driven Beans become useful ?

Answer 1

Message driven beans listen to JMS queues asynchronously unlike entity/session beans.

This does not block server resources as the processing happens only when the message has arrived on the queue.

Other than loads of Java forums and sites, Wikipedia has a good set of usecases where MDBs come in handy

http://en.wikipedia.org/wiki/Enterprise_JavaBean#Message_driven_beans

Answer 2

I'm wondering, why not use Session Beans instead of Message Driven Beans ?

Hmm, they don't serve the same purpose, message-driven beans allow Java EE applications to process messages asynchronously.

If you can call remote methods from EJBs, so why bother sending/receiving messages with Message Driven Beans (which is more difficult to develop than session beans) ?

Because MDBs give you asynchronism and loose coupling, which is something you might want/need in some situations:

• for long running jobs
• when resources are not always available
• when you want to parallelize processing

By the way, I've personally always found MDBs to be the easiest Enterprise Beans to develop.

In which scenarios Message Driven Beans become useful ?

See above.

See also

• What Is a Message-Driven Bean?