Webapplikationen mit Unterstützung von XML

Navigation:

Inhalt -> 2 Grundlagen und Voraussetzungen -> 2.4 Server für Webapplikationen

Neues und Änderungen << Vorheriges Kapitel | Nächstes Kapitel >>

Schon im Kapitel 2.1 Geschichtliches und Entwicklung wurde angedeutet, dass bei Client-Server-Systemen oft auch mehrere Server im Einsatz sind. Das gilt auch bei Servern für Webapplikationen. Im typischen Fall werden die Aufgaben auf Webserver, Applikationsserver und Datenbankserver aufgeteilt. Das Schema einer solchen Konfiguration findet man in Abbildung 3.

Abbildung 3: Typische Architektur für Webapplikationen

Dieses System stellt eine 4-Tier-Architektur19 dar: Der Client als eine Ebene und die drei Server als die übrigen.

Die Funktionsweise dieses System lässt sich vereinfacht folgendermaßen erklären: Der Benutzer arbeitet am Client und gibt im Browser Webadressen (URLs) ein, klickt auf Links oder sendet HTML-Formulare ab. Diese Daten werden vom Browser über das Internet oder Intranet an den Webserver gesendet. Der Webserver analysiert diese Daten. Sind die angeforderten Dokumente statisch (statische Webseiten, Bilder, Stylesheets, etc.), so liegen sie üblicherweise auf der Festplatte des Webservers und dieser kann sie direkt an den Client senden.

Muss allerdings eine Webseite dynamisch erstellt werden, so übermittelt der Webserver die Anfrage vom Client an den Applikationsserver. Dort laufen Programme, die für die Generierung der Webseiten zuständig sind. Üblicherweise müssen bei der Generierung Daten geschrieben und gelesen werden. Diese Daten werden fast immer auf einem eigenen Datenbankserver gehalten. Ist die Generierung unter Zuhilfenahme der Daten am Datenbankserver abgeschlossen, so wird der HTML-Code der Webseite an den Webserver weitergereicht, der sie schließlich über das Internet oder Intranet an den Client sendet. Der Browser kann dann den Inhalt anzeigen.

Zu beachten ist, dass mit "Webserver", "Applikationsserver" und "Datenbankserver" sowohl Hardware als auch die Software gemeint ist. Am Webserver (Rechner) läuft das Webserver-Programm. Analoges gilt für Applikationsserver und Datenbankserver.

Reale Serverstrukturen können sich aber entscheidend von der in Abbildung 3 dargestellten Struktur unterscheiden. Bei vielen kleinen Anwendungen gibt es keinen eigenen Applikationsserver (Hardware). Sowohl die Webserver- als auch die Applikationsserver-Software läuft auf nur einem Rechner. Oft kann man dann nicht mehr von Applikationsserver-Software sprechen. Vielmehr ist ein Modul innerhalb des Webservers für die Erzeugung der dynamischen Webseiten zuständig. Es entfällt also eine Ebene. Das System ist eine 3-Tier-Architektur.

Bei noch kleineren Projekten kann auch die Datenbankserver-Software am Webserver laufen (2-Tier-Architektur). Theoretisch wäre auch der Verzicht auf eine Datenbank denkbar. Stattdessen könnten die Daten in Dateien gespeichert werden. Allerdings ist diese Vorgehensweise nicht zu empfehlen. Datenbanken sind sicherer und schneller. Nur bei ganz einfachen Datenstrukturen oder ganz speziellen Anwendungen könnten Dateien schneller als Datenbanken sein.

Umgekehrt gibt es auch bei größeren Anwendungen verschiedenste Varianten. Die verschiedenen Servertypen können mehrfach vorhanden sein. Anfragen der Clients werden dann z.B. auf verschiedene Webserver aufgeteilt. Auch können für spezielle Anwendungsfälle andere spezialisierte Servertypen zum Einsatz kommen. Man spricht dann von N-Tier-Architekturen. Ein zusätzlicher Servertyp wäre etwa ein Transaktionsserver, der dafür sorgt, dass die Benutzeranfragen auf die verfügbaren Server bzw. Prozesse aufgeteilt und Transaktionen immer komplett oder gar nicht durchgeführt werden. Die Suchmaschine Google verwendet z.B. geschätzte 54.000 Server für verschiedenste Aufgaben.20

Neben der Frage nach der Anzahl der Server, die zum Einsatz kommen sollen, ist auch die Wahl der Soft- und Hardwareplattformen entscheidend. Dabei ergibt sich die Hardwareplattform oft aus der Wahl der Softwareplattform. Es stehen sowohl kommerzielle als auch Open-Source Produkte zur Verfügung.

Die Marktführer bei Datenbanken sind eindeutig Oracle, IBM und Microsoft, wobei sich Oracle und IBM einen Kampf um den ersten Platz liefern [Heise News 2002]. IBM geht dabei mit zwei Produkten, nämlich DB2 und Informix, ins Rennen. Oracle mit seinem gleichnamigen Datenbank-Produkt und Microsofts Datenbank-Server Software nennt sich MS-SQL Server. In der Liste der schnellsten Datenbanksysteme führt momentan ein Clustersystem mit dem Microsoft SQL Server. Beim Benchmark des Transaction Processing Performance Council nach der TPC-C-Spezifikation hat das System den ersten Platz erreicht. Bei der TPC-C-Spezifikation werden die Datenbanksysteme mit Abfragen getestet, wie sie typischerweise bei Online-Transaktionsprozessen vorkommen. Bei diesem Benchmark spielt allerdings auch die Hardware eine sehr große Rolle. [Heise News 2002b] [TPC 2002] Die genannten Produkte sind alle ausgereift und haben sich tausendfach im Produktionseinsatz bewährt.

Freie Datenbanksoftware

Neben den kommerziellen Datenbank-Produkten gibt es auch freie, die für Webapplikationen gar nicht so selten - vor allem für kleinere Anwendungen - verwendet werden. Das bekannteste Produkt ist MySQL. MySQL wird von der Firma MySQL AB entwickelt und verkauft, aber auch unter der GNU General Public License (GPL) kostenlos weitergegeben [MySQL 2002]. Seit kurzem gibt es die ersten 4.0.x Versionen von MySQL. Den Großteil der Installationen machen aber nach wie vor die 3.23.x Versionen aus. Vor allem letztere haben noch einige Mängel, die einen Einsatz anstatt eines professionellen DBMS nicht erlauben. Insbesondere wurde das fehlende Transaktionsmanagement kritisiert. MySQL 4.0.x unterstützt Transaktionen nach dem ACID-Prinzip (siehe Kapitel 2.1.1 Entwicklung von Computeranwendungen), zeilenweises Sperren von Datensätzen (row-level locking) und Fremdschlüsseln (foreign keys). Trotzdem fehlen aber noch Subselects, Triggers und Stored Procedures. Durch das Fehlen von Subselects müssen oft aus Performanz-Sicht viel aufwändigere Joins durchgeführt werden. Das Fehlen von Trigger erschwert automatische Aufgaben. Eine Stored Procedure enthält Code, der am Datenbankserver selbst ausgeführt wird. Zum Beispiel mehrere Datenbankabfragen auf einmal. Dadurch lassen sich einige Aufgaben vereinfachen und vor allem beschleunigen. Subselects sind allerdings in der Version 4.1 und Stored Procedures in der Version 5.0 geplant.

Bei kleinen Datenmengen und weniger kritischen Aufgaben kann sich MySQL insbesondere bei der Geschwindigkeit mit den großen kommerziellen Konkurrenten messen. Außerdem sprechen der hohe Verbreitungsgrad und die vielen verfügbaren Werkzeuge für MySQL. [Gitschel 2001] [MySQL Benchmarks 2002] [Mischke 2002]

Das zweite relativ weit verbreitete freie Produkt ist PostgreSQL. PostgreSQL ist großteils SQL92 konform und unterstützt daher die Funktionen, die MySQL fehlen. Allerdings ist PostgreSQL nicht so weit verbreitet wie MySQL. Daher gibt es nicht so viele Werkzeuge wie für MySQL und es mangelt auch an guter Dokumentation. Außerdem ist es langsamer als sein freier Konkurrent. Vom Funktionsumfang kann es dafür mit kommerziellen Produkten durchaus mithalten. [Mischke 2002]

Die meisten Datenbanksysteme, die heute verwendet werden, sind relationale Datenbanken. Bei relationalen Datenbanken sind die Daten in Tabellen gespeichert. Die Tabellenspalten geben die Bezeichnung des Datenfelds und deren Typ vor. In jeder Zeile liegt dann ein Datensatz. Die Tabellen sind über bestimmte Felder ("Schlüssel" und "Fremdschlüssel") miteinander verknüpft. Daten in einer relationalen Datenbank können mit Hilfe der Standard Query Language (SQL) abgefragt, verändert und neu hinzugefügt werden. Mit der Hilfe von Indizes können die Daten sehr schnell in einer relationalen Datenbank gefunden werden. Bei solchen Daten spricht man auch von strukturierten Daten.

Daten- und dokumentzentriert

XML-Daten so zu speichern, dass schnell auf bestimmte XML-Datenfelder zugegriffen werden kann, ist dagegen nicht so trivial. Man unterscheidet zwischen daten- und dokumentzentrischen XML-Daten bzw. -Dokumenten.

Datenzentrische XML-Dokumente enthalten Daten, die einfach in eine relationale Struktur gebracht werden können. Es gibt keine Rekursion in XML-Schema- oder DTD-Definitionen und wenig bis gar keine "Mixed-Content" Elemente. "Mixed-Content" Elemente sind Elemente, die sowohl reinen Text als auch Elemente, teilweise verschachtelt, enthalten. Eine Rechnung könnte so ein datenzentrisches XML-Dokument sein. Normalerweise kann eine Rechnung einfach in einer relationalen Struktur mit Tabellen gerspeichert werden. [Ziegler 2001] [Bourret 2002]

Schwieriger wird es allerdings bei dokumentzentrischen XML-Dokumenten. Diese enthalten Rekursionen und Elemente mit Mixed-Content. Ein typische Beispiel: Ein XHTML-Dokument. Elemente können beliebig ineinander verschachtelt sein. Außerdem können Elemente an beliebiger Stelle im Text vorkommen. Bei diesen Dokumenten ist es nicht einfach, sie so zu speichern, dass auf die Daten schnell und einfach zugegriffen werden kann. Bei Abfragen auf rekursive Elemente müssen transitive Hüllen berechnet werden, um alle passenden Daten zu erhalten.

Natürlich können viele XML-Dokumente nicht genau dem daten- oder dem dokumentzentrischen Typ zugeordnet werden. Vielmehr sind die Übergänge fließend.

Speichern von XML-Daten und XML-Dokumente in Datenbanken

Um XML-Daten oder XML-Dokumente in einer Datenbank speichern zu können, bieten sich nach [Bourret 2002] hauptsächlich folgende Möglichkeiten an:

• XML-Middleware, die auf ein herkömmliches, relationales DBMS aufbaut.
• XML-enabled relationes DBMS. Hierbei wird eine relationales Datenbank Management System um XML-Fähigkeiten erweitert. Alle oben erwähnten kommerziellen DBMS sind XML-enabled.
• Native XML-Datenbanken.
• Content Management System. Es erlaubt die Verwaltung von Dokumenten und ist in dem Fall auf einer nativen XML-Datenbank aufgebaut.

Im Folgenden wird auf verschiedene zur Speicherung von XML-Daten und XML-Dokumenten genauer eingegangen. Zu beachten ist, dass hier zwischen XML-Daten und XML-Dokumenten unterschieden werden kann. XML-Dokumente sind, wie der Name schon sagt, vollständige Dokumente. Alle Elemente des Dokuments, wie Kommentare und Processing Instructions21 und die Reihenfolge sind entscheidend. Bei XML-Daten stehen, wie ebenfalls der Name schon sagt, die Daten im Mittelpunkt. XML dient als Hilfsmittel die Daten zu halten.

XML-Dokumente im Dateisystem

XML-Dokumente können natürlich einfach als Dateien abgespeichert werden. Mit Programmen, die eine Volltextsuche erlauben, können diese Dateien durchsucht werden. Dabei tritt allerdings das Problem auf, dass diese Programme nur schwer zwischen Markup und dem eigentlichen Dateninhalt unterscheiden können.

XML-Dokumente in BLOBs in relationalen Datenbanken

XML-Dokumente können in relationale Datenbanken ganz trivial als BLOBs (Binary Large Objects) gespeichert werden. Auch Datenbanken bieten Mechanismen zur Volltextsuche an. Teilweise sogar mit unscharfer Suche, die es auch erlaubt, den Suchbegriffen nur ähnliche Daten zu finden. Außerdem bieten Datenbanken Transaktions-Management, Sicherheitskonzepte und Mehrbenutzerbetrieb. Über zusätzliche Tabellen ist es darüber hinaus möglich, Indizes zu erstellen. Diese müssen allerdings manuell erstellt werden.

XML-Daten in Tabellen in relationalen Datenbanken

Werden die Daten in Tabellen gespeichert, ergibt sich das Problem, dass nicht die gesamte Struktur des XML-Dokuments gespeichert wird.22 Kommentare oder Processing Instructions und die Reihenfolge der Elemente werden nicht abgespeichert, und können somit auch nicht mehr rekonstruiert werden. Daher eignet sich diese Methode weniger für vollständige XML-Dokumente.

XML-Daten können auf zwei verschiedene Arten auf Tabellen abgebildet (mapped) werden. Die erste Methode ist das tabellenbasierte Mapping, das von vielen Middleware-Produkten verwendet wird. Dabei werden die Tabellen der Datenbank im XML-Format angegeben:

<table>
  <row>
    <column1>...</column1>
    <column2>...</column2>
    ...
  </row>
  <row>
    ...
  </row>
  ...
</table>

Tabellenbasiertes Mapping ist beispielsweise interessant, wenn Daten von einer Datenbank in eine andere transferiert werden sollen. Wenn die XML-Daten nicht in das im Beispiel gezeigte Format passen, dann ist es nicht anwendbar.

Bei der zweiten Methode, dem objektrelationalen Mapping, werden Elemente im XML-Dokument, die Kind-Elemente und Attribute oder "mixed Content" enthalten, als Klassen gesehen. Für jede Klasse wird eine Tabelle in der relationalen Datenbank generiert. Attribute und Elemente, die keine Elemente oder Attribute sondern nur einfache Daten (String, Integer, etc.) enthalten, sind Spalten in diesen Tabellen. Über Schlüssel und Fremdschlüssel werden die Tabellen dann so verknüpft, dass sie den Inhalt des ursprünglichen XML-Dokuments widerspiegeln. Diese Methode wird bei einigen Middleware-Produkten und bei allen XML-enabled Datenbanken verwendet. Zu beachten ist, dass diese Methode je nach Struktur der XML-Daten oder -Dokumente sehr langsam werden kann, wenn beim Arbeiten mit den Daten sehr viele Tabellen über Joins23 miteinander verknüpft werden müssen.

Native XML-Datenbanken

Der Begriff "Native XML-Datenbank" kommt eigentlich aus dem Marketing. Die deutsche Firma Software AG hat ihre Datenbank "Tamino" als eine native XML-Datenbank bezeichnet.

In [Bourret 2002] schreibt der Autor eine mögliche Definition einer nativen XML-Datenbank, die von den Mitgliedern der XML:DB Mailing Liste entwickelt wurde. Zusammengefasst ist die grundlegende logische Struktur einer nativen XML-Datenbank ein XML-Dokument. Bei einer relationalen Datenbank ist diese logische Struktur dagegen eine Tabelle. Es muss bei einer nativen XML-Datenbank möglich sein, alle Inhalte eines XML-Dokuments zu speichern. Diese müssen auch wieder in der richtigen Reihenfolge ausgelesen werden können. Die physikalische Struktur der Daten ist dagegen nicht festgelegt.

Native XML-Datenbanken bieten - ebenso wie relationale - Transaktionsmechanismen, Mehrbenutzerbetrieb, Sicherheitskonzepte und Programm-APIs (Application Programming Interface). Mit Hilfe dieser APIs können andere Programme auf die Datenbank zugreifen. Weiters können Indizes auf XML-Elemente und Attribute definiert werden.

Der Einsatz von nativen Datenbanken bietet sich an, wenn semistrukturierte Daten vorhanden sind. Das sind beispielsweise die oben erwähnten dokumentzentrischen Daten, die nur schwer in eine relationale Struktur zu bringen sind. Mit nativen XML-Datenbanken hat man auch den Vorteil, dass man auf spezielle XML-Fähigkeiten, wie XML-Abfragesprachen (XML Query Languages), zurückgreifen kann.

Die Daten in XML-Datenbanken sind als XML-Dokumente abgespeichert. Abfragen auf Dokumentebene sind daher sehr schnell. Werden bei einer Abfrage mehrere Dokumente benötigt, ist das allerdings aufwändiger und langsamer. Zum Vergleich: Bei den XML-enabled Datenbanken, die die Dokumente in mehrere Tabellen aufteilen (Stichwort: objektrelationales Mapping), sind auch Zugriffe auf einzelne Dokumente sehr langsam.

Native XML-Datenbanken liefern ihre Daten in XML-Form. Das ist besonders interessant, wenn die Daten in dieser Form benötigt werden. Beispielsweise wenn die Daten auf entfernten Rechnern weiterverarbeitet werden, und die Übertragungsschnittstelle XML-basiert ist. Werden die Daten dagegen lokal benötigt, müssen diese erst geparst werden, um die benötige Information auslesen zu können. Dies bringt einen weiteren Geschwindigkeitsnachteil.

Persistent DOMs

Eine weitere Möglichkeit, XML-Daten zu speichern, sind Persistent DOMs (PDOMs). Das ist nichts anderes als das DOM, das üblicherweise im Arbeitsspeicher gespeichert ist, auf die Festplatte zu speichern.

XML-Abfragesprachen

Relationale Datenbanken haben mit SQL eine äußerst mächtige Abfragesprache, die über die reinen Abfrage hinaus auch das Manipulieren von Daten und Datenstrukturen erlaubt. Bei Abfragesprachen für XML sind die Standards und Spezifikation noch nicht so weit fortgeschritten. Außerdem erlauben alle XML-Abfragesprachen nur Abfragen und kein Ändern von Daten.

Template-basierte XML-Abfragesprachen

Die zur Zeit am meisten verwendete XML-Abfragesprache ist die Template-basierte Abfragesprache. Wie diese funktioniert, kann man am besten anhand eines Beispiels sehen:

<?xml version="1.0"?>
<BookCatalog>
  <SelectStmt>SELECT Title, ISBN, Author FROM Book</SelectStmt>
  <Book>
    <Title>$Title</Title>
    <ISBN>$ISBN</ISBN>
    <Author>$Author</Author>
  </Book>
</BookCatalog>

Daraus ergibt sich dann:

<?xml version="1.0"?>
<BookCatalog>
  <Book>
    <Title>XSLT Programmer's Reference</Title>
    <ISBN>1-861005-06-7</ISBN>
    <Author>Michael Kay</Author>
  </Book>
  <Book>
    ...
  </Book>
  ...
</BookCatalog>

Es wird hier also ein Template mit einer Select-Abfrage (SelectStmt) verwendet. Wird die Abfragen ausgeführt, so wird ein XML-Dokument entsprechend dem Template mit Daten gefüllt und zurückgeliefert.

SQL/XML

SQL/XML ist ein erweitertes SQL, das es ermöglicht, die Ergebnisdaten der Abfrage in XML-Form zu erhalten. Es haben sich mehrere Firmen zusammengeschlossen um hier einen Standard zu erarbeiten. Die ersten Arbeiten dazu wurden ANSI und ISO zur Standardisierung vorgelegt.

SELECT XMLElement("Book",
                  XMLAttributes(ISBN),
                  XMLElement("Title", Title),
                  XMLElement("Author", Author)) AS xmldocument
FROM BookCatalog WHERE ISBN="1-861005-06-7"

liefert folgendes Ergebnis:

<Book ISBN="1-861005-06-7">
  <Title>XSLT Programmer's Reference</Title>
  <Author>Michael Kay</Author>
</Book> 

XML Query Language (XQuery)

Die beiden oben genannten Abfragesprachen können nur auf XML-Daten zugreifen, die in relationalen Datenbanken gespeichert sind. Die XML Query Language (XQuery) soll hier Abhilfe schaffen. Sie erlaubt auch die Abfrage über XML-Dokumente. Sollen Daten aus einer relationalen Datenbank abgefragt werden, müssen diese erst mittels tabellenbasiertem oder objektrelationalem Mapping auf ein XML-Dokument übertragen werden. An XQuery arbeitet momentan eine Arbeitsgruppe des W3C.

Die beiden am häufigst anzutreffenden Webserver sind der Apache Webserver und Microsofts IIS (Internet Information Server). Der Apache ist das Vorzeigeprodukt der Open-Source Gemeinde und wird von der Apache Software Foundation [Apache 2002] entwickelt. Vom Apache gibt es Versionen für viele verschiedene Betriebssysteme, insbesondere die Unix-Derivate (wie Solaris der Firma Sun und Linux) und auch Windows. Da der Apache Open-Source ist, kann er kostenlos heruntergeladen werden. Gemeinsam mit z.B. dem Betriebssystem Linux erhält man ein kostenloses Betriebssystem-Webserver-Gespann. Der Microsoft IIS ist dagegen nur auf der Windows Plattform verfügbar. Der IIS ist bei den NT-Versionen von Windows (Windows NT, Windows 2000, Windows XP) enthalten, muss also ebenfalls nicht extra gekauft werden. Allerdings ist das Betriebssystem sehr wohl kostenpflichtig.

Vor einigen Monaten ist die neue Version 2.0.x des Apache erschienen. Sie verspricht einen deutlichen Performancegewinn, läuft entscheidend besser auf den verschiedenen Plattformen, vor allem Windows, und erlaubt eine einfachere und bessere Einbindung von Modulen. Da aber noch nicht alle Module fehlerfrei auf 2.0.x portiert wurden, wird in der Praxis meist noch eine der 1.3.x Versionen eingesetzt. [Richter 2002]

Verbreitung der Webserver

