% PARTOF texte:da/tex/a_home.tex

\chapter{Mobile Software-Agenten}
\label{mobileagents}
Gegenstand dieses Kapitels sind mobile Software-Agenten. Anders als in den
vorangegangenen Abschnitten bezeichnet der Begriff {\em Agent} im diesem Kapitel
Software-Komponenten, die den bereits geschilderten Anforderungen bez"uglich
Kooperation und Autonomie gerecht werden. Es beginnt mit einer "Ubersicht der
unter dem Begriff Agent zusammengefa"sten unterschiedlichen Konzepte in der
Informatik. Danach werden exemplarisch f"unf Agentensysteme und Modelle
vorgestellt, die eine Grundlage f"ur die Modellbildung des in Kapitel
\ref{umgebung} beschriebenen Agentensystems bilden.

\section{Begriffsbestimmung}
\label{Begriffsbestimmung}

Der Begriff des ``Agenten'' ist nicht neu. Bereits seit ca. 10 Jahren wird diese
Bezeichnung auf fast jedes Gebilde der Informatik angewendet, das ein
Mindestma"s an Autonomie aufweisen kann. Die Folge dessen ist, da"s sich keine
konsistente Definition des Begriffs herausgebildet hat. Allerdings gibt es
Ans"atze, zumindest eine Klassifikation der unter diesem Begriff versammelten
Konzepte zu erreichen \cite{BeWo94}:

\begin{description}
\item[User Agents] aus dem Bereich der verteilten
k"unstlichen Intelligenz (VKI) sind adaptive, lernende und
selbstkonfigurierende Softwarebausteine. Ihre Aufgabe besteht darin,
T"atigkeiten auszuf"uhren, die im Normalfall ohne Agenten von deren menschlichen
{\em alter ego} wahrgenommen werden. Dabei versuchen die Agenten durch
Beobachten von sich wiederholenden T"atigkeiten des menschlichen Benutzers auf
Routineabl"aufe zu schlie"sen und diese dann an dessen Stelle auszuf"uhren.

\item[Leitagenten (Agent Guides)] werden Softwarekomponenten genannt, die in
der Rolle eines Lehrers Hilfestellung oder spezifisches Wissen an einen
menschlichen Benutzer vermitteln. Dabei unterst"utzen sie ihn kontextabh"angig
bei Problemen der Benutzung von komplexen Softwaresystemen. Sie bilden somit ein
flexibles Hilfesystem mit einer nat"urlichen (da einem menschlichem Vorbild
entsprechenden) Metapher.

\item[Autonome Agenten] werden charakterisiert durch ihren Grad an Autonomie
in Bezug auf die Ausf"uhrung der ihnen zugewiesenen Aufgaben. Sie sind in der
Lage, diese ohne weitere Interaktion mit dem Benutzer zu erledigen. Dabei
arbeiten sie losgel"ost von ihrem Benutzer und zwar sowohl zeitlich als auch
"ortlich. Dadurch sind sie in der Lage, gro"se Datenbest"ande ohne
aufrechterhalten einer permanenten Netzverbindung zu verarbeiten und nur die
relevanten Informationen dem Benutzer zu pr"asentieren.

\item[Symbiotische und kooperative Agenten] sind in der Lage, einen menschlichen
Benutzer bei der Erledigung seiner Aufgabe zu helfen. Sie sind damit eine Form
der Leitagenten, k"onnen aber dar"uber hinaus dem Benutzer alternative
Problemsichten darstellen oder ihn mit zus"atzlichen, f"ur die L"osung seines
Problems relevanten, Informationen versorgen.

\item[Anthropomorphe Agenten] imitieren Menschen. Diese Agenten stammen aus der
Dom"ane der ``Multi-User'' Spiele \cite{Fon93} und haben innerhalb des Spiels
die gleichen F"ahigkeiten wie menschliche Spieler, f"uhren dabei insbesondere
nat"urlichsprachliche Dialoge.

\item[Mobile Agenten] sind eine Form der autonomen Agenten, die die F"ahigkeit
zur Mobilit"at besitzen, d.h. sich aufgrund eigener Entscheidungen aktiv an
andere Orte bewegen zu k"onnen. Das bekannteste und kommerziell erh"altliche
System basierend auf Agenten dieser Art sind Telescript und Magic Cap
\cite{GM95} von General Magic, Inc.

