Decidir entre mod_jk, mod_proxy_http y mod_proxy_ajp

A lo largo de los años se han desarrollado multitud de conectores para comunicar el servidor Apache con Tomcat utilizando distintos protocolos. Buscando en la web cómo hacerlo, no es difícil encontrarse con algunos realmente malos y multitud de recetas caducadas. Así que en primer lugar, las únicas opciones a considerar son las siguientes :

• mod_jk
• mod_proxy_http
• mod_proxy_ajp

Debe evitar conectores que han sido abandonados a lo largo de los años: mod_jk2, mod_jserv, mod_webapp y cualquier otro módulo que no aparezca en nuestra lista. La experiencia del autor dando soporte a los clientes de SpringSource y la mía propia es que es más fácil tener problemas con mod_proxy_ajp que con mod_jk o mod_proxy_http. No es que mod_proxy_ajp sea malo, lo he usado durante 18 meses en sistemas en producción sin un solo problema, si no que tiene algunos errores más que los otros módulos. Esta desventaja mejora día a día pero en este momento mod_jk y mod_proxy_http están por encima de mod_proxy_ajp.

Esto nos lleva a la gran pregunta: ¿mod_proxy_http o mod_jk? ¿y la respuesta? ¡Depende!. Ambos módulos tienen sus puntos fuertes y sus debilidades. ¿Cual es el adecuado para usted?,La respuesta depende mucho de sus circunstancias. Los factores que normalmente influyen en esta elección son:

• ¿ Está ya usando uno de estos módulos?
• ¿ La comunicación entre Apache y Tomcat debe ser encriptada?
• ¿ El servidor apache escucha SSL? ¿Debe transmitirse la información de SSL (certificados cliente etc..) a Tomcat?

Si usted ya está usando mod_jk o mod_proxy_http y cumplen con sus necesidades, no es probable que necesite cambiarlo. Es recomendable usar un módulo ya en uso y mantener la coherencia entre las intstancias de apache. Si necesita cifrar las comunicacinoes entre Apache y Tomcat esto es mucho más fácil usando mod_proxy_httpd. Mod_jk usa el protocolo AJP, que no admite cifrado, por lo que debería aplicarlo por separado a través de un tunel SSH o similar, esto puede complicar mucho la configuración del canal de comunicación entre Apache y Tomcat

Si está usando https con autenticación de cliente, mod_jk pasa automáticamente (con dos directivas simples) la información a Tomcat. Tomcat sin necesidad de configuración adicional deja disponibles los datos para las aplicaciones Web. Para lograr esto mismo con mod_proxy_http requiere que configurar el servidor para pasar la información de los certificados en las cabeceras http y debe configurar una «valve» en tomcat para extraer esta información y ponerla a disposición de las aplicaciones Web. Hacer que la información de SSl esté disponible para Tomcat es por tanto más complicado con mod_proxy_http. Por otra parte las «directivas» de configuración son diferentes, mod_proxy_http será muy fácil de usar para quien este familiarizado con la sintaxis de Apache, el enfoque de mod_jk puede parecer un poco raro.

En resumen:
Si necesita cifrar la comunicación entre Apache y Tomcat use mod_proxy_http.
Si tiene que pasar la información de SSL a la aplicación Java use mod_jk.
Si ya esta usando uno de estos dos módulos, cambiar probablemente le cause más disgustos que otra cosa.
Dada una elección totalmente libre, haría uso de mod_proxy_http sólo porque la configuración es semejante a la del resto de módulos de http.

Traducción libre del articulo Mark Thomas en Tomcat Expert

Coincido punto por punto con las apreciaciones del autor, salvo en la última, dada una elección libre yo escogería mod_jk sobre todo en entornos de red complejos donde hay un firewall por medio y mediante mod_jk podemos ajustar mejor los tiempos (KeepAlive, SocketTimeout etc..).