Introduction to IBM MQ bridge for HTTP
The IBM MQ bridge for HTTP is a Java™, Enterprise Environment (JEE) Web application. HTTP clients can send POST, GET, and DELETE requests to it to put, browse and delete messages from IBM MQ queues. The IBM MQ bridge for HTTP is not suitable for use with messages, if assured delivery is required.
Benefits
With the IBM MQ bridge for HTTP we can send and receive IBM MQ messages using HTTP from a wide variety of environments:HTTP support can be used with both point-to-point and publish/subscribe messaging topologies.
- Environments that support HTTP, but not IBM MQ.
- Environments that have insufficient storage space to install an IBM MQ MQI client.
- Environments that are too numerous to install the IBM MQ MQI client on each system that requires access to IBM MQ.
- Web-based applications from which you want to send or receive messages without coding your own bridge to IBM MQ.
- Web-based applications to enhance, using asynchronous techniques such as AJAX. IBM MQ bridge for HTTP makes IBM MQ queues and topics available using Representation State Transfer (REST) over HTTP.
How does HTTP support work?
The IBM MQ bridge for HTTP Web application receives HTTP requests from one or more clients. It interacts with IBM MQ on their behalf, and returns HTTP responses to them.The IBM MQ bridge for HTTP is a JEE servlet that is connected to IBM MQ using a resource adapter. The HTTP servlet handles three different types of HTTP requests: POST, GET, and DELETE.
Table 1. IBM MQ bridge for HTTP verbs HTTP Request Result POST Puts a message on a queue or topic. GET Browses the first message on a queue. In line with the HTTP protocol, GET does not delete the message from the queue. Do not use GET with publish/subscribe messaging. DELETE Gets and deletes a message from a queue or topic.
HTTP POST example
HTTP POST puts a message to a queue, or a publication to a topic. The HTTPPOST Java sample is an example an HTTP POST request of a message to a queue. Instead of using Java, you could create an HTTP POST request using a browser form, or an AJAX toolkit instead.
The following figure shows an HTTP request to put a message on a queue called myQueue. This request contains the HTTP header x-msg-correlId to set the correlation ID of the IBM MQ message.
The following figure shows the response sent back to the client. There is no response content.
HTTP DELETE example
HTTP DELETE gets a message from a queue and deletes the message, or retrieves and deletes a publication. The HTTPDELETE Java sample is an example an HTTP DELETE request reading a message from a queue. Instead of using Java, you could create an HTTP DELETE request using a browser form, or an AJAX toolkit instead.
The following figure shows an HTTP request to delete the next message on queue called myQueue. In response, the message body is returned to the client. In IBM MQ terms, HTTP DELETE is a destructive get.
The request contains the HTTP request header x-msg-wait, which instructs IBM MQ bridge for HTTP how long to wait for a message to arrive on the queue. The request also contains the x-msg-require-headers request header, which specifies that the client is to receive the message correlation ID in the response.
The following figure shows the response returned to the client. The correlation ID is returned to the client, as requested in x-msg-require-headers of the request.
HTTP GET example
HTTP GET gets a message from a queue. The message remains on the queue. In IBM MQ terms, HTTP GET is a browse request. You could create an HTTP GET request using a Java client, a browser form, or an AJAX toolkit.
The following figure shows an HTTP request to browse the next message on queue called myQueue.
The request contains the HTTP request header x-msg-wait, which instructs IBM MQ bridge for HTTP how long to wait for a message to arrive on the queue. The request also contains the x-msg-require-headers request header, which specifies that the client is to receive the message correlation ID in the response.
The following figure shows the response returned to the client. The correlation ID is returned to the client, as requested in x-msg-require-headers of the request.