\end{description}

Russel Beale und Andrew Wood geben in \cite{BeWo94} eine Definition des Begriffs
Agent, die in dieser Arbeit im weiteren Verlauf gelten soll: "`Ein Agent kann
als eine relativ einfache, heterogene, autonome und kommunizierende
Software-Komponente definiert werden; viele dieser Agenten existieren
gleichzeitig und arbeiten zusammen, um eine Aufgabe f"ur einen Benutzer zu
erf"ullen."'

"Uber diese generelle Definition hinaus z"ahlen die im weiteren betrachteten
Agenten, aufgrund ihrer geforderten Mobilit"at, zur Klasse der {\em mobilen
Agenten}.

\section{Verwandte Arbeiten}

In diesem Abschnitt werden verschiedene Referenzimplementationen f"ur
Agentensysteme vorgestellt. Dabei handelt es sich in erster Linie um Telescript,
ein kommerzielles Agentensystem der Firma General Magic. Desweiteren werden mit
Facile, Mole und COSY drei Ans"atze aus der Forschung vorgestellt, wobei es
sich bei COSY um ein System aus dem Gebiet der Verteilten K"unstlichen
Intelligenz (VKI) handelt. Abschlie"send wird kurz auf eine g"anzlich andere
Form mobiler Agenten, auf die der MIME-Agents, eingegangen.

\subsection{Telescript}

Telescript ist eine objektorientierte Programmiersprache f"ur die verteilte
Programmierung mit mobilen Agenten. Die Telescript-Technologie wurde f"ur den
Einsatz mit sog. ``Pers"onlichen Digitalen Assistenten (PDA)'' entwickelt.
F"ur das amerikanische Unternehmen General Magic ist Telescript das Fundament
f"ur verteilte Anwendungen unter Einbeziehung von PDA, PC, Telefonen und
Netzwerken.

Neben der Tatsache, da"s Telescript das erste kommerziell verf"ugbare
Programmiersystem f"ur mobile Agenten war, bildet das Denkmodell hinter
Telescript \cite{Whi94} die Grundlage verschiedener anderer Agentsysteme, wie
z.B. das im Abschnitt \ref{Mole} beschriebene Mole.

Telescript kennt die folgenden Konzepte: Orte, Agenten, Reisen, Treffen und
Kommunikationsverbindungen.

Orte strukturieren den Raum, in dem sich Agenten bewegen k"onnen. Sie bilden
eine logische Struktur innerhalb einer verteilten Umgebung, die sich an den in
ihr angebotenen Diensten und an den Autorit"aten der beteiligten Rechnersysteme
oder Dienstanbieter orientiert. Telescript geht von einer offenen
Dienstnutzungsumgebung, insbesondere f"ur den elektronischen Handel, aus. In
dieser Form bildet die offene Dienstnutzungsumgebung einen {\em elektronischen
Marktplatz}, auf dem sich Anbieter von Dienstleistungen mit ihren jeweiligen
Kunden treffen und interagieren.

Ein elektronischer Marktplatz ist untergliedert in viele verschiedene und
voneinander unabh"angige Orte. Ein solcher Ort, evtl. physisch auf einem PDA
gelagert, repr"asentiert das Zuhause eines Benutzers. Andere Orte stellen z.B.
virtuelle Kaufh"auser oder Unternehmen dar und sind auf andere Rechnersysteme,
m"oglicherweise "uber die ganze Welt, verteilt. Orte bilden untereinander eine
Hierarchie, k"onnen daher wiederum andere Orte enthalten. Auf diese Weise wird
die elektronische Welt, "ahnlich der realen Welt, in Unternehmen, Abteilungen,
Unterabteilungen, R"aume o."a. unterteilt.

Jeder Ort repr"asentiert, innerhalb der elektronischen Welt, ein Individuum oder
eine Organisation, die sog. Autorit"at, aus der realen Welt.

Orte k"onnen nun dynamisch von Agenten bev"olkert werden, um mit den anderen
Agenten desselben Ortes zu interagieren. Jeder Agent kann mittels einer Reise
zu beliebigen anderen Orten gelangen, sofern der Zielort den Eintritt gew"ahrt.
Anbieter und Kunden, jeweils durch Agenten repr"asentiert, k"onnen auf diese
Weise zueinander gelangen, um miteinander zu handeln.

