Zurück: Sprachen im Webauthoring
Weiter: Web-Browser

Webapplikationen

Diese Einführung befasst sich mit den Grundlagen des Webauthorings, also der Textauszeichnung in XHTML und dem Styling in CSS. Nicht näher behandelt werden server- und clientseitige Programmier- oder Skriptsprachen. Dennoch möchte ich Ihnen einen kleinen Überblick über weitere Möglichkeiten verschaffen und Ihnen Techniken der Webseitenerstellung vorstellen, die für Sie interessant sein könnten. Eine große Anzahl von Links führt Sie zu Quellen, wo Sie sich weiter informieren können.

Der gesamte Abschnitt »Webapplikationen« wurde von Jens Becker verfasst.

Einleitung

Die Kenntnis von XHTML und CSS ermöglicht es, Webseiten zu gestalten. Diese Webseiten sind jedoch statisch in der Art, dass sie bewegungslos sind und Interaktion nur sehr begrenzt erlauben.

Wie das Anzeigen eines XHTML-Dokumentes abläuft

Wenn Sie sich mit Ihrem Webbrowser eine Webseite ansehen, passiert in den meisten Fällen folgendes:

  1. Sie geben einen URL in die Adressleiste Ihres Browsers ein, zum Beispiel http://example.com/dokument.html. Der Webbrowser versucht, den Namen aufzulösen: er prüft an verschiedenen Stellen (erst auf Ihrem Rechner, dann bei so genannten DNS-Servern, d.h. Domain Name System-Servern), ob für den von Ihnen eingegebenen URL eine IP-Adresse existiert.
    • Ein Rechner hat in einem Netzwerk eine eindeutige IP-Adresse der Form x.x.x.x, wobei x jeweils zwischen 0 und 255 liegen darf. Verschiedene Adressbereiche sind für spezielle Zwecke reserviert, beispielsweise 192.168.*.* für private Netzwerke.
      Man kann eine Website übrigens auch aufrufen, indem man die IP-Adresse statt der Domain in den Browser eingibt. Aber wer kann sich schon Zifferncodes merken?
  2. Bei Gelingen nimmt der Browser Kontakt mit dem Zielrechner auf (die IP-Adresse bleibt dabei für den Benutzer unsichtbar). Dabei bedient sich der Browser des Protokolls HTTP, dem Hypertext Transfer Protocol. Dieses Protokoll definiert eine Sprache, mit der sich Rechner verständigen können.
     
  3. Auf dem Zielrechner muss eine Software installiert sein, die HTTP versteht, diese Anfrage entgegen nimmt und darauf entsprechend reagiert: der Webserver (manchmal nennt man die Software Webserver, manchmal die Hardware, manchmal die Verbindung von beidem). Der Webserver sucht nun nach der gewünschten Datei und schickt sie dem Browser.
     
  4. Der Browser empfängt die Datei. Wenn es sich um ein XHTML-Dokument handelt, liest es der Browser üblicherweise und stellt es so dar, wie er den Inhalt interpretiert.

Um die Fähigkeit reinen XHTMLs zu erweitern, kann man also an genau zwei Stellen ansetzen: am Browser und am Webserver. Beide Fälle verhalten sich analog: es gibt verschiedene Browser/Webserver mit verschiedenen Fähigkeiten und man kann Browsern/Webservern neue Fähigkeiten beibringen. Letzteres sind eben so genannte client- bzw. serverseitige Applikationen. Bei verschiedenen Anwendungsfällen muss man nun grundsätzlich überlegen, auf welcher Seite man ansetzen muss.

Clientseitig

Wenn man sich im Browser eine Animation statt eines statischen XHTML-Dokumentes ansehen möchte, dann ist dies Aufgabe des Browsers. Der Server liefert die Animations-Datei normal aus, der Browser muss aber fähig sein, diese auch als Animation anzuzeigen. Ein Beispiel dafür sind Flash-Dateien: Der Browser kann solch eine Flash-Animation nur dann anzeigen, wenn man ein so genanntes Plug-In installiert hat.

