Guidelines: Identifying Message-Driven Beans
Topics
Introduction
This guideline focuses on identifying Message-Driven Beans. Additional guidance
on Message-Driven Beans is provided in Guidelines:
Message-Driven Beans. General guidance on EJBs is provided by Guidelines:
Enterprise JavaBeans.
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 Guidelines:
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 Activity: 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 Guidelines: 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 Guidelines:
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.
|