Introduction

IBM WebSphere® Application Server provides support for applications that call Java^TM Message Service (JMS), which enables applications to use both point-to-point and publish/subscribe styles of messaging to send and receive messages within the scope of a transaction. In addition, Enterprise JavaBeans (EJB) 2.0 introduces the message-driven bean (MDB). The application server listens to named destinations, and as JMS messages are delivered, they are passed to an MDB for processing. The MDB may then delegate the processing of the message to an application bean.

WebSphere Extended Messaging enhances this basic messaging capability within the application server. It provides a simple programming model for handling incoming messages and, where appropriate, the sending of replies to these messages. Additionally, it can handle outgoing messages and provide correlation of responses when they are delivered to the server. By exploiting common usage patterns, business components should be unaware that asynchronous messaging is being used. Using these patterns together with asynchronous messaging means that applications do not have to wait on each individual request, but rather may process requests in parallel. This is achieved by having a clear separation between the messaging logic and the business logic, and using the server facilities to manage the messaging interactions. Extended Messaging is a feature of WebSphere Application Server Enterprise, Version 5.

Back to top

Basic messaging patterns

Applications may use many different messaging scenarios to meet their business requirements, but typically they tend to use common patterns:

These basic messaging patterns are often combined to support a variety of messaging scenarios. For example:

An application on a WebSphere Application Server may:

• initiate messages based upon these patterns,
• be the recipient of such messages,
• or both.

Figure 1 shows two patterns, which illustrate the terminology used in this article:

• In the first pattern (one-way, or datagram), a message is sent from a Source to a Destination .
• In the second pattern (two-way, or request and reply), the Source sends a request to a Destination. The Destination then sends a reply , which the Source retrieves as a response .

Back to top

Message beans

WebSphere Extended Messaging supports the above messaging patterns with two message beans. These message beans are built from EJBs and, individually, are referred to as sender beans and receiver beans . These beans are constructed using the WebSphere Studio Application Developer, Integration Edition (hereafter called Application Developer). Application Developer encourages the separation of the message and business logic, and helps the bean developer by generating the code to handle the parsing and formatting of the messages. These generated message beans contain code to define the message content, and invoke the Extended Messaging run time supplied with the WebSphere Application Server. As we shall see later, resources called input ports and output ports are used to define the JMS resources required for sending and receiving messages.

When methods in the sender bean are invoked, they are passed a number of objects which are then mapped to messages. Similarly, receiver beans pass objects, extracted from messages, to application beans . These objects may be any type, Java primitive types or user defined. User defined objects can represent any business object, but they must be serializable. For example, a user defined object could represent details of a bank account, or an XML document.

Sender bean

A sender bean is constructed from a stateless session bean. Sender beans encapsulate the sending of messages and the handling of any responses to those messages. They can also handle the transformation of parameters into a JMS message and the conversion of a response message into objects.

Sender beans provide support for three interaction patterns:

1. Send a message and then receive a synchronous response.
   With this pattern, the sender bean, with its runtime support, assembles the message and completes the send. The sender bean then waits for the far end to reply before returning the response to the application bean. While the application sees a synchronous pattern, the underlying messaging is completed asynchronously due to the JMS provider. It is the Extended Messaging support that provides the synchronous behavior. It is possible to specify a timeout value to avoid the system waiting infinitely for a response. Because a response to a message that has been sent cannot be retrieved in the same transaction, the system will always force the message to be sent immediately, ignoring any transaction boundaries.
2. Defer the receipt of a response.
   With this pattern, the sender bean assembles and sends the message, then returns to the caller with a correlator , an object that is subsequently used to retrieve the corresponding response. It is the application's responsibility to retrieve the response later. This pattern also has an advantage in that sends may occur in parallel, which means a number of messages may be sent before attempting to retrieve any response. If the response is not yet available when the application attempts to retrieve the message, the application may try again later. When the application requests the response, it may also choose to set a time limit in which the response should complete. If the request time limit expires before the message is retrieved, the application may choose to try again. There is no limit on the number of times the application may attempt to retrieve the response. With this pattern, the application may also retrieve multiple responses to a single message.
3. Receive no response.
   This is a datagram. The sender bean uses the run time to assemble and send the message, but does not use any of the message retrieval support.

With the first two patterns, if an expected response is not received (within the time limit) the application can request that Extended Messaging route the response to a user-supplied receiver bean. For more details on this, see LateResponseHandling .

Receiver bean

