% PARTOF texte:da/tex/a_home.tex
% chapter Ein abstraktes Programmiermodell
%------------------------------------------------------------------------------
\chapter{Das abstrakte Programmiermodell}
\label{abstraktprgmodell}

In diesem Abschnitt wird die verteilte Datenbankanwendung des
``MultiSiteAnalyzers'' agentenbasiert modelliert. Ziel ist es, die Verwendung
der im Kapitel \ref{umgebung} vorgestellten Konzepte anhand eines realistischen
Beispiels zu demonstrieren. Es wird keine vollst"andige Realisierung des
MultiSiteAnalyzers gezeigt. Lediglich die aus der Sicht des Agentensystems
interessanten Teile sollen an dieser Stelle illustriert werden. Im Vordergrund
stehen dabei die Agenten bzw. Orte und nicht der bereits geschilderte Aufbau des
Agentensystems.

Zur Beschreibung der Agenten und Orte wird eine Pseudokode-Darstellung
verwendet, die es erlaubt, von den Details der konkreten Implementierung zu
abstrahieren. Diese wird dann in Kapitel \ref{AgentenBibliothek} beschrieben.

\section{Das Kooperationsmodell: Konversationen}

Das prim"are Ziel der mobilen Software\--Agenten ist es, Ko\-ordinations\--,
Kom\-munikations\-- und Mo\-bilit"ats\-aspekte aus einer
Anwendung herauszufaktorisieren. Auf diese Weise kann sich der
Anwendungsprogrammierer auf den {\em Anwendungsteil} seiner Applikation
konzentrieren, der durch die Agenten gebildete {\em Systemteil} ist generisch
und steht daher zur Verf"ugung. Durch die Verankerung definierter
Koordinations\-- und Kommunikationsmethoden im Systemteil k"onnen verschiedene
Anwendungen miteinander interagieren, ohne da"s dies explizit bei der jeweiligen
Anwendungserstellung ber"ucksichtigt werden mu"s.

Da das Modell der {\em Business Conversations} nicht nur eine
Modellierungsmethode darstellt, sondern auch ein definiertes
Verarbeitungsmodell, d.h. ein definiertes Interaktionsprotokoll zwischen den
Aktoren, besitzt, bildet es die Grundlage der Kooperation unter Agenten.

Dabei erfordert das {\em Business Conversations}-Modell die Offenlegung der
Kooperationsschnittstelle einer Anwendung in Form von {\em
Konversationsspezifikationen}. Diese Proze"sspezifikationen sind vollst"andig
medien- und aktorenunabh"angig. Eine Konversationsspezifikation, die von einem
Agenten genutzt wird, kann f"ur eine Kooperation unter menschlichen Aktoren
entwickelt worden sein. Das zugrundeliegende Spezifikationsobjekt ist uniform
und kann daher ohne Anpassung f"ur alle m"oglichen Arten von Aktoren
wiederverwendet werden.

Die von den Beispielagenten benutzten Konversationsspezifikationen werden
gem"a"s der Grammatik aus Abbildung \ref{Spec-Grammar} gebildet.
Auf eine vollst"andige Wiedergabe der f"ur die Anwendung erforderlichen
Spezifikationen wurde aus Gr"unden der "Ubersichtlichkeit verzichtet, jedoch ist
der in Abbildung \ref{ergebnissedialogspec} gezeigte Ausschnitt exemplarisch.
Die grafische Darstellung einer solchen Spezifikation, wie sie in Abbildung
\ref{wspkonvspec} gezeigt wird, bietet einen Eindruck "uber die vollst"andige,
vom {\em WebSiteProfiler} unterst"utzte Kooperationsschnittstelle, wie sie die
Beispielagenten verwenden.

\section{Beispielagenten}

