user manual

214 BES Developers Guide
Client View of an MDB
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.
Client View of an MDB
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 <resource-ref> and
<resource-env-ref> elements of their deployment descriptor and then point to
the same JNDI names as the MDB's <connection-factory-name> and <message-
driven-destination-name> 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.