To
help you design your enterprise application, consider
a generic enterprise application that uses one message-driven bean
to retrieve messages from a JMS queue destination, and passes the
messages on to another enterprise bean that implements the business
logic.
About this task
To design an enterprise application to use message-driven
beans, complete the following steps:
Procedure
- Identify
the message listener interface for the message
type that the message-driven bean is to handle. The message-driven
bean class must implement this message listener interface. For example,
an EJB message-driven bean class used for JMS messaging must implement
the javax.jms.MessageListener interface.
- Identify the resources that the application is to use. This helps to identify the properties of resources that must
be used within the application and configured as application deployment
descriptors or within WebSphere® Application Server.
Table 1. JMS resource types and examples of their
properties. The left hand column of this table lists
the JMS resource types, and the right hand column shows examples of
the properties of each of the JMS resource types shown in the left
hand column.JMS resource type |
Properties (for example) |
JMS connection factory |
Name: SamplePtoPQueueConnectionFactory
JNDI Name: Sample/JMS/QCF
|
JMS destination |
Name: Q1
JNDI Name: Sample/JMS/Q1
|
J2C activation specification properties |
Name: MyMDBsActivationSpec
JNDI Name: eis/MyMDBsActivationSpec
Destination JNDI Name: MyQueue
Destination type: javax.jms.Queue
|
Message-driven
bean (deployment properties) |
Name: JMSppSampleMDBBean
Transaction type: Container
Message selector: JMSType='car'
Acknowledge mode: Dups OK Acknowledge
Destination type: javax.jms.Queue
ActivationSpec JNDI name: MyMDBsActivationSpec
|
Business logic bean |
Name: MyLogicBean
|
Ensure that you use consistent values
where
needed; for example, the JNDI name for the J2C activation specification
must be the same in both the activation specification and the Message-driven
bean deployment attributes.
- Separate out
the business logic. You should
develop a message-driven bean to delegate the business processing
of incoming messages to another enterprise bean. This provides clear
separation of message handling and business processing. This also
enables the business processing to be invoked by either the arrival
of incoming messages or, for example, from a WebSphere J2EE
client.
- Decide whether to configure security. Messages
arriving at a destination being processed by a listener have no client
credentials associated with them; the messages are anonymous. Security
depends on the role specified by the RunAs Identity for the message-driven
bean as an EJB component. For more information about EJB security,
see EJB component security.
- Understand how best effort nonpersistent messages are handled
by the default messaging provider.
If you
have a non-transactional message-driven bean, the system either deletes
the message when the message-driven bean starts, or when the message-driven
bean completes. If the message-driven bean generates an exception,
and therefore does not complete, the system takes one of the following
actions:
- If the system is configured to delete the message when the message-driven
bean completes, then the message is despatched to a new instance of
the message-driven bean, so the message has another opportunity to
be processed.
- If the system is configured to delete the message when the message-driven
bean starts, then the message is lost.
The message
is deleted when the message-driven bean starts if the quality of service
is set to Best effort nonpersistent. For all other
qualities of service, the message is deleted when the message-driven
bean completes.