Hello dear friends. In this video, we will examine the Message-Driven Beans. So, 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. MDB is a 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 message listener, which is similar to an event listener, but receives JMS messages instead of events. The messages can be sent by any Java EE component or by a JMS application or 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 message-driven beans and session beans is that clients do not access message-driven beans through interfaces. Unlike a session bean, a message-driven bean has only a bean class. In several respects, a message-driven bean resembles a stateless session bean. A message-driven bean's 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 pull 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 bean's destination during deployment by using GlassFish server resources. Message-driven beans are 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 cast the message to one of the five JMS message types and handles it in accordance with the application's 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; non-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 bean's 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, but we haven't looked at JMS yet. So, for the time being, it will do for message-driven. So, now we're done with the EJB topic. So, until the next video, take care my friends.