Leider sind Aussagen über die tatsächliche Verbreitung nicht besonders einfach zu treffen. Die Netcraft Studie vom November 2002 [Netcraft 2002] bescheinigt dem Apache 60,80% Verbreitung, dem Microsoft IIS 28,69%, dem neuen Server Zeus 2,17% und allen anderen kaum über bzw. unter 1%. Das Problem ist allerdings, dass bei dieser Studie nach Domains gezählt wird. Auf einem Server können allerdings hunderte bis tausende Domains gehostet werden. Gerade bei Billig-Providern wird das oft auf Basis von Linux und Apache gemacht, wodurch hier der Apache Server in der Statistik profitiert. Weiters wird bei dieser Studie die Wichtigkeit der Domains nicht berücksichtigt. Auch jede private Webseite mit eigener Domain zählt also mit. Im Jahr 2000, als der Apache laut Netcraft einen ähnlich hohen Verbreitungsgrad hatte, gab es auch eine Studie vom ENT Online Magazin, das die Webserver der Top 500 Firmen auswertete. Dabei erreichte der IIS 41,6%. Apache lag mit 15,6% hinter Netscapes iPlanet Server (34,6%) nur auf Platz drei. Allerdings war diese Studie äußerst Microsoft-freundlich ausgelegt [Schmidt 2000].

Geschwindigkeitsvergleiche

Ebenso wie über den Verbreitungsgrad sind auch Aussagen über die Geschwindigkeit nur schwer zu machen. Bei statischen HTML-Seiten werden die Grenzen der Systeme nur erreicht, wenn mehrere Netzwerkkarten mit einer Übertragungskapazität von 100 MBit/s verwendet werden. Auf Hochleistungshardware auch mit nur einer CPU werden hier mehrere tausend Anfragen pro Sekunde erreicht. Dabei liegt der Datendurchsatz nur unwesentlich hinter der reinen Übertragungsrate der Netzwerkkarten. Und selbst hier lässt sich noch etwas Performance gewinnen, wenn man den TUX Webserver für Linux verwendet. Dieser kleine Server ist als Linux-Kernel-Modul geschrieben und daher besonders leistungsfähig. [Schmidt 2000a]

Bei dynamischen Seiten hängt das Verhältnis sehr von der verwendeten Programmiersprache ab. Wobei hier manche Sprachen nur auf einer der beiden Plattformen zur Verfügung stehen bzw. nicht auf beiden gleich gut optimiert sind. Außerdem arbeiten bei dynamisch generierten Webseiten meist Datenbanken im Hintergrund. Je nach Anwendung können diese ebenfalls das langsamste Glied in der Kette sein.

Weiters kommt hinzu, dass mit Apache 2.0.x und mit der Microsoft .NET Umgebung neue Produkte auf dem Markt sind, für die es noch nicht genügend unabhängige Performancevergleiche gibt. Ein Sieger lässt sich also nicht eindeutig feststellen.

Im Folgenden wird meist von HTML-Dokumenten gesprochen, die mit Hilfe von Programmen dynamisch erstellt werden.24 Die HTML-Dokumente werden üblicherweise von einem Browser angefordert und nach der Erstellung an ihn zurückgesendet. Genauso gut können aber auch Anwendungen XML-Dokumente von einem Webserver anfordern. Auch diese können von Programmen generiert werden. Dies wird beispielsweise bei Webservices benötigt.

Common Gateway Interface

Der erste Schritt in diese Richtung war die Entwicklung des Common Gateway Interface (CGI). CGI ist eine Schnittstelle, die der Webserver externen Programmen zur Verfügung steht. Wird statt einer statischen Seite so ein Programm aufgerufen, so wird dieses ausgeführt. Die Ausgaben des Programms werden an den Webbrowser gesendet. Grundsätzlich können CGI-Programme mit jeder Programmiersprache erstellt werden. [CGI 2002]

Perl

Die Sprache, die am häufigsten im Zusammenhang mit CGI benutzt wird, ist Perl. Perl hat seinen Ursprung in der Programmiersprache C und einigen Unix Werkzeugen wie sed oder awk [Christiansen 1999]. Perl ist Open Source und daher kostenlos erhältlich. Außerdem enthält es ausgezeichnete Werkzeuge zur Textmanipulation, wie sie bei Webapplikationen oft benötigt werden. Ein Nachteil von Perl ist allerdings, dass es eine relativ kryptische Syntax hat. Einfache Programme können zwar schnell erstellt werden, aber um optimale Perl-Programme zu schreiben, muss man sich intensiv mit der Sprache beschäftigen. Ein weiterer Nachteil von CGI und Perl ist, dass bei jedem Aufruf einer dynamischen Seite, die von einem Perl-Programm generiert werden soll, der Perl-Interpreter neu geladen werden muss, was zu großen Performanzverlusten führt. Es stehen allerdings mit mod_perl für den Apache und FastCGI schnellere Alternativen zur Verfügung. Trotzdem wird bei neuen Projekten meist auf modernere Sprachen wie Java, PHP oder eine der ASP.NET Sprachen von Microsoft zurückgegriffen. Diese bieten einfachere Datenbankanbindungen, Sessionmanagement und teilweise weitere Mechanismen, wie sie für Webapplikationen benötigt werden, aber Perl von sich aus nicht besitzt.

Java

Java ist eine objektorientierte Sprache, die sich sehr stark an die Syntax der Sprachen C bzw. C++ angelehnt ist. Java ist aber eine plattformunabhängige Sprache. Dies wird folgendermaßen erreicht: Der Quellcode wird in Bytecode umgewandelt. Dieser Bytecode wird dann von einer so genannten Java Virtual Machine (JVM) ausgeführt. Diese JVM ist für fast alle Rechnerplattformen und Betriebssysteme verfügbar. So kann ein und dasselbe Programm auf den verschiedensten Rechnern ablaufen. Bei anderen Programmiersprachen müssen die Programme zumindest neu kompiliert werden, um auf anderen Plattformen und Betriebssystemen zu laufen. Meist sind auch aufwändige Codeänderungen notwendig.

Java eignet sich daher besonders für Anwendungen rund um das Web. Einerseits als Applets, andererseits als Servlets oder JSPs. Applets sind kleine Java-Programme, die im Webbrowser des Benutzers ablaufen.

