+

Search Tips   |   Advanced Search

Design an enterprise application to use message-driven beans

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.

To design an enterprise application to use message-driven beans:


Tasks

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

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

  3. Separate out the business logic. We 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.
  4. 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.

  5. Understand how best effort nonpersistent messages are handled by the default messaging provider.

    If we 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 dispatched 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.


Related:

  • Message-driven beans - automatic message retrieval
  • Developing an enterprise application to use message-driven beans
  • Deploy an enterprise application to use message-driven beans with JCA 1.5-compliant resources
  • Deploy an enterprise application to use message-driven beans with listener ports
  • Secure enterprise bean applications

    IBM MQ library