WWW-Applikationsserver beschleunigen die Entwicklung leistungsfähiger Web-Anwendungen und vereinfachen deren Betrieb. Was tun Applikationsserver, wie arbeiten sie und wie entscheidet man sich für einen bestimmten?

Aktuell”, “interaktiv” und “individuell” sind die Anforderungen an den modernen Web-Auftritt. Dafür reichen statische HTML-Seiten längst nicht mehr. “Just In Time” wird eine Seite erst in dem Moment zusammengebaut, wenn ein Besucher sie abruft. Hinter die klassischen zu präsentierenden Inhalte wie Texte und Grafiken ist also noch eine Programmlogik zu legen, die für die Erzeugung der Seiten sorgt.

Web-Entwicklung ist Teamarbeit. Für eine saubere Aufteilung der Zuständigkeiten werden Inhalte, Layout und Funktionalität getrennt verwaltet. Zur Abtrennung des Layouts werden meist Schablonen (neudeutsch Templates) verwendet, in die dann die Inhalte an vorgegebenen Stellen eingefügt werden. Die Redakteure haben keine Möglichkeit, das Layout nach dem eigenen Geschmack zu verändern, sondern widmen sich ihren Inhalten. Und die Entwickler kümmern sich um die Programmlogik und nur darum.

Verbreitete Scriptsprachen wie PHP, ASP oder Perl bieten diese klare Trennung von nicht, weil die Weblogik in die HTML-Seiten eingebettet wird. An dieser Stelle setzen Web-Applikationsserver an. Sie sitzen – auch als Middleware bezeichnet – in der Mitte zwischen der Anwendung, die einen Web-Dienst realisiert, und dem Webserver, der die Anfragen der Besucher entgegennimmt sowie der Datenbank, die die Komponenten der Website verwaltet. Der englische Name für diese 3-Schichten-Architektur heißt “Three-Tier-Architecture”.

Mindestens 50 verschiedene Software-Produkte tummeln sich inzwischen auf dem Markt. Es gibt proprietäre Server; die bekanntesten sind BEA Weblogic, der Oracle Application Server und IBM WebSphere. Im Open Source sind die Dinge stark in Bewegung. Hier haben sich bisher vor allem Zope [8], Enhydra [4] und Midgard [6] einen Namen gemacht. Eine Auswahl von weiteren OSS-Applikationsservern finden sich im Info-Kasten [2-8].

Wie geht’s?

Wie arbeitet nun so ein Applikationsserver (im folgenden kurz “AS” genannt)? Am Anfang steht wie immer die Web-Anfrage des Besuchers der Site. Durch die Verzahnung zwischen sich und dem AS erkennt der Webserver, dass die Anfrage der Web-Anwendung gilt und gibt sie an den Kollegen weiter. Anhand der URL erkennt der AS, welche Seite und somit welcher Teil der Anwendung abgerufen werden soll. Diese Seite ist nun zu erzeugen. Dazu benötigt werden das Layout und die Programmlogik der Seite. Das Layout ist entweder statisch zugeordnet oder wird anhand von Kriterien wie Browsermodell, Wochentag, Jahreszeit oder gespeicherter Benutzer-Vorlieben dynamisch ausgewählt. Durch Ausführung der Programmlogik werden die inhaltlichen Elemente zu einer kompletten Seite im gewählten Layout zusammengefügt. Das Ergebnis ist heute üblicherweise noch eine HTML-Seite, die an den anfragenden Browser zurückgesandt wird. Später könnten die Daten auch in einem leistungsfähigeren Format wie XML (dazu später) ausgeliefert werden.

Hohe Anforderungen

Ist eine Website erst einmal so umfangreich, dass sich der Einsatz eines AS lohnt, stellt der Betreiber auch umfangreiche Anforderungen an das System:

Ein AS muss eine Seitenanfrage so schnell bearbeiten, als würde einfach eine statische HTML-Datei ausgeliefert. Nichts ist ärgerlicher als potentielle Kunden, die wegen langer Wartezeiten die Site wieder verlassen. Weiterhin muss ein AS-System stabil und zuverlässig laufen. Die erprobten Bausteine Linux und Apache liefern da recht gute Voraussetzungen. Die optimale Lösung für beide Probleme jedoch lautet Clustering. .

XML endlich

In Webapplikationen kommen oft Daten ganz verschiedener Quellen zusammen: Texte in ASCII-Form oder als Textverarbeitungs-Dokumente, Grafiken mit Zusatzinformationen, Kundendaten aus dem Warenwirtschaftssystem und so weiter. Da konnte es nicht lange dauern, bis der Mangel an einem einheitlichen, flexiblen Datenformat unerträglich wurde. Abhilfe trat in Form der Extensible Markup Language XML auf den Plan [1].

Als Heilsbringer der Datensammler sehnlich erwartet, wird XML vielfach inzwischen zur plattform- und anwendungsunabhängigen Repräsentation von Informationen eingesetzt – derzeit jedoch meist nur auf der Anbieterseite.

Die Qual der Wahl

Wie sich denn nun für einen Applikationsserver entscheiden? Bei großen Projektes muss die Software verteilte Entwicklung unterstützen, möglichst mit Versionverwaltung und Zugriffsschutz (Locking).

Als Programmiersprache ist Java prädestiniert, Perl und PHP, aber auch Tcl oder Python haben sich bei WebEntwicklern etabliert. Je nach Anwendung beschleunigt es die Entwicklung, auf flexible Werkzeuge und fertige Applikationsbausteine zurückzugreifen. Komponenten für Datenbankzugriffe, Connection Pooling, Session-Management und Browser-Interaktion sind in Form von Enterprise Java Beans oder als Perl-Module im CPAN ([11]).

Eine flexible und leistungsfähige Datenverwaltung muss immer möglich sein, eventuell mittels XML.

Es bleibt die Feststellung, dass gerade im Bereich “Web-Anwendungen” vieles noch im Fluss ist. Ein Applikationsserver ist ein Puzzle aus so vielen Einzelelementen, die selbst starken Veränderungen unterliegen (XML, Java, usw.), dass hier ein System mit offenen Schnittstellen und Standardkonformität am ehesten Bestand haben kann. Das ist das beste Argument, auch hier Open Source Software einzusetzen.