web server - Borland Technical Publications
web server - Borland Technical Publications web server - Borland Technical Publications
Chapter 20 20Message-Driven Beans and JMS Chapter Important For documentation updates, go to www.borland.com/techpubs/bes. JMS and EJB According to the EJB 2.0 specification, there are no limitations on a bean acting as a JMS message producer or synchronous consumer. It can use the regular JMS APIs to send a message to a queue or publish to a topic. As long as you perform synchronous style consumption of messages (that is, not based on javax.jms.MessageListener), then there are no problems on the consumption side either. The complexity lies in wanting the sending/receiving of the message to share the transaction context of some other piece of work. We already know how to solve this problem using JMS and JTA in conjunction. The EJBs demand no special treatment. Since EJB method invocations are synchronous, some calls will have to wait until the bean has completed its processing. This may include calling other beans, databases, and so forth. This RMI behavior can be undesirable in many situations. For example, you may just want to call the method and have it return before doing any heavy processing, allowing the caller to proceed with other tasks in the meantime. Threading in the client is an obvious way to achieve this, but it suffers from two problems: ■ ■ the client's programming model is not a true asynchronous style if the client is an EJB, threading is prohibited in its method implementations Chapter 20: Message-Driven Beans and JMS 183
Client View of an MDB Client View of an MDB The most desirable scenario is for an appclient, servlet, EJB, or other component to have the capability to fire a message using JMS APIs and then have an EJB be driven asynchronously by that message. In turn, that EJB can send a message to another EJB or perform direct data access or other business logic. The caller does not wait beyond the time the message is successfully queued. On the other side, the EJB can process the message at its convenience. This EJB's processing typically involves a unit of work made up of three operations: 1 dequeueing the message, 2 activating an instance and performing whatever work the business logic demands, and 3 optionally queuing a reply message back Enterprise systems require that it be possible to have transactional and other container-managed guarantees for this unit of work. EJB 2.0 Message-Driven Bean (MDB) The EJB 2.0 specification formalizes the integration between JMS and asynchronous invocation of enterprise beans by pushing these responsibilities to the EJB Container. This eases the burden on the developer, who now simply provides a class that is a JMS listener and also an EJB. This is done by implementing javax.jms.MessageListener and javax.ejb.MessageDrivenBean in the class. This and an XML descriptor containing all the deployment settings is all that the application programmer needs to provide. To the client, this EJB is nonexistent. The client simply publishes messages to the queue or topic. The EJB container associates the MDB with the published queue/topic and handles all lifecycle, pooling, concurrency, reentrance, security, transaction, message handling, and exception handling issues. Clients do not bind to an MDB like they do for session beans and entity beans. The client only needs to send a JMS message to the queue/topic to which the MDB is configured to listen. Typically clients also use the and elements of their deployment descriptor and then point to the same JNDI names as the MDB's and descriptor elements. See Chapter 23, “Using JMS” for information on how to configure your deployment descriptors. This being the case, there is no EJB metadata or handle of which the client needs to be aware. This is because there is no RMI client view of a Message Driven Bean. 184 BES Developer’s Guide
- Page 143 and 144: Container-Managed Persistence in Bo
- Page 145 and 146: Container-Managed Persistence in Bo
- Page 147 and 148: Container-Managed Persistence in Bo
- Page 149 and 150: Container-Managed Persistence in Bo
- Page 151 and 152: Container-Managed Persistence in Bo
- Page 153 and 154: 142 BES Developer’s Guide
- Page 155 and 156: Setting Properties J2EE 1.3 Entity
- Page 157 and 158: Setting Properties Figure 16.2 Edit
- Page 159 and 160: Setting Properties Table 16.1 ejb.m
- Page 161 and 162: Setting Properties Table 16.3 Table
- Page 163 and 164: Setting Properties Security Propert
- Page 165 and 166: Aggregate Functions in EJB-QL Selec
- Page 167 and 168: Support for ORDER BY Support for OR
- Page 169 and 170: Overriding SQL generated from EJB-Q
- Page 171 and 172: Container-managed data access suppo
- Page 173 and 174: 162 BES Developer’s Guide
- Page 175 and 176: Generating primary keys from a cust
- Page 177 and 178: Implementing primary key generation
- Page 179 and 180: Transaction manager services Consis
- Page 181 and 182: Transaction manager services When t
- Page 183 and 184: Transaction manager services Follow
- Page 185 and 186: Declarative transaction management
- Page 187 and 188: Declarative transaction management
- Page 189 and 190: JDBC API Modifications JDBC API Mod
- Page 191 and 192: Handling of EJB exceptions Applicat
- Page 193: 182 BES Developer’s Guide
- Page 197 and 198: Clustering of MDBs This is yet anot
- Page 199 and 200: Error Recovery Redelivered messages
- Page 201 and 202: 190 BES Developer’s Guide
- Page 203 and 204: JNDI Definitions Module Important s
- Page 205 and 206: Disabling and Enabling a Deployed D
- Page 207 and 208: Configuring JDBC Datasources In the
- Page 209 and 210: Configuring JDBC Datasources To add
- Page 211 and 212: Defining the Connection Pool Proper
- Page 213 and 214: Defining the Connection Pool Proper
- Page 215 and 216: Descriptions of Borland Enterprise
- Page 217 and 218: Advanced Topics for Defining JDBC D
- Page 219 and 220: Connecting to JDBC Resources from J
- Page 221 and 222: Configuring JMS Connection Factorie
- Page 223 and 224: Defining Connection Pool Properties
- Page 225 and 226: Obtaining JMS Connection Factories
- Page 227 and 228: JMS and Transactions and its accomp
- Page 229 and 230: JMS and Transactions For instance:
- Page 231 and 232: 220 BES Developer’s Guide
- Page 233 and 234: Configuring JMS administered object
- Page 235 and 236: Tibco Creating Clustered JMS Servic
- Page 237 and 238: Sonic serverUrl String localhost:72
- Page 239 and 240: Sonic Creating Clustered JMS Servic
- Page 241 and 242: OpenJMS Even though OpenJMS can be
- Page 243 and 244: OpenJMS Important If you use OpenJM
Client View of an MDB<br />
Client View of an MDB<br />
The most desirable scenario is for an appclient, servlet, EJB, or other component to<br />
have the capability to fire a message using JMS APIs and then have an EJB be driven<br />
asynchronously by that message. In turn, that EJB can send a message to another<br />
EJB or perform direct data access or other business logic. The caller does not wait<br />
beyond the time the message is successfully queued. On the other side, the EJB can<br />
process the message at its convenience. This EJB's processing typically involves a<br />
unit of work made up of three operations:<br />
1 dequeueing the message,<br />
2 activating an instance and performing whatever work the business logic demands,<br />
and<br />
3 optionally queuing a reply message back<br />
Enterprise systems require that it be possible to have transactional and other<br />
container-managed guarantees for this unit of work.<br />
EJB 2.0 Message-Driven Bean (MDB)<br />
The EJB 2.0 specification formalizes the integration between JMS and asynchronous<br />
invocation of enterprise beans by pushing these responsibilities to the EJB Container.<br />
This eases the burden on the developer, who now simply provides a class that is a<br />
JMS listener and also an EJB. This is done by implementing javax.jms.MessageListener<br />
and javax.ejb.MessageDrivenBean in the class. This and an XML descriptor containing<br />
all the deployment settings is all that the application programmer needs to provide.<br />
To the client, this EJB is nonexistent. The client simply publishes messages to the<br />
queue or topic. The EJB container associates the MDB with the published queue/topic<br />
and handles all lifecycle, pooling, concurrency, reentrance, security, transaction,<br />
message handling, and exception handling issues.<br />
Clients do not bind to an MDB like they do for session beans and entity beans. The<br />
client only needs to send a JMS message to the queue/topic to which the MDB is<br />
configured to listen. Typically clients also use the and <br />
elements of their deployment descriptor and then point to the same JNDI names<br />
as the MDB's and <br />
descriptor elements. See Chapter 23, “Using JMS” for information on how to configure<br />
your deployment descriptors.<br />
This being the case, there is no EJB metadata or handle of which the client needs to be<br />
aware. This is because there is no RMI client view of a Message Driven Bean.<br />
184 BES Developer’s Guide
Change language