% Diplomarbeit von Andreas Boesch
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Grundlagen des WWW


\chapter{Grundlagen des World Wide Web}
\label{Kap. wwwgrla}
Das World Wide Web (WWW) ist einer der am st"arksten frequentierten Dienste des Internet. Ein erster Prototyp entstand 1990 am CERN in Genf \cite{cern}. Zwei Jahre nach der offiziellen Vorstellung des WWW brachte die einfach zu bedienende Visualisierungssoftware (engl. {\em {\brow}}) \fn{MOSAIC} den Durchbruch f"ur das WWW, das mit Wachstumsraten von mehr als 1000 Prozent pro Jahr (Stand 1996) der am schnellsten wachsende Internet-Dienst ist. 

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{Bilder/wwwgrla/wwwGlob.eps}
\end{center}
\caption{Das WWW als ein Dienst des Internet}
\label{wwwGlob}
\end{figure}

Abbildung~\ref{wwwGlob} stellt das Client/Server Konzept des WWW dar. Ein {\brow} auf dem Rechner des Client kann in Interaktion mit dem Benutzer Informationen von beliebigen Internet Servern\footnote{Der Begriff Server wird hier zweideutig verwendet. Er bezeichnet einerseits einen physisch vorhandenen Rechner, der an das Internet angeschlossen ist und andererseits ein Softwareprogramm, da"s auf diesem Rechner l"auft. Es ist m"oglich, da"s mehrere Serverprogramme auf einem Rechner aktiv sind.} anfordern. Der Server stellt dem Client die gew"unschte Information zur Verf"ugung, sofern sie vorhanden ist und der Client berechtigt ist darauf zuzugreifen. Informationen liegen auf dem Server entweder in statischer Form (Dateien) vor oder werden von ihm dynamisch generiert. Nach der "Ubertragung der Information zum Client ist der {\brow} f"ur deren Darstellung verantwortlich.

Verschiedene Arten von Informationen erfordern unterschiedliche Protokolle f"ur ihre "Uber\-tra\-gung. Das WWW erm"oglicht mit Hilfe des verbindungslosen {\em Hypertext Transfer Protocol} (HTTP, {\VAS}~\ref{http}) die "Uber\-tragung von Information zwischen WWW Servern und WWW Clients. Andere Internetdienste erfordern andere Protokolle. So wird zum Versand elektronischer Post das {\em Simple Mail Transfer Protocol} (SMTP) benutzt und zur "Ubertragung beliebiger Dateien das {\em File Transfer Protocol} (FTP). Mit der Entwicklung von neuen {\brow}n wie dem {\net} {\nav} \cite{NS} oder dem \pn{Internet Explorer} von {\ms} \cite{MS} werden immer mehr Dienste des Internet, wie z. B. die elektronische Post ({\email}) oder der Dateitransfer ({\ftp}) unter einer Benutzerschnittstelle integriert und so f"ur den Benutzer leichter zug"anglich gemacht. 

Anwendungen im WWW bestehen heute meist aus folgenden Komponenten: einem {\brow} auf der Client-Seite, einem Server mit optionalem CGI Skript und bspw. einem Datenbankserver ({\VAB}~\ref{wwwszenario}) \cite{DG95,Bi96}. 

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=4,5cm
\epsffile{Bilder/ansatzbew/wwwszenario.eps}
\end{center}
\caption{Ein typisches {\www}-Szenario}
\label{wwwszenario}
\end{figure}

Der {\brow} zeigt dabei vom Server an den Client "ubertragene Informationen an, die in Form von HTML Seiten entweder statisch als Dateien auf dem Server vorliegen oder automatisch aus dem Datenbestand einer Datenbank generiert werden. Die Verbindung zwischen WWW Server und Datenbank wird "uber das {\em Common Gateway Interface} (CGI) hergestellt. Ein weit verbreitetes Praxisbeispiel f"ur eine solche Anwendung ist ein H"andler, der seine Produktpalette in einer Datenbank verwaltet und "uber einen WWW Server einen Informationsservice f"ur seine Produkte anbietet. Ein Benutzer fordert "uber seinen {\brow} Informationen zu einem bestimmten Produkt an. Der WWW Server gibt die Parameter der Anfrage an das CGI Skript weiter, dieses baut eine Verbindung zur Produktdatenbank auf, fragt die entsprechenden Daten mittels eines SQL Kommandos ab, bereitet die von der Datenbank gelieferten Daten im HTML Format auf und schickt sie zum Benutzer zur"uck. 

