HTTP/HTTPS Support Architecture

Message Queue’s support architecture is very similar for both HTTP and HTTPS support, as shown in Figure C–1:

• On the client side, an HTTP or HTTPS transport driver (part of the Message Queue client runtime) encapsulates each message into an HTTP request and makes sure that these requests are transmitted in the correct sequence.

• If necessary, the client can use an HTTP proxy server to communicate with the broker. The proxy’s address is specified using command line options when starting the client; seeUsing an HTTP Proxy for more information.

• An HTTP or HTTPS tunnel servlet (both bundled with Message Queue) is loaded into an application server or Web server on the broker side and used to pull payload messages from client HTTP requests before forwarding them to the broker. The tunnel servlet also sends broker messages back to the client in response to the client’s HTTP requests. A single tunnel servlet can be used to access multiple brokers.

• On the broker side, the httpjms or httpsjms connection service unwraps and demultiplexes incoming messages from the corresponding tunnel servlet.

Figure C–1 HTTP/HTTPS Support Architecture

The main difference between HTTP and HTTPS connections is that in the HTTPS case (httpsjms connection service), the tunnel servlet has a secure connection to both the client application and the broker. The secure connection to the broker is established by means of the Secure Socket Layer (SSL) protocol. Message Queue’s SSL-enabled HTTPS tunnel servlet passes a self-signed certificate to any broker requesting a connection. The broker uses the certificate to establish an encrypted connection to the tunnel servlet. Once this connection is established, a secure connection between the client application and the tunnel servlet can be negotiated by the client application and the application server or Web server.