% PARTOF texte:da/tex/a_home.tex

\chapter{Die Ausf"uhrungsumgebung}
\label{umgebung}

Dieses Kapitel beschreibt die Architektur der Ausf"uhrungsumgebung f"ur
mobile Agenten und deren Komponenten. Dabei wird auf bereits vorhandene Konzepte
und Realisierungen verwiesen. Das Kapitel ist nicht an ein spezifisches
Programmiersystem gebunden und zeigt Realisierungsm"oglichkeiten f"ur
verschiedene Systemplattformen auf. Die Beschreibung erfolgt auf der Ebene von
Komponenten, Schnittstellen und Strukturmodellen.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/agmodel.eps}}
\caption{Modell einer Ausf"uhrungsumgebung f"ur mobile Agenten}
\label{AgEnvKonzeptModell}
\end{figure}

\section{"Ubersicht}

Die Abbildung \ref{AgEnvKonzeptModell} zeigt das Schichtenmodell einer
Ausf"uhrungsumgebung f"ur mobile Agenten nach \cite{CHK94}. In der Ebene der
Anwendungssysteme befinden sich die Applikationen, die einem Endbenutzer zur
Verf"ugung stehen. Von der dort vorgenommenen Unterscheidung in Klienten und
Dienstleister (engl. {\em client/server}) ist in dieser Darstellung abstrahiert
worden. In der Regel ist diese auch willk"urlich, da sich auf
Rechnersystemen der realen Welt h"aufig eine Vielzahl unterschiedlicher Dienste
und Dienstnutzer befinden, oder eine Applikation sowohl einen Dienst erbringt
als auch die Dienste anderer Applikationen nutzt. Im Hinblick auf die im
Abschnitt \ref{offeneDienstnutzungsumbegungen} geschilderten ``offenen
Dienstnutzungsumgebungen'', die allgemeiner von kooperierenden Komponenten in
wechselnden Rollen ausgeht, ist eine strikte Trennung von Klient und
Dienstleister zu strikt.

Die Komponenten einer offenen Dienstnutzungsumgebung befinden sich in der
Schicht der Anwendungssysteme. Eine Anwendung, wie sie sich dem
Endbenutzer darstellt, besteht aus einem Zusammenschlu"s dieser unabh"angigen
Komponenten, die durch Kooperation untereinander einen Dienst f"ur den
Endbenutzer erbringen. Zur Interaktion mit einem menschlichen
Endbenutzer\footnote{Wie bereits im Abschnitt \ref{KooperationUndAutonomie}
dargelegt, k"onnen auch nicht-menschliche Akteure als Endbenutzer angesehen
werden.} sind in dieser Schicht auch generische Visualisierungsdienste
angesiedelt, die eine f"ur Menschen geeignete Pr"asentation der Dienste
bereitstellen.

Die Menge der tats"achlich vorhandenen Anwendungen ist nicht vorhersagbar. Die
Population variiert je nach Endbenutzer und Einsatzgebiet des Rechnersystems.
Eine homogene Anwendungsstruktur kann daher auf dieser Ebene nicht vorausgesetzt
werden. Vielmehr mu"s es Ziel sein, die verschiedenen autonomen Anwendungen im
Sinne einer Kooperation zu integrieren\footnote{Eine Motivation hierf"ur findet
sich ebenfalls in Abschnitt \ref{KooperationUndAutonomie}}.

Die Schicht des Agentensystems leistet dies. Im Gegensatz zur
Anwendungssystemschicht ist das Agentensystem auf jedem Rechnerknoten einer
auf Agenten basierenden, offenen Dienstnutzungsumgebung vorhanden. Die
Anwendungsprogrammierschnittstellen (engl. {\em application programming
interface} (API)) des Agentensystems wird von den in der
Anwendungssystemschicht befindlichen Applikationen verwendet, um die
erforderliche Kooperation mit anderen Komponenten ihrer Schicht zu erreichen.

Auf die Dienste bzw. Komponenten des Agentensystems und des Nachrichtensubsystems
wird in den folgenden Abschnitten genauer eingegangen. Die
Kommunikationsinfrastruktur wird nicht n"aher betrachtet, da mit dem
Nachrichtensubsystem eine Abstraktionsschicht "uber dieser liegt. Hier k"onnen
ggf. erforderliche Anpassungen transparent vorgenommen\footnote{Die in dieser
Arbeit vorgenommene Implementation des Agentensystem benutzt als Anbindung an
die Kommunikationsinfrastruktur {\em Sockets}.} werden.

\section{Agentensystem}

Die in diesem Abschnitt genannten Architekturmerkmale basieren wesentlich auf
Erfahrungen mit dem Telescript-System, Arbeiten von David Chess, et al.
\cite{CGHLP95} und Arbeiten im Rahmen der Dissertation von Bernd
Mathiske \cite{Mat96}.

Diese Architekturmerkmale sind im einzelnen:

\begin{itemize}

\item Anwendungsnahe, migrationsorientierte Strukturierung des Netzes f"ur
agentenbasierte Dienste.

\item Anwendungsnahe Kooperationsformen und Protokolle.

\item Basisklassen zur Erzeugung von Agenten.

\item Migrationsunterst"utzung

\end{itemize}

\subsection{Strukturierungsmittel}

Eine wesentliche Leistung des Agentensystems ist die Strukturierung der
``Welt'', in der sich die mobilen Agenten bewegen. Da Migration von Agenten ein
Kernelement des Agentensystem ist, d.h. ein Agent seinen Aufenthaltsort aktiv
bestimmen kann, wurde eine r"aumliche Metapher zur Strukturierung gew"ahlt.
Diese soll helfen, den Umgang mit der Migration als sprachliches Mittel auf
Anwendungsebene zu erleichtern.

Das Agentensystem realisiert  die Konzepte {\em Dom"ane} und {\em Ort}. Eine
Dom"ane ist einem Knoten des Rechnernetzes zugeordnet und verf"ugt "uber einen
eigenen Kommunikationsendpunkt innerhalb des Netzes. Eine Dom"ane kann ein
beliebiges Rechnersystem sein, das einen Komponentenstapel aus Abbildung
\ref{AgEnvKonzeptModell} beherbergt. Jede Dom"ane ist innerhalb des Netzwerkes
eindeutig adressierbar und besteht immer aus mindestens einem Ort, welcher die
Wurzel der lokalen Ortehierarchie eine Dom"ane bildet.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/aelog.eps}}
\caption{Logische Struktur der Agentenwelt}
\label{AgWeltStruktur}
\end{figure}

In Abbildung \ref{AgWeltStruktur} ist die vom Agentensystem geschaffene
logische Struktur einer Dom"ane dargestellt.
Orte sind untereinander hierarisch angeordnet. Ein Ort kann eine beliebige
Anzahl anderer Orte und Agenten beherbergen. Dabei ist jeder Ort innerhalb
seiner Dom"ane\footnote{Dies ist eine Implementationseinschr"ankung, die bei
Bedarf aufgehoben werden kann.} eindeutig benannt.

Orte bilden dynamische Sichtbarkeitsbereiche f"ur Agenten und enthaltene
Orte. Jeder Ort wird durch einen spezialisierten Agenten repr"asentiert, einen
sog. Orte-W"achter. Dieser kann f"ur jeden Agenten, der den Ort betreten
m"ochte, entscheiden, ob dieser in den Sichtbarkeitsbereich des Ortes eindringen
darf oder nicht. Lehnt ein Orte-W"achter den Zutritt ab, wird die Migration des
betroffenen Agenten nicht durchgef"uhrt.

Ein Agent kann nur mit Agenten in Kontakt treten, die sich mit ihm am selben Ort
befinden. Ein Ort (bzw. dessen Orte-W"achter) kann aber sowohl von
innerhalb des Ortes, als auch von au"serhalb erreicht werden. Sie befinden sich
daher in Abbildung \ref{AgWeltStruktur} auf der Grenze zweier Orte.

Jeder Ortswechsel, ob dom"anen"ubergreifend oder lokal, geschieht
mittels einer {\em Migration}. Der Wechsel zu einem anderen Ort ist nur dann
m"oglich, wenn der migrierende Agent eine g"ultige Reiseroute zum gew"unschten
Zielort angibt. Eine solche Route besteht aus der Netzadresse der Zieldom"ane
und der Namen aller Orte, die sich auf dem Pfad zum Zielort befinden. Im Falle
einer lokalen Migration ist eine ortsrelative Adressierung ausreichend.

Die Kontrolle der Migration "ubernimmt eine Komponente des Agentensystems, die
{\em Migrationssteuerung}. Sie stellt sicher, da"s jeder betroffene
Orte-W"achter "uber den Migrationswunsch informiert wird und den Eintritt
gew"ahrt.

Durch diesen Mechanismus wird erreicht, da"s jeder Ort "uber die an ihm
befindlichen Orte und Agenten informiert ist. Das Erzeugen eines neuen
Agenten oder Ortes ist ebenfalls zustimmungspflichtig durch den betroffenen
Ort.

Orte k"onnen, genau wie Agenten, beliebig zur Laufzeit erzeugt und wieder
vernichtet werden\footnote{Die konkrete Implementation des Agentensystems
verhindert die Vernichtung eines Ortes, sofern dieser nicht leer ist.}.

Mit den genannten Eigenschaften bilden Orte die Grundlage der
anwendungsorientierten Strukturierung einer Dom"ane. Die Repr"asentation
eines Ortes durch einen aktiven Orte-W"achter erlaubt die Nutzung der
selben Systemmechanismen f"ur Orte wie f"ur Agenten. Allerdings sind
Orte im Gegensatz zu den Agenten immobil. Diese Einschr"ankung ist durch
die r"aumliche Metapher motiviert, denn in der realen Welt sind Orte ebenfalls
fixiert. Eine Anwendung kann w"ahlen, ob eine Komponente durch einen Agenten
oder Ort implementiert wird. Das Kapitel \ref{abstraktprgmodell}, welches das
Programmiermodell f"ur mobile Agenten vorstellt, zeigt dies anhand eines
Beispiels.

\subsection{Kooperation}
\label{umgebungkooperation}
Auch die Kooperationsformen, die eine Interaktion autonomer Agenten
erm"oglichen, sollen anwendungsnah sein. Um dies zu erreichen, wird das im
Kapitel \ref{tbc} vorgestellte Kooperationsmodell der {\em Business
Conversations} in der Umgebung f"ur mobile Agenten eingesetzt. Da diese
medienunabh"angig definiert sind und von einer maximalen Autonomie der
Kommunikationspartner ausgehen, eignen sie sich f"ur das Agentensystem.

Agenten\footnote{Die Aussagen in Bezug auf Agenten gelten in diesem Abschnitt
auch f"ur Orte (bzw. Orte-W"achter).} kooperieren mit anderen Agenten, indem
sie mit ihnen {\em Konversationen} f"uhren. Die dadurch entstehenden Beziehungen
zwischen Agenten sind in Abbildung \ref{AGInteraktion} dargestellt.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/bezdarst.eps}}
\caption{Interaktionsbeziehungen zwischen Agenten}
\label{AGInteraktion}
\end{figure}

In einer Konversationsbeziehung ist es notwendig, da"s ein Partner die Rolle des
Kunden einnimmt und der andere Partner die des Dienstleisters (in den
Abbildungen mit K und D gekennzeichnet). Agenten k"onnen diese Rollen je nach zu
erf"ullender Aufgabe einnehmen. Die Rollen gelten nur f"ur die jeweilige
Konversation mit einem Agenten.

Jeder Agent kann gleichzeitig mehrere Konversationsbeziehungen zu anderen
Agenten aufrechterhalten. Die zeitliche Ausdehnung einer solchen Beziehung ist
nur durch die Lebensdauer der beteiligten Agenten beschr"ankt. Diese Eigenschaft
ist im Hinblick auf Anwendungen aus dem Bereich der computerunterst"utzten
Gruppenarbeit (CSCW) hilfreich, da hier h"aufig lang andauernde
Beziehungen zwischen den Akteuren eines Arbeitsprozesses vorkommen \cite{Jab95}.
Diese Beziehungen k"onnen direkt durch das Agentensystem modelliert werden.

Eine Konversation zwischen Agenten erfordert keine verbindungsorientierte
Kommunikation der Partner. Stattdessen repr"asentiert eine Konversation
eine virtuelle Verbindung zu einem Agenten, die "uber das Nachrichtensubsystem
(siehe Abschnitt \ref{Nachrichtensubsystem}) abgebildet wird.

Die Kooperation nach dem {\em Business Conversation}-Modell besitzt eine Reihe
von Vorteilen gegen"uber der direkten Objektinteraktion, die bei den
Agentensystemen Mole und Telescript verwendet wird:

\begin{itemize}

\item Die Konversationsbeziehungen sind autonomiebewahrend. Durch den
Austausch von definierten Formularobjekten werden keine privaten Objektbindungen
eines Agenten dem Konversationspartner zug"anglich gemacht. Daher kann auf
besondere Bindungsarten f"ur Objekte, wie
z.B. die Ownership-Referenzen \cite{Whi94,tde95}, verzichtet werden.

\item Die Konversationsbeziehungen sind migrationssicher. Da in einer
Kooperation nur Bindungen an Objekte des BC-Modells entstehen, bleibt auch die
{\em faktische} Mobilit"at erhalten \cite{Mat96}. Sind beliebige
Objektinteraktionen erlaubt, kann ein Agent Bindungen an Objekte erhalten, die
aus dem Anwendungskontext betrachtet nicht mobil sind. Dies trifft insbesondere
auf Massendaten zu, die aufgrund ihres Volumens nicht "uber ein Netzwerk
transportiert werden sollten\footnote{Zum Beispiel ist der
Versicherungsvertragsbestand einer Lebenversicherung {\em faktisch} immobil.}.

\item Das Modell besitzt ein definiertes Verarbeitungsmodell. Anders als bei der
direkten Objektinteraktion, wird f"ur jede Kooperation beliebiger Agenten die
erforderliche Koordination vom Agentensystem vorgenommen. Daher ist keine
weitere Synchronisation beim geteilten Zugriff auf Ressourcen notwendig, die
durch Agenten realisiert sind. Der Anwendungsprogrammierer wird auf diese Weise
von den Problemen der ausgepr"agten Nebenl"aufigkeit im Agentensystem
abgeschirmt.

\item Das Modell ist medienunabh"angig. Bei einer Beschr"ankung der Kooperation
auf Konversationen ist ein Agent in der Lage auch zuk"unftige, nicht
agentenbasierte Systeme "uber seine Kooperationsmechanismen zu bedienen.
Insbesondere k"onnen klassische objektbasierte Verteilungsmechanismen, wie sie
z.B. in CORBA \cite{OMG91} vorkommen, auf das Konversationsmodell abgebildet
werden.

\item Die Kooperationsbeziehungen sind transparent. Die einzig m"ogliche
Einflu"snahme eines Agenten auf einen anderen Agenten, ist durch die
Benutzung der Kooperationsschnittstelle des Agentensystems. Da aber die daf"ur
erforderliche Kommunikation "uber ein gesondertes Kommunikationssubsystem
abgewickelt wird, ist der vollst"andige Nachrichtenflu"s an einer zentralen
Stelle abgreifbar. Damit ist er anderen Diensten wie Logging, Tracing,
Authentisierung, \dots zug"anglich\footnote{Siehe auch der Mediator im 
Abschnitt \ref{Nachrichtensubsystem}}.

\item Konversationen unterliegen einer Proze"sspezifikation. Jede Konversation
ist "uber ein zugeh"origes Spezifikationsobjekt beschrieben. Diese Spezifikation
liegt zur Laufzeit den beteiligten Agenten vor und wird am Beginn einer
Konversation dem Partner mitgeteilt. Dies erm"oglicht den Abgleich des
potentiellen Gespr"achsverlaufes durch die Agenten, bevor eine Konversation
aufgenommen wird.

\end{itemize}

Diesen Vorteilen steht der Nachteil gegen"uber, da"s ein Agent seine zu
kommunizierenden Anwendungsdatenstrukturen in die vom {\em Business
Conversation}-Modell verlangten Formularobjekte konvertieren mu"s. Da aber
h"aufig nur ein kleiner Teil des Zustandes eines Agenten einem anderen Agenten
mitgeteilt werden mu"s, ist dieser Aufwand, gemessen an den Vorteilen des
Modells, vertretbar.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/agkonv.eps}}
\caption{Konversationen zwischen Agenten}
\label{AGKonversationen}
\end{figure}

In Abbildung \ref{AGKonversationen} findet sich eine detailliertere Darstellung
der Konversationsbeziehungen zwischen Agenten.

Sie zeigt den Zusammenhang von Konversationen und Konversationsspezifikationen,
der durch das Agentenmodell erreicht wird.

Jede Rolle eines Agenten erfordert eine zugeh"orige Konversationsspezifikation.
Diese wird bei einer Konversationsbeziehung zu einem anderen Agenten
instantiiert und wirkt dabei als Generator f"ur die Formularobjekte, die im
Verlauf der Konversation zwischen den Partnern ausgetauscht werden.

Konversationen werden deklarativ "uber {\sl ON}-Regeln programmiert. Daraus
resultiert eine Aufteilung des Programmflusses in Ereignis/Aktions-Paare, die
in einer Regelbasis des Agenten gespeichert wird. Diese strikte Strukturierung
in Bearbeitungsregeln bietet weiter die M"oglichkeit, eine Fehlererholung mit
kompensierenden Aktionen \cite{MS87,DHL90} f"ur jede Konversation anzugeben.
Dabei kann jede solche {\em inverse}-Bearbeitungsregel die lokale
Gespr"achshistorie der aktuellen Konversation verwenden.

Ein Agent ist in der Lage, beliebig viele Konversationen gleichzeitig zu
f"uhren, wobei allerdings die Exekution einer Bearbeitungsregel eines
Formulars, wie durch das {\em Business Conversation}-Modell verlangt, atomar
geschieht. Jede Konversation bildet damit eine Art eigener {\em Thread},
einen {\sl Gespr"achs}faden, mit einem eigenen Kontext. Die Umschaltpunkte
sind jeweils das Ende einer Bearbeitungsregel. Das Kontextmanagement, d.h. die
Zuordnung des korrekten Kontextes zur jeweiligen Regel, leistet das
Agentenskelett (siehe Abschnitt \ref{Agentengeneratoren}).

Bei der Migration eines Agenten an einen neuen Ort oder wenn dieser eine
sekund"are Konversation beginnt, wird die atomare Ausf"uhrung der umgebenden
Bearbeitungsregel aufgehoben. Im Falle der Migration ist dies erforderlich, um
den Agenten durch den Migrationsdienst linearisieren und verschicken zu
k"onnen. Hierbei wird sichergestellt, da"s keine andere Bearbeitungsregel
aktiviert wird, solange die erste nicht beendet ist. Dies bedeutet, das eine
Migration aus der Sicht der initiierenden Bearbeitungsregel atomar ausgef"uhrt
wird, aus der Sicht des Agenten jedoch die Regel unterbricht.

Die sekund"are Konversation mit einem anderen Agenten verlangt, da"s diese
Konversation zuerst beendet wird, bevor die ausl"osende Konversation
weitergef"uhrt wird. Dieses synchrone Verfahren entspricht in seiner
Verarbeitung dem Prozeduraufruf in einer Programmiersprache. Hierbei wird die
Ausf"uhrung der initiierenden Bearbeitungsregel ebenfalls unterbrochen, jedoch
k"onnen andere Bearbeitungsregeln in dieser Unterbrechung ausgef"uhrt werden.

Der durch das Agentensystem erzeugte Nachrichtenflu"s einer Konversation ist in
Abbildung \ref{cvflow} veranschaulicht.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/cvflow.eps}}
\caption{Nachrichtenflu"s einer Konversation}
\label{cvflow}
\end{figure}

In dieser Darstellung sind die beiden Ebenen Kommunikation und Kooperation zu
erkennen. Auf der Kommunikationsebene werden zwischen den Partnern
systemdefinierte Nachrichten ausgetauscht. Mit diesen Nachrichten wird die
Kooperation auf der Basis anwendungsorientierter Formular- und
Spezifikationsobjekte realisiert.

Durch das {\em Business Conversation}-Modell ist der erforderliche
Interaktionsablauf der Kooperation zwischen einem Kunden und seinem
Dienstleister vorgegeben. Das Model trifft jedoch keine Festlegung dar"uber, wie
ein Kunde einen geeigneten Dienstleister {\em ermitteln} kann. Dieses Problem,
das sich auch unter der engl. Bezeichnung {\em trading} oder {\em brokering} im
Zusammenhang mit der Client/Server-Programmierung findet \cite{WL94,Pop96},
wird vom Modell nicht eingeschr"ankt. Das Agentensystem bietet f"ur diesen
Bereich lediglich eine Kernunterst"utzung, die es Agenten erlaubt,
Konversationen mit anderen Agenten zu beginnen. Zu diesem Zweck ist es
notwendig, da"s ein Agent den Namen des anderen kennt.

Das Agentensystem verwendet die sich aus der hierarchischen Ortestruktur
ergebenden Sichtbarkeitsbereiche zur Bindung der Agenten "uber deren
Namen.

Dabei stehen folgende Varianten der Kontaktaufnahme zur Verf"ugung:

\begin{enumerate}

\item Rendezvous ohne Gespr"achsbeginn.

\item Synchroner Gespr"achsbeginn.

\item Asynchroner Gespr"achsbeginn.

\end{enumerate}

Im ersten Fall, dem Rendezvous zweier Agenten ohne einem Gespr"achsbeginn,
erh"alt der Initiator des Treffens ledigliche eine Referenz auf einen
anderen Agenten. Dieses Treffen (engl. {\em meeting}) ist das Basisprotokoll der
Kontaktaufnahme zweier Agenten und damit die Grundlage der beiden anderen
Varianten.

Ein wichtiger Aspekt des Treffens ist, da"s es sich um ein durch
das Agentensystem moderierten Rendezvous handelt. Der Initiatoragent teilt
seinen Kontaktwunsch dem Agentensystem mit, das die weitere Abwicklung des
erforderlichen Protokolls\footnote{Einzelheiten "uber die Abwicklung des
Protokolls finden sich im Kapitel \ref{AgentenBibliothek}.} durchf"uhrt. Das
Agentensystem ermittelt einen geeigneten Agenten innerhalb dessen aktuellen
Sichtbarkeitsbereiches und leitet den Kontaktwunsch weiter. Dieser Agent,
der Akzeptor, kann den Wunsch annehmen, ablehnen oder einen dritten Agenten
f"ur das Treffen vorschlagen.

Nimmt der Agent den Kontaktwunsch an, stellt das Agentensystem dem Initiator
eine Referenz auf den Akzeptor zur Verf"ugung. Das Agentensystem bewahrt dabei
die Autonomie der Partner, indem es nur k"unstliche
Objektreferenzen\footnote{Dies k"onnen zum Beispiel automatisch erzeugte,
weltweit eindeutige Bezeichner sein.} austauscht. Echte Objektreferenzen auf
Agenten sind nur innerhalb der Schicht des Agentensystems selber vorhanden und
werden unter keinen Umst"anden anderen Agenten sichtbar.

Lehnt ein Agent den Kontaktwunsch eines anderen Agenten ab, so wird dieser
dar"uber vom Agentensystem informiert. Der Agent hat dann keine M"oglichkeit,
mit dem Akzeptor zu interagieren. Die Existenz des potentiellen Partners bleibt
vor ihm verborgen.

Wenn der Akzeptor einen dritten Agenten vorschl"agt, wird das Treffen {\em
delegiert}. Dieser Mechanismus erlaubt, einfache Broker-Dienste in normale
Agenten zu integrieren. Das Agentensystem versucht in einem solchen Fall,
und f"ur den Initiator transparent, ein Treffen mit dem vorgeschlagenen Agenten
zu arrangieren. Dabei wird das Protokoll iterativ auf den neuen Agenten
angewendet.

Wird ein Treffen erfolgreich etabliert, so kann die erzeugte Referenz auf den
Partneragent verwendet werden, eine Konversation mit diesem zu beginnen. Im
Gegensatz zu dem in Telescript oder Mole verwendeten Rendezvousprotokoll ist
eine Migration der Partner auch nach Herstellung eines Treffens erlaubt. Dies
ist m"oglich, da die Agenten keine Objektreferenzen aufeinander erhalten sondern
indirekte Identifikatoren verwenden, die "uber das Agentensystem verwaltet
werden. Auf diese Weise bleiben die Objektgraphen der Agenten voneinander
isoliert und ihre Autonomie erhalten.

Der synchrone und der asynchrone Gespr"achbeginn unterscheiden sich nur im Grad
der Nebenl"aufigkeit innerhalb eines Agenten. Ein synchron begonnenes Gespr"ach
mu"s, im Unterschied zum asynchronen, erst vollst"andig beendet sein, bevor eine
andere Konversation initiiert werden kann. Dies entspricht einer {\em
sekund"aren} Konversation, die ebenfalls im Verarbeitungsmodell f"ur {\em
Business Conversations} definiert ist.

Im asynchronen Fall ist eine nebenl"aufige Gespr"achsf"uhrung mit mehreren
Partnern erlaubt. Dabei bleibt die Unteilbarkeit der Regelauswertungen
erhalten, lediglich die Konversationen als Ganzes "uberlappen sich.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/iafolg.eps}}
\caption{Regelauswertung innerhalb von Agenten}
\label{ruleexecution}
\end{figure}

Ein Agent, der ein Gespr"ach mit einem anderen Agenten beginnt, nimmt
automatisch f"ur dieses Gespr"ach die Rolle eines Kunden ein. Komplement"ar dazu
erh"alt der Akzeptor die Rolle des Dienstleisters. Die durch die
unterschiedliche Gespr"achsarten implizierten Interaktionsfolgen sind in
Abbildung \ref{ruleexecution} wiedergegeben.

\subsection{Agentengeneratoren}
\label{Agentengeneratoren}
Ein Entwurfsziel des Agentensystems ist, die Anwendungsentwicklung nicht durch
die Programmierung von Agenten zu behindern. Agenten sollen daher nicht vom
Anwendungsprogrammierer an das Agentensystem angebunden werden. Vielmehr sind
Generatoren\footnote{Z.B. implementiert durch Klassen einer objektorientieren
Implementierungssprache} oder generische Bibliotheken sinnvoll, die es
gestatten, spezialisierte Agenten durch Parametrierung eines allgemeinen
Musters zu erzeugen.

Diese Agentengeneratoren sind Bestandteil der Agentenumgebung, da sie auf
die verwendeten Interaktionsprotokolle des Agentensystems ausgelegt sein
m"ussen.

Die Parametrierung erfolgt gem"a"s der durch das Agentensystem implementierten
Kooperations- und Interaktionsprotokolle. Immer dann, wenn der Agent von Au"sen,
d.h. vom System beeinflu"st wird, ist da"s Agentenmuster zu spezialisieren. F"ur
die bereits geschilderten Leistungen sind dies:

\begin{itemize}
\item Die Erzeugung bzw. Beendigung eines Agenten oder Ortes.
\item Die Nachfrage eines fremden Agenten oder Ortes nach einem Treffen.
\item Nur bei Agenten: Eintritt in einen neuen Ort bzw. Verlassen eines Ortes.
\item Nur bei Orten: Eintritt eines neuen Agenten bzw. Verlassen eines Agenten.
\end{itemize}

An diesen Punkten der vom Agentensystem implementierten Protokolle kann der
Anwendungsprogrammierer das Agentenmuster "andern. In Kapitel
\ref{abstraktprgmodell} wird gezeigt, wie dies in einem konkreten Fall aussehen
kann.

Eine weitere Parametrierung im Sinne einer Konfiguration des Agenten erfolgt
zur Laufzeit. Hier kann der Agent seine Regelbasis zur Bearbeitung von
Konversationen mit anderen Agenten aufbauen und so seine kooperativen
F"ahigkeiten "uber die Zeit ver"andern. Nur wenn der Agent sowohl
Konversationsspezifikationen als auch Bearbeitungsregeln f"ur diese aufweist,
kann er mit andern Agenten kooperieren. Ein Agent ohne Regelbasis f"ur
Konversationen kann lediglich "uber das Meeting-Protokoll wirken. Hier kann er
Nachfragen bez"uglich Treffen an andere Agenten weiterleiten.
Orte haben zus"atzlich die M"oglichkeit, die Migration fremder Agenten in
ihren Sichtbarkeitsbereich abzulehnen oder zu gestatten.

\subsection{Migrationsunterst"utzung}

Das Agentensystem hat weiter die Aufgabe, die Reise eines Agenten an einen
gew"unschten Zielort durchzuf"uhren.

Bei einer Reise kann ein Agent innerhalb einer Dom"ane bleiben oder aber diese
verlassen. Das Agentensystem sorgt in beiden F"allen f"ur die Abwicklung des
erforderlichen Migrationsprotokolls. Ist der Zielort in der gleichen Dom"ane
angesiedelt, so werden nur die internen Datenstrukturen des lokalen
Agentensystems angepa"st. Ist ein Ort einer anderen Dom"ane das Reiseziel, so
mu"s das Agentensystem den Transport des Agenten "uber ein Rechnernetz
durchf"uhren. Zu diesem Zweck ist eine Konvertierung des Agenten in eine
linearisierte Darstellung erforderlich. Dabei m"ussen die Objektreferenzen, die
ein Agent an das lokale Agentensystem hat, getrennt werden. Diese Referenzen
k"onnen dann nach der Migration an das in der Zieldom"ane vorhandene
Agentensystem gebunden werden, um dem Agenten eine Interaktion mit diesem zu
erm"oglichen\footnote{Dies ist immer m"oglich, da das Agentensystem
f"ur alle Zielsysteme ubiquit"ar ist.}.

Die Migration in eine fremde Dom"ane mu"s transaktional erfolgen, da sonst
im Falle von "Ubertragungsfehlern Dubletten eines Agenten auftreten k"onnen.
Auch besteht sonst die Gefahr das ein Agent bei der "Ubertragung verloren
geht \cite{Mat96,tde95}. Diese Gefahr erh"oht sich, wenn eine Migration "uber
ein Weitverkehrsnetz (WAN) erforderlich wird.

Eine weitere Aufgabe, die den Einsatz des Agentensystems bei einer transienten
Verbindung zum Netz erm"oglichen, ist die Verz"ogerung der Abreise eines
Agenten. Dabei werden alle Agenten, die die Dom"ane verlassen wollen, gesammelt
und bei der n"achsten Verbindung zum Rechnernetz in einem Stapelverfahren
verschickt. Auf der anderen Seite k"onnen zu diesem Zeitpunkt auch Agenten von
einem vereinbarten ``Parkplatz'' abgeholt werden. Dies ist eine Dom"ane, die
eine permanenten Verbindung zum Rechnernetz besitzt und von Agenten immer dann
angelaufen werden kann, wenn die gew"unschte Zieldom"ane zum Migrationszeitpunkt
nicht erreichbar ist.

\section{Nachrichtensubsystem}
\label{Nachrichtensubsystem}

Das Nachrichtensubsystem stellt die Grundlage der Kommunikation aller
Systemkomponenten dar. Es hat die Aufgabe, das Agentensystem von der auf dem
Rechnerknoten eingesetzten Kommunikationsinfrastruktur bzw. der konkreten
Netztopologie abzukoppeln. Auf diese Weise k"onnen beliebige Middleware-Systeme
zur Realisierung der erforderlichen Netzwerkkommunikation eingesetzt werden und
das Agentensystem von Details der Netzwerkprogrammierung abgeschirmt werden. Im
Hinblick darauf, da"s Agenten sowohl lokal miteinander kommunizieren k"onnen als
auch mit entfernten Agenten anderer Knoten Konversationsbeziehungen unterhalten,
bietet das Nachrichtensubsystem ortstransparente Kommunikationsformen an.

Ein weiteres Erfordernis aus der Sicht des Agentensystems ist die
Unterst"utzung der Mobilit"at der Klienten des Nachrichtensystems. Dieses  mu"s
gew"ahrleisten, da"s die Mobilit"at seiner Klienten w"ahrend der Nutzung des
Systems erhalten bleibt. Diese Mobilit"at bedingt weiter, da"s das
Nachrichtensystem nicht von einer permanenten Erreichbarkeit seiner Klienten
ausgehen kann und schlie"st daher verbindungsorientierte Kommunikationsformen
aus.

Da Agenten und Orte durch autonome Aktivit"aten repr"asentiert werden und
diese daher voneinander unabh"angig agieren, stellt ein zentrales
Nachrichtensystem einen potentiellen Flaschenhals des Gesamtsystems dar. Es ist
daher f"ur den Durchsatz des Systems f"orderlich, ein derartiges zentrales
System nur kurze Zeit durch seine Klienten zu blockieren. Aus diesem Grunde
verwendet das System asynchrone, nachrichtenorientierte Verfahren als Basis der
Kommunikation zwischen seinen Klienten. Dabei wird jede Nachricht eines Klienten
an das Nachrichtensystem weitergegeben und gilt damit f"ur diesen als versendet.
Dem Nachrichtensystem obligt die Sicherung der tats"achlichen Zustellung einer
Nachricht, wobei der Sender mit dem System vereinbaren kann, mit welcher
Qualit"at diese versendet werden soll.

Auf der Seite des Nachrichtensystems erfordert dies eine die Reihenfolge
erhaltende Zwischenspeicherung der Nachrichten in Nachrichtenwarteschlangen 
(engl. {\em message queue}) und ein store-and-forward Protokoll f"ur deren
Versand \cite{KV89}. Diese Nachrichtenwarteschlangen werden vom
Nachrichtensubsystem verwaltet und gew"ahrleisten die korrekte Zustellung einer
Nachricht, auch wenn die Zielapplikation zeitweilig nicht erreichbar ist
\cite{MSMQ95}.

Ein weiterer Vorteil dieser Kommunikationsform ist, da"s sie die einfachste (im
Vergleich zu RPC oder ROI)  und zugleich flexibelste Form darstellt.
Von eine Applikation versendete Nachrichten k"onnen bei Bedarf beliebig
umgeleitet, kopiert oder ver"andert werden. Ein Einsatzgebiet f"ur diese
Flexibilit"at ist das "Uberwachen des Nachrichtenflusses (engl. {\em
monitoring}) oder externe Router, die Nachrichten an andere Zielsysteme
weiterleiten. Das dem Agentensystem zugrundeliegende Nachrichtensubsystem,
dessen Implementation in Kapitel \ref{AgentenBibliothek} beschrieben wird, sieht
hierf"ur das Konzept sog. Mediatoren vor, die eine aktive Schnittstelle f"ur
solche Systemdienste darstellen. Dabei handelt es sich aus der Sicht des
Nachrichtensubsystems um externe Dienste, die von diesem beim Nachrichtenversand
gesondert ber"ucksichtigt werden. Ein solcher Mediator erh"alt transparent jede
verarbeitete Nachricht und kann entscheiden, ob und in welcher Form diese
Nachricht an das vom Sender gew"unschte Ziel weitergeleitet wird.

\section{Anforderungen an Implementationsplattformen}

F"ur eine effiziente Implementation des beschriebenen Agentensystems sollte die
verwendete Platt\-form\footnote{Die M"oglichkeit, einen eigenen
``Agenteninterpreter'' f"ur eine sonst ungeeignete Implementationsplattform zu
schaffen wird au"seracht gelassen.} Un\-ter\-st"ut\-zung in den Punkten Mo\-bi\-li\-t"at,
Aktivit"atsorientierung, Kommunikation und Offenheit bieten. Unter dem
Gesichtspunkt der Anwendungsn"ahe des Agentenkonzepts ist eine
aus\-drucks\-m"a\-cht\-ige Sprache zur Beschreibung der Objekte einer Anwendung
ebenfalls w"unschenswert.

Die Mobilit"at der Agenten, die sich auf einem weltweiten elektronischen
Marktplatz der Dienste bewegen, macht eine Ber"ucksichtigung der Heterogenit"at
in der Systemlandschaft unumg"anglich. Eine L"osung f"ur dieses Problem bietet
die Ausf"uhrung des Agentensystem auf einer virtuellen Maschine, die eine
Abstraktion von der realen Systemplattform bietet
\cite{Sun95a,CGHLP95,Kna95,Mat96}. Diese virtuelle Maschine bildet die
Ausf"uhrungsumgebung sowohl f"ur das Agentensystem als auch f"ur die Agenten
selbst.

Nicht nur der Programmcode der Agenten mu"s in einer plattformunabh"angigen
Repr"asentation vorliegen, sondern auch die "uber Systemgrenzen ausgetauschten
Daten (z.B. die Nachrichten und der Ausf"uhrungszustand eines Agenten) m"ussen
systemweit einheitlich dargestellt sein. Hierf"ur gibt es bereits Standards, wie
die ASN.1 \cite{NV92} der ISO oder die {\em Network Data Representation} (NDR)
im DCE \cite{Schi93}, welche dieses leisten.

Das Agentenmodell impliziert ein ausgepr"agt nebenl"aufiges Programmierleitbild.
Jeder Agent im System stellt eine eigene, autonome Aktivit"at dar, die ihren
eigenen Kontrollflu"s besitzt.

Demzufolge ist eine Systemunterst"utzung f"ur nebenl"aufiges Programmieren
unabdingbar. Die Implementationsplattform sollte daher Prozesse\footnote{
Proze"s wird hier als Oberbegriff verwendet und schlie"st leichtgewichtige
Prozesse, sog. Threads, mit ein.} und Synchronisationsmechanismen,
wie Semaphore, bereitstellen.

Mobilit"at erfordert weiterhin die M"oglichkeit, einen Agenten und seinen
aktuellen Zustand aus dem Kontext eines Agentensystems zu isolieren und in einem
anderen Kontext (d.h. einer anderen Dom"ane) wieder zu etablieren. Die hierf"ur
erforderlichen Bindungstechniken stehen ebenfalls in einigen Systemen bereits
zur Verf"ugung \cite{Mat96,tde95,Kna95}.

Die Einbindung bereits bestehender Anwendungssysteme (engl. {\em legacy
systems}), in den vom Agentensystem gebildeten elektronischen Dienstemarkt ist
eine wichtige Voraussetzung f"ur den Erfolg eines solchen Systems. Daher ist die
Offenheit der Implementationsplattform notwending als Grundlage der Integration
dieser Altsysteme in neue, agentenbasierte Dienste.

Eine Kommunikationsunterst"utzung ist durch die vom Agenten- und
Nachrichtensystem geschaffenen Abstraktionen nur minimal notwendig. Weder das
Agentensystem, noch das Nachrichtensubsystem erfordern hier spezielle, h"ohere
Dienste (Trader, Schnittstellen-Repositories, Object Request Broker etc.), wie
sie z.B. von DCE oder CORBA \cite{OMG91} angeboten werden. Stattdessen
erm"oglicht das Agentensystem auf der Anwendungsebene eigene, wiederum durch
Agenten implementierte Dienste, die nicht von der jeweils verwendeten Middleware
abh"angig sind.