Zusammengefa"st besitzt das Telescript-System folgende
Eigenschaften \cite{tde95}:

\begin{itemize}
  \item objektorientiert ("ahnlich Smalltalk: alles ist ein Objekt)
  \item Klassen, Vererbung, Mixins (eine Art der Mehrfachvererbung)
  \item interpretierter Bytecode (virtuelle Maschine)
  \item orthogonale Persistenz als Grundlage f"ur Mobilit"at
  \item Sicherheitsmechanismen
  \item spezielle, autonomieerhaltende Objektbindungen
  \item Ressourcenkonzept "uber Teleclicks
  \item Multithreading
  \item Interaktionsprotokolle
  \item Kommunikationsmechanismen
  \item Anbindung externer Dienste m"oglich

\end{itemize}

Neben einem "Ubersetzer, der Telescript-Kode in den Bytecode der virtuellen
Maschine wandelt, besteht das System aus einer Laufzeitumgebung (engl. {\em
engine}), die auf jedem Knoten des Telescript-Netzes installiert sein mu"s.

Diese Laufzeitumgebung bietet die Kerndienste f"ur Mobilit"at und Kooperation
von Agenten und den Betrieb der Orte. Sie beinhaltet im wesentlichen die
virtuelle Maschine und die Anbindung an das Netzwerk. Desweiteren
implementiert sie die Sicherheitsmechanismen, Authentisierung, Autorisierung und
autorisiert die Mitnahme von Objekten anderer Besitzer im Falle einer Migration
von Agenten an einen anderen Ort.

Die Telescript-Programmiersprache bietet eine Reihe von Mitteln, den Zugriff auf
Objekte (d.h. deren Referenzen) zu kontrollieren. Zu diesem Zweck ist es
m"oglich, Objektreferenzen zu sch"utzen (sog. {\em protected references}), so
da"s die von ihnen bezeichneten Objekte nicht modifiziert werden k"onnen.

Dar"uber hinaus geh"ort zu jedem Objekt ein Besitzer (engl. {\em owner}),
entweder ein Agent oder ein Ort. Nur Objekte, die ein Agent besitzt, kann dieser
bei einer Reise an einen anderen Ort mitnehmen. Alle anderen Objekte werden am
Ursprungsort zur"uckgelassen, so da"s der Agent seine Referenzen auf diese
verliert. Objekte, die in der transitiven referentiellen H"ulle des Objektgraphs
eines Agenten erreichbar sind, werden von der Engine daraufhin "uberpr"uft, ob
sie dem Agenten geh"oren. Ist dies nicht der Fall, so wird vor der Migration der
Objektgraph an der betreffenden Stelle gekappt (der Objektgraph wird {\em
isoliert}). Auf diese Weise stellt die Engine sicher, da"s die Autonomie von
Agenten bewahrt wird.

Des weiteren kennt Telescript sog. Erlaubnisscheine ({\em permits}), die die
F"ahigkeiten eines Agenten oder Ortes kennzeichnen. Diese
Erlaubnisscheine bestimmen, welche Systemeigenschaften einem Agenten oder Ort
zur Verf"ugung stehen. Insbesondere kann ein Erlaubnisschein die
Migrationsoperationen f"ur einen Agenten sperren oder einem Agenten
bzw. Ort erlauben, die F"ahigkeiten {\em anderer} Agenten einzuschr"anken.

Jeder Agent und jeder Ort wird von der Telescript-Engine als eigener, autonomer
Proze"s ausgef"uhrt. Die Kooperation von Prozessen untereinander wird durch die
Engine "uberwacht. Dabei erfolgt die Interaktion von Prozessen in Form eines
Rendezvous \cite{HeHo94}, das durch die Engine vermittelt wird. Der
Informationsaustausch zwischen den Partnern eines Rendezvous geschieht mittels
des direkten Methodenaufrufs des Initiators im Objekt des Akzeptors. Dabei
erh"alt der Initiator mittels des Sprachkonstruktes {\sl meet} eine
Bindung\footnote{Unter Verwendung des dargestellten {\em Ownership}-Konzepts zur
Wahrung der Autonomie der Agenten.} an das Objekt des Akzeptors. Die Beziehung
ist asymmetrisch, d.h. der Akzeptor erh"alt keine Bindung an den Initiator.
Beide Rendezvouspartner d"urfen ein solches Treffen jederzeit abbrechen. Die
Engine sorgt f"ur eine Isolation der Partner nach Beendigung des Treffens.

Neben der M"oglichkeit der direkten Interaktion, bei der sich immer beide
Partner am selben Ort befinden m"ussen und auch keine Migration erlaubt ist,
stellt Telescript eine verbindungsorientierte Kommunikationsform zu Verf"ugung,
die dem Socket-Mechanismus aus dem Betriebssystem Unix "ahnelt \cite{Sun90}.
Diese Verbindungen sind migrationstransparent und erlauben den Austausch von
Daten "uber Rechnergrenzen hinweg.

Innerhalb einer Kooperationsbeziehung zwischen Prozessen wird keine implizite
Serialisierung durch die Telescript-Engine erzwungen. Statt dessen kann ein
Objekt dies durch sog. Ressource-Objekte erreichen, die sowohl konditional als
auch unkonditional genutzt werden k"onnen. Mit Hilfe dieser Ressource-Objekte
werden ({\em konditionale}) kritische Abschnitte geschaffen, die einer
einfachen Konfliktmatrix unterliegen. In dieser Matrix werden die exklusive
Benutzung und die geteilte Benutzung einer Ressource unterschieden. Exklusive
Benutzung ist immer inkompatibel zu jeder anderen Benutzungsart, geteilte
Benutzung ist kompatibel zu einer geteilten Benutzung durch einen anderen
Proze"s. Werden Konditionen verwendet, mu"s sich die Ressource zus"atzlich in
einem Zustand befinden, der vom anfragenden Proze"s erwartet wird.

Die Telescript-Engine bietet weiter zur Senkung des "Ubertragungsvolumens bei
einer Migration von Agenten die M"oglichkeit, die transitive referentielle
H"ulle eines Agenten zu begrenzen. Wird ein Objekt gefroren (engl. {\em
freezing}), so werden alle abh"angigen Objekte, die durch eine gegebene
Klassenbibliothek erzeugt werden k"onnen, durch Identifikatoren der Bibliothek
ersetzt.