``Internet WebSiteProfiler'' werden durch Orte innerhalb von Dom"anen
repr"asentiert. Diese Orte bilden die Ziele f"ur reisende Agenten der
ebenfalls durch Orte vertretenen ``MultiSiteAnalyzer''-Anwendungen im Netz.
In Abbildung \ref{pseudomsaort} findet sich die Pseudokodedarstellung eines
solchen ``MultiSiteAnalyzer''-Ortes.

Darin sind Funktionen, die vom lokalen Agentensystem einer Dom"ane exportiert
werden, durch den Prefix {\sl agent} gekennzeichnet. Obwohl auch durch mobile
Agenten referenziert, unterliegen diese Bindungen nicht der Mobilit"at der
Agenten. Stattdessen verweisen diese Referenzen nach einer Agentenmigration
transparent auf das in der jeweils aktuellen Dom"ane vorhandene Agentensystem.
Die hierf"ur notwendigen Bindungstechniken werden im Abschnitt
\ref{Bindungstechniken} n"aher beschrieben.

Jeder Ort wird innerhalb einer Dom"ane als Teil einer Orte-Hierarchie etabliert:

\begin{xple}
$=>$ agent.newPlace(owner \ msa)
\end{xple}

In diesem Kodefragment wird die Operation {\sl newPlace(\dots)} des aktuellen
Agentensystems nachgefragt. 

