17.3 Servlets und Java Server Pages entwickeln und testen 

Um Servlets und Java Server Pages entwickeln und testen zu können, benötigen wir einen Servlet-fähigen Web-Server beziehungsweise einen Servlet-Container. Mittlerweile gibt es eine große Anzahl von Herstellern, deren Server Servlets verwalten.

17.3.1 Servlet-Container 

Servlets und Applets sind konzeptionell ähnlich. Daher kann ein Vergleich gewagt werden: Applets werden vom Web-Browser geladen und gestartet. Den Browser können wir dabei als Container für Applets sehen, der eine Infrastruktur wie die virtuelle Maschine oder Netzwerkeigenschaften bereitstellt. Innerhalb einer Java-Umgebung im Browser können durchaus mehrere Applets parallel eingebunden sein, die untereinander kommunizieren. Genauso verhält es sich mit Servlets. Auch hier benötigen wir einen Container, der alle Servlets verwaltet. Dieser kann entweder in einem Web-Server eingebettet sein oder in einen Applikations-Server. Der Container leitet dann Anfragen an das Servlet weiter. Neben der Kommunikation nach außen verwaltet der Container den Lebenszyklus eines Servlets, genau wie ein Browser darüber wacht, ob das Applet gerade sichtbar ist oder nicht. Bei Servlets sieht ein solcher Vorgang wie folgt aus: Ein Client richtet eine HTTP-Anfrage an den Web-Server. Dieser bemerkt, dass es sich um ein Servlet handelt und gibt die Anfrage an den Container weiter. Dieser wiederum verwaltet alle Servlets und spricht genau das Servlet an, das der Benutzer nutzen wollte und übergibt Datenströme zur Ein- und Ausgabe. Das Servlet liest über den Eingabekanal optional Formularinhalte und generiert über den Ausgabestrom eine HTML-Seite, die der Container an den Client weiterreicht.

17.3.2 Web-Server mit Servlet-Funktionalität 

Sun verzeichnet auf ihrer Web-Seite http://java.sun.com/products/servlet/industry.html eine Liste von Servlet-fähigen Servern. Ein Server ist genau dann Servlet-fähig, wenn er die Java-Servlet- und Java-Server-Pages (JSP)-Spezifikation erfüllt.

Die Servlet-Komponente kann integraler Bestandteil eines Servers oder auch ein Zusatz sein, der nachträglich zu installieren ist. Die wichtigsten beiden freien Server sind:

Apache Tomcat Tomcat ist die offizielle Referenzimplementierung. Zum Testen von Servlets und JSP kann Tomcat sowohl als Stand-alone-Applikation eingesetzt oder als Ergänzung zum Apache Server eingebunden werden. Er ist ebenso wie der Apache-Server frei und findet sich unter http://jakarta.apache.org/tomcat. Wir nutzen die aktuelle Version 5 (http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html) mit der Servlet 2.4- und JSP 2.0-Spezifikation.

Jetty Ein weiterer freier Open-Source-HTTP-Server und Servlet-Container mit findet sich unter http://jetty.mortbay.org/jetty/. Der Server lässt sich leicht in eigene Programme einbauen, wenn sie Servlet/JSP-Funktionalität benötigen.

Rückblick: JSDK, JSWDK und Tomcat

Der Web-Server von Sun (Sun's Java Web Server), natürlich eine Implementierung vollständig in Java, war der erste Servlet-Server. Mittlerweile hat Sun die Entwicklung eingestellt. Die Entwicklung wird unter dem Netscape/I-Planet-Server fortgesetzt.

Der Ursprung dynamischer Web-Seiten geht auf die Zeit zurück, als das JDK noch unter 1.0 ausgeliefert wurde. Sun nannte das Paket mit den Klassen und Programmen für die Servlet-Umgebung anfangs Java Servlet Development Kit (JSDK). Das Paket wurde bis zur Version 2.1 gepflegt. Da allerdings das alte JDK (Java Development Kit) in Java 2 Software Development Kit (J2SDK) umbenannt wurde, bestand eine Verwechslungsgefahr mit dem JSDK, so dass Sun das JSDK in Java Server Web Development Kit (JSWDK) umbenannte. Zusätzlich nahmen die Entwickler noch Java Server Pages auf. Das JSWDK begann in der Nummerierung wieder bei 1.0.

Nach langer interner Entwicklung hat Sun den Quellcode für das JSWDK der Apache-Gruppe übergeben, so dass die Implementierung jetzt Open Source ist. Die Apache-Gruppe entwickelte das JSWDK weiter und nannte es fortan Tomcat, das nun damit die einzig gültige Referenzimplementierung bildet. Weitere Freigaben werden offen sein und stehen unter dem Java Community Process. Damit endet die Produktlinie, und JSDK und JSWDK kommen ins Archiv. Der Name »Tomcat« wurde von Apache gewählt, da in frühen Entwicklungstagen Tomcat der interne Name für die Servlets bei Sun war. Erschwerend im Versions-Wirrwarr ist, dass die Spezifikation für Servlets und JSP andere Versionen als JSDK, JSWDK und jetzt Tomcat haben.