Für diese Arbeit interessant sind allerdings die Servlets bzw. die JSP. Servlets sind Java-Programme, die von einer bestimmten Klasse abgeleitet (im objektorientierten Sinn) sind. Über die Methoden dieser Klasse kann auf die für Webseiten benötigten Daten zugegriffen werden. Die Ausgabe des Programms (üblicherweise eine HTML-Seite) wird vom Webserver an den Browser geschickt. Ähnlich wie bei einem CGI-Programm. Mit dem Unterschied, dass die JVM immer im Speicher bleibt, und nicht bei jedem Aufruf neu geladen werden muss. Dadurch sind Servlets schneller. [Klute 1998]

Bei Servlets ist das Programm für die gesamte Ausgabe der HTML-Seiten zuständig. Bei den Java Server Pages (JSP) ist es umgekehrt. Hier hat man eine normale HTML-Seite, in der Java-Code eingebettet ist. So eine JSP sieht dann etwa so aus:

<html>
  <head>
    <title>Ein JSP Beispiel</title>
  </head>
  <body>
    <b>Hallo</b>. Wir haben heute
    <% out.print( new java.util.Date() ); %>
  </body>
</html>


Das könnte zu folgender HTML-Seite führen:

<html>
  <head>
    <title>Ein JSP Beispiel</title>
  </head>
  <body>
    <b>Hallo</b>. Wir haben heute
    Sat Dec 07 16:13:55 CET 2002
  </body>
</html>

Wie man sieht, wird alles zwischen "<%" und "%>" als Javacode interpretiert und ausgeführt [Ullenboom 2002].

Für Java gibt es Unmengen von Code-Bibliotheken und Komponenten. Mit der Java 2 Enterprise Edition (J2EE) von Sun steht eine umfangreiche Plattform zur Entwicklung von Geschäftsanwendungen - auch verteilt auf mehreren Servern - zur Verfügung. J2EE beinhaltet beispielsweise die Enterprise Java Beans (EJB). Das sind Komponenten, die unter anderem Lastverteilung, Transaktionsmanagement, Sicherheitsmechanismen und Zugriff auf CORBA-Objekte ermöglichen. Weiters unterstützt J2EE die Erstellung von XML-Webservices. Mittels RMI können Java-Programme auf verschiedenen Servern miteinander kommunizieren. [Merkle 1999] [J2EE 2002]

Je nach Anwendungsbereich kann man bei Java auf kommerzielle und kostenlose Werkzeuge zurückgreifen. Viele der Open Source Produkte der Apache Software Foundation bauen auf Java. Das Apache Jakarta Projekt bietet hier neben anderen Produkten die Servlet- bzw. JSP-Engine Tomcat an. Diese läuft sowohl auf Apache als auch auf Microsofts IIS Webserver. [Jakarta 2002]

Weiters bietet die Firma Sun als Entwickler von Java kostenlose Werkzeuge und kommerzielle Produkte an. Auch die Applikationsserver Websphere von IBM oder WebLogic von BEA arbeiten mit Java. Unter java.sun.com/ findet man Werkzeuge, um mit Java beginnen zu können, und weiterführende Literatur.

Cocoon: Extensible Server Pages

Ein besonderes Produkt des Apache XML Projects ist Cocoon. Apache Cocoon erlaubt es konsequent Daten und Präsentation zu trennen. Das Ausgangsdokument ist ein XML-Dokument mit eingebettetem Java-Code. Mit Hilfe des Java-Codes können XML-Dokumente dynamisch erstellt werden. Diese XML-Dokumente werden in Anlehnung an die Java Server Pages Extensible Server Pages (XSP) genannt.

Anschließend werden diese dynamisch generierten Dokumente von einem XML-Parser in einen DOM-Baum umgesetzt. Mit Hilfe eines XSLT-Prozessors und XSL-Stylsheets werden sie dann in das endgültige Ausgabeformat, beispielsweise HTML oder XHTML gebracht [Mintert 2000]. Coocon kann man unter [Cocoon 2002] downloaden. Außerdem findet man dort auch weitere Dokumentationen.

Wie bereits angesprochen, ist das eine ausgesprochen saubere Lösung in Hinblick auf die Trennung von Daten, Struktur und Darstellung. Leider ist der Seitengenerierungsprozess aber relativ aufwändig. Bereits generierte Seiten werden zwar in einem Cache zwischengespeichert, aber gerade bei Webapplikationen bringt das meist wenig. Bei Webapplikationen sind Seiten meist für genau einen Benutzer angepasst. Kein zweiter Benutzer erhält dieselbe Seite. Daher können keine Seiten aus dem Cache verwendet werden, sondern müssen immer neu generiert werden.

ASP.NET

Microsoft präsentiert mit .NET eine komplette Entwicklungsumgebung für herkömmliche Windows Programme und dynamische Webseiten. Mit .NET ist man zwar auf die Microsoft Plattform gebunden25, aber .NET ist sprachenunabhängig. Microsoft führt dazu die Common Language Specification (CLS) ein. Alle .NET Sprachen müssen zu einem gemeinsamen Zwischencode kompilierbar sein. Dieser ist vergleichbar mit dem Bytecode, den der Java-Compiler erzeugt. Microsoft nennt ihn Microsoft Intermediation Language (MSIL). Die so genannte Common Language Runtime (CLR), die mit der Java Virtual Machine vergleichbar ist, führt diesen MSIL-Code aus. Nur mit der Sprache C++ kann auch direkt ein ausführbares Programm erstellt werden.

