Architektur und Funktionsweise des Apache Tomcat. Wird es den Ansprüchen des eCommerce gerecht?

Inhaltsverzeichnis:

Einleitung

1 Die Architektur des Java Servlet und JSP Containers
1.1 Definition eines Webcontainers und dessen Bedeutung im J2EE Framework
1.2 Definition und Funktionsweise von Java Servlets
1.3 Definition und Funktionsweise von JavaServer Pages
1.4 Der Apache Webserver
1.5 Der Catalina Servlet Container
1.5.1 Konfiguration des Servers
1.5.2 Bearbeitung einer Anfrage
1.5.3 Container Komponenten
1.5.3.1 Default Context
1.5.3.2 Class Loader
1.5.3.3 Logger
1.5.3.4 Session Manager
1.5.3.5 Realm
1.5.3.6 Valve Architektur
1.6 Jasper - JSP Engine
1.7 Administrationstools

2 Vor- und Nachteile f ü r die Realisierung von eCommerce-Anwendungen
2.1 Definition von eCommerce und Anforderungen an Webanwendungen..
2.2 Komponenten-basierte Entwicklung mit Tomcat
2.3 Hochverfügbarkeit und Load-Balancing mit Tomcat und Apache
2.3.1 Load-Balancing mit Apache Webserver und Tomcat
2.3.2 Cluster Lösung mit Apache Webserver und Tomcat
2.3.3 Fazit
2.4 Tomcat als Teilprojekt der Apache.org
2.5 Administrierbarkeit und Wartbarkeit von Tomcat
2.6 Sicherheit realisieren mit dem Tomcat Container
2.7 Performance des Tomcat Containers
2.8 Kostengünstigkeit für Webanwendungen

Zusammenfassende Bewertung

Abkürzungsverzeichnis:

Abbildung in dieser Leseprobe nicht enthalten

Einleitung

Die Seminararbeit behandelt den Apache Tomcat, einem Servlet Container der neuesten Generation, der 100% in Java programmiert ist. Er verwirklicht die offizielle Referenzimplementierung von den Java Servlets und JavaServer Pages APIs, welche von Sun Microsystems in den aktuellen Versionen Java Servlet 2.3 und JavaServer Pages 1.2 gefordert wird¹. Das Tomcat Projekt ist Teil eines Großprojekts der Apache.org mit dem Codenamen Jakarta. Ziel von Jakarta ist, serverseitige, kostenlose und hochqualitative Lösungen für Java Plattformen zu erstellen und zu warten, die von der ASF, der Apache Software Foundation, lizenziert sind und für die Öffentlichkeit kostenlos zugänglich sein sollen.²

Die Seminararbeit setzt ihren Schwerpunkt auf die Architektur und die Funktionsweise des Servlet Containers, nachdem die Begriffe Apache Webserver, Webcontainer, Java Servlet und JSP erläutert und in Zusammenhang gebracht wurden. Der zweite Abschnitt beschreibt die Ansprüche, die Anwendungen im eCommerce an den Apache Tomcat stellen, und prüft, in wieweit diesen auch gerecht werden kann.

1 Die Architektur des Java Servlet und JSP Containers

Zu Beginn des Kapitels werden die grundlegenden Eigenschaften und Aufgaben von Webcontainern im J2EE Framework vorgestellt. Zudem sollen kurz die Themen Java Servlets, JavaServer Pages im Allgemeinen beleuchtet werden, für deren Einsatz der Tomcat Webcontainer entwickelt wurde. Anschließend wird die Architektur von Apache Tomcat in der Version 4, des sogenannten Catalina Containers, vorgestellt.

1.1 Definition eines Webcontainers und dessen Bedeutung im J2EE Framework

Die Java 2 Enterprise Edition "definiert einen Standard zur Implementation, Konfiguration, Verteilung und zum Einsatz von unternehmensweiten Anwendungen (Enterprise applications)."³

