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, complete the following steps:

  1. Identify the JMS 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 WebSphere Application Server.

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

  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.

    Note: 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. For more information about this context restriction, see The effect of transaction context on non-durable subscribers.

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