Designing an enterprise application to use extended messaging

This topic describes things to consider when designing an enterprise application to use extended messaging.

Why and when to perform this task

The design of JMS-usage for applications that use extended messaging is the same as the design for JMS and message-driven beans, except that the JMS-usage is simplified because JMS support is managed by the extended messaging service. For design considerations related to JMS and message-driven beans, see the following topics:

The extra design consideration for applications that use extended messaging are as follows. For more detail, see the related topics.

Steps for this task

  1. For a receiver bean, decide whether to use a message-driven bean or stateless session bean.
    Message-driven bean
    You can use a deployed message-driven bean as a receiver bean, to automatically handle messages received at the associated listener port. As with any message-driven bean, when a message is received on the JMS destination monitored by the listener port, the message is passed to the onMessage() method of the message-driven bean.

    You need to develop and deploy the message-driven bean, and configure its associated listener port, separately from the extended messaging tasks.

    Stateless session bean
    You can use a stateless session bean as a receiver bean, to poll for messages on a named destination associated with an input port.

    You need to develop and deploy the session bean separately from the extended messaging tasks, but configure the associated input port as part of the extended messaging tasks.

  2. Decide whether or not you want to use data mapping.
    If you call the methods of sender and receiver beans with data arguments, you need to use data mapping to construct the JMS messages needed. For data mapping, you need to decide what data arguments need to be specified as properties on the sender or receiver bean method signatures.

    For a receiver bean deployed as a message-driven bean, you can define the mapping behavior if a data exception is caught by extended messaging. That is, you define whether a message should be flowed back if a ReplyTo destination is defined in the JMS message header.

  3. Decide whether or not you want to handle late responses.

    A sender bean can optionally retrieve a response to messages sent. If a response is delayed within the messaging infrastructure, the bean cannot receive the response. Extended messaging can retrieve such a response message (referred to as a late-response message) when it does arrive and pass it to a message-driven bean provided by the application to handle late responses. To handle late responses, you need to develop and deploy a standard EJB 2.0 message-driven bean that contains a registerLateResponse() method, and associate it with a listener port to be used to receive late responses.


Related concepts
Extended messaging - overview
Extended messaging - receiving messages
Extended messaging - sending messages
Extended messaging - data mapping
Extended messaging - handling late responses
Related tasks
Developing an enterprise application to use extended messaging
Using extended messaging in applications



Searchable topic ID:   tmc_desap
Last updated: Jun 21, 2007 8:07:48 PM CDT    WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/cmm/tasks/tmc_desap.html

Library | Support | Terms of Use | Feedback