Skip Navigation Links | |
Exit Print View | |
![]() |
Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Part I Introduction to Message Queue Administration
1. Administrative Tasks and Tools
3. Starting Brokers and Clients
6. Configuring and Managing Connection Services
8. Configuring Persistence Services
9. Configuring and Managing Security Services
10. Configuring and Managing Broker Clusters
11. Managing Administered Objects
12. Configuring and Managing Bridge Services
13. Monitoring Broker Operations
14. Analyzing and Tuning a Message Service
17. Broker Properties Reference
18. Physical Destination Property Reference
19. Administered Object Attribute Reference
20. JMS Resource Adapter Property Reference
21. Metrics Information Reference
22. JES Monitoring Framework Reference
A. Distribution-Specific Locations of Message Queue Data
B. Stability of Message Queue Interfaces
Step 1 (HTTPS Only): Generating a Self-Signed Certificate for the Tunnel Servlet
Step 2 (HTTPS Only): Specifying the Key Store Location and Password
To Specify the Location and Password of the Certificate Key Store
Step 3 (HTTPS Only): Validating and Installing the Server's Self-Signed Certificate
To Validate and Install the Server's Self-Signed Certificate
Step 4 (HTTP and HTTPS): Deploying the Tunnel Servlet
To Deploy the HTTP or HTTPS Tunnel Servlet
Modifying the Application Server's Security Policy File
Step 5 (HTTP and HTTPS): Configuring the Connection Service
To Activate the httpjms or httpsjms Connection Service
Step 6 (HTTP and HTTPS): Configuring a Connection
Installing a Root Certificate (HTTPS Only)
Configuring the Connection Factory (HTTP and HTTPS)
Using a Single Servlet to Access Multiple Brokers (HTTP and HTTPS)
Client Failure to Connect Through the Tunnel Servlet
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.