A receiver bean is constructed from either a message-driven bean or a stateless session bean. Receiver beans encapsulate the receiving of messages and the sending of any reply to those messages. They can also handle the transformation of a JMS message into parameters that are used to invoke a business component, and the conversion of any reply objects into a JMS message.

There are two types of receiver beans, which have different invocation and reply semantics:

• Constructed from a message-driven bean
  These receiver beans are invoked by the arrival of a message at a destination, which has a JMS message listener active. They invoke business methods passing parameters derived from the message.
• Constructed from a stateless session bean
  These receiver beans, also referred to as Application Callable receiver beans, are invoked by the application bean calling a method on the receiver bean. They return to the application an object known as a Logical Message Format (LMF). The application bean uses getters on this object, which contains the de-marshalled message, to retrieve the data content.

Receiver beans provide support for three interaction patterns:

1. Send a synchronous reply.
   With this pattern, the received message is de-marshalled, and is then used to invoke a business component to pass in parameters derived from the de-marshalled message. In addition, the receiver bean can transform the result of the downstream business method into a JMS message and send it as the reply. In this case, the destination for the reply is defined by the original message, within the JMSReplyTo field in the JMS message header. This pattern is applicable to receiver beans built on message-driven beans.
2. Send an asynchronous reply.
   With this pattern, the message is received, de-marshalled and passed to the user application. The application may send a reply by calling a generated replySender method, whose function is to map the method parameters to a JMS message. The message is then sent to the reply destination, which is defined in either the request message or the input port. Using this technique, the application may send more than one message in reply to a message request. This pattern is applicable to receiver beans built on stateless session beans.
3. Send no reply.
   This makes use of the de-marshalling and method invocation functions, but does not make any use of the reply handling capability. This pattern is applicable to both types of receiver beans.

Back to top

Sample scenario

To demonstrate the relationship between applications and message beans, let's look at a sample scenario which, though oversimplified, will effectively show how the parts may be related.

In this scenario, a user needs to know the balance of an account. The developer will build two pieces:

• the client side application (typically an EJB, invoked from a client)
• the back-end access application.

The flow of this scenario will go like this:

• The client side application receives a request and performs some local processing.
• The client side application determines it needs to pass the request to the back-end application, and does so. The request passed may typically supply some account details, such as account number, type of account, customer name, etc.
• The back-end system takes the request, and uses it to perform the account lookup and retrieve the balance.
• The response from the back-end application is returned to the client side application.
• The response is returned to the user.

The developer writes the client side and back-end access applications to fulfill this scenario. Deciding to use messaging to connect the two ends together, the developer uses the Application Developer tools to build the sender and receiver beans.

Figure 2 illustrates the flow of this example. The client calls a sender bean to build and write a JMS message to destination queue Q1. When a message listener retrieves the message, it invokes the receiver bean, passing the JMS message. The receiver bean, in turn, parses the JMS message, and then invokes the getBalance() method in the inquiry EJB, to find the balance. When control returns to the receiver bean, the object returned is mapped to a JMS message, and the reply is then written to destination queue Q2. The sender bean, called by the client application, then retrieves the response from destination Q2 and returns it to the originator.

As mentioned earlier, there are two interaction patterns of interest when sending a message and retrieving a response: the deferred response pattern and the synchronous pattern. Here is how each of these patterns may be applied to this scenario:

The flow for the deferred response pattern:

1. Application A calls a method (e.g. getBalance) on the sender bean, passing a number of parameters on the call.
2. The sender bean marshals the data into a JMS message, and specifies destination Q2 (indicating the destination for the response) in the replyTo field of the message header. It then puts the message to Q1 (the destination), and returns to Application A, passing back a correlator object.
3. At the receiving end, the JMS provider detects the delivery of the message on destination Q1, and invokes an instance of the receiver bean, passing the JMS message to the onMessage() method.
4. The receiver bean de-marshals the message, then calls a method (e.g. getBalance) in Application B, passing it objects from the message.
5. When Application B completes, it returns to the receiver bean, passing back an object.
6. The receiver bean maps the return object to a JMS message, and then sends the reply message to destination Q2.
7. Since it used a deferred response, Application A has been performing other work. To obtain the response, Application A calls a retrieve() method, on the sender bean, passing it the correlator that was returned in step 2. If the response message is not available, the application can simply repeat calling the retrieve method.
8. The sender bean de-marshals the message and returns the response to Application A.

The flow for the synchronous pattern differs from the deferred receipt response pattern, as follows:

