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 we have added some complexity in that a user of the CLM solution needs to 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, we allow for a fully distributed topology 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 URL² 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 we will look at 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 stubmling point for many clients 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.

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 article #686 ². 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(s) 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 in any way but potentially provides the opportunity to unify your deployment and share resources (aka the same physical machine, a Web Server, or transparent caching server )

NO – Using 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 like 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.