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 ?
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:
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.
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
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.
