% Diplomarbeit von Andreas Boesch
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Bewertung der vorhandenen Ans"atze


\chapter{Bewertung vorhandener Konzepte und Technologien verteilter Informationssysteme}
\label{Kap. AnsatzBewert}

Die grundlegenden Konzepte und Technologien des WWW (Adressierung mittels URLs, HTTP, HTML, CGI) sind bereits einige Jahre alt. In diesem Kapitel werden Konzepte und Technologien des WWW ({\VKA}~\ref{Kap. wwwgrla}) anhand der in Kapitel~\ref{Kap. AnfInformation} erarbeiteten Anforderungen an verteilte Informationssysteme beurteilt ({\VAS}~\ref{wwwBew}).

Einige Vorteile der verteilten Informationssysteme {\hw} und {\netiva} gegen"uber dem WWW werden in Abschnitt~\ref{andereVerIS} vorgestellt. W"ahrend {\hw} "uber eigene Client- und Serversoftware verf"ugt, setzt {\netiva} einen {\java} f"ahigen WWW {\brow} als Clientsoftware voraus.


\section{Das WWW}
\label{wwwBew}
Das World Wide Web ist das Internet Informationssystem mit den seit Jahren gr"o"sten Wachstumsraten. In diesem Abschnitt wird untersucht, inwiefern das WWW Anforderungen an verteilte Informationssysteme ({\VKA}~\ref{Kap. AnfInformation}) erf"ullt und wo Defizite grundlegender Konzepte und Technologien bestehen. 

\subsection{Funktionale Anforderungen}
\label{funktAnfBew}
Die funktionalen Anforderungen von Nutzern und Autoren verteilter Informationssysteme wie dem WWW sind unterschiedlich. Dies trifft insbesondere f"ur das WWW zu, da nicht jeder Benutzer des Systems die M"oglichkeit hat, selbst Informationen im WWW zu ver"offentlichen. Im Folgenden werden die funktionalen Anforderungen des Nutzers an verteilte Informationssysteme auf das WWW "ubertragen und die dort vorhandenen Konzepte zu deren Erf"ullung bewertet:

\begin{description}
\item[Orientierung:] Im WWW sieht der Benutzer in der Regel nur eine HTML Seite. Insofern ist es f"ur ihn nicht m"oglich, sich auf einem Server zu orientieren und zu erfahren, in welchem Kontext die gerade betrachtete Seite mit anderen Informationen auf dem Server steht. Die Orientierung kann nur von dem Autor eines Informationsangebotes z.B. durch die Nutzung von HTML {\em frames} erleichtert werden. {\hw} bietet f"ur die Orientierung des Benutzers auf einem Server verschiedene vom Autor unabh"angige Konzepte ({\VAS}~\ref{hyperwave}). 

\item[Navigation:] Im WWW ist die wichtigste M"oglichkeit zur Navigation im Informationsraum das Verfolgen von Hyperlinks. Die Eingabe einer URL erlaubt den direkten Zugang zu Informationen deren Adresse bekannt ist. {\brow} bieten desweiteren M"oglichkeiten zum Speichern von URL's. Diese k"onnen wie ein Lesezeichen in einem Buch sp"ater wieder aufgerufen werden. Desweiteren werden die in einer Sitzung besuchten Adressen in einer Liste gespeichert und sind w"ahrend der Sitzung weiterhin zug"anglich. Beim Beenden des {\brow} Prozesses geht diese Liste jedoch verloren, so da"s sich der Benutzer fr"uhzeitig entscheiden mu"s, ob er einen URL in seine Lesezeichenliste mit aufnehmen will.
Hyperlinks, die bereits aufgerufen wurden, werden vom {\brow} in einer anderen Farbe dargestellt als Hyperlinks, die noch nicht verfolgt wurden.  {\hw} bietet im Zusammenhang mit seinen erweiterten Orientierungsfunktionen neben dem Verfolgen von Hyperlinks auch andere Navigationsm"oglichkeiten an.

\item[Suchm"oglichkeiten:] Die Suchm"oglichkeiten im WWW sind nicht systemimmanent sondern werden mit Hilfe des CGI von externen Applikationen bereitgestellt, die auf Datenbanken zugreifen. Die Datenbanken werden durch das Abrufen von HTML Seiten und der Auswertung der darauf enthaltenen Texte gef"ullt und speichern die URL der HTML Seite samt der gesammelten Informationen. Der Suchraum ist bei Suchmaschinen wie z.B. {\lyc} auf Audio- und Bilddateien bzw. verschiedene verwendete Sprachen einschr"ankbar. Suchmaschinen im WWW basieren auf der nachtr"aglichen Auswertung von HTML Dateien, w"ahrend in Systemen wie {\hw} Informationen inklusive ihrer Metadaten (Autor, Datum, Stichworte, Typ der Information, etc.) in strukturierter Form in Datenbanken vorliegen. Dadurch sind die Suchergebnisse in diesen Systemen immer aktuell, da sie auf den Originaldaten beruhen, w"ahrend die Ergebnisse von Suchmaschinen wie {\lyc} auf Zweitauswertungen der Originalinformation basieren und die Suchmaschine "uber "Anderungen oder L"oschungen von HTML Seiten nicht informiert wird. 

\item[Visualisierung von "Anderungen:] Die {\em push} Technologie erlaubt es dem Benutzer im WWW Informationen zu abonnieren. Ein Client erh"alt dann unter Zuhilfenahme einer speziellen Software automatisch die jeweils neusten auf einem Server vorliegenden Informationen. Das geschieht dadurch, da"s die {\em push} Software beim Bestehen einer Netzwerkverbindung regelm"a"sig beim Server "uberpr"uft, ob dort neue vom Benutzer abonnierte Informationen vorliegen und diese dann automatisch anfordert. Solche Systeme werden z.B. zur automatischen Verteilung von  B"orsenkursen, HTML Seiten oder Software eingesetzt \cite{Ki97}.

\item[Transparenz und Bedienbarkeit:] Die transparente Bedienbarkeit des WWW ist f"ur den Benutzer gegeben, da er nur Hyperlinks verfolgt oder Formulare ausf"ullt. Die Anforderung und "Ubertragung der Informationen "ubernimmt der {\brow}, der auch f"ur die Darstellung der Information sorgt, sofern das Datenformat bekannt ist.

\end{description}

F"ur Erstellung und Wartung von Information im WWW haben Autoren weitere Anforderungen:

\begin{description}
\item[Statische und dynamische Informationserstellung:] Informationen im WWW k"onnen sowohl statisch als auch dynamisch erstellt werden. Statische Informationen liegen z.B. in Form von HTML Seiten, Bildern, {\java} Applets als Dateien auf dem Server vor und werden auf Anfrage eines Client ausgeliefert. Dynamische Informationen werden in der Regel in Form von HTML Seiten mit Hilfe der CGI Schnittstelle als Antwort auf eine individuelle Anfrage eines Client erzeugt ({\VAS}~\ref{cgi}). Die CGI Schnittstelle wird auch f"ur Client/Server Anwendungen im WWW genutzt, ist daf"ur aber nicht geeignet, da keinerlei Typinformation "uber die Parameter in Anfragen mitgeliefert werden und HTTP ein zustandsloses Protokoll ist. 

\item[Autorisierte Erstellung und Wartung:] Mit der HTTP Methode {\em PUT} ist es m"oglich, Dateien vom Client zum WWW Server zu "ubertragen und dort zu speichern. Dies kann aber nur mit zugeh"origen Sicherheitsmechanismen erfolgen, damit nicht jeder beliebige Benutzer eine WWW Seite "andern kann. Server, die die PUT Methode implementieren, bieten dementsprechend Authentisierungs- und Autorisierungmechanismen an. Da WWW Server statische Informationen im Dateisystem ablegen, mu"s  der Sys\-tem\-ad\-ministrator darauf achten, da"s dort nur befugte Autoren Schreibrechte haben. 

\item[Konsistenzerhaltende Wartung:] Da die Erstellung von Informationen derzeit meist au"serhalb des WWW (z.B. mit Hilfe von HTML Editoren, CGI Skripten und Datenbanken) erfolgt, m"ussen hier Mechanismen wie z.B. Versionierung eingesetzt werden, um bei "Anderungen von Ressourcen die Konsistenz von Verweisen auf die alten Informationen zu erhalten. K"ummert sich ein Autor nicht um die Erhaltung der Konsistenz, z.B. dadurch da"s er HTML Dateien umbenennt oder l"oscht, werden die Verweise auf diese Information ung"ultig und sind unbrauchbar.

\item[Automatische Erzeugung von Hyperlinks:] Die Wiederverwendung bereits bestehender Information durch die automatische Erzeugung von Hyperlinks wird im WWW nicht von System unterst"utzt. Der Autor mu"s die von ihm referenzierten Ressourcen und deren URL kennen, um einen Hyperlink zu erzeugen.  

\item[Trennung von Inhalt und Pr"asentation:] Im WWW erlaubt HTML die Trennung von Inhalt und Pr"asentation. W"ahrend der Inhalt als ASCII Text und die Funktion des Inhalts (z.B. "Uberschrift, Aufz"ahlung, Tabelle) als HTML Schl"usselworte definiert werden, sorgen die {\em style sheets} f"ur die Festlegung der Formatierung des Inhalts. Liegen keine vom Autor definierten {\em style sheets} vor, "ubernimmt der {\brow} die Formatierung des Inhalts. 

\end{description}

Die oben erw"ahnten Vorteile von {\hw} werden in Abschnitt~\ref{andereVerIS} n"aher erl"autert.

\subsection{Architekturelle Anforderungen}
\label{archAnfBew}
Die architekturellen Anforderungen an verteilte Informationssysteme aus Abschnitt~\ref{archAnf} werden im Folgenden auf das WWW "ubertragen und die damit zusammenh"angenden Konzepte und Defizite betrachtet.

Um die Konsistenz in einem Informationssystem zu erhalten, sollten folgende Forderungen erf"ullt werden:

\begin{description}

\item[Objektbenennung:] Die Identifizierung von Objekten erfolgt im WWW anhand ihrer URLs ({\VAS}~\ref{adressierung}). Objekte werden anhand ihrer Adresse und des Zugangsverfahrens referenziert. Bei Adre"s"anderungen kommt es so zu Inkonsistenzen. W"urden stattdessen URNs zur Identifizierung von Objekten eingesetzt, k"onnten Hyperlinks unabh"angig von der Adresse eines Objektes definiert werden und w"aren auch bei Adre"s"anderungen (z.B. Verschieben einer Datei in ein anderes Verzeichnis) weiterhin g"ultig.

\item[Redundanzfreiheit:] Das WWW bietet keine M"oglichkeit die Redundanzfreiheit der Informationsinhalte sicherzustellen. Jede HTML Datei kann unter beliebig vielen Adressen den gleichen Inhalt haben. Dies ist im WWW ein Problem, wenn Informationen wie z.B. Adressen oder Telefonnummern von Organisationen auf mehreren statischen HTML Seiten verwendet werden. Eine konsistente "Anderung dieser Dateien wird nicht vom WWW unterst"utzt. Bei dynamischen Informationen, die aus Datenbanken gewonnen werden, sind die Datenbanken f"ur die Redundanzfreiheit der Information verantwortlich. 

\item[Versionierung:] Das WWW bietet keine Konzepte und Technologien f"ur die Versionierung von Ressourcen.\footnote{Der neuste Standardisierungsvorschlag des WWW Konsortiums f"ur HTML 4.0 unterst"utzt die Versionierung von HTML Dateien ({\VAS}~\ref{htmlVier}).}
 Verschiedene Ans"atze wie z.B. Server- und Protokollerweiterungen werden in Kapitel~\ref{Kap. versionierung} betrachtet. 
\end{description}

Neben der Konsistenz der Informationen sind von einem verteilten Informationssystem folgende Anforderungen zu erf"ullen:

\begin{description}

\item[Strukturierte Datenspeicherung:] Die WWW Infrastruktur (URLs, HTTP, HTML, CGI) stellt keine Konzepte f"ur die Speicherung der Informationsinhalte bereit. W"ahrend statische HTML Seiten als Dateien im Dateisystem gespeichert werden, bietet CGI die Verbindung von WWW Servern zu beliebigen anderen Programmen wie z.B. Datenbanken. WWW Server wie z.B. {\jig} ({\VAS}~\ref{jigsaw}) verwalten eigene Datenstrukturen der von ihnen bereitgestellten Information und bieten so den Zugriff auf strukturierte Metainformation.

\item[Skalierbarkeit:] Die Performanz des WWW h"angt von vielen Faktoren ab (Bandbreiten zwischen Benutzer, Internet und Informationsanbieter, Verkehr auf dem Internet, Auslastung der Server). Um Engp"asse bei der Leistung der Server zu umgehen, gibt es im WWW das Konzept der Zwischenspeicherung von Informationen auf {\em Proxy} Servern. Hierbei erreichen alle Anfragen des Client zuerst einen Proxy Server, der versucht, die Anfrage des Client aus seinem eigenen Zwischenspeicher zu bedienen, bevor er eine Anfrage an den in der Clientanfrage genannten Server stellt. Dadurch wird der Netzwerkverkehr reduziert und der Originalserver entlastet. Das auf dem Internet Protokoll basierende WWW ist es nicht an einzelne Netzwerkverbindungen gebunden. Die Umleitung des Netzwerkverkehrs erfolgt bei Ausfall eines Internetrechners automatisch "uber andere Rechner.

\item[Anpassung an variable Netzkapazit"aten:] Ein Benutzer kann bei geringen Bandbreiten die "Ubertragung von Bildern und {\java} Applets mit Hilfe des {\brow}s unterdr"ucken. Eine automatische Anpassung w"are zus"atzlich w"unschenswert, z.B. mit Hilfe des IPv6 und des RSVP ({\VAS}~\ref{IPv6}). 

\item[Integrit"at:] Das WWW unterst"utzt die sichere "Ubertragung von Informationen im WWW mit S-HTTP. Eine propriet"are Variante der sicheren Daten"ubertragung ist die {\em secure socket layer} (SSL) von {\net}. Einfache, unverschl"usselte Authentifizierung mittels Passwortabfragen bietet HTTP. WWW Server unterst"utzen das Protokollieren aller Zugriffe auf den Server (engl. {\em auditing}).

\end{description}

Die grundlegende Architektur des WWW --- in Form des verbindungslosen HTT Protokolls und der zustandslosen WWW Server --- f"uhren zu Problemen bei verteilten Anwendungen, mit denen aus mehreren Teilschritten bestehende Transaktionen durchgef"uhrt werden sollen ({\VAS}~\ref{cgi} und Kapitel~\ref{Kap. objektcom}). F"ur die einfache "Ubertragung von Information in Form von Dateien (HTML Seiten, Bilder, {\java} Applets) ist das WWW jedoch gut geeignet.

\subsection{Technische Anforderungen}
\label{techAnfBew}
Die in Abschnitt~\ref{techAnf} erarbeiteten technischen Anforderungen werden im Folgenden auf das WWW "ubertragen:

\begin{description}
\item[Plattformunabh"angigkeit:] Plattformunabh"angigkeit ist im WWW durch plattformunabh"angige Informationsformate (HTML, GIF, JPEG, {\java}, {\javas}) gegeben. {\ms} versucht mit {\ax} ein plattformabh"angiges Codeformat im WWW zu etablieren. Dadurch entsteht f"ur den Informationsanbieter hoher Aufwand, da er f"ur jede Plattform eigene {\ax} Komponenten zur Verf"ugung stellen mu"s.

\item[Kompatibilit"at:] Die meistgenutzte Kompatibilit"atsschnittstelle im WWW ist das CGI, da sie von allen Servern unterst"utzt wird und auf der Clientseite lediglich das Ausf"ullen von HTML Formularen bzw. das Aufrufen von Hyperlinks erfordert. Die {\java} Applet Schnittstelle von {\brow}n erlaubt die sichere Ausf"uhrung von Programmcode auf dem Clientrechner. Schnittstellen zu beliebigen heterogenen Systemen stehen durch die Unterst"utzung von {\corba} ({\VKA}~\ref{Kap. objektcom}) im {\net} {\brow} Version 4.0 zur Verf"ugung. Auf der anderen Seite wird in neueren Betriebssystemen von {\ms} der {\brow} mit der normalen Benutzerschnittstelle verschmelzen, so da"s der Benutzer keinen Unterschied mehr zwischen lokaler und entfernter Information feststellt \cite{MS}.

\item[Migration:] Migrationskonzepte sind in den WWW Technologien nicht vorhanden, da es sich um ein klassisches Client/Server System handelt. Es ist aber denkbar, da"s die von {\brow}n unterst"utzte Programmiersprache {\java} mit solchen Konzepten und Bibliotheken versehen wird und der Benutzer migrierende Agenten mit seinen Auftr"agen im WWW umherschicken kann, die ihn mit speziellen Informationen versorgen.

\item[Ressourcenunabh"angigkeit:] Die Ressourcenunabh"angigkeit ist im WWW Kontext insbesondere f"ur {\java} Applets wichtig, die sich evtl. auf das Vorhandensein bestimmter ben"otigter Bibliotheken verlassen. {\brow} versuchen nicht lokal vorhandene {\java} Bibliotheken nachzuladen. Dieses Vorgehen ist auch f"ur propriet"are Informationsformate denkbar, die auf dem Clientrechner nicht bekannt sind. So k"onnten bei unbekannten Informationsformaten vom {\brow} entsprechende {\java} Applets oder {\ax} Komponenten angefordert werden, die f"ur die Darstellung der unbekannten Objekte sorgen.

\end{description}


Dadurch, da"s die Datenspeicherung von Informationen au"serhalb der Konzepte und Technologien des WWW stattfindet, kann das WWW in vielen Anwendungsf"allen (z.B. Orientierung, Suchm"oglichkeiten, Navigation) nicht mit auf Datenbanken basierenden Informationssystemen konkurrieren. In anderer Hinsicht wie z.B. der Plattformunabh"angigkeit und der transparenten Bedienbarkeit ist es hingegen vorbildlich.

\section{Andere verteilte Informationssysteme}
\label{andereVerIS}
In diesem Abschnitt werden ausgew"ahlte Konzepte der Systeme {\hw}  und {\netiva} vorgestellt und gezeigt, inwiefern diese Vorteile gegen"uber dem WWW bieten. W"ahrend {\hw} (vgl. Ab\-schnitt~\ref{hyperwave}) einige grundlegend neue Konzepte (z.B. bidirektionale Hyperlinks) gegen"uber dem WWW bietet, handelt es sich bei {\netiva} ({\VAS}~\ref{netiva}) um ein System f"ur Mehrbenutzerdatenbankanwendungen im WWW, das Beschr"ankungen und Komplexit"at von HTTP, HTML und CGI  f"ur Entwickler und Benutzer aufhebt.

\subsection{{\hw}}
\label{hyperwave}
{\hw} (ehemals {\hg}) ist ein hypermediales Informationssystem f"ur das Internet. Es wurde am Anfang seiner Entwicklung als ein eigenst"andiges "`Internet Informationssystem der 2. Generation"' beschrieben \cite{DH95}, w"ahrend es heute, aufgrund des gro"sen Erfolges des WWW, als eine Erweiterung des WWW gesehen wird \cite{M96}. 

Die Architektur eines {\hw} Systems ist in Abbildung~\ref{hwArch} dargestellt. Es gibt spezielle {\hw} Server und Clients sowie das sie verbindende {\em HyperG-Client Server Protocol} (HG-CSP). Ein {\hw} Server ist auch "uber HTTP von WWW {\brow}n aus zug"anglich. 

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=1cm
\epsffile{Bilder/ansatzbew/hwArch.eps}
\end{center}
\caption{Architektur eines {\hw} Systems}
\label{hwArch}
\end{figure}

Einige wesentliche Unterschiede zum WWW werden im Folgenden erl"autert.

\subsubsection*{Objektbenennung}

Ein {\hw} Server kann Objekte beliebiger Art verwalten und speichert sie in einer Datenbank. Die Identifikation einzelner Objekte erfolgt mittels eines serverweit eindeutigen lokalen Objektbezeichners (OID). Im Zusammenhang mit der SID, die einen Server eindeutig bezeichnet, ergeben sich weltweit eindeutige globale Objektbezeichner, die in {\hw} als {\em birthplace ID} bezeichnet werden. Anhand der OID wird ein Objekt in der Datenbank identifiziert und die zum Objekt geh"orenden Metainformationen ausgewertet. Aus den Metainformationen wird die Adresse bzw. der Verzeichnispfad des Objektes gewonnen und letztlich das Objekt ausgeliefert.

Durch diese Art der Speicherung stehen umfassende Suchm"oglichkeiten anhand der bereitgestellten Metainformationen (Autor, Titel, Schl"usselworte, Zugriffsrechte, Erstellungszeitpunkt, etc.) zu einem Objekt zur Verf"ugung. Desweiteren besteht Orts- und Adre"stransparenz. Referenzen auf Objekte bestehen immer nur aus der Kombination von SID und OID und m"ussen nicht ge"andert werden, wenn das Objekt seine Adresse "andert, wie es beim URL Konzept des WWW der Fall ist.

\subsubsection*{Strukturierung, Orientierung und Navigation}

W"ahrend im WWW Informationsknoten nur mittels Hyperlinks strukturiert werden k"onnen, bietet {\hw} wesentlich mehr Strukturierungsm"oglichkeiten f"ur die im System enthaltene Information. {\hw} Objekte sind Instanzen spezifischer Klassen. Es gibt u.a. Klassen f"ur Text-, Bild- und Klangdokumente. Ein der Strukturierung dienendes Objekt ist das Kollektionsobjekt. Eine {\em Kollektion} ist ein zusammengesetztes Objekt, das Dokumente oder andere Kollektionen enth"alt. Das Kollektionsobjekt ist mit einem Verzeichnis in einem Dateisystem vergleichbar. Die Kollektionen in einem {\hw} System bilden einen gerichteten azyklischen Graphen --- die Kollektionshierarchie ---, dessen oberstes Objekt als {\em Wurzelkollektion} bezeichnet wird.

Eine Kollektionshierarchie wird in einem {\hw} Client "ahnlich einer Verzeichnisstruktur in einem zus"atzlichen Fenster angezeigt. So kann ein Benutzer ein Dokument betrachten und gleichzeitig sehen, in welcher Kollektion er sich befindet und welche anderen Objekte in dieser Kollektion  vorhanden sind. Au"serdem kann er jederzeit in der Kollektionshierarchie Kollektionen "offnen und Dokumente aufrufen, die dann automatisch in einem anderen Fenster zur Dokumentendarstellung angezeigt werden. Folgt ein Benutzer einem Hyperlink in einem Dokument, wird nicht nur das jeweilige Dokument angezeigt, sondern auch die dazugeh"orige Stelle in der Kollektionshierarchie. Diese Orientierungs- und Navigationsm"oglichkeiten sind jedoch mit WWW {\brow}n nicht zu nutzen sondern erfordern spezielle {\hw} Clients.

\subsubsection*{Hyperlinks}
Hyperlinks werden durch ihre Quell- und Zielanker definiert und nicht in Dokumenten selbst gespeichert. Der Quellanker ist der Startpunkt eines Hyperlinks und spezifiziert den Teil eines Dokumentes von dem aus der Hyperlink aktiviert werden kann. In einem Textdokument wird dieser z.B. hell unterlegt, w"ahrend er in einem Video als Ausschnittrahmen dargestellt wird. Der Zielanker ist der Endpunkt eines Hyperlinks und beschreibt eine bestimmte Stelle in einem Dokument, die angezeigt wird, wenn man an diesem Knoten ankommt (z.B. ein spezifischer Absatz in einem Textdokument). Dokumente und Anker stehen in einer 1:n Beziehung, d.h. einem Dokument k"onnen mehrere Quellanker als auch mehrere Zielanker zugeordnet werden. Quell- und Zielanker stehen in einer n:1 Beziehung, d.h. viele verschiedene Quellanker k"onnen dem gleichen Zielanker zugeordnet werden. Soll ein Quellanker nicht zielgenau auf einen spezifischen Teil eines Objektes verweisen wird kein Zielanker f"ur das Objekt angelegt. Der Hyperlink f"uhrt dann direkt vom Quellanker zu dem Dokument.

Das Wesentliche an diesem Konzept ist, da"s es f"ur den Client m"oglich ist, Hyperlinks in beide Richtungen zu verfolgen. Er kann ein Dokument zu einem Anker finden und andererseits alle Anker eines gegebenen Dokumentes.  Da die Beziehung zwischen Quell- und Zielanker ebenfalls bidirektional ist, lassen sich auch alle Dokumente finden, die ein betrachtetes Dokument referenzieren. Mit bidirektionalen Hyperlinks ist es m"oglich die Konsistenz von Hyperlinks auch bei "Anderungen an Dokumenten zu bewahren, z.B. indem der Autor eines Hyperlinks, der ein ge"andertes Dokument referenziert, "uber die "Anderung informiert wird oder automatisch bei vorhandenen Rechten ein Quellanker entfernt wird.


\subsection{{\netiva}}
\label{netiva}
{\netiva} ist ein System zur Realisierung von Mehrbenutzerdatenbankanwendungen im WWW \cite{Netiva}. Es besteht aus einer Entwicklungsumgebung ({\netiva} {\em designer}) und einem {\netiva} WWW Server. {\netiva} Anwendungen sind Client/Server Datenbankanwendungen. Die Clientsoftware wird in Form von {\java} Applets per URL vom {\netiva} Server angefordert und dann in einem {\brow} ausgef"uhrt. Die {\java} Applets kommunizieren mit dem {\netiva} Server und f"uhren Datenbanktransaktionen durch ({\VAB}~\ref{netivaArch}).

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{Bilder/ansatzbew/netivaArch.eps}
\end{center}
\caption{Architektur eines {\netiva} Systems}
\label{netivaArch}
\end{figure}

Der {\netiva} Server hat folgende Aufgaben:
\begin{itemize}
\item "Ubertragung der Clientapplets zum {\brow}
\item Management der Zust"ande der bestehenden Verbindungen
\item Bereitstellung von Datenbankserverfunktionalit"at und Transaktionsmangement
\end{itemize}

\subsubsection*{Anwendungsentwicklung}
Das Konzept von {\netiva} Anwendungen unterscheidet sich grundlegend von herk"ommlichen relationalen Datenbankanwendungen \cite{Lo87}, in denen zuerst die Tabellenstrukturen erstellt werden, um in einem zweiten Schritt bestimmte Sichten (Eingabeformulare, Abragen, Berichte) auf diese Strukturen zu entwickeln.

Die Anwendungsentwicklung von {\netiva} Datenbankanwendungen erfolgt in drei Schritten:
\begin{description}
\item [Gestaltung der Benutzerschnittstelle:] Der Entwickler gestaltet per {\em drag and drop} sowohl Benutzerschnittstellenseiten ({\em front-end pages}) als auch Seiten, die nur f"ur den Entwickler relevant sind ({\em back-end pages}). W"ahrend die {\em back-end pages} den Tabellen der Datenbank entsprechen, sind die {\em front-end pages} mit verschiedenen Sichten auf die Datenbanktabellen vergleichbar. Eine Seite kann z.B. Texteingabefelder, Schaltfl"achen, Tabellen und beliebige andere Benutzerschnittstellenelemente wie z.B. Grafiken und Hyperlinks enthalten.

\item [Makroprogrammierung:] Mit Hilfe einer {\vb} "ahnlichen Makroprogrammiersprache werden die {\em front-end pages} mit den {\em back-end pages} verkn"upft. So kann z.B. ein Makro durch eine Schaltfl"ache aktiviert werden, das daf"ur sorgt, da"s die in den Eingabefeldern gemachten Angaben in die Datenbank aufgenommen werden. 

\item [Bereitstellung der Anwendung auf dem {\netiva} Server:] Aus {\em front-end pages}, {\em back-end pages} und Makros wird in einer einzelnen Datei eine {\netiva} Datenbankanwendung erzeugt. Au"serdem wird eine HTML Seite generiert, die lediglich ein mit der entsprechenden Datenbankanwendung initialisiertes {\netiva} Clientprogramm in Form eines {\java} Applets referenziert. Eine {\netiva} Anwendung mu"s inkl. der zugeh"origen HTML Seite in ein Verzeichnis des {\netiva} Servers kopiert werden und steht dann f"ur Zugriffe aus dem WWW zur Verf"ugung.
\end{description}

Ein {\netiva} Entwickler kommt zu keinem Zeitpunkt mit HTTP, HTML, CGI oder {\java} in Ber"uhrung. Es werden keine {\java} Quellcodedateien erzeugt. 
Die gesamte Entwicklung findet im {\netiva} Designer statt. Neben der Neuentwicklung von Datenbanken k"onnen auch Datenbanken in anderen Formaten (z.B. {\ms} {\acc} oder {\dBase}) weiterverwendet werden, so da"s mit {\netiva} Benutzerschnittstellen f"ur bestehende Datenbanken im WWW verf"ugbar werden.

\subsubsection*{Bewertung}
Anwendungen mit WWW Benutzerschnittstelle profitieren grunds"atzlich davon, da"s keine spezielle Clientsoftware installiert werden mu"s und da"s neue Versionen der Clientanwendung automatisch verf"ugbar sind. {\java} Clientanwendungen bieten dar"uber hinaus den Vorteil der Dynamik, d.h. es k"onnen "Uberpr"ufungen von Eingabefeldern vorgenommen werden, ohne da"s eine neue Verbindung zum Server erforderlich wird bzw. eine neue HTML Seite geladen werden mu"s.

Entwicklungsumgebungen wie der {\netiva} Designer setzen die bei {\vb} begonnene Reihe der grafischen Entwicklungsumgebungen nahtlos f"ur WWW Datenbankanwendungen fort. Datenbankanwendungen sind in sehr kurzer Zeit ohne Kenntnisse von HTML, HTTP, CGI, Skriptsprachen und {\java} zu entwickeln. Desweiteren ist es nicht notwendig, da"s sich ein {\netiva} Entwickler mit Indizes, Fremdschl"usseln oder der Normalisierung von Datenbanken auskennt, da das System die Datenbankstruktur v"ollig transparent f"ur den Entwickler aus den von ihm erstellten grafischen Benutzerschnittstellen generiert.

Ein entscheidender Nachteil von {\netiva} ist, da"s das Komponentenmodell {\java} {\beans} ({\VAS}~\ref{javabeans}) noch nicht unterst"utzt wird. Dadurch w"urde es m"oglich, {\java} {\beans} beliebiger Hersteller in die Entwicklungsumgebung zu integrieren und die bisher beschr"ankte Funktionalit"at von {\netiva} zu erweitern.