Bestimmt haben Sie auch schon einmal animierte Menüs auf Webseiten gesehen. Diese sind oft mit JavaScript erstellt, einer Skriptsprache (ähnlich einer Programmiersprache). Im XHTML-Dokument befindet sich dabei neben dem XHTML-Quellcode noch JavaScript (oder das Dokument enthält einen Verweis auf eine externe Javascript-Datei), welches der Browser interpretieren muss. Für JavaScript gibt es keine Plug-Ins, die verbreitetsten Webbrowser können JavaScript selbst interpretieren.

Serverseitig

Wenn Sie ein Kontaktformular oder ein Gästebuch auf Ihrer Webseite haben möchten, dann reichen die Fähigkeiten des Browsers nicht mehr aus. Die Gästebuch-Einträge müssen auf dem Server gespeichert werden, also ist hier der Webserver zuständig. Der Webserver muss wissen, was er mit den erhaltenen Daten anfangen soll, die Sie ihm mit Absenden eines Kontaktformulars oder Gästebuch-Eintrags geschickt haben.

Es gibt etliche Lösungen für solche Aufgabenstellungen. Prinzipiell wird auf dem Server ein Programm (eine Applikation) ausgeführt, wenn etwas gespeichert oder generiert werden soll. Es gibt Webserver, die »von Haus aus« eine oder mehrere Arten von Applikationen unterstützen. Vielen Webservern kann man zusätzliche Funktionen hinzufügen, analog zu den Browsern. Der Ablauf ist dabei im Grunde immer der selbe, unabhängig von der verwendeten Applikation. Dazu zwei Beispiele:

  1. Wenn Sie sich nun die schon vorhandenen Einträge in Ihrem Gästebuch ansehen, liest eine Applikation die Daten aus einer Datenbank oder Textdatei (wo die Einträge gespeichert sind) und generiert ein ganz normales XHTML-Dokument, das der Browser erhält und anzeigt.
  2. Jemand füllt auf Ihrer Webseite das Kontaktformular aus. Wenn er auf »Absenden« klickt, werden die Daten an eine Applikation übergeben, die nun aus den Daten beispielsweise eine E-Mail erstellt und diese an Sie schickt. Die Applikation generiert außerdem ein XHTML-Dokument, das dem Benutzer anzeigt, dass die Nachricht verschickt wurde.

Der verbreitetste Webserver weltweit ist der Apache Webserver der Apache Software Foundation. Der Name ist ein Synonym für a patchy webserver, das heißt einen Webserver, den man gut modular erweitern kann. So gibt es für viele Applikationsarten Erweiterungsmodule für den Apache. Fast alle großen Provider haben den Apache Webserver installiert. Darüber hinaus ist der Microsoft IIS Webserver (Internet Information Services), der Active Server Pages unterstützt und eine komfortablere Verwaltung bietet, sehr verbreitet.

Welche Art Applikation Sie benutzen sollten, hängt nun davon ab, welchen Webserver Sie zur Verfügung haben und welche Art von Anwendungen Sie entwickeln möchten. Die bekanntesten Arten werden weiter unten erläutert.

Einige Spezialfälle sollen nicht verschwiegen werden: es gibt Anwendungen, für die sowohl server- als auch clientseitig eine Applikation installiert sein muss. Das bekannteste Beispiel sind Chats. Der Server koordiniert den Chat, und auf dem Client muss ein Java Applet installiert sein, dass mit der serverseitigen Applikationen zusammenarbeitet (und die Anzeige sofort aktualisiert, wenn jemand im Chat eine Aktion ausgeführt hat). Java Applets sind spezielle clientseitige Java-Programme, die später noch genauer erläutert werden.

Jetzt wissen Sie prinzipiell, welche Möglichkeiten es gibt, um Webseiten dynamisch zu entwerfen. Im Folgenden werden nun technische Details und verschiedene Arten von Applikationen im Detail besprochen. Plug-Ins werden nicht weiter behandelt, lediglich Skript- bzw. Interpretersprachen.

Applikationstypen

