Message-Driven Bean

What Is a Message-Driven Bean?

A message-driven bean is an enterprise bean that allows J2EE applications to process messages asynchronously. It normally acts as a JMS message listener, which is similar to an event listener except that it receives JMS messages instead of events. The messages can be sent by any J2EE component--an application client, another enterprise bean, or a web component--or by a JMS application or system that does not use J2EE technology. Message-driven beans can process either JMS messages or other kinds of messages.

For a simple code sample, see Chapter 28. For more information about using message-driven beans, see Using the JMS API in a J2EE Application and Chapter 34.

What Makes Message-Driven Beans Different from Session and Entity Beans?

The most visible difference between message-driven beans and session and entity beans is that clients do not access message-driven beans through interfaces. Interfaces are described in the section Defining Client Access with Interfaces. Unlike a session or entity bean, a message-driven bean has only a bean class.

In several respects, a message-driven bean resembles a stateless session bean.

A message-driven bean's instances retain no data or conversational state for a specific client.
All instances of a message-driven bean are equivalent, allowing the EJB container to assign a message to any message-driven bean instance. The container can pool these instances to allow streams of messages to be processed concurrently.
A single message-driven bean can process messages from multiple clients.

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.

Client components do not locate message-driven beans and invoke methods directly on them. Instead, a client accesses a message-driven bean through JMS by sending messages to the message destination for which the message-driven bean class is the MessageListener. You assign a message-driven bean's destination during deployment by using Application Server resources.

Message-driven beans have the following characteristics:

They execute upon receipt of a single client message.
They are invoked asynchronously.
They are relatively short-lived.
They do not represent directly shared data in the database, but they can access and update this data.
They can be transaction-aware.
They are stateless.

When a message arrives, the container calls the message-driven bean's onMessage method to process the message. The onMessage method normally casts the message to one of the five JMS message types and handles it in accordance with the application's business logic. The onMessage method can call helper methods, or it can invoke a session or entity bean to process the information in the message or to store it in a database.

A message can be delivered to a message-driven bean within a transaction context, so all operations within the onMessage method are part of a single transaction. If message processing is rolled back, the message will be redelivered. For more information, see Chapter 28.

When to Use Message-Driven Beans

Session beans and entity beans allow you to send JMS messages and to receive them synchronously, but not asynchronously. To avoid tying up server resources, you may prefer not to use blocking synchronous receives in a server-side component. To receive messages asynchronously, use a message-driven bean.

评论

1 楼 VerRan 2007-09-05  

One great benefit of EJB is that you don’t need to write thread-safe code. You
design your enterprise beans as single-threaded components and never need to
worry about thread synchronization when concurrent clients access your
component. In order to service concurrent client requests, your EJB container
automatically instantiates multiple instances of your component.
The container’s thread services can be both a benefit and a restriction. The
benefit is that you don’t need to worry about race conditions or deadlock in
your application code. The restriction is that some problems lend themselves
well to multithreaded programming, and that class of problems cannot be
easily solved in an EJB environment.
So why doesn’t the EJB specification allow for multithreaded beans? EJB is
intended to relieve the component developers’ worry about threads or thread
synchronization. The EJB container handles those issues for you by load
balancing client requests to multiple instances of a single-threaded component.
An EJB server provides a highly scalable environment for single-threaded
components.
If the EJB specification allowed for beans to control threads, a Pandora’s box
of problems would result. For example, an EJB container would have a very
hard time controlling transactions if beans were randomly starting and
stopping threads, especially because transaction information is often
associated with a thread.
The bottom line is that EJB was not meant to be a Swiss army knife, solving
every problem in existence. It was designed to assist with server-side business
problems, which are largely single-threaded. For applications that absolutely
must be multithreaded, EJB may not be the correct choice of distributed object
architectures.