Sowohl der Webserver Apache als auch der Servlet-Container Tomcat werden von der Apache Software Foundation gepflegt. Ein perfektes Zusammenspiel scheint daher selbstverständlich. Doch die Realität sieht anders aus. Dieser Coffee-Shop zeigt Ansätze für eine Lösung.

Verschiedene Entwicklungslinien, viele, aber veraltete Howtos: Die korrekte Konfiguration von Tomcat im Zusammenspiel mit Apache ist ein Abenteuer und für jede Distribution anders zu lösen. Der vor einiger Zeit erschienene Coffee-Shop zum Thema Tomcat[1] hat eine kleine Lawine von Mails ausgelöst. Insbesondere die mit Hinweis auf die ausführliche Dokumentation gemachte Aussage, dass "das Zusammenspiel mit dem Apache in der Version 4 deutlich einfacher zu konfigurieren ist als früher" stimmt so leider nicht.

Diese Folge beleuchtet deshalb zwei Fragestellungen, die in typischen Tomcat-Einführungen zu kurz kommen. Zum einen ist dies die gemeinsame Konfiguration von Tomcat und Apache, zum anderen die SSL-Konfiguration von Tomcat. Die Verbindung beider Themen, also Apache mit »mod_ssl« als Frontend und Tomcat als Servlet/JSP-Backend ist zwar ein realistisches Szenario, würde den Umfang dieser Folge aber bei weitem sprengen.

Mehrweg-Kommunikation

Im Prinzip ist die Zusammenarbeit eines Webservers mit einem dahinter liegenden Servlet-Container einfach. Der Webserver arbeitet gewissermaßen als Proxy und leitet die für den Servlet-Container gedachten Requests an diesen weiter, um dessen Antwort an den anfragenden Client zurückzuschicken.

Ein echter Proxy weiß allerdings wegen der angefragten Webadresse, an welchen Server er sich wenden soll. Beim Apache-Tomcat-Gespann funktioniert das nicht. Der Webserver muss selber wissen, welche Requests er direkt beantwortet und welche er an die Servlet-Engine weiterleitet. Selber wissen bedeutet also, dass entsprechende Einträge in der Apache-Konfigurationsdatei vorhanden sein müssen.

Die Kommunikation zwischen Apache und Tomcat kann unterschiedlich ablaufen. Naheliegend sind normale Netzwerkverbindungen, als Alternative stehen für den Fall, dass Apache und Tomcat auf derselben Maschine laufen, Unix-Sockets oder In-Process-Kommunikation bereit. Bei der letzten Variante startet Apache den Tomcat-Server im eigenen Adressraum (über das Java Native Interface), eine Architektur, die neben dem Vorteil schneller Kommunikation zwei wesentliche Nachteile besitzt: Diese Lösung ist nicht nur weniger robust, sie ist auch nicht skalierbar.

Die Kommunikationsarchitektur zwischen den Servern besteht aus zwei Elementen auf der Apache-Seite und einem Element bei Tomcat. Ein Apache-Modul kann Client-Requests an Tomcat weiterleiten. Das Modul bedient sich hierzu als zweitem Element eines Kommunikationsprotokolls. Das dritte Element ist ein Konnektor auf Tomcat-Seite, er muss - genauso wie das Apache-Modul - das Kommunikationsprotokoll verstehen und verarbeiten können.

Die erfolgreiche Konfiguration des Apache-Tomcat-Tandems besteht also aus drei Schritten: Auswahl des geeigneten Protokolls, Installation und Konfiguration des Apache-Moduls sowie Aktivierung und Konfiguration des entsprechenden Tomcat-Konnecktors.

Entwicklungslinien

Im Laufe der Jahre entstand eine ganze Reihe von Protokollen und entsprechenden Apache-Modulen für die Kommunikation zwischen Apache und Tomcat. Der erste Tomcat-Artikel im Linux-Magazin[2] beschreibt das JServ-Modul, das das so genannte AJP12-Protokoll verwendet hat. Beide - Modul und Protokoll - sind veraltet und sollten nicht mehr verwendet werden. Als Nachfolger hat sich das AJP13-Protokoll etabliert, für ein AJP14-Protokoll liegt ein Diskussionsvorschlag vor

Bei den Modulen und Konnektoren gibt es zurzeit zwei aktive Entwicklungslinien: JK beziehungsweise JK2. Die Konnektoren werden im Coyote-Teilprojekt entwickelt, daher heißen sie auch Coyote-Konnektoren. Beide arbeiten mit dem AJP13-Protokoll. Der JK2-Konnektor wurde explizit in Hinblick auf Apache 2 entwickelt, funktioniert laut Dokumentation aber auch mit dem Apache 1.3 und anderen Webservern wie IIS, IPLanet und Lotus-Domino. Ebenso soll der JK-Konnektor auch mit dem Apache 2 funktionieren.

Damit ergeben sich für Apache mit Tomcat vier Kombinationsmöglichkeiten. Die Dokumentation empfiehlt für den JK2-Konnektor aber explizit Apache 2. Deshalb behandelt dieser Coffee-Shop JK2 nur in der Kombination mit Apache 2. Eine weitere Entwicklungslinie wurde durch »mod_webapp« mit dem so genannten WARP-Protokoll begonnen, das aber explizit die Apache Portable Library voraussetzt. Damit ist der Einsatzbereich dieser Kommunikationsalternative ebenfalls auf Apache 2 beschränkt.

Sowohl der Webserver Apache als auch der Servlet-Container Tomcat werden von der Apache Software Foundation gepflegt. Ein perfektes Zusammenspiel scheint daher selbstverständlich. Doch die Realität sieht anders aus. Dieser Coffee-Shop zeigt Ansätze für eine Lösung.