们必须证明购买额外的反向代理服务器是值得的。这两个因素结合在一起，促使我们仔细研究如何使用现有的反向代理服务器满足新 Web 应用程序的需求。惟一的问题是，这个应用程序需要一个与现有 HR 应用程序不同的 FQDN。
我们研究了几种为新的 Web 应用程序使用现有反向代理服务器的方法。第一种想法是，将新旧两个应用程序的域名都改为某个通用域名，比如 rp.company.com，并用上下文路径区分这两个应用程序。但是，原来的反向代理服务器用户强烈反对改变域名。如果改变域名，他们必须将域名变更情况通知公司中的所有人，还要修改所有印刷资料，以反映新的 URL。改变域名的成本非常高，而且可能会影响客户支持部门，他们不可避免地会收到大量用户投诉。另外，两个应用程序组都希望保留自己的 FQDN，他们认为自己精心选择的 FQDN 比这种一般化的 URL 更醒目，而且也是宣传推广这些 页码：[1] [2] [3] [4] [5] [6] 第4页、共6页 |
