is MessageDrivenBean no longer used from ejb3.0?

Question

In jms, we have MessageLister , onMesssage which receives messages. Then why we need MessageDrivenBean? Is this became obsolete? In javaee6 MDB api, they say from ejb 3.0, its not used. what is difference between mdb and jms ?

What is sychronous call in Jms ? is that response is returned back to caller immediately ? Are synchronous calls are guaranteed in Jms ?

Answer 1

First of all let's put a misunderstanding to rest: the EE6 Javadoc for the MessageDrivenBean interface states

As of EJB 3.0 it is no longer required that a message driven bean class implement this interface.

This is because as of EJB 3.0 you will typically use the @MessageDriven annotation to declare the MDB, and a @Resource annotation to obtain its MDC. Like this, from the official tutorial

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(propertyName = "destinationLookup",
            propertyValue = "jms/MyQueue"),
    @ActivationConfigProperty(propertyName = "destinationType",
            propertyValue = "javax.jms.Queue")
})
public class SimpleMessageBean implements MessageListener {

    @Resource
    private MessageDrivenContext mdc;
    static final Logger logger = Logger.getLogger("SimpleMessageBean");

Although quite often used together, MDBs and JMS are totally different things:

• MDBs are a programming model for asynchronous message receivers that fits well into the JavaEE programming landscape, and that shares important properties with the other EJB types, like transaction awareness.
• JMS is a messaging technology specification, ie the blueprint for a message oriented middleware.

MDBs could be used with other messaging technologies, and JMS can obviously be used outside of MDBs. The main point of using MDBs in a Java EE application is in my opinion the easy implementation of a message endpoint that can be transaction aware.

In synchronous messaging systems systems, the sending end will wait for a message to be delivered. In async systems however, the sender returns immediately without waiting for actual delivery to take place. This results in a much looser coupling between the two ends of the system, and zero risk that your sending side will lock up / slow down due to receiver failure or overload.