Configuring Enterprise CLM Reverse Proxies, Part 1: Understanding Reverse Proxy

Please be aware:The content of this article has been migrated to the Deployment wiki: Understanding reverse proxy topic page. The content will be maintained and updated in the wiki going forward. Therefore, this version of the article might not contain the most up to date information.

All deployment guidance and best practice will be published in the Deployment wiki rather than as articles going forward.

This article outlines the rationale for configuring a reverse proxy, how this is used to support a consistent Public URL in a flexible deployment topology. Provided in some follow on articles in this series will be some detailed deployment guidance for setting up reverse proxying.

Other articles in this series:

Understanding why to 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.

Fully distributed            CLM enterprise topology example
Figure 1: Fully distributed CLM enterprise topology example1

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 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 we will look at a bit further on in the article.

Using a reverse proxy            in your topology
Figure 2: Using a reverse proxy in your topology3

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.

Understanding what a reverse proxy 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 article #686 2. 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 might have a fronting web/proxy to listen on variation urls like to forward traffic to the correct port of the public URL, simplifying the user experience but not changing the public URL.


Related Content

  1. Collaboratice Lifecycle Management 3.0.1 Information Center
  2. Using content caching proxies for Jazz Source Control
  3. WebSphere 7 Information Center


  1. Collaboratice Lifecycle Management 3.0.1 Information Center: Fully distrubuted CLM enterprise topology example
  2. Moving Jazz Servers and URI Stability with CLM 2011
  3. Collaboratice Lifecycle Management 3.0.1 Information Center: Using a reverse proxy in your topology
  4. Rational Team Concert 3.0.1 English Licence Agreement

About the authors

Sean Wilbur works in the Rational Unleash the Labs team and with the Jazz JumpStart team providing support for clients adopting and evaluating Rational solutions across the globe.

Was this information helpful? Yes No 5 people rated this as helpful.