user manual

Chapter 20: Message-Driven Beans and JMS 213
Chapter
20
Chapter 20Message-Driven Beans and JMS
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
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