% PARTOF texte:da/tex/a_home.tex

% /// chapter Kooperierende Informationssysteme
%------------------------------------------------------------------------------

\chapter{Kooperierende Informationssysteme}
\label{koopis}

Rechnergest"utzte Informationssysteme haben sich heute in vielen
Anwendungsbereichen etabliert. Mittels dieser Systeme ist eine extrem gro"se
Menge an unterschiedlichsten Informationen zug"anglich, die weltweit von
unz"ahligen Firmen, Institutionen und Privatpersonen aus den verschiedensten
Gr"unden gesammelt, verwaltet und angeboten wird.

Dieses Kapitel gibt eine "Ubersicht "uber die Aspekte der Verteilung und
"uber existierende Ans"atze zur Verwaltung autonomer, heterogener
Informationsbest"ande.

Im Abschnitt \ref{offeneDienstnutzungsumbegungen} wird das Konzept der
``offenen Dienstnutzungsumgebung'' eingef"uhrt. Die aus diesem Teil motivierten
Begriffe {\em Kooperation} und {\em Autonomie} werden dann im Abschnitt
\ref{KooperationUndAutonomie} n"aher betrachtet.

\section{Verteilte Anwendungen}
\label{verteilte-anwendungen}
Eine {\em verteilte Anwendung} setzt sich aus einer Menge von kommunizierenden
Komponenten zusammen, die keinen gemeinsamen Adressraum voraussetzen und auf
verschiedenen Rechnern verteilt sein k"onnen \cite{Schi90}. Dabei st"utzt sich
die verteilte Anwendung auf ein {\em verteiltes System}, das auf der Basis einer
physikalischen Rechnerkopplung diese Kommunikation erm"oglicht
(Abb.\ref{Rechnerkplg}). Es ist dabei nicht relevant, ob diese Kopplung direkt
"uber ein lokales Netzwerk existiert oder ob sie mittels zwischengeschalteter
Transitsysteme verschiedene Netze einbezieht.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/rechkopp.eps}}
\caption{Kopplung von Rechnern zu einem verteilten System}
\label{Rechnerkplg}
\end{figure}

Bis Ende der 80er Jahre, mit dem Aufkommen der glasfasergest"utzten
Breitbanddaten"ubertragung und der daf"ur notwendigen schnellen
Vermittlungstechniken, wurden verteilte Anwendungen f"ur lokale Netzwerke
realisiert (Beispiel: Drucker-Server). Dies wurde durch die geringe
Zuverl"assigkeit und die ebenfalls geringe "Ubertragungsbandbreite der Orts-
und Weitverkehrsnetze erzwungen. Dadurch war der m"ogliche Nutzen der
Verteilung auf die optimierte Auslastung lokal vorhandener Ressourcen wie
Prozessor, Haupt- und Sekund"arspeicher oder Drucker beschr"ankt.

Heute sind insbesondere durch das Internet viele lokale Netzwerke in globale
Netze integriert. Dabei erreicht die "Ubertragungsleistung "uber die Netzgrenzen
hinaus oft schon die Leistung, die innerhalb des lokalen Netzes verf"ugbar
ist\footnote{Es ist zu erwarten, da"s sich diese Angleichung von
Leistungsmerkmalen auch in der Zukunft fortsetzt\cite{Tsch94}.}.

Neben den permanenten Netzverbindungen, die in der Regel auch "ortlich
gebunden sind, gibt es in j"ungster Zeit einen Trend, Endbenutzer im privaten
Bereich den Zugang zu globalen Netzen zu erm"oglichen. Dieser Zugang
zu "offentlichen Netzen geschieht mittels der vorhandenen
Telekommunikationsinfrastruktur "uber sogenannte {\em Provider}. Provider
bieten als Dienst ihren permanenten Netzzugang Endbenutzern zur freien
Verwendung an. Die Endbenutzer werden dann zeitweilig (f"ur die Dauer der
Verbindung zu ihrem Provider) Teil des globalen Netzes. Die den Endbenutzern
zur Verf"ugung stehende Netzbandbreite ist nur ein Teil der dem Provider zur
Verf"ugung stehenden Bandbreite, daf"ur jedoch hat eine Vielzahl von
Endbenutzern gleichzeitig "uber einen Provider Zugang zum globalen Netz.

Durch den Ausbau der Telekommunikationsinfrastruktur auf Glasfaserbasis ist es
in naher Zukunft f"ur eine breite Anwenderschicht m"oglich, mittels ISDN eine
"Uber\-trag\-ungs\-band\-breite von 64 KBit/s zu nutzen.

Aus diesen Gr"unden k"onnen neben der Optimierung der Lastverteilung (und damit
z.B. der Antwortzeiten eines Auftrags) auch v"ollig neue Arten von Anwendungen
realisiert werden, die insbesondere auch f"ur den privaten Endbenutzer
interessant sind. In diesem Zusammenhang werden in \cite{Tsch94} eine Reihe
typischer Eigenschaften dieser neuen Anwendungsklassen genannt:

\begin{itemize}

\item Hoher Durchsatz und erh"ohte Zuverl"assigkeit. Im
Weitverkehrsbereich erm"oglichen sie eine unternehmens- und
standort"ubergreifende Kopplung von Rechnernetzen, Gro"srechnern und
Arbeitsplatzrechnern.

\item Nutzung von Audio- und Videodaten in Realzeit f"ur multimediale
Anwendungen. Beispiele hierf"ur sind Videokonferenzen und multimediale
Dokumente.

\item Nutzung von offenen Umgebungen mit zahlreichen Teilnehmern und Ressourcen.
Die Anwendungen nutzen die verbundenen Netze und die unterst"utzende Plattform
f"ur einen offenen Markt von Diensten. Informationen, Ressourcen und Know-How
werden dynamisch angeboten und genutzt. Beispiele hier sind Rechenleistung,
multimediale Informationsbanken, Unterrichtsmaterial, Expertenwissen und alle
Formen des Unterhaltungs- und Freizeitmarktes.

\item Ko\-opera\-tive Arbeit entfernter Teilnehmer und Gruppen. Die Anwendungen
nutzen die Dienstleistungen des Netzes f"ur die koordinierte Arbeit von
entfernten Teilnehmern und Komponenten an einem gemeinsamen Gegenstand oder
simulieren die gemeinsame Pr"asenz der Teilnehmer.

\end{itemize}

Diesen Anwendungsklassen gemeinsam ist eine verteilte Datenhaltung, der
eine Vielzahl von heterogenen Plattformen zugrunde liegt und die eine starke
r"aumliche Verteilung der Daten erm"oglicht.

\section{Realisierung verteilter Anwendungen}

Bei der Realisierung einer verteilten Anwendung f"ur ein verteiltes System
sind eine Reihe von Besonderheiten zu beachten, die gerade aus der Verteilung
entstehen.

Es existieren verschiedene Ans"atze, Datenbest"ande zu verteilen. Diese
lassen sich anhand des jeweils betrachteten Verteilungsgegenstandes
klassifizieren. Die Klassifizierung, die im folgenden Abschnitt verwendet wird,
identifiziert dabei: verteilte Daten, verteilte Objekte und verteilte
Aktivit"aten.

Ein weiterer Freiheitsgrad beim Entwurf und der Realisierung einer Anwendung ist
die Art der verteilten Programmierung. Dieser Aspekt wird im Abschnitt
\ref{verteilteProgrammierung} weiter behandelt.

\subsection{Gegenst"ande der Verteilung}

Im Folgenden werden die unterschiedlichen Ans"atze zur Verteilung von
Objekten\footnote{Objekte hier im sprachlichen Sinne} beschrieben und
gegen"ubergestellt.

\subsubsection{Verteilte Daten}

Bei diesem Ansatz werden Nutzdaten auf mehrere unabh"angige Datenbanksysteme
"uber verschiedene Rechnerknoten verteilt. Dies entspricht dem  klassischen
Verteilungsansatz mit verteilten Datenbankmanagementsystemen (DBMS, z.B.
das System R* \cite{CePe84}).

Der Zugriff auf die verwalteten Daten geschieht "uber Nachrichten an das DBMS
der Art STORE bzw. QUERY. Die Nachrichtenformate f"ur diesen Zugriff sind
abh"angig vom Datenmodell des angesprochenen DBMS und variieren auch innerhalb
eines Datenmodells je nach Hersteller der verwendeten Management-Systeme.

Der konkurrierende Zugriff mehrerer Benutzer auf dieselben Daten erfordert ein
Zugriffsprotokoll, welches die Konsistenz des Datenbestandes (unabh"angig von
der Verteilung) innerhalb der DBMS gew"ahrleistet. Ein weit
verbreiteter Transaktionsbegriff, der dieses Kriterium erf"ullt, basiert auf dem
ACID-Prinzip\footnote{ACID ::= {\em A}tomicy, {\em C}onsistency, {\em
I}solation, {\em D}urability} \cite{GrRe93}.

Eine Fehlererholung f"ur verteilte Transaktionen mu"s ebenfalls den
ACID-Anforderungen gen"ugen. Betrachtet werden dabei {\em kurze}
Transaktionen mit Sperren auf Tupel- oder Dateiebene, die im verteilten Fall mit
einem zweiphasigen Best"atigungsprotokoll zwischen den beteiligten DBMS
koordiniert werden. Dadurch wird ein konsistentes, gemeinsames Ende einer
verteilten Transaktion erreicht.

F"ur diesen Ansatz ist eine "uberwiegend homogene DBMS-Struktur notwendig, da
der Datenzugriff Wissen "uber das vom DBMS verwendete Datenmodell voraussetzt
und die Datenmanipulationssprachen (d.h. die Nachrichten) je nach DBMS
variieren.

Obwohl auch in diesem Fall von Datenbankservern und Klienten (den
Applikationen) gesprochen werden kann, handelt es sich bei diesem Ansatz
um ein {\em geschlossenes} System, in das keine anderen Dienste integriert
werden k"onnen.

\subsubsection{Verteilte Objekte}

Der in letzter Zeit immer st"arker in der Praxis verwendete Client/Server-Ansatz
geht von beliebigen Diensterbringern (engl. {\em server}) und Dienstnutzern
(engl. {\em client}) in Rechnernetzen aus. In diesem Modell ist der Gegenstand
der Verteilung eine Menge von Objekten, die mittels Daten- und
Funktionsabstraktion die {\em Dienste} bilden. Dienste verbergen alle Details
einer zugrundeliegende Implementation vor ihren Dienstnutzern. Somit bietet ein
Dienst eine Schnittstelle f"ur den Zugriff auf die Daten und die Funktionalit"at
einer im System vorhandenen Komponente "uber die von ihr exportierten
Operationen.

Diese Vorgehensweise erm"oglicht es z.B., ein bestehendes, in Cobol
implementiertes Informationssystem in einem Objekt zu kapseln und dieses als
Dienst verf"ugbar zu machen. Danach kann die Implementation des
Informationssystems durch eine andere Technologie (beispielsweise basierend auf
SQL) ausgetauscht werden, ohne die bereits vorhandenen Dienstnutzer dadurch zu
beeintr"achtigen. Die Spezifikation der Dienstschnittstelle wird durch den
Technologiewechsel nicht ber"uhrt.

Die Strukturierung und Verwaltung der Menge unterschiedlicher Dienste
geschieht durch wenige, in der Dienstumgebung standardisierte
Systemdienste\footnote{Engl. {\em middleware}.}. Dabei handelt es sich z.B. um
Vermittlungsdienste, die einem Klienten das Auffinden geeigneter Diensterbringer
zu einer Dienstspezifikation erm"oglichen (Trader-/Brokerdienste) oder einfache
Namensverzeichnisse zur indirekten Adressierung von Diensten. Andere
Systemdienste gew"ahrleisten die Interoperabilit"at innerhalb einer heterogenen
Systemlandschaft, indem sie z.B. Datenformate konvertieren, und bieten eine
skalierende Kommunikationsinfrastruktur an.

Die Kommunikation mit den Dienstobjekten geschieht "uber den Methodenaufruf,
d.h. "uber einen Nachrichtenaustausch, der direkt zur Exekution einer in das
Netz exportierten Operation des adressierten Dienstobjektes f"uhrt. Der Dienst
seinerseits verbirgt alle inneren Strukturdetails vor dessen Nutzer.

Fehlererholungsmechanismen und -strategien sind spezifisch zum jeweilig
angesprochenen Dienst. Allerdings bietet die Middleware in der Regel allgemeine
Mechanismen zur Fehlererholung an, die von dem Dienst verwendet werden k"onnen.

Ein Beispiel f"ur ein verteiltes Objektsystem ist die Systemarchitektur CORBA
der OMG\cite{OMG91}. Eine detaillierte Beschreibung der in diesem System
verwendeten Komponenten findet sich z.B. in \cite{Rich97}.

\subsubsection{Verteilte Aktivit"aten}

Gegenstand der Verteilung bei diesem Ansatz sind aktive und autonome
Objekte, die {\em Agenten} \footnote{Der Begriff {\em Agent} wird im Abschnitt
\ref{Begriffsbestimmung} in seinen verschiedenen Bedeutungen n"aher
betrachtet.}. Sie bilden ein anwendungsnahes Verteilungskonzept "ahnlich den
{\em Business Objects} \cite{Orf96}. In dieser Hinsicht stellen sie in sich
abgeschlossene und separat entwickelte Anwendungskomponenten dar, die sich in
eine bestehende Gesamtanwendung aus vielen solcher Einzelkomponenten
integrieren. Dabei interagieren sie mit anderen Agenten ihrer Umgebung, indem
sie sowohl Dienste f"ur andere Agenten anbieten als auch Dienste als Klient
nutzen.

Agenten kapseln Daten, Funktionen und eine Historie "uber ihrem Zustand. Sie
sind insofern autonom, als da"s sie einen eigenen Kontrollflu"s besitzen und
daraus ihr Verhalten gegen"uber anderen Komponenten selbst bestimmen. Aus deren
Sicht erscheint daher das Verhalten des Agenten willk"urlich und unvorhersagbar.
Agenten gelten in diesem Sinne als {\em pro-aktiv}, im Gegensatz zu den vorher
genannten {\em re-aktiven} Objekten \cite{AGP94}.

{\em Mobile} Agenten sind dar"uber hinaus in der Lage, sich aufgrund interner
Entscheidungen innerhalb des Netzes von einem Adressraum in einen andern zu
bewegen und dort in einem neuen Kontext zu wirken. Das f"uhrt zu einer
dynamischen Topologie der Objekte des Netzes und der Kommunikationsbeziehungen,
die zwischen diesen Objekten bestehen.

Insbesondere gibt es keine M"oglichkeit, von au"sen den jeweiligen internen
Zustand eines Agenten zu bestimmen oder aus einer zentralen Sicht heraus
Aussagen "uber das Gesamtsystem aller Agenten zu machen, da die f"ur diesen
Zweck notwendige "au"sere Kontrolle fehlt.

Das Konzept der Verteilung basierend auf mobilen Agenten eignet sich
aufgrund seiner Anwendungsn"ahe zur Modellierung langandauernder Aktivit"aten,
wie sie h"aufig in der realen Welt vorkommen.

Dabei ist eine auf dem ACID-Prinzip basierende Abarbeitung der Gesamtaktivit"at
auf der Grundlage von Transaktionen, wie dies z.B. im Fall der verteilten Daten
mit verteilten DBM-Systemen geschieht, nicht sinnvoll. Ein solches Vorgehen
h"atte ein Aufrechterhalten aller Sperren auf verwendete Objekte einer
Transaktion "uber deren gesamten Ablaufzeitraum zur Folge. Konkurrierende
Transaktionen m"u"sten dann, aufgrund der im ACID-Prinzip geforderten
Konsistenz- und Isolationsbedingung, auf die Beendigung der sperrenden
Transaktion warten oder in Deadlock-Situationen komplett r"uckg"angig gemacht
werden. Bei Transaktionen, die viele Objekte verschiedener Dienste
"uber lange Zeitr"aume ben"otigen, f"uhrt ein solches Transaktionsmodell zu
einer starken Verminderung des Transaktionsdurchsatzes im System.

Dieser Effekt kann vermieden werden, wenn Sperren nicht bis zum Ende der
Transaktion gehalten werden m"ussen und so die Wahrscheinlichkeit
f"ur Sperrkonflikte zwischen Transaktionen verkleinert wird. Die einzelnen
Schritte einer solchen Transaktion k"onnen dabei nach dem ACID-Prinzip
durchgef"uhrt werden und damit die Konsistenz der verwendeten Objekte
sicherstellen. Durch das fr"uhe Freigeben von Sperren und der damit verbundenen
Aufweichung der Atomarit"at der Gesamttransaktion werden jedoch zwischenzeitlich
inkonsistente Zust"ande f"ur andere Transaktionen sichtbar.

Zus"atzlich mu"s f"ur jeden Zustands"ubergang der langandauernden
Transaktion eine kompensierende Aktion angegeben werden, die die {\em Effekte}
der ersten gegebenenfalls kompensiert\cite{MS87}. Dadurch k"onnen die
Auswirkungen der einzelnen Schritte wieder r"uckg"angig gemacht werden. Diese
kompensierenden Aktionen werden auch {\em inverse} Aktionen genannt.

\subsection{Ans"atze zur verteilten Programmierung}
\label{verteilteProgrammierung}

Verteilte Programmierung ist die programmiersprachliche und systemtechnische
Grundlage zur Erstellung von verteilten Anwendungen. Unabh"angig davon, welches
der im vorherigen Abschnitt dargestellten Verteilungsmuster verwendet wird, d.h.
unabh"angig davon, ob nun Daten, Objekte oder Aktivit"aten den Gegenstand der
Verteilung bilden, m"ussen die zum Design einer verteilten Anwendung verwendeten
Hilfsmittel die verteilte Programmierung unterst"utzen.

Diese Unterst"utzung kann verschiedene Auspr"agungen haben, die im folgenden
vorgestellt werden.

\begin{itemize}

\item Betriebssystemansatz: Netzbetriebssysteme erg"anzen Rechner mit lokalen
Betriebssystemen um Komponenten zur verteilten Kommunikation. Sie erm"oglichen
den geteilten Zugriff auf Ressourcen eines u.U. heterogenen Rechnerverbundes,
wie Plattenspeicher oder Rechenzeit. Die einzelnen Rechner des Verbundes bleiben
als solches sichtbar. Bekannte Netzbetriebssysteme sind AMOEBA und MACH
\cite{Tan95}.

\item Direkte Programmierung: Bei diesem Ansatz werden dem
Programmierer innerhalb einer gew"ohnlichen Programmiersprache (z.B.
C, C++, Cobol, \dots) "uber Funktionsbibliotheken Betriebssystemoperationen f"ur
die verteilte Programmierung zur Verf"ugung gestellt. Im einfachsten Fall
handelt es sich dabei um Funktionen zur "Ubermittlung von untypisierten
Datenstr"omen, die in einer definierten Qualit"at an einen fest zu w"ahlenden
Kommunikationspartner "ubermittelt werden.\footnote{Im weit verbreiteten
Betriebssystem Unix werden sog. {\em Sockets} verwendet.} Die Schnittstellen und
Operationssemantiken variieren je nach verwendetem Betriebssystem, und
Interoperabilit"atsaspekte m"ussen bei Bedarf vom Programmierer selbst
ber"ucksichtigt werden.

\item Nachrichtenaustausch: Der Nachrichtenaustausch innerhalb eines
programmiersprachlichen Rahmens folgt dem gleichen Prinzip wie der
Nachrichtenaustausch auf der Ebene der Systemprozesse. Der wesentliche
Unterschied ist, da"s die Nachrichten innerhalb der Programmiersprache {\em
typisiert} sind. Jede Anwendung kann ihre eigenen, nur innerhalb ihres
Anwendungskontextes g"ultigen Nachrichtenarten definieren.
 
\item Entfernter Prozeduraufruf: Der entfernte Prozeduraufruf ist eine
Erweiterung des lokalen Prozeduraufrufes, wie er von herk"ommlichen
Programmiersprachen der 3. und 4. Generation angeboten wird. Eine Menge
semantisch zusammengeh"origer, entfernter Prozeduren bildet einen Dienst.

Dabei wird die Aufrufsemantik der lokalen Prozeduren dahingehend erweitert, da"s
sie auch innerhalb eines anderen Adressraumes ausgef"uhrt werden
d"urfen. Es wird in diesem Fall lokal (beim Klienten) lediglich die Signatur der
Prozedur deklariert, ohne da"s eine Implementation vorhanden ist.

Die tats"achliche Implementation der Prozedur wird zur Laufzeit, vor ihrem
ersten Aufruf, ermittelt. Dies geschieht in einer sog.
Bindephase, in deren Verlauf ein geeigneter Diensterbringer f"ur die
Prozedur festgelegt wird.

Die lokale Ausf"uhrung der Prozedur wird von einem generischen Kodefragment
(einem sog. {\em Stub}) transparent durch eine definierte Folge von
Nachrichten an das gebundene Diensterbringersystem ersetzt. Die aktuellen
Argumente, die zum Zeitpunkt des Prozeduraufrufs bekannt sind, werden dabei in
einer systemunabh"angigen Darstellung an den entfernten Partner "ubermittelt.

Der Diensterbringer seinerseits besitzt eine Implementation des Prozedurrumpfes,
so da"s dieser die Prozedur mit den "ubermittelten Aktualparametern des Klienten
ausf"uhren kann. Das Ergebnis der Ausf"uhrung wird dem Klienten
zur"uck"ubermittelt. Der entfernte Prozeduraufruf ist in der Regel synchron,
wenn die Prozedur ein Ergebnis liefern soll. Die Abwicklung des
Nachrichtenprotokolls und die Wahl der geeigneten Darstellung der Argumente bzw.
des Ergebnisses ist ein Systemdienst, der f"ur die Anwendung im Idealfall nicht
sichtbar ist \cite{JO95}.

\item Entfernte Objektaktivierung. Der objektorientierte Ansatz mit den
Grundprinzipien der {\em Datenabstraktion}, der {\em Vererbung} und des
{\em dynamischen Bindens} f"uhrt zur Strukturierung einer Anwendung in der Form
von kommunizierenden Objekten. Die Interaktion zwischen Objekten und damit der
Zugriff auf den vom Objekt gekapselten Zustand erfolgt ausschlie"slich "uber
{\em Nachrichten}. Diese f"uhren dann zum Aufruf von {\em Methoden} in dem
Empf"angerobjekt. Der wesentliche Unterschied zum o.g. Nachrichtenaustausch ist,
da"s jede Nachricht direkt einer Methode zugeordnet ist und damit immer eine
Aufforderung zur Ausf"uhrung einer Operation darstellt. Im Vergleich zum
entfernten Prozedur\-aufruf wird i.d.R. eine erweiterte Semantik in Bezug auf
Objektreferenzen und Objektmobilit"at angeboten.

\end{itemize}

Im Gegensatz zu den ``Add On''-Ans"atzen, die versuchen kommerziell relevante
Programmiersprachen um Aspekte der verteilten Programmierung zu erweitern, gibt
es eine Reihe von Sprachen, welche Verteilung explizit ber"ucksichtigen. Zu
diesen Spachen geh"oren Emerald\cite{Jul88}, Obliq\cite{Card94} und
Phantom\cite{Cour95}. Diese Sprachen nutzen die entfernte Objektaktivierung und
bieten spezielle Sprachkonstrukte, um Teilaspekte der verteilten Programmierung
gesondert zu unterst"utzen. Allerdings verwenden alle diese Sprachen das Konzept
der {\em Netzwerkreferenzen} auf Objekte anderer Dom"anen. Ein solches Verfahren
zur verteilten Programmierung ist aus Sicht der Autonomie der Dom"anen nicht
vertretbar und f"uhrt dar"uber hinaus zu einer unkontrollierbaren Ausdehnung von
Objekten. Netzwerkreferenzen sind daher i.d.R. nur in lokalen Netzwerken
sinnvoll einsetzbar \cite{Mat96}.

\section{Offene Dienstnutzungsumgebungen}
\label{offeneDienstnutzungsumbegungen}

Die im vorigen Abschnitt behandelten Ans"atze zur Programmierung verteilter
Anwendungen bilden die Grundlage f"ur die Realisierung von verteilten Systemen.

"Uber die genannten Mechanismen sind System oder Systemkomponenten in der Lage,
mit anderen Systemen bzw. Systemkomponenten zu interagieren. Dies gilt
insbesondere dann, wenn sich die Interaktionspartner in voneinander getrennten
Adressr"aumen befinden.

Verteilte Anwendungen k"onnen mit den genannten Mitteln erstellt werden. Um
allerdings die Investitionen, die ein Unternehmen in die Konzeption,
Erstellung und Pflege eines verteilten Informationssystems get"atigt hat, "uber
einen langen Zeitraum zu sichern, ist es notwendig, neben den technischen
Voraussetzungen zur Kommunikation auch eine geeignete Infrastruktur f"ur diese
Systeme zu ber"ucksichtigen.

Informationssysteme unterliegen "uber die gesamte Dauer ihres Einsatzes sowohl
einem technologischen Wandel, als auch organisatorisch bedingten Ver"anderungen.
Um diesen stetigen Wandel zu begegnen, ist es sinnvoll, gro"se Systeme in
einzelne, voneinander getrennte Komponenten zu untergliedern, die "uber flexible
Mechanismen interagieren k"onnen. Die auf diese Weise geschaffenen
Informationssysteme sind sog. ``Offene Systeme''.

Der Term ``Offene Systeme (engl.: {\em open systems})'' bezeichnet Systeme,
welche durch bestimmte Ma"snahmen zu Beziehungen mit der Au"senwelt (d.h. mit
anderen, ebenfalls offenen Systemen) bef"ahigt sind und dabei die nachfolgend
angef"uhrten Qualit"atsmerkmale besitzen. Betrachtet man in der Erweiterung
des Konzeptes statt einzelner Systeme einen freien Verbund, so f"uhr das zu der
Vorstellung der ``Offenen Dienstnutzungsumgebung''. Hier steht der Begriff
``offen'' als Synonym f"ur ``frei zug"anglich'', ``unbegrenzt'', ``heterogen'',
``selbst"andig und unabh"angig'' und ``dezentralisiert'' \cite{Tsch94}.

Die genannten Merkmale einer offenen Dienstnutzungsumgebung stellen sich im
Einzelnen wie folgt dar:

\begin{itemize}

\item Unbegrenzt: Generell ist die offene Dienstnutzungsumgebung die unbegrenzt.
Es bestehen prinzipiell keine Beschr"ankungen in semantischer, geographischer,
organisatorischer oder technischer Hinsicht.

\item Frei zug"anglich: Eine offene Dienstnutzungsumgebung l"a"st prinzipiell
jede Art von Benutzern, Anwendungen und Komponenten zu. Es wird grunds"atzlich
niemand von der Nutzung vorhandener Ressourcen oder Dienste ausgeschlossen.

\item Heterogen: Jede Organisation innerhalb der Umgebung kann "uber die ihr
zugeh"origen Komponenten frei verf"ugen. Dadurch entsteht eine Ansammlung von
Komponenten und Anwendungen, die sich den von der jeweiligen Organisation
vorgegebenen Anforderungen kontinuierlich anpa"st.

\item Selbst"andig und unabh"angig: Jede Komponente ist an ihrem Betriebs\-ort
charakteristischen Bedingungen unterworfen. Die lokale Umgebung bestimmt ihr
Verhalten und ihre Fortentwicklung. Den anderen Komponenten gegen"uber "au"sert
sich dies in einem unabh"angigen, selbstbestimmten Verhalten. Jede Komponente
ist aus der Sicht anderer Komponenten {\em autonom}.

\item Dezentralisiert: In der offenen Umgebung entwickeln sich die Komponenten
und ihre Eigenschaften und Verhaltensweisen nach lokalen Gesichtspunkten und
ohne eine globale Kontrolle. Daher gibt es auch keinen global beobachtbaren
Zustand und keine Institution, die Aussagen "uber einen momentanen Zustand
aller Komponenten erlaubt.

\end{itemize}

Offene Dienstnutzungsumgebungen besitzen aufgrund ihrer potentiell unbegrenzten
Ausdehnung einen inh"arent f"oderativen Charakter. Sie sind eine Erweiterung des
bereits eingangs geschilderten ODP-Modells, indem sie, f"ur sich genommen, keine
eigene ODP-Anwendung darstellen, sondern vielmehr das Konzept eines freien und
globalen Marktes autonomer und miteinander kooperierender Dienste begr"unden.
Die Basis solcher Dienste, sowohl im Hinblick auf die Modellierung als auch auf
die verwendeten Realisierungsprinzipien, wird durch die ODP-Grundlagen gebildet.

Innerhalb von Dienstm"arkten schlie"sen sich Komponenten zum Zwecke des
Erreichens eines gemeinsamen Ziels dynamische zusammen. Das ODP-Referenzmodell
definiert hierf"ur sog. Tradingdienste \cite{Pop96}, die mit
Informationen "uber Dienstleistungen anderer Anbieter handeln. Komponenten
k"onnen so ihre Dienstleistungen an Traderkomponenten exportieren, wenn sie auf
dem Dienstemarkt eine Leistung anbieten wollen. Andererseits k"onnen sie aber
auch Dienstleister ermitteln (tats"achlich werden i.d.R. Dienstleistungen
ermittelt; der eigentliche Dienstleister bleibt verborgen) und dessen angebotene
Leistung nutzen.

Es ist daher nicht vorhersehbar, welche Komponenten zu einem Zeitpunkt
mit welchen anderen Komponenten zusammenarbeiten werden. Aus diesem Grund sind
Systemmechanismen notwendig, welche flexible und verbindliche Kooperationen
zwischen beliebigen Komponenten erm"oglichen.

\section{Kooperation und Autonomie}
\label{KooperationUndAutonomie}

In diesem Abschnitt werden die Begriffe Kooperation und Autonomie genauer
betrachtet. Die Darstellung folgt in wesentlichen Teilen
\cite{Kir94},\cite{Tsch94} und \cite{CISManifesto97}.

Als autonom bezeichnete Einheiten haben das Recht auf Selbstbestimmung und
Unabh"angigkeit. Autonome Teile eines Systems handeln nach individuellen oder
lokalen Gesetzen und k"onnen die allgemein vorherrschenden Regeln und
Verhaltensweisen entweder zeitweise oder auf Dauer mi"sachten. Autonome
Komponenten erlauben nicht den Einblick in ihre Interna. Ihr Zustand kann daher
nur aus der Beobachtung ihrer Interaktion mit ihrer Umgebung geschlossen werden.

Die Betrachtung der Ursachen f"ur Autonomie ergibt eine Unterscheidung zwischen
organisatorischen und operationellen Ursachen.

Organisatorische Ursachen erwachsen aus dem Umstand, da"s Komponenten
{\em Eigentum} bestimmter Organisationen sind.

Daraus folgt, da"s jede Organisation

\begin{itemize}
\item das generelle Umfeld und die Einsatzziele f"ur ihre Informationssysteme
nach eigenen Bed"urfnissen bestimmt,

\item ihre Ziele unabh"angig von anderen Organisationen plant und realisiert,
auch wenn diese dasselbe generelle Umfeld und Einsatzziel haben,

\item ihre Anwendungen so plant und implementiert, da"s lokale Anforderungen an
Leistung, Sicherheit, usw. erf"ullt werden,

\item Hardware und Software-Komponenten entwickelt und installiert, die ihren
Zielen und Anforderungen m"oglichst optimal entsprechen,

\item ihre Komponenten st"andig den sich "andernden Anforderungen und
technischen Gegebenheiten anpa"st.

\end{itemize}

Die aus diesen Punkten erkennbaren unterschiedlichen Formen von Autonomie werden
als {\em Design-Autonomie}, {\em Evolutions-Autonomie} und {\em
Administrations-Autonomie} bezeichnet.

Der gemeinsame Aspekt aller organisatorisch begr"undeten Erscheinungsformen der
Autonomie ist die Tatsache, da"s die den Komponenten inh"arenten
Verhaltensregeln von den lokalen Organisationen bestimmt oder beeinflu"st
werden. Das bedeutet, da"s diese verhandelbar sind, wenn es darum geht, zwischen
Organisationen {\em Kooperationen} einzurichten und ihre Einheiten in
gemeinsame Anwendungen einzubringen.

Neben den genannten organisatorischen Ursachen gibt es noch operationelle
Ursachen f"ur Autonomie. Das Verhalten lokaler Benutzer, die St"oreinfl"usse
der Umgebung und der Betrieb insgesamt beeinflussen die Autonomie von
Komponenten.

Dabei werden das Last- und Fehlerverhalten der Komponenten aus der Sicht
externer Beobachter oder Auftraggeber betrachtet. Verschiedene Komponenten
k"onnen auf Einfl"usse ihrer Umgebung unterschiedlich reagieren. Die Reaktion
auf auftretende Last (in Form von Bedien- und Wartezeiten bei Auftr"agen f"ur
eine Komponente) oder das st"orungs- und fehlerbedingte Verhalten der
Komponenten kann nicht von au"sen, d.h. von der Umgebung, beeinflu"st werden,
sondern liegt in der Verantwortung der Komponente selbst.

Die aus dieser Sicht erkennbaren Formen der Autonomie werden
als {\em Zustands-Autonomie}, bzw. im Falle der St"oreinfl"usse, als {\em
Fehler-Autonomie} bezeichnet. Im Gegensatz zu den organisatorischen Ursachen
f"ur Autonomie k"onnen die operationell begr"undeten Erscheinungsformen von
Autonomie von den lokalen Organisationen nur indirekt bestimmt oder beeinflu"st
werden.

Autonome Komponenten eines Systems werden nachfolgend mit dem Begriff {\em
Agenten} bezeichnet. Generell ist es dabei nicht relevant, ob es sich um eine
Software-Aktivit"at oder um einen menschlichen Akteur handelt\footnote{Auf die
unterschiedlichen Agentenbegriffe wird in Abschnitt \ref{Begriffsbestimmung}
n"aher eingegangen.}.

Agenten verfolgen in der Regel Ziele\footnote{Nat"urlich ist es m"oglich,
Agenten zu erschaffen, die {\em kein} Ziel verfolgen. Aus der Sicht kooperativer
Informationssysteme werden diese Agenten allerdings nicht betrachtet.}, d.h.
sie haben einen in einem bestimmten Kontext definierten Zweck oder eine
Aufgabe. Es ist daher naheliegend, spezialisierte Agenten zur
Erf"ullung ihrer Aufgaben oder einer "ubergeordneten Gesamtaufgabe
zusammenarbeiten zu lassen. Ein solcher permanenter oder zeitweiliger
Zusammenschlu"s von Einheiten zum Zweck koordinierter, zielgerichteter
Aktivit"aten hei"st {\em Kooperation} \cite{Tsch94}.

Kernpunkt jeder Kooperation ist die gegenseitige Beeinflussung von Handlungen
oder Handlungspl"anen unter kooperierenden Agenten. Dabei gelten eine Reihe von
Bedingungen f"ur Kooperation:

\begin{itemize}
\item Zielidentit"at
\item Ver"anderbarkeit der Pl"ane
\item Ressourcenaustausch
\item Regelbarkeit
\item Kontrolle
\end{itemize}

Der wichtigste Punkt ist die {\em Zielidentit"at}. Damit wird gefordert, da"s
Agenten "ubereinstimmende Ziele oder Teilziele aufweisen. Die Handlungspl"ane
der Agenten sollten insofern ver"anderbar sein, als da"s sie sich durch die
Interaktion mit anderen Agenten neuen Erfordernissen anpassen. Mit
Ressourcenaustausch wird gefordert, da"s neben dem Austausch von
Kooperationsinhalten auch Randbedingungen wie Ort, Zeit, eingesetzte Mittel und
Materialien zwischen den Agenten weitergegeben werden k"onnen. Die F"ahigkeit
zur flexiblen Planbeeinflussung und Behandlung von Ausnahmesituationen hei"st
Regelbarkeit. Die Kontrolle verlangt schlie"slich, da"s die Handlungsabsichten
eines Agenten, d.h. die Handlungspl"ane, im voraus erkennbar sein m"ussen, so
da"s eine maximale Transparenz des kooperativen Prozesses gew"ahrleistet ist.

Kooperative Informationssysteme als Ganzes m"ussen durch die genannten Formen
der Autonomie "Anderungen "uber lange Zeitr"aume hinweg tolerieren
und unterst"utzen.

Eine Architektur f"ur derartige kooperative Informationssysteme untergliedert
das System in vier Schichten\cite{CISManifesto97}:

Die Systemschicht bildet die Basis eines kooperativen Informationssystems. In
dieser Ebene befinden sich die spezifischen, konventionellen Anwendungen bzw.
Komponenten eines Unternehmens. Diese sog. Altsysteme (engl. {\em legacy
systems}) stellen aus Unternehmenssicht die Kernfunktionalit"at des
Informationssystems bereit und sind f"ur sich genommen nicht kooperativ.

Dar"uber sorgt eine Systemintegrationsschicht f"ur die Zusammenarbeit
verschiedener, u.U. verteilter Systeme. Diese Schicht integriert
die Komponenten der Systemschicht und bietet den h"oheren Schichten der
Architektur eine einheitliche Sicht auf diese. Hier sind die einheitlichen
Kooperationsmechanismen definiert, die die Interaktion mit anderen Systemen
erm"oglichen.

Die Arbeitsgruppenschicht und die Unternehmensschicht bilden organisatorische
Aspekte des Unternehmens auf das Informationssystem ab. Dabei ist es die Aufgabe
der Arbeitsgruppenschicht, die soziologische Struktur eines Unternehmens (Teams,
Abteilungen, Profit Center, \dots) abzubilden. In der Unternehmensschicht wird
ein Unternehmen als Ganzes betrachtet. Dabei treten das Unternehmensmodell bzw.
die Ziele und Strategien eines Unternehmens in den Vordergrund.

Im folgenden werden nur die Aufgaben der Systemintegrationsschicht erl"autert,
da diese die kooperativen Eigenschaften eines Informationssystems ma"sgeblich
beeinflu"st.

Die Systemintegrationsschicht soll den Anwendungsprogrammierer durch Abstraktion
in den folgenden Punkten unterst"utzen:

\begin{enumerate}

\item Kooperation "uber die Zeit: Die Lebensdauer aller maschinellen Akteure
richtet sich nach der Dauer der Gesch"aftsprozesse, in denen sie involviert
sind. Die Lebensdauer ist allein durch den Gesch"aftsproze"s bestimmt und daher
unabh"angig von Parametern des verwendeten Systems, wie der
Programmiersprache, der Lebensdauer von Betriebssystemprozessen oder
von "Anderungen der zugrundeliegenden Datenbankschemata.

\item Kooperation innerhalb des Raums: Maschinelle Akteure k"onnen
innerhalb einer physikalisch oder logisch verteilten Umgebung migrieren.
Dabei sind sie nicht von speziellen Systemplattformen oder
Organisationsstrukturen abh"angig.

\item Kooperation in mehreren Arbeitsformen: Softwaresysteme sollen f"ur
maschinelle Akteure einheitlich benutzbar sein. Dabei werden die folgenden
Arbeitsformen gleichbehandelt: einfache Stapelverarbeitung,
Transaktionsverarbeitung, direkte Manipulation durch menschliche Akteure
"uber formularbasierte Eingabemasken, rechnerunterst"utzte Zusammenarbeit
menschlicher Akteure, rechnergest"utztes Workflow-Management und automatische
Informationsverarbeitung mit mobilen Softwareagenten. Ebenfalls sollen
verschiedene Medien auf gleiche Art unterst"utzt werden: E-Mail-Nachrichten,
EDI-Nachrichten, HTTP-Requests, CORBA Object-Requests oder entfernte
Prozeduraufrufe.

\end{enumerate}

Durch die Abstraktion in den Modalit"aten Zeit, Raum und Arbeitsform kann sich
der Programmierer auf das {\em was} und {\em wie} des speziellen Problems
konzentrieren und braucht sich nicht mehr um das {\em wann} (d.h.
Stapelverarbeitung, interaktive Sitzungen oder langandauernde Konversationen mit
einem Kunden), {\em wo} (d.h. zentralisierter Hostrechner, Server innerhalb
eines Unternehmens oder ein Laptop eines Verkaufsmitarbeiters) und {\em wer}
(d.h. Kunde, Verk"aufer, Workflow-Management-System oder Internet-Agent) zu
k"ummern. Die Applikationen werden so von technischen Details wie dem
Datentransfer, der Synchronisation und Fragen der Benutzeroberfl"ache oder der
Dialogsteuerung, befreit.

Es finden sich in der Literatur eine Reihe unterschiedlicher
Kooperationsmodelle (z.B. netzbasierte Modellierung\cite{BBOO86},
Nachrichtenmuster im Actor-System \cite{AH87} oder selbstleitende Nachrichten
\cite{HoGa84}), von denen im n"achsten Abschnitt ein anwendungsnahes
Kooperationsmodell, der Language/Action-Ansatz, vorgestellt wird.

\section[Ein Leitbild f"ur Kooperation: Der {\em Language/Action} Ansatz] {Ein
Leitbild f"ur Kooperation: Der \\ {\em Language/Action} Ansatz}

\label{koopleitbild}

Dieses Kooperationsleitbild betrachtet die Sprache als wichtigste Dimension f"ur
kooperative Zusammenarbeit zwischen Menschen. Die Grundlage des Leitbildes ist
die Sprechakttheorie, die von Austin \cite{Aust62} eingef"uhrt und von Searle
\cite{Sear69} erweitert wurde.

Der Kern der Spechakttheorie besteht darin, da"s sich alle sprachlichen
"Au"serungen (die sog. Sprechakte) hinsichtlich ihrer Verwendung in f"unf
disjunkte Typklassen einteilen lassen: assertive "Au"serungen (Feststellungen),
direktive "Au"serungen (Aufforderungen), kommissive "Au"serungen (Versprechen),
expressive "Au"serungen (Ausdruck von Meinungen) und deklarative "Au"serungen
(Erkl"arungen).

Nach Searle ist eine "Au"serung dabei unmittelbar an ihre Bedeutung
gekoppelt. Sprechakte werden daher als Mitteilung einer legalen
Zustands"anderungen ihres Sprechers innerhalb einer Konversation betrachtet.

Arbeiten aus dem Bereich der computerunterst"utzten Gruppenarbeit (CSCW) von Fernando Flores und Terry Winograd \cite{Wino87,FlWi+88} identifizieren zwei haupts"achliche Arten von Sprechakten, die in der Dom"ane von Gesch"aftsprozessen eine Rolle spielen: Das sind zum einen die {\em Conversations for Possibilities} (CfP) und zum anderen
die {\em Conversations for Action} (CfA). Eine CfA ist eine Folge von
Aufforderungen und Versprechen, die direkt auf eine gemeinsame Aktivit"at der
Gespr"achspartner gerichtet ist. Dabei ist innerhalb einer CfA die Reihenfolge
der einzelnen Sprechakte, d.h. die erlaubten Gespr"achstransitionen, unter den
Gespr"achspartnern festgelegt.

Werden in einer Konversation keine Verpflichtungen eingegangen, sondern wird die
``Funktion eines Managers'' wahrgenommen, sprechen Winograd und Flores vom
Typ einer CfP. In diesem Fall werden in einer Konversation nur Feststellungen,
Meinungen oder Erkl"arungen ausgetauscht. Bei keinem Partner wird durch einen
Sprechakt eine Aktion impliziert.

Eine CfA oder CfP strukturiert und koordiniert einzelne Sprechakte. Durch diese
Sprechakte bilden die beteiligten Kommunikationspartner eine gemeinsame
Historie, vor deren Hintergrund neue Sprechakte erzeugt und interpretiert
werden. Bei einer CfA, deren Konzept dem Kooperationsmodell aus Kapitel
\ref{tbc} zugrunde liegt, vereinbaren die Partner wechselseitig zuk"unftige
Aktionen, die direkt an die ge"au"serten Sprechakte der jeweiligen Partner
gekoppelt sind.





