Public URIs, Proxy Servers, and Server Rename
*Understanding the communication in a CLM Deployment*
Server rename landing page
Accessing CLM
- When a user accesses a CLM deployment, the user enters the Public URI for the application into a browser window.
- Depending on the deployment architecture, the Public URIs may have the same ‘stem’ in the public URI and a different “context root” or the Public URIs could be completely different.
CLM application
|
Typical Enterprise Deployment
|
Typical Departmental Deployment
|
Jazz Team Server /jts
|
https://jts_server:9443/jts
|
https://clmserver:9443/jts
|
Rational Quality Manager/qm
|
https://rqm_server:9443/qm
|
https://clmserver:9443/qm
|
Rational Doors Next Generation/rm
|
https://rdng_server:9443/rm
|
https://clmserver:9443/rm
|
Rational Team Concert/ccm
|
https://rtc_server:9443/ccm
|
https://clmserver:9443/ccm
|
Departmental Deployment:
Enterprise Deployment:
Here, my pubic URI’s are:
- https://jtsserver:9443/jts Where jtsserver is the computer name (or virtual hostname configured in W.A.S.) The service is listening on port 9443 and the context root is jts
- https://rtcserver:9443/ccm Where rtcserver is the computer name (or virtual hostname configured in W.A.S.)The service is listening on port 9443 and the context root is ccm
- https://rqmserver:9443/rqm Where rqmserver is the computer name (or virtual hostname configured in W.A.S.)The service is listening on port 9443 and the context root is qm
- https://rdngserver:9443/rm Where rdngsrver is the computer name (or virtual hostname configured in W.A.S.)The service is listening on port 9443 and the context root is rm
Applications "communicating" with each other
The servers reference each other through their Public URIs
- When JTS application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
- When RTC application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
- When RQM application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
- When JTS application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
- When RTC application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
- When RDNG application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
- When RQM application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
- When RTC application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
- When RDNG application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
This is true for each of the applications and each of the “artifacts” within the applications.
The Public URI’s are in each of the application configuration files and are embedded in the artifacts for each application stored in the database(s)
User communicating with the Applications
Here, the user talks directly to each application server but the application servers still “communicate” directly with each other.
- When JTS application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
- When RTC application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
- When RQM application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
- When JTS application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
- When RTC application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
- When RDNG application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
- When RQM application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
- When RTC application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
- When RDNG application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
This is true for each of the applications and each of the “artifacts” within the applications.
The Public URI’s are in each application’s configuration files and are embedded in the artifacts for each application stored in the database(s)
Introducing a Proxy Server
When you introduce a proxy server, all traffic gets routed through the proxy server which then redirects the traffic based upon the context root.
When a proxy server is configured, the applications still communicate with each other using the public URI, but the “stem” of the public URI always points to the proxy server.
Typically, if you are implementing a proxy server, then the “stem” of the public URI would not change but each application would still have a distinct context root.
The Proxy server looks at the context root of the traffic ( jts, ccm, rm, qm) and directs traffic accordingly.
The proxy sends
- /qm traffic to the RQM Application server
- /jts traffic to the JTS application server
- /ccm traffic to the RTC server
- and /rm traffic to the RDNG server
In this case, the I.H.S. (Web Server) “takes over” the public URI. (clmserver) Meaning, either the I.H.S. server name has to be the same as the public URI OR, you configure a virtual host name on the I.H.S. server (httpd.conf file) to “spoof it” into thinking that its name is the public URI.
Implementing a Proxy Server
Proxy Server
- If you implemented / configured a proxy server into your environment on Day 1 (before you actually deployed) then your users and application server communicate to each of the applications through the proxy server.
- If you want to move an application server with this proxy configuration, you do not need to do a server rename, you simply modify your proxy server to point to the new server.
- If you did not implement a proxy server in your initial deployment, then all users and applications communicate with the application servers directly.
- If you want to move an application to a new server with a different name, then you may* need to do a server rename.
More detailed information on Reverse Proxy can be found: Understanding reverse proxy
Server Rename
Server Rename
If you want to change your Public URI for whatever reason, you MUST do a server rename.
The Public URI is embedded deeply within each artifact of each application. Therefore, implementing a server rename is the only way to change the Public URI of a deployment.
Why do a Server Rename?
- Company got bought by another company and the domain changes
- Want to remove a port number from a Public URI
- You want to create a test environment from a production system
- You are moving from Test to Production and the original Public URI was “localhost” or contained an I P address.
Server Rename Best Practices
- If you are going to change your Public URI consider creating a more “portable” URI that would not have to be changed again.
- Try to avoid using real server names as they are less portable
- Consider implementing a proxy server for easier portability and HA/DR
Server Rename Mapping File
In a server rename, we create a mapping file that defines each “original” Public URI and maps this to the new ‘desired’ Public URI.
- #/context root
- source=https://old_server:9443/context_root
- target=https://new_server:port/jts
In the Target Public URI, we have omitted the PORT because we are going to configure a proxy server into our deployment. The Proxy Server (Web Server / I.H.S. server) will be configured to listen on the default ports 80 and 443 so no port number is necessary.If I wanted to, I could configure my proxy server to listen on ports 9080 and 9443 but if I did that, then I would have to include the port number in the Target URI
In this example, we are using an enterprise deployment and we want to implement a proxy server.
Clmserver is the virtual hostname for our proxy server
We are also configuring our proxy server to listen on the default ports of 80 and 443 so the new public URIs (target URIs) will not have to include a port number.
#/jts
source=https://jtserver:9443/jts
target=https://clmserver/jts
#/qm
source=https://rqmserver:9443/qm
target=https://https://clmserver/qm
#/rm
source=https://rdngserver:9443/rm
target=https://clmserver/rm
#/rtc
source=https://rtcserver:9443/ccm
target=https://clmserver/ccm
Back to the
Server rename landing page
External links: