The Messaging Component Model

Normally, a JMS client sends and receives messages by opening a connection to a JMS queue or topic and then using that connection to transmit a message. However, to asynchronously receive a message in the application server runtime, a thread would have to wait for an incoming message to be received. That is where Message Driven Beans (MDB) come into play. The figure below shows a simple messaging application:

Message Driven Beans

MDB is an extension to the EJB programming model that allows the container to drive asynchronous work using a component model. Declarations are made in deployment descriptors, which describe the message selector to use and hint at the destination type. The message selector can be used to filter messages that an MDB processes, based on property values. During deployment, this is matched up to a JMS listener port. When a message is received, an MDB instance is driven to service it. The following sections describe how to use WebSphere to build and run a messaging application. The PlantsByWebSphere application will be extended with messaging to support decoupling of order processing from the application.

Designing an Application for Messaging

The first thing to do is identify the JMS resources that the application needs to use. In particular, a decision needs to be made on whether to use point to point or publish/subscribe messaging. The choice will also help identify the properties of resources that need to be used within the application, and configured as application deployment descriptors, or within WAS. For this example, a point to point queue will be used to deliver notifications to an order-processing subsystem that an order has been received. Pub/sub is not necessary here because the topology will require a single queue and consumer. The order processing subsystem will then take care of processing the order and updating inventory. No message selector will be used to filter incoming messages because all messages will contain an order that needs to be recorded.

It is recommended that we delegate the business processing of incoming messages to another EJB. This provides a clear separation of message handling and business processing, which have different requirements for security, transactions, and scalability. This also enables the business processing to be invoked either by the arrival of incoming messages, or, for example, from a WebSphere J2EE client.

It is important to remember that the client identity that initiated the message does not flow with the message. A run as identity may be specified to associate an identity with the message request.

Message processing transaction requirements may also be specified. In this case, the processing of the message and placement of the order in the database should occur under the same transaction so that if rollback occurs, the message is not processed. During rollback, the unprocessed message is placed back on the queue to be processed again until the JMS listener threshold is reached or the message is moved (by the JMS provider) to some dead letter queue. The WebSphere JMS/MQ provider provides two queue attributes, backout threshold and backout requeue queue. The threshold prevents transactional processing loops where a rollback puts a message back on the queue only to be processed and rolled back again. Once the threshold is reached, it is moved to the queue declared by the backout requeue queue attribute.

One thing to keep in mind while designing and constructing an application using JMS messaging is that WebSphere MQ supports clustering and fail-over of queues if the full WebSphere MQ product (External JMS/MQ provider) is used, but does not support clustering of topics. See the Managing WebSphere Messaging section for more details.

Building a Messaging Application

WebSphere Studio Application Developer supports both development and unit testing of MDBs. This section will use messaging to extend the PlantsByWebSphere application to add order fulfilment processing to the existing order-entry capabilities.

