MQ Transport User Guide

Using the WebSphere JMS MQ Interface

The WebSphere MQ for Java APIs do not support XA transactions. Consequently, ALSB does not support XA transactions for the MQ transport. If XA is required, you can use the WebSphere MQ JMS interface.

The following sections outline how ALSB connects to WebSphere MQ and presents an overview of some message types used in communication between WebSphere MQ and ALSB.

Using the WebSphere MQ JMS Interface

ALSB connects to WebSphere MQ via the WebSphere MQ JMS interface. That is, ALSB is a WebSphere MQ JMS client.

The foreign JMS server in WLS specifies the initial context factory, connection factory, and queue to the WebSphere MQ server. For more information, see Configuring Foreign Server Resources to Access Third-Party JMS Providers in Configuring and Managing WebLogic JMS.

WebSphere MQ JMS supports two transport types:

BINDINGS
CLIENT

If the WebSphere MQ JMS client is running on the same physical machine as the queue manager, it is possible to set the transport type to BINDINGS. Otherwise, you can use only the CLIENT type.

WebSphere MQ can interface with ALSB in two ways:

ALSB acts as the front-end of WebSphere MQ to accept service requests from other applications and converts them to WebSphere MQ requests. See Figure 3-1.
WebSphere MQ sends messages to other applications through ALSB. See Figure 3-2.

Figure 3-1 ALSB Front End

ALSB Front End

Figure 3-2 Messages sent through ALSB

Messages sent through ALSB

ALSB is configured in the ALSB Console, which is described in Using the AquaLogic Service Bus Console.

Messaging Types

ALSB supports the following messaging types:

Non-Persistent Messaging

If you decide to accept an unreliable delivery, such as some missing requests, you can use non-persistent messages where appropriate. WebSphere MQ logging and WebLogic JMS message persistence are only performed for persistent messages; therefore, the use of non-persistent messages eliminates any related I/O activity.

Note:

Non-persistent message throughput is usually limited by the processor speed of the machine. However, in case of a shortage of physical memory, the server system may consume CPU cycles on a paging I/O.

Non-XA Persistent Messaging

WebSphere MQ persistent message throughput is usually limited by the queue manager and the I/O latency writing to the log.

XA Messaging

To enable support for transactional (XA) access to queues, use:

BINDINGS to access the queue manager when ALSB is co-located with IBM WebSphere MQ
CLIENT when ALSB and IBM WebSphere MQ are on different machines. However, with CLIENT, you need a special version of the IBM WebSphere MQ client that supports XA transactions, called the WebSphere MQ Extended Transaction Client.

Tip:

For the deployment descriptors to be set appropriately for XA capable resources (JMS, TUXEDO, EJB), you must set the XA attribute on the referenced connection factory before creating a proxy service.

Tuning WebSphere MQ

The following guidelines help you tune WebSphere MQ when you are working with ALSB. For detailed WebSphere MQ information, refer to relevant WebSphere MQ documentation.

Use the BINDINGS transport type if ALSB and the queue manager are deployed on the same machine.
If you need XA for only a small section of application requests, create a separate connection object and disable XA.
Distribute active logs across many volumes. If your system is required to handle high persistent message throughput, you must place the log files on a fast Direct Access Storage Device (DASD) with a minimum of contention from other data set usage. Ideally, you can allocate each of the active logs on separate, low-usage volumes.
To reduce buffer overflow, tune the buffer pools and pagesets. Buffer overflow results in flushing of the hard disk.
To avoid broken ALSB JMS connections to MQ queues, increase the number of active channels to more than 100. By default, the number of active channels is 10.