Sie schreiben einen so genannten Quelltext in einer Programmiersprache. Dieser kann aber nicht ohne weiteres vom Betriebssystem ausgeführt werden, sondern muss in eine Form gebracht werden, die das Betriebsystem versteht. Dazu gibt es nun verschiedene Ansätze.

  1. Programmiersprachen C, C++, Pascal, Basic, Cobol, Fortran
    Dies ist der konventionelle Ansatz. Sie lassen Ihren Quelltext von einer Entwicklungssoftware kompilieren, das heißt Sie lassen durch einen Compiler eine ausführbare Binärdatei (Windows: .exe-Datei) erstellen. Diese ausführbare Datei ist nur auf einem Betriebssystem ausführbar.
  2. Interpretersprachen Java, C#
    Der Quelltext wird nicht in eine ausführbare Datei umgewandelt, sondern in eine Zwischenstufe. Der betriebssystemunabhängige Zwischencode muss in einer betriebssystemspezifischen so genannten Laufzeitumgebung ausgeführt werden. Die Laufzeitumgebung übersetzt zur Ausführungszeit den Zwischencode in einen Code, den Ihr Betriebssystem versteht.
  3. Interpreter-/Skriptsprachen PHP, Python, Perl, ASP
    Der Quelltext wird nicht kompiliert, sondern zur Ausführungszeit interpretiert. Der Interpreter muss den Quelltext zur Ausführungszeit komplett in einen Code übersetzen, den das Betriebssystem versteht. Daher ist dies der langsamste, aber auch universellste Ansatz.

Im serverseitigen Bereich haben sich vor allem die Skriptsprachen durchgesetzt. Die meisten Sprachen sind Open Source; da nicht kompiliert werden muss, kann man Applikationen mit einfachen ASCII-Editoren entwickeln. Im Business-Bereich sind auf Java basierende Applikationen beliebter, hierzu zählen JavaServlets und JavaServerPages. Sie bieten vor allem Geschwindigkeitsvorteile, aber auch mehr Funktionen.
In »normalen« Programmiersprachen geschriebene Programme findet man dagegen im Internet recht selten an, da Servlets, JSP und viele Skriptsprachen explizit für Webapplikationen entwickelt worden sind.

Clientseitige Applikationen

Allen browserseitigen Erweiterungen ist gemein, dass sie vom verwendeten Browser und dessen Konfiguration abhängig sind. Bedenken Sie also:

Hier nun eine kleine Übersicht über mögliche Erweiterungen von XHTML durch browserseitige Skript- und Programmiersprachen:

Skriptsprachen

  1. Ursprünglich von Netscape entwickelt und seit dem Navigator 2.0 eingeführt, wird JavaScript mittlerweile von zahlreichen Browsern unterstützt. Leider ist es nicht einfach, ein Script zu schreiben, dass auf mehreren verschiedenen Browsern läuft, da alle Hersteller andere Wege bei der Weiterentwicklung und Interpretation von JavaScript gegangen sind.

    • Wofür die Schuld ohne Voreingenommenheit bei Microsoft zu suchen ist: anstatt Netscapes JavaScript zu lizenzieren entwickelte Microsoft JScript, das seit dem Internet Explorer 3.0 unterstützt wird.

    Außerdem gibt es bereits verschiedene JavaScript-Versionen, wobei die aktuelleren auch nur von aktuelleren Browsern verstanden werden. Zu bedenken ist auch, dass viele Benutzer die JavaScript-Fähigkeit Ihres Browsers deaktivieren.

    JavaScript wird entweder direkt in das XHTML-Dokument geschrieben oder aber von einem XHTML-Dokument aus referenziert. Einfache Anwendungsmöglichkeiten sind aufklappende Menüs, Popup-Fenster und ähnliche dynamische Effekte.

  2. Die europäische Standardisierungs-Kommission ECMA (European Computer Manufacturers Association) hat alle verschiedenen JavaScript-Versionen auf einen gemeinsamen Nenner gebracht und diesen als Standard (Norm) verabschiedet. ECMAScript ist prinzipiell nichts anderes als eine JavaScript-Form, allerdings mittlerweile (seit der dritten Ausgabe von 1999) in vielen Bereichen mächtiger als Java- oder JScript. ECMAScript wird von der ECMA weiterentwickelt, hat sich aber bisher nicht bei den Browser-Entwicklern durchgesetzt.

  3. VBScript (Microsoft Visual Basic Scripting Edition) wurde von Microsoft entwickelt und wird daher auch nur von aktuelleren Microsoft-Browsern unterstützt. In der Praxis wird es oft bei ASP eingesetzt und (außer auf Microsoft-Webseiten) nur äußerst selten clientseitig.

