When you install any part of CLM (JTS, RTC, RRC, RMC), an important recommendation is to use a reverse proxy server. One exception to this is when you’re installing an “evaluation” topology, where you are just evaluate CLM or using it in a small isolated project such as a skunkworks. But otherwise, the recommendation is to use a reverse proxy.
Why? because it’s easier to change your topology later. Much easer. For example, you can change the server name and port the JTS lives on and it will be transparent to users and other applications. Without a reverse proxy, you can’t change the server name at all.
The result of this suggestion is that people believe you can change the public URI if you use a reverse proxy.
THIS IS NOT TRUE. YOU CANNOT CHANGE THE PUBLIC URI.
This will change in the future when a server rename feature is available, and even then it’s not a simple thing to do. The advantage of setting up your CLM installation in a reverse proxy is so you can change things “behind the scenes” in a way that won’t impact users or associated software (integrations and such).
The URL that people (and other applications) use to access your CLM installation will remain the same no matter what you do inside the reverse proxy. The reverse proxy just lets you move and rename servers, move applications to new servers, change ports, and do things like that without impacting your users. All the apps still think they have the same public URI, and they do.
Jazz administrators sometimes forget that changing the external URL (the URL that users use to access Jazz applications) isn’t just a matter of giving developers a new link. Jazz users aren’t the only ones who use the public URI. Jazz-based applications also use that public URI to access data in other Jazz-based applications as well as their own data. And until there’s such a thing as a Jazz server rename feature, there’s no way to tell Jazz-based applications that the URI has changed.
This is why you usually need to set up your reverse proxy when you first install CLM. The applications will reference data in other applications (and themselves) through the reverse proxy, using the same URL that everyone uses to access the reverse proxy. The reverse proxy will route these requests to the proper servers that live inside the reverse proxy.
You could add a reverse proxy at a later date if you initially set up your evaluation topology to use the default ports instead of 9443 and 8080. Then you can set up the reverse proxy to service the plain URL (without ports) that your evaluation topology used. In other words, the Jazz-based applications are still accessing data using the same URL, but now it’s going through the reverse proxy before it gets to the desired application. Once that’s set up, you can transform your eval topology into a more robust topology, placing apps on different machines and using different ports. The public URIs of the apps don’t change (even though the servers and ports they run on might change), but the reverse proxy makes sure requests go to the right place.
If you’re going to add a reverse proxy (and you probably should), check out these reverse proxy articles, part 1 and part 2. You should also review this InfoCenter article. And watch for the CLM Administration Workshop that will be posted soon on Jazz.net. There’s a lab in that workshop that describes how to set up a reverse proxy.