- Internet
- 25.09.2017
- EN
Open Text Delivery Server with a Front Controlling Web Server
written by Danny Baggs, 10. February 2010
Overview
This post discusses the best practice of deploying the Open Text Delivery Server in an optimal way alongside a front controlling web server.
Delivery Server is a dynamic web server component that has strengths in coarse grained personalisation and dynamic behaviour as well as system integration. Therefore, as it is housed within a Servlet Container, it is not the ideal location from which to serve static content (unless you wish to maintain a level of access control over the static content).
Leveraging the use of a front controlling Web Server, facilitates an optimised site deployment as web servers such as Microsoft’s IIS or Apache’ HTTP Server can be utilised for delivering static content in an optimised way. For example, it is possible to easily configure a far future ‘Expires’ header on a given folder and therefore its content within either Apache or IIS, which promotes the caching of content in a user’s browser, which reduces page load times. Another example is in the use of mature compression features within such web servers. Although these examples can be achieved with some Servlet Container’s, it is certainly not straight forward and doesn’t necessarily make sense from an architectural perspective.
It is for this architectural reason, that best-practice dictates that we delegate only the relevant HTTP requests to Delivery Server. In most cases, this means that Delivery Server is delegated requests for .htm and .xml resources. The rest can be served from the front controlling web server (or better still a CDN).
This article provides a high-level overview of what to set up. Depending on feedback, I may post further posts on the details of each step.
Delegating Requests from the Web Server to Delivery Server
This step can be easily achieved using the Tomcat Connector for both IIS and Apache. To find out more see the Tomcat Connector documentation here: http://bit.ly/at1w8G.
This connector uses the Apache JServ Protocol, which connects to port 8009 by default on Tomcat and is optimised to use a single connection between the Web Server and the Delivery Server for many HTTP requests. Therefore, this represents a better option than using reverse proxy functionality within the Web Server.
If we take a typical Delivery Server install (i.e. the reference install using Tomcat), a page can be accessed with something like the following URL:
http://<host>:8080/cps/rde/xchg/<project>/<xsl_stylesheet>/<resource>
where resource could be any text based file like index.html or action.xml.
The result of correctly installing the Tomcat Connector means that we can access that same resource but through the Web Server on port 80 and not direct to the Tomcat instance on port 8080:
http://<host>/cps/rde/xchg/<project>/<xsl_stylesheet>/<resource>
Many confuse this step with URL rewriting or redirecting as the Tomcat Connector is often called the Jakarta Redirector. Therefore, I choose to differentiate by saying that this delegatesHTTP requests between the two systems and nothing more.
In every install, I have always used the defaults in the workers.properties file and just used the following rule in the uriworkermap.properties file:
/cps/*=wlb
URL Rewriting
Due to the effort of setting up delegation, deciding which HTTP requests should be forwarded to Delivery Server is a simple matter of performing some URL rewrites.
As we have decided to use a mature Web Server, there are best practice ways to achieve this. In IIS6, HeliconTech (http://bit.ly/bgJEF6) created a very useful ISAPI filter which ports the widely adopted Apache mod_rewrite (http://bit.ly/cfvuLD) functionality. For both of these, the same rewrite rules can be used. The following provides a couple of typical examples:
# Default landing page redirect RewriteRule ^/$ /cps/rde/xchg/<project>/<xsl_stylesheet>/index.htm [L]
# Rewrite to delegate all *.html or *.htm HTTP requests to Delivery Server RewriteRule ^/?.*/(.+.html?)$ /cps/rde/xchg/<project>/<xsl_stylesheet>/$1 [L]
# Rewrite to delegate all *.xml HTTP requests to Delivery Server RewriteRule ^/?.*/(.+.xml)$ /cps/rde/xchg/<project>/<xsl_stylesheet>/$1 [L]
Those of you who are well versed in regular expressions will see that the last two rules could be combined but I tend to leave them separate to aid readability.
The beauty of using regular expressions in this way is that you can actually create useful SEO benefits to your site also. Take for example the following rule:
RewriteRule ^/?.*/([0-9a-zA-Z_]+)$ /cps/rde/xchg/<project>/<xsl_stylesheet>/$1.htm [L]
This rule maps a URL with many apparent subdirectories to the Delivery Server file. This means that you can publish a page with a “virtual” path within the Management Server which appears to a browser (and search engines) as something like the following:
http://<host>/this/is/a/descriptive/directory/structure/page.htm
and yet this maps to:
/cps/rde/xchg/<project>/<xsl_stylesheet>/page.htm
IIS7
Being a Microsoft product, IIS7 has some quirks with regards to the rewriting (of course), which I explained in a previous post: Fun and Games with IIS7 and Tomcat Connector (Jakarta).
Summary
This approach has led to many successful installations where sites could additionally be optimised for SEO and page load.
Source: Open Text Delivery Server with a Front Controlling Web Server
© copyright 2010 by Danny Baggs