Beim Auftauen (engl. {\em thawing}), werden diese Identifikatoren mit
einer lokalen Klassenbibliothek zur Rekonstruktion der Originalobjekte
verwendet.

\subsection{Facile}

Facile ist eine weitgehend\footnote{Facile besitzt zus"atzliche imperative
Konstrukte.} funktionale, streng typisierte Sprache h"oherer Ordnung. Sie ist
eine Erweiterung der Sprache ML \cite{Har86,Mil89} zur Unterst"utzung von
verteilter und nebenl"aufiger Programmierung. Facile wurde am ECRC\footnote{ECRC
::= European Computer-Industrie Research Centre.} entwickelt und von Frederick
Knabe im Rahmen einer Dissertation als Grundlage f"ur ein
Agenten-Programmiersystem verwendet \cite{Kna95}. Die Sprache ist seit 1994
unter der Bezeichnung {\em Facile Antigua Release} am ECRC frei verf"ugbar.

An agentenorientierten Erweiterungen stehen in Facile Bindungstechniken für
ubiquit"are Ressourcen, eine optimierte Kodeerzeugung f"ur mobile Funktionen und
Koderepräsentationen für heterogene Ausführungsumgebungen zur Verf"ugung.

Das Binden an ubiquit"are Ressourcen geschieht statisch typisiert "uber global
verf"ugbare (z.B. mittels FTP verteilte) "ubersetzte Signaturen der jeweiligen
Ressource. Facile identifiziert kompatible Ressourcen anhand eindeutiger Id's
in den exportierten Signaturen, die zur "Ubersetzungszeit erzeugt werden. Das
Binden (bzw. Isolieren) selbst wird durch ein Manipulieren der transitiven,
referentiellen H"ulle eines Objektes (engl. {\em closure trimming}) bei dessen
"Ubertragung vom Laufzeitsystem transparent vorgenommen (siehe auch Abschnitt
\ref{Bindungstechniken}).

Facile kann Funktionen in verschiedenen Koderepr"asentationen "ubertragen, die
entweder nach Platzbedarf oder Ausf"uhrungsgeschwindigkeit optimiert sind und
sich f"ur heterogene Systemumgebungen eignen.

Agenten werden mit Skripten realisiert, die "uber Nachrichtenkan"ale (engl. {\em
channels}) "ubertragen werden. Skripte sind in Facile spezielle
Funktionsabschl"usse, die beliebigen Kode beinhalten d"urfen und sich auf
eine definierte Agentenumgebung beziehen k"onnen.

Die Agentenumgebung von Facile besteht aus einer Sammlung von Dom"anen mit je
einem Verzeichnisdienst, dem {\em Domain Directory Service}, und einem
"Uberwachungswerkzeug, dem {\em Agent Tracking Service}. "Uber den
Verzeichnisdienst werden alle Dienste angeboten, die in einer Dom"ane vorhanden
sind. Dieser Dienst wird selbst "uber einen Agenten implementiert. "Uber diesen
Dienst k"onnen Benutzer vorhandene Agenten anfordern, deren Kopien dann lokal
ausgef"uhrt werden. Allerdings bietet Facile keine Persistenz, so da"s ein
einmal "ubertragener Agent nach einem Systemneustart erneut bei dem
Verzeichnisdienst abgeholt werden mu"s.

\subsection{Mole}
\label{Mole}

Das Agentensystem Mole ist im Rahmen einer Diplomarbeit an der Universit"at
Stuttgart entstanden \cite{Hoh95} und basiert auf einer Klassenbibliothek f"ur
die Programmiersprache Java der Firma Sun Microsystems \cite{Sun95a}.

Java ist eine objektorientierte Programmiersprache, deren Syntax der Sprache C
"ahnelt. Java-Programme sind portabel, sie werden in einen Bytecode "ubersetzt
und auf einer virtuellen Maschine ausgef"uhrt. Die virtuelle Maschine ist f"ur
den Betrieb in einer offenen Umgebung ausgelegt und bietet daher eine Reihe von
Sicherheitsma"snahmen, die das Betriebssystem vor unerlaubtem Zugriff durch Java
Programme sch"utzen \cite{Sun95b}.

Java bietet in seiner momentanen Version keine orthogonale Persistenz. Daher
geht Mole einen anderen Weg bei der Migration von Agenten als Telescript.

Mole-Agenten m"ussen alle Objekte, die nach einer Migration auf dem Zielrechner
vorhanden sein sollen, explizit bei einem zur Umgebung geh"orenden {\em
Persistency Manager} anmelden. Dabei mu"s das Objekt liniarisierbar sein, d.h.
es mu"s Methoden anbieten, um sich in eine Zeichenkettenrepr"asentation zu
konvertieren. Die R"uckwandlung in ein Java-Objekt geschieht mittels des
Persistency Managers, in dem dieser die erzeugte Zeichenkette auswertet.
Tats"achlich beinhaltet die Zeichenkettenrepr"asentation eines Objektes
g"ultigen Java-Quellcode, der vom Java-Compiler "ubersetzt werden kann. Diese
Form der reflektiven Programmierung erfordert, da"s jedes Objekt einer Klasse
entstammt, die eigens f"ur die Mobilit"at vorbereitet worden ist.

Das Verarbeitungsmodell vom Mole ist an Telescript angelehnt. Mole kennt
ebenfalls Orte, Agenten und Treffen, die semantisch zu den Konzepten von
Telescript "aquivalent sind. Auch das Kooperationsmodell stimmt mit dem von
Telescript "uberein, es basiert auf dem Methodenaufruf in anderen Agenten,
allerdings kennt Mole keine besonderen Bindungsarten an Objekte.

Bei Mole migrieren keine Threads in Ausf"uhrung. Stattdessen wird nach
erfolgter Kode-Migration, die durch einen Methodenaufruf des Agenten im Objekt
des Umgebungsortes initiiert wird, die Wiederherstellung der pseudo-persistenten
Objekte durchgef"uhrt. Danach wird der Agent erneut mit der {\sl start}-Methode
gestartet, so da"s der Ausf"uhrungspunkt des Original-Thread verlorengeht. Der
Programmierer mu"s dies bei der Erstellung von Mole-Agenten ber"ucksichtigen.
Weiter ist eine Migration nur dann erlaubt, wenn der Agent sich nicht
in einer Meeting-Beziehung zu einem anderen Agenten befindet.