Der Zweck des J2EE Framework ist, unabhängig von verschiedenen Diensten oder den verwendeten Plattformen wie z.B. Microsofts Windows oder Suns Solaris, Anwendungen zu entwickeln, die in kleine, einfache, anpassbare und leicht zu administrierende Komponenten aufgeteilt sind. Hierzu wird die Anwendung in drei grobe Schichten eingeteilt: dem Client Tier, den Middle Tier und den EIS Tier (siehe Abbildung 1)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: René Valdéz Voges, "Apache Tomcat", München 2002 nach Turau,V. u.a. "Java Server Pages und J2EE" Heidelberg 2001

Hier wird nur auf den Client Tier und Middle Tier eingegangen. Die Clients der Anwendung befinden sich entweder im eigenen Netz, oder über eine Firewall verbunden im Internet. Sofern keine eigenen Anwendungen auf den Clients installiert werden müssen, sollen sie über die gebräuchlichen Webdienste an den Middle Tier angebunden werden, also im Allgemeinen über das Protokoll HTTP bzw. HTTPS und die Beschreibungssprachen HTML bzw. XML.⁴ Im Middle Tier wird die Laufzeitumgebung für die J2EE Anwendungen über sogenannte Container realisiert. Diese Container stellen eine gebündelte Sicht auf die darunter liegenden APIs des J2EE für die Anwendungskomponenten zur Verfügung. So dürfen verschiedene Komponenten einer Anwendung niemals direkt miteinander kommunizieren, sondern nur über die Protokolle und Schnittstellen, die der Container für die Kommunikation zwischen den Komponenten untereinander oder mit Diensten der jeweiligen Plattform anbietet. Dadurch, dass man Container zwischen den Diensten der J2EE und den Anwendungskomponenten stellt, kann der Container je nach Konfiguration für die einzelne Komponente Transaktionen durchführen, auf Sicherheit achten, Ressourcen einteilen und die Zustände der sich im Container befindlichen Anwendungen prüfen. Es gibt folgende Typen von Containern: application client container, applet container, web component container und enterprise bean container.⁵ Die Anforderungen an einen Container sind in der Spezifikation von J2EE klar definiert, und es würde den Rahmen dieser Arbeit sprengen, näher darauf einzugehen. Tatsache ist allerdings, dass das J2EE Modell Web-basiert ist⁶, und damit spielt der web component container eine tragende Rolle bei der Kommunikation zwischen den Clients und der eigentlichen Anwendung. Diese Container, auch Servlet Container genannt, sind Erweiterungen für Webserver.⁷ Der Webcontainer nimmt Anfragen aus dem Intra- oder Internet über HTTP entgegen. Java Servlets, bzw. JavaServer Pages, die im Container ausgeführt werden, verarbeiten die Anfrage und schicken eine Antwort zurück. Über den Webcontainer kann auch auf andere Komponenten oder auf Ressourcen im J2EE zugegriffen werden. Natürlich ist der Einsatz eines Webcontainers nicht auf das Internet beschränkt, so dass auch Verarbeitungsschritte zwischen Servlets, ohne die übliche Client-Anbindung mittels Browser, über den Webcontainer denkbar sind. Apache Tomcat, von Sun Microsystems mit auf den Weg gebracht und unterstützt⁸, ist hierbei ein wichtiger Vertreter.

1.2 Definition und Funktionsweise von Java Servlets

