Understanding reverse proxy

This topic outlines the rationale for configuring a reverse proxy, and how this is used to support a consistent Public URL in a flexible deployment topology. Follow-on articles in this series will provide detailed deployment guidance for setting up reverse proxying.

Other topics in this series

• Install Proxy Servers
• Configure a Reverse Proxy Server with WebSphere plugins
• Configuring Enterprise CLM Reverse Proxies: WebSphere 8 and IHS 8
• Configuring Enterprise CLM Reverse Proxies: Apache and mod_proxy
• Configuring Enterprise CLM Reverse Proxies: WebSphere 8.5 ND Proxy

Why use a reverse proxy?

One crucial piece to a successful deployment of the reverse proxy configuration is understanding what you are going to accomplish and what problems this will not solve for you. First and formost, the benefit of using a reverse proxy is the ability to mask the complexity of the underlying deployment from your end users.

Figure 1: Fully distributed CLM enterprise topology example

In order to fully distribute your deployment, complexity has been added in that a user of the Rational solution for CLM must connect to 4+ different servers, as well as manage the different ports and context roots involved. The benefit here is the simplicity of the deployment. A fully distributed topology is allowed for, the deployment details are transparent to the user, and there is a minimum amount of complexity in how to connect the applications together. The big downside is that the implementation details have become part of the deployment; this may include ports and machine names that are not standard and with the underlying requirement to never change the Public URL2 this can make infrastructure level changes difficult tasks.

One alternative approach is to use a reverse proxy server to "listen" on your public URL and allow for the underlying deployment to vary. This is a common technique for hosting applications for security and load balancing reasons and a standard feature of the IBM WebSphere and HTTP Server plugin architecture that will be discussed a bit further on in the article.

Figure 2: Using a reverse proxy in your topology

Now this approach gives the deployment more flexibility at the added complexity of managing an additional system to host the reverse proxy itself. The added complexity is has been the main stumbling point for many people who have avoided this type of deployment. This series of articles are intended to provide some additional to help overcome the initial hurdles to a successful reverse proxy deployment.

What a reverse proxy will and will not do

A reverse proxy here can help introduce a layer of abstraction between the public URL and the underlying deployment, but this is not going to solve any problems that require actually changing the public URL the same requirements apply as covered in You can't change the public URL. Below are a few common variations of the same questions:

NO - Change the server name, port, context root, or protocol of the public URL. While it is possible for the server to respond to different URLs, the application content and logic depend on the public URL. It is possible to test the server and access the system via the direct machine name or IP address in the browser address, but the application navigation and content will contain the public URL.

YES - Allow for the current public URL or URLs to be hosted while the underlying deployed server topology is changed. By hosting the public URL via a web or proxy, the underlying deployment is free to change while the external URL remains fixed.

YES - Consolidate multiple public URLs to be served from a single location. This does not change the public URL, but potentially provides the opportunity to unify your deployment and share resources (the same physical machine, a web server, or transparent caching server).

NO - Use existing web, proxy, and other network infrastructure to rewrite URLs directly inside of content and header responses. While there are various technologies that can handle this functionality for you, this is unsupported with Jazz and may cause data integrity issues for consumers and if invalid URL references are written back to the Jazz system without the valid public URL.

YES - Use existing web, proxy, and other network infrastructure to listen on various URLs to help direct users to the correct system via forwarding. It is possible to listen on other URLs that your users may request and forward the requests to the public URL. For instance, a CCM server with a public URL of https://clm.example.org:9443/ccm might have a fronting web/proxy to listen on variation URLs such as https://clm.example.org/ccm to forward traffic to the correct port of the public URL, simplifying the user experience but not changing the public URL.

Related topics: Deployment planning: Where to start?, Maintaining the public URL, Proxy server installation, Configuring Enterprise CLM Reverse Proxies: WebSphere 8 and IHS 8, Configuring Enterprise CLM Reverse Proxies: Apache and mod_proxy, Configuring Enterprise CLM Reverse Proxies: WebSphere 8.5 ND Proxy

External links:

• Rational solution for Collaborative Lifecycle Management Information Center
• Rational solution for systems and software engineering Information Center
• WebSphere Application Server 7 Information Center
• WebSphere Application Server 8.0 Information Center
• WebSphere Application Server 8.5 Information Center

Additional contributors: None