Neben der Interaktionsform "uber lokale Rendezvous, die "ahnlich Telescript
durch ein Treffen eingeleitet werden, bietet Mole die Kommunikation "uber den
von Java bereitgestellten Socketmechanismus und globale Nachrichten. Diese
werden beim Empf"anger in einem vom Agentensystem verwalteten Briefkasten
(engl. {\em mailbox}) des Agenten gesammelt und k"onnen dort von diesem abgeholt
werden.

Die Ausf"uhrungsumgebung von Mole stellt eine Reihe von Basisdiensten zu
Verf"ugung. Dies sind neben der "Uberwachung von Rendezvous und Migration der
Agenten ein Namensdienst f"ur die systematische Benennung  und ein
{\em Heartbeat}-Dienst, welcher ein periodisches Aufwecken eines Agenten durch
den Aufruf der entsprechenden Methode im Agenten, ausgehend vom Agentensystem,
erm"oglicht.

Java selbst bietet einen Standardmechanismus zur automatischen
Klasseninstallation an, bei dem die Java-Engine fehlende Klassen mittels dem
HTTP\footnote{HTTP ::= HyperText Transfer Protocol} beim Ursprungsort des Agenten
nachfordert. Diese Klassen werden dann automatisch auf dem Zielsystem
installiert und stehen dem Agenten zur Verf"ugung.

\subsection{COSY}

Obwohl das AI-Agentensystem COSY \cite{Had95}, das in diesem Abschnitt
beschrieben wird, keinen Mobilit"atsbegriff kennt, ist es dennoch f"ur die
weitere Arbeit interessant. Das System besitzt, im Gegensatz zu den bisher
vorgestellten Ans"atzen, eine auf Kooperation und Autonomie der Agenten
ausgelegte Architektur.

COSY Agenten basieren auf interpretierten Skripten und dem Austausch von
Nachrichten mit ihren Kooperationspartnern gem"a"s spezifizierter
Protokolle. Diese Protokolle sind anwendungsabh"angig, d.h. sie k"onnen f"ur jeden
Agenten gesondert definiert werden.

Das Kooperationsmodell orientiert sich an den Sprechakten aus
Abschnitt \ref{koopleitbild}. Die Architektur verwendet eine strenge
Klassifikation von Nachrichten, die zwischen den Agenten auf der
Anwendungsebene ausgetauscht werden k"onnen. Dabei handelt es sich um elf
verschiedene Nachrichtentypen der Art {\sl inform}, {\sl request}, {\sl notify},
\dots, die durch die Theorie der Sprechakte motiviert sind. Anhand der
Nachrichtenart wird die vom Sender beabsichtigte Reaktion des Empf"angers auf
deren Inhalt ausgedr"uckt.

Die in COSY definierten Nachrichtenarten fallen in zwei Gruppen: eine Gruppe,
deren Nachrichten Antworten des Kooperationspartners erwarten und eine zweite
Gruppe, deren Nachrichten keine Antwort erfordern.

Neben den interpretierten Skripten besitzen COSY-Agenten eine Wissensbasis, die
den Ablauf der Skripte beeinflu"st. Mit der Wissensbasis werden Annahmen
({\em beliefs}), W"unsche ({\em desires}) und Absichten ({\em intentions})
eines Agenten repr"asentiert\footnote{Es handelt sich somit um ein BDI-System,
wenngleich die Terminologie in \cite{Had95} abweicht.}.

Die wesentlichen Architekturkomponenten, die im folgenden betrachtet werden,
sind: die Aus\-f"uhr\-ungs\-kom\-po\-nen\-te (engl. {\em Protocol Execution Component}
(PEC)) und die Entscheidungskomponente (engl. {\em Reasoning and Deciding
Component} (RDC)).

Jeder Agent im COSY-System definiert verschiedene Kooperationsprotokolle, die
dynamisch durch das Skript von den Agenten gew"ahlt werden k"onnen.
Protokolle entsprechen den Konversationsspezifikationen aus Kapitel \ref{tbc}.