Das Agentensystem erzeugt, abh"angig von der Art des Besitzers (hier das
Argument {\sl owner}), einen neuen Ort. Bezeichnet {\sl owner} einen
Orte-W"achter, so wird der Ort des ``MultiSiteAnalyzers'' eine Hierarchieebene
unter der des angegebenen Ortes erzeugt. Der neue Ort kann dann nur "uber den
Ort {\sl owner} erreicht werden. Bezeichnet {\sl owner} jedoch eine mobilen
Agenten, so wird der neue Ort unterhalb der Hierarchieebene angelegt, die der
angegebene Agent momentan besucht. In beiden F"allen mu"s der "ubergeordnete Orte-W"achter der Erzeugung
zustimmen\footnote{Jede Dom"ane hat immer mindestens einen Ort; dieser bildet
die Wurzel der Orte-Hierarchie der Dom"ane.}.

\begin{figure}[pbt]
\input{msaplace-xple.tex}
\caption{Pseudokodedarstellung des MSA-Ortes}
\label{pseudomsaort}
\end{figure}

\begin{figure}[pbt]
\input{msaplace-xple-2.tex}
\caption{Pseudokodedarstellung des MSA-Ortes (Fortsetzung)}
\end{figure}

Ist ein Ort erfolgreich vom Agentensystem angelegt worden, so initiiert es
im zum Ort geh"orenden Orte-W"achter die Ausf"uhrung der {\sl
birth}-Methode, die jeder Agent implementiert. Diese Methode wird innerhalb
einer {\em k"unstlichen} Dienstleisterrolle vom Orte-W"achter atomar
ausgef"uhrt\footnote{Siehe Kapitel \ref{umgebungkooperation}.} und initialisiert
die Regelbasis des Agenten. Dabei werden die Rollen, die der Agent innerhalb
von Konversationen einnehmen kann, festgelegt. Der Agent bleibt nach der
Ausf"uhrung der {\sl birth}-Methode erhalten, wartet nun jedoch auf externe
Ereignisse. Dies k"onnen Gespr"achsaufforderungen bzw. Treffen mit anderen
Agenten sein. Bei Orten wird auch das Eintreffen, Erzeugen und Verlassen anderer
Agenten durch den Orte-W"achter registriert.

Der Beispiel-Ort des MSA vereinbart in seiner {\sl birth}-Methode zwei
Kundenrollen und eine Dienstleisterrolle. Innerhalb einer solchen Rolle
befinden sich die Bearbeitungsregeln, die die Reaktion des Agenten auf Dialoge
bzw. Anfragen, festlegen. Der MSA-Ort tritt gegen"uber einem nicht n"aher
ausgef"uhrten User-Interface Agenten in Form eines Dienstleisters auf
(definiert durch die {\sl msaGUIRole}-Rolle). Diese Rolle hat die Aufgabe,
Auftr"age f"ur die durch den Ort zu versendenden Boten-Agenten vom Benutzer der
MSA-Anwendung entgegenzunehmen.

Zu diesem Zweck werden in der Bearbeitungsregel f"ur ``Parameter''-Dialoge bei
``start''-Anfragen dynamisch die sogenannten {\em Boten-Agenten} erzeugt:

\begin{xple}
agent.new(self \ msaCollector \ ``MSA-Bote'')
\end{xple}

\begin{figure}[pbt]
\input{msacoll-xple.tex}
\caption{Pseudokodedarstellung des MSA-Botenagenten}
\label{pseudomsabote}
\end{figure}

Der Kode eines solchen Boten-Agenten ist in Abbildung \ref{pseudomsabote}
dargestellt.

Diese Boten, (die {\sl msaCollector}-Agenten), dienen der Interaktion mit den
``WebSiteProfiler'' Systemen und tragen jeweils einen Auftrag des MSA-Benutzers mit
sich. Jedem Boten wird der Ort seines ``WebSiteProfiler''-Systems mitgeteilt, zu
dem er reist.

Diese Auftragsvergabe geschieht "uber eine asynchrone Konversation zwischen
dem Boten und dem MSA-Orte-W"achter, die von dem W"achter mittels

\begin{xple}
collector = agent.meet(self \ ``MSA-Bote'' \ collectorSetupRole.spec \ 0)
\end{xple}

erfragt wird. Das Agentensystem vermittelt das Treffen mit dem Agenten
``MSA-Bote''\footnote{Um Namens"uberschneidungen zu verhindern, kann der Name
des Agenten auch aus einem generierten Bezeichner bestehen.}, dabei erh"alt
dieser Kenntnis sowohl von dem Initiator als auch von dessen gew"unschter
Konversationsspezifikation. Der letzte Parameter gibt an, wieviele Sekunden der
Agent auf das Zustandekommen eines Treffens warten will. Dabei bildet die Angabe
eine untere Schranke f"ur die Dauer in der ein Treffen vermittelt werden soll.

Die Konversation mit dem Boten wird danach vom MSA-Orte-W"achter an eine
bereits vorbereitete Rolle {\sl collectorSetupRole} gebunden:

\begin{xple}
collectorSetupRole.startConversation(agent \ collectorContext)
\end{xple}

Im letzten Schritt dieser Konversation migriert der Boten-Agent zu seinem
Zielort. Dort f"uhrt er dann autonom eine Konversation mit dem ans"assigen
WSP-Agenten, um die statistischen Daten gem"a"s seines Auftrags von diesem zu
ermitteln.

Ist die Migration des Boten zu seinem Bestimmungsort abgeschlossen, f"uhrt er
eine synchrone, sogenannte {\em sekund"are}, Konversation mit dem WSP-Agenten in
der Rolle eines Kunden:

\begin{xple}
agent.meetAndTalk(self \ ``WebSiteProfiler'' \ wspCustomerRole \ 30)
\end{xple}

Nach Beendigung dieser Konversation reist der Boten-Agent wieder an
seinen Ursprung zur"uck, um die ermittelten Daten an den MSA-Agenten
weiterzureichen.

\begin{xple}
agent.migrateTo(self \ self.home())
\end{xple}

Das Agentensystem der Dom"ane, an der der MSA-Ort angesiedelt ist, informiert
den entsprechenden MSA-Orte-W"achter "uber das Eintreffen eines Agenten.
Diese Benachrichtigung f"uhrt zu einer Aktivierung der {\sl
incoming\_agent}-Methode des Ortes. Auf diese Weise erh"alt der Ort Kenntnis
von dem Agenten, der eintreten will. Das erlaubt dem Orte-W"achter, mit dem
ankommenden Agenten eine Konversation zu beginnen. Ist der Ort nicht gewillt,
den Agenten in seinen Sichtbarkeitsbereich eintreten zu lassen, kann er dies
dem Agentensystem durch das Ergebnis der Methodenausf"uhrung mitteilen.

Im dem gezeigten Beispiel beginnt der MSA-Orte-W"achter eine Konversation mit
dem eintreffenden Botenagenten, die dazu verwendet wird, die mitgebrachten
Statistikdaten des Boten-Agenten dem MSA-Orte-W"achter zug"anglich zu machen.
Dieser kann auf diese Weise die Daten aller eintreffenden Agenten aggregieren
und diese Aggregation wiederum anderen Agenten zug"anglich machen.

Durch diese Art der Programmierung bilden die Boten-Agenten eine Form von {\em
intelligenten} Nachrichten, die z.B. auf auftretende Ausnahmesituationen bei
ihrem Empf"anger reagieren k"onnen.

\section{Synchronisation und Delegation}

Die verwendeten Koordinationsmechanismen Rendezvous und Konversation erm"oglicht
es, Kontakte zwischen zwei Agenten herzustellen, bei denen ein dritter Agent als
Vermittler auftritt. F"ur das beschriebene Beispielszenario zeigt dies Abbildung
\ref{syncunddelegation}.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/osembsp2.eps}}
\caption{Synchronisation und Delegation mittels Agenten}
\label{syncunddelegation}
\end{figure}

