Hello, dear friends. In this video, we will examine the Message-Driven Beans. Let's begin. A Message-Driven Bean is an Enterprise Bean that allows Java EE applications to process messages asynchronously. A Message-Driven Bean as MDB is an asynchronous consumer that is invoked by the container as a result of the arrival of a message. To a message producer, an MDB is simply a message consumer hidden behind a destination to which it listens. MDBs are not part of the EJB specification and their model is close to stateless Session Beans as they do not have any state and run inside an EJB container. The container listens to a destination and delegates the call to the MDB upon message arrival. Like any other EJB, MDBs can access resources managed by the container. This type of Bean normally acts as a JMS MessageListener, which is similar to an EventListener but receives JMS messages instead of events. The messages can be sent by any Java EE component or by a JMS application or a system that does not use Java EE technology. Message-Driven Beans can process JMS messages or other kinds of messages.

MDB asynchronously receives the message and processes it. The most visible difference between MessageDriven Beans and Session Beans is that the clients do not access Message-Driven Beans through interfaces. Unlike a Session Bean, a Message-Driven Bean only has a Bean class. In several respects, a Message-Driven Bean resembles a stateless Session Bean. A Message-Driven Beans instances retain no data or conversational state for a specific client. All instances of a Message-Driven Bean are equivalent allowing the EJB container to assign a message to any Message-Driven Bean instance. The container can pool these instances to allow streams of messages to be processed concurrently. A single Message-Driven Bean can process messages from multiple clients. Client components do not locate Message-Driven Beans and invoke methods directly on them. Instead, a client accesses a Message-Driven Bean through, for example, JMS by sending messages to the message destination for which the Message-Driven Bean class is the message listener. You assign a Message-Driven Beans destination during deployment by using Glassfish server resources.

Message-Driven Bean's relatively short-lived and do not represent directly shared data in the database, but they can access and update this data. They are stateless. When a message arrives, the container calls the Message-Driven Beans onMessage method to process the message. The onMessage method normally casts the message to one of the five JMS message types and handles it in accordance with the applications business logic. The onMessage method can call helper methods or can invoke a Session Bean to process the information in the message or to store it in a database. A message can be delivered to a Message-Driven Bean within a transaction context. So, all operations within the onMessage method are part of a single transaction. If message processing is rolled back, the message will be delivered. Now, let's examine the lifecycle of MDB. Like a stateless Session Bean, a Message-Driven Bean is never passivated and has only two states; none existent, and ready to receive messages. The EJB container usually creates a pool of Message-Driven Bean instances. For each instance, the EJB container performs these tasks. If the Message-Driven Bean uses dependency injection, the container injects these references before instantiating the instance.

The container calls the method annotated postConstruct, if any. At the end of the lifecycle, the container calls the method annotated preDestroy, if any. The Beans instance is then ready for garbage collection. Now, let's look at the code snip. For MDB, we only require a message-driven annotation. For the time being, I won't explain MDB. We need some information regarding JMS in order to learn more. However, we haven't yet looked at JMS. So, for the time being, it will do for message-driven. We are now done with the EJB topic. In the next video, we will start to solve topic questions. Until the next video, take care.