+

Search Tips   |   Advanced Search

 

Designing an enterprise application to use message-driven beans

 

This topic describes things to consider when designing an enterprise application to use message-driven beans.

 

Overview

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...

 

Procedure

  1. 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.

     

  2. Optional: To handle messages at a scheduled date and time, or after a specified interval has elapsed, identify the schedule values and the business logic to react to time-based messages. A message-driven bean can be registered with the EJB timer service for time-based event notifications. When a message arrives on the destination, a message-driven bean timer is initiated. When the timer expires, a message-driven bean is selected to process the ejbTimeout() method, which implements the business logic that is to process the message.

  3. Identify the resources that the application is to use. This helps to identify the properties of resources that need to be used within the application and configured as application deployment descriptors or within WAS.

    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's deployment properties.

  4. Separation of business logic. You 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.

  5. 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. For more information about EJB security, see EJB component security.

  6. Topic durability considerations. A non-durable subscriber can only be used in the same transactional context (for example, a global transaction or an unspecified transaction context) that existed when the subscriber was created. For more information about this context restriction, see The effect of transaction context on non-durable subscribers.

  7. Discarding of best-effort non-persistent messages with the default messaging provider. If you configure a JMS destination (queue or topic) to use the default messaging provider, you can configure the maximum reliability of messages on the bus destination to which the JMS destination is assigned.For non-transactional JMS message-driven beans and MessageListeners that use a JMS destination configured on the default messaging provider, best-effort nonpersistent messages are not recoverable. In this case, if a message is unlocked because the message-driven bean or MessageListener threw an exception, then the message is not redelivered or sent to the exception destination because it was deleted from the message store when it was passed to the listener. If you want better message reliability for non-transactional JMS message-driven beans and MessageListeners, you should configure a different option for the Maximum reliability property of the bus destination.


 

Related concepts


Message-driven beans - automatic message retrieval

 

Related tasks


Developing an enterprise application to use message-driven beans
Deploying an enterprise application to use message-driven beans against JCA 1.5-compliant resources
Programming to use message-driven beans