Nachfolgend werden die Grundlagen des WWW kurz vorgestellt. Die Adressierung von Daten im WWW erfolgt "uber {\em Uniform Resource Identifier} ({\VAS}~\ref{adressierung}). Abschnitt~\ref{html} erl"autert die Grundlagen der Seitenbeschreibungssprache {\em Hypertext Markup Language} \newline (HTML). Das {\em Hypertext Transfer Protocol} (HTTP) ist die Sprache, die WWW Clients und WWW Server benutzen, um miteinander zu kommunizieren ({\VAS}~\ref{http}). Das {\em Common Gateway Interface} (CGI) ist die Schnittstelle zwischen einem WWW Server und einem beliebigen anderen Programm ({\VAS}~\ref{cgi}). 

Eine besondere Rolle spielen in diesem Zusammenhang Skriptsprachen ({\VAS}~\ref{skripte}) wie z.B. {\javas} und {\vbs}, sowie die Programmiersprache {\java} ({\VAS}~\ref{code}). Diese Sprachen werden nicht wie HTTP, HTML und CGI vom World Wide Web Konsortium (W3C) standardisiert\footnote {Standards, Spezifikationen und Vorschl"age zur Standardisierung sind unter {\em http://www.w3.org} zu finden.}, sondern sind kommerzielle Produkte, die in der jeweiligen Client- und Serversoftware ihrer Hersteller Verwendung finden. 

\section{Adressierung im WWW}
\label{adressierung}
Im WWW werden viele Dienste des Internet integriert und sind in einem {\brow} transparent zu benutzen. Da jedoch z.B. E-mail und FTP unterschiedliche Adressierungsschemata haben, wurde f"ur das WWW das Adressierungskonzept der {\em Uniform Resource Identifier} (URI) entwickelt. URI sind die generische Menge aller Namen und Adressen, die als kurze Zeichenketten Ressourcen referenzieren. Sie schlie"sen die Menge der {\em Uniform Resource Locator} (URL) und der {\em Uniform Resource Name} (URN) ein. Ein URN ist ein URI Schema, das einen Namen global eindeutig und persistent definiert. Ein URN ist im Gegensatz zu einem URL unabh"angig vom Ort des benannten Objektes. Ein URL bezeichnet ein URI Schema, da"s explizite Instruktionen f"ur den Zugang zu Ressourcen im Internet enth"alt, es setzt sich aus dem Protokolltyp, dem Rechnernamen und den Pfadangaben zu der gew"unschten Information zusammen. So k"onnte der H"andler aus obigem Beispiel unter dem URL

\begin{xple}
http://www.unternehmen.de/cgi-bin/produktinfo 
\end{xple}

erreichbar sein. In dem URL wird das Hypertext Transfer Protokoll (HTTP, {\VAS}~\ref{http}) zur "Ubertragung der gew"unschten Information spezifiziert. Der Rechnername ist in diesem Fall {\em www.unternehmen.de}. Alternativ kann der Rechnername als IP Nummer angegeben werden. Falls der WWW Server nicht auf dem Standard WWW TCP Port 80 arbeitet, ist die Angabe einer Portnummer notwendig, z.B. {\em www.unternehmen.de:8001}. Der Pfadname zur gew"unschten Information ist in diesem Beispiel {\em /cgi-bin/produktinfo}. Ein Kunde, der diesen URL in seinem {\brow} aufruft, k"onnte als Antwort vom Server ein Formular erhalten, das es ihm erm"oglicht, ein oder mehrere Produkte aus einer Liste auszuw"ahlen, zu denen er weitere Information w"unscht. Der Kunde in diesem Beispiel hat sich f"ur das Produkt "`Software"' entschieden und fordert vom Server unter folgendem URL weitere Information an:

\begin{xple}
http://www.unternehmen.de/cgi-bin/produktinfo?produkt=software
\end{xple}

In diesem URL wird einem CGI Skript ({\VAS}~\ref{cgi}) zus"atzlich das Name=Wert Paar "`produkt=software"' "ubergeben. 


\section{Hypertext Markup Language}
\label{html}
Die {\em Hypertext Markup Language} ({\html}) ist eine auf {\sgml} (vgl. \cite{R95,SGML}) basierende Seitenbeschreibungssprache. HTML Texte k"onnen von einem {\sgml} Parser gelesen und auf syntaktische Korrektheit "uberpr"uft werden \cite{DH95,HTML}. Im WWW werden die Texte direkt an ein Anzeigeprogramm (engl. {\em{\brow}}) "ubergeben, das ihnen auf dem Bildschirm ein bestimmtes Aussehen zuordnet. Der {\brow} entscheidet "uber die Art der Darstellung anhand von Markierungen im Text (z.B. Titel, "Uberschrift, Listendarstellung, Formulare, etc.). Mit Hilfe von {\em Cascaded Style Sheets} (CSS) ist es m"oglich, die exakte Formatierung von HTML Seiten zu definieren. So lassen sich z.B. Schriftart, Schriftgr"o"se, Schriftschnitt, etc. von HTML Markierungen vom Autor eines Dokumentes bestimmen und m"ussen nicht der willk"urlichen Darstellung des {\brow} "uberlassen werden.

Da HTML Seiten aus ASCII Zeichen bestehen, k"onnen sie mit allen Texteditoren erstellt werden. Es gibt au"serdem Programme, mit denen HTML Seiten nach dem Prizip des WYSIWYG (engl. {\em What You See Is What You Get}) erstellt werden k"onnen. Bei diesen Werkzeugen ist es nicht n"otig, die spezielle Syntax der HTML Markierungscodes (engl. {\em markups}) zu kennen, da sie sich mit Hilfe von grafischen Symbolen oder Men"ueintr"agen in ein Dokument einf"ugen lassen. 

Jeder Markierungscode beginnt mit einer offenen Klammer "'$<$"', gefolgt seinem Namen. Daran schlie"st sich bei einigen Markierungscodes eine Liste von optionalen Attributen an. Ein {\em markup} wird durch eine schlie"sende Klammer "'$>$"' beendet. 

Die meisten HTML Markierungscodes umschlie"sen einen Text und andere Elemente eines Dokumentes mit einer Anfangs- und einer Endmarkierung. Eine Endmarkierung enth"alt vor seinem Namen einen Schr"agstrich "'/"' und niemals Attribute. Das folgende Beispiel definiert einen rechtsb"undigen Absatz:

\begin{xple}
$<$p align=right$>$Dies ist ein rechtsb"undiger Absatz. $<$/p$>$
\end{xple}

HTML Seiten werden "uber sogenannte {\em Hyperlinks} miteinander verkn"upft. Ein Hyperlink enth"alt den URL ({\VAS}~\ref{adressierung}) einer anderen WWW Ressource (HTML Seite, Bild, CGI Programm, etc.). Klickt ein Benutzer auf einen Hyperlink, wird die im URL angegebene Ressource angefordert. Der Hyperlink:

\begin{xple}
$<$a href="'http://www.unternehmen.de/produktinfo.html"'$>$Informationen zu unseren Produkten. $<$/a$>$
\end{xple}

wird von den meisten {\brow}n als unterstrichener Text dargestellt und referenziert eine HTML Seite, die bei Anwahl des Hyperlinks mit der Maus per HTTP angefordert wird.


\section{Hypertext Transfer Protocol}
\label{http}
Das {\em Hypertext Transfer Protocol} (HTTP) ist ein vom W3C standardisiertes, zustandsloses Protokoll zur Kommunikation zwischen WWW Clients und WWW Servern. Die Adressierung von Ressourcen erfolgt mittels URL's ({\VAS}~\ref{adressierung}). Das Verst"andnis des Protokolls dient nicht nur der Programmierung von Clients und Servern, sondern ist auch f"ur die Programmierung von CGI Anwendungen ({\VAS}~\ref{cgi}) unabdingbar \cite{SQ96}.

\subsection{HTTP Grundlagen}
\label{httpGrundlagen}
HTTP Transaktionen folgen einem immer gleichen Schema, das sich sowohl beim Client als auch beim Server aus drei Teilen zusammensetzt:

\begin{itemize}
\item Der Client baut eine Verbindung zu einem bestimmten TCP Port --- in der Regel Port 80 --- auf. Er sendet eine Dokumentenanfrage (engl. {\em request line}) in Form eines HTTP Befehls, einer sogenannten {\em Methode} ({\VAS}~\ref{httpMethoden}), gefolgt von einer Ressourceadresse und einer HTTP Versionsnummer. So benutzt z.B. der Befehl:
\begin{xple}
GET /welcome.html HTTP/1.0
\end{xple}
die Methode {\em GET}, um ein Dokument {\em welcome.html} anzufordern. Der Client benutzt dazu die HTTP Version 1.0. 
\item Als n"achstes sendet der Client einen optionalen Nachrichtenkopf (engl. {\em request header}), um den Server "uber seine Konfiguration und die Dokumentenformate zu informieren, die er verarbeiten kann.
\item Eventuell sendet der Client danach weitere zus"atzliche Daten (engl. {\em request entity body}) zum Server, die dort zu einem verarbeitenden Programm "ubertragen werden.
\end{itemize}

Der Server antwortet darauf wie folgt:
\begin{itemize}
\item Die Antwort des Servers besteht aus einer Statuszeile (engl. {\em response line}), die die benutzte HTTP Version des Servers, eine Zustandskennung und deren Beschreibung enth"alt.
\begin{xple}
HTTP/1.0 200 OK
\end{xple}
Die Zustandskennung ist eine dreistellige Dezimalzahl, die das Ergebnis des Servers auf die Anfrage des Client darstellt. Die Beschreibung ist lesbarer Text, der die Statuskennung erkl"art.
\item Als n"achstes sendet der Server Informationen (engl. {\em response header}) "uber sich selbst und das gew"unschte Dokument (z.B. Datum der letzten "Anderung, Typ, L"ange, etc.).
\item War die Anfrage des Client erfolgreich, folgt das angeforderte Dokument (engl. {\em response entity body}). Dieses kann eine Kopie einer Datei oder die Antwort eines CGI Programms sein. Einige Server erm"oglichen alternativ zu CGI Skripten die Einbindung von Skriptcode ({\VAS}~\ref{skripte}) in HTML Dokumenten, der dann vom Server ausgef"uhrt wird. Dies wird als {\em server-side scripting} bezeichnet.
\end{itemize}

Bei Verwendung von HTTP 1.0 bricht der Server die Verbindung zum Client ab und beendet die Transaktion, nachdem er die gew"unschten Daten gesendet hat. Bei Nutzung von HTTP 1.1 bleibt die Verbindung zwischen Client und Server bestehen, um dem Client weitere Anfragen zu erm"oglichen. Dies ist sinnvoll, da HTML Dokumente oft andere Dokumente (z.B. Bilder, Rahmen, {\java} Applets, etc.) enthalten und der wiederholte Verbindungsaufbau zum gleichen Server eingespart wird. Die Verbindung bleibt bestehen, solange sie nicht von Client oder Server explizit beendet wird.

Da HTTP ein zustandsloses Protokoll ist, bewahrt es keine Informationen von einer zur n"achsten Transaktion. Jede Verbindung eines Client zu einem Server wird vom Server unabh"angig von der vorhergehenden behandelt. Mechanismen, die die Emulation von individuellen Kommunikationszust"anden zwischen Client und Server erm"oglichen, sind von HTTP unabh"angig und werden im Zusammenhang mit CGI Skripten ({\VAS}~\ref{cgi}) verwendet.

\subsection{HTTP Methoden}
\label{httpMethoden}
Eine Methode ist ein HTTP Befehl, mit dem die erste Zeile einer Client Anfrage beginnt. Nach dem Methodennamen folgt die Adresse des Zielobjektes. Folgende Methoden sind in der HTTP Version 1.1 gebr"auchlich:

\begin{description}
\item[GET] Die GET Methode fordert eine Information unter einer bestimmten Adresse vom Server an. Die Berechnung des Ergebnisses erfolgt durch den Server und kann auf unterschiedliche Art erreicht werden (Kopie einer Datei, Antwort eines CGI Programms, {\em server-side scripting}).
\item[HEAD] Diese Methode entspricht der GET Methode mit dem Unterschied, da"s nur Metainformationen (z.B. Dateigr"o"se, Datum der letzten "Anderung, etc.) einer Ressource angefordert werden.
\item[POST] Die POST Methode erlaubt die Sendung von Daten vom Client zum Server in einer Clientanfrage. Die Daten werden im dritten Teil einer Clientanfrage --- dem {\em request entity body} ({\VAS}~\ref{httpGrundlagen}) --- an den Server gesandt. Dieser gibt die Daten an ein Programm an der spezifizierten Adresse weiter ({\VAS}~\ref{cgi}).
\end{description}

Weitere Methoden sind u.a.:
\begin{description}
\item[PUT] dient dazu, eine Ressource auf dem Server unter einem angegebenen URL zu speichern.
\item[DELETE] sorgt f"ur das L"oschen von Daten auf dem Server an einem spezifizierten URL.
\item[OPTIONS] fordert Informationen "uber auf dem Server verf"ugbare Kommunikationsoptionen an (z.B. eine Liste der vom Server unterst"utzten Methoden). 
\item[TRACE] verlangt die intakte R"uckgabe des {\em request entity body}. Dieser dient dann zur Fehlersuche.
\end{description}

Insbesondere die Methoden GET und POST sind f"ur die "Ubertragung von Parametern und Formulareingaben von Benutzern an CGI Programme n"otig.

\section{Common Gateway Interface}
\label{cgi}
Das {\em Common Gateway Interface} (CGI) ist der Teil eines WWW Servers, der mit anderen auf dem Server ablaufenden Programmen kommunizieren kann. Mit Hilfe des CGI kann der WWW Server ein beliebiges Programm aufrufen und diesem benutzerspezifische Parameter "ubergeben. Das Programm berechnet dann aufgrund dieser Parameter eine Ausgabe, die dem Benutzer in seinem {\brow} pr"asentiert wird \cite{Gu96,SQ96}.

Die Kommunikation eines Benutzers mit einem CGI Programm erfolgt "uber HTML Formulare. Diese Formulare k"onnen Benutzerschnittstellenelemente wie z.B. Textfelder, Auswahllisten, Optionsfelder, etc. enthalten und legen au"serdem die zur Sendung des Formulars benutzte HTTP Methode fest. Klickt der Benutzer in einem Formular auf eine sogenannte "'Submit"' Befehlsschaltfl"ache, werden die Daten aus dem Formular bei Benutzung der HTTP GET Methode an den URL in der {\em request line} ({\VAS}~\ref{httpGrundlagen}) angeh"angt. Wird die POST Methode verwendet, werden die Daten im {\em request entity body} an den WWW Server "ubergeben. Der WWW Server reicht sie dann an ein CGI Programm in Form von Varible=Wert Paaren weiter. Dies geschieht bei Gebrauch der GET Methode "uber die UNIX Umgebungsvarible QUERY\_STRING und bei Benutzung der POST Methode als Standard Eingabe (STDIN). Andere Umgebungsvariablen enthalten z.B. das Format und die L"ange der Eingabe, die Rechneradresse des Client, die {\email} Adresse des Client, den Namen des Servers, das Kommunikationsprotokoll, etc.

Aufgrund des zustandslosen HTT Protokolls gibt es keine unterschiedlichen Kommunikationszust"ande zwischen Client und Server. Aus diesem Grund mu"s bei einer neuen Anfrage ein Client einem Server zus"atzliche Informationen "uber sich, bzw. fr"uher gemachte Anfragen mitteilen, damit der individuell reagieren kann. Diese Informationen k"onnen sich in versteckten HTML Formularfeldern befinden, die in einer vorherigen Serverantwort generiert wurden oder in einer Datei ({\net} Cookies, s.u.) , die sich auf dem Rechner des Client befindet.

\subsection*{{\net} Cookies}
\label{cgiCookies}
{\em Cookies} sind ein von der Firma {\net} in ihrem {\brow} {\nav} verwendeter Mechanismus zur persistenten Speicherung von clientspezifischen Informationen auf dem Rechner des Client. Diese Informationen werden beim wiederholten Zugriff auf einen URL automatisch vom Client einer Anfrage hinzugef"ugt und erm"oglichen dem Server ein Personalisieren seiner Antwort f"ur jeden Client. Cookies arbeiten auf folgende Weise:

\begin{enumerate}
\item Identifiziert ein CGI Programm einen neuen Benutzer, f"ugt es einen zus"atzlichen {\em response header} ({\VAS}~\ref{httpGrundlagen}) seiner Antwort hinzu, der einen Bezeichner f"ur diesen Benutzer enth"alt und andere Informationen, die der Server aus der Eingabe des Client entnimmt.
\item Aufgrund des  zus"atzlichen {\em response header} speichert der {\brow} diese Information in der Cookies Datei des Client.
\item Alle weiteren Anfragen des {\brow} an diese URL enthalten die Cookie Information als einen zus"atzlichen {\em request header}.
\item Das CGI Programm benutzt diese Information, um eine Antwort zu generieren, die auf diesen spezifischen Benutzer zugeschnitten ist.
\end{enumerate}

Cookies k"onnen au"ser vom {\brow} auch von in HTML Seiten befindlichen Skripten gelesen und geschrieben werden. {\javas} --- ebenfalls ein Produkt der Firma {\net} --- ist eine Skriptsprache, die in HTML Seiten verwendet werden kann.

\section{Aktive Komponenten}
\label{aktKomp}
HTML Dokumente bieten keine M"oglichkeit, auf Benutzereingaben dynamisch zu reagieren. Tabelle~\ref{aktK} zeigt verschiedene Technologien, die auf der Client- wie auf der Serverseite eingesetzt werden k"onnen, um dynamisches Verhalten zu realisieren. Diese Technologien sind kommerzielle Produkte, die nicht vom W3C standardisiert werden und daher teilweise propriet"ar sind. 

\begin{table}[hbt]
\begin{center}
\leavevmode
\begin{tabular}{|l|l|}   \hline
Client & Server \\ \hline\hline
Client-Side-Scripting: & Server-Side-Scripting: \\ 
{\javas}, {\vbs}, {\jscript} & {\javas}, {\vbs}, {\jscript} \\ \hline
{\java} Applets & {\java} Servlets \\ \hline
{\ax} Controls & {\ax} Controls \\ \hline
{\net} {\plugi} &   \\ \hline
\end{tabular}
\end{center}
\caption{Aktive Komponenten im WWW Kontext}
\label{aktK}
\end{table}


Die Technologien lassen sich konzeptuell in zwei Gruppen unterteilen. Die erste Gruppe bilden die Skriptsprachen {\javas}, {\vbs} und {\jscript}. Der Skriptcode wird direkt in HTML Seiten eingef"ugt und vom {\brow} oder Server ausgef"uhrt ({\VAS}~\ref{skripte}). Die zweite Gruppe bilden {\java}, {\ax} und {\net} {\plugi}, die kompilierten Code auf Client- und Serverseite einsetzen, um die F"ahigkeiten von {\brow}n und Servern zu erweitern ({\VAS}~\ref{code}).  

\subsection{Skripte}
\label{skripte}
Skripte im WWW Kontext erf"ullen den Zweck, die F"ahigkeiten von HTML Seiten zu erweitern. Man unterscheidet {\em client-side scripting}, bei dem die Auswertung des Skriptcodes nach der "Ubertragung der HTML Seite vom {\brow} erfolgt, und {\em server-side scripting}, wobei der Skriptcode vor der "Ubertragung auf dem Server ausgef"uhrt wird. 

\subsubsection*{{\javas}}
\label{skriptJavas}
{\javas} ist eine interpretierte Programmiersprache der Firma {\net} und erlaubt die Verteilung von ausf"uhrbaren Inhalten "uber das WWW. Dies ist so noch kein Unterschied zu sogenannten Applets, die in der Programmiersprache {\java} ebenfalls "uber das WWW verteilt werden k"onnen. W"ahrend Applets jedoch in einer geschlossenen Umgebung ablaufen --- der virtuellen {\java} Maschine (JVM) --- kann {\javas} direkt in HTML Seiten verwendet werden und mit der Seite interagieren. {\javas} verf"ugt u.a. "uber folgende F"ahigkeiten \cite{SQ96}:

\begin{itemize}
\item Kontrolle des Erscheinungsbildes und des Inhaltes von HTML Dokumenten, z.B. lassen sich beliebige HTML Markierungscodes in Abh"angigkeit von anderen Berechnungen in die Seite einf"ugen, 
\item Kontrolle des Verhaltens des {\brow}, z.B. existieren Methoden zur Erzeugung von Dialogboxen oder zum "Offnen und Schlie"sen neuer {\brow} Fenster,
\item Interaktion mit dem Inhalt von Dokumenten, z.B. lassen sich Benutzereingaben in HTML Formularen vor dem Abschicken des Formulars an den Server "uberpr"ufen und gegebenenfalls Neueingaben veranlassen,
\item Interaktion mit dem Benutzer, z.B. kann, immer wenn ein Benutzer seine Maus an einer bestimmten Stelle des Dokumentes positioniert, eine Aktion des {\brow}  ausgel"ost werden,
\item Lesen und Schreiben von Cookies,
\item Ausf"uhrung beliebiger mathematischer Berechnungen.
\end{itemize}

Durch die F"ahigkeit mit dem Inhalt von Dokumenten zu interagieren, kann {\javas} auch zur Steuerung von {\java} Applets ({\VAS}~\ref{code}) dienen und somit die Rolle des Vermittlers zwischen einer HTML Seite und einem {\java} Applet annehmen ({\VAB}~\ref{htmljava}) \cite{Mi96}. 

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=1cm
\epsffile{Bilder/wwwgrla/htmljava.eps}
\end{center}
\caption{{\javas} Code als Vermittler zwischen HTML und {\java} Code}
\label{htmljava}
\end{figure}
 
\subsubsection*{{\vbs} und {\jscript}}
\label{skriptVbs}
{\vbs} sowie {\jscript} sind interpretierte Programmiersprachen der Firma {\ms}. {\jscript} ist kompatibel zu {\javas} und hat den gleichen Umfang wie das von der Programmiersprache {\vb} abgeleitete {\vbs}. Beide Sprachen verf"ugen "uber die o.g. F"ahigkeiten von {\javas}. 


\subsection{Programmcode}
\label{code}
Im Gegensatz zu Skriptcode ({\VAS}~\ref{skripte}) wird Programmcode nicht in Form von Quelltexten ausgetauscht, sondern entweder als Bytecode ({\java}, {\VAS}~\ref{java}) oder als Maschinencode ({\ax}, {\VAS}~\ref{ax} / {\plugi}, {\VAS}~\ref{plugi}). Aufgrund der starken Unterschiede zwischen diesen beiden Modellen werden im folgenden die wesentlichen Merkmale von {\java} und {\ax} erl"autert.


\subsubsection{{\java}}
\label{java}
{\java} ist eine {\oo}e {\cpp}-"ahnliche Programmiersprache der Firma {\sm} \cite{LP96}. Seine gro"se Popularit"at hat {\java} im wesentlichen der Tatsache zu verdanken, da"s {\java} Programme nicht direkt in ausf"uhrbaren Maschinencode "ubersetzt werden, sondern in eine Zwischenrepr"asentation (Bytecode), die auf jeder beliebigen Hardwareplattform verwendet werden kann, f"ur die ein {\java}-Interpreter --- die sogenannte {\em Java Virtual Maschine} ---  existiert ({\VAB}~\ref{javaComp}). Mit der Plattformunabh"angigkeit macht sich {\java} eines der wesentlichen Merkmale des WWW zu eigen. Im Vergleich mit Programmen in Maschinencode sind {\java} Programme langsam \cite{RSS97}. Abhilfe schafft hier ein sogenannter {\em Just in Time Compiler} (JIT), der {\java} Bytecode in Maschinencode "ubersetzt. 

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{Bilder/wwwgrla/javaComp.eps}
\end{center}
\caption{Erstellung und Ausf"uhrung von {\java} Programmen}
\label{javaComp}
\end{figure}

Es existieren drei verschiedene Auspr"agungen von {\java} Programmen:
\begin{description}
\item[Anwendungen:] {\java} Anwendungen sind Programme, die in der Sprache {\java} geschrieben und in der JVM ausgef"uhrt werden.
\item[Applets:] Applets sind {\java} Programme, die in HTML Seiten eingebunden "uber das WWW "ubertragen und dann beim Client in einem {\java}-f"ahigen {\brow} ausgef"uhrt werden.
\item[Servlets:] Servlets sind {\java} Programme, die Erweiterungen von Serverfunktionalit"at unabh"angig von Server Software und der verwendeten Plattform erlauben \cite{Pa97}. Sie sind zu einer spezifischen Schnittstelle konforme {\java} Objekte, die im Gegensatz zu Applets keine grafische Benutzerschnittstelle haben.
\end{description}


Desweiteren unterst"utzt {\java} die drei entscheidenden Konzepte {\oo}er Programmiersprachen \cite{M90}:
\begin{description}
\item[Kapselung:] Daten und Methoden zur Verarbeitung der Daten sind zu einer Einheit in Klassen zusammengefa"st.
\item[Vererbung:] Von bereits bestehenden Klassen k"onnen neue abgeleitet werden. Die abgeleiteten Subklassen erben die Eigenschaften ihrer Superklassen und k"onnen um weitere Daten und Methoden erweitert werden.
\item[Polymorphie:]  Ein Name in einem Programm (eine Variable) kann an Werte verschiedener Typen gebunden werden. 
\end{description}

{\java} verf"ugt "uber umfangreiche Klassenbibliotheken, die sogenannten {\em Packages} \cite{Sc96}. Neben den Basisklassen f"ur grundlegende Datentypen wie Object, Integer, Float, String, etc. gibt es u.a. Packages f"ur Applets, grafische Benutzerschnittstellen, Dateibehandlung und Netzwerkunterst"utzung. Eigene Klassen k"onnen von diesen Klassen erben und eigene Packages bilden.

\subsubsection*{Sicherheitsmechanismen}
Mit {\java} Applets kommt unbekannter Programmcode --- eventuell sogar unbemerkt --- auf dem Rechner des Client zur Ausf"uhrung. Dies erfordert Sicherheitsmechanismen, die es verhindern, da"s:
\begin{itemize}
\item lokale Dateien und Verzeichnisse ge"offnet, gelesen oder ver"andert werden,
\item Betriebssystembefehle aufgerufen werden,
\item andere Programme gestartet werden,
\item Netzwerkverbindungen zu anderen Rechnern au"ser dem Herkunftsrechner des Applet aufgebaut werden.
\end{itemize}

{\java} verhindert die o.g. Operationen auf vier Ebenen: der Programmiersprache selbst, der virtuellen Java Maschine (JVM), des Lademechanismus f"ur {\java} Klassen und der {\java} Klassenbibliothek \cite{Te96,Hu96}.

\subsubsection{{\ax}}
\label{ax}
{\ax} ist die Antwort der Firma {\ms} auf {\java} \cite{RSS97}. Basis f"ur {\ax} ist das unter {\msw} verwendete {\ole} (engl. {\em Object Linking and Embedding}). {\ole} erm"oglicht den Austausch von Daten zwischen verschiedenen Anwendungen. So ist es z.B. m"oglich, Daten einer Tabellenkalkulation als ein Objekt in ein Dokument einer Textverarbeitung einzubetten und so diese beiden Dokumente miteinander zu verkn"upfen. Wenn die eingebettete Tabelle angew"ahlt wird, wird das Tabellenkalkulationsprogramm gestartet, um die Daten zu bearbeiten. Werden andererseits unabh"angig vom Textdokument die Tabellendaten ge"andert, "ubernimmt das Textdokument die "Anderungen automatisch. 

Grundlage von {\ole} ist das {\em Component Object Model} ({\com}), das festlegt, wie Softwareobjekte im Speicher vorliegen und Objekte miteinander kommunizieren k"onnen. Softwarekomponenten sind als austauschbare Teile eines Ganzen zu interpretieren. So l"a"st sich z.B. eine Komponente zur Rechtschreibpr"ufung eines Herstellers problemlos in eine Anwendung eines anderen Herstellers integrieren. {\dcom} ({\em Distributed Component Object Model}) bietet die M"oglichkeit Softwarekomponenten im Netz verteilt zu halten und bildet die Basis f"ur die Internet Variante {\ax}.

{\ax} Controls sind in Bin"arcode "ubersetzte Programme, die nach der "Ubertragung "uber das WWW auf dem Rechner des Client installiert und ausgef"uhrt werden. Da {\ax} mit {\ole} und {\dcom} auf der 32 Bit {\msw} Plattform basiert, ist es bis jetzt eine propriet"are L"osung. An einer Portierung von {\ax} und {\dcom} auf UNIX wird allerdings bereits gearbeitet \cite{RSS97}. {\ax} hat den Vorteil, da"s durch die Basis {\ole} und {\com} bereits eine gro"se Anzahl an Komponenten zur Verf"ugung stehen, die als {\ax} Controls im Internet verwendet werden k"onnen.

\subsubsection*{Sicherheitsmechanismen}
{\ax} Controls haben uneingeschr"ankten Systemzugriff. Das erm"oglicht einerseits die nahtlose Kommunikation mit anderen Anwendungen, andererseits ist eine mi"sbr"auchliche Nutzung nicht auszuschlie"sen. Eine Sicherheitsma"snahme, die {\ms} f"ur {\ax} Controls anbietet, ist deren Zertifizierung. Mit Hilfe eines mitgelieferten Zertifikates kann sich ein Anwender nach dem Laden eines {\ax} Controls davon "uberzeugen, da"s diese Software mit derjenigen identisch ist, die der Entwickler abgeschickt hat. Dieser Mechanismus bietet jedoch keinen wirklichen Schutz vor Mi"sbrauch, wie ein von {\ms} zertifiziertes {\ax} Control zeigt, da"s nach seinem Start das {\win} System des Anwenders abschaltet \cite{RSS97}.


\subsubsection{{\plugi}}
\label{plugi}
{\net} {\plugi} sind wie {\ax} Controls ausf"uhrbare Programme in Maschinencode und daher plattformabh"angig. Sie k"onnen mit dem {\net} {\nav} "uber definierte {\cc}/{\cpp} Schnittstellen kommunizieren und sind in eine HTML Seite integrierbar. {\plugi} reagieren auf MIME Typen von Dokumenten. Ist ein Dokument von einem bestimmten MIME Typ und ist dieser einem {\plugin} zugeordnet, wird dieses gestartet und "ubernimmt die Behandlung bzw. Darstellung des Dokumentes. 

{\plugi} haben wie {\ax} Controls uneingeschr"ankten Systemzugriff und stellen somit eine Sicherheitsrisiko f"ur den Benutzer und sein System dar. W"ahrend sich {\ax} Controls eventuell automatisch installieren, m"ussen {\plugi} explizit vom Benutzer installiert werden.