Ein Servlet wird folgendermaßen in der aktuellen Spezifikation von Sun Microsystems definiert: "A servlet is a Java technology based web component, managed by a container, that generates dynamic content."⁹ Der im vorherigen Kapitel definierte Webcontainer sorgt für die Kommunikation, die nach dem request/response Paradigma funktioniert. Ein Servlet ist eine Java Klasse, die das Interface Servlet implementieren muss, oder sich von einer Klasse ableitet, die dieses Interface implementiert hat, um mit dem Webcontainer über diese API kommunizieren zu können. Das Interface Servlet enthält drei Methoden: eine init(), eine destroy() und eine service() Methode. Diese Methoden werden auch life-cycle methods genannt, da sie für den Lebenslauf des im Container ausgeführten Servlets zuständig sind.¹⁰ In der init() Methode wird das Servlet initialisiert, also alle Aktionen ausgeführt, die vor der Ausführung des Servlets von Nöten sind, z.B. Dateien öffnen oder Verbindung zu einer entfernten Datenbank herstellen. In der destroy() Methode werden meistens die vorher getroffenen Maßnahmen wieder rückgängig gemacht, wie eben Dateien oder Verbindungen zur Datenbank schließen. Die service() Methode implementiert die eigentliche Funktionalität des Servlets und wird vom und im Webcontainer ausgeführt. In der Java J2EE API sind bereits Klassen definiert, um die Entwicklung von Servlets erleichtern. Die Klasse HTTPServlet dient z.B. als Vorlage für HTTP Servlets. Sie verfügt bereits über entsprechende Methoden, um über das HTTP Protokoll mit Webbrowsern zu kommunizieren.¹¹

1.3 Definition und Funktionsweise von JavaServer Pages

JavaServer Pages (JSP) werden in der Spezifikation von Sun Microsystems definiert als "(...) a text-based document that describes how to process a request to create a response."¹² Aber wie funktioniert eine JavaServer Page? Anders als bei einem Servlet muss die HTML Seite nicht extra mittels Befehle eincodiert werden, vielmehr werden JavaServer Pages in HTML Seiten integriert. Durch spezielle Tags kann der dynamische Code in die HTML Seite gebracht werden. Diese Seiten werden vom Webcontainer geparst und in ein Java Servlet übersetzt. Dieser Vorgang wird in Abbildung 2 veranschaulicht: Wurde eine JSP neu erstellt, wird bei dem ersten Aufruf der Seite die JSP analysiert und ein Servlet generiert, die sogenannte JSP page implementation class.¹³ Daraus wird ein .class File erstellt, das nun vom Webcontainer wie ein Servlet ausgeführt wird. Der Aufruf einer JSP wird vom dazugehörigen Container aufgenommen und an die Servlets weitergeleitet. Vor der Ausführung des Servlets wird überprüft, ob sich die dazugehörige JSP geändert hat, und gegebenenfalls wird die JSP neu übersetzt und das Servlet neu generiert.¹⁴ Dadurch hat der Webcontainer zwei grundlegende Phasen der JSP zu organisieren: Die translation phase und die execution phase. In der Übersetzungsphase sucht der Webcontainer nach der JSP implementation class, und wenn noch keine existiert, generiert er diese. Dieser Prozess ist abhängig von der Semantik der JSP. Der Container interpretiert die Standarddirektiven und Funktionen der JSP API und selbstdefinierte Tags. Dazu dienen die sogenannten tag libraries, in denen eigene Funktionalitäten zusammengefasst sind, die von der JSP aufgerufen werden können. Wie effektiv die Umsetzung erfolgt, hängt von dem verwendeten Container ab. In der Ausführungsphase muss der Container aus der implementation class Objekte erstellen. Da er zuständig ist für die Kommunikation mit der Außenwelt muss er die Request Objekte erstellen und diese an die jeweiligen JSP Objekte weiterleiten. Die Response Objekte werden wiederum vom Container aufgenommen und an den Client über das entsprechende Netzwerkprotokoll überstellt.¹⁵

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: René Valdéz Voges, "Apache Tomcat", München 2002 nach Turau, V u.a. "Java Server Pages und J2EE" Heidelberg 2001

1.4 Der Apache Webserver

