In looking at how to do this I cannot help but ask myself why I would need to do this. If you make a true J2EE Web App, won't all your pages be JSP anyway? Therefor IIS/Apache will always redirect to the Tomcat Server. Now, as I understand it, Apache/IIS will then deliver the HTML content back to the client, but is the response time of IIS/Apache that much greater than Tomcat that it warents integrating them? You can always have your static pages on IIS/Apache and then just have a link to the web app. Any comments?
Apache (and I guess IIS though I don't trust M$ stuff) is far better at serving up static content. Gif's, jpg's, html, flash, css, js etc. A full website has all of this in conjuction with the Dynamic Content. Apache has built in smart cacheing of static stuff, something not worked on that hard with Tomcat. The best is to configure Apache for the static stuff and Tomcat the dynamic. This also helps Tomcat use it resources (Memory, CPU cycles, disk access etc.) for what it's designed for. Even some of the heavy weight App Servers (WebSphere, OC4J, Sun One etc) have an HTTP element (Usually founded on Apache) that they recommend setting up to serve static content with. By all means, if you site has very little by way of static content, then the overhead of the Connector isn't worth the resource savings and there isn't any need to integrate with an HTTP element.
Another reason to integrate Apache with Tomcat from apache site is as follows -
# Socket handling/system stability. Apache has better socket handling with respect to error conditions than Tomcat. The main reason is Tomcat must perform all its socket handling via the JVM which needs to be cross platform. The problem is socket optimization is a platform specific ordeal. Most of the time the java code is fine, but when you are also bombarded with dropped connections, invalid packets, invalid requests from invalid IP's, Apache does a better job at dropping these error conditions than JVM based program. (YMMV)