Kapitel 17 Servlets und Java Server Pages

Lebensfreude entsteht durch Frieden, der nicht statisch,
sondern dynamisch ist.
– Henry Miller

17.1 Dynamische Webseiten und Servlets

In der ersten Generation von Internetseiten war jede Seite statisch auf dem Webserver abgelegt und durch einen eindeutigen Namen identifiziert. Doch dies reichte für viele Anwendungen nicht aus und beschränkte die Interaktionsfähigkeit. Es gibt mehrere gute Gründe, warum Webinhalte dynamisch generiert werden sollten:

Die Seite ist abhängig von Benutzereingaben. Wenn ein Kunde sich beispielsweise für ein Produkt und dessen Preis interessiert hat, dann war es kaum möglich, für jedes Produkt eine aktuelle statische Webseite bereitzustellen. Zudem sieht ja jede Seite anders aus, und so gäbe es sehr viele Seiten. Falls sich die Produktbeschreibung ändert, müsste der Benutzer immer eine aktuelle Seite sehen. In diesem Fall ist es günstig, die Webseiten bei Bedarf zu erzeugen. Für Einkaufssysteme kommt noch eine weitere Eigenschaft hinzu: Der Benutzer bewegt sich über mehrere Seiten und verwaltet einen Warenkorb, der anwachsen oder schrumpfen kann.

Daten ändern sich oft. Eine weitere Anwendung ergibt sich, wenn sich die Seiteninformationen ändern. Wie könnten wir die Anzahl der Benutzer, die bis dato auf eine Seite zugegriffen haben, darstellen? Oder was wollen wir machen, wenn Nachrichten oder Börseninformationen von einer Datenbank kommen und auf einer Webseite aktuell gehalten werden sollen? Dies würde mit statischen Seiten nur unter großen Verrenkungen möglich sein.

Aus diesen Gründen wurden Schnittstellen definiert, wobei die bekannteste das Common Gateway Interface (kurz CGI) ist. Andere Hersteller haben für ihre Server eigene Schnittstellen definiert. So etwa Netscape NSAPI oder Microsoft ISAPI (Internet Information Server). Alle Schnittstellen erlauben dem Webserver externe Programme aufzurufen, die dann eine HTML-Seite generieren, die zurück zum Client geschickt wird. Mittels der CGI-Schnittstelle kann der Browser dem Server Daten übergeben, wie etwa ein Produkt, nach dem das Programm suchen soll. Über den Austausch der Daten haben wir uns schon im Kapitel über die URL-Klasse Gedanken gemacht.

17.1.1 Was sind Servlets? 

Unsere URL-Klasse definiert lediglich die Client-Seite, also den Aufrufer, der den Browser ersetzt. Auf der Server-Seite laufen dann meist keine Java-Programme. Häufig übernehmen Skriptsprachen wie Python oder Perl die Aufbereitung der Daten. Servlets sind nun die Antwort auf CGI-Programme. Dabei sind Servlets aber nicht einfache Java-Programme, die über die CGI-Schnittstelle mit dem Server kommunizieren, sondern eine eigenständige Entwicklung. Wenn wir Java-Programme als normale Applikationen auf der Server-Seite nutzen würden, müsste der Webserver immer dann, wenn eine dynamische Seite generiert wird, die JVM aufrufen und dann das Programm ausführen. Die Laufzeit wäre – das können wir uns denken – ziemlich schlecht. Eine Verbesserung würde darin bestehen, dass der Webserver eine JVM integriert, die immer läuft, und Objekte einzelne Verbindungen innerhalb der Java-Maschine bedienen. Genau das sind Servlets. Sie sind vergleichbar mit Applets. Ein Applet ist ein Java-Programm auf der Client-Seite (im Browser), und ein Servlet ist ein Programm auf der Server-Seite (im Server).

Um eine Vorstellung davon zu bekommen, wie ein Servlet programmiert ist, werfen wir einen Blick auf ein einfaches:

Listing 17.1   FirstServlet.java

import java.io.*;
import javax.servlet.*;

public class FirstServlet extends GenericServlet
{
  public void service( ServletRequest request,
                       ServletResponse response )
      throws ServletException, IOException
  {
    PrintWriter out = response.getWriter();
    out.println( "'Chr! Schnarch! Razong! Chr! Chr! Rapüh!'"+
                 " (Disneys beste Comics, Band 5, S. 218)");
  }
}

17.1.2 Was sind Java Server Pages? 

Servlets sind Server-Programme, die Webseiten erstellen. Das machen sie, indem sie die HTML-Anweisungen mit println() oder Ähnlichem in den Ausgabestrom senden. Wir können uns leicht ausmalen, dass dies nicht nur fehlerträchtig ist, sondern dass auch eine gewünschte Trennung zwischen Informationen und Visualisierung schwer fällt. Ändert sich das Erscheinungsbild, so muss das Programm umgebaut werden. In vielen dynamischen Programmen stecken oft nur ein oder zwei Zeilen Dynamik, der Rest ist statischer HTML-Code. In der Regel ist der Programmierer auch nicht der Designer, und dieser möchte mit Webseiten-Erstellungsprogrammen wie DreamWeaver oder Microsoft FrontPage arbeiten.