Obwohl der Apache Tomcat Server stand-alone auch als HTTP Server und mit anderen Webservern lauffähig ist, wird er häufig in Kombination mit dem Apache verwendet. Als Projekt der Apache Group im April 1995 gestartet, wird der Webserver seitdem laufend weiterentwickelt und ist für eine Vielzahl von Betriebssystemen verfügbar. Die aktuelle Version ist 2.0. Die Funktionen des Webservers können durch Module erweitert werden. Es gibt mehr als 100 Module, darunter spezielle Authentifikationsmodule, Skript- und verschiedene Interpretermodule für PHP, Perl, Python und Tcl.¹⁶ Die erste Unterstützung für Servlets im Apache Webserver war das Modul Jserv, aus dem auch das Tomcat Projekt erwachsen ist und das jetzt nur noch gewartet, aber nicht mehr weiterentwickelt wird. Die Verbindung zwischen Webserver und dem Jserv Modul wird über das Apache Jserv Protokoll (AJP) durchgeführt.¹⁷ Dieses Relikt finden wir im Apache Tomcat wieder, der das Protokoll unterstützt und so mit den Webservern kommunizieren kann. Über das mod_jk Modul für den Apache Webserver kann die Anbindung über das Apache Jserv Protokoll an einen Tomcat Container für Servlets und JSP konfiguriert werden. Auf diese Weise ist es möglich, Hochverfügbarkeits- und Load-Balancing Lösungen für den Tomcat zu verwirklichen. Dazu aber mehr, wenn über die Tauglichkeit des Apache Tomcat für Webanwendungen gesprochen wird.¹⁸

1.5 Der Catalina Servlet Container

Nun soll das Design des Tomcat Servlet Containers näher beschrieben werden. Es ist nützlich, wenn man sich dazu das Klassendiagramm des Containers anschaut (siehe Abbildung 3).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: René Valdéz Voges, "Apache Tomcat", München 2002 nach Rossbach (Hrsg.) "Java Servlets und JSP mit Tomcat 4x" Javamagazin, Frankfurt 2002 Das Interface Server stellt die Schnittstelle für einen kompletten, funktionsfähigen Catalina Container im Apache Tomcat dar. Der Server kann über mehrere Services verfügen, die jeweils über mehrere Connectors erreichbar sind. Jeder Server kann über einen eigens definierten Port hoch und heruntergefahren werden. Ein Service stellt einen oder mehrere Dienste über seine Connectors zur Verfügung. Diese können selbst definiert und entfernt oder hinzugefügt werden. Zusätzlich stellt der Service die Verbindung zwischen Connectors und den Engines her.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: René Valdéz Voges, "Apache Tomcat", München 2002 nach Rossbach (Hrsg.) "Java Servlets und JSP mit Tomcat 4x" Javamagazin, Frankfurt 2002

Jeder Connector bestimmt den Port und das Protokoll, über das mit der Außenwelt kommuniziert wird. Standard ist HTTP 1.0, HTTP 1.1, SSL/HTTPS, AJP 1.3 und Warp 1.0, aber es können auch weitere Ports oder Protokolle selbst geschrieben und hinzugefügt werden. Eine Engine enthält mehrere Host Container, die über die Service Schnittstellen kommunizieren. Die Engine sorgt für die Verteilung von Anfragen an Hosts und wählt den jeweils Richtigen an. Hier lassen sich für die verschiedenen Hosts die Einstellungen für Logging, Session Management und Autorisierung vornehmen. Hosts verfügen über eigene Anwendungsverzeichnisse und sind absolut getrennt voneinander. Auf diese Weise können verschiedene Versionen einer Anwendung, wie z.B. Test und Vorabversionen, in einer Engine zusammengefasst werden. Ein Host enthält einen oder mehrere Context Container. Da eine Engine auch ein Container ist, kann der Host Eigenschaften seiner Engine, in der er sich befindet, erben. Dadurch können Default Einstellungen auf alle Hosts in einer Engine verteilt werden. Der Context enthält wiederum in Wrapper gebundene Servlets, die zu einer Anwendung gehören, und er sorgt auch dafür, dass eine Anfrage an das richtige Servlet zugestellt wird.¹⁹ Um die Zusammenhänge besser zu illustrieren, zeigt das Diagramm in der Abbildung 4 nochmals die einzelnen Komponenten.

1.5.1 Konfiguration des Servers