Java Applets

Applets sind eine spezielle Art von Java-Programmen, die für die Benutzung innerhalb von Webseiten gedacht sind. Dazu muss eine Laufzeitumgebung installiert und dem Browser bekannt sein. Die beiden bekanntesten Laufzeitumgebungen sind die Java Virtual Machine von Microsoft und die Java Runtime Engine von Sun.

Anwendungsbeispiele sind komplexere Programme, die aber auf einer Webseite laufen sollen, zum Beispiel ein Online-Banking-Client oder ein Chat-Client.

Serverseitige Schnittstellen zwischen Applikationen und Webservern

Clientseitig dienen die Browser praktisch als Schnittstelle, als »Schaltzentrale». Der Browser empfängt die Daten, die er vom Webserver geschickt bekommt. Der Webserver seinerseits dient als Schaltzentrale auf der anderen Seite. Damit serverseitig Applikationen ausgeführt werden können, muss analog zum Browser der Webserver entweder die Applikation selbst ausführen oder aber über eine Schnittstelle ein anderes Programm dafür aufrufen.

Damit beispielsweise der Apache Webserver weiß, wie er mit Skripten einer bestimmten Sprache umzugehen hat, muss es eine Verbindung zwischen dem Webserver und dem Interpreter der Skriptsprache geben. Die beiden gebräuchlichsten Methoden sind CGI und SAPI:

CGI

Das Common Gateway Interface ist keine Programmiersprache, sondern bezeichnet eine Schnittstelle, die einige Webserver besitzen. Über diese Schnittstelle ist faktisch jedes Programm ausführbar, unabhängig von der verwendeten Sprache. Auf Windows-Systemen kann über die CGI-Schnittstelle beispielsweise prinzipiell jede beliebige .exe- oder .com-Datei aufgerufen werden. Dies wird auch dazu genutzt, Interpreter auszuführen.

Da CGI in der (mittlerweile ferneren) Vergangenheit (mangels Alternativen) prinzipiell mit der Sprache Perl gleichzusetzen war, liest man häufig von CGI-Programmen (Dateiendung .cgi), die nichts weiter sind als Perl-Programme. Auch in der unten aufgeführten »CGI Programming FAQ« wird die Skriptsprache PHP als Alternative zu CGI gesehen, was aber so nicht stimmt. CGI bezeichnet wie oben beschrieben nur die Schnittstelle, CGI-Programme müssen also keine Perl-Programme sein.

SAPI

Die meisten Webserver lassen sich durch Erweiterungsmodule das Ausführen von Programmen beibringen. Viele Module basieren auf dem Server Application Program Interface-»Standard».

Viele Interpreter für Skriptsprachen sind als Modul für die wichtigsten Webserver verfügbar und bieten mehrere Vorteile gegenüber einer CGI-Lösung (vor allem Performance), aber auch Nachteile (z.B. sind Module für den PHP-Interpreter nach Angaben der Entwickler und eigenen Erfahrungen nicht so ausgereift wie die Applikation; außerdem bevorzugen Provider meist die CGI-Version, da diese sich leichter für einzelne Benutzer beschränken lässt).

Für verschiedene Webserver gibt es angepasste Versionen. Der IIS Webserver (Internet Information Services) von Microsoft nutzt beispielsweise den Microsoft-eigenen ISAPI-Standard (Internet Server Application Program Interface). Für nicht so weit verbreitete Server wie beispielsweise OmniHTTPd oder Xitami gibt es meist keine Module bzw. der Server ist nicht modular erweiterbar; dort ist man auf die CGI-Schnittstelle angewiesen.

Serverseitige Applikationen

PHP, Perl, Python