Bei der Entwicklungsumgebung von Microsoft für .NET sind bereits fünf Sprachen inkludiert: C++, C# (sprich: C sharp, eine Java-Erweiterung), Visual Basic.NET, JScript.NET (Javascript ähnlich) und J# (ein an .NET angepasstes Java). Mittlerweile gibt es bereits über 25 Sprachen für .NET, die der CLS entsprechen [Schwichtenberg 2002]. Darunter sind auch Sprachen, wie Cobol, Fortran oder Delphi (Pascal) zu finden. Einen Überblick findet man unter [Schwichtenberg 2002a].

Bei .NET dient zur Erzeugung dynamischer Webseiten ASP.NET. War das alte ASP (Active Server Pages)-Konzept tatsächlich schon veraltet, gibt es bei ASP.NET umfangreiche Neuerungen. Beim alten ASP konnte nur mit VBScript (Visual Basic ähnlich), und JScript (Javascript ähnlich) programmiert werden. Beide Sprachen boten nur einen geringen Funktionsumfang. Viele benötigte Funktionen mussten mit zugekauften oder selbst erstellten COM-Komponenten realisiert werden, die in DLLs ausgelagert waren. Dies führte häufig zu Versionskonflikten. Die Installation und das Updaten der DLLs war häufig mit Serverneustarts und damit Ausfallszeiten verbunden.

Für das neue ASP.NET wurde eigens die Sprache C# entwickelt. C# ist eine Erweiterung von Java und unterstützt genau das, das die MSIL und die Common Language Runtime ermöglicht. So ist C# für ASP.NET die Programmiersprache erster Wahl. Weiters ist in ASP.NET noch Visual Basic.NET (kurz: VB.NET) und JScript.NET fix integriert. Die Syntax dieser Sprachen wurde erweitert, damit diese mit .NET besser zusammenarbeiten. Insbesondere wurde VB.NET mit Konzepten der objektorientierten Programmierung erweitert.

ASP.NET bietet eine Menge an Klassenbibliotheken und Mechanismen, um das Erstellen von Webapplikationen zu vereinfachen. Microsoft hat sich besonders bei der Unterstützung von Webservices hervorgetan. Weiters bietet es so genannte HTML- und Web-Controls für Elemente in HTML-Formularen an. Dabei bietet es Schnittstellen, die möglichst ähnlich den Schnittstellen zu Bedienelementen in herkömmlichen Windowsprogrammen sind. Somit können normale Anwendungen schnell ins Web portiert werden. Dem Programmierer wird einige Arbeit abgenommen, da der entsprechende HTML- und Javascript-Code automatisch generiert wird. Dabei kann auch die Eingabedatenvalidierung automatisiert werden. Problematisch ist diese Vorgehensweise aber insofern, da man weniger Kontrolle über den erzeugten Code hat. Zusätzlich ist der erzeugte Code sehr stark für Microsofts Internet Explorer optimiert, sodass sich der Einsatz eher nur bei Intranets mit IE-Browsern empfiehlt. [Wenz 2002]

Interessant ist auch das so genannte Code-Behind-Modell. Dabei können Code und Layout in zwei verschiedene Dateien getrennt werden. Das macht sich bezahlt, da es gerade bei Sprachen wie JSP, ASP, PHP, wo Programmcode innerhalb des HTML-Codes eingebettet ist, oft zu einer starken Vermischung von Code und Layout kommt.

Das neue ASP.NET ist auch bedeutend schneller als das alte ASP. Microsoft selbst spricht von drei bis fünf mal schneller [ASP.NET 2002]. Natürlich ist das eine Marketing-Aussage. Wenn man sich allerdings die Vorgehensweise bei ASP.NET ansieht, dann sieht man schnell, dass es schneller sein muss, als das alte ASP, dessen Code nur interpretiert wurde. In der folgenden Grafik (aus [Schwichtenberg 2002]) sieht man den Weg des Quellcodes zum nativen Maschinencode:

Abbildung 4: .NET: Vom Quellcode zum nativen Maschinencode

