Using the IBM MQ service provider
The IBM® MQ service provider that is supplied with IBM z/OS® Connect allows REST aware applications to interact with z/OS assets that are exposed by IBM MQ for z/OS queues and topics without the need to use asynchronous messaging APIs.
All the capabilities of IBM z/OS Connect to expose APIs, are supported by the IBM MQ service provider.
Setting up the IBM MQ service provider consists mainly of configuration tasks. The REST application does not need to be aware of IBM MQ. However, access to items such as MQMD fields is provided for more advanced applications.
The IBM MQ service provider exposes IBM MQ queues and topics as services. For more information, see Service types.
Supported versions of IBM MQ
The IBM MQ service provider is supported by IBM MQ for z/OS Version 8.0 and later.
The IBM MQ service provider was originally included as part of IBM MQ 9.0.1, and is still available as part of IBM MQ 9.1.0. Customers who are using this earlier version of the IBM MQ service provider should upgrade to the version that is built into IBM z/OS Connect. For more information about migrating, see Migrating a service to the IBM MQ service provider in IBM z/OS Connect.
This documentation refers to the IBM MQ service provider that is built into IBM z/OS Connect. For more information about the IBM MQ service provider that is included with IBM MQ 9.1.0, see IBM MQ for z/OS Service Provider for IBM z/OS Connect EE in the IBM MQ documentation.
Connection modes
- Bindings mode
- In bindings mode, connections are made directly to the queue manager by using the Java Native Interface (JNI).
Bindings mode connections tend to provide better performance than client mode but require the IBM z/OS Connect server and IBM MQ queue manager to be running in the same LPAR.
In bindings mode, you must enable the TXRRS authorized service. For more information, see Configuring the Liberty Angel process and z/OS authorized services and the sample scenario Create a server to connect to IBM MQ.
- Client mode
- In client mode, connections to the queue manager are made over TCP/IP.
Client mode connections allow greater flexibility than bindings mode as the IBM MQ queue manager can be running on a different z/OS LPAR to the IBM z/OS Connect server. However, they require more configuration, which might include setting up TLS. Client mode connections typically do not perform as well as bindings mode connections.
Both connection modes are supported by the IBM MQ service provider, regardless of the version of MQ for z/OS that they connect to.
transportType property in the
properties.wmqJms section of the connection factory in the
server.xml file of the IBM z/OS Connect server:- A
transportTypeof BINDINGS allows bindings mode connections. - A
transportTypeof CLIENT allows client mode connections.
If client mode connections are required, you also need to set the channel,
hostName, and port properties and if TLS is being used, the SSL
attributes. For more information about these properties, see WebSphere® MQ JMS queue connection factory
properties in the WebSphere Application Server Liberty documentation.
Feature configuration
<feature>zosconnect:mqService-1.0</feature>zosconnect:mqService-1.0, any dependent features are
automatically included. For more information, see the task Create a server to connect to IBM MQ in the example scenario.Other considerations
The IBM MQ service provider uses optional HTTP headers to specify overrides, such as MQMD values.
IBM MQ messages consists of both payload and properties. When HTTP requests are sent to the IBM MQ service provider the JSON content of the request is sent as the payload of a message. When a message is returned as part of an HTTP response, only the message payload is returned as part of the HTTP response body. Therefore, applications are not exposed to IBM MQ concepts if all they need is the message data.
The IBM MQ Service Provider uses the IBM MQ resource adapter support in WebSphere Application Server Liberty profile and is based on JMS.