Die Auffälligkeit, dass alle drei genannten Sprachen mit P beginnen, ist kein Zufall. Vielleicht haben Sie schon einmal die Begriffe LAMP oder WAMP gehört: sie bezeichnen die weit verbreiteten Webserver-Systeme, auf denen ein Apache Webserver (»A«) und eine mySQL-Datenbank (»M«) installiert sind. »L« bzw. »W« stehen für Linux bzw. Windows. Das »P« steht für die unterstützten Skriptsprachen; alle drei Sprachen dienen prinzipiell dem selben Zweck. Perl ist allerdings ursprünglich eher für Netzwerk-, Server- oder UNIX-Administratoren als für Web-Entwickler erdacht worden, daher kann man eher (das syntaktisch stark an C angelehnte) PHP empfehlen, wenn es um reine Web-Entwicklung geht.

PHP bietet in der Version 4 mittlerweile über 1800 Funktionen, die alle Träume eines Entwicklers möglich machen. Aufwendige eCommerce-Lösungen, Meinungsportale, Foren, Communities und vieles mehr.
Man benötigt keinen Compiler, um Quellcode zu erstellen, lediglich der Webserver muss wissen, was er mit dem Quellcode zu tun hat. Dadurch sind Programme auch unbestreitbar portabel und einfach zu erstellen. Wenn ein Client eine PHP-Datei beim Webserver anfordert, wird diese auf dem Server ausgeführt. Das Programm schickt im Normalfall ein dynamisch erstelltes XHTML-Dokument zurück, kann aber vieles mehr: Einträge in eine Datenbank, E-Mails versenden, löschen oder abrufen, Dateien erstellen oder verändern, Kontakt zu anderen Servern aufnehmen und ähnliches.

Perl ist praktisch der Urvater und noch recht weit verbreitet. PHP ist erst einige Jahre alt, wird aber stetig und schnell weiterentwickelt. PHP ist mittlerweile sehr weit verbreitet, weil es leicht von Webservern unterstützt werden kann und einfacher zu erlernen ist als Perl. Python hat es da als sehr neue Sprache noch vergleichsweise schwer, vielen missfällt die Syntax.

Java Servlets, JSP

Auf Java basierende Applikationen sind meist schneller, sicherer, stabiler und mächtiger als Skriptsprachen. Dafür benötigt man eventuell Entwicklungsumgebungen; die Unterstützung durch Webserver ist nicht so unproblematisch. Allgemein sind Java-basierende Programme auf dem Server bei weitem nicht so weit verbreitet wie PHP- oder Perl-Skripte (zumindest im nicht-kommerziellen Bereich).

Servlets sind Java-Programme, die üblicherweise in XHTML eingebunden werden. JSP ist faktisch eine Erweiterung der Servlet-Technologie, bei der JSP-Dateien direkt aufgerufen werden und wie Skriptsprachen erst dynamische Seiten erstellen. Als Webserver gut geeignet ist der Apache in Verbindung mit dem Tomcat, einem vollständig in Java programmierten Applikation-Server, der unter dem Jakarta-Projekt der Apache Software Foundation entwickelt wird.

SSI

Server Side Includes ist eine mit dem Apache Webserver mitgelieferte Erweiterung, die eine sehr einfache Möglichkeit bietet, dem Webserver einige serverseitige Funktionen beizubringen. Die wohl meistgenutzte ist include, mit der man in mehreren Dateien vorkommende XHTML-»Schnipsel« bequem zur Laufzeit einfügen kann (um beispielsweise die Benutzung von Frames zu vermeiden).
Allerdings handelt es sich bei SSI nicht wirklich um eine Programmiersprache, sondern vielmehr um eine kleine Servererweiterung, die nur wenige Funktionen bietet.

Zu bedenken ist, dass SSI (anders als beispielsweise CGI) kein Standard ist. SSI wurde von der NCSA (National Center for Supercomputing Applications) bei seinem Webserver eingeführt. Der Apache beruht auf dem NCSA Webserver, sodass auch der Apache SSI unterstützt.

ASP

Active Server Pages ist Microsofts Begriff für serverseitige Programmierung bzw. für die von Micosoft-Webservern unterstützten Scriptsprachen. Während viele VBScript beispielsweise nur im clientseitigen Anwendungsbereich kennen, so wird es viel öfter in serverseitigen Skripten verwendet. Von Haus aus werden Microsoft JScript und VBScript unterstützt, allerdings kann man durch modulare Erweiterung auch andere Skriptsprachen verwenden.

Zurück: Sprachen im Webauthoring
Weiter: Web-Browser
Zum Seitenanfang