O'Reilly - Java Message Service

Java Message Service
Although session, entity, and web components can all act as JMS producers, these
components can only consume JMS messages synchronously using the
MessageConsumer.receive( ) methods. Calling one of the receive( ) methods causes the
JMS client to pole the queue or topic and wait for a message. [1] These methods are used to
consume messages synchronously, while MessageListener objects are used to consume
messages asynchronously.
[1] It's recommended that the component developer use the nonblocking method, receiveNoWait(
), to conserve resources and avoid blocking. Unrestricted blocking is not limited to any length of
time, and is therefore risky.
Only the message-driven bean and application client components can both produce and
consume asynchronous messages. The web, session, and entity components cannot act as
asynchronous JMS consumers because they are driven by synchronous request-reply
protocols, not asynchronous messages. Web components respond to HTTP requests while
entity and session beans respond to Java RMI-IIOP requests.
The fact that neither web components nor session and entity beans can asynchronously
consume JMS messages was one of the things that led to development of the messagedriven
bean. The message-driven bean provides J2EE developers with a server-side JMS
consumer that can consume asynchronous messages, something they didn't have before
EJB 2.0.
8.4 The New Message-Driven Bean in EJB 2.0
While most JMS vendors provide the message-brokering facilities for routing messages
from producers to consumers, the responsibility for implementing JMS clients is left to the
application developer. In many cases the JMS clients that consume and process messages
need a lot of infrastructure in order to be robust, secure, fault-tolerant, and scalable. JMS
clients may access databases and other resources, use local and distributed transactions,
require authentication and authorization security, or need to process a large load of
concurrent messages. Fulfilling these needs is a tall order, requiring that a significant
amount of work be done by the application developer. In the end, the kind of infrastructure
needed to support powerful JMS consumers is not unlike the infrastructure needed for
session and entity beans, which can produce but not consume messages asynchronously. [2]
[2] Entity and session beans can technically consume JMS messages synchronously by polling the
destination using the MessageConsumer.receive( ) methods.
In recognition of this need, EJB 2.0 now includes the MessageDrivenBean type, which can
consume JMS messages, and process them in the same robust component-based
infrastructure that session and entity beans enjoy. The MessageDrivenBean type (messagedriven
bean) is a first-class enterprise bean component that is designed to consume
asynchronous JMS messages. Like stateless session beans, message-driven beans don't
maintain state between requests; they may also have instance variables that are maintained
throughout the bean instance's life, but that may not store conversational state. Unlike all
other bean types, a message-driven bean does not have a remote or home interface,
because the message-driven bean is not an RPC component. It does not have business
methods that are invoked by EJB clients. A message-driven bean consumes messages
delivered by other JMS clients through a message server.
128