Designing an enterprise application to use message-driven beans
This page describes things to consider when designing an enterprise application to use message-driven beans.
The considerations in this topic are based on 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.
To design an enterprise application to use message-driven beans...
- Identify the message listener interface for the message type that the message-driven beans is to handle. The message-driven bean class must implement this message listener interface. For example, an EJB 2.1 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 WAS.
Table 1. JMS resource types and examples of their properties
JMS resource type Properties (for example) JMS connection factory Name: SamplePtoPQueueConnectionFactoryJNDI Name: Sample/JMS/QCF
JMS destination Name: Q1JNDI Name: Sample/JMS/Q1
J2C activation specification properties Name: MyMDBsActivationSpecJNDI Name: eis/MyMDBsActivationSpec
Destination JNDI Name: MyQueue
Destination type: javax.jms.Queue
Message-driven bean (deployment properties) Name: JMSppSampleMDBBeanTransaction 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 spec and the Message-driven bean's deployment properties.
- Separation of business logic. we are recommended to 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.
- Security considerations. 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.
See about EJB security, see EJB component security.
- Discarding of best effort nonpersistent messages with the default messaging provider. If we have a non-transactional message-driven bean, the system either deletes the message when the bean starts, or when the bean completes. If the 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 bean completes, then the message is despatched to a new instance of the bean, so the message has another opportunity to be processed.
- If the system is configured to delete the message when the bean starts, then the message is lost.
The message is deleted when the 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 bean completes.
 
Related concepts
Message-driven beans - automatic message retrieval
Related tasks
Develop an enterprise application to use message-driven beans
Deploy an enterprise application to use message-driven beans against JCA 1.5-compliant resources
Deploy an enterprise application to use EJB 2.0 message-driven beans with listener ports
Programming to use message-driven beans