mod_jk vs. mod_proxy - Introduction
With apache 2.2, things had become a little confusing (for me at least). I am not a member of the ASF, not a developer or tester on any of these projects, and I don't monitor development discussions. When I learned that apache 2.2 came out with a very full-featured "competitor" to mod_jk in the form of mod_proxy_balancer, the first question I asked myself was, "What was wrong with mod_jk?" I've been doing some research and to try and keep each post as brief as possible, I will probably need to break things up across multiple posts. As I'm writing this in my head, I've already thought of related articles that could be (and were) written like "Why front-end a tomcat box with apache any way?"
The other confusing thing to some about mod_jk is jk2. jk2 is deprecated but still around and some folks think that because it's jk2, it must be better and should be used over jk, which is not the case.
Finally, you need to be cognizant about the type of back-end application server you are connecting to. If the container is tomcat, glassfish, or jetty or based upon tomcat or jetty, then you can utilize mod_jk but if your upstream application server does not support ajp (apache jserv protocol), then mod_jk is not going to be very useful. One example of an application server where usage of mod_jk would not be appropriate is the websphere application server. Another is the pramati appliction server. I am not sure about Glassfish because I have never used it.
mod_proxy is a set of modules provided by the apache httpd project. mod_proxy, mod_proxy_balancer, mod_proxy_http, and mod_proxy_ajp provides everything you need to implement apache as a reverse proxy and provides for upstream application server connectivity. mod_proxy has been around for a while as well although mod_proxy_ajp and mod_proxy_balancer are fairly new but still well-tested. mod_proxy_ajp implements support for the ajp13 protocol and just about everything you can do with mod_jk can be done through mod_proxy_ajp. mod_proxy_http is a bit more universal because it speaks http everywhere.
I'm beginning to favor the mod_proxy_http approach for everything now mostly because of maintainability. With mod_jk, upstream workers are normally (although not necessarily) defined in a separate file. Upstream uri maps are implemented in still another file. mod_jk updates are implemented out-of-band from tomcat updates and from apache httpd updates. None of this is causing a particular hardship on me but it is just easier to tell someone that everything they need is in one configuration file. When I tell people that we load-balance with BigIP, mod_jk, or mod_proxy_ajp or mod_proxy_http, they just get confused. Cutting from 4 to 2 makes the suits feel better because they feel they can wrap their heads around 2 solutions over 4.
--Update--May 20th 2009--
One disadvantage to a mod_proxy based solution is that it is tied to apache releases. The last release of apache 2.2 was 2.2.11, released in December 2008. As of today, (May 20th, 2009), that's 5 months without an update to mod_proxy. Over this same time frame, there have been about three releases to mod_jk.
The other confusing thing to some about mod_jk is jk2. jk2 is deprecated but still around and some folks think that because it's jk2, it must be better and should be used over jk, which is not the case.
Finally, you need to be cognizant about the type of back-end application server you are connecting to. If the container is tomcat, glassfish, or jetty or based upon tomcat or jetty, then you can utilize mod_jk but if your upstream application server does not support ajp (apache jserv protocol), then mod_jk is not going to be very useful. One example of an application server where usage of mod_jk would not be appropriate is the websphere application server. Another is the pramati appliction server.
mod_proxy is a set of modules provided by the apache httpd project. mod_proxy, mod_proxy_balancer, mod_proxy_http, and mod_proxy_ajp provides everything you need to implement apache as a reverse proxy and provides for upstream application server connectivity. mod_proxy has been around for a while as well although mod_proxy_ajp and mod_proxy_balancer are fairly new but still well-tested. mod_proxy_ajp implements support for the ajp13 protocol and just about everything you can do with mod_jk can be done through mod_proxy_ajp. mod_proxy_http is a bit more universal because it speaks http everywhere.
I'm beginning to favor the mod_proxy_http approach for everything now mostly because of maintainability. With mod_jk, upstream workers are normally (although not necessarily) defined in a separate file. Upstream uri maps are implemented in still another file. mod_jk updates are implemented out-of-band from tomcat updates and from apache httpd updates. None of this is causing a particular hardship on me but it is just easier to tell someone that everything they need is in one configuration file. When I tell people that we load-balance with BigIP, mod_jk, or mod_proxy_ajp or mod_proxy_http, they just get confused. Cutting from 4 to 2 makes the suits feel better because they feel they can wrap their heads around 2 solutions over 4.
--Update--May 20th 2009--
One disadvantage to a mod_proxy based solution is that it is tied to apache releases. The last release of apache 2.2 was 2.2.11, released in December 2008. As of today, (May 20th, 2009), that's 5 months without an update to mod_proxy. Over this same time frame, there have been about three releases to mod_jk.
