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 ?

Mcalpine

had the same question, I've found this interesting -- theserverside.com/news/thread.tss?thread_id=32105 – Camaraderie

Answer 1

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?

Whiffler

I'll add that MDBs are not necessarily asynchronous, it's really the Connector that drives the communication style. MDBs were born out of JMS and the Connector API was abstracted from that use case, but now the Connector/MDB relationship actually allows for any kind of communication. I have some ideas for EJB.next to further simplify the MDB/Connector relationship so that the Connector can supply it's own annotations that the MDB can use, making @ActivationConfig and the need for an explicit MessageListener interface irrelevant. Then things like JAX-RS could be done as a Connector/MDB. – Hydrochloride

@David That's right (I simplified considerably). And what you're mentioning is a very interesting direction. Thank you very much for sharing this, David. – Whiffler

Yeah, I'm kind of excited about it. Have been meaning to carve it out in a blog post, but since we're chatting I finally bit the bullet and did so bit.ly/bym3SC On a further side note, the whole "which bean type do I use" question is one I hope we can kill by basing everything on @ManagedBean and freeing people up to focus on the services they want to use and how they want their bean exposed. – Hydrochloride

Answer 2

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

Gautea

Answer 3

Both Serves Different purpose.

1) if you want to use it for just remote methods usage then just use Session Bean

2) but if responce/result not maters but the later message is mater to you then go for the JMS as it is creating the queue to make it work and to set the message. but perfomance issue will be there.

if u need to have just method usage then just use Session bean as it is light weight bean. and it is giving good performance.

Danforth