1. Application A calls a method (e.g. getBalance) on the sender bean, passing a number of parameters on the call. The application then waits for the response.
2. The sender bean marshals the data into a JMS message, and specifies destination Q2 (indicating the destination for the response) in the replyTo field of the message header. It then puts the message to Q1 (the destination). The sender bean does not return to Application A and does not pass back a correlator object, but waits for the response to be delivered.
3. The remaining steps 3 through 8 are the same, except step 7 does not occur.

We will refer back to this sample scenario in later sections.

Back to top

Message content

As part of its message construction, Extended Messaging handles the message format for you. The sender or receiver bean methods are passed a number of objects when they are invoked. These objects may be of any type, but should be serializable. Otherwise, the message stream cannot be constructed. An error exception is thrown when attempting to construct a message from a non-serializable object.

JMS-defined messages consist of a header and a body, where JMS provides five forms of message body. Extended Messaging uses the StreamMessage form for the message body, and constructs the body by sequentially adding on the passed objects. The generated code, within the message bean, is responsible for passing the parameters that make up the message to the message formatter. Objects that are not Java primitive types are serialized first, then treated as byte arrays before being added to the data stream. This is not apparent, since the system handles the message formatting. At the receiving end, it is fairly simple to then de-marshal the message and extract all the objects. However, to enable this data mapping between the two ends, Extended Messaging needs to be able to associate the message types at both ends. The methods at the sending and receiving ends use a message format identifier to associate the message with its defined data content. Both ends require the exact same understanding of the message content. Since each sender and receiver bean may handle more than one message format, the JMSType header field is used to hold the message identifier.

Although the Extended Messaging tooling is designed to generate message beans that are capable of handling both ends of the service, it is possible for users to have a non-WebSphere application server at either end. In this case, the application developer is able to override the default marshaling and de-marshaling of parameters into JMS messages.

Back to top

Late response handling

On occasion, a response may not be available to the sender bean within a prescribed time period. These delayed messages are referred to as late responses . A late response may occur for a number of reasons; the application producing the reply message may be too busy to reply within the required time, there may be a failure in the messaging system infrastructure, etc. In these situations, the application requiring the response has to decide what action to take to recover from the error.

WebSphere Extended Messaging provides a facility to assist in the handling of any late responses. When the response message is eventually delivered it may be routed to a user-created message-driven receiver bean.

The response mode of the sender bean affects how the system registers late response requests:

• Synchronous Mode: If the bean has been deployed with the handle late message function enabled, a request is automatically registered for the system to route the late response to a receiver bean.
• Deferred Mode: The application bean has the responsibility for registering the request with the sender bean. In this mode, the Extended Messaging system is unable to register the request automatically. This is because the application may itself retry the retrieve a number of times, and Extended Messaging cannot detect when the application has given up retrying. The application bean registers the request by calling the registerLateResponse(Correlator) method on the sender bean, passing the correlator that was returned on the send call. Another consideration is what happens if the application was expecting to receive more than one response. In this case, the application needs to register a request for each outstanding response it wants Extended Messaging to handle. For example, if the application was expecting to retrieve three responses but only received one, it would call the register method twice. That, of course, assumes it wants both late responses to be routed to a receiver bean.

Once the request to handle the late response has been registered, the Extended Messaging system listens for the message to be delivered, and then passes the message to the receiver bean developed by the user. How does Extended Messaging know which receiver bean to target with the late response? That link is made when the sender bean is deployed and specifies a listener port. The listener port is then associated with the receiver bean, or message-driven bean, when that bean is deployed.

One aspect to consider with late responses is, what happens when the registration request is made? The request is used to inform the listener function which message is to be retrieved from the named destination. Initially, the registration request is logged to persist the request in cases of system restart or failure, then the listener commences the listening process waiting for the response message. Meanwhile, the application that registered the request may continue performing some other work. It is quite possible, therefore, that in some cases this could result in the receiver bean processing the message before the original application bean has completed its processing.

Back to top

Transactions

Message-driven beans that require the initial message to be received within a global transaction must use Container Managed Transactions (CMT). Similarly, the message beans constructed by the Extended Messaging tooling also need to use CMT. Using CMT for the message beans enables sender beans and both types of receiver beans to have the same transaction control. By setting the transaction attributes on the bean methods in this way, the application deployer has full control over the transaction boundaries.

