Why you need to front end your CLM servers with an HTTP Server

Off
Strongback Consulting

Don’t run your CLM Servers without an HTTP Server

All too often I run into organizations who have started with IBM Rational Team Concert and some other consultant has setup their servers without an HTTP server. Invariably they run into the same issues over and over again. Its a simple step to setup this up. The IBM HTTP Server is even included in the download packages from Passport Advantage. So, if you are just getting started with Team Concert, Quality Manager, Design Manager, or DOORs NG, please read this for the sake of your future sanity (if not for just mine).

The diagram below represents what a typical deployment might look like. Perhaps you

It hides the implemetation

With an HTTP server, you might have 1 CLM server (such as Team Concert), or you could have a cluster of RTC servers, you might have RTC and an RQM server, or for a large environment, an RQM Cluster, an RTC cluster, a Jazz Team Server cluster and a DNG server. Either way the users access the same host name (i.e. http:/rtc.mycompany.com/), but just a different root context for each application (/ccm, /jts, /qm, etc). The less the user community knows about the infrastructure, the more secure it can be.

It provides another layer of security

When users access the standard ports (80 for HTTP, and 443 for HTTPS), you can hide or restrict access to the server ports on the VLAN. This is important as it also restricts access to the WebSphere Admin console, or Liberty Console.

It makes moving  or adding servers easier

Notice we mentioned the use of a cluster above? With RTC 6.0x clustering is supported again with the use of WebSphere Liberty clustering. If you add another server to your mix, and everyone is accessing the :9443 port, guess what? That clustering won’t work! What about moving your RTC server to a larger server with a different host name? What if you outgrow the resources of a single server and need to split JTS off onto its own server? Without an HTTP server, you would run into issues that would affect the user community, and make it difficutlt to later change such a setup.

It can provide caching, and thus improve performance

RTC, Quality Manager, DOORs NG, and Design Manager all have a plethora of static resources. They are web applications, after all. All the images, cascading style sheets, and mountains of Javascript code get sent to the browser with every call to a raw WebSphere server. Every. Single. Call. That is pulling resources from your WebSphere server, which could just be cached at the HTTP server. That will reduce the load on your WebSphere servers by a noticible amount.

It avoids authentication issues between Team Concert, Quality Manager, and other products

Let’s say you have an RTC server and a Quality Management server running on different machines. Their hostnames are:

rtc.mycompany.com

qm.mycompany.com

When you click a test result link on an RTC work item that opens up an RQM test result, you will be prompted to authenticate. Authentication does not share across these servers as they are on different hosts. If you had an HTTP server in front of it, and its host name was clm.mycompany.com, you would only be changing root contexts (/qm from /ccm), and thus the authentication would be seamless.

It avoids port issues

If you allow access to your server outside of your VPN or Intranet, it means you’re poking a hole in your firewall to use that port. If you have a tighter security than that (which I really hope you do), and have a firewall between your data center and your employee VLAN segments  (which you should), you can further protect your CLM server and expose only the HTTP Server.

Its makes it easier for users to type the URL

On what commercial website do you know of that you have to type the port number in the URL? Go ahead..I’ll wait.

Can’t think of any, can you? So why would you want to burden your users with extra keystrokes, and you with confused users?

The port number 9443 is to be considered a transport HTTP port, not one that users should access directly. It tends to confuse users. Do you really want that?

It only takes about an hour to setup an IBM HTTP Server

Really. Its quick, its easy to setup. Here are the instructions:

https://www.ibm.com/support/knowledgecenter/en/SSEQTJ_9.0.0/com.ibm.websphere.ihs.doc/ihs/tihs_archive_intall.html

It does not affect your IBM licensing

You can use as many IBM HTTP servers in your CLM environment as you want. They are no extra charge.

Comments are closed.

Strongback Consulting