Der Quellcode (hier C#) wird über den Compiler (hier ein C# Compiler) in die MSIL übersetzt. Dabei kann auf die umfangreichen Klassenbibliotheken zurückgegriffen werden. Bei dynamischen Webseiten geschieht diese Übersetzung automatisch. Der generierte MSIL-Code wird zwischengespeichert. Falls sich der Quellcode ändert, wird der MSIL-Code neu übersetzt.

Im nächsten Schritt wird der MSIL-Code in der Laufzeitumgebung CLR (Common Language Runtime) mit Hilfe eines Just in Time Compilers (JIT) vor der Ausführung in nativen Maschinencode übersetzt. Anschließend wird der Maschinencode ausgeführt und so die Webseite erzeugt. Für jede Webseite kann dabei definiert werden, ob die Seite in einem Cache zwischengespeichert werden soll. Bei einem darauffolgenden Aufruf muss die Seite dann nicht mehr neu generiert werden, sondern kann direkt aus dem Cache geladen werden.

Der JIT-Compiler ist dabei besonders schnell, da er den erzeugten Code an die Maschinensprache des Rechners anpassen kann, auf dem der Code laufen soll. Somit ist klar, dass ASP.NET viel schneller ist, als das alte interpretierte ASP.

Bei Java gibt es übrigens beide Varianten. Der vom Java-Compiler erzeugte Bytecode wurde ursprünglich von der JVM interpretiert. Bald gab es aber auch JVMs mit JIT-Compiler. Microsoft behauptet, dass .NET um einiges schneller ist als Suns J2EE. Bei einem Vergleichstest schien das auch bestätigt zu werden, allerdings stellte sich dann heraus, dass die .NET Version der Implementierung sehr stark optimiert wurde. Die Java Implementierung war hingegen weniger optimiert. Der Test wird daher nochmals wiederholt, unter Miteinbeziehung der Java-Anhänger [Heise News 2002a]. Java hat sich schon bewährt. Microsofts .NET muss sich in der Praxis erst bewähren. Momentan scheint es aber so, als hätte Microsoft das etwas bessere Produkt. Allerdings ist man mit Microsoft auf eine Plattform beschränkt.

PHP: Hypertext Preprocessor

Hinter PHP (PHP: Hypertext Preprozessor) steht keine so potente Firma wie Microsoft oder Sun. PHP ist Open Source und ein Produkt der Apache Software Foundation. PHP läuft bevorzugt als Modul des Apache Webserver auf verschiedenen Plattformen (Linux, Unix, Windows, Mac OS X), aber auch auf Microsofts IIS und anderen Webservern. PHP ist eine C-, Perl- und Java-ähnliche Sprache, die speziell für die Generierung von dynamischen Webseiten entwickelt wurde. Dabei kann der Code, wie bei JSP und ASP zwischen den HTML-Elementen in die Seite integriert werden. Vor allem, wenn man schon mit dem C-, Perl- oder Java-ähnlichen Syntax vertraut ist, kann man PHP sehr leicht erlernen.

PHP bietet umfangreiche Funktionen, die das Erstellen von dynamischen Webseiten erleichtert. Beispielsweise umfangreiche Stringmanipulationsfunktionen, inklusive den regulären Ausdrücken von Perl. Mit regulären Ausdrücken (Englisch: Regular Expressions) können komplizierteste Stringvergleiche und -ersetzungen mit einer Zeile Code durchgeführt werden. PHP bietet auch Funktionen zum Zugriff auf viele verschiedene Datenbanken. Eine Übersicht findet man unter [PHP.net 2002a]. Weiters gibt es eine Sessionverwaltung, Funktionen zur TCP-Socketprogrammierung, für FTP-Transfer, für Zugriff auf E-Mail-Server, zur Erstellung und Bearbeitung von Grafiken und vieles mehr. Natürlich können auch von PHP aus XML Daten sowohl mit SAX als auch mit DOM bearbeitet werden.

PHP wird oft gemeinsam mit Linux, Apache und MySQL eingesetzt. In diesem Zusammenhang spricht man von einem LAMP-System. "LAMP" steht dabei für: Linux, Apache, MySQL und PHP. LAMP ist ein komplettes Open Source System zur Erstellung von Datenbank-gestützten, dynamischen Webseiten bzw. von Webapplikationen. Bis jetzt war der größte Nachteil dabei, dass MySQL keine Transaktionen unterstützt. Die neuen Versionen, insbesondere aber die kommende 4.x Versionen haben hier gegenüber den kommerziellen Datenbanken beträchtlich aufgeholt.

Interessant ist das System vor allem dann, wenn man keinen eigenen Webserver im Haus hat, sondern man entweder Webspace oder einen kompletten dedizierten Server bei einem Provider gemietet hat. Die Mietpreise für solche LAMP-Systeme mit ausreichend Datentransferrate sind mittlerweile äußerst gering. Es gibt auch bereits in Europa genügend Anbieter solcher Konfigurationen. Der Vorteil liegt an der großen Anzahl an verfügbaren Werkzeuge zur Fernwartung dieser Systeme.

Ab PHP Version 4 (PHP4) wird - wie auch bei Microsofts .NET - ein JIT Compiler eingesetzt. Vor der Ausführung wird der PHP-Code also kompiliert. Die Firma Zend, die von den Programmierern von PHP3 und PHP4 gegründet wurde, bietet auch kommerzielle Produkte rund um PHP an. Eines davon, die Zend Performance Suite, bietet einen Seiten-Cache, sodass bereits generierte Seiten nicht mehr neu generiert werden müssen, und einen Programm-Cache, sodass bereits kompilierte PHP-Programme nicht bei jedem Aufruf neu geparsed und kompiliert werden müssen [Zend Performance Suite 2002]. Dadurch steigt die Geschwindigkeit nochmals beträchtlich.

PHP selbst und Dokumentationen in mehreren Sprachen findet man unter [PHP.net 2002]. Weitere Ressourcen sind [PHP Center 2002] und [Zend 2002].

19"Tier" ließe sich hier am besten mit "Ebene" übersetzen.

20Siehe www.google.com/press/highlights.html und www.heise.de/newsticker/data/hps-18.04.03-003/.

21Processing Instructions sind eigene Elemente, die Anweisungen für XML-Werkzeuge enthalten, die das Dokument verarbeiten sollen.

22Zumindest bei aktuellen Produkten ist das nicht der Fall.

23Verknüpfungen von mehreren Tabellen werden als "Joins" bezeichnet

24Diese Programme werden häufig mit so genannten "Script-Sprachen" erstellt. Die Programme selbst werden daher meist als "Scripts" bezeichnet. Die Bezeichnung "Script-Sprache" kommt daher, da die Programme (zumindest früher) nicht kompiliert, sondern interpretiert wurden. D.h., dass erst bei der Ausführung des Programms der Quellcode Zeile für Zeile gelesen, in Maschinencode übersetzt und schließlich ausgeführt wird. Mittlerweile werden aber immer öfters so genannte "Just in Time Compiler" (JIT) eingesetzt. Dabei wird der gesamte Quelltext unmittelbar vor der Ausführung übersetzt. Erst danach wird er ausgeführt. Es gibt auch Mischformen, wo jeweils Blöcke des Quelltexts (etwa einzelne Funktionen) übersetzt und anschließend ausgeführt werden. Neuerdings wird der übersetzte Maschinencode auch zwischengespeichert, wodurch bei der nächsten Ausführung ein neuerliches Kompilieren nicht notwendig ist - vorausgesetzt, der Quelltext wurde nicht geändert.

25Es gibt Bestrebungen .NET auch auf andere Plattformen zu portieren. Microsoft strebt das selbst für portable Geräte wie Handhelds an. Für Linux oder ähnliche Betriebssysteme müsste das aber sicher von anderer Seite passieren.