Eine JSP (Java Server Pages) geht das Problem genau anders herum an. Wo ein Servlet eine Java-Klasse ist, die sich um die Ausgabe des HTML-Codes kümmert, ist eine JSP eine HTML-Seite mit Java-Code ähnlich wie JavaScript. Sehen wir uns ein einfaches Beispiel an:

Listing 17.2   EinDate.jsp

<html><body>
Hallo Nutzer. Wir haben heute
<%= new java.util.Date() %>.
</body></html>

Selbst eine normale Webseite ohne Java ist eine JSP-Seite.

Nun kann der Designer die Visualisierung der Informationen noch nachträglich anpassen. Das ist sehr wichtig, da so eine Trennung zwischen Informationen und Visualisierung erfolgt.

JSP-Skripte werden vom Server automatisch in Servlets übersetzt. Der Server weiß JSP von normalen HTML-Seiten zu unterscheiden und kompiliert mit Hilfe eines JSP-Übersetzers daraus ein Servlet und stellt es dar. (Prinzipiell könnten JSP auch andere Programmiersprachen einbetten, doch das hat Sun natürlich nicht vorgesehen.) Der Übersetzungsvorgang von JSP in ein Servlet muss dann nur einmal getätigt werden, danach benutzt der Servlet-Container direkt die übersetzte Klasse.

17.1.3 Vorteil von JSP/Servlets gegenüber CGI-Programmen 

Im Gegensatz zu herkömmlichen CGI-Programmen hat diese Nähe zum Server viele Vorteile:

Effizienz: Ein wichtiger Vorteil, der für das Gespann JSP/Servlets und gegen externe CGI-Programme spricht, ist die gute Performance. Sie ergibt sich nicht daraus, dass die Programmiersprache Java verwendet wird, sondern daraus, dass die JVM im Server integriert ist, und daher keine externen Programme gestartet werden müssen. Dies ist bei der CGI-Lösung ein großes Problem, denn jede Anfrage, die ein externes Programm aufruft, startet einen externen Prozess. Bei einer Anfrage am Tag, bei der die Antwortzeit nicht so wichtig ist, spielt das sicherlich keine große Rolle; wollen jedoch viele Clients bedient werden, fällt die Antwortzeit ins Gewicht. Bei Servlets läuft permanent die JVM im Hintergrund. Dabei wird jede Verbindung durch ein Thread-Objekt gehandhabt, dessen Erzeugung und Speicherverbrauch wesentlich optimaler ist als die Verwendung externer Programme. Für CGI-Programme wurde FastCGI definiert, sodass die Geschwindigkeit auch hier besser wird, da keine externen Prozessaufrufe mehr nötig sind.

Datenaustausch und Kommunikation mit dem Webserver: Ein CGI-Programm kann mit anderen CGI-Programmen nur mühsam Daten teilen. Jedes Programm läuft unabhängig von anderen und verwaltet eigene Zustände. Da aber Servlets in einem gemeinsamen Maschinen-Kontext laufen, können sie Daten teilen. Zwecks Optimierung lassen sich beispielsweise Datenbankverbindungen oder vorberechnete Daten gemeinsam nutzen.

Einfachheit: Programmierer lieben zwar unterschiedliche Sprachen, doch ist es sehr praktisch, eine gemeinsame Sprache zu nutzen. Warum sollte eine Firma eine Sprache nur für Webapplikationen verwenden? Nur deshalb, weil sich vielleicht spezielle Probleme in zehn Zeilen lösen lassen und nicht in fünfzig? Für den kommerziellen Erfolg spielt das keine Rolle. Wer einmal versucht hat, eine Benutzerverwaltung oder Auktionsbörse in Perl zu verstehen, der weiß, was ich meine. Wartung und die Möglichkeit, die Software einfach zu erweitern, spielen eine größere Rolle als kurze Entwicklungszeiten für Hacker gegenüber langen Pflegezeiten. Zudem bietet Java alle Eigenschaften der objektorientierten Welt. Für Servlets gibt es ordentliche Klassenbibliotheken, die sowohl den Zugriff auf die Felder der Formulare erlauben als auch Session-Tracking (das Verfolgen der Seiten, die ein Benutzer während einer Sitzung anwählt) oder Cookies. Java bietet die Infrastruktur für parallele Programme mit Threads, eine einfache Möglichkeit auf Datenbanken mittels JDBC zuzugreifen und verteilte Programme mit RMI/CORBA zu verwenden, die vorher mit dem Namensdienst JNDI gefunden wurden.