Apache Jakarta Tomcat 4

Übersicht: Anwendung

• Einsatz-Szenarien
• Download und Installation
• Konfiguration
• Administration

Einsatz-Szenarien

In dem ursprünglichen Konzeptvorschlag für die Catalina-Architketur werden fünf verschiedene Einsatz-Szenarien für Tomcat genannt:

1. Eigenständiger Webserver ("Standalone")
2. Erweiterung eines bestehenden Webservers, wie z.B. Apache HTTP Server ("Add-on")
3. Eingebettet in einen Applicationserver (z.B. J2EE-kompatible Plattformen) für die erweiterte Speicherung von Sessions und Lastverteilung
4. Web-basierte Verwaltung von bestehenden Serveranwendungen (z.B. Firewalls, DBMS)
5. Web-basierte Verwaltung von in Geräten eingebettete Anwendungen (z.B. in Routern, X10-kompatiblen Haushaltsgeräten)

In der Praxis findet man am häufigsten die Szenarien 1 und 2 vor, wobei im Allgemeinen aus Performancegründen empfohlen wird, Tomcat im Zusammenspiel mit einem bestehenden Webserver (also Szenario 2) einzusetzen, besonders wenn viele Anfragen nach statischen Komponenten (z.B. HTML- und Bilddateien) bedient werden müssen.

Download und Installation

Die Quellen der Tomcat 4.x Releases stehen in Unterverzeichnissen von http://jakarta.apache.org/builds/jakarta-tomcat-4.0/ als komprimierte tar-Archive und als zip-Archive zum Download bereit. Gleiches gilt für die Binaries, wobei für Windows-Systeme zusätzlich ein Windows Installer angeboten wird.

Welche Schritte für das Kompilieren und die Installation erforderlich sind, kann in den Dateien "BUILDING.txt" bzw. "RUNNING.txt" nachgelesen werden.

Die folgende Tabelle beschreibt die Verzeichnisstruktur:

Tabelle 2: Die Tomcat-Verzeichnisstruktur

Konfiguration

Tomcat wird durch Einstellungen in zwei XML-Dateien, /conf/server.xml und /conf/web.xml, konfiguriert. Um die Dateien zu bearbeiten, bietet sich es sich an, einen XML-Editor wie Xeena oder XMLSpy zu benutzen. Aber auch ein einfacher Texteditor reicht völlig aus.

server.xml

Mit den Angaben in der server.xml wird festgelegt, wie der Tomcat-Server genau aufgebaut sein soll, d.h. so wie eine JSP als Bauanleitung für ein Servlet verstanden werden kann, ist die server.xml als Bauanleitung für eine konkrete Instanz des Tomcat-Servers zu verstehen. Die Tomcat-Komponenten können auf verschiedene Weise miteinander kombiniert werden und bieten daher viel Spielraum für unterschiedliche Konfigurationen. Um zunächst eine Übersicht über die einzelnen Komponenten zu verschaffen, zeigt die folgende Abbildung ein Schema der Catalina-Architektur:

Abbildung 3: Schema der Catalina-Architektur

Für die Konfiguration von Tomcat für den Standalone-Betrieb als Webserver genügt es, die Engine-Komponente als den Webserver zu verstehen, der Requests irgendwie von einem TCP/IP-Port empfängt und darüber auch Request versenden kann. Pro Engine sind mehrere (virtuelle) Hosts möglich, die jeweils über sog. Contexts mehrere Web-Applications und damit Servlets beinhalten können.

Im Abschnitt Architektur wird auf alle Komponenten detailliert eingegangen.

<Server port="8005" shutdown="SHUTDOWN" debug="0">

<Service name="Tomcat-Standalone">
	<Connector
		className=
		"org.apache.catalina.connector.http.HttpConnector"
		port="8080" minProcessors="5" maxProcessors="75"
		enableLookups="true" redirectPort="8443"
		acceptCount="10" debug="0" 
		connectionTimeout="60000"/>
	<Connector
		className="org.apache.coyote.tomcat4.CoyoteConnector"
		port="8081" minProcessors="5" maxProcessors="75"
		enableLookups="true" redirectPort="8443"
		acceptCount="10" debug="0" 
		connectionTimeout="20000"/>
	<Engine name="Standalone" defaultHost="localhost"
		debug="0">
		<Host name="localhost" debug="0" appBase="webapps"
			unpackWARs="true">
			<Context path="/seminarvortrag"
				docBase="seminarvortrag"
				debug="0" reloadable="true"/>
		</Host>
	</Engine>
</Service>

</Server>

Listing 3: Eine sehr einfache Fassung der server.xml

In Listing 3 ist eine sehr einfache, aber vollständige Fassung der server.xml angegeben. In dem Service "Tomcat-Standalone" sind zwei Connectors und die Engine "Standalone" zusammengefaßt. Es existiert nur ein Host, "localhost", für den nur ein Context festgelegt wurde. Requests, die mit dem über path angegeben Pfad beginnen, werden an die in docBase spezifizierte Web-Application weitergeleitet. Hier also "seminarvortrag".

Ab der Engine-Ebene können zusätzlich sog. Valves (engl. für "Ventil") eingebunden werden, die einen Request schon verarbeiten, d.h. verändern, erweitern, weiterreichen oder ablehnen können, bevor er zum Servlet gelangt. Valves können als Request-Präprozessoren verstanden werden. Mit Valves werden in Tomcat unter anderem Logfiles und Adreßfilter realisiert.

web.xml ("Deployment Descriptor")

Während in der server.xml festgelegt wird, wie der Tomcat-Servers konkret aufgebaut sein soll, stehen in der web.xml Angaben zu Standard-Servlets, u.a. dem JSP-Servlet sowie weitere Angaben zu den Einstellungen von Session Timeout und MIME-Typ-Zuweisungen. Es handelt sich dabei um Standardeinstellungen, die für jede Web-Application ergänzt oder überschrieben werden können. Dazu dient eine weitere web.xml, die für jede Web-Application existieren muß. Diese Datei nennt man auch den "Deployment Descriptor". Listing 4 zeigt einen sehr einfachen Deployment Descriptor, der nur ein einziges Servlet definiert.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app
	PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
	"http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">

<web-app>

	<servlet>
		<servlet-name>SeminarVortrag</servlet-name>
		<servlet-class>
			de.fh_wedel.ws02.SeminarVortrag
		</servlet-class>
	</servlet>

</web-app>

Listing 4: Ein sehr einfacher Deployment Descriptor

Administration

Deployment von Web-Applications

Das Deployment einer Web-Application ist ein einfacher Vorgang, der aus zwei Schritten besteht:

1. Kopieren des WAR-Files in das Verzeichnis /webapps
2. Eintragen eines entsprechendes Context in der server.xml

Manager Application

Die Tomcat Manager Application ist eine Web-Application, mit der andere Web-Applications über einen Browser installiert, gestartet, erneut geladen, gestoppt und deinstalliert werden können. Außerdem dient sie dazu, Statusinformationen (z.B. Liste der aktuell installierten Web-Applications, Sessionsdetails) abzurufen.

Ihre Oberfläche ist extrem einfach gehalten Kommandos werden per direkter Eingabe in die Adreßzeile des Browsers übertragen und die Antwort wird als einfacher Text dargestellt.