One silly question !!!
Why do we need MDBs when we can have a Session or Entity bean which can implement the MessageListener interface and implement the onMessage() method ??
Interesting question. Here are some initial thoughts.
1) EntityBeans should by definition be object representations of data-like entities and mixing asynchronous functionality into an EntityBean sounds a bit suspicious.
2) MessageDrivenBeans must be stateless, SessionBeans can be stateful.
3) Stateless SessionBeans could be invoked both through a JMS queue/topic or a synchronous invocation, but then again, is it really that much of a trouble to have the MDB call the stateless SessionBean? Is it worth the extra complication caused into deployment descriptors? Maybe, maybe not.
I think it would be interesting to be able to define a component with two modes of access, but I don't regard this as a top priority for EJB 2.2 ...
Thanks Lasse for sharing your thoughts...
So, from your answer, I get the feeling that it is BAD design from the best practices point of view to have Session or Entity beans listening to messages. Otherwise, we could get the work done using Session and Entity beans rather than MDBs. I understand it now...
Let me know if I am wrong !!! I was reading the EJB Bible (Richard-Monson Haefel's book) and everytime, I keep getting strange and new questions....
Any more thoughts on this subject ???
another reason for MDB
what will happen if ur Session/Entity bean receives message notification when it is busy with other work. Since beans are not allowed to be multithreaded, u should wait until the Session/Entity bean completes its current work.
Sonu TheKool ,
MDB are active as soon as you deploy them in Application Server. So to keep them active you do not have to do anything. But for Session Bean you must take that they do not go for passivasion.