% Diplomarbeit von Andreas Boesch
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Anforderung an Erstellung und Wartung von Information

\chapter{Anforderungen an verteilte Informationssysteme}
\label{Kap. AnfInformation}

In diesem Kapitel werden allgemeine Anforderungen an die Erstellung, Speicherung, Wartung, Pr"asentation und Verteilung von Information in Informationssystemen als Pendant zu Programmen aus der Softwaretechnik erarbeitet werden. Es wird der Fragestellung nachgegangen, inwiefern sich Konzepte wie z.B. Konsistenzerhaltung, Redundanzfreiheit, Wartbarkeit, Skalierbarkeit oder Plattformunabh"angigkeit aus der Softwaretechnik (\cite{Matt93}, \cite{B82}, \cite{M90}, \cite{Lo87}) auf die allgemeinen Anforderungen an Information "ubertragen lassen. Weitere spezielle Anforderungen f"ur verteilte Informationssysteme, wie z.B. die Anpassung an unterschiedliche Pr"asentationssysteme (Hardware, Protokolle, {\brow}) und variable Netzkapazit"aten werden untersucht. 

Unter einem {\em Informationssystem} (IS) versteht man ein Werkzeug zur Erfassung und Kommunikation von Information zum Zwecke der Erf"ullung der Anforderungen seiner Benutzer, der Aktivit"aten ihres Unternehmens und zur Erreichung der Unternehmensziele \cite{Vo95}. Ersetzt man in dieser Definition den Begriff {\em Unternehmen} durch {\em Organisation} gelangt man zu einer allgemeineren Definition. Ein IS umfa"st s"amtliche zur Informations-Sammlung, -Verwaltung, -Benutzung und -Distribution in der Organisation vorhandenen Resourcen, wie z.B. die Daten in Datenbanken oder Dateisystemen, die Datenbank- und die Anwendungs-Software, die Hardware des Rechnersystems inklusive der verwendeten Speichermedien, sowie die Benutzer, Verwalter und Programmierer des Systems. IS basieren heute typischerweise auf dem Einsatz von Datenbanken. 

Zwischen den Daten einer Datenbank und der Information, die ein Benutzer in einem IS ablegen oder aus ihm gewinnen m"ochte, mu"s im allgemeinen ein Interpretationsproze"s stehen, der in der Regel durch Programme in algorithmischen Programmiersprachen zu realisieren ist \cite{Lo87}. 

In diesem Kapitel werden nun die prim"aren Anforderungen an die Erstellung ({\VAS}~\ref{erstell}), Speicherung, Wartung, Pr"asentation und Verteilung von Information in (verteilten) Informationssystemen am Beispiel des {\web} herausgearbeitet werden.


\section{Erstellung von Information}
\label{erstell}
Die Erstellung von Information im {\www} erfolgt in zunehmendem Ma"se dynamisch, d.h. eine HTML Seite wird aufgrund einer parametrisierten Anfrage eine Client individuell f"ur diesen aus bestehenden Datenbest"anden zusammengestellt bzw. erzeugt. Dadurch wird der mangelnden Aktualit"at ({\VAS}~\ref{wart}) statischer {\html} Seiten begegnet, die einerseits zu Inkonsistenzen und andererseits zu nachlassendem Benutzerinteresse f"uhrt. Ein derzeit weitverbreiteter Ansatz der automatischen Generierung von Information in Form von HTML Seiten ist die Verwendung von CGI Anwendungen, die Information aus Datenbanken im HTML Format aufbereiten ({\VKA}~\ref{Kap. wwwgrla}).

F"ur die automatische Generierung bzw. Zusammenstellung von Information werden einerseits Datenbanken ben"otigt, die strukturierte Information bereitstellen, und andererseits Programmierwerkzeuge, die die Information aus den vorhandenen Datenbest"anden interpretieren und daraus die vom Informationssuchenden gew"unschten extrahieren. {\ty} als persistente polymorphe Programmiersprache bietet hier Vorteile gegen"uber herk"ommlichen Programmiersprachen-Datenbank Kombinationen, da der sogenannte {\em impedance mismatch} - die Diskrepanz zwischen mengenorientierter, deklarativerter Datenverarbeitung in Datenbanksystemen und dem elementorientierten, prozeduralen Paradigma konventioneller Programmiersprachen - durch die konzeptionelle Integration von Datenbankmodellen in eine algorithmisch vollst"andige Programmiersprache vermieden wird \cite{Matt93}. 

Die derzeit im {\www}-Zusammenhang vieldiskutierte {\oo}e Programmiersprache {\java} ({\VAS}~\ref{java}) bietet keine transparente Persistenzabstraktion wie {\ty} sondern Klassen zum Datenbankzugriff auf beliebige Datenbanken, die die von mehreren gro"sen Softwarefirmen definierte Schnittstelle {\jdbc} (engl. {\em Java Database Connectivity}) unterst"utzen ({\VAS} ~\ref{java}). Andererseits wird bereits an einer persistenten Variante von {\java} dem sogenannten {\pjava} gearbeitet ({\VAS}~\ref{pjava}).

Neben Werkzeugen zur automatischen Generierung von Information m"ussen auch f"ur den nicht mit Programmiersprachen und Datenbanken bzw. Datenbankprogrammiersprachen vertrauten Anwender Hilfsmittel zur Verf"ugung stehen, die es diesem erm"oglichen, seine Information auf herk"ommlichem Wege, d.h. in diesem Fall mit Hilfe von statischen {\html} Seiten f"ur das WWW aufzubereiten. Beispiele f"ur solche Werkzeuge sind z.B. WYSIWYG\footnote{engl. {\em What You See Is What You Get}}-Editoren, mit denen {\html} Seiten ohne das Schreiben von {\html} Befehlen interaktiv gestaltet werden k"onnen. 

Desweiteren sind Konverter notwendig, die in anderen Formaten vorliegende Information in das {\html} Format des {\www} umwandeln, da der Benutzer in der Regel nicht gewillt ist auf seine ihm bekannten Werkzeuge wie z.B. {\ms} {\word} oder {\latex} zu verzichten und sich in neue Werkzeuge wie z.B. HTML Editoren einzuarbeiten.


\subsection*{Anforderungen:}
\begin{description}
\item [Konzepte zur Wiederverwendung vorhandener Information:] Information kann in vielerlei Formaten und Strukturen vorliegen. So gibt es unterschiedliche Formate zur Speicherung textueller, grafischer, auditiver und bildhafter Information.  

Daten aus Datenbanken und anderen Formaten
\item [Werkzeuge zur interaktiven Erstellung von Information:]
\item [Konverter:]
\end{description} 

In verteilten heterogenen Informationssystemen ist es wichtig, da"s das Format der erstellten Information von der Rechnerplattform und dem verwendeten Betriebssystem unabh"angig ist, damit sie auf beliebigen Plattformen ohne Konvertierungen, die in der Regel zu Zeitverlusten und Kosten f"uhren, verwendet werden kann.

\section{Speicherung von Information}
\label{speich}
Die Speicherung von Information kann im Zusammenhang mit dem {\www} einerseits in Dateien im {\html}-Format erfolgen und andererseits in Datenbanken aus denen dann bei Abruf {\html}-Seiten generiert werden. Da eine effiziente Speicherung von Information in Dateien nicht ohne weiteres m"oglich ist, "ubernehmen Datenbanken diese Aufgabe. Hierbei ergeben sich Anforderungen, wie z.B. die Vermeidung von Redundanz ({\VAS}~\ref{redundanz}) oder die Versionierung von Daten ({\VAS}~\ref{versionierung}). 

\subsection{Vermeidung von Redundanz}
\label{redundanz}
Man spricht von Redundanz, wenn das gleiche Objekt mehrfach in einer Datensammlung vorkommt. Dies kann zu einem inkonsistenten Zustand der Datensammlung f"uhren, wenn "Anderungen an einem der mehrfach vorhandenen Objekte durchgef"uhrt werden und die nicht ge"anderten Objekte trotzdem referenziert werden. Das Problem der Redundanz in Informationssystemen l"a"st sich auf die Nichteinhaltung von Integrit"atsbedingungen zur"uckf"uhren. Integrit"atsbedingungen sollen u.a. das mehrfache Auftreten des gleichen Objektes in einer Datensammlung verhindern, jedes Objekt mu"s also eindeutig identifizierbar sein. In relationalen Datenbanken wird dies durch die Einf"uhrung von Schl"usselattributen erreicht. Formal ausgedr"uckt bedeutet die Definition eines Schl"ussels, bestehend aus einer Liste von Attributen  $<$ ..., ki, ...$>$, da"s nur diejenigen Werte einer Relation rel legal sind, die folgende Bedingung erf"ullen:
\begin{center}
\k{all} r, s \k{in} rel (($<$ ..., r.ki, ...$>$ = $<$ ..., s.ki, ...$> \Rightarrow$ (r = s)).
\end{center}
Aus der Wertgleichheit eines Paares von Relationenelementen r, s folgt mit Hilfe der Men\-gen\-eigen\-schaft von rel, da"s es sich bei r und s um dasselbe Element handeln mu"s \cite{Lo87}.

{\ty} erreicht die Vermeidung redundanter Deklarationen f"ur "`identische"' semantische Objekte in verschiedenen Werkzeugen durch eine Vereinheitlichung der Benennungsmechanismen von semantischen Ojekten, wie etwa Attributen, Relationen, Datenbanken, Sichten, Programmvariablen, Funktionen, etc. So werden z.B. strukturelle Typinformationen im Datenbankschema, bei der Definition von Programmvariablen, bei der Beschreibung von Bildschirmmasken oder bei der Protokolldefinition in Rechnernetzen ben"otigt.

In persistenten Objeksystemen und dort im Objektspeicher wird die Eindeutigkeit von Objekten mit Hilfe von abstrakten Objektspeicherreferenzen (OID) garantiert \cite{MMS95c}. Zur Sicherung der referentiellen Integrit"at des Objektspeichers d"urfen Klienten des Objektspeichers den Speicherplatz nicht mehr ben"otigter Speicherobjekte nicht explizit freigeben. Der Objektspeicher ist selbst f"ur das L"oschen nicht mehr erreichbarer Objekte verantwortlich. Bei der Freispeicherverwaltung (engl. {\em garbage connection}), werden alle nicht mehr von einem ausgezeichneten Wurzelobjekt transitiv erreichbaren Objekte gel"oscht ({\VAS}~\ref{vertObjektspeicher}).

\subsubsection*{Anforderungen:}
\begin{itemize}
\item M"oglichkeit zur Definition von Integrit"atsbedingungen 
\item Werkzeuge zur automatischen "Uberwachung von Integrit"atsbedingungen
\end{itemize} 


\subsection{Versionierung}
\label{versionierung}
Unter Versionierung versteht man die F"ahigkeit von Datenbank Management Systemen (DBMS) zur Erzeugung, Administration und Pflege verschiedener Versionen von individuellen Dateneintr"agen oder Objekten "uber einen l"angeren Zeitraum \cite{C*93}. 

In traditionellen Datenbanksystemen wird vor dem Benutzer verborgene Versionierung genutzt, um die Effizienz von Transaktionssynchronisationsmechanismen zu steigern. Die Anforderungen an moderne Datenbanksysteme enthalten allerdings die explizite Offenlegung der Versionierung f"ur den Benutzer. So ist es in Datenbanken oft von Nutzen, die Historie von Daten nachvollziehen zu k"onnen, wie z.B. "Anderungen an Vertr"agen oder Laufbahnen von Mitarbeitern in Organisationen. Versionierungskonzepte sind immer notwendig, wenn mehrere Personen an dem gleichen Objekt arbeiten, dies ist insbesondere in CAD\footnote{engl. {\em Computer Aided Design}}- und CASE\footnote{engl. {\em Computer Aided Software Engineering}}-Umgebungen der Fall.

Auch im {\www} ist die Versionierung von Daten und Objekten eine offene Frage. 
F"ur die Visualierung von Historien von Daten wie z.B. der verschiedenen Standards von {\html}, wo es angebracht w"are auf Server-Seite {\oo}e Vererbungsmechanismen zu nutzen - {\html} 1.0 vererbt seine Eigenschaften an {\html} 2.0 und wird um neue F"ahigkeiten erweitert - reichen die Konzepte von {\html} nicht aus ({\VAS} ~\ref{html}). So entstehen redundante Datens"atze, die nicht nur die Gefahr von Inkonsistenzen mitsichbringen sondern auch f"ur unn"otigen Speicherplatzverbrauch sorgen. Einen interessanten Ansatz bietet hier {\lin} ({\VAS} ~\ref{lincks}), eine {\www}-Benutzerschnittstelle f"ur ein {\oo}es Datenbank Management System (DBMS).

Im Zusammenhang mit der kollaborativen Arbeit an Projekten wie z.B. dem Editieren von {\www}-Seiten oder verteilter Softwareentwicklung versuchen andere Ans"atze das Problem der Versionierung f"ur statische {\html}-Dokumente zu l"osen, indem sie z.B. das {\http}-Protokoll um neue Methoden zur Versionsverwaltung und zur Unterst"utzung gemeinsamer Arbeit an Objekten erweitern (\cite{W96}) oder eine neue Beschreibungssprache {\vtml} (engl. {\em Versioned Text Markup Language}, {\VAS}~\ref{htmlErweiterung})  als Erweiterung von {\html} definieren \cite{VD95}.

Verschiedene Versionen der auf der Client-Seite benutzten {\em browser} f"uhren zu Informationsverf"alschungen bzw. sogar zu Informationsverlusten. Komplizierter wird es, wenn mit Hilfe von {\java} Applikationen "uber das Internet bzw. Intranet "ubertragen werden. Hier m"u"ste vor der "Ubertragung einer neuen Version einer Anwendung, zuerst die bereits vorhandene Version auf Kompatibilt"at zur neuen "uberpr"uft werden. Dies erfordert allerdings einen Zugang zum lokalen Dateisystem des updatewilligen Benutzers, was aus Sicherheitsgr"unden ({\VAS}~\ref{sicherheit}) in {\java} nicht erlaubt ist.

\subsubsection*{Anforderungen:}
\begin{itemize}
\item Unterst"utzung kooperativer Arbeit an beliebigen Objekten ({\em lost update} Problem)
\item Bewahrung der Konsistenz von Verweisen (im {\www}-Zusammenhang), indem Verweise immer auf die "`richtige"' Version eines Objektes zeigen
\item M"oglichkeit zur Definition der Verantwortlichkeit f"ur verschiedene Versionen eines Objektes
\item Mechanismen zur "Uberpr"ufung vorhandener Versionen von Software 
\end{itemize} 

\section{Wartung von Information}
\label{wart}
Zwischen der Wartung von Software und der Wartung von Information besteht ein gravierender Unterschied, da ein Softwareprodukt nicht verschleist und daher wie ein Auto oder ein Fernseher "`gewartet"' werden mu"s. Wartung in Bezug auf Software meint einerseits die Folgen der "Anderung von Systemspezifikationen und andererseits die Beseitigung von Fehlern, die von vornherein nicht h"atten vorhanden sein d"urfen \cite{M90}.

Information bildet einen zu einem konkreten Zeitpunkt vorhandenen Wissensstand ab. Damit Information nicht veraltet bzw. ungenau oder falsch wird, mu"s sie wie andere Dinge, die st"andigen Ver"anderungen unterliegen, gewartet werden. Ein wichtiges Konzept zur Wartung von Information ist das der Versionierung, das bereits in Abschnitt ~\ref{versionierung} behandelt wurde.  Weitere wichtige Konzepte werden im Folgenden vorgestellt.

\subsection{Konsistenz und Integrit"at}
\label{konsistenz}
In der Literatur wird zwischen der Konsistenz bzw. Integrit"at von {\em Systemen} und der von den in den Systemen gespeicherten {\em Daten} unterschieden.

\subsubsection*{Integrit"at von Systemen}
\label{integSystem}
\cite{M90} versteht unter Integrit"at "`die F"ahigkeit eines Softwaresystems, seine verschiedenen Komponenten (Programme, Daten, Dokumente) gegen unberechtigte Zugriffe und Ver"anderungen zu sch"utzen"'. Diese F"ahigkeit ist im {\www} insofern gegeben, als da"s einerseits Passwort- und Verschl"usselungsmechanismen existieren und andererseits in der Regel nur lesender Zugriff auf Programme, Daten und Dokumente gew"ahrt wird. Die o.g. Definition ist eher im Bereich der Sicherheit von Softwaresystemen einzuordnen und wird daher in Abschnitt ~\ref{sicherheit} n"aher untersucht.

\subsubsection*{Konsistenz von Daten}
\label{integDaten}
Die Korrektheit der in einem Datenverwaltungssystem gespeicherten Daten bezeichnet man als deren Konsistenz oder Integrit"at. Konsistenregeln bzw. Integrit"atsbedingungen definieren einen korrekten Datenzustand bzw. eine korrekte Datenzustandsver"anderung \cite{Ja90}. Hierzu z"ahlt u.a. das bereits in Abschnitt ~\ref{redundanz} untersuchte Problem der Redundanzfreiheit von Informationssystemen.

Das Problem der Konsistenz von Information findet man im {\www} an mehreren Stellen wieder: 

\begin{description}
\item[mangelnde Aktualit"at:]
Die mangelnde Aktualitk"at von Information im {\www} beruht meist darauf, da"s sie in statischer Form vorliegen und nicht automatisch mit anderen in Organisationen vorhandenen Informationssystemen (z.B. Datenbanken) abgeglichen werden. Angenommen eine Organisation stellt sich und seine Mitarbeiter im {\www} dar. Dann erfordert jede "Anderung an der Personaldatenbank der Organisation (z.B. Ausscheiden eines Mitarbeiters) eine "Anderung der entsprechenden {\html}-Seiten, damit ein konsistenter Zustand herrscht. Dieses Problem kann umgangen werden, indem zum Abfragezeitpunkt der {\html}-Seite automatisch aus den relevanten Mitarbeiterdaten entsprechende {\html}-Seiten generiert werden. Diese M"oglichkeit erfordert nat"urlich ein hohes Ma"s an Sicherheitsvorkehrungen, die den unerlaubten Zugriff auf Daten verhindern \cite{Li96}.  

\item[ung"ultige Verweise:] Das Problem der ung"ultigen Verweise ({\em Hyperlinks}) auf andere lokale oder externe {\www}-Seiten kann zwei Ursachen haben. Zum einen ist es m"oglich, da"s die referenzierte Seite umbenannt wurde, andererseits existiert sie vieleicht nicht (mehr). Hier sind Werkzeuge wie z.B. {\ms} {\fp} n"otig, die automatisch in {\html}-Seiten vorhandene lokale und externe Hyperlinks auf ihre G"ultigkeit pr"ufen. Dieses Vorgehen ist mit "Uberpr"ufungen der referentiellen Integrit"at in relationalen Datenbanksystemen vergleichbar. 
\end{description}

\subsubsection*{Anforderungen:}
\begin{itemize}
\item M"oglichkeit zur Definition von Integrit"atsbedingungen 
\item Werkzeuge zur automatischen "Uberwachung von Integrit"atsbedingungen bei Datenzustandsver"anderungen (Einf"ugen, "Andern, L"oschen)
\end{itemize}

 
\subsection{Lokalit"at}
\label{lokalitaet}
Optimale Lokalit"at liegt vor, wenn zur L"osung eines Problems alle ben"otigten Informationen auf einer Seite zu finden sind. Das bedeutet andererseits, da"s nicht ben"otigte Informationen nicht vorhanden sind \cite{B82}. Diese Definition ist im Kontext der modularen Softwareentwicklung zu sehen. Die Beachtung dieses Prinzips erm"oglicht die schnelle Einarbeitung, f"ordert die Verst"andlichkeit und Lesbarkeit und erleichtert die Wartung von Software.

Ein gro"ser Vorteil von Hypermediasystemen wie dem {\www} ist die einfache Vernetzbarkeit und M"oglichkeit der Strukturierung von Information mittels Verweisen (engl. {\em Hyperlinks}). Durch sie kann dem Informationssuchenden wichtige zus"atzliche Information unmittelbar zur Verf"ugung gestellt werden. Dabei ist es unwichtig, ob diese Information auf dem gleichen Rechner wie das urspr"ungliche Dokument liegt oder auf einem weit entfernten Rechner. Der Sinn und Zweck des {\www} ist es, Information aus allen Teilen der Welt f"ur den Informationssuchenden transparent zug"anglich zu machen. Das Prinzip der Lokalit"at von Information gilt im {\www} also offenbar nicht. Dennoch ist die Strukturierung der Information auf einer {\html}-Seite notwendig, da bei "uberm"a"siger Nutzung von Hyperlinks schnell die eigentliche Information aus dem Blickfeld ger"at und dem Informationssuchenden das sogenannte {\em lost in Hyperspace}-Syndrom droht. Das Konzept der direkten Vernetzung von Infor\-ma\-tion mittels Verweisen ist auch f"ur Programmierumgebungen von gro"sem Nutzen. So lassen sich z.B. Hyperlinks sehr gut f"ur die Dokumentation von Import- und Export-Beziehungen zwischen verschiedenen Modulen, Vererbungsbeziehungen zwischen Klassen oder auch Typ\-hierar\-chien nutzen. Als Beispiel ist hier die Dokumentation des {\java}-API zu nennen, die automatisch aus dem Quellcode der {\java}-Klassenbibliotheken generiert wird \cite{F95} und im {\www} zur Verf"ugung steht \cite{JaAPI}.

\section{Pr"asentation von Information}
\label{praes}
Die ansprechende und transparente Pr"asentation von Information in Form von formatiertem Text, Tabellen, Grafiken oder Audio- und Video-Pr"asentationen ist mittlerweile in nahezu allen Organisationen ein Mu"s. Dank der immer schnelleren Hardware sind diese Pr"asentationsformen auch auf Rechnern m"oglich. Hier gilt es jedoch insbesondere in verteilten Informationssystemen die zu "ubertragenden Datenmengen gering zu halten und andererseits die Information mit den geeigneten Mitteln ansprechend zu pr"asentieren. Aufgrund der oft hohen Datenlast von WAN`s\footnote{engl. {\em Wide Area Network}} ist eine Skalierbarkeit der Pr"asentation w"unschenswert ({\VAS} ~\ref{skalierbarkeit}).

\cite{F95} stellt in ihrem Artikel die Anforderungen an ein {\www}-In\-formations\-system f"ur die Dokumenation der {\java}-Anwendungsprogrammierschnittstelle in diesem Zusammenhang wie folgt dar:
\begin {itemize}
\item Gute Lesbarkeit am Monitor
\item Benutzerunterst"utzung f"ur Navigation, Suche und Bl"attern (engl. {\em browsing})
\item Reflexion des Informationsinhaltes auf die Informationsstruktur
\item Ansprechende Benutzerschnittstelle
\end {itemize}

Da es sich aufgrund der {\oo}en Struktur des API um auf vielf"altige Art miteinander verkn"upfte Textdokumente handelt, wird der Benutzer die Dokumentation in der Regel nicht ausdrucken wollen, sondern die Nutzung von Verweisen im {\www} bevorzugen. Daher steht die gute Lesbarkeit am Monitor als prim"are Anforderung im Vordergrund. Um die {\oo}e Struktur des API inkl. aller Super- und Subklassenbeziehungen f"ur den Leser nachvollziehbar zu machen, werden ihm Werkzeuge zur Navigation, Suche und zum Bl"attern in den Textdokumenten zur Verf"ugung gestellt. 


\subsection*{Anforderungen}
\begin{itemize}
\item Reflexion des Informationsinhaltes auf die Informationsstruktur
\item Ansprechende Benutzerschnittstelle inkl. guter Lesbarkeit am Monitor
\item Skalierbarkeit der Pr"asentation 
\end{itemize}

\section{Verteilung von Information}
\label{verteil}
Die heterogene Verteilung von Information ist in Organisationen die Regel. (Infor\-ma\-ti\-ons-)Hierarchien werden abgebaut und Information dort vorgehalten, wo sie anfallen. Verteilte Informationssysteme haben die Aufgabe heterogene Datenbest"ande zusammenzuf"uhren bzw. f"ur den Informationsuchenden zug"anglich zu machen. Informationssysteme verwalten heute nicht mehr nur Daten und Information an sich, sondern auch Prozesse, die mit Daten arbeiten, sie verwalten und automatisieren. Von zunehmender Bedeutung sind hier {\em Gesch"aftsprozesse}, die Unternehmensaktivit"aten darstellen, welche zur Erf"ullung vertraglicher Vereinbarungen oder zur Befriedigung von Kundenw"unschen entworfen werden. Diese Gesch"aftsprozesse m"ussen in vielen F"allen auf die im Unternehmen vorhandenen Informationsbest"ande (z.B. Kunden-, Bestell- und Lieferdaten) zugreifen und werden deshalb in ein bestehendes IS integriert. Das Paradigma der Integration von Gesch"afts- und Informationsprozessen ist das des {\em Workflow-Management} \cite{Vo95}. Sowohl die heterogene Verteilung von Information als auch die Integration von Gesch"afts- und Informationsprozessen f"uhrt zu neuen Anforderungen an verteilte Informationssysteme wie z.B. Migration ({\VAS} ~\ref{migration}) und Funktionen h"oherer Ordnung ({\VAS} ~\ref{hof}).

\subsection{Skalierbarkeit}
\label{skalierbarkeit}

Zur Unterst"utzung computergest"utzter kooperativer Arbeit (CSCW) in Echtzeit werden 
einerseits eine garantierte Bandbreite und andererseits die minimale Verz"ogerung der 
"ubertragenen Daten ben"otigt \cite{EG96}. Diese Anforderungen erf"ullt das Internet bzw. das {\www} 
derzeit nicht. Es gibt hierzu folgende Ans"atze:

\begin {description}
\item [Internet Protokoll V6:] Die Internet Engineering Task Force (IETF) hat das {\em Internet Protokoll Version 6} (Ipv6) entwickelt, um eine effizientere Adressierung, schnellere Verteilungsmechanismen, Multimediaverbesserungen und eine h"ohere Netzsicherheit zu erreichen. IPv6 erm"oglicht die Priorisierung von Datenstr"omen. So kann z.B. ein Videodatenstrom in mehrere Kan"ale aufgeteilt werden, die eine fortschreitend h"ohere Bildsch"arfe haben. Treten Verz"ogerungen auf, wird die "Ubertragung der Kan"ale mit h"oherer Bildsch"arfe ausgesetzt, damit die Bandbreitenanforderungen reduziert und so die "Ubertragung von schlechter aufgel"osten Bildern zum Empf"anger erreicht werden kann.
\item [Reservation Setup Protocol:] Das {\em Reservation Setup Protocol} (RSVP) setzt auf dem IP Protokoll auf und wird ebenfalls von der IETF entwickelt. RSVP zielt auf die vom Empf"anger initiierte Zuweisung von Ressourcen. Der Empf"anger kann eine Bandbreite f"ur eine Verbindung reservieren und so eine leitungsvermittelte Verbindung simulieren. Er erreicht dadurch eine h"ohere Qualit"at des Dienstes (engl. {\em Qualtity of Service}, QoS) f"ur seine Datenstr"ome. Erfordert z.B. eine Anwendung einen spezifischen QoS, wird RSVP benutzt, um diese Anforderung an jeden Vermittlungsrechner entlang des "Ubertragungsweges weiterzugeben.
\end {description}

Das Ziel dieser beiden Protokolle sind adaptive Anwendungen. Das Institut National de Recherche en Informatique et en Automatique (INRIA) hat basierend auf IETF's Realtime Protocol (RTP), das die adaptive Codierung von Audio- und Video-Information mittels variabler Datenkompressionsalgorithmen spezifiziert, ein Internet-Video-Konferenz-System (IVCS) entwickelt, das die Menge der "ubertragenen Daten bei hoher Netzbelastung reduziert. Dies resultiert in einer schlechteren "Ubertragungsqualit"at (Durchsatzadaption) oder in einer reduzierten Bildrate (Verz"ogerungsadaption). Der Sender ermittelt mittels {\em polling} die Qualit"at des Empfangs beim Empf"anger, berechnet die vorhandene Bandbreite und passt dementsprechend die Kompressionsrate an ({\VAB} ~\ref{adaptapp}).

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{Bilder/anfinformation/adaptapp.eps}
\end{center}
\caption{Adaptive Anwendungen k"onnen ihren QoS den gegebenen Netzwerkbedingungen anpassen}
\label{adaptapp}
\end{figure}


\subsection{Plattformunabh"angigkeit und Kompatibilt"at}
\label{plattform}
Unter Kompatibilit"at versteht \cite{M90} "`das Ma"s der Leichtigkeit, mit der Softwareprodukte mit anderen verbunden werden k"onnen"'. Das {\www} bietet mit dem {\em Common Gateway Interface} (CGI) eine Schnittstelle, die den Aufruf beliebiger Programme erm"oglicht und so dynamisch generierte Information erzeugen kann ({\VAS}~\ref{worldwideweb}). Die {\oo}, plattformunabh"angige Programmiersprache {\java}, die mittlerweile von allen wichtigen {\brow} unterst"utzt wird, wird mit der in absehbarer Zeit vorhandenen {\em Java Database Connectivity} (JDBC) eine direkte Kommunikation zwischen Client und Datenbanken - ohne den "`Umweg"' "uber den {\http}-Server - erlauben.  

\subsection{Migration}
\label{migration}
Aktivit"aten mit langen Laufzeiten wie z.B. Gesch"aftsprozesse in Unternehmen werden h"aufig von mehreren Mitarbeitern bearbeitet. Solche Gesch"aftsprozesse ben"otigen verschiedene Daten- und Informationsquellen und werden aus diesem Grund innerhalb eines Unternehmens mehrfach weitergegeben. Das Ziel von {\em Workflow-Management-Systemen} ist es, die Weitergabe und Bearbeitung von Gesch"aftsprozessen automatisch zu steuern, um so die Durchlaufzeit eines zu bearbeitenden Objektes zu optimieren und die bei manueller Weitergabe des Objektes  - z.B. in Form von Akten - auftretenden Liegezeiten zu vermeiden. Hierzu ist es n"otig, da"s ein Objekt {\em migriert}, d.h seinen Ort wechselt. Der jedem Objekt eigene Bearbeitungsstatus mu"s dabei persistent gespeichert werden, da ein Objekt durchaus einige Zeit inaktiv sein kann, z.B. wenn zur Bearbeitung n"otige Informationen fehlen. Da die Internet-Technologie u.a.  intern in Organisationen im Rahmen eines Intranet eingesetzt wird, kommt dem Konzept der Migration von Gesch"aftsprozessen in diesem Rahmen eine zunehmende Bedeutung zu. Ein weiteres innovatives Szenario der Migration von Objekten sind Agentensysteme, in denen autonome Softwareagenten das Internet bereisen, um jeweils vor Ort im Auftrag ihres Benutzers Handlungen unterschiedlichster Art durchzuf"uhren \cite{Ma96}.

Mit dem Ziel langlebige, verteilte und kooperierende Aktivit"aten zu unterst"utzen wurde im Rahmen des {\ty}-Projektes das Konzept der (migrierenden) {\em Threads} untersucht. {\em Threads} sind einerseits Aktivit"aten die erzeugt, ausgef"uhrt, synchronisiert, unterbrochen und beendet werden k"onnen und andererseits passive Daten, die persistent gespeichert, mit Attributen versehen, mit anderen persistenten Datenstrukturen assoziiert, zwischen heterogenen Netzwerkknoten verschickt und durch Berechnungen manipuliert werden k"onnen \cite{MaSc94}.

Ein Thread beschreibt einen einfachen sequentiellen Kontrollflu"s in einem Programm. Gibt es mehrere Threads in einem Programm, bedeutet das, da"s das Programm zu jedem Zeitpunkt mehrere Ausf"uhrungspunkte hat und zwar genau einen in jedem seiner Threads. Mehrere Threads werden im Gegensatz zu Betriebssystemprozessen in einem gemeinsamen Adre"sraum ausgef"uhrt und k"onnen auf gemeinsame Ressourcen zugreifen. Im Gegensatz zum traditionellen Thread-Konzept bieten Threads (genau wie Daten und Code) in {\ty} \cite{MMS95a}:

\begin{itemize}
\item Unabh"angigkeit von der Lebensdauer des sie umschlie"senden Betriebssystemprozesses; 
\item Mobilti"at, d.h. die F"ahigkeit ihren (persistenten) Adre"sraum zu wechseln.
\end{itemize}

F"ur verteilte Informationssysteme stellen migrierende persistente Threads ein Konzept zur Verf"ugung, das die Modellierung und Implementation von verteilten Workflow-An\-wendung\-en erlaubt. Die Threads erstrecken sich dabei "uber mehrere Netzwerkknoten und voneinander unabh"angige Datenbanken.

In Abbildung ~\ref{mtspesen} ist ein Workflow am Beispiel einer verteilten Bearbeitung einer Reisekostenabrechnung dargestellt \cite{Ma96}. Nachdem auf dem Rechner eines Angestellten ein Spesenbereicht eingegeben wurde, migriert die Aktivit"at zum Arbeitsplatzrechner einer Sekret"arin, die anhand der informellen Angaben des Spesenberichtes eine formal korrekte Reisekostenabrechnung erstellt. Nach einer weiteren Aktivit"atsmigration begutachtet der Gruppenleiter die Reisekostenabrechnung und entscheidet (in diesem Fall positiv) "uber ihre Zul"assigkeit. Schlie"slich erfolgen in der Buchhaltung die anfallenden finanziellen Transaktionen.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{/usr/users/boesch/Diplomarbeit/Latex/Bilder/anfinformation/mtspesen.ps}
\end{center}
\caption{Modellierung eines Reisekosten-Workflows durch einen migrierenden Thread}
\label{mtspesen}
\end{figure}

Die in dem nachstehend aufgelisteten {\tl}-Skript dieses Threads verwendete Notation \k{migrate to \ldots\  do} ist reiner
"`syntaktischer Zucker"', der mit Hilfe von Tycoons erweiterbarer Syntax
\cite{CMA94} realisiert ist. 

\begin{xple}
\k{let} \k{var} spesenBericht = dummy
\k{repeat}
   \k{migrate to} angestellter \k{do}    
      \k{let} spesenBericht = erfasseBenutzerDaten()     
      \k{migrate to} sekretaerin \k{do}
         abrechnung := verfasseAbrechnung(spesenBericht)
      \k{end}
   \k{end}
\k{until} formalKorrekt(abrechnung)
\k{migrate to} gruppenLeiter \k{with remote} budgetDB :BudgetDB \k{do}
   ueberpruefe(budgetDB  abrechnung.summe)
\k{end}
\k{migrate to} buchhaltung \k{do}
   ueberweise(abrechnung.summe)
\k{end}
\end{xple}

Im Kontext des {\www} findet man das Konzept der Migration von Objekten in Form von sogenannten {\em Agenten} wieder. Die Basis f"ur Suchmaschienen wie z.B. {\lyc} oder {\av} sind Sofwareroboter, die selbstst"andig das {\www} nach neuen {\html}-Seiten durchsuchen, diese nach bestimmten Stichw"ortern analysieren und anhand von Themen katalogisieren. Diese Metainformationsdatenbanken sind dann f"ur den Benutzer "uber ein {\html}-Formular abfragbar. Die f"ur eine individuelle Anfrage automatisch generierten Suchergebnisse enthalten dann Hyperlinks auf die gesuchte Information.


\subsection{Funktionen h"oherer Ordnung}
\label{hof}
Funktionen h"oherer Ordnung sind solche, die Funktionen auch als Argumente akzeptieren und/oder als Ergebnisse liefern. Man spricht deshalb auch von Funktionen als gleichberechtigten Werten (engl. {\em first class values}) \cite{Matt93}.

\subsection{Sicherheit}
\label{sicherheit}
Systemsicherheitsdienste wie Authentifizierung, Zugangskontrolle und die Aufzeichnung von Benutzerinteraktionen (engl. {\em auditing}) werden zunehmend wichtiger f"ur Informationssysteme (IS), insbesondere in verteilten heterogenen Umgebungen \cite{RMS95}. Der Bedarf an einer st"andig wachsenden Anzahl unterschiedlichster Dienste in IS wie z.B. Massendatenspeicherung, Datenpersistenz, Transaktionen, Netzwerkkommunikation oder fensterbasierte Datenvisualisierung erfordert die Verlagerung solcher Dienste in generische Bibliotheken. Diese erm"oglichen die sichere Nutzung und Kombination solcher Dienste.

\subsection{verteilte Objektspeicher}
\label{vertObjektspeicher}

In persistenten Objeksystemen und dort im Objektspeicher wird die Eindeutigkeit von Objekten mit Hilfe von abstrakten Objektspeicherreferenzen (OID) garantiert \cite{MMS95c}. Zur Sicherung der referentiellen Integrit"at des Objektspeichers d"urfen Klienten des Objektspeichers den Speicherplatz nicht mehr ben"otigter Speicherobjekte nicht explizit freigeben. Der Objektspeicher ist selbst f"ur das L"oschen nicht mehr erreichbarer Objekte verantwortlich. Angenommen man betrachtet HTML-Seiten als Objekte eines persistenten Objektsystems und die URLs als Objektreferenzen (OIDs). Das Objektsystem f"uhrt eine Freispeicherverwaltung (garbage collection) durch, d.h. alle nicht mehr von einem ausgezeichneten Wurzelobjekt (root) transitiv erreichbaren Objekte werden gel"oscht. Das k"onnte bei HTML-Seiten auf einem Server auch durchgef"uhrt werden. Hierbei treten allerdings vielf"altige Probleme auf:

\begin{itemize}
\item Was passiert mit Seiten, die gerade "'in Bearbeitung"' sind und daher
nicht zugreifbar sind? Beim Objektsystem (vgl. TSP) gibt es einen
Enumerator, der solche Seiten aufz"ahlt, die dann quasi als
zus"atzliche Wurzelobjekte behandelt werden (mit allen transitiven
Ab\-h"angig\-kei\-ten).
\item Was passiert mit Seiten, die nicht (mehr) innerhalb des Servers,
sondern (nur noch) von au"sen referenziert werden? Das ist auch bei
persistenten Objektsystemen (jedenfalls in Tycoon) ein offenes Problem (Stichwort: {\em network references}). L"osungen: Alle die Seiten, die von au"sen referenziert werden, auch durch einen Enumerator aufz"ahlen, sprich:
extern verwalten. Aber: Wann d"urfen diese Seiten dann je gel"oscht
werden? L"osung im WWW: G"ultigkeitszeiten (expire). (Das fehlt in
Tycoon! K"onnen wir noch was vom WWW lernen.) Und: Verweisseiten, auf
denen nur noch steht: "'Diese Seite existiert nicht mehr."' und evtl.:
"'Die neue URL lautet ..."'. Auch dieses Konzept lie"se sich in die Verwaltung extern referenzierter Objekte des POS integrieren.
\end{itemize}

Generell: Was gibt es bei verteilten Objektspeichern fuer
Basistechnologien und -pro\-blem\-l"o\-sungen?



\subsection{Ressourcenabh"angigkeit}
\label{sec. rc}

Tycoon Programme h"angen von externen Ressourcen und den Eigenschaften
der Tycoon Maschine bzw. des TSP ab.  Ein prinzipiell korrektes Tycoon
Programm l"auft evtl. auf einem anderen Rechner oder sogar dem gleichen
Rechner, aber mit anders konfigurierter Tycoon Maschine, nicht.

Wenn wir den WWW-Browser als abstrakte Maschine betrachten, die
({\html}-)Dokumente interpretiert, kann "ahnliches passieren: Der Browser
kann (auf der Maschine, in der Konfiguration) bestimmte Dokumente (oder
Teile davon, z.B. Bilder) nicht darstellen. Was sind dort die
L"osungen? L"a"st sich dies auf Tycoon "ubertragen? (Tycoon st"urzt
einfach ab.)



 

%\begin{figure}[hbt]
%\begin{center}
%\leavevmode
%\epsfxsize=13cm \epsfysize=5cm
%\epsffile{/usr/users/boesch/Diplomarbeit/Latex/Bilder/}
%\end{center}
%\caption{bla}
%\label{VB1}
%\end{figure}



