Stateless Session Bean

<< Using Message-Driven Beans | Managing Distributed Transactions >>

Stateless Session Bean

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 does synchronous receives from another destination.

The bean class commonly injects a MessageDrivenContext resource, which provides some
additional methods that 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 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 it 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.

For example, your application could manage conversations by using 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.

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.

To create a new instance of a message-driven bean, the container does the following:

Instantiates the bean

Performs any required resource injection

Calls the @PostConstruct callback method, if it exists

To remove an instance of a message-driven bean, the container calls the @PreDestroy callback
method.

Using the JMS API in a Java EE Application

Chapter 31 · The Java Message Service API

957