WebSphere Message Broker does not provide any unique programming interfaces, but supports several programming interfaces that are already in use by messaging applications today.
The MQI provides a small number of calls that allow an application to interact with other applications across a WebSphere MQ network of 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 as to language or function are defined by the relevant product for that operating system.
The MQI is described in the WebSphere MQ Application Programming Guide and WebSphere MQ Application Programming Reference. These books also give details of the programming language and operating system support available for clients that use this interface.
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 message 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. Check the current level of the WebSphere MQ Application Messaging Interface book for details, or visit the WebSphere MQ web site.
The JMS is an application programming interface that provides Java language functions for handling messages. Developed by messaging vendors, including IBM in partnership with Sun Microsystems, Inc., the JMS API provides a common interface to access different enterprise messaging systems, including WebSphere MQ. This interface is appropriate for point-to-point and publish/subscribe applications.
Messaging clients in JMS are called JMS clients, and the messaging system is called the JMS provider. A JMS application is a business system that comprises JMS clients and at least one JMS provider. Client applications using the JMS interface are written in the Java programming language, and are therefore restricted to the levels of JVM that are supported on the operating system in question. For further information, see the WebSphere MQ Using Java book, or visit the WebSphere MQ web site.
These calls are described in WebSphere MQ Mobile Transport.
These messages are described in WebSphere MQ Telemetry Transport.
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 across the supported protocols, using the appropriate input and output nodes. WebSphere Message Broker provides built-in input and output nodes for its supported protocols and you can create your own user-defined nodes to support additional protocols if you choose.
You can also create new end-user applications to interact with the broker.
WebSphere Message Broker provides parsers for a large number of WebSphere MQ headers, and can therefore accept messages that contain these headers across the WebSphere MQ Enterprise Transport, WebSphere MQ Mobile Transport, and WebSphere MQ Telemetry Transport protocols.
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:
When a message is processed by a WebSphere Message Broker 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:
Use the MQRFH2 header in all new applications written for the WebSphere Message Broker environment that use a supported protocol based on WebSphere MQ technology. The MQRFH2 header should 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).
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac00455_ |