- Message Queue Interface (MQI)
The MQI provides a few calls that allow an application to interact with other applications in a network of WebSphere MQ queue managers. The calls support a large range of parameters that allow a rich choice of processing options for each and every message.
Client applications using the MQI can run on any supported WebSphere MQ operating system, and therefore any limitations that are enforced for language or function are defined by the relevant product for that operating system.
The MQI is described in the Application Programming Reference and Application Programming Guide sections in the
WebSphere MQ Version 7 product documentation online . Details are also
provided of the programming language and operating system support
available for clients that use this interface. - Application Messaging Interface (AMI)
The AMI is designed to simplify the application programmer's task by centralizing the selection of optional parameters outside the application program. It also provides support for the more advanced functions available from the broker. The AMI is designed for general messaging applications with and without a broker.
The principal functions of the AMI are administrator-defined packets of options known as policies and services. An application specifies a service to determine the underlying messaging support required, and associates a policy with sending or receiving a message to control attributes for message processing, such as priority.
The policies and services mean that the application does not have to understand details of the MQRFH2 header and the MQI interface.
Client applications using the AMI are restricted to the operating systems and programming languages supported by this interface. The AMI is defined in the Publish/Subscribe User's Guide section in the
WebSphere MQ Version 7 product documentation online.
If you have existing end-user applications that are written to these interfaces, they can typically run unchanged in a broker environment. You must create the message flows to interact with these applications from the supported protocols, using the appropriate input and output nodes. IBM Integration Bus provides built-in input and output nodes for its supported protocols and you can create your own user-defined nodes to support additional protocols.
You can also create new end-user applications to interact with the broker.
Message headers
IBM Integration Bus provides parsers for many WebSphere MQ headers, and can therefore accept messages that contain these headers from the WebSphere MQ Enterprise Transport protocol.
Messages must include a WebSphere MQ Message Descriptor (MQMD) as the first header, which must precede user or application data in every message. The MQMD contains basic control information that must travel with the message, including:
- The message identifier
- The destination of the reply, if one is to be sent
- Reply and report options (for example, confirm on delivery report)
- The format of any following data in the message
When a message is processed by an IBM Integration Bus broker, it typically (but not necessarily) has one or more additional headers. The header following the MQMD is always identified in the format field within the MQMD, and itself contains another format field to identify either the header that follows, or the format of the user data.
The additional headers can include:
- MQRFH
- The Rules and Formatting header is used by WebSphere MQ Publish/Subscribe.
- MQRFH2
- The MQRFH2 is an updated version of MQRFH and allows Unicode strings
to be transported without translation, and it can carry numeric data
types. The MQRFH2 header carries a description of the message contents,
so that IBM Integration Bus can select the
correct message parser when content-based processing is carried out
on the message. In addition, this header contains publish/subscribe
command messages.
Use the MQRFH2 header in all new applications written for the IBM Integration Bus environment that use a supported protocol based on WebSphere MQ technology. The MQRFH2 header must be immediately before the body of the message (that is, the last header).
If an MQRFH2 header is not included (which is normally the case of the application uses a supported protocol that is not based on WebSphere MQ technology), you must configure the message flow that processes its messages to specify the message characteristics (by setting the input node properties).
Last updated Friday, 21 July 2017