[Enterprise Extensions only]

An overview of the extended messaging service

WebSphere enterprise applications can use the extended messaging service to automatically receive messages from input queues (JMS destinations) and to coordinate the processing of those messages. This enables automatic asynchronous delivery of messages to an enterprise application, instead of the application having to explicitly poll for messages on the queue. The extended messaging service is shown in the figure [Message handling by the extended messaging service].

The extended messaging service comprises a listener manager, which controls and monitors one or more JMS listeners. Each JMS listener monitors an input queue (a JMS destination) for incoming messages. When a message arrives on the input queue, the JMS listener passes the message to a user-developed message bean (EJB) for processing. You are recommended to develop a message bean to delegate the business processing of incoming messages to another EJB, to provide 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 EJB client. Responses can be handled by another EJB acting as a sender bean, or handled in the message bean. Optionally, this process can happen within the scope of a transaction.


Message handling by the extended messaging service

Message handling by the extended messaging service. This figure shows an incoming message being passed by a JMS listener to a message bean, which passes the message on to a business logic bean for business processing. For more information, see the text that accompanies this figure.

The operation of the extended messaging service is controlled by an XML configuration file, which you edit to specify properties of the service; for example, the identities of JMS destinations that are to be monitored, the transactional requirements, and the name of the Enterprise JavaBean to process messages. When an application server is started, it initializes the JMS listener manager based on the enterprise services XML configuration file. The listener manager creates a dynamic session thread pool for use by JMS listeners, creates and starts JMS listeners based upon the XML configuration file, and during server termination controls the cleanup of resources. Each JMS listener completes several steps for the JMS destination that it is to monitor, including:

You can update the configuration file at any time, but if it is updated, the updates only take effect when the server is next started.

The message bean is implemented as a stateless session bean. In a future version of WebSphere, the message bean is to be re-implemented as a J2EE message-driven bean.