Tomcat-httpd-integration
Apache Tomcat is capable of serving as a HTTP/HTTPS server, but Apache httpd can be used as the front end for client requests as well. Listed are popular options for establishing this integration.
Options for connecting Apache to Tomcat’s Servlet/JSP engine
mod_proxy
mod_jk
mod_proxy_ajp
Each of these choices has its advantages and disadvantages.
httpd mod_proxy and ProxyPass/ProxyReverse
httpd mod_proxy and ProxyPass/ProxyReverse is a quick and easy way to connect httpd to Tomcat, but it is also the least flexible and least performant. Complex configurations can be created with mod_proxy and the associated mod_proxy_* modules, however it’s not the best solution unless:
There is only one Tomcat back-end instance
All that matters is the quickest possible time to setup
Using Apache httpd 2.2.x is not an option
Performance requirements are not a concern
There is a preference to not compile httpd modules from source
One advantage with this method is that if proxying with plain http (not https), tools like snort or tcpdump can view the conversation back and forth. This can be useful for troubleshooting issues.
Bottom line: useful only in limited circumstances, and not a good choice for high-volume or business-critical installations.
Tomcat mod_jk (Apache 1.3 and greater)
The Tomcat mod_jk httpd module has gone through a long cycle of development and improvements. It’s been around for quite some time and is reasonably stable. This module talks to Tomcat using the AJP13 protocol, which is a packet-oriented binary protocol. Using AJP13 has pretty significant performance advantages in that it supports connection persistence, and it implements a form of payload compression to reduce the amount of data traversing the connection. It also has built-in support for handling multiple back-end servers.
Although mod_jk is generally stable and performant, it may or may not be the best option. To properly implement mod_jk generally requires doing some code compilation, and configuration factors must match up on both the httpd and Tomcat side. With those caveats, mastery of the vagaries of mod_jk configuration will enable a robust and performant multi-server installation.
mod_jk is the best solution for Apache/Tomcat integration if:
Higher performance than mod_proxy is needed
Support for multiple back-ends with failover and/or session stickyness is needed
Extra effort of compiling httpd modules is not a factor
Bottom line: most shops choose this option, as it’s a heavily used and tested solution that provides redundancy features.
http mod_proxy/mod_proxy_ajp/mod_proxy_balancer (httpd 2.2.x and later)
As of Apache httpd 2.2.x there is native support for the AJP13 protocol available without having to compile mod_jk. The addition of mod_proxy_ajp and mod_proxy_balancer to the httpd codebase reduces the number of hoops to jump through to get AJP connectivity to Tomcat.
As with mod_jk, combining mod_proxy_ajp/_balancer allows for complex configurations with multiple back-ends, session stickyness and automatic failover (though failover/failback may still be slightly iffy). There is still a need to make specific configuration changes on the Tomcat side, but they are essentially the same as you would make for mod_jk integration.
mod_proxy_ajp/_balancer is the best choice if:
Using Apache 2.2.x is not an issue
Compiling mod_jk is an issue
A ‘pure’ Apache httpd installation is needed
Being slightly on the ‘bleeding edge’ is acceptable (mod_proxy_ajp is not as mature as mod_jk)
Bottom line: mod_proxy_ajp is a clean implementation that comes with Apache 2.2.x, but since it is relatively newer, it may require more testing than the other choices. With time, this native implementation of AJP13 should become the favored one, with mod_jk becoming vestigial.