Java Reference
In-Depth Information
The EJB container automatically performs several setup tasks that a stand-alone client
must perform:
• Creating a message consumer to receive the messages. Instead of creating a mes-
sage 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.
• Registering the message listener. You must not call
setMessageListener
.
• Specifying a message acknowledgment mode. The default mode,
AUTO_ACKNOWLEDGE
, is used unless it is overridden by a property setting.
If JMS is integrated with the application server using a resource adapter, the JMS resource
adapter handles these tasks for the EJB container.
Your
message-driven
bean
class
must
implement
the
javax.jms.MessageListener
interface and the
onMessage
method.
It may implement a
@PostConstruct
callback method to create a connection, and a
@PreDestroy
callback method to close the connection. Typically, it implements these
methods if it produces messages or performs synchronous receives from another destina-
tion.
The
bean
class
commonly
injects
a
MessageDrivenContext
resource,
which
provides some additional methods you can use for transaction management.
The main difference between a message-driven bean and a session bean is that a message-
driven bean has no local or remote interface. Instead, it has only a bean class.
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.
Like a stateless session bean, a message-driven bean can have many interchangeable in-
stances 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 that would 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.
