Compréhension du couplage Apache/Apache Tomcat

Bonjour,

Jusque là, j'ai toujours utilisé Tomcat pour déployer les .war fournis par les développeurs, et c'est donc lui qui effectuais le rendu html.

Dans un nouveau projet, je dois étudier la pertinence d'une séparation entre le Tomcat et l'Apache Web Server.

D'après ma compréhension, un Apache configuré avec un connecteur (type mod_jk ou mod_proxy_ajp) permet d'aller chercher ses infos sur le(s) Tomcat correspondant à l'URL demandée par le client.

Mais, qui effectue le rendu HTML ? Toujours le Tomcat ? Dans ce cas, l'intérêt est faible non (si j'ai déjà un loadbalancer matériel en frontal des Tomcats) ?

Oui, c'est toujours Tomcat qui fait le rendu HTML, comme tu dis. L'intérêt c'est que Tomcat n'est pas accéder directement par les clients (les navigateurs), donc on peut ajouter un niveau de sécurité (Apache en DMZ, Tomcat en MZ). On peut aussi utiliser Apache pour gérer les ressources statiques (les images, JavaScript, CSS, etc.) de manière à ne solliciter Tomcat que pour le vrai traitement dynamique. Mais si tu as déjà un load balancer en frontal de Tomcat, l'intérêt est très limité.

Dis mac, le loadbalancer de quoi s'agit il?? il permet l'accessibilité aux tomcats
via le http? Si non je pense que voila un intéret qui n'est pas des moindres.

Tomcat sait nativement parler HTTP, donc on n'utilise pas un load balancer pour rendre Tomcat accessible par HTTP. On utilise un load balancer pour au moins deux raisons :

• La répartition de charge (un load balancer est avant tout un load balancer, n'est-ce pas)
• Eviter que Tomcat (le serveur applicatif) soit accessible directement par les navigateurs : avec un répartiteur en frontal, on ajoute un rideau défensif. C'est mon histoire de DMZ/MZ.

On peut avoir d'autres raisons en fonction des capacités du load balancer.

Ce que je dis juste c'est que l'archi load balancer => Apache => Tomcat peut sembler superflue et préférer l'archi plus simple load balancer => Tomcat si Apache n'a pas de rôle particulier.