Design an enterprise application to use message-driven beans

This topic 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, complete these 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 WAS.

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