Network Deployment (Distributed operating systems), v8.0 > Applications > Messaging resources > Interoperation with WebSphere MQ > Interoperation using the WebSphere MQ messaging provider
Enhanced features of the WebSphere MQ messaging provider
The WebSphere MQ messaging provider enables WAS applications and clients to connect to and use WebSphere MQ resources in a JMS-compliant manner. This provider includes the enhanced features described in this topic.
Overview
The WebSphere MQ messaging provider has enhanced administrative options supporting the following functions:
- WebSphere MQ channel compression
- WebSphere MQ client channel definition table
- Client channel exits
- Transport-level encryption by using SSL
- Automatic selection of the WebSphere MQ transport type
WebSphere MQ channel compression
Data sent over the network between WAS and WebSphere MQ can be compressed, reducing the amount of data that is transferred. Channel compression can be beneficial in the following situations:
- If a cost is incurred that is proportional to the amount of data transferred over a network. For example, nodes in a network might span a leased line for which a utilization charge is applied.
- If the rate at which messaging data can be transferred across a network is the limiting factor in the performance of an application.
- If compressing the data might reduce the cost of its encryption and decryption.
To use WebSphere MQ channel compression, configure the message compression properties of an existing connection factory or activation specification. See the appropriate step within Configure JMS resources for the WebSphere MQ messaging provider.
See the WebSphere MQ topic Channel compression in the WebSphere MQ information center that is part of the WebSphere MQ library.
WebSphere MQ client channel definition table
The client channel definition table reduces the effort required to configure a connection to a queue manager. Your WebSphere MQ administrator can create a single table of all the WebSphere MQ channels supported by queue managers in the enterprise, then in WAS you configure a connection to a queue manager by identifying the client channel definition table and providing any additional information not already contained within the table.
We can also use the client channel definition table to provide a basic failover capability, by specifying that a connection is attempted against several queue managers listed in the table. Each suitable channel definition is tried in turn until a queue manager connection is successfully established.
We can use the client channel definition table, with WebSphere MQ messaging provider activation specifications and connection factories, to select the client channel definition to use when establishing a connection to WebSphere MQ. The table can be configured to select from a number of queue managers, depending on their availability.
When you use a client channel definition table, note the following restrictions:
- If your client channel definition table can select from more than one queue manager, you might not be able to recover global transactions.
Activation specifications and connection factories that specify a client channel definition table must either do so without ambiguity as to the target queue manager, or must avoid using the resources with applications that enlist in global transactions.
- If your client channel definition table contains channel definitions that reference native WebSphere MQ channel exits, the use of these channel definitions is not supported in the WAS environment.
For more information about client channel definition tables, see the developerWorks article WebSphere MQ V6 Java and JMS clients and the client channel definition table, and the WebSphere MQ topic Client channel definition table.
To use a client channel definition table, specify it when you create a new activation specification or connection factory.
Client channel exits
Client channel exits are pieces of Java code that you develop, and that run in the application server at key points during the life cycle of a WebSphere MQ channel. Your code can change the runtime characteristics of the communications link between the WebSphere MQ messaging provider and the WebSphere MQ queue manager.
Only client channel exits written in Java are supported for use within the WAS environment.
For more information about client channel exits, see the WebSphere MQ topic Channel exit programs. For a list of the channel exits that work with the WebSphere MQ messaging provider, see the client connection channel row of the table in the WebSphere MQ topic What are channel exit programs?.
To use client channel exits, configure the client transport properties of an existing connection factory or activation specification.
Transport-level encryption by using SSL
Transport-level encryption by using SSL is the supported way to configure SSL for JMS resources associated with the WebSphere MQ messaging provider. The SSL configuration is associated with the communication link for the connection factory or activation specification. You either define the SSL information in the connection factory, or your WebSphere MQ administrator defines the SSL information in an associated client channel definition table.
Automatic selection of the WebSphere MQ transport type
The WebSphere MQ messaging provider supports the following ways to connect to a WebSphere MQ queue manager:
- Bindings mode (or call attach)
- Bindings mode attachment is only possible if the queue manager is located on the same physical machine as the WAS. Bindings mode attachment, where available, typically offers better performance.
- Client mode (or socket attach)
- Client mode attachment can be used wherever the WebSphere MQ queue manager and WAS can establish a network connection to one another.
- Bindings mode, then client mode (automatic selection)
- This method tries a bindings mode connection first and, if that fails, a client mode connection is tried.
Every node in a WAS cluster shares identical configuration information. With automatic selection of the WebSphere MQ transport type, all the servers in a cluster can be configured to automatically select their transport.
This has the effect that any clustered server that is co-located with a queue manager establishes a bindings mode connection to the queue manager, whereas other servers in the cluster establish client mode connection to the queue manager.
Interoperation using the WebSphere MQ messaging provider
Introduction: Messaging resources
Choosing a messaging provider
Configure JMS resources for the WebSphere MQ messaging provider
Concept topic