Designing an enterprise application to use message-driven beans

 


Overview

This page discusses a an app that uses one MDB to retrieve messages from a JMS queue destination, and then pass messages on to another enterprise bean that implements the business logic.

  1. Identify the JMS resources that the application is to use.

    This can be within the deployment descriptor or within the WAS console.

    JMS resource type Properties
    Queue connection factory

    Name: SamplePtoPQueueConnectionFactory
    JNDI Name: Sample/JMS/QCF
    
    
    Queue destination

    Name: Q1
    JNDI Name: Sample/JMS/Q1
    
    
    Listener port (for the destination)

    Name: SamplePtoPListenerPort
    Connection Factory JNDI Name: Sample/JMS/QCF
    Destination JNDI Name: Sample/JMS/Q1
    Maximum Sessions: 5
    Maximum Retries: 10
    Maximum Messages: 1
    
    
    Message-driven bean (deployment properties)

    Name: JMSppSampleMDBBean 
    Transaction type: Container
    Destination type: Queue
    Listener port name: SamplePtoPListenerPort
    
    
    Business logic bean

    Name: MyLogicBean
    
    


    Ensure that you use consistent values where needed; for example, the JNDI names for the connection factory and destination must be the same for both those resources and the equivalent properties of the listener port.

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

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

  4. General JMS considerations

    For Publish/Subscribe messaging, choose the JMS server port to be used depending on your needs for transactions or performance:

    Queued port

    The TCP/IP port number of the listener port used for all point-to-point and Publish/Subscribe support.

    Direct port

    The TCP/IP port number of the listener port used for direct TCP/IP connection (non-transactional, non-persistent, and non-durable subscriptions only) for Publish/Subscribe support.

    Message-driven beans cannot use the direct listener port for Publish/Subscribe support. Therefore, any topic connection factory configured with Portset to Direct cannot be used with message-driven beans.

    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.


Message-driven beans - an overview
Developing an enterprise application to use message-driven beans
Deploying an enterprise application to use message-driven beans
Using message-driven beans in applications

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.