The following tutorial illustrates how a Message Driven Bean is written and deployed in an Enterprise JavaBeansTM 2.0 Container. The Mdb component is invoked by an inbound message from a Java client. This function is demonstrated with a sample application run on Pramati Server 3.0 (Alpha). The Server ships with Pramati Message Server 1.0 and can be DOWNLOADed from www.pramati.com. The application sources are freely downloadable to get a better understanding of how MDB components are written and work.
A message driven bean is a stateless, server-side, transaction-aware component that is driven by a Java message (javax.JMS.message). It is invoked by the EJB Container when a message is received from a JMS Queue or Topic. It acts as a simple message listener.
A Java client, an enterprise bean, a Java ServerPagesTM (JSP) component, or a non-J2EE application may send the message. The client sending the message to the destination need not be aware of the MDBs deployed in the EJB Container. However, the message must confoRM to JMS specifications.
Before MDBs were introduced, JMS described a classical approach to implement asynchronous method invocation. The approach used an external Java program that acted as the listener, and on receiving a message, invoked a session bean method.
However, in this approach the message was received outside the application server and was thus not part of a transaction in the EJB Server. MDB solves this problem.
The EJB Container performs several tasks at the beginning of the life cycle of the MDB:
QueueReceiver or TopicSubscriber) to receive the messages
The lifecycle of an MDB depends on the lifespan of the EJB Server in which it is deployed. As MDBs are stateless, bean instances are typically pooled by the EJB Server and retrieved by the Container when a message becomes available on the topic or queue.
Writing an MDB involves the following tasks:
javax.ejb.MessageDrivenBean and javax.jms.MessageListener interfaces in the MDB class.onMessage().setMessageDrivenContext() method that associates the bean with its environment.ejbCreate() method that returns void and takes no arguments. This method may be blank.ejbRemove() method implementation. This method may be blank, unless certain resources need to be acquired before the bean goes out of SCOpe. The tutorial uses a sample application, StockTrader, to illustrate the writing of an MDB. The sample uses a simple message driven bean buyAgentMDB that is contacted by a client which wishes to buy shares. The client looks up the BuyQueue and implements the javax.jms.MessageListener. It provides a private method buy() that takes two arguments: a double value that holds the price and a string (stockSymbol) that holds the scrip symbol.
An MDB implements two interfaces: javax.jms.MessageListener and javax.ejb.MessageDrivenBean. The MDB class is defined as public and cannot be defined as abstract or final. The MDB class looks like this:
public class BuyAgentMDB implements MessageDrivenBean, MessageListener { private MessageDrivenContext mdbContext;
The class must consist of:
public void ejbCreate() with no argumentspublic void ejbRemove() usually used to free resources allocated in ejbCreate methodpublic void setMessageDrivenContext(MessageDrivenContext mdc) called by the EJB Container after the creation of the instance, without any transaction context The class must not contain the finalize method.
Business logic for the EJB is triggered by the onMessage() method of the MDB. The onMessage() is called by the Container when the JMS Queue or Topic receives a message. The onMessage() does not return any result and has one argument. The full JMS message object is passed as an argument.
The signature for the method is:
public void onMessage(Message msg) {}
In the sample, when there is a message on the BuyQueue, the onMessage() method of the BuyAgent picks up the message and sends it to the topic StockMarket. The StockRepository in turn looks up this topic.
The following code of the buyAgentMDB performs this function:
public void onMessage(Message msg) { // Retrieves the text message TextMessage priceMessage = (TextMessage) msg; try { } catch(JMSException ex) { ex.printStackTrace(); } }
The ejbCreate() is called at the time of bean instantiation, in order to allocate resources such as connection factories if the bean send messages or datasources, if the bean accesses databases. This method is invoked once in the lifecycle - when the bean is created.
The following code of the BuyAgentMDB performs this function:
public void ejbCreate () throws CreateException { }
The setMessageDrivenContext provides the methods for transaction management. The BuyAgentMDB implements setMessageDrivenContext. This method is called by the EJB Container to associate the BuyAgent instance. The context is maintained by the Container.
The input parameter for setMessageDrivenContext is an instance of the MessageDrivenContext interface. It gives the MDB access to information about the runtime environment.
In Container-managed transactions, de-queuing occurs out of the onMessage(). The only methods on the MessageDrivenContext that are accessible to the MDB are transaction-related methods.
This method is invoked when an MDB is being removed from a pool. Application server vendors may implement an arbitrary algorithm that decides when to remove the MDB instances from the pool.
The following code of the BuyAgentMDB performs this function:
public void ejbRemove() { //Removes the bean from the pool }
For MDBs that use container-managed transactions, the Container automatically acknowledges a message when the EJB transaction commits. The Container overrides the acknowledgement mode given in the deployment descriptor. If the EJB uses bean-managed transactions, both the receipt and the acknowledgement of a message occur outside the EJB transaction context.
Some business cases may require responding to the Sender of the message that triggered the MDB. To register the "reply to" destination of the Sender, the client can use getJMSReplyTo header.
The JMSReplyTo header field contains a destination supplied by the client along with the message. It is the destination where a "reply to the message" may be sent. Messages sent with a JMSReply value typically expect a response.
The code to use the JMSReplyTo header looks like this:
public void onMessage(Message msg){ try{ destination d = msg.getJMSReplyTo() } catch(JMSException jmse){} }
The destination associated with an MDB is specified in the deployment descriptor of the MDB in the ejb-jar.XML file. A destination is a JMS-administered object accessible via JNDI.
Here is a sample destination entry in the deployment descriptor:
The description of a MDB in the EJB 2.0 deployment descriptor contains the following specific elements:
The MDB deployment descriptor specifies whether the bean is intended for a Topic or a Queue. A bean set for a Topic can act as a durable subscriber guaranteeing that the listener receives all messages even if the listener is unavailable for some time. The deployment descriptor also sets transaction demarcation and security.
If the transaction type is "container", the transactional behavior of MDB methods is defined as for other enterprise beans in the deployment descriptor.
Here is the entry for the transaction type in the deployment descriptor:
For the onMessage method, only the Required or NotSupported transaction attribute must be used as there are no incoming transaction context.
The important thing to notice is that the deployment descriptor contains all the information except the destination name required to deploy a message-driven bean. The destination name is set in an application server's vendor-specific configuration file or as a system property (deploy time mapping).
By default, the following destinations are entered in the configuration file of the Message Server:
BuyQueue
SellQueue
StockMarket The configuration file is located in the directory[install_dir]/jms/config/jms-config.xml, where [install_dir] is the installation directory of Pramati Server 3.0.
The following steps will deploy the application on Pramati Server:
runadmin.sh from the Server installation directory.
Server > Start from the main menu. This brings up the Start Server dialog where the J2EE Server to start is identified. Check the Start JMS Server option to start the Message Server along with the J2EE Server. This is essential to be able to run the message driven beans.
When the Server starts, click on the Deploy button in the view panel of the Console to start the Deploy Tool.
Select Archive > Open and open the application stockapp.ear from the following location:
[install_dir]/samples/mdb/
where[install_dir] is the installation directory of Pramati Server 3.0.
Deploy the application.
Set the classpath as follows:
WindowsRun the file
run.batfrom the directory[install_dir]/samples/mdb
Add the following location of the application classes to the client classpath:
[install_dir]/server/samples/mdb/classes
where[install_dir]is the installation directory of Pramati Server 3.0.Unix
export CLASSPATH=$install_root/server/samples/mdb/classes:%$CLASSPATH
The stock repository is run by the client StockServer.java. Start the client by executing:
java com.pramati.samples.mdb.StockServer
This brings up the stock repository panel which displays the scrip and the price along with a Buy/Sell advisory message.
Observe the price fluctuates every time buying or selling happens.
MDBs overcome the limitations of synchronous messaging using session and entity beans in the EJB 1.1 container. MDBs can be deployed in the EJB 2.0 Container, which acts as a message listener and uses inbound messages as a trigger to invoke business methods in an asynchronous manner.
This tutorial outlined the steps involved in writing an MDB using a sample application that may be downloaded from www.pramati.com.
For further information, contact Mailto:support@pramati.com">support@pramati.com.
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