When using transactions, it is important to remember that any messages sent within the scope of a transaction are not physically sent until the transaction is committed. If the transaction is rolled back, rather than committed, then any messages are discarded and not sent to the destination. When using synchronous mode interactions, sending the message and retrieving the response occur in the same sender bean method. This would cause a problem if the method was part of a transaction, because the send would not complete until the transaction was committed. This means that the response could never succeed in the same transaction; there would either be a timeout on the response or, worse, a deadlock if no timeout was specified. To avoid a possible deadlock with this mode of interaction, Extended Messaging always forces the message send to become a sendImmediate; that is, the send is not part of any transaction and occurs immediately. Retrieving the response is part of the transaction associated with the method. This means that once the send has occurred, it cannot be undone even if the transaction is rolled back; the message will always be sent.

When using the send with a deferred response, it is the application deployer's responsibility to avoid any possible deadlock by ensuring that the send and receive methods are not part of the same transaction. For example, when the application is deployed, the receive method could be specified with the transaction attribute of RequiresNew.

Back to top

Sample code

How much coding needs to be done to enable an application to use Extended Messaging? In some cases, very little. Considering the sample application above, the sender and receiver bean are generated by the Application Developer tools. Some code needs to be added to invoke a method on the message bean, within the client EJB, to handle errors returned from our method call. (This is discussed later in Error handling .) The inquiry EJB is not necessarily aware that it is being called from a receiver bean, and so requires no special code.

Let's look at the sample scenario again, first using the synchronous message pattern, then using the deferred response pattern:

Synchronous response mode

When using the synchronous message pattern, the objects being passed to the sender bean need to be created and their values need to be set. To do this, the getBalance method will be called on the sender bean, passing in three parameters (Customer name, account type and account number) and receiving back the account balance. The code segments would be similar to Listing 1.

int accountBalance; // int that holds the result.

String custName = "Smith"; // String - parameter 1.
int accountType = 20; // int - parameter 2.
int accountNumber = 123456; // int - parameter 3.

// Create the initial context for looking up the Sender Bean.
Context initialContext = new javax.naming.InitialContext();

// Lookup the SenderBeanHome and cast it to the correct reference type.
SenderBeanHome home = (SenderBeanHome)javax.rmi.PortableRemoteObject.narrow
(initialContext.lookup
("java:comp/env/ejb/ems/SenderBean"), SenderBeanHome.class);

// Create the SenderBean.
SenderBean sb = home.create();

// Lookup the result by calling the getBalance method on the SenderBean.
accountBalance = sb.getBalance(custName, accountType, accountNumber);

The code in Listing 1 will return the balance amount for the requested account. No special code was required here to accommodate Extended Messaging. Similar code would be used to invoke any EJB method call.

Deferred response mode

When using the deferred response pattern, two methods are actually being called: one to send the request, and another to retrieve the response. First, the requestBalance method is called, passing in the same three parameters as before, and then the getBalance method is called later when we want to see if the response has been delivered.

int accountBalance; // int that holds the result.
String custName = "Smith"; // String - parameter 1.
int accountType = 20; // int - parameter 2.
int accountNumber = 123456; // int - parameter 3.

// For simplicity the code to look up the sender bean home has been omitted.

// Send the request by calling the senderBean requestBalance method.

CMMCorrelator corr = sb.requestBalance(custName, accountType, accountNumber);

// do some other work, until we are ready to retrieve the result

// Get the result, using the correlator returned from the request
accountBalance = sb.getBalance(corr);

In Listing 2, a request is sent for the account balance (requestBalance method call), which was then followed up later by a request for the result (getBalance method call). The call to requestBalance returned a correlator object, which we then used again in the getBalance call. The advantage this pattern provides is the ability to perform other, unrelated processing between sending the request and retrieving the response.

As discussed earlier, if the response is not available when requested, we can request that the response be handled later by routing the message to a receiver bean. To do this with the deferred messaging pattern, use the following code to pass the correlator object to the registerLateResponse method:

// Register request for the system to handle the late response
sb.registerLateResponse(corr);

Back to top

Error handling

There are two error scenarios to consider when using Extended Messaging:

• handling exceptions that are returned to the application
• handling recovery when transactions are rolled back.

If the Extended Messaging run time encounters a problem when handling messages (such as a configuration or JMS communication error, or a data formatting problem, etc.), it will throw a CMMException. In our sample application where we called the sender bean, we would typically call the bean in a try-catch condition. Listing 4 shows how a CMMException may be handled. For simplicity, the handling of other exceptions has been omitted.

