MessageDriven Bean MDB What Makes MessageDriven Beans Different

Message-Driven Bean [ MDB ]

What Makes Message-Driven Beans Different from Session and Entity Beans? The most visible difference between message-driven beans and session and entity beans is that clients do not access message-driven beans through interfaces.

When to Use Message-Driven Beans • Session beans and entity beans allow you to send JMS messages and to receive them synchronously, but not asynchronously. • To avoid tying up server resources, you may prefer not to use blocking synchronous receives in a server-side component. • To receive messages asynchronously, use a messagedriven bean.

Message-Driven Bean • MDB is designed for clients to invoke server-side business logic using asynchronous communication, which is a special case of a stateless session bean. • Note: There isn’t any home interface or remote interface for a MDB. • MDB monitors Java Message Service communications and reacts to messages sent by clients. • Clients don’t directly access a MDB.

• The MDB intercedes and processes requests anonymously. This is possible because MDB is stateless. • The EJB container can begin a new instance of the MDB when the message is received or use an existing instance of the MDB from the instance pool. Note: Unlike a session bean or entity bean, a client does not control the life of an MDB. • The EJB container handles the responsibility for creating and removing an MDB.

• Requests from clients are sent via JMS. • The EJB container listens for messages in the JMS service that MDBs are registered to receive. • The developer must provide all the logic to process a message in the on. Message() method. • The JMS service enables the client and MDB to work independently and without having to wait until the other is finished processing.

• An MDB processes a client request by using business methods defined in the MDB and by invoking business methods defined in other EJBs. • An advantage of using an MDB is that the EJB container does most of the work. • The EJB container acts as the intermediary between JMS service and the MDB.

• The EJB container makes a connection to the JMS service and registers to receive JMS messages that have a particular JMS Topic or that are on a particular JMS message Queue, depending on if a client uses JMS topics or a JMS message queue to send a request for service. • The EJB container then creates a Topic. Subsriber object or Queue. Receiver object, depending on how JMS messages are handled by the JMS server. • The Topic. Subscriber object or Queue. Receive object is then used to receive JMS messages from clients.

• The EJB container knows which receiver object to create because the receiver object is specified in the MDB deployment descriptor. • The EJB container also registers the message listener and sets the message acknowledge mode to respond to the JMS server when a JMS message is received by the EJB container. • NOTE: All this occurs behind the scenes without the MDB developer needing to write additional code in the MDB.

The Life Cycle of a Message-Driven Bean Figure: illustrates the stages in the life cycle of a message-driven bean. The EJB container usually creates a pool of message-driven bean instances. For each instance, the EJB container instantiates the bean and performs these tasks: 1. It calls the set. Message. Driven. Context method to pass the context object to the instance. 2. It calls the instance's ejb. Create method. Figure 3 -6 Life Cycle of a Message-Driven Bean

Creating an MDB An MDB must define four methods: 1. ejb. Create() : is called when the MDB is created by the container first invoked by the EJB container, but not when a JMS message is received from a client. 2. ejb. Remove(): is called by the EJB container when the container terminates the instance of the MDB. 3. set. Message. Driven. Context(): creates the context for the MDB, which is similar to the session and entity context classes.

4. on. Message(): is called each time the EJB container receives a JMS message from a client. The on. Message() method is where the MDB processes messages received indirectly from a client. Any type of stateless process can be included in this method.

• A skeleton of an MDB import javax. ejb. Message. Driven. Bean; import javax. ejb. Message. Driven. Context; import javax. jms. Message. Listener; import javax. jms. Message; public class my. MDB implements Message. Listener, Message. Driven. Bean { public void set. Message. Driven. Context(Message. Driven. Context mdc) {} public void ejb. Create(){} public void ejb. Remove(){} public void on. Message(Message client. Message){} }

• An on. Message() method displays the message received from a client public void on. Message(Message client. Message){ Text. Message tmp. Mesg = null; try{ if(client. Message instanceof Text. Message) { tmp. Mesg = (Text. Message) client. Message; System. out. println(“Incoming Message: ”+tmp. Mesg. get. Text()); } else {System. out. println(“Incorrect Message: ”+client. Message. get. Class(). get. Name()); } } catch(JMSException error) { System. out. println(“Error: ”+error. get. Message()); } }

The JAR File: o EJB classes & related files are packaged together into a Java Archive (JAR) file for deployment. o The JAR file is a compressed file format that was originally designed to reduce the size of software so it could be easily be transported. o The JAR file used to package an EJB must contain the following: o o o o EJB classes Dependent classes Remote interface Home interface Dependent interfaces Primary key class Deployment descriptor NOTE: In addition, the deployment descriptor must be located in the META-INF/ejb-jar. xml path.

If Any clarification feel free to contact AND Best up luck for your Exams Thank You……. . ☻☻☻☻☻