Introduction to the MQ Transport

ALSB supports access to IBM WebSphere^® MQ using the MQ Transport. This transport supports both inbound and outbound connectivity. MQ proxy services can receive messages from WebSphere MQ and MQ business services can route messages to WebSphere MQ.

Key Features

Inbound and outbound connectivity. MQ proxy services can receive messages from WebSphere MQ and MQ business services can route messages to WebSphere MQ.
Access to WebSphere MQ version 5.3 and 6.0. For more information, see Adding MQ Client Libraries to Your Environment.
Sending and receiving messages of Any XML, Binary, XML, Text and MFL types.
Processing of all the MQMD (MQ message descriptor) headers. A message descriptor is an attribute representing a property of the message that is either being sent or received.

For a list of MQ headers that can be configured for outbound response and inbound requests, see Transport Headers.

TCP/IP and bindings mode for connecting to queue managers.

Use the bindings mode to connect to WebSphere MQ that is located on the same physical machine as ALSB. Use TCP/IP to connect to WebSphere MQ that does not reside on the same machine as ALSB.

One-way and two-way SSL on inbound and outbound transport.

SSL is supported only when TCP/IP is used to connect to WebSphere MQ from ALSB.

Advantages of Using the MQ Transport

Using the MQ transport has the following advantages over using the WebSphere MQ JMS interface:

Faster connection to WebSphere MQ through the MQ transport than through the WebSphere MQ JMS interface.
Ability to read and generate MQ messages. Using the JMS interface, it is not possible to set certain headers.
Support for sending and receiving MQ receipt messages.
No explicit binding of MQ Connection Factory and MQ Queue to WebLogic’s JNDI is required.
Configuration of resources like a JMS provider, outside of ALSB, is not required.
Performance improvement because messages are sent directly using the transport instead of channeling them through the JMS transport.

Supported Service Types

The MQ transport is available for the Message Service and XML Service service types.

Messaging Patterns

The Native MQ transport supports one-way and request-response messaging patterns for both inbound and outbound connectivity. By default, one-way messaging is supported. A proxy or business service supports request-response messaging when you set the is-response-required option while configuring the service.

The inbound and outbound transports support the asynchronous request-response pattern using messageID or correlationID for correlation between the request and the response. You can set the response correlation pattern during service configuration. For more information, see “CorrelationID” and “MessageID” in Transport Headers.

The outbound transport provides an option to auto-generate the correlation ID / messageID or use the one specified by you in the message flow. Select the Auto-generate Correlation Value option, to indicate that the correlation ID / message ID should be auto-generated by the transport. If the option is not selected, the value specified by you in the message flow is used.

If the correlation value (messageID / correlationID) is not auto-generated and if the managed server goes down, the remaining response messages may never get removed when the server is restarted. BEA recommends that the Expiry header on the request is configured to a finite value and that the Report header contains the MQC.MQRO_PASS_DISCARD_AND_EXPIRY option. The MQC.MQRO_PASS_DISCARD_AND_EXPIRY option serves as a directive to the receiving client that the message descriptor of the reply should inherit the Expiry header value of the request message. This ensures that the response messages are removed by the MQ server after the configured expiry period has elapsed. When the correlation value is automatically generated, the ALSB server is responsible for cleaning up any remaining response messages.

For more information about configuring Is Response Required, Response Correlation Pattern, Auto Generate Correlation Value for a service, see Configuring Proxy Services to Use the Native MQ Transport and Configuring Business Services to Use the Native MQ Transport.

Environment Values

Environment values are certain predefined fields in the configuration data whose values are very likely to change when you move your configuration from one domain to another (for example, from test to production). For information about updating environment values, see Finding and Replacing Environment Values in Using the AquaLogic Service Bus Console. The following sections provide a list of environment values for the Native MQ transport services and the MQ connection resource.

Services based on the MQ transport support the Work Manager (Inbound and Outbound) environment value.

MQ connections are sharable resources that can be reused across multiple MQ proxy and business services. MQ Connection resources provide the connection parameters required for connecting to a MQ queue manager. The MQ connection resource supports the following environment and operational values:

MQ Connection Host Name
MQ Connection Port
MQ Queue Manager Name
MQ Channel Name
MQ Connection Pool Size
MQ Connection Timeout

For information about updating environment values, see Customization in Using the AquaLogic Service Bus Console.

Quality of Service

When the inbound transport is MQ and the Quality of Service (QoS) on the outbound transport is exactly-once, the resultant QoS will be at-least-once. By default, the QoS on the outbound transport is exactly-once.

When the outbound is request-response, the QoS is at-least-once only if the outbound transport is configured to support exactly-once QoS.

For more information about QoS in ALSB messaging, see “Quality of Service” in Modeling Message Flow in ALSB in the AquaLogic Service Bus User Guide.

MQ Clusters and the MQ Transport

The cluster support in WebSphere MQ is that of store-and-forward messaging and not of load-balancing and fail over. The cluster queues in WebSphere MQ are created locally on one of the queue managers and shared with other cluster members that act as remote forwarders to the shared queue.

Requests from the MQ transport are load balanced by sending messages using the load balancing algorithm to the members of the cluster. However, the transport receives messages by accessing only the MQ server node that holds the reference to the local queue.

MQ Transport User Guide