📄 jms7.html
字号:
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> <meta http-equiv="Content-Style-Type" content="text/css" /> <title>Using the JMS API in a J2EE Application</title> <link rel="StyleSheet" href="document.css" type="text/css" media="all" /> <link rel="StyleSheet" href="catalog.css" type="text/css" media="all" /> <link rel="Table of Contents" href="J2EETutorialTOC.html" /> <link rel="Previous" href="JMS6.html" /> <link rel="Next" href="JMS8.html" /> <link rel="Index" href="J2EETutorialIX.html" /> </head> <body> <table width="550" summary="layout" id="SummaryNotReq1"> <tr> <td align="left" valign="center"> <font size="-1"> <a href="http://java.sun.com/j2ee/1.4/download.html#tutorial" target="_blank">Download</a> <br> <a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/faq.html" target="_blank">FAQ</a> <br> <a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/history.html" target="_blank">History</a> </td> <td align="center" valign="center"><a accesskey="p" href="JMS6.html"><img id="LongDescNotReq1" src="images/PrevArrow.gif" width="26" height="26" border="0" alt="Prev" /></a><a accesskey="c" href="J2EETutorialFront.html"><img id="LongDescNotReq1" src="images/UpArrow.gif" width="26" height="26" border="0" alt="Home" /></a><a accesskey="n" href="JMS8.html"><img id="LongDescNotReq3" src="images/NextArrow.gif" width="26" height="26" border="0" alt="Next" /></a><a accesskey="i" href="J2EETutorialIX.html"></a> </td> <td align="right" valign="center"> <font size="-1"> <a href="http://java.sun.com/j2ee/1.4/docs/api/index.html" target="_blank">API</a> <br> <a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/search.html" target="_blank">Search</a> <br> <a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/sendusmail.html" target="_blank">Feedback</a></font> </font> </td> </tr> </table> <img src="images/blueline.gif" width="550" height="8" ALIGN="BOTTOM" NATURALSIZEFLAG="3" ALT="Divider"> <blockquote><a name="wp82114"> </a><h2 class="pHeading1">Using the JMS API in a J2EE Application</h2><a name="wp82118"> </a><p class="pBody">This section describes the ways in which using the JMS API in a J2EE application differs from using it in a standalone client application:</p><div class="pSmartList1"><ul class="pSmartList1"><a name="wp82119"> </a><div class="pSmartList1"><li>Using session and entity beans to produce and to synchronously receive messages</li></div><a name="wp82120"> </a><div class="pSmartList1"><li>Using message-driven beans to receive messages asynchronously</li></div><a name="wp82121"> </a><div class="pSmartList1"><li>Managing distributed transactions</li></div><a name="wp82122"> </a><div class="pSmartList1"><li>Using application clients and Web components</li></div><a name="wp88578"> </a><div class="pSmartList1"><li>Specifying deployment descriptors</li></div></ul></div><a name="wp82124"> </a><p class="pBody">A general rule new at J2EE version 1.4 applies to all J2EE components that use EJB or Web containers: </p><a name="wp88583"> </a><p class="pBodyRelative">Any component within an EJB or Web container must have no more than one JMS session per JMS connection.</p><a name="wp88582"> </a><p class="pBody">This rule does not apply to application clients.</p><a name="wp82130"> </a><h3 class="pHeading2">Using Session and Entity Beans to Produce and to Synchronously Receive Messages</h3><a name="wp82131"> </a><p class="pBody">A J2EE application that produces messages or synchronously receives them may use either a session bean or an entity bean to perform these operations. The example in <a href="JMSJ2EEex2.html#wp95588">A J2EE Application that Uses the JMS API with a Session Bean</a> uses a stateless session bean to publish messages to a topic.</p><a name="wp82135"> </a><p class="pBody">Because a blocking synchronous receive ties up server resources, it is not a good programming practice to use such a <code class="cCode">receive</code> call in an enterprise bean. Instead, use a timed synchronous receive, or use a message-driven bean to receive messages asynchronously. For details about blocking and timed synchronous receives, see <a href="JMS5.html#wp79947">Writing the Client Programs</a>.</p><a name="wp82142"> </a><p class="pBody">Using the JMS API in a J2EE application is in many ways similar to using it in a standalone client. The main differences are in administered objects, resource management, and transactions.</p><a name="wp82146"> </a><h4 class="pHeading3">Administered Objects</h4><a name="wp82147"> </a><p class="pBody">The J2EE Platform Specification recommends that you use <code class="cCode">java:comp/env/jms</code> as the environment subcontext for JNDI lookups of connection factories and destinations. With the J2EE Application Server, you use <code class="cCode">deploytool</code> to specify JNDI names that correspond to those in your source code.</p><a name="wp82148"> </a><p class="pBody">Instead of looking up a JMS API connection factory or destination each time it is used in a method, it is recommended that you look up these instances once in the enterprise bean's <code class="cCode">ejbCreate</code> method and cache them for the lifetime of the enterprise bean.</p><a name="wp82152"> </a><h4 class="pHeading3">Resource Management</h4><a name="wp82153"> </a><p class="pBody">JMS API resources are a JMS API connection and a JMS API session. In general, it is important to release JMS resources when they are no longer being used. Here are some useful practices to follow.</p><div class="pSmartList1"><ul class="pSmartList1"><a name="wp82154"> </a><div class="pSmartList1"><li>If you wish to maintain a JMS API resource only for the life span of a business method, it is a good idea to close the resource in a <code class="cCode">finally</code> block within the method.</li></div><a name="wp82155"> </a><div class="pSmartList1"><li>If you would like to maintain a JMS API resource for the life span of an enterprise bean instance, it is a good idea to use the component's <code class="cCode">ejbCreate</code> method to create the resource and to use the component's <code class="cCode">ejbRemove</code> method to close the resource. If you use a stateful session bean or an entity bean and you wish to maintain the JMS API resource in a cached state, you must close the resource in the <code class="cCode">ejbPassivate</code> method and set its value to <code class="cCode">null</code>, and you must create it again in the <code class="cCode">ejbActivate</code> method.</li></div></ul></div><a name="wp82157"> </a><h4 class="pHeading3">Transactions</h4><a name="wp82158"> </a><p class="pBody">Instead of using local transactions, you use <code class="cCode">deploytool</code> to specify container-managed transactions for bean methods that perform sends or receives, allowing the EJB container to handle transaction demarcation. </p><a name="wp82159"> </a><p class="pBody">You can use bean-managed transactions and the <code class="cCode">javax.transaction.UserTransaction</code> interface's transaction demarcation methods, but you should do so only if your application has special requirements and you are an expert in using transactions. Usually, container-managed transactions produce the most efficient and correct behavior. This tutorial does not provide any examples of bean-managed transactions.</p><a name="wp82163"> </a><h3 class="pHeading2">Using Message-Driven Beans</h3><a name="wp82164"> </a><p class="pBody">As we noted in <a href="EJBConcepts5.html#wp79967">What Is a Message-Driven Bean?</a> and <a href="JMS2.html#wp78426">How Does the JMS API Work with the J2EE Platform?</a>, the J2EE platform supports a special kind of enterprise bean, the message-driven bean, which allows J2EE applications to process JMS messages asynchronously. Session beans and entity beans allow you to send messages and to receive them synchronously but not asynchronously.</p><a name="wp82171"> </a><p class="pBody">A message-driven bean is a message listener that can reliably consume messages from a queue or a durable subscription. The messages may be sent by any J2EE component--from an application client, another enterprise bean, or a Web component--or from an application or a system that does not use J2EE technology.</p><a name="wp82173"> </a><p class="pBody">Like a message listener in a standalone JMS client, a message-driven bean contains an <code class="cCode">onMessage</code> method that is called automatically when a message arrives. Like a message listener, a message-driven bean class may implement helper methods invoked by the <code class="cCode">onMessage</code> method to aid in message processing.</p><a name="wp82174"> </a><p class="pBody">A message-driven bean differs from a standalone client's message listener in the following ways, however:</p><div class="pSmartList1"><ul class="pSmartList1"><a name="wp82175"> </a><div class="pSmartList1"><li>Setup tasks performed by the EJB container</li></div><a name="wp82176"> </a><div class="pSmartList1"><li>Interfaces and methods the bean class must implement</li></div></ul></div><a name="wp82177"> </a><p class="pBody">The EJB container automatically performs several setup tasks that a standalone client has to do:</p><div class="pSmartList1"><ul class="pSmartList1"><a name="wp93552"> </a><div class="pSmartList1"><li>Creating a message consumer to receive the messages. IInstead of creating a message consumer in your source code, you associate the message-driven bean with a destination and a connection factory at deployment time. If you want to specify a durable subscription or use a message selector, you do this at deployment time also.</li></div><a name="wp82179"> </a><div class="pSmartList1"><li>Registering the message listener. You must not call <code class="cCode">setMessageListener</code>.</li></div><a name="wp93156"> </a><div class="pSmartList1"><li>Specifying a message acknowledgment mode. (For details, see <a href="JMS7.html#wp92011">Managing Distributed Transactions</a>.)</li></div></ul></div><a name="wp93610"> </a><p class="pBody">If JMS is integrated with the application server using a resource adapter, the JMS resource adapter handles these tasks for the EJB container. It creates a connection factory for the message-driven bean to use. You use an activation configuration specification to specify properties for the connection factory, such as a durable subscription, a message selector, or an acknowledgment mode. See <a href="JMS7.html#wp89449">Specifying Activation Configuration Properties for Message-Driven Beans</a> for details. The examples in Chapter <a href="JMSJ2EEex.html#wp78297">30</a> show how the JMS resource adapter works in the J2EE 1.4 Application Server.</p><a name="wp93165"> </a><p class="pBody">Your message-driven bean class must implement the following, in addition to the <code class="cCode">onMessage</code> method:</p><div class="pSmartList1"><ul class="pSmartList1"><a name="wp82189"> </a><div class="pSmartList1"><li>The <code class="cCode">javax.ejb.MessageDrivenBean</code> and the <code class="cCode">javax.jms.MessageListener</code> interfaces</li></div><a name="wp82191"> </a><div class="pSmartList1"><li>The <code class="cCode">ejbCreate</code> method, which has the following signature:</li></div><a name="wp82192"> </a><p class="pBodyRelative"><code class="cCode">public void ejbCreate() {}</code></p><a name="wp82193"> </a><p class="pBodyRelative">If your message-driven bean produces messages or does synchronous receives from another destination, you use its <code class="cCode">ejbCreate</code> method to look up JMS API connection factories and destinations and to create the JMS API connection.</p><a name="wp82195"> </a><div class="pSmartList1"><li>The <code class="cCode">ejbRemove</code> method, which has the following signature:</li></div><a name="wp82196"> </a><p class="pBodyRelative"><code class="cCode">public void ejbRemove() {}</code></p><a name="wp82197"> </a><p class="pBodyRelative">If you used the message-driven bean's <code class="cCode">ejbCreate</code> method to create the JMS API connection, you ordinarily use the <code class="cCode">ejbRemove</code> method to close the connection.</p><a name="wp82200"> </a><div class="pSmartList1"><li>The <code class="cCode">setMessageDrivenContext</code> method. A <code class="cCode">MessageDrivenContext</code> object provides some additional methods that you can use for transaction management. The method has the following signature:</li></div><a name="wp82201"> </a><p class="pBodyRelative"><code class="cCode">public void setMessageDrivenContext(MessageDrivenContext <br /> mdc) {}</code></p></ul></div><a name="wp82206"> </a><p class="pBody">The main difference between a message-driven bean and other enterprise beans is that a message-driven bean has no home or remote interface. Instead, it has only a bean class.</p><a name="wp82207"> </a><p class="pBody">A message-driven bean is similar in some ways to a stateless session bean: its instances are relatively short-lived and retain no state for a specific client. The instance variables of the message-driven bean instance can contain some state across the handling of client messages: for example, a JMS API connection, an open database connection, or an object reference to an enterprise bean object.</p><a name="wp82208"> </a><p class="pBody">Like a stateless session bean, a message-driven bean can have many interchangeable instances running at the same time. The container can pool these instances to allow streams of messages to be processed concurrently. The container attempts to deliver messages in chronological order when this does not impair the concurrency of message processing, but no guarantees are made as to the exact order in which messages are delivered to the instances of the message-driven bean class. Because concurrency can affect the order in which messages are delivered, you should write your applications to handle messages that arrive out of sequence. </p><a name="wp95635"> </a><p class="pBody">For example, your application could manage "conversations" with application-level sequence numbers. An application-level conversation control mechanism with a persistent conversation state could cache later messages until earlier messages have been processed.</p><a name="wp95643"> </a><p class="pBody">Another way to ensure order is to have each message or message group in a conversation require a confirmation message that the sender blocks on receipt of. This forces the responsibility for order back on the sender and more tightly couples senders to the progress of message-driven beans.</p><a name="wp82212"> </a><p class="pBody">⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -