% PARTOF texte:da/tex/a_home.tex
% chapter Eine generische Tycoon-Bibliothek f’r mobile Agenten
%------------------------------------------------------------------------------
\chapter{Eine generische Tycoon-Bibliothek f"ur mobile Agenten}
\label{AgentenBibliothek}

In diesem Kapitel wird der konkrete Entwurf der Umgebung f"ur mobile
Software-Agenten und dessen Realisierung beschrieben. Die Implementation besteht
aus einer Reihe generischer Modulbibliotheken f"ur das Tycoon-System, welches im
vorherigen Kapitel bereits vorgestellt wurde. Entsprechend der Konzeption des
Agentensystems gliedern sich die im Rahmen dieser Arbeit realisierten Module in
drei separate Bereiche:

\begin{enumerate}
\item Kooperationsunterst"utzung: Implementation des {\em Business
Conversation}-Modells.

\item Kommunikationsunterst"utzung: Implementation des Nachrichtensubsystems.

\item Koordination: Realisierung des Agentensystems und der Agentengeneratoren.

\end{enumerate}

Um den Grad der Wiederverwendbarkeit zu erh"ohen, wurde bei der
Umsetzung darauf geachtet, die Module der einzelnen Systembereiche unabh"angig
von ihrer Nutzung durch das Agentensystem zu realisieren. Die Module zur
Kooperationsunterst"utzung sind daher auch f"ur Anwendungen einsetzbar,
die {\it nicht} agentenbasiert verteilt werden sollen. Gleiches
gilt f"ur das Nachrichtensubsystem, welches als allgemeine Basisinfrastruktur
f"ur kommunikationsintensive und stark nebenl"aufige Anwendungen dienen kann,
auch wenn diese keinerlei Agententechnologie verwenden.

\section{Realisierung des {\em Business Conversation}-Modells}

Die im {\sl TBCEnv}\footnote{Tycoon Business Conversations Environment}
angesiedelten Module bilden die Basis der Kooperation zwischen zwei
Kommunikationspartnern, wie sie das {\em Business Conversation}-Modell
definiert.

Die Module dieser Bibliothek erzeugen alle Objekte, "uber die ein
Informationsaustausch zwischen autonomen Kooperationspartnern abgewickelt
wird. Analog zum Modell wird auch hier zwischen Konstruktoren f"ur
Spezifikationsobjekte und den aus ihnen erzeugten Instanzobjekten
unterschieden.

Eine wichtige Pr"amisse f"ur die Umsetzung des {\em Business
Conversation}-Modells ist, da"s TBC-Objekte per Definition keinem der
Gespr"achspartner ``geh"oren''. Dies bedeutet, beide Partner stimmen darin
"uberein, da"s der jeweils andere "uber alle ihm zug"anglichen TBC-Objekte frei
verf"ugen kann. Insbesondere hat jeder Konversationspartner das Recht, jedes
TBC-Objekt kopieren bzw. manipulieren zu d"urfen. Dies ist nat"urlich bei der
Realisierung von Massendatenobjekten besonders zu ber"ucksichtigen, um die
Effizienz einer Applikation nicht zu gef"ahrden.

Kopiervorg"ange, in denen TBC-Objekte involviert sind, treten in der praktischen
Anwendung h"aufig auf, da jede Konversation zwischen entfernten Partnern eine
"Ubertragung von Dialogobjekten "uber ein Netzwerk erfordert. Auch die Tatsache,
da"s zu jeder Konversation automatisch eine Historie aller ausgetauschten
Dialogobjekte angelegt wird, f"uhrt zu potentiellen TBC-Objektkopien im Falle
einer Agentenmigration.

Die Schnittstellen der einzelnen Module sind im Anhang \ref{tycTBCSpecs}
in Ausz"ugen wiedergegeben.

\subsection{Dialoginhalt und dessen Spezifikation}

Grundlage jeder Konversation ist die Notwendigkeit, die Struktur eines
Dialoges beschreiben zu k"onnen. Zu diesem Zweck bietet das Modul {\sl
tbcContent.tm} kombinierbare Konstruktoren f"ur die Erzeugung von
Inhaltsspezifikationen gem"a"s dem Modell aus Abbildung \ref{tbcspec}.

Ein einfaches Spezifikationsobjekt zur Beschreibung von Inhaltsobjekten des
Typs ``nat"urliche Zahl'' wird durch

\begin{xple} $=>$ let anyInt = tbcContent.intSpec() \end{xple}

generiert. Alle Spezifikationskonstruktoren erzeugen, unabh"angig von den durch
sie beschriebenen Instanzobjekten, ein Objekt vom Typ {\sl :tbcContent.Spec},
welches die Strukturinformation der Instanzobjekte kapselt.

Dabei er"offnet die uniforme Behandlung aller darstellbaren Spezifikationen
durch Objekte erster Klasse die M"oglichkeit der reflektiven Programmierung
"uber diesen Spezifikationsobjekten. Diese Technik findet in der 
werkzeugunterst"utzten Modellierung \cite{gei95} und der dynamischen
Modell"uberpr"ufung Anwendung.

Ein komplexeres, zusammengesetztes Inhaltsspezifikationsobjekt wird z.B. wie
folgt erzeugt:

\begin{xple}
\begin{tabbing}
\hspace*{0.7cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
\>$=>$ let person = tbcContent.rcdSpec of \\
\>\>\>tuple ``name'' \ tbcContent.stringSpec() end \\
\>\>\>tuple ``first'' \ tbcContent.stringSpec() end \\
\>\>\>tuple ``age'' \ tbcContent.intSpec() end \\
\>\>\>tuple ``birthday'' \ tbcContent.dateSpec() end \\
\>\>end
\end{tabbing}
\end{xple}

Mit Records bzw. varianten Records ist es m"oglich, benannte Komponenten zu
aggregieren. Die Komponentenobjekte k"onnen bei einer Instantiierung des
umfassenden Spezifikationsobjektes des Rekords "uber den entsprechenden Namen, z.B. {\em birthday}, erreicht werden.

Die Operationen, welche auf solchen Spezifikationsobjekten erlaubt sind, werden
durch den offengelegten varianten Tupeltyp {\sl :Spec} festgelegt. Bei
Spezifikationsobjekten, die atomare Instanzobjekte beschreiben, kann nur der
jeweilige Instanzobjekttyp ermittelt werden. Bei den Aggregationen kann
zus"atzlich noch die Menge der enthaltenen Spezifikationsobjekte und deren
Bezeichner festgestellt werden. Die Auswahl- und Sequenzspezifikationsobjekte
besitzen nur genau ein Elementspezifikationsobjekt, das ebenfalls "uber eine
Methode des umgebenden Spezifikationsobjektes ermittelt werden kann.

Aus jeder durch kombinieren erzeugbaren Inhaltsspezifikation k"on\-nen mittels
{\sl tbcContent.create(\dots)} Instanzobjekte erzeugt werden. Deren Struktur
wird ist das Spezifikationsobjekt beschrieben:

\begin{xple}
$=>$ let fred = tbcContent.create(person)
$=>$ let heinz = tbcContent.create(person)
\end{xple}

Jedes Objekt nimmt im Laufe dieses Instantiierungprozesses einen
definierten Ausgangszustand an, der von der Art des jeweiligen Objektes
abh"angt.

Die Operationen, die auf den so instantiierten Inhaltsobjekten erlaubt sind,
werden durch den varianten Tupeltyp {\sl tbcContent.T} beschrieben. Jedes
erzeugte Inhaltsobjekt ist "uber die Operation {\sl spec()} selbstbeschreibend
und erm"oglicht so den Zugriff auf das Spezifikationsobjekt, aus dem es erzeugt
wurde.

F"ur atomare Objekte sind weiterhin Operationen zum Lesen und Schreiben des
gekapselten Objektzustandes vorgesehen. Records erm"oglichen, durch die auf
ihnen definierte {\sl ref(\dots)} Operation, den Zugriff auf die aggregierten
Komponentenobjekte. Bei einem varianten Record besteht dar"uber hinaus die
M"oglichkeit, eine der Varianten zu w"ahlen oder die aktuell gew"ahlte Variante
zu ermitteln. Zu jeder dieser Varianten geh"oren eigene Komponenten, so da"s die
Menge der mittels {\sl ref(\dots)} erreichbaren Komponenten von der aktuell
ausgew"ahlten Variante bestimmt wird.

Die Auswahlobjekte f"ur einfache und mehrfache Auswahlen erlauben die Selektion
eines oder mehrerer Objekte aus einer vorzugebenden, endlichen
Menge\footnote{Der Typ der in der Menge enthaltenen Objekte wird durch das
zugeh"orige Elementtyp-Spezifikationsobjekt festgelegt.}. Die Schnittstelle
dieser beiden Objektarten unterscheidet sich lediglich darin, da"s die
Mehrfachauswahl eine Operation {\sl discard(\dots)} zum entfernen bereits
getroffener Auswahlen aus der Ergebnismenge vorsieht. Im Gegensatz zur einfachen
Auswahl darf die Ergebnismenge der Mehrfachauswahl auch leer sein.

Die Implementation des vom {\em Business Conversation}-Modell vorgesehenen
Massendatencontainers {\em Sequence} kann f"ur jede Sequenz einzeln bestimmt
werden. Wird ein solches Sequenzobjekt erzeugt, so verwendet dieses eine
einfache Standardimplementation f"ur Sequenzen, bei der die in der Sequenz
enthaltenen Daten {\em Teil} des Containerobjektes werden. Das
Protokoll f"ur Containerobjekte erm"oglicht es, diese Standardimplementation
f"ur Sequenzen gegen andere auszutauschen, wenn dies z.B. aus Gr"unden der
Effizienz oder im Hinblick auf Verteilungsanforderungen gew"unscht wird.

Zu diesem Zweck definiert das Interface {\sl TBCContent.ti} den Tupeltyp {\sl
:Sequence}, welcher das eigentliche Zugriffsprotokoll auf die im
Sequenzcontainer gekapselten Massendaten festlegt. Eine konkrete
Sequenzimplementation mu"s die hier definierten Operationen {\sl
elements(\dots)} und \- {\sl fromIter(\dots)} anbieten, mit denen zwischen
Elementen der Sequenz (TBC-Objekte vom Typ {\sl :tbcContent.T}) und den
modellierten Massendaten auf TL-Seite abgebildet wird. Eine derartige
Sequenzimplementation kann dann an ein bereits instantiiertes Sequenzobjekt
gebunden werden und ersetzt damit die Standardimplementation f"ur dieses Objekt.

Neben der Erzeugung eines Inhaltsobjektes aus einem Spezifikationsobjekt bietet
das Modul {\sl tbcContent.tm} noch die Funktion {\sl copy(\dots)}, mit der ein
ggf. strukturiertes Inhaltsobjekt unter Beibehaltung seines aktuellen Zustands
kopiert werden kann. Eine solche Kopie besitzt einen eigenen, vom Original
getrennten Zustand und eine identische Struktur. F"ur den Sequenzcontainer
ist zu beachten, da"s der Objektzustand die jeweilige Sequenzimplementation ist.
Daher nutzen Original und Kopie dieselbe Sequenzimplementation und referenzieren
"uber diese auch dieselben Sequenzen.

\subsection{Konversationsspezifikationen}

Aufbauend auf den Inhaltsspezifikationsobjekten bietet das Modul {\sl
tbcSpec.tm} Konstruktoren f"ur die Erzeugung von Anfrage-, Dialog- und
Konversationsspezifikationen.

Ein Konversationsspezifikationsobjekt wird mit der Funktion {\sl
tbcSpec.new(\dots)} aus einer anzugebenden Menge von
Dialogspezifikationsobjekten erzeugt. Jede dieser, mit {\sl
tbcSpec.newDialog(\dots)} erzeugten, Dialogspezifikationsobjekten enth"alt
wiederum eine Menge benannter Inhaltsspezifikationsobjekte und eine Menge
erlaubter Anfragen. Ein Dialogspezifikationsobjekt ist dabei als Spezifikation
des initialen Dialogs der beschriebenen Konversation zu kennzeichnen.

\subsection{Konversationen}

Das Modul {\sl tbConv.tm} stellt Funktionen zur Erzeugung von
Konversationsobjekten zur Verf"ugung, welche aus den
Konversationsspezifikationsobjekten des Moduls {\sl tbcSpec.tm} generiert
werden. Neben diesen Konversationsobjekten definiert das Modul die Schnittstelle
zu Dialogobjekten, die in den Konversationsobjekten enthalten sind.

Jedes Konversationsobjekt besitzt einen eigenen, innerhalb von TL typisierten
Zustand, "uber den ein externer Gespr"achskontext modelliert werden kann.
Dar"uber hinaus ist das Objekt selbstbeschreibend, da es den Zugriff auf das
zugrundeliegende Spezifikationsobjekt der Konversation erlaubt.

Weiter bietet ein Konversationsobjekt "uber die Operation {\sl
newDialog(\dots)} die M"oglichkeit, einen neuen Dialog gem"a"s der zugeh"origen
Dialogspezifikation zu erzeugen. Dieser neue Dialog wird gleichzeitig der
aktuelle Dialog der Konversation. Eine Referenz auf das letzte erzeugte
Dialogobjekt kann mit der Operation {\sl currentDialog(\dots)} ermittelt werden.

Dar"uber hinaus f"uhrt ein Konversationsobjekt eine lokale Historie "uber
Dialogobjekte. Auf sie kann mittels der Operationen {\sl saveDialog(\dots)} und
{\sl copyHistoryDialog(\dots)} und zugegriffen werden. Die Identifikation eines
Dialogs geschieht "uber dessen Bezeichner. Die Operation {\sl saveDialog(\dots)}
speichert ein angegebenes Dialogobjekt auf dem Stapel. Die Operation {\sl
copyHistoryDialog(\dots)} erzeugt eine Kopie des j"ungsten Dialogobjekts im
Stapel mit der angegebenen Bezeichnung.

Ein Konversationsobjekt wird "uber die Funktion {\sl new(\dots)} aus dem
angegebenen Konversationsspezifikationsobjekt erzeugt und an einen initialen
Gespr"achskontext gebunden. Ein Dialogobjekt, welches mit der Operation {\sl
newDialog(\dots)} eines Konversationsobjektes generiert wird, erlaubt den Zugriff
auf dessen Inhaltsobjekte und das zugeh"orige Spezifikationsobjekt.

Desweiteren sind in dem Modul {\sl tbConv.tm} eine Reihe von im {\em Business
Conversation}-Modell vorgesehene, systemimmanente Dialoge, Anfragen und
Spezifikationsobjekte definiert. Neben der initialen Anfrage, die von jedem
Kunden zu seinem Dienstleister gesendet wird und die daher nicht Teil einer
Gespr"achsspezifikation zwischen diesen sein kann, ist das der initiale Dialog
und ein spezieller Ausnahmedialog, der {\sl breakdownDialog}. Diese Objekte
sind ebenfalls nicht Teil einer anwendungsabh"angigen
Konversationsspezifikation. Ihre Struktur kann jedoch ermittelt werden, da alle
Dialogobjekte -- auch der initiale und der Ausnahmedialog -- "uber ihre
Spezifikationsobjekte selbstbeschreibend sind.

\section{Nachrichtenorientierte Kommunikation}

Grundlage des Agentensystems ist das Nachrichtensubsystem einer Dom"ane, welches
den Nachrichtenverkehr zwischen allen kommunizierenden Komponenten abwickelt.

Gem"a"s dem Architekturmodell aus Abbildung \ref{AgEnvKonzeptModell} ist dieses
Nachrichtensubsystem aus der Sicht der Agenten eine ubiquit"are Ressource, kann
daher in jeder Dom"ane vorausgesetzt werden.

Das System ist bindungsarm und mobilit"atsorientiert entworfen. Es ist daher
isolierbar und relinkf"ahig, d.h alle vom System erzeugten Objekte enthalten
keine direkten Referenzen auf Objekte anderer Systemnutzer. Dies gilt
insbesondere f"ur die wichtigsten vom Nachrichtensystem verwendeten TL-Objekte
vom Typ {\sl $:Port$}, welche die symbolisch adressierbaren
Kommunikationsendpunkte der Systemnutzer repr"asentieren. Das System verarbeitet
statisch typisierte Nachrichten, deren Struktur in dem TL-Interface {\sl
ITCMessage.ti} offengelegt werden mu"s.

Die Struktur des als aktive Komponente ausgelegten Nachrichtensubsystems ist in
Abbildung \ref{ITCModell} dargestellt.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/itcstrkt.eps}}
\caption{Modell des Nachrichtensubsystems}
\label{ITCModell}
\end{figure}

Die Architektur ist in Anlehnung an das {\em Message Handling
System (MHS)} \cite{KV89} der ISO-Empfehlung entworfen worden. Die wesentlichen
Eigenschaften des realisierten Nachrichtensubsystems sind:

\begin{itemize}
\item Bereitstellen einer Abstraktion von lokaler und entfernter Kommunikation
f"ur dessen Nutzer.

\item Abstraktion von der konkreten Netzwerkumgebung, den Netzwerkprotokollen
und der Netzwerkprogrammierung.

\item Unterst"utzung der Kommunikation mit Anwendungen, die tempor"ar nicht
erreichbar sind.

\end{itemize}

Die Abstraktion von lokaler und entfernter Kommunikation wird durch die
zentrale Komponente des Nachrichtenrouters (engl. {\em Message Router})
erreicht, welcher den Flu"s einer Nachricht anhand der angegebenen Zieladresse
bestimmt. Im Falle eines lokalen Empf"angers wird die Nachricht direkt an den
angegebenen Kommunikationsendpunkt zugestellt und ggf. der Besitzer dieses
Endpunktes benachrichtigt.

Ist ein entfernter Kommunikationsendpunkt Ziel der Nachricht, so wird
diese "uber die Transportkomponente (engl. {\em Message Transport}) an
das entsprechende Nachrichtensubsystem "ubermittelt und dort in Empfang
genommen. Dabei "ubernimmt die Transportkomponente auch den
Empfang der Nachrichten, die "uber das Rechnernetz zugestellt werden. In einem
solchen Fall ist der Routingkomponente, "uber die Kontrollkomponente, zur
(lokalen) Weiterleitung der Nachricht involviert.

Alle empfangenen Nachrichten werden in Briefk"asten (engl. {\em mailbox})
verwaltet, die ihren Besitzern nur indirekt und ohne eine Objektbindung
zugeordnet sind. Ein Besitzer kann so den Ort eines Briefkastens verlassen und
trotzdem weiter Nachrichten empfangen. Diese Nachrichten k"onnen sp"ater bei
seiner R"uckkehr entgegengenommen werden. Die Briefk"asten werden "uber
Nachrichtenwarteschlangen modelliert, die die Empfangsreihenfolge zweier
Nachrichten erhalten.

Die Kommunikationskomponente ist nicht auf eine Nutzung durch Agenten oder das
Agentensystem festgelegt. Normale Tycoon-Threads sind ohne besondere Ma"snahmen
in der Lage, die Funktionen des Nachrichtensubsystems zu verwenden und "uber
dieses miteinander zu kommunizieren.

Das durch die Anwendungsprogrammierschnittstelle (API) definierte, generelle
Anwendungsschema ist in Abbildung \ref{itcuse} dargestellt. Die vollst"andige
Schnittstelle zum Nachrichtensubsystem ist im Anhang \ref{tycNSS} wiedergegeben.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/itcuse.eps}}
\caption{Benutzung des Nachrichtensubsystems}
\label{itcuse}
\end{figure}

Das Nachrichtensubsystem stellt Funktionen sowohl zum synchronen, als auch zum
asynchronen Nachrichtenaustausch zur Verf"ugung. Dabei wird zwischen privaten
und "offentlichen Kommunikationsendpunkten unterschieden. Nur die "offentlichen
Kommunikationsendpunkte werden benannt und k"onnen daher symbolisch adressiert
werden. Nachrichten, die an einen privaten Port versendet werden sollen
erfordern, da"s Sender und Empf"anger ein Port-Objekt teilen\footnote{Eine Kopie
des Objektes ist ebenfalls verwendbar.}. Die Port-Objekte fungieren als
weltweit eindeutige Bezeichner eines Kommunikationsendpunktes und k"onnen
beliebig kopiert oder auch als Teil einer Nachricht versendet werden.

Das realisierte Nachrichtensubsystem, d.h. insbesondere die Transportkomponente,
basiert auf TCP/IP Sockets zum Empfang und zum Versand von Nachrichten, jeweils
von bzw. an andere Nachrichtensubsysteme im Rechnernetz. Dabei wird f"ur den
Zeitraum des Nachrichtversands eine Socketverbindung zwischen den betroffenen
Nachrichtensubsystemen hergestellt. Die ggf. erforderliche IP-Adressaufl"osung
geschieht in der aktuellen Implementation durch den Namensdienst des
Internet, den {\em Domain Name Service} (DNS).

Eine Adressaufl"osung mittels der weltweit eindeutigen Identifikatoren der
Kommunikationsendpunkte ist bislang nicht vorgesehen, jedoch lassen sich die in
\cite{Goe96} beschriebenen Mechanismen transparent einsetzen.

\subsection{Mediatoren}

Ein {\em Mediator} ist ein spezieller, optionaler Systemdienst des
Nachrichtensubsystems.  Auf jedem Knoten, auf dem ein Nachrichtensubsystem
eingerichtet ist, kann ein solcher Mediator konfiguriert werden.
Dieser stellt sich gegen"uber dem Nachrichtensubsystem als normaler Klient dar,
benutzt aber einen speziell vereinbarten Kommunikationsendpunkt f"ur den Empfang
von Nachrichten. Hat das Nachrichtensubsystem einen lokalen Mediator erkannt, so
wird dieser beim Routing aller im folgenden "uber die Kommunikationskomponente
versendeten Nachrichten ber"ucksichtigt. Dabei erh"alt der Mediator jede
Nachricht, die an einen "offentlichen Kommunikationsendpunkt adressiert ist,
bevor diese an den Empf"anger ausgeliefert wird. Er hat dann das Recht, die
Nachricht zu manipulieren, zu duplizieren, zu unterdr"ucken, umzuleiten oder
unver"andert zustellen zu lassen.

Der f"ur das Agentensystem beispielhaft implementierte Mediator verwaltet
priorisierte Dienste, sog. Mediator-Services. Diese bilden eine nach
absteigender Priorit"at sortierte Dienstkette, bei der jeder enthaltene Dienst
eine Nachricht maximal einmal sieht. Nur, wenn alle Dienste die Nachricht {\sl
sm} mit {\sl sm.delegateMessage()} an den jeweils n"achsten Dienst in der Kette
weiterleiten, wird diese dem Empf"anger zugestellt.

Ein Mediator wird auf einem Knoten mit

\begin{xple}
$=>$ let m = mediator.new()
\end{xple}

eingerichtet. Danach k"onnen beliebige Mediatordienste mittels der
Operation \- {\sl m.addService(\dots)} am Mediator registriert werden.

Sowohl der lokale als auch der entfernte Nachrichtenverkehr unterliegt dem
Mediator eines Knotens. Daher wird eine Nachricht, die nicht lokal zugestellt
werden kann, zweimal betrachtet: einmal von dem lokalen Mediator und einmal in
dem entfernten. Mediator-Dienste besitzen hierbei eine Sonderrolle die es ihnen
erlaubt, Nachrichten zu versenden, welche nicht durch den lokalen Mediator
bearbeitet werden.

Das Konzept der Mediator-Dienste entspricht dem der ODP-Interzeptorobjekte und
erm"oglicht es an zentraler Stelle, nachtr"aglich Systemdienste einzurichten,
die das Verhalten einer Dom"ane als Ganzes betreffen. Sie eignen sich daher zur
Realisierung von Loggingdiensten, Protokollumsetzern, Routern oder zur zentralen
Einrichtung von Sicherheitsmechanismen.

\section{Agentensystem}

"Ahnlich dem Nachrichtensubsystem wird das Agentensystem einer
Dom"ane durch ein ubiquit"ares Modul, das Modul {\sl agent.tm}, repr"asentiert,
welches die Administrations- und Applikationsschnittstelle zur
Ausf"uhrungsumgebung gegen"uber den Agenten bildet. Die vollst"andige
Schnittstelle ist im Anhang \ref{tycAgent} wiedergegeben.

Das Agentensystem einer Dom"ane wird "uber die Operation {\sl
agent.startDomain()} auf dem aktuellen Knoten etabliert und ist danach als
Migrationsziel f"ur andere Agenten erreichbar. Die Komponenten des
Agentensystems sind in Abbildung \ref{AEKomponenten} dargestellt.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/aephys.eps}}
\caption{Komponenten der Ausf"uhrungsumgebung}
\label{AEKomponenten}
\end{figure}

Alle Agenten und Orte einer Dom"ane werden in entsprechenden Verzeichnissen
der Dom"ane verwaltet. Diese Verzeichnisse bilden die Grundlage der
verschiedenen Dienste, wie sie vom Agentensystem angeboten werden. Neben der
Verwaltung dieser Verzeichnisse lassen sich die Aufgaben des Agentensystems
in drei getrennte Kategorien einteilen:

\begin{itemize}
\item Agentenerzeugung bzw. Umgebungssteuerung
\item Kooperationssteuerung
\item Migrationssteuerung und Portal
\end{itemize}

Neben den speziellen Aufgaben der Komponenten aus jeder dieser Kategorien, die
in den folgenden Abschnitten n"aher dargestellt werden, sorgt das Agentensystem
f"ur die korrekte Abwicklung der jeweiligen Protokolle auf der Basis von
Nachrichten. Diese Nachrichten werden zwischen den beteiligten Agenten und dem
Agentensystem, "uber das Nachrichtensubsystem der Dom"ane, ausgetauscht.

Das generelle Strukturmodell der Objekte und ihrer Beziehungen, die durch das
Agentensystem verwaltet bzw. verwendet werden, ist in Abbildung \ref{aeosm}
dargestellt.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/aeosm.eps}}
\caption{Strukturmodell der Objekte des Agentensystems}
\label{aeosm}
\end{figure}

Die zentralen Objekte dieser Darstellung sind der {\em Agent} und das
Bindungsobjekt (engl. {\em Binding}). Objektreferenzen an Agentenobjekte sind
nur innerhalb eines Agentensystems definiert. Nach au"sen, d.h. gegen"uber
Agenten bzw. an der Schnittstelle zum Agentensystem, wird ein abstrakter
Identifikator ({\em AgentHandle}) verwendet. Dieser ist weltweit eindeutig
und wird "uber das Agentensystem, genauer "uber die dort verwalteten
Bindungsobjekte, den konkreten Agentenobjekten zugeordnet. Auf diese Weise
k"onnen diese indirekten Referenzen auf Agenten verwendet werden ohne deren
Autonomie zu beeintr"achtigen. Das Agentensystem verbirgt die konkreten
Objektreferenzen auf Agenten vollst"andig durch seine Programmierschnittstelle.
Teil des Identifikators eines Agenten ist zum einen sein Name, der der
anwendungsnahen Bezeichnung des Agenten dient, und zum anderen der Identifikator
seines Erzeugers und die Adresse des Ortes, an dem er erzeugt wurde.

Das Objekt Dom"ane (engl. {\em Domain}) repr"asentiert in dieser Darstellung
einen systemimmanenten Ort, welcher automatisch beim Start des Agentensystems
eingerichtet wird. Dieser Ort bildet die Wurzel der in der Dom"ane vorhandenen
Ortehierarchie. Er beherbergt die Administrationsschnittstelle der Dom"ane und
hat als einziger Ort, durch seine Verankerung im Agentensystem, direkten Zugriff
auf die Datenstrukturen und Verzeichnisse des Agentensystems. Auf diese Weise
k"onnen sich Konversationen dieses Agenten auf den aktuellen Status des
Agentensystems beziehen.

\subsection{Agentenerzeugung}

Die Erzeugung von Agenten, sowohl von mobilen Agenten als auch von
immobilen Orten mit ihren Orte-W"achtern, wird durch das Agentensystem
vorgenommen. Eine Beschreibung der Komponenten eines solchen {\em
Agentenskeletts} wird im Abschnitt \ref{Agentenskelett} gegeben. Wesentlich an
dieser Stelle ist, das jeder Agent aus einem Anwendungsteil und einem Systemteil
besteht. Der Systemteil ist f"ur alle Agenten gleich und beinhaltet die
Protokollabwicklungskomponente, die die Verbindung zwischen dem Anwendungsteil
und dem Agentensystem darstellt.

Ein neuer Agent wird durch die Operation {\sl agent.new(\dots)} erzeugt. Das
zugeh"orige Protokoll, welches vom Agentensystem durchgef"uhrt wird, besteht in
den Schritten:

\begin{enumerate}
\item Ermittlung des Ortes, in dem der Agent erzeugt werden soll.

\item Erzeugung des Agentenskeletts. Mit dem Systemteil des Agenten k"onnen ab
jetzt Nachrichten ausgetauscht werden. Der Anwendungsteil des Agenten ist
jedoch noch inaktiv.

\item Erzeugung des Bindings zwischen Agent und Agentensystem. Das Binding
enth"alt bereits alle Informationen zu dem neuen Agenten.

\item Zustimmung des Ortes einholen, welcher den Agenten aufnehmen soll. Dies
f"uhrt zu einer Aktivierung der {\sl incomingAgent(\dots)} Methode des
zugeh"origen Orte-W"achters, der auf diesem Wege den eindeutigen Bezeichner des
neuen Agenten erh"alt.

\item Wenn der Orte-W"achter der Erzeugung zustimmt, wird der Agent als Besucher
des Ortes gef"uhrt, ansonsten wird das Binding bzw. das Agentenskelett wieder
zerst"ort und das Protokoll endet mit einer Ausnahme auf der Seite des
Agenten\footnote{Agenten und Orte k"onnen auch von jedem Tycoon-Thread erzeugt
werden.}, welcher die {\sl agent.new(\dots)} Operation ausgel"ost hat.

\item Aktivierung des Anwendungsteils des Agenten durch die Ausf"uhrung seiner
{\sl birth(\dots)} Methode.

\item R"uckgabe des weltweit eindeutigen Bezeichners des neuen Agenten.

\end{enumerate}

Die Erzeugung eines Ortes folgt demselben Protokoll. Die fr"uhe
Generierung des Agentenskeletts und des Bindings hat zur Folge, da"s ein Agent
gegebenenfalls wieder zerst"ort werden mu"s, bietet jedoch die M"oglichkeit der
aktiven Beteiligung des Agenten an der Protokollabwicklung.

Die Verzeichnisse des Agentensystems werden mit der Instantiierung des
Bindungsobjektes (engl. {\em Binding}) aktualisiert. Daher kann der
Orte-W"achter des Ortes, welcher den neuen Agenten aufnehmen soll, Informationen
"uber diesen ermitteln, noch bevor er vom Agentensystem vollst"andig aktiviert
wurde.

\subsection{Kooperationssteuerung}

Die Kooperationssteuerung des Agentensystems hat die Aufgabe, die Kooperation
zwischen Agenten zu koordinieren. Zu diesem Zweck implementiert es die
Protokolle f"ur die Operationen \\ {\sl agent.meet(\dots)} und {\sl
agent.meetAndTalk(\dots)}.

Das grundlegende Protokoll f"ur Agententreffen {\sl meet}, in dessen Verlauf
Agenten Referenzen auf fremde Agenten erhalten k"onnen, dient der
Kontaktaufnahme eines Agenten mit einem anderen Agenten am selben Ort "uber
dessen {\em Namen}:

\begin{xple}
\begin{tabbing}
\hspace*{0.7cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
$=>$ let wspAgent = \\
\>\>agent.meet(self \ ``WebSiteProfiler'' \ wspSpec \ timeOutSecs)

\end{tabbing}
\end{xple}

Der mit {\sl self} bezeichnete Agent initiiert das Treffen-Protokoll mit
dem Ziel, eine Referenz auf einen Agenten mit dem Namen ``WebSiteProfiler'' zu
erhalten. Die Kooperationssteuerung durchl"auft zu diesem Zweck folgendes
Protokoll:

\begin{enumerate}

\item Ermittlung eines Agenten mit dem gesuchten Namen. Das Agentensystem
versucht, innerhalb des Ortes an dem sich der suchende Agent $a_1$ befindet und
innerhalb der mit {\em timeOutSecs} nach unten beschr"ankten Zeitspanne, einen
Agenten mit dem angegebenen Namen zu ermitteln.

\item Kann ein solcher Agent $a_2$ ermittelt werden, so wird diesem der Wunsch
nach einem Treffen mit Agent $a_1$ mitgeteilt. Andernfalls wird eine Ausnahme in
dem Agenten $a_1$ ausgel"ost.

\item Im Agent $a_2$ wird die {\sl meet(\dots)} Methode ausgef"uhrt, mit der
er dem Wunsch nach dem Treffen mit $a_1$ zustimmen oder diesen ablehnen kann.
Lehnt er ihn ab, so wird im Agenten $a_1$ eine Ausnahme ausgel"ost. Im Falle
einer Zustimmung kann der Agent auch einen weiteren Agenten $a_3$ bestimmen,
welcher das Treffen mit $a_1$ behandeln soll. Geschieht dies, so wird dieser
Schritt iterativ ausgef"uhrt, bis ein Agent $a_n$ entweder das Treffen mit
$a_1$ endg"ultig ablehnt oder es selbst annimmt. Jede Weiterleitung wird wie ein
gesondertes Treffen behandelt, so da"s die im {\em timeOutSecs} vorgegebene
Zeitspanne f"ur jedes Treffen erneut zur Verf"ugung.

\item R"uckgabe des weltweit eindeutigen Bezeichners des ermittelten Agenten.

\end{enumerate}

Kernpunkt dieses Protokolls ist die Ausf"uhrung der {\sl meet(\dots)} Methode im
ermittelten Agenten. Auf diese Weise erh"alt der Agent Kenntnis von dem
suchenden Agenten (d.h. dessen Identifikation) und von der Spezifikation einer
Konversation, die dieser mit dem Agenten zu f"uhren w"unscht.

Die Implementation von {\sl agent.meetAndTalk(\dots)} ist eine Spezialisierung
der geschilderten \\ {\sl agent.meet(\dots)} Operation. Statt im letzten Schritt
den Identifikator des ermittelten Agenten zur"uckzugeben, initiiert die
Kooperationssteuerung gleich eine {\em synchrone} Konversation zwischen dem
ermittelten Agenten und dem suchenden Agenten, zu der im {\sl
meetAndTalk(\dots)} angegebenen Konversationsspezifikation. Dies zwingt den
suchenden Agenten in die Rolle des Kunden und erfordert vom ermittelten Agenten
die Rolle des Dienstleisters bez"uglich der
Konversationsspezifikation.

Die Abwicklung des Verarbeitungsmodells einer begonnenen {\em Business
Conversation} wird ohne die Mitwirkung der Kooperationssteuerung des
Agentensystems zwischen den beteiligten Agenten durchgef"uhrt. Die zust"andigen
Protokollkomponenten der Agenten sind jedoch vollst"andig im Agentenskelett
verankert, welches wiederum durch das Agentensystem erzeugt worden ist.

\subsection{Migrationssteuerung und Portal}

Die Migration von Agenten zwischen Orten, sowohl innerhalb einer Dom"ane als
auch in den Bereich einer anderen Dom"ane hinein, wird durch die Komponente der
Migrationssteuerung durchgef"uhrt. Ist bei einer Migration ein Wechsel der
Dom"ane erforderlich, so wird in der entfernten Dom"ane zus"atzlich deren
Portaldienst involviert, welcher den reisenden Agenten entgegennimmt und in der
neuen Dom"ane reaktiviert. Ist kein Dom"anenwechsel erforderlich, so ist f"ur
die Migration des Agenten lediglich eine "Anderung in den lokalen Verzeichnissen
des Agentensystems erforderlich. Im Einzelnen wird bei jeder Agentenmigration,
ausgel"ost durch die Operation {\sl agent.migrateTo(\dots)}, von der
Migrationssteuerung folgendes Protokoll verwendet:

\begin{enumerate}
\item Ermittlung, ob lokale Migration vorliegt. Diese wird durch das lokale
Migrationsprotokoll implementiert, welches vom Portal (s.u.) verwendet wird.
Die weiteren Schritte sind nur bei einem Wechsel der Dom"ane erforderlich.

\item Start eines tempor"arem Threads, dem Versanddienst, f"ur die Kommunikation
mit dem entfernten Portal. Das Agentensystem erh"alt keine Objektreferenz auf
diesen Thread, so da"s keine unerw"unschten Bindungen an den zu versendenden
Agenten im Agentensystem verbleiben k"onnen.

\item Vorbereitung des Agenten. Der Systemteil des Agenten wird aufgefordert,
sich auf den bevorstehenden Versand vorzubereiten. Dabei werden insbesondere
alle Bindungen an das Nachrichtensubsystem durch den Agenten isoliert und der
Agent in einen definierten Ruhezustand "uberf"uhrt.

\item Versand. Der Agent wird als Teil einer Nachricht an das entfernte
Agentensystem (genauer dessen Portal) versendet. Der lokale Versanddienst
wartet auf die Best"atigung der erfolgreichen Reaktivierung des Agenten durch
das entfernte Portal.

\item Abschlu"s der Migration. Wird die erfolgreiche Migration durch das
entfernte Portal best"atigt, so reaktiviert der Versanddienst den Systemteil
der nun "uberfl"ussigen, lokalen Kopie des Agenten. Der Agent terminiert
daraufhin ordnungsgem"a"s. Dem letzten Aufenthaltsort des Agenten wird das
Verlassen des Agenten "uber dessen {\sl outgoingAgent(\dots)} Methode
signalisiert. War die Migration nicht erfolgreich, so wird der lokalen Kopie des
Agenten dies durch den Versanddienst mitgeteilt und der Agent bleibt erhalten.

\end{enumerate}

Das entsprechende Protokoll auf der Seite des Portaldienstes, welcher beim
Start jeder Dom"ane eingerichtet wird, ist wie folgt implementiert:

\begin{enumerate}
\item Eintreffen eines Agenten. Nachdem der Agent $a_1$, der sich im definierten
Ruhezustand befindet, an dem Portal eintrifft, wird der Systemteil des Agenten
vom Portal reaktiviert.

\item Lokale Migration. Das Portal holt die Zustimmung des Wurzelortes seiner
lokalen Ortehierarchie zum Zutritt des fremden Agenten ein. Zu diesem Zweck
l"ost es in dem entsprechenden Orte-W"achter die {\sl incomingAgent(\dots)}
Methode aus, "uber die der W"achter Kenntnis von dem Agenten $a_1$ erh"alt.
Stimmt der Orte-W"achter dem Eintritt zu, so "andert das Portal die lokalen
Verzeichnisse des Agentensystems. Ist das Reiseziel des Agenten ein Ort
unterhalb der Wurzel, so f"uhrt das Portal diese lokale Migration iterativ aus.
Immer, wenn dabei ein Ort verlassen wird, signalisiert das Portal dem
entsprechenden W"achter dieses Ereignis "uber die {\sl outgoingAgent(\dots)}
Methode.

\item Abschlu"s der Migration. Hat jeder Ort auf dem Weg des Agenten Einlass
gew"ahrt, so best"atigt das Portal dem entfernten Versanddienst den
erfolgreichen Dom"anenwechsel und reaktiviert den Anwendungsteil des
Agenten. Andernfalls erh"alt der entfernte Versanddienst eine negative
Best"atigung und die lokale Kopie des Agenten wird vernichtet.

\end{enumerate}

Die Migration wird in dieser Implementation nicht transaktional gesichert, so
da"s im Falle eines Dom"anenausfalls oder einer gest"orten Kommunikation
w"ahrend der Migration sowohl Dubletten eines Agenten auftreten k"onnen als auch
ein Agent verloren gehen kann. In \cite{Mat96} sind jedoch Mechanismen
beschrieben, mit denen ein zweiphasiges Best"atigungsprotokoll \cite{GrRe93} zur
Sicherung der Migration gegen Systemausf"alle, unter Verwendung des
Tycoon-Systems, eingesetzt werden kann.

\section{Agenten}
\label{Agentenskelett}

Agenten bestehen aus einem Systemteil, der durch das Agentensystem generiert
wird und einem Anwendungsteil, der "uber eine Parametrisierung zum Zeitpunkt der
Generierung eines Agenten bestimmt wird.

Abbildung \ref{agphys} zeigt das "Ubersichtsmodell der Komponenten, die den
Systemteil jedes Agenten bilden.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/agphys.eps}}
\caption{"Ubersichtsmodell eines Agenten}
\label{agphys}
\end{figure}

Der Systemteil eines Agenten hat die Aufgabe, die Verbindung zwischen dem
Anwendungsteil und dem Agentensystem bereitzustellen. Auf diese Weise ist es
m"oglich, den Anwendungsteil eines Agenten vollst"andig von der Abwicklung der
einzelnen Protokolle des Agentensystems abzukoppeln. Auf der anderen Seite kann
sich jedes Agentensystem seinerseits auf die korrekte Abwicklung der einzelnen
Protokollschritte verlassen, da diese nicht durch die konkrete Verwendung eines
Agenten beeinflu"st werden k"onnen.

Ein Agent besteht im wesentlichen aus drei aktiven Komponenten:

\begin{enumerate}
\item Die Kontrollkomponente.
\item Regelausf"uhrungskomponente f"ur Dienstleisterrollen ({\em PRX}).
\item Regelausf"uhrungskomponente f"ur Kundenrollen ({\em CRX}).
\end{enumerate}

Die Kontrollkomponente stellt das Bindeglied zwischen dem Agentensystem und dem
Agenten dar. Sie besitzt einen "offentlich zug"anglichen Kommunikationsendpunkt,
"uber den jedwede Interaktion der Au"senwelt mit dem Agenten stattfindet.

Die zur Implementation des Verarbeitungsmodells der {\em Business Conversations}
notwendige Regelauswertung geschieht getrennt von der Kontrollkomponente in
der jeweiligen Regelauswertungskomponente. Die Auswertung der Bearbeitungsregeln
erfolgt in einem eigenen Tycoon-Thread, da diese Regeln zum Anwendungsteil des
Agenten gerechnet werden m"ussen. Daher kann das Verhalten dieser Regeln nicht
vorherbestimmt werden, insbesondere kann durch sie eine Migration des Agenten
veranla"st werden. In deren Verlauf ist es gem"a"s dem bereits geschilderten
Migrationsprotokoll notwendig, den Kontrollflu"s eines Agenten in einen
definierten Ruhezustand zu "uberf"uhren, um ihn dann versenden zu k"onnen. Durch
die Realisierung in voneinander getrennten Threads ist es direkt m"oglich, den
Regelausf"uhrungspunkt innerhalb der Migrationsoperation zu fixieren, ohne dabei
den Systemteil des Agenten zu inaktivieren. Dieser kann so f"ur die weitere
Protokollabwicklung, speziell bei der schrittweisen Reaktivierung des Agenten in
der Zieldom"ane, genutzt werden.

Der Bedarf f"ur zwei Regelauswertungskomponenten begr"undet sich durch die im
{\em Business Conversation} Modell definierte Konversationsform der sekund"aren
Konversation zwischen zwei Agenten. Diese synchrone, eingeschobene
Konversation erfordert einen tempor"aren Rollenwechsel des Agenten f"ur die
Dauer der eingeschobenen Konversation. Der momentane Ausf"uhrungspunkt der
initiierenden Bearbeitungsregel kann durch die Kontrollkomponente fixiert
werden, indem der zugeh"orige Thread in den Zustand {\sl suspended} "uberf"uhrt
wird. Die Regelauswertung f"ur die sekund"are Konversation "ubernimmt dann der
noch verbleibende, aktive Thread. Ist die Konversation beendet, so wird die
Bearbeitung der suspendierten Regelauswertung wieder aufgenommen.

Die Regelauswertungskomponenten verwalten die Menge der aktiven Konversationen,
die Menge der m"oglichen Konversationen ("uber die dem Agenten bekannten
Konversationsspezifikationen) und die jeweiligen Bearbeitungsregeln, die zu
einer Konversationsspezifikation geh"oren.

Die Kontrollkomponente hat, parallel zur aktiven Regelauswertung durch die
Regelauswertungskomponenten, Zugriff auf die Verzeichnisstrukturen des Agenten.
Daher kann ein Agent, auf der Ebene von Systemnachrichten und unabh"angig von
seinem momentanen Zustand auf der Ebene der {\em Business Conversations},
Auskunft "uber seinen aktuellen, internen Zustand geben. Dies ist hilfreich,
wenn ein Agent potentiell langandauernden Bearbeitungsregeln ausf"uhrt.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/agntosm.eps}}
\caption{Objektstrukturmodell eines Agenten}
\label{agentosm}
\end{figure}

Die Abbildung \ref{agentosm} zeigt die Objektstrukturmodellierung der Objekte
und ihrer Beziehungen, die vom Systemteil des Agenten verwaltet werden.

Ein neuer Agent wird durch das Agentensystem "uber die Operation
{\sl agent.new(\dots)} erzeugt:

\begin{xple}
\begin{tabbing}
\hspace*{0.7cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
$=>$ let wspAgent = agent.new(initialContext \\
\>\>\>birth \ meet \ die \ leave \ enter \\
\>\>\>agent.currentRootPlace() \ ``WebSiteProfiler'')
\end{tabbing}
\end{xple}

In diesem Beispiel wird ein Agent mit dem Namen ``WebSiteProfiler'' erzeugt und
im Wurzelort der aktuellen Dom"ane angesiedelt. Der Anwendungsteil des Agenten
wird durch die Funktionsparameter {\sl birth(\dots), meet(\dots), die(\dots),
leave(\dots) und enter(\dots)} bestimmt, die vom Systemteil des Agenten in die
entsprechenden Protokolle integriert werden.

Der {\sl initialeContext} eines Agenten ist n"utzlich, um Bindungen zu
aggregieren, welche in allen Protokollmethoden sichtbar sein sollen. Die
Aggregation dieser Bindungen in einem expliziten Kontextobjekt tr"agt dabei zur
Strukturierung eines Agenten bei.

Die {\sl birth(\dots)} Methode des Agenten erlaubt die Initialisierung der
kooperativen F"ahigkeiten eines Agenten und/oder die Erzeugung von Agenten, die
ein Skript abarbeiten. Die "ubergebene Funktion wird ausgef"uhrt, wenn der Agent
durch das Agentensystem erfolgreich im angegebenen Ort erzeugt wurde. Die
Anwendung kann dann innerhalb der Funktion die Rollen und Bearbeitungsregeln des
Agenten registrieren:

\begin{xple}
\begin{tabbing}
\hspace*{0.7cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
let p = agent.addPerformerRole(:Ok \ self \ wspConvSpec \ fun() ok) \\
\>p.set(tbConv.initialDialogName() \ tbConv.initialRequest() \\
\>\>fun(cv :agent.Conversation(Ok)) :tbConv.Dialog \ begin \\
\>\>\> \dots \\
\>end)
\end{tabbing}
\end{xple}

Die auf diese Weise registrierten Regeln werden in den Kunden- und
Dienstleisterregelbasen des jeweiligen Agenten gespeichert. Die Regeln, und
damit die F"ahigkeiten eines Agenten, werden in der aktuellen Implementation
ebenfalls "uber Nachrichten "ubergeben. Es ist daher m"oglich,
die Regelbasis eines Agenten nach dessen Erzeugung zu erweitern oder zu "andern
und ihn so dynamisch an sich "andernde Anforderungen anzupassen.

Die {\sl die(\dots)} Methode eines Agenten wird ausgef"uhrt, bevor ein Agent
terminiert. Zu diesem Zeitpunkt darf ein Agent weder neue Konversationen
eingehen, noch seine Migration veranlassen oder andere Agenten erzeugen. Die
Operation dient lediglich einer geordneten Beendigung der Aufgaben des Agenten.
Die {\sl die(\dots)} Methode wird nicht ausgef"uhrt, wenn ein Agent (oder
dessen Kopie) im Laufe des Migrationsprotokolls vernichtet werden soll.

\subsection{Orte}

Orte, genauer die Orte-W"achter, sind eine Spezialform der Agenten. Sie
unterscheiden sich lediglich in der Parametrisierung bei der Erzeugung
durch das Agentensystem. Der strukturelle Aufbau eines Orte-W"achters entspricht
dem beschriebenen Agentenskelett.

Ein Ort wird vom Agentensystem z.B. durch

\begin{xple}
\begin{tabbing}
\hspace*{0.7cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
$=>$ let redaktion = agent.newPlace(initialContext \\
\>\>birth \ meet \ die \ incomingAgent \ outgoingAgent \\
\>\>agent.currentRootPlace() \ ``SpiegelRedaktion'')
\end{tabbing}
\end{xple}

erzeugt. Die Ortehierarchie einer Dom"ane wird inkrementell aufgebaut, indem ein
neuer Ort immer unterhalb der Hierarchiestufe des angegebenen Ortes eingerichtet
wird. Bezeichnet der angegebene Agent keinen Ort, so wird stattdessen der Ort
verwendet, an dem sich dieser momentan aufh"alt\footnote{Ist dieser
jedoch nicht zu ermitteln, so wird der neue Ort nicht erzeugt.}.

Da Orte immobil sind, besitzt ein Orte-W"achter nicht die Methoden {\sl
enter(\dots)} und {\sl leave(\dots)}. Stattdessen werden Orte-W"achter vom
Agentensystem "uber die Methoden {\sl incomingAgent(\dots)} und {\sl
outgoingAgent(\dots)} "uber das Eintreffen und Verlassen von Agenten in ihren
Sichtbarkeitsbereich informiert.