Die zur Kooperation verwendeten Nachrichtenarten sind allerdings vielf"altiger,
wobei die jeweilige Absicht der Nachricht bereits an der Nachrichtenart
erkennbar ist. Es ist dar"uber hinaus einem Agenten m"oglich, primitive
Nachrichten ohne Protokollspezifikation zu versenden, wobei der empfangende
Agent aus der Nachrichtenart schlie"sen kann, was der Sender beabsichtigt.
Allerdings ist dann, falls die Nachrichtenart eine Antwort impliziert, nicht
vorhersagbar, welche Antwortnachricht der Empf"anger w"ahlt.

Es k"onnen sich mehrere Protokolle gleichzeitig in Ausf"uhrung befinden. Jede
Transition innerhalb eines Protokolls f"ur sich ist hingegen atomar, d.h. alle
anderen Protokolle sind w"ahrend der Ausf"uhrung suspendiert. Die PEC w"ahlt das
zur Nachricht geh"orende suspendierte Protokoll und aktiviert es. Wenn kein
zugeh"origes Protokoll existiert, wird ein neues instantiiert.

Die RDC hat die Aufgabe, aus dem Inhalt einer eingehenden Nachricht und dem
momentanen Zustand des Agenten eine g"ultige Fortf"uhrung des Protokolls
auszuw"ahlen und seine Wissensbasis ggf. anzupassen. Dabei ber"ucksichtigt die
Komponente die bereits in der Wissensbasis repr"asentierten strategischen und
taktischen Absichten des Agenten. Die RDC liefert der PEC (d.h. dessen
Scheduler) Informationen, welche Protokolle ausgef"uhrt werden sollen.

\subsection{Tcl/MIME Agents}

Das Agentensystem, das hier vorgestellt wird, unterscheidet sich von den
bisher genannten dadurch, da"s es keine besondere Ausf"uhrungsumgebung
voraussetzt\footnote{Abgesehen von dem Interpreter f"ur die Agentenskripte.}.
Stattdessen werden diese Agenten als Programmskripte im Anhang von
elektronischer Post versendet und tragen deshalb auch die englische Bezeichnung
{\em active mail}.

Das in \cite{Ros93} vorgeschlagene Agentensystem basiert auf einem Dialekt der
frei verf"ugbaren Skriptsprache Tcl, Safe-Tcl. Programme dieser Sprache werden
ohne Vor"ubersetzung interpretiert. Weiter bietet Tcl GUI-Elemente, eine
einfache Syntax, und ist bereits als ``Vermittlersprache'' zwischen Systemen
konzipiert. Der Interpreter ist kompakt und laut \cite{Ros93} leicht in
andere Systeme integrierbar.

Tcl-Agenten werden mittels einer Erweiterung des
Multi-Purpose Internet Mail Extensions Standards (MIME) f"ur aktive Mail
verschickt. "Uber diesen Standard sind bereits eine Reihe von
Multimedia-Erweiterungen f"ur elektronische Post realisiert.

Agenten sind Tcl-Skripts, die beim Eintreffen mit dem Postsystem des Empf"angers
interagieren und abh"angig von der Interaktion selbstt"atig Aktionen ausf"uhren
k"onnen.

Dabei wird die notwendige Sicherheit durch ein Zwillings-Interpreter-Modell
erreicht. Es besteht aus einem, auf einen sicheren Sprachsubset reduzierten,
{\em untrusted}-Interpreter und einem vollst"andigen {\em
trusted}-Interpreter. Der {\em untrusted}-Interpreter besitzt keinen Zugriff auf
das zugrundeliegende Betriebssystem auf dem das e-mail System arbeitet. Alle
Skripte, die in der aktiven Post enthalten sind, werden von diesem Interpreter
ausgef"uhrt.

Der Besitzer des Agentensystems kann nun die Funktionalit"at des {\em
untrusted}-Interpreters schrittweise erh"ohen, indem er Funktionen definiert,
die vom {\em trusted-} in den untrusted-Interpreter exportiert werden, aber vom
trusted-Interpreter ausgef"uhrt werden. Auf diese Weise wird erreicht, da"s die
Sicherheit des Gesamtsystems (aus der Sicht des Benutzers) nicht gef"ahrdet
wird. Allerdings setzt dies voraus, da"s die exportierten Prozeduren
mit sorgf"altig programmiert sind und keine Sicherheitsl"ucken bieten, die einen
unkontrollierten Zugriff auf den {\em trusted}-Interpreter erm"oglichen.