Der mit FM bezeichnete Agent ist der Stellvertreteragent eines Benutzers aus
der realen Welt. Stellverteter repr"asentieren Benutzer und deren Autorit"at
gegen"uber anderen Agenten innerhalb der modellierten Welt. Solche Agenten sind
nicht als vollst"andig autonom anzusehen, sie stellen die personalisierte
Verbindung von der realen zur modellierten Welt dar. In der Abbildung ist diese
Verbindung "uber eine HTTP-Anbindung realisiert. Der Stellvertreteragent
fungiert hierbei auch als Protokollumsetzer zwischen den HTTP-Nachrichten und
den {\em Business Conversations}.

Der Agent synchronisiert die unterschiedlichen Aktivit"aten f"ur
Protokollumsetzung und Dialogaustausch "uber die Serialisierung der
entsprechenden Nachrichten, die ihm "uber das Nachrichtensubsystem zugestellt
werden.

Werden Rendezvousanfragen "uber den Treffen-Mechanismus des Agentensystems an
den Agenten herangetragen, so k"onnen diese an andere Agenten {\em delegiert}
werden. Dies ist insbesondere dann sinnvoll, wenn sich ein Agent permanent an
einem Ort befindet, jedoch kein geeigneter Dienstleister vorhanden ist.
In diesem Fall kann der Kontaktwunsch eines Agenten $A_{1}$ von dem durch das
Agentensystem ermittelten Agenten $A_{2}$ an einen dritten Agenten $A_{3}$
weitergereicht werden.

Dieses Weiterleiten wird wiederholt, bis ein Agent entweder den Wunsch nach
einem Treffen durch Agent $A_{1}$ annimmt, oder diesen Wunsch endg"ultig
verweigert. F"ur den initiierenden Agent $A_{1}$ ist das Verfahren
transparent.

Die Agenten, die im Laufe des Protokolls vorgeschlagen werden, m"ussen 
notwendigerweise am selben Ort wie der Initiator des Treffens existieren.
Allerdings ist eine dynamische Erzeugung von Bearbeitern innerhalb des
Weiterleitungsprotokolls erlaubt. Auf diese Weise k"onnen Bearbeiteragenten von
einem zentralen Brokeragenten erzeugt werden, die individuelle Beziehungen zu
Agenten aufrechterhalten.

Das Agentensystem behandelt dabei jede Weiterleitung wie ein gesondertes
Treffen, so da"s ein Bearbeiteragent auch innerhalb der zum Treffen angegebenen
Warteperiode am Ort eintreffen darf.