Um den modularen Aufbau besser verstehen zu können, wird hier auf eine Beispiel- Konfiguration einer Tomcat Installation eingegangen.²⁰ Der Tomcat lässt sich über die config/server.xml Datei konfigurieren. Wie man an der Extension sehen kann, handelt es sich um eine XML Datei, die beim Startup des Servers eingelesen wird und aus der die einzelnen Komponenten, sprich Objekte, erstellt werden. Ein in Tomcat integrierter XML Mapper liest die XML Datei und generiert daraus diese Java Objekte.²¹ Betrachtet man die XML Syntax der server.xml Datei genauer, lässt sich der modulare Aufbau leicht erkennen. Es gibt sogenannte Top Level Elements, das sind <Server> und <Service> Tags, wobei <Server> das Basistag der gesamten Anwendung ist. <Service> kann nur <Connector> und <Engine> Tags enthalten. Ein <Engine> Tag ist ein Top Level Tag für die untergeordneten Container, wie <Host> und <Context>. Des weiteren werden auf dieser Ebene zwischen <Engine> </Engine> Tags auch die verschiedenen zusätzlichen Komponenten eines Catalina Containers konfiguriert, die später noch näher betrachtet werden. Über die Konfigurationsdatei hinaus stellt Tomcat auch eine Klasse für die Integration in eine bestehende J2EE Konfiguration zur Verfügung.²²

[...]

¹ Vgl. o.V., "The Jakarta Site - Apache Tomcat", Stand: 09.10.2002

² Vgl. o.V., "The Jakarta Site - Mission", Stand: 09.10.2002

³ Turau, V., Saleck K., Schmidt, M., "Java Server Pages und J2EE", Heidelberg 2001, S.1

⁴ Vgl. Kapitel 1 Turau, V., Saleck K., Schmidt, M., "Java Server Pages und J2EE", Heidelberg 2001

⁵ Vgl. Kapitel 2.3 o.N. "Java 2 Platform, Enterprise Edition (J2EE) Specification Version 1.4", Santa Clara, California, USA

⁶ Vgl. Kapitel 1 Turau, V., Saleck K., Schmidt, M., "Java Server Pages und J2EE", Heidelberg 2001

⁷ Vgl. Kapitel 1.1 Coward, Danny, "Java Servlet Specification Version 2.3", Palo Alto, California, USA

⁸ Vgl. o.V. "JavaServer Pages™ - Tomcat @ Jakarta", Stand: 09.10.2002

⁹ Coward, Danny, "Java Servlet Specification Version 2.3", Palo Alto, California, USA, S. 17

¹⁰ Vgl. o.V. "Java 2 Platform EE v1.3: Interface Servlet", Stand: 09.10.2002

¹¹ Vgl. Kapitel 15.1 Coward, Danny, "Java Servlet Specification Version 2.3", Palo Alto, California, USA

¹² Pelegrí-Llopart, Eduardo, "JavaServer Pages Specifications Version 1.2", Palo Alto, California, USA, S. 25

¹³ Pelegrí-Llopart, Eduardo, "JavaServer Pages Specifications Version 1.2", Palo Alto, California, USA, S. 27

¹⁴ Vgl. Kapitel 2.1-2.5 Turau, V., Saleck K., Schmidt, M., "Java Server Pages und J2EE", Heidelberg 2001

¹⁵ Vgl. Kapitel 2.1.3 Pelegrí-Llopart, Eduardo, "JavaServer Pages Specifications Version 1.2", Palo Alto, California, USA

¹⁶ Vgl. Kapitel 3.3, Eilebrecht, Lars, „Apache Web-Server“, Bonn 2000

¹⁷ Vgl. o.V., "The Apache JServ Project", Stand: 09.10.2002

¹⁸ Vgl. Kapitel 2.3

¹⁹ Vgl. Kapitel "Basisarchitektur", Rossbach, Peter (Hrsg.), u.a. "Java Servlets und JSP mit Tomcat 4x", Frankfurt 2002

²⁰ Vgl. Appendix A, Goodwill, J., "Apache Jakarta-Tomcat", Berlin 2002

²¹ Vgl. o.V., "Catalina Internal API Dokumentation: Class XmlMapper", Stand: 09.10.2002

²² Vgl. McClanahan Craig, "Catalina Internal API Dokumentation: Class Embedded", Stand: 09.10.2002