The first thing to accomplish is to define the message structure to be passed as a message. For this particular example, we will use a JMS TextMessage to carry the order key information. There are other message types that could be used (for details on the JMS specification see http://java.sun.com/products/jms/), but a TextMessage is the most commonly used message type. Next, we will divide and conquer using specific EJBs to handle specific message processing functions. A local stateless session EJB will be used to handle sending the order to the fulfillment subsystem. A MDB will be used to receive the message, and fulfillment processing will be handled by a stateless session EJB. Here are the steps for the order sender EJB:

Use the wizard selection panel to create a J2EE enterprise bean in the PlantsByWebSphereEJB project. Select Session Bean, and give it a name like OrderSender, with a package name like com.ibm.pbw.ejb, and click Next:

Here, be sure to select a Local client view and uncheck the Remote client view. Since we do not intend to make a remote view available, change the local interface name to OrderSender and the home interface to OrderSenderHome, as shown, and then click Finish:

Add a sendOrder() method to the OrderSenderBean that takes Order as an argument. Add business logic to send a JMS TextMessage to the order fulfillment queue. The code should look like the following:

 public void sendOrder(Order o) {   try {     //initiate the order fulfillment process     Context ctx = Util.getInitialContext();     QueueConnectionFactory qcf =                              (QueueConnectionFactory) ctx.lookup(                             "java:comp/env/jms/ConnectionFactory");     Queue q = (Queue) ctx.lookup(                             "java:comp/env/jms/FulfillmentQueue");     QueueConnection conn = qcf.createQueueConnection();     QueueSession session = conn.createQueueSession(true,                               Session.AUTO_ACKNOWLEDGE);     QueueSender sender = session.createSender(q);     //not necessary to start a connection to send a message     //conn.start();     //create msg     String key = ((OrderKey) o.getPrimaryKey()).orderId;     TextMessage msg = session.createTextMessage(key);     //send it     sender.send(msg);     sender.close();     session.close();     conn.close();   } catch (NamingException e) {     e.printStackTrace();   } catch (JMSException e) {     e.printStackTrace();   } } 

As you can see, there is a fair amount of coding involved in setting up and managing a standard JMS queue connection for sending a message. First, we must create a connection factory for the queue, then use the factory to create a connection. The connection is then used to create a session, which is used to create a message sender. Finally, a message can be created and sent. WebSphere provides extensions to ease this burden by encapsulating message sender logic in message sender beans.

The connection factory uses the security identity defined by the deployment descriptor or the ID and password provided by the application when the connection is created (if the application chooses to provide them). The credentials are authenticated before processing proceeds. WebSphere provides additional authorization extensions to control access to JMS resources if the embedded JMS provider is used and security is enabled. See was_install\config\integral-jms-authorisations.xml for configuring permissions granted to queues and topics. A cell based configuration file exists at was_install\config\cells\your_cell_name\integral jms authorisations.xml.

Be sure to promote the sendOrder() method to the local interface. Set the deployment descriptor container transaction settings for the sendOrder() method to Mandatory, as this will ensure that

acceptance of the order by the order fulfillment subsystem will be tied to order entry.

Add a resource reference to the OrderSender EJB deployment descriptor information for the queue connection factory. To do this, edit the deployment descriptor for the module, click the References tab, select the OrderSender bean, and click the Add button. Select EJB resource reference and click Next.

The name must be consistent with the application code used to look up the connection factory. For example, if the code wants to look up java:comp/env/jms/ConnectionFactory, the name of the resource reference must be jms/ConnectionFactory. The type should be javax.jms.QueueConnectionFactory because we are using a queue to send the message. Other resource types include a topic connection factory and a Java 2 Connector connection factory. Set Authentication to Container and Sharing scope can be left as Sharable. Click Finish. See the following figure for an example:

Set the JNDI binding in the deployment descriptor for jms/ConnectionFactory to jms/FulfillmentQCF. This can be done by selecting the resource and entering the binding in the WebSphere Bindings section. The server configuration will need to be updated to used to set up the connection factory with this JNDI name, as we will see later.

Now add a resource environment reference to the OrderSender EJB for the queue. In this case, the Name should be jms/FulfillmentQueue and the Type should be Queue.

Set the JNDI binding in the deployment descriptor for jms/FulfillmentQueue to jms/FulfillmentQueue. The server configuration will need to be updated to create a JMS destination with this JNDI name. This will be handled later.

Now, we need to tie order creation to initiating the order fulfillment process. There are two ways to approach this. One way is to modify the OrderModel in the presentation logic to send a message after using the Order EJB home to create an order. However, if the Order EJB is used to create orders from other locations, then they will need to be modified as well. The alternative is to have the Order EJB itself create and send the message. This means that the Order EJB will be operating under a two phase commit transaction protocol. The two phase commit transaction support allows both order creation and message sending to occur together or not all. Modify the OrderBean's ejbPostCreate() method to call the OrderSender EJB sendOrder() method. The following can be added to the end of the method:

    setOrderitem(orderItems);        OrderSenderHome senderHome = (OrderSenderHome) ctx.lookup(                                "java:comp/env/ejb/OrderSenderHome");     OrderSender sender = senderHome.create();     sender.sendOrder((Order) myEntityCtx.getEJBLocalObject());     sender.remove();   }   catch (Exception e) {     throw new EJBException(e);   }                              }

Add the OrderSender local EJB reference to the deployment descriptor as described in Chapter 5.

At this point, creating an order will not only add a row to the database table represented by the Order EJB, it will also send a message to the order fulfillment subsystem using a message queue. This is all done under the same transaction so that order entry and fulfillment process initiation happen together or not at all. However, fulfillment processing happens asynchronously.

We now start on the message consumer side of the application by creating the business logic to process order fulfillment. We will create a FulfillOrder stateless session EJB with a processOrder() method that handles the business logic for fulfillment. This allows the message processing functionality to be segregated into an OrderReceiver MDB.

The business logic for the order fulfillment process will simply be to check that the inventory can satisfy the order and reduce the inventory quantities if the order can be met. However, there may be a case where inventory is less than required by an order. To discontinue processing when inventory does not meet the order requirements, an application exception needs to be created. An exception thrown during order processing will flow back to the order receiver component and it will force the transaction to roll back.

Create an InsufficientInventoryException Java class that extends java.lang.Exception as part of the com.ibm.pbw.ejb package. The constructor should take a String as a message argument and call the super-class constructor with the argument:

 package com.ibm.pbw.ejb; public class InsufficientInventoryException extends Exception {    public InsufficientInventoryException(String msg) {       super(msg);    } } 

Now that we have the exception to pass from the fulfillment process business logic, we can create the bean itself, using the following steps:

Create a stateless session EJB called FulfillOrder in the same package as the OrderSender EJB. It should use a container transaction type. Add a local client view in addition to the remote client view. The local client view will be used by the OrderReceiver MDB for initiating fulfillment processing on an order. The remote client view could be used to initiate order processing manually by a remote client if necessary:

Add two new private data members, orderHome and invHome, to the FulfillOrderBean class. These data members will be used to cache references to OrderHome and InventoryHome classes. Add a private getter method for each that initializes and returns the private data members. These should be like the following:

 private InventoryHome getInvHome() {   try {     InitialContext ic = new InitialContext();     if (invHome == null) {       invHome = (InventoryHome)         ic.lookup("java:comp/env/ejb/InventoryHome");     }     return invHome;   } catch (NamingException e) {     return null;   } } private OrderHome getOrderHome() {   try {     InitialContext ic = new InitialContext();     if (orderHome == null) {       orderHome = (OrderHome)         ic.lookup("java:comp/env/ejb/OrderHome");     }     return orderHome;   } catch (NamingException e) {     return null;   } } 

Add the two local EJB references used by the JNDI lookups to the deployment descriptor as described in Chapter 5.

Add a processOrder() method that takes a String key argument (the key found in the message) to the FulfillOrderBean class and have it throw the InsufficientInventoryException. The business logic uses the orderHome() to find the order that needs to be processed based on the argument. It then checks the inventory for each item on the order to see if sufficient quantity exists. If there is enough quantity, the inventory count is decremented by the order item count. If not, then processing is stopped and an exception is thrown. It is expected that the caller will roll back the transaction currently in progress when this happens. This example code is part of our continuing example:

 public void processOrder(String key)      throws InsufficientInventoryException {   try {     Order order = getOrderHome().findByPrimaryKey(new OrderKey(key));     Iterator items = order.getOrderitem().Iterator();        while (items.hasNext()) {       OrderItem oi = (OrderItem)items.next();       //get inventory info       Inventory inv = getInvHome().findByPrimaryKey(new                                     InventoryKey(oi.getId()));       //check inventory quantity       if (inv.getQuantity() >= oi.getQuantity()) {         //decrement inventory count         inv.setQuantity(inv.getQuantity() - oi.getQuantity());        } else {         //stop order processing         throw new InsufficientInventoryException(           "requested " + oi.getQuantity() + " have " +           inv.getQuantity());       }     }    } catch (FinderException e) { } } 

In the Outline view, promote the processOrder() method to the remote and local interface.

In the Assembly Descriptor settings of the deployment descriptor, add a Mandatory transaction type for the processOrder() method. This will ensure that it is called within a transaction.

This completes the creation of the business logic for the fulfilment process. We now set up the message handling part of the message consumer by creating a MDB to receive the order message and initiate order fulfilment processing, using the following steps:

• Message-driven bean

• OrderReceiver

• Next:

This will display the MDB details page. Ensure Container Transaction type is selected. This will enable the message receipt and order fulfillment processing to run under the same transaction. If order fulfillment needs to be rolled back for any reason, the message will be placed back on the queue for reprocessing. Select Queue for the Destination Type. The selector can be left blank because all messages will be delivered to the MDB for processing. The ListenerPort is a binding to a specific connection factory defined in the server configuration. It is not necessary to fill this in, but it does prevent having to specify the binding during deployment if the binding is already known. For rapid iterative development in a WSAD unit test environment, it provides information to automatically generate a server configuration. Give the ListenerPort the name OrderReceiverListenerPort and click Finish:

Create a cached reference to FulfillOrderLocalHome in the OrderReceiver MDB. Declare a private fulfillOrderLocalHome member in the OrderReceiverBean class and add the following code to the ejbCreate() method:

public void ejbCreate() {   try {      fulfillOrderLocalHome = (FulfillOrderLocalHome)          Util.getInitialContext()           .lookup("java:comp/env/ejb/FulfillLocalOrderHome");   } catch (javax.naming.NamingException e) { } }

Be sure to add a local EJB reference for ejb/FulfillOrderLocalHome to the deployment descriptor. For a real application, the exception logic should be filled in with logging information and an EJBException would be thrown to let the container know the MDB is not in an acceptable state for additional processing.

Next, edit the onMessage() method to receive a TextMessage and initiate order processing using the data found in the message. The method should look as shown:

 public void onMessage(javax.jms.Message msg) {   TextMessage m = (TextMessage)msg;      try {     String orderKey = m.getText();     FulfillOrderLocal fulfill;     fulfill = fulfillOrderLocalHome.create();      fulfill.processOrder(orderKey);      fulfill.remove();   } catch (InsufficientInventoryException e) {     //rollback tran for later processing     fMessageDrivenCtx.setRollbackOnly();   } catch (JMSException e) {    } catch (CreateException e) {    } catch (RemoveException e) { } } 

Under normal circumstances, additional code would be required in the catch blocks to deal with the exceptions, such as logging the exceptions and potentially rolling back the transaction. For this example, the error case will be left as an exercise for the reader.

Add the OrderReceiver onMessage() method to the required container transaction set in the Assembly Descriptor tab of the deployment descriptor. To do this, open the EJB Deployment Descriptor editor and switch to the Assembly Descriptor tab. The container transactions section allows a new container transaction setting to be added via the Add button or an existing Required transaction setting can be edited using the Edit button. Click Add, to add a new transaction setting. Select the OrderReceiver EJB and click Next. Select the Required transaction type and the onMessage() method and click Finish:

WAS provides an extension that allows methods to run in a local transaction as well, but in most cases a global transaction will be desired. This is used mainly for recovery of dangling resources not contained within a global transaction unit of work (for example, uncommitted updates to a JDBC resource).

To make things more interesting, we will modify the presentation to display the current inventory. This will require updates to the com.ibm.pbw.ejb.StoreItem, com.ibm.pbw.war.InventoryModel, and product.jsp, using the following steps:

Edit the StoreItem class. Add a private int inStock data member and public getter and setter methods for it. Save the changes.

Edit the InventoryModel class and update the methods that create and initialize a StoreItem class to also set the inStock value:

 private StoreItem InventoryToStoreItem(Inventory inv) {   StoreItem si = new StoreItem(inv);   si.setInStock(inv.getQuantity());   return si; } 

Edit product.jsp. Join the cells in the third row of the table then add some text that says, " items are available in stock". Place the insert point before the text and use JSP | Insert Expression to insert an expression. The value of the expression should be item.getInStock():

Configuring the Test Environment

Use of the test environment is dependent upon the application scenario being used. The test environment's MQJD Lightweight JMS provider does not support two phase commit with JMS resources, but a two phase solution was used for developing the Plants-By-WebSphere application. The Managing WebSphere Messaging section discusses how to prepare the WAS for running the Plants-By-WebSphere application. If a single phase solution is used, this section describes how to configure the test environment.

The server configuration must be edited to configure the queue connection factory, JMS destination, queue names served by the server, and the MDB listener ports. Similar configuration management will be done for the WAS.

To edit the test environment configuration, use the server perspective to display the server configurations that were created earlier. Double click the WebSphere v5.0 test environment in the Server Configuration view to edit it. We need to create an authentication ID to use first. Select the Security tab and click the Add button for the JAAS Authentication Entries. Enter your local ID and password and give the entry an alias name to represent those credentials. Click OK.

Select the JMS tab to display the JMS server configuration settings. Click the Add button for the WASQueueConnectionFactory entries. The name can be whatever name you want to call the connection factory. The JNDI name configured here and the JNDI name declared earlier when the JMS resource reference was created need to match. In this case, use jms/FulfillmentQCF. Description and Category are descriptive fields used for helping to organize the connection factories, but do not affect the runtime.

The Component managed authentication alias and Container managed authentication alias represent the credentials to use depending on what type of authentication was chosen when the JMS resource reference was created. Recall that container authentication was chosen. Therefore, choose the authentication alias created earlier from the Container managed authentication alias drop down menu. If application authentication was chosen when the resource reference was created, the Component managed authentication alias drop down menu would be used.

Choose the Node and Server Name from their drop down menus. There should only be one choice in the test environment. The rest of the options configure connection pool management and are listed in the figure below. Click OK.

For publisher subscriber messaging, a topic connection factory would be created instead. As part of creating the topic connection factory, a choice of the JMS server port to be used depends 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 publisher subscriber 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 Pub/Sub support.

Note that MDBs cannot use the direct listener port for publisher subscriber support. Therefore, any topic connection factory configured with a direct port cannot be used with MDBs.

Now that the connection factory is configured, create the destination. Click the Add button for the WASQueue entries. Set the Name to the name of the queue. By convention, the JMS destination name is the name of the queue prefixed by jms/, but it must match with the JNDI setting used earlier when the JMS destination resource environment reference was created. Select the Node from the drop down menu and set Persistence to be PERSISTENT. Normally, this would ensure the message survives a crash or shutdown, but the test environment ignores this setting. The Priority settings control message priority, and the Expiry settings control expiration of messages on the queue. This is shown in the figure below. Click OK.

The server needs to be configured to host the destination just configured. Under the JMS Server Properties section of the JMS tab, click the Add button to add a queue name. Enter the name of the Fulfillment destination just created. Be sure the Initial State is START. This will make sure the JMS server is started as part of the server process startup:

Now create the JMS listener port for the MDB. Switch to the EJB tab and click the Add button for the Listener Ports. Enter a name for the listener port. This name must match the listener port used earlier when the MDB was created or during deployment, it will be necessary to choose a listener port binding for the MDB. The connection factory and destination can be chosen from the drop down menus. The Max messages and Max sessions define concurrency settings for the listener port. Set Max retries to 2. It defines how many times a message can be processed before the listener is shutdown. This prevents processing loops when something goes wrong. The Initial State of START will ensure the listener processes messages as soon as the server is started and is shown in the figure below. Click OK.

Save the changes to the server configuration.

This completes the set up for messaging support in the Plants-By-WebSphere application. When the Plants-By-WebSphere application is run on the test environment server, it will be possible to order a set of items, note their inventory level, and then return to those item descriptions after the order is submitted and notice the inventory levels they have been decremented. If your order exceeds the inventory level, the fulfilment processing will attempt to process the order twice and then shutdown the listener to prevent a processing loop.

Recall earlier that connection properties can be set for a backout threshold and queue. Setting up another queue and these properties will allow the offending message to be removed from the queue so that other messages can be processed rather than shutting down all message processing.

Container Managed Messaging

MDBs provide a component based approach for dealing with inbound message processing. WebSphere Application Server xD provides extensions beyond this to cover container managed outbound messaging, which in conjunction with J2EE MDBs are collectively called Message Beans. The inbound side, covered by MDB support, is abstractly known as Receiver Beans. Sender Beans cover the outbound messaging and convert method calls into outbound messages. Reply support is provided by ReplySender and ReplyReceiver beans.

Managing WebSphere Messaging

This section describes how to use the WebSphere administration console to manage applications that use messaging. We will use the Plants-By-WebSphere application to walk through the setup and management process. There are two ways to manage messaging for WAS. Management of the embedded JMS engine is integrated with the WAS administration console. WebSphere MQ handles administration of the External JMS/MQ engine. This section only addresses use of the administration console for managing the embedded JMS engine.

It is necessary to understand how the embedded JMS engine is integrated into the application server administration. Systems administration is covered in more detail in Chapter 14. Administration is divided into a hierarchy of artifacts starting at the cell level. A cell contains multiple nodes (machines), and each node can contain multiple server processes. Each server process can contain multiple applications and server components or services. The embedded JMS engine is a JMS server component that controls the JMS engine. Installation of WAS creates a default server configuration that includes the JMS server component. Starting a server process using the default server configuration causes the JMS server component (and therefore, the embedded JMS engine) to be started. Stopping a server process that contains a JMS server component will stop the embedded JMS engine. It is recommended that no more than one JMS server component be started on any given node; or another way to phrase this is that since multiple server processes can be started on a given node, care should be taken to ensure that only one of those is configured to contain a JMS server component.

In general, to use JMS messaging, you must create and use a QueueConnectionFactory or TopicConnectionFactory for each unique JMS resource reference in an application. It is possible to map multiple JMS resource references within an application to the same configured connection factory, (for example, different security settings). The Plants-By-WebSphere application uses a single queue connection factory, a single queue, and a single MDB, so these must be added to the server configuration.

The administrative console is used to configure the resources and define a physical JNDI name for each. The resources declared in the application's deployment descriptors are retrieved by the application using a logical JNDI name. We cheated a bit earlier when we created bindings to associate the program's logical JNDI name with the physical resource configured in the server, because the physical resources did not exist yet. Normally, the JNDI binding is defined during deployment. To make things easier during deployment, we will create the physical resource to match the binding using the following steps.

In the Administrative Console, expand the Resources tree and click on the WebSphere JMS Provider link. The page provides access to the connection factories and destinations associated with the embedded JMS engine:

Click on WebSphere Queue Connection Factories to display the currently defined queue connection factories or to prepare to define a new queue connection factory. If the samples were installed with the server, an existing queue connection factory will already exist. We will be creating a separate one:

From here, a new queue connection factory can be created by clicking the New button or an existing queue connection factory can be modified. Click New and create a new connection factory, PBWOrderQCF. Use the same settings as described in the Configuring the Test Environment section. Be sure to enable XA transactions to ensure that the two phase commit scenario will be supported:

A JMS server may exist on any and every node in the WAS administrative cell (see Chapter 12). The Node defines the JMS server to use for hosting this queue. Under the covers, a QueueConnectionFactory creates remote (TCP) XA MQ connections to the server. A TopicConnectionFactory connection may be QUEUED or DIRECT as described earlier. The latter does not support transactions or persistence, but offers better performance.

Important

The embedded JMS Provider does not provide the capability to configure store and forward messaging from one messaging server (queue manager) to another. To communicate using JMS, two applications must agree on the JMS Server (node) that they will use.

In addition to a queue/topic connection factory, you must also define the specific queues and topics, or in general terms, the destination, to be used. From the WebSphere JMS Provider page, click WebSphere Queue Destinations. If the samples were installed, a JMS destination will already exist. We will create a new one:

This page allows a new queue or topic to be created by clicking the New button. Clicking an existing queue name can be used to browse or modify existing queues. Queues and topics listed here will be created or modified automatically when the JMS Server starts up. Click New to create a new queue:

The settings are the same as those in the Configuring the Test Environment section. Set the Name to FulfillmentQueue and the JNDI Name to jms/FulfillmentQueue. Set Persistence to PERSISTENT and click OK.

The connection factory and queue setup are now complete.

A separate JMS listener will need to be configured for the MDB to bind to during deployment. Here are the steps:

Expand the Servers tree on the left-side navigation panel and click the Application Servers link. Click server1 (or whatever server will be used to deploy the application) on the right-side detail panel. In the Additional Properties list, locate Message Listener Service and click it. Now locate Listener Ports and click it. Click New on the Listener Ports detail panel to create a new Listener Port:

Here, set the Name to OrderReceiverListenerPort, Connection Factory JNDI name to jms/FulfillmentQCF, Destination JNDI name to jms/FulfillmentQueue, and Maximum retries to 2 for the reasons described in the Configuring the Test Environmentsection. Click OK.

Click the Save menu item at the top of the page and save the configuration. This completes the necessary setup to run the application on WAS. You will need to restart your server before these resources will become active.

When deploying our EAR file, there are a few additional configuration steps we need to look out for. First up we need to choose the listener port for our MDB:

We also have to map the QueueConnectionFactory and Queue:

Scalability and Availability

WebSphere messaging provides support for managing the scalability and availability of the messaging server. These are detailed in the sections below.

Queue Manager Availability

The set of circumstances under which a queue manager fails but the node remains available is very limited. While it is possible for an individual disk to fail, in which case another queue manager using another disk might be able to continue, under most circumstances, if the queue manager is down the chances are that the node is down as well. Clustering provides fail-over support, which should prevent the need for multiple cluster managers on a node.

Queue Manager Clustering

With an external MQSeries provider, queue managers may be connected into a queue manager cluster. The queue manager cluster provides:

• Simplified systems management

• Queue hosting across queue managers in the cluster

• Round robin distribution of messages to each queue manager for load distribution

• Fail over of queue managers in the cluster

Note that workload management is only performed when a Queue Connection Factory is configured to deliver messages to a remote node in the cluster. It will not happen if the queue manager is local. Configuration of the cluster should take into consideration JMS client distribution across nodes in a cell if clustering is desired. In such cases, a separate set of clustered JMS server nodes are used to ensure the client components running within a WAS are not on the same node as the node hosting the queue.

Shared Queues

MQSeries for z/OS provides a feature similar to queue manager clustering called Shared Queues, but it has faster recovery capabilities than its counterpart. A Shared Queue is a Queue that is held in the Coupling Facility, and managed by a set of Queue Managers that form a Queue Sharing Group. The Coupling Facility provides:

• Highly available access to the Shared Queue

• Tolerance of failure of up to n 1 of the n Queue Managers in the Queue Sharing Group

• Alternative Queue Manager access to all messages (including those with in-flight transaction) should a Queue Manager fail

To use Shared Queues, it is necessary to have a Coupling Facility and a DB2 Data Sharing Group.