Dienstbare Geister
Das World Wide Web steckt voller Dynamik. Dabei interessiert es den Surfer nicht, wie die Seiten generiert werden. Der Webautor dagegen muss sich entscheiden, ob er mit einfachem CGI, Perl, PHP, ASP oder Java arbeiten will.
- Christian Plessl
- Erik Wilde
Nachdem das Web seinen Anfang als verteiltes Hypertext-System genommen hat, ist schon seit langem der Trend offensichtlich, es als Plattform zur Applikationsentwicklung zu nutzen. Die eigentlichen Hypertext-Aspekte treten (bedauerlicherweise) immer mehr in den Hintergrund, und einer der wichtigsten Aspekte von Webtechniken ist heute ihre Integrationsfähigkeit in bestehende IT-Lösungen und -Infrastrukturen. Dieser Artikel stellt die populärsten Ansätze zur Anbindung von Applikationen an Webserver vor.
Immer mehr verdrängen dynamische Webinhalte die statischen Dokumente. Die beiden Hauptgründe dafür sind die Reaktion auf sich verändernde Inhalte sowie auf unterschiedliche Anforderungen seitens der Inhaltskonsumenten, sei es aufgrund von Benutzerprofilen oder browserspezifischen Anpassungen.
Die einfachste und älteste Möglichkeit, dynamische Webseiten zu generieren, bietet das Common Gateway Interface (CGI). CGI ist eine standardisierte Schnittstelle dafür, wie Webserver und externe Programme, die dynamische Inhalte generieren, miteinander kommunizieren. Der Vorteil dieser Lösung ist die komplette Unabhängigkeit von der Programmiersprache, denn jede Sprache, die Zugriff auf die Umgebungsvariablen des Systems bietet und das Lesen von der Standardeingabe sowie das Schreiben auf die Standardausgabe unterstützt, ist für CGI geeignet. Zudem unterstützen alle Webserver CGI.
Für eine schnelle und komfortable Programmentwicklung setzten Webmaster anfangs vor allem Script-Sprachen ein, die bereits zur Automatisierung von Systemadministrationsaufgaben unter Unix verwendet wurden, beispielsweise Shell-Scripts, Perl oder Tcl. Da Webseiten jedoch typischerweise sowohl aus dynamischen, als auch zu einem großen Teil aus statischen Inhalten bestehen, hat die Verwendung von CGI-Scripts zur dynamischen Seitengenerierung einen inhärenten Nachteil: Das Script muss jeweils den ganzen HTML-Quellcode ausgeben, unabhängig davon, ob dieser dynamisch ist oder nicht. Eine elegantere Lösung wäre die Integration der Scripts in den HTML-Quellcode, sodass die dynamischen Elemente in den statischen HTML-Quellcode eingebettet werden und eine Interpretation auf dem Webserver auslösen, bevor er die Seite an den Browser sendet.
Online-Quellen
http://wildesweb.com/topicmap/
http://www.serverpages.com/index.html
CGI-Classic:
http://hoohoo.ncsa.uiuc.edu/cgi/
CCI-Classic mit Perl:
http://www.heise.de/ix/online/perl.html
CGI mit eingebettetem Perl:
http://www.engelschall.com/sw/eperl/
http://perl.apache.org/embperl/index.html
FastCGI:
PHP:
http://www.heise.de/ix/raven/Web/php/
Active Server Pages (ASP):
Servlets und Java Server Pages (JSP):
Verschiedene konkurrierende Ansätze basieren auf der direkten Einbettung des ausführbaren Script-Codes in HTML. Beispiele sind Microsofts Active Server Pages (ASP), PHP, Embperl oder Java Server Pages (JSP), wobei jeder Ansatz seine spezifischen Stärken und Schwächen hat.
Diverse Websites widmen sich dem Thema Server Side Scripting und bieten neben Informationen über die verwendeten Sprachen auch fertige Beispiele an (siehe ‘Online-Quellen’).
CGI-Classic
CGI verdankt seine große Popularität dem einfachen Interface und der praktisch lückenlosen Unterstützung seitens der Webserver. Der Zugriff auf dynamisch generierte Inhalte erfolgt für den Benutzer transparent, das heißt, den dynamisch generierten Inhalt referenziert wie üblich eine URL, die sich nach außen nicht von einem Verweis auf statischen Inhalt unterscheidet. Der Begriff ‘Inhalt’ sei hier speziell betont, denn obwohl CGI-Scripts meistens HTML generieren, sind auch beliebige andere Inhalte möglich und werden zum Beispiel im Falle dynamischer Grafikgenerierung - wie bei Zugriffszählern - auch häufig verwendet. Bei CGI-Scripts spielen FORM-Elemente in HTML-Seiten oft eine wichtige Rolle. Sie erlauben es, einen Satz von Eingabedaten an das Script zu übermitteln.
Der Abruf einer mittels CGI-Script generierten Webseite funktioniert wie folgt: Der Webserver erhält eine für das CGI-Script bestimmte Anfrage und startet darauf das CGI-Script als separaten Prozess. Den Namen des auszuführenden Scripts entnimmt der Webserver dem HTTP-Request. Den Request des Browsers, zusätzliche HTTP-Header sowie weitere serverabhängige Variablen übergibt er dem CGI-Script über dessen Standardeingabe und Umgebungsvariablen. Via Webserver kommuniziert das Script mit dem Browser, indem es die für den Browser bestimmten Ausgaben auf die Standardausgabe schreibt. Das Terminieren des Scripts schließt den Response ab.
Sicherlich liegt der große Vorteil von CGI in der Einfachheit des Mechanismus und in der Generalität des Ansatzes. Das einfache Interface ist jedoch gleichzeitig die Schwäche von CGI. Viele Konzepte, die für größere Webapplikationen, etwa im E-Commerce Umfeld, nötig sind, fehlen - beispielsweise die Unterstützung von Sessions. Zudem ist die Erstellung von einem eigenen Prozess pro Request zwar eine einfach zu implementierende, jedoch keine besonders performante Lösung.
CGI-Classic mit Perl
Seit Beginn des Einsatzes von CGI-Scripts werden CGI und Perl oft in einem Atemzug genannt, obwohl beide keinen direkten Zusammenhang haben. Perl ist eine objektorientierte Programmiersprache, die auf den ersten Blick an Shell-Scripts oder C-Programme erinnert. Doch sie ist weit mehr: Entstanden als Practical Extraction and Report Language (PERL), eine Art integrierte Sprache für die Unix-Tools sed, awk und grep, hat sich Perl zu einer voll ausgereiften Programmiersprache entwickelt, die auf große Beliebtheit stößt, nicht zuletzt, weil sie als Open-Source-Projekt jedem kostenlos unter der ‘Artistic License’ zur Verfügung steht. Zudem gibt es Portierungen für nahezu jede Plattform.
Perl zeichnet sich durch leistungsfähige Funktionen zur Textmanipulation aus, wie Suchen und Ersetzen oder die Unterstützung von Regular Expressions, was in CGI-Scripts von großem Nutzen ist. Gilt es, in einer Anwendung - wie dies bei CGI-Scripts üblich ist - andere Programme aufzurufen, deren Ausgaben zu interpretieren und neu zu formatieren, dann ist Perl sicher die erste Wahl. Ein weiterer Vorzug liegt in der ausdrucksstarken Syntax und den leistungsfähigen Befehlen, die es erlauben, kurze Programme mit großem Funktionsspektrum zu schreiben. Perls Fähigkeiten lassen sich durch in Perl oder C geschriebene Module erweitern. Über die Jahre ist eine unüberblickbare Vielzahl von Perl-Modulen entstanden, die ein zentrales Repository, genannt CPAN (Comprehensive Perl Archive Network), verwaltet.
Für Webapplikationen gibt es auf diverse Anwendungsszenarien zugeschnittene Module, zum Beispiel Datenbankzugriff, LDAP, Mail, SMTP oder dynamische Grafikgenerierung. Beim CGI-Einsatz erfreut sich das Modul CGI.pm grosser Beliebtheit. Es erleichtert die Erstellung von CGI-Scripts erheblich durch den einfachen Zugriff auf HTML-Formular-Variablen, HTTP-Header, die automatische Konversion von URL-kodierten Strings und die Unterstützung von Cookies. Zudem gibt es Perl-Wrapper für diverse HTML-Konstrukte, um die dynamische HTML-Generierung zu erleichtern.
Zweifelsohne ist Perl eine leistungsfähige und interessante Programmiersprache für Webanwendungen. Da sie jedoch meist nicht in den Webserver integriert ist, sondern jeweils als eigener Prozess gestartet wird, bringt dies die bekannten Nachteile von klassischen CGI-Scripts mit sich, das heißt den Overhead, verursacht durch das Erzeugen eines neuen Prozesses und die fehlende Trennung zwischen dynamischem und statischem Inhalt.
CGI mit eingebettetem Perl
Mehrere Projekte streben hierfür eine Lösung an, die allerdings jeweils auf einen spezifischen Webserver ausgerichtet sind. Dieser Artikel konzentriert sich auf den weitverbreiteten Apache-Server. Allen Ansätzen gemeinsam ist, dass sie als Erweiterungsmodul zu Apache implementiert sind, stellvertretend seien hier Apache::ePerl und Apache::embperl genannt. Apache ist als Plattform für die Perl-Unterstützung speziell geeignet, da das populäre mod-perl einen Zugriff von Perl auf die Apache-API und somit die Erweiterung der Apache-Funktionen mittels Perl erlaubt. Dazu wird der Perl-Interpreter direkt in Apache integriert.
Beide Ansätze ermöglichen die Einbettung von Perl-Code in den HTML-Quelltext und bieten ähnliche Funktionen. Die Benutzung von ePerl ist einfach, die auszuführenden Perl-Scripts werden über konfigurierbare Tags, standardmässig <? ... perlcode(); ... !>, in HTML integriert. ePerl geht jedoch nicht über diese Kernfunktion hinaus und stellt außer den Start- und Endtags für den Perl-Code und die daraus resultierende Einbettung der Resultate in die erzeugte Seite keine weiteren Befehle bereit, das heißt, ePerl ist allgemein gehalten und nicht speziell auf HTML ausgelegt. Embperl dagegen geht einen Schritt weiter und bietet zusätzliche Pseudo-HTML-Kommandos, die das Arbeiten mit HTML-Konstrukten erleichtern.
FastCGI
Bei FastCGI handelt es sich nicht um eine spezielle Programmiersprache, sondern um eine nahe liegende Erweiterung des gewöhnlichen CGI-Mechanismus. Es behält die Vorteile des ursprünglichen Interfaces bei wie Einfachheit, Sprachunabhängigkeit, die Trennung von Webserver und CGI-Prozess sowie die offene Spezifikation, versucht aber die Performance der Scripts mittels einiger Modifikationen zu verbessern. Diese basieren auf der berechtigten Annahme, dass das Erzeugen eines neuen Prozesses auf dem Webserver ressourcenintensiv ist.
Im Fall von FastCGI gelten dieselben Mechanismen wie beim klassischen CGI mit zwei wesentlichen Änderungen:
- Das CGI-Script terminiert nach dem Abarbeiten eines Request nicht, sondern wartet auf das Eintreffen einer neuen Anfrage.
- Die Parameter übergibt der Webserver nicht über Umgebungsvariablen, sondern über eine bidirektionale TCP-Verbindung oder eine Pipe.
Der Ablauf bei Verwendung von FastCGI ist demnach wie folgt:
- Das FastCGI-Script wird beim Start des Webservers oder beim ersten Aufruf gestartet und initialisiert. Danach wartet es auf einen eingehenden Request vom Webserver.
- Der Webserver schickt die Daten vom Browser über eine bidirektionale Verbindung (TCP oder Pipe) zum FastCGI-Prozess.
- Der FastCGI-Prozess schickt seine Ausgabe über die Verbindung zurück zum Webserver und schliesst die Verbindung, wenn der Request abgehandelt wurde. Danach wartet das FastCGI-Script wieder auf eine eingehende Anfrage vom Webserver.
Der Hauptvorteil von FastCGI liegt darin, das kostspielige Erzeugen eines neuen Prozesses zu umgehen. Durch die Kommunikation über TCP können die Prozesse zudem auf verschiedenen Servern laufen, was zum Beispiel Load Balancing ermöglicht. Dank der starken Anlehnung an das klassische CGI lässt sich ein bestehendes CGI-Script leicht zu einem FastCGI-Script erweitern.
Derart einfach funktioniert der Mechanismus jedoch nur für single-threaded Scripts, das heißt, wenn sie jeweils nur eine Anfrage gleichzeitig behandeln. Bei der parallelen Verarbeitung mehrerer Requests können je nach Anwendung Mechanismen zur Synchronisation oder zum gegenseitigen Ausschluss notwendig sein.
PHP: Hypertext Preprocessor
PHP ist eine speziell auf Webapplikationen ausgerichtete Script-Sprache. Syntaktisch macht sie starke Anleihen bei Perl und C, was Umsteigern die Einarbeitung erleichtert. Sie ist Open Source, liegt in der GPL-Lizenz vor und lässt sich als Modul in Apache integrieren, was Vorteile hinsichtlich der Performance bringt.
Von Anfang an speziell für das Server Side Scripting für Webapplikationen entworfen, vereint PHP Elemente von Perl und diversen Bibliotheken für netzbasierte Dienste. Während die meisten anderen Sprachen auf externe Module oder Libraries zurückgreifen, werden diese in PHP direkt integriert.
Üblicherweise sind PHP-Programme in den statischen HTML-Quellcode eingebettet und können mit den Tags <?php ... ?> oder mit
<script type="text/php">
echo ("You can put your PHP code here.");
</script>
aktiviert werden. Dabei ist die zweite Variante an die Syntax von eingebetteten Client Side Scripts wie JavaScript angelehnt.
Unter PHP stehen die üblichen Konstrukte aus C zur Verfügung: for(), if(), while() und so weiter. Einen Teil der Syntax borgt sich PHP von Perl. Zusätzlich zu ein- und mehrdimensionalen Arrays stehen assoziative Arrays - auch als Hash-Tabellen bekannt - sowie Perl-kompatible Regular Expressions zur Verfügung. Zudem finden sich einfache objektorientierte Ansätze (stark erweitert in PHP4).
Die wahre Stärke dieser Script-Sprache liegt aber in der Integration von spezifischen Funktionen, wie sie üblicherweise für die dynamische Generierung von Webseiten benutzt werden. Dazu gehören unter anderem die Generierung von GIF-Grafiken sowie die dynamische Erstellung von PDF-Dokumenten.
Natürlich stellt PHP auch Methoden zur Behandlung von HTTP-Headern, zur Verwaltung von Benutzer-Sessions und zum Kodieren beziehungsweise Dekodieren von URL-encoded Strings bereit.
Durch die komfortable Anbindung an diverse Datenbanken wie Oracle, MySQL, Microsoft SQL Server, Postgres oder über die ODBC-Schnittstelle (Open Database Connectivity) eignet sich die Sprache ideal für datenbankgenerierte Webseiten. Ein weiterer Vorzug sind die Schnittstellen zu verschiedenen, netzwerkbasierten Diensten, wie sie für typische Webapplikationen häufig verwendet werden, zum Beispiel POP, IMAP, SMTP oder LDAP. Die Integration eines XML-Parsers ermöglicht die Erstellung von XML-fähigen Applikationen, die zur Zeit zunehmend an Bedeutung gewinnen.
Gegenüber Perl zeichnet sich PHP vor allem darin aus, dass die wesentlichen für typische Webapplikationen benötigten Funktionen direkt integriert sind und nicht als externe Module dazugeladen werden müssen. Obwohl die Sprache stark an Perl angelehnt ist, stellt sie nur eine Untermenge von deren Möglichkeiten zur Verfügung. Trotzdem eignet sie sich auch für größere Applikationen, was man an ihrer weiten Verbreitung erkennt - auch in komplexeren Anwendungen. Hier sei nochmals explizit auf die neue Release PHP4 verwiesen, die viele der bekannten Schwachstellen der Version 3 beseitigt. Beispielsweise gibt es jetzt eine integrierte Session-Unterstützung.
ASP: Microsoft Active Server Pages
Microsofts Lösung zum Server Side Scripting heißt ASP. Die Unterstützung für Active Server Pages ist direkt im Microsoft Internet Information Server (IIS ab Version 3) und in den Personal-Webservern von Windows 95 beziehungsweise NT integriert und deshalb einfach benutzbar.
Als Programmiersprache für ASP dienen wahlweise JScript (Microsofts Implementierung von ECMAScript), VBScript (Visual Basic Script) oder eine beliebige andere Script-Sprache. Die Verwendung von JScript vereinfacht dem Entwickler die Einarbeitung, da dieselbe Sprache bereits zum Client Side Scripting in HTML zum Einsatz kommt. Der Funktionsumfang von JScript ist jedoch relativ gering gehalten, die Sprache eignet sich nur beschränkt für größere Webanwendungen. ASP-Scripts lassen sich über die Markierung mit den Tags <% ...script.... %> an beliebiger Stelle direkt in HTML einbetten. Im Gegensatz zu gewöhnlichen JScript-Scripts im HTML-Source, die der Browser interpretiert, führt der Webserver den Code von ASP-Scripts direkt aus.
ASP basiert auf einem ‘Objektmodell’, das heißt, die eigentliche Stärke von ASP liegt nicht in den Fähigkeiten der verwendeten Script-Sprache, sondern im Einsatz von Softwarekomponenten (COM-Komponenten), mit denen der Webprogrammierer komplexere Funktionen im Baukastenprinzip zusammensetzen kann. Prinzipiell hat er auch die Möglichkeit, eigene Scripting-fähige COM-Komponenten zu schreiben und in seinen ASP-Scripts zu nutzen. Typischerweise wird er aber eher auf ein Repertoire vorgefertigter Komponenten von Microsoft oder anderen Anbietern zurückgreifen. Einige Objekte sind bereits fest eingebaut. Diese erlauben klassische CGI-Funktionen, zum Beispiel Verarbeitung von HTML-Formularen, Verwaltung von Cookies und Generieren von Antwortseiten. Zudem stehen weiter gehende Funktionen zur Session-Verwaltung zur Verfügung.
In einer Microsoft-Umgebung bietet sich die Verwendung von ASP an, da sich viele MS-Produkte durch mitgelieferte Komponenten gut integrieren lassen und der Webserver beispielsweise auf diese Weise Excel-Tabellen einfach darstellen kann. Zur Anbindung von Datenbanken dient eine ODBC-Komponente.
Server Side Java: Servlets und JSP
Nachdem der ganze Marketing Hype um Java etwas abgeklungen ist, stellt sich die Frage, ob diese Programmiersprache auch für den Server-Side-Einsatz geeignet ist. Dies bietet sich durch die umfangreichen mitgelieferten Klassenbibliotheken geradezu an. Besondere Vorzüge sind die hervorragende Netzwerkfähigkeit, die Unterstützung verteilter Applikationen durch Java RMI (Remote Method Invocation) oder CORBA (Common Object Request Broker Architecture) und die komfortable Datenbankanbindung via JDBC (Java Database Connectivity). Durch die grosse Popularität von Java gibt es inzwischen eine Vielzahl von Bibliotheken für verschiedene Anwendungsszenarien. Natürlich wäre auch Java als Programmiersprache für gewöhnliche CGI-Scripts einsetzbar, doch in der Praxis ist dies kaum eine gangbare Lösung. Die größte Hürde stellt die Java Virtual Machine (JVM) dar, die als Interpreter für Java-Programme nötig ist. Die großen Speicheranforderungen der JVM belasten den Webserver stark, da bei der Verwendung von CGI jeweils eine JVM pro Request startet. Wie bei anderen Server-Side-Techniken liegt die Integration einer JVM in den Webserver nahe (vergleichbar der Verwendung persistenter Programme bei FastCGI). Genau diesen Weg gehen Servlets und Java Server Pages (JSP).
Servlets sind durch Suns Java-Servlet-API standardisiert und (analog zu Applets) nichts anderes als Klassen, die ein spezifisches Interface (javax.servlet.Servlet) implementieren. Das Servlet wird kompiliert und beim ersten Aufruf auf dem Server gestartet. Ab diesem Zeitpunkt wartet das Programm auf einen eingehenden Request, behandelt diesen, generiert die gewünschten Ausgaben und wartet dann auf das Eintreffen eines neuen Request. Genauso wie beim FastCGI-Ansatz umgeht man auf diese Weise das zeitaufwendige Erzeugen eines neuen Prozesses. Zur Vereinfachung der Programmierung von Webapplikationen bietet die Servlet-API komfortable Funktionen zur Unterstützung von Cookies und damit zur Session-Verwaltung. So lassen sich einer Benutzer-Session auf einfache Art beliebige Java-Objekte auf dem Server zuordnen.
Java-Servlets generieren jeweils eine gesamte HTML-Seite als Antwort, das Einfügen der Ausgabe des Servlet in eine ansonsten statische HTML-Seite ist außer über proprietäre Erweiterungen der Serverhersteller nicht machbar. Zur Einbettung von Java-Programmen in HTML-Seiten bieten sich die ebenfalls von SUN spezifizierten Java Server Pages (JSP) an. Damit ist es ähnlich wie bei ASP oder PHP möglich, Java Code direkt in die HTML-Seite einzubetten. Die Einbindung des Codes erfolgt über die Tags <%! my_java_code_here(); %> oder über die XML-konformen Tags
<jsp:declaration>
<![CDATA[
my_java_code_here();
]]>
</jsp:declaration>
Innerhalb der Applikation kann der Benutzer ebenfalls auf die Servlet-API zurückgreifen.
Zur Ausführung von Java-Servlets oder Java Server Pages wird ein dafür geeigneter Webserver benötigt, der diese Unterstützung direkt integriert hat. Für einige Webserver stehen zudem freie und kommerzielle Plugins zur Verfügung, die diese Funktionen nachrüsten. Interessant für größere Applikationen ist die Möglichkeit, auf dem Server modulare, komponentenorientierte Software, so genannte Enterprise JavaBeans (EJB), einzusetzen.
Die bei Java-Anwendungen immer wieder aufflammende Diskussion um die Performance des interpretierten Bytecodes stellt sich natürlich auch bei Servlets und JSP. Hierzu ist anzumerken, dass der Hauptvorteil von Java beim Server Side Scripting in den umfangreichen zur Verfügung stehenden Klassenbibliotheken liegt und nicht unbedingt in der Performance der resultierenden Anwendung, die vor allem durch die verwendete JVM bestimmt wird. Berücksichtigt man jedoch, dass PHP- oder Perl-Programme ebenfalls interpretiert ausgeführt werden, relativieren sich diese Bedenken ein wenig.
Abschließende Betrachtungen
Welche der Lösungen die geeignetste für die Erstellung von Webapplikationen ist, hängt stark von der Ausgangssituation und der Art der Zielanwendung ab. Obwohl die hier vorgestellten Sprachen hinsichtlich der einfacheren Funktionen große Gemeinsamkeiten aufweisen, unterscheiden sie sich grundlegend in ihrer Eignung für anspruchsvolle Webapplikationen. Für weniger komplexe Programme ist zumeist ein einfacher Zugriff auf die über HTML-Formulare übertragenen Parameter interessant. Da dynamische Inhalte meist durch Abfrage einer externen Datenquelle (oft eine Datenbank) generiert werden, sind einfache Anbindungen der Script-Sprache an diese Datenquellen wünschenswert. Besonders häufig wird der Wunsch nach eine Anbindung an Datenbanken, LDAP-Adressverzeichnisse oder E-Mail laut. Diese Funktionen können entweder in der Sprache selbst integriert sein (wie bei PHP), oder Zusatzmodule bieten sie (Perl, ASP, Servlets).
Größere Applikationen, vornehmlich im E-Commerce-Bereich, führen den Benutzer über mehrere Webseiten, auf denen er zum Beispiel verschiedene Artikel aussuchen sowie in seinen Warenkorb legen und schließlich eine Bestellung abschicken kann. Dazu ist dem Benutzer eine so genannte Session zugeordnet, das heißt, der Webserver speichert alle Aktionen des Benutzers zwischen. Üblicherweise geschieht die Identifikation eines Benutzers zur Verfolgung einer Session über Cookies oder über URL-Rewriting. Die zur Session gehörigen Daten speichert der Webserver dazu temporär in einer Datenbank. Bei komplexeren Applikationen ist es wünschenswert, den Programmierer von der Aufgabe des expliziten Sicherns und Wiederherstellen der Session-Daten zu entbinden und ihm die Illusion von persistenten Daten innerhalb einer Session zu geben. Im Weiteren sind Funktionen erwünscht, welche die Existenz mehrerer paralleler Sessions verbergen, sodass der Programmierer die Applikation so erstellen kann, als wäre nur jeweils ein einziger Client aktiv. Hier unterscheiden sich die einzelnen Server-Side-Techniken deutlich. Während bei CGI mit Perl oder PHP3 diese Funktionen nur mit größerem Aufwand erreichbar sind, bringen PHP4, ASP und Servlets diese Fähigkeiten von Haus aus mit. Vor allem PHP4 und Servlets bieten in dieser Hinsicht leistungsfähige Funktionen.
Wie bei allen größeren Softwareprojekten ist bei der Erstellung von Webapplikationen ein modularer, komponentenorientierter Aufbau interessant. Dieser eröffnet zudem die Möglichkeit, käufliche Komponenten in eigenen Applikationen zu verwenden. Java bietet über JavaBeans standardmäßig komponentenorientierte Möglichkeiten. Speziell für das Webumfeld hat Sun die Enterprise JavaBeans entwickelt, die komponentenbasierte, plattformunabhängige Multi-Tier-Applikationen ermöglichen, und die Benutzerschnittstelle klar von den darunterliegenden Diensten trennen. Microsoft geht mit der Unterstützung von COM-Objekten durch ASP einen ähnlichen Weg. Dort ist der komponentenorientierte Ansatz das A und O, da die verwendeten Script-Sprachen JScript und VBScript in ihrer Mächtigkeit bei weitem nicht mit Java vergleichbar sind. Ausgefeiltere Funktionen in ASP-Scripts realisieren COM-Objekte, die das Script lediglich noch geeignet konfiguriert.
Aus Sicherheits- und Performance-Gründen benutzen die meisten Unternehmen einen dedizierten Webserver, der keine weiteren Dienste anbietet. Deshalb werden oft auch verteilte Webapplikationen benötigt. Von den vorgestellten Techniken bietet nur Java mittels RMI und CORBA integrierte Möglichkeiten zur einfachen Erstellung verteilter, heterogener Anwendungen.
Fazit
Die vorgestellten Server-Side-Techniken stellen weder eine komplette Liste an verfügbaren Lösungen dar, noch kann der Artikel eine abschließende Bewertung leisten, die sie in einer eindeutigen Reihenfolge anordnet. Anliegen ist es vielmehr, einen Überblick über die derzeit verbreitetsten Ansätze zu geben und damit bei der Frage als Entscheidungshilfe zu dienen, welche Technik für eine spezifische Aufgabenstellung am geeignetsten ist. Um eine dem Einzelfall angepasste Untersuchung kommt man jedoch nicht herum, und wie in vielen anderen Bereichen des Webs bietet sich das Vorgehen an, nicht bei Null anzufangen, sondern gründlich zu schauen, wo das gegebene Problem so oder in ähnlicher Form schon aufgetaucht ist, und was man aus den dort gewählten Lösungen lernen kann.
Christian Plessl
ist Diplomand am Institut für Technische Informatik an der ETH Zürich und arbeitet dort auf dem Gebiet Reconfigurable Computing.
Erik Wilde
arbeitet an der ETH Zürich und als selbstständiger Berater. Er forscht und arbeitet in den Bereichen XML sowie Webtechniken, insbesondere Hypermedia für XML und Linkdatenbanken.
Literatur
[1] Stefan Mintert, Rainald Menge; XML verpuppt; Aufbereitung mit Cocoon und Extensible Server Pages; c’t 10/2000, S. 222 ff.
[2] Lars Röwekamp, Peter Roßbach; JSP-Tutorial, Teil 1, Teil 2, Teil 3
[3] Tobias Ratschiller; Brennpunkt WWW; Maßgeschneidert für das Web: PHP 4.0
iX-TRACT
- Schon als das Web noch in den Kinderschuhen steckte, bot das Common Gateway Interface (CGI) eine standardisierte Schnittstelle für dynamisch generierte HTML-Seiten.
- CGI ist einfach zu benutzen, hat jedoch Nachteile - schlechte Performance, fehlende Session-Unterstützung -, die es für größere Webapplikationen im kommerziellen Umfeld ungeeignet machen.
- Diverse Lösungen wie embedded Perl, PHP, Active Server Pages, Servlets oder Java Server Pages versuchen auf unterschiedliche Weise, die Schwächen der klassischen CGI-Programmierung auszugleichen.
- Welche Technik die geeignetste ist, hängt sowohl von der Anwendung als auch von der Systemumgebung ab. Eine allgemeingültige Empfehlung lässt sich nicht geben.
| Server-Side-Techniken im Vergleich | |||||
| Classic CGI mit Perl | Embedded Perl | PHP | ASP | JSP, Servlets | |
| Session-Unterstützung | -- | -- | ±(PHP4: ++) | + | ++ |
| Datenbankzugriff | Modul | Modul | integriert | ODBC-Komponente | JDBC |
| Textprocessing-Funktionen | ++ | ++ | + | - | - |
| Integration von Scripts in HTML | - | + | + | + | - |
| Verbreitung | ++ | ± | ++ | ++ | ± |
