Native MQ Transport User Guide

Interoperability with WebSphere MQ

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. Tuning guidelines for WebSphere MQ are also provided.

Using WebSphere MQ Using JMS in ALSB

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

WebLogic Server's foreign JMS server specifies the initial context factory, connection factory, and queue to the WebSphere MQ server. For details, 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 via ALSB

Messages sent via ALSB

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

Messaging Types

The following sections provide an overview of 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

Because the WebSphere MQ for Java APIs do not support XA transactions, ALSB does not support XA transactions for the Native MQ transport. If XA is required, JMS transport with WebSphere MQ JMS interface should be used. For more information, see Interoperability Solutions for JMS.

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 the flushing of the hard disk.
To avoid broken ALSB JMS connections to MQ queues, increase the number of active channels is to more than 100. By default, the number of active channels is 10.