written by Danny Baggs, 14. May 2010
Another update on this topic. If you were making the use of custom error pages in IIS7 and you implemented the below update, you may have noticed that the custom error commands are no longer being adhered to. To change this, you need to set up custom error pages at a site level by choosing your site, selecting “Error Pages”, then “Edit Feature Settings” from action menu and then “Custom error pages”.
On page 2 of this article (How To Configure IIS 7.0 and Tomcat with the IIS ARR Module), there is a key step that I failed to observe when I wrote the original post below. The step in question is the enablement of the (reverse) proxy server after the ARR install. By doing this, you are able to apply rewrite rules at the site level — something I wasn’t able to achieve originally, which meant that the routing rules within my server farm were somewhat overloaded.
With this setting enabled, I can leave a single delegation rewrite rule at the server farm level, telling IIS to delegate HTTP requests of a certain pattern but leave the rewrite rules that are there for beautification at the desired site level. This is a much tidier and more scalable approach.
One gotcha that you need to be aware of is that the rewrites at the site level need to be absolute URLs. Therefore, you could be tempted to place the host of a single tomcat instance that lay behind IIS direct in here and it would work fine but why not allow for a little future proofing and use localhost within all absolute URL site level rewrites, which isolates the rewrites used for masking ugly application URLs and delegates the job of request delegation to the server farm? This approach would allow for the server farm config to be used to bring other tomcat instances online or taken offline for maintenance etc without having to change the site level configuration. In other words, it keeps the various areas of the IIS7 interface focused on the job in hand allowing for easier administration.
Please keep this update in mind as you read the otherwise unchanged original post below.
Regards,
Dan
After many years of using the Tomcat Connector (http://tomcat.apache.org/connectors-doc/) when setting up Tomcat behind IIS, it is now time to say goodbye.
This is the conclusion that I’ve come to after having some particularly significant challenges using IIS7 on a 64bit Windows 2008 machine.
The traditional approach I’ve used in the past has been to utilise the Tomcat Connector, which is implemented as an ISAPI Filter, to delegate requests from IIS through to Tomcat. This has worked great for me in the past and was the subject of a previous article (Fun and Games with IIS7 and Tomcat Connector (Jakarta)) but the 64bit system threw in a couple of additional challenges that weren’t so easy to get around.
The problems faced led me to discover Application Request Routing (ARR), an official extension for IIS7, which allows you to define the delegation of requests to servers sitting behind the IIS instance.
What is particularly nice with this extension is the way in which it facilitates the former approach within the GUI, making it easier to understand what is being delegated. The approach however, is similar to the ISAPI filter approach – delegating based on URL path patterns.
The following takes you through an overview of how to set this up:
You can obtain the appropriate install for the ARR IIS7 extension at
http://www.iis.net/download/applicationrequestrouting
Once installed, the ‘Server Farms’ node indicates that it has installed correctly as indicated in the picture below.
The Server Farms node is seen if ARR is installed correctly
A number of modules are added as part of this extension. You can find the details of these from the same ARR link (http://www.iis.net/download/applicationrequestrouting)
Although the concept of a ‘farm’ of servers may be overkill for our needs of delegating HTTP requests through ISS7 to Tomcat, we shall never the less set up a farm containing one server – our Tomcat instance.
To do this:
Now that we have informed IIS7 about the server that sits behind, we need to let it know how we wish to delegate HTTP requests to it. To do this, we choose the newly created Server Farm in the left hand panel and select the Routing Rules feature.
Within here, we have a few options. I’ve chosen to keep the defaults of having both checkboxes checked and have no exclusions set as I am delegating this responsibility to the URL Rewrite Rules.
From here, you can add and modify the rewrite rules defining how requests are delegated using the ‘URL Rewite’ link in the right-hand action panel.
In my case, I chose to change the default rule that was set up for me to a regular expression as opposed to the wildcard default. However, I only chose this due to personal preference. The pattern I used for this rule is:
cps(.+)
and I ignore the case.
Finally, I have no Conditions or Server Variables to take note of in my scenario although they can easily be added here, so I conclude the rule by setting the action to ‘Route to Server Farm’ and chose my ‘Tomcat – Delivery Server’ farm with a path setting of
/{R:0}
This passes all URL path info through to Tomcat. I also choose to stop processing of subsequent rules.
Lastly, in my setup, I’ve added the following further rules to refine how my site is served through IIS7:
Delegate .htm and .html requests:
Pattern - ([^/]+.html?) Action path - /cps/rde/xchg/<project>/default.xsl/{R:1}
Delegate .xml requests:
Pattern - ([^/]+.xml?) Action path - /cps/rde/xchg/<project>/default.xsl/{R:1}
Delegate default home page:
Pattern - ^/?$ Action path - /cps/rde/xchg/<project>/default.xsl/index.htm
Although this approach of using IIS7 in a reverse proxy capacity may not benefit from the efficiencies of the AJP protocol used by the Tomcat Connector, the impact in most sites will be negligible. In exchange, you have a way of Tomcat and IIS7 working together in a way where the GUI of the IIS7 Management Console helps admins define and understand what is happening. The ISAPI Filter approach is often not so visible because of the broad nature of what ISAPI modules can provide but also due to the configuration required outside of the IIS7 Management Console.
Source: IIS7, Tomcat & Application Request Routing
© copyright 2010 by Danny Baggs