Um dynamische Seiten zu erzeugen, gibt es Technologien wie Sand am Meer. Vom klassischen CGI-Programm bis zu Skriptsprachen, die in Webseiten eingebettet werden, reicht das Spektrum. Jeder Ansatz hat Vor- und Nachteile, die es abzuwägen gilt. Oftmals entscheidet aber einfach das vorhandene Know-how über die Implementation: Ein guter Perl-Programmierer wird schon aus Zeitgründen nicht über Alternativen wie PHP oder Java nachdenken.
Für Java-Abhängige gibt es auch keinen Grund fremdzugehen. Sie müssen sich nur zwischen zwei grundlegenden Technologien entscheiden. Servlets erzeugen die Webseiten aus Java-Code heraus, während JSPs den Java-Code innerhalb der Webseiten definieren. Der JSP-Server kompiliert die Seite dann beim ersten Aufruf in ein richtiges Servlet und erzeugt so die Webseite.
Der erste Ansatz ist programmzentriert, während die Alternative die Perspektive des Web-Autors darstellt. Beide Ansätze führen zu unübersichtlichen Programmen beziehungsweise Webseiten, und zwar schon bei Seiten, die nur minimal komplexer sind als einfachste Demos. Erst im Zusammenspiel von Servlets und JSPs ist eine klare Trennung von Code und HTML möglich.
Den Ansatz der Trennung von Code und Design verfolgen auch viele Toolkits, die auf Servlets beziehungsweise JSPs aufsetzen. Diese werden hier aber vorerst nicht betrachtet (das bleibt einer späteren Folge vorbehalten), um zunächst die zugrunde liegenden Mechanismen genauer herauszuarbeiten.
Web-Anwendungen
Web-Anwendungen sind entweder dialogorientiert (also klassische interaktive Webseiten) oder serviceorientiert. Es ist zwar technisch kein Problem, interaktive Web-Eingabemasken aus Skripten oder aus anderen Webseiten heraus automatisch aufzurufen (entsprechende Beispiele gibt es auch immer wieder im Linux-Magazin), doch gibt es für serviceorientierte Anwendungen inzwischen bessere Schnittstellen als HTML-Forms mit der Simulation von Benutzereingaben. Webservice heißt hier das Stichwort. In diesem Coffee-Shop geht es aber erst einmal um eine klassische Web-Anwendung.
Eine Web-Anwendung im Sinne der Servlet-Spezifikation ist dabei ein Paket aus statischen und dynamischen Seiten einschließlich der Bilder und anderer Ressourcen sowie aller benötigten Klassen und JAR-Bibliotheken. Dieses Paket, das so genannte Web-Archiv, wird in einer Datei mit der Erweiterung ».war« verpackt. Physisch ist dies - wie JARs auch - ein Zip-Archiv. Weitere Details zum Aufbau von WARs stehen im Kasten "Web-Applikationen".
|
Web-Applikationen
|
|
Die Verzeichnisstruktur einer Web-Applikation ist durch die Servlet-Spezifikation festgelegt. Es gibt zwei Typen von Ressourcen: solche, die der Servlet-Container ausliefern darf, und solche, auf die der Benutzer keinen Zugriff hat, sondern nur die Anwendung. Letztere liegen unterhalb des Verzeichnisses »WEB-INF«. Dateien auf der obersten Ebene, also parallel zu »WEB-INF«, liegen im virtuellen Wurzelverzeichnis der Anwendung. Darunter ist die Verzeichnisstruktur nicht festgelegt, typischerweise gibt es beispielsweise ein »images«-Verzeichnis für GIFs.
Im »WEB-INF«-Verzeichnis liegen die Anwendungs-Konfigurationsdatei »web.xml« und außerdem die Verzeichnisse »classes« und »lib«. Ersteres nimmt der Servlet-Container in den »CLASSPATH« der Anwendung auf, somit sind Java-Klassen unterhalb von »classes« automatisch zu finden. Zusätzlich kommen alle JARs aus dem »lib«-Verzeichnis ebenfalls in den »CLASSPATH«. Virtuelles Wurzelverzeichnis
Typischerweise erstellt man also Servlet-Klassen im »classes«-Verzeichnis und kopiert notwendige zusätzliche Java-Bibliotheken in das »lib«-Verzeichnis. Weitere, anwendungsspezifische Konfigurationsdateien sollten ebenfalls unterhalb von »WEB-INF« stehen. Es ist sogar sinnvoll, sie in den »CLASSPATH« zu legen, da man sie dort mit ganz normalen Java-Mitteln finden kann (zum Beispiel mit Hilfe von »Class.getResourceAsStream(String)«). Liegen sie direkt unterhalb von »WEB-INF«, erfolgt der Zugriff über entsprechende Serv- let-APIs wie etwa »ServletContext.getRealPath(String)« oder »ServletContext.getResourceAsStream (String)«.
Der Administrator hängt das virtuelle Wurzelverzeichnis der Anwendung an geeigneter Stelle in die Verzeichnisstruktur der Website ein. Der Produktkatalog einer Firma könnte beispielsweise unter »http://www.meinefirma.com/produkte/aktuell/katalog/« beziehungsweise unter »http://www.meinefirma.com/kataloge/produkte/« zu finden sein. Der Context-Path
Der Teil zwischen dem Hostnamen und dem Einhängepunkt heißt Context-Path der Anwendung (im ersten Beispiel also »"/produkte/aktuell/katalog/« und im zweiten »/kataloge/ produkte/«). Der Context-Path ist aus Container-Sicht nichts anderes als ein Synonym für die Anwendung. Bei Tomcat ist es die Konfigurationsdatei »conf /server.xml«, die die notwendigen Definitionen enthält. Tomcat macht aber die Administration auf Wunsch auch einfacher, indem die Verzeichnisstruktur unterhalb des »webapp«-Verzeichnisses als Context-Path eingesetzt wird.
Die Web-Anwendung selbst weiß über ihren Context-Path nichts. Alle Dateien der Anwendung liegen aus Anwendungssicht relativ zu »/«. Eine Feinheit ist hierbei jedoch zu beachten: In JSPs und statischen HTML-Seiten darf man bei Links trotzdem nur relative Pfade nutzen, denn hier beziehen sich absolute Pfade auf den Webserver, denn der Servlet-Prozessor sieht den Request ja erst, wenn er die angeforderte Seite als Teil der Web-Anwendung identifizieren kann. Werden Ressourcen (zum Beispiel JSPs, siehe Listing 3) dagegen aus Servlets heraus benutzt, sind absolute Pfade notwendig, die alle relativ zum Context-Path interpretiert werden.
Wer die Entwicklungsumgebung wie im Haupttext aufbaut und Ant nutzt, muss sich nicht um die Details kümmern. Die »build.xml«-Datei aus dem Tomcat-Beispiel sorgt automatisch für die richtige Struktur. Einfachstes Deployment
Wenn alle Dateien vorliegen, müssen sie nur noch mittels JAR zu einem Web-Archiv zusammengepackt werden (auch das kann Ant erledigen). Die Einbindung in den Tomcat-Container, auf gut Neudeutsch Deployment genannt, reduziert sich dann auf das Kopieren in das definierte »webapp«-Verzeichnis und die Konfiguration eines geeigneten Context-Paths in der »conf/server.xml«-Datei.
Je nach der konkreten Konfiguration des Servers packt dieser aus Performance-Gründen das Web-Archiv wieder aus. Wenn später eine neue Version der Anwendung installiert werden soll, sind die ausgepackten Dateien noch vorher zu entfernen.
|
Die Idee hinter Web-Archiven ist einfach: Eine standardkonforme Anwendung soll herstellerunabhängig in jedem beliebigen Servlet-Container laufen. Das Archiv wird dazu in ein serverspezifisches Verzeichnis kopiert, zusätzlich ist nur noch, abhängig von der Ablaufumgebung, eine Reihe von Konfigurationen zu setzen - das war's.
Die Realität sieht meist allerdings etwas anders aus, da sich Servlet-Container zwar in ihrer Grundfunktionalität nicht wesentlich unterscheiden, aber die Hersteller oft nützliche Features anbieten, beispielsweise zur JSP-Gestaltung oder zum Zugriff auf Datenbanken. Diese Features beschleunigen zwar die Implementation, sorgen aber auch für eine Abhängigkeit vom Hersteller. Hier zahlt sich die Verwendung von freien Open-Source-Hilfsmitteln aus.
Der Fahrplan
In diesem Coffee-Shop wird eine einfache Web-Anwendung vorgestellt, die mit Hilfe von Servlets und JSPs implementiert werden soll. Details zur Anwendung sind im Kasten "Websheet - Spreadsheet im Web" beschrieben. Es geht diesmal nur um einen Prototyp sowie um die Entwicklungsumgebung und die Installation im Tomcat-Server.
|
Websheet - Spreadsheet im Web
|
|
Viele kleine Anwendungen haben ein flaches Datenmodell und könnten ohne weiteres als Spreadsheet abgebildet werden. Eine Normalisierung ist aufgrund des Datenvolumens oder der Datenstruktur nicht notwendig. Als Beispiele können einfache Adressverwaltungen oder etwa CD-Listen dienen. Für einzelne Benutzer ist ein Spreadsheet-Programm sicherlich auch die beste Lösung.
Problematisch ist es, wenn verschiedene Anwender gleichzeitig zugreifen müssen. Eine einfache Mitfahrerbörse für eine Firma etwa ist besser im Intranet aufgehoben. Gesperrte Dateien auf Server-Laufwerken gehören dann der Vergangenheit an.
Alle hier aufgeführten Beispiele folgen einem einheitlichen Anwendungsmuster: Datensätze müssen erstellt, geändert, gefunden und gelöscht werden können. Daraus ergibt sich eine Reihe von Anwendungsfällen.
Login: Die Anwendung ist nur für authorisierte Benutzer zugänglich. Dieser Anwendungsfall ist je nach Umgebung und Anwendung optional.
Logout: Sauberes Verlassen der Anwendung. Die Session wird beendet, benutzerbezogene Objekte werden gelöscht. Dieser Anwendungsfall ist nicht zwingend, falls auf ein Login verzichtet wird.
Datensatz erstellen: Der Anwender gibt einen neuen Datensatz ein. Dieser wird nach der Validierung in einer Datenbank gespeichert.
Datensätze suchen: Der Anwender definiert Suchkriterien und erhält als Ergebnis eine Liste von Datensätzen.
Datensätze ändern: Vorhandene Datensätze sollen geändert werden können. Dieser Anwendungsfall nutzt den Anwendungsfall "Datensätze suchen".
Datensätze löschen: Vorhandene Datensätze sollen gelöscht werden können. Dieser Anwendungsfall nutzt den Anwendungsfall "Datensätze suchen".
Detailanzeige: Zu einem Datensatz kann der Anwender alle Details abfragen. Dieser Anwendungsfall nutzt den Anwendungsfall "Datensätze suchen".
|
In den nächsten Folgen des Coffee-Shops wird dann aus dem Prototyp unter Verwendung von Open-Source-Software (überwiegend aus dem Jakarta-Projekt) Stück für Stück eine funktionsfähige Anwendung zusammengebaut.
