Introduction

This guideline focuses on identifying Message-Driven Beans. Additional guidance on Message-Driven Beans is provided in Guideline: Message-Driven Bean General guidance on EJBs is provided by Guideline: Enterprise JavaBean (EJB).

Some characteristics of message-driven beans are:

• They are stateless.
• They do not return values or exceptions to clients.
• They do not have interfaces, as clients do not access message driven beans directly, but indirectly by sending messages to the destination (or endpoint) serviced by the bean. There is one listener method ("onMessage()" in case of JMS message-driven bean) which generically handles any message. This means that type checking has to be performed at run-time, using the "instanceOf()" operation to determine the type of a message received.

Messages can be sent to the container from anywhere, including from other EJBs, Web components, and application clients. The container invokes message-driven EJBs, as needed, to handle the incoming message events. Message-driven EJBs can access other session or entity EJBs, or the EIS tier directly to process messages.

Identifying Message-Driven Beans

Message-driven beans provide a way to handle messages asynchronously. Session and Entity beans can only be invoked synchronously. Message-driven beans are identified as part of defining concurrency for the overall system. See Guideline: Concurrency for general guidelines on concurrency, such as design patterns for decoupling caller and called code. Message-driven beans are typically identified as part of Task: Describe the Run-time Architecture as a means of providing concurrency within the EJB container. As such, they are generally not directly identified from analysis classes, but rather are identified to resolve specific design issues, such as performance and coupling concerns.

Some reasons to introduce message-driven beans include:

• Separate concerns between different areas of the software - can send a message to a queue without being coupled to the consumer of those messages. Can also support multiple senders and receivers.
• Increase performance by allowing the message sender to perform processing instead of being blocked on a synchronous call (such as occurs on an invocation of an Entity or Session bean).
• Increased reliability by allowing the message sender to continue to function even if the message consumers are offline.
• Other advantages may be offered by the message-oriented middleware (MOM) behind the messaging interface - such as guaranteed message delivery.
• There is an existing design element (such as a legacy system) that uses messaging to communicate.
  

Modeling Message-Driven Beans

See Guideline: Identifying Enterprise JavaBeans (EJBs) for general guidance on modeling EJBs. Note, however, that message-driven beans are generally modeled as part of the Process View. For specific guidance on modeling message-driven beans in the Process View, refer to Guideline: Describing the Run-Time Architecture for J2EE Applications.

Returning Results to Message Senders

Message-driven beans cannot directly send responses to the message sender.

A typical strategy for sending a response is to introduce another destination or endpoint for responses. See [ROM02] for additional details on this strategy.