try
{
....
accountBalance = sb.getBalance(custName, accountType, accountNumber);

} 
catch (....)
{
...
} 
catch (CMMException cmme)
{
// Create message if an error occurs during Extended Messaging transit.
result = "Error occurred in getBalance\r\n";

result += "Exception message is: " + cmme + "\r\n";
Exception e = cmme.getLinkedException();
if (e != null)
result += "Extended Messaging Linked Exception is: " + e + "\r\n";
if (e instanceof JMSException)
{
JMSException jmse = (JMSException)e;
msg += "JMS Linked Exception:" + jmse.getLinkedException() + "\r\n";
}
}

The result string containing the error information would then be logged and used by the application to report back a suitable error to the client application.

To recover from the error, standard practices can be applied in most cases, since the user application is typically in control. For example, rolling back the existing transaction and retrying the operation may well be successful. If the retry fails, the application can determine how many retries to attempt before reporting a permanent error and stopping.

With receiver beans built on message-driven beans there is another consideration, since the invocation of the message-driven bean is under the control of the system, not the application. Here, if the transaction is rolled back, the message is returned to the queue, and the system will retry the operation by invoking another instance of the message-driven bean. To eliminate potential infinite loops, the listener port can have a retry count specified and, once the count is exceeded, stop delivering messages until it is restarted. Some JMS providers have the capability to redirect the message to a dead-letter queue once a retry threshold is reached.

Back to top

Development scenario

Before looking at the steps for building a sender or receiver bean, some aspects regarding the design of the application need to be considered. Once the application is built, the runtime definitions and resources required within the WebSphere Application Server will also need to be looked at.

While the beans may be developed in any order, it is generally easier to create the application beans first, then the sender bean, and finally the receiver bean. If the receiver bean is built on a message-driven bean, it needs to be built after the target application bean, since it uses the method signature of the application bean to define the data mapping.

Application beans

In designing the application beans, we need to consider how they interact with the message beans they use. The type of reply/response pattern used, together with the choice of using data mapping or non data mapping, will have a significant effect on the design of both the application and message beans.

Three modes of interaction will be considered:

• Applications driven by receiver beans based on message-driven beans
  With this mode, the application bean is generally isolated from the messaging layer and not aware that messaging is driving the application. Simply put, the interface between the receiver bean and application are defined in much the same way as for any two interacting EJBs.
• Applications initiating requests via sender beans
  Referring to the earlier sample, a request can be sent using either a synchronous or deferred mode of interaction. Synchronous is generally less complex to use, since it requires only one call to send the request and retrieve an answer. However, to send the request and then look for the response later may be more practical if additional work can be processed before the response is needed. If the request requires multiple responses, this is the mode to use.
• Applications requesting input from receiver beans built on stateless session beans
  Here, the application needs to be fully aware of the content being retrieved. As we saw earlier, the content of the message is mapped to a Logical Message Format (LMF) which is returned to the application. The application can then use the getters on the object which was returned to extract the relevant properties. If the application is interested in only a single property, it can retrieve the value directly rather than having to use an LMF object.

Sender Beans

The first consideration when designing a sender bean is the form of interaction the application is using. Second, what form of data mapping is required? Can the application send the message and continue processing before retrieving the response, or does it need to wait for the response to arrive? Alternatively, the application may not expect any response. When the application expects a response, we need to determine the behavior to invoke if the response is not available. Is this an error the application will handle, or is the Extended Messaging support required to handle the late response? Finally, while designing the interfaces to the sender bean, remember that any objects passed have to be serializable, otherwise an error will occur when mapping the message.

Receiver beans

The type of receiver bean used is dictated by the application requirements:

• Are the beans invoked by a message being delivered (use a message-driven bean construction), or
• Is the application requesting the message (use a stateless session bean)?

Message-driven beans are normally the most efficient types to use, since the system will invoke an instance once a message is available.

With receiver beans, we also need to consider whether there is any reply to be sent. The interaction is different depending upon the type of receiver bean being used. With receiver beans that are built on message-driven beans, the reply is mapped from the object returned by the user application to a JMS message. With receiver beans constructed on stateless session beans, the replies are asynchronous and are mapped from the objects passed to the constructed reply/sender method on the receiver bean. In both cases, the mapping is handled by methods in the receiver bean.

Message beans

Message beans are created by the Application Developer tools. Extended Messaging provides a number of wizards to simplify the task of creating the beans. These wizards can be used to create new beans, convert an existing EJB to a message bean, or update an existing message bean. An EJB that is converted to either a sender or receiver bean must be either a stateless session bean or a message-driven bean. Sender or receiver beans may be created individually, or the sender and receiver bean may be created in a single step using a combination wizard.

Running the wizard will:

• Create the code for the sender or receiver bean.
• Create a resource reference to any input or output ports.
• Create an ejb-ref for a message-driven bean.
• Optionally, create the WebSphere bindings to help simplify the application install.

Back to top

IBM extensions to the Application Deployment Descriptor

Extended Messaging has some extensions in addition to the standard EJB Deployment Descriptors. These may be added when the message beans are developed using the Application Deployment Descriptor editor, or they may also be added by using the Application Assembly Tool (AAT).

For sender beans, the properties are:

• Response timeout - This value may be set to override the value specified when the sender bean was originally constructed.
• Handle late response - Enabling this option specifies that Extended Messaging should handle any registered late responses. The sender beans would normally expect this to be set if they were generated to register late responses. If the late response option is enabled, then the associated Listener port name may be specified.

For application-callable receiver beans (those based on stateless session beans), there is a single property:

• Message Selector - This enables messages to be filtered by specifying selection criteria for the message that the receiver bean is retrieving. The selection is based upon JMS header and property fields. For example, JMSType = 'car' AND color = ' red' . The selector uses the same format as message-driven beans.

For message-driven based receiver beans, there are no additional properties beyond those typically used for message-driven beans.

Resources used by deployed message beans

What resources does Extended Messaging use? In addition to the basic JMS resources, such as JMS destinations and connection factories, there are two principal resources: output ports for sender beans, and input ports for application callable receiver beans. Also, any application planning to use late response handling must have a specialized listener port associated with it.

These resources are defined either by using the WebSphere Application Server system management console, or by using the batch WSAdmin command. Within the Admin console, the input and output ports are defined under the Extended Messaging provider, which is located under Resources.

Input ports

Input ports are used by receiver beans that are constructed from stateless session beans. The purpose of the input port is to define the JMS resources together with other properties. Receiver beans built on message-driven beans do not require input ports, because they are associated with a Listener port when deployed.

Required properties for the input port include the JNDI name for the connection factory, and the destination used to receive the message. Additional properties, such as destination type or subscription durability, may also be defined. If a reply is to be sent to the message, the JMSReplyTo information from the message is used, but this may be overridden by specifying a connection factory and destination for the reply in the input port.

In the sample scenario, an input port is not required because the receiver bean is deployed as a message-driven bean, which uses a Listener port.

Output ports

In the same way that receiver beans are associated with input ports, so sender beans are associated with output ports. The output port is also used to define the JMS resources together with other properties. The JNDI name for the connection factory and the destination used to send the message are required. The destination type and other properties for handling the JMS message can also be defined. It is possible to specify more than one destination in an output port. If multiple ports are specified, then the message is sent to each port.

If a response is expected, then configuring the output port requires a bit of thought. If the application uses the deferred response pattern, or if the response can be handled as a late response, then the connection factory and destination name used to retrieve the response are required. For the synchronous response pattern, the factory and destination are optional; if they are not specified, a temporary queue is used.

Listener ports

Listener ports are normally used to associate the JMS resources and deployed message-driven beans with the Listener service which is handling the incoming messages. To support late response handling, Extended Messaging uses a specialized Listener port to retrieve the messages. When the port is enabled to handle late responses, additional properties may also be specified to control the checking and timeout periods while waiting for the response.

The properties are specified through the system management console by selecting Manage Application Server => Application Server => Extended Messaging Service => Listener Port Extensions , then adding a new entry for the Listener port.

Installing the application

Having designed and constructed our message beans, assembled the application, and defined the required resources, the final step is to install the application. The standard application server install steps can be followed.

Back to top

Conclusion

In this article, we have examined how the Extended Messaging support within WebSphere Application Server can be used to simplify applications. We have looked at the messaging patterns and runtime facilities available, and have considered a sample scenario with coding examples to show how an application might benefit from using Extended Messaging support.

About the author

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Basic messaging patterns
• Message beans
• Sample scenario
• Message content
• Late response handling
• Transactions
• Sample code
• Error handling
• Development scenario
• IBM extensions to the Application Deployment Descriptor
• Conclusion
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

Cloud computing for developers

Virtual workshop: Learn how to build a cloud infrastructure and develop/deploy cloud-based applications. (6-8 Apr 2010)

Special offers