AIDA I - Abschlußbericht

Fritz Hohl, Joachim Baumann, Kurt Rothermel, Markus Schwehm, Markus Straßer

Bericht Nr. 1998/03 Februar 1998

AIDA I - Abschlußbericht

Fritz Hohl,Joachim Baumann,Kurt Rothermel,Markus Schwehm,Markus Straßer

Email: Fritz.Hohl@informatik.uni-stuttgart.de

Institut für Parallele und Verteilte Höchstleistungsrechner (IPVR) Fakultät Informatik Universität Stuttgart Breitwiesenstr. 20 - 22 D-70565 Stuttgart

Universität Stuttgart

Fakultät Informatik

Seite 1: nächste Seite | Übersicht

2

Kurzfassung

In diesem Bericht geht es um die Zusammenfassung der Erkenntnisse, die im Verlauf der ersten Phase des AIDA-Projektes bis September 1997 gewonnen wurden. AIDA ist ein Projekt, das von der Deutschen Forschungsgemeinschaft (DFG) finanziert wird. Das Thema dieses Projektes sind mobile Agenten, also Einheiten, die aus Code, Daten und Zustand bestehen und sich selbständig in einem Netzwerk bewegen können. Das Ziel von AIDA I war es, auf der Grundlage eines allgemeinen Verarbeitungsmodells flexible Systemmechanismen für verteilte, agentenbasierte Systeme zu entwickeln.

Seite 2: vorherige Seite | nächste Seite | Übersicht

3

1 Einführung

Mobile Agenten sind aktive und autonome Verarbeitungseinheiten, die in der Lage sind, Funktionalität für eine Anwendung zu erbringen und selbständig von Systemknoten zu Systemknoten migrieren können. Mobile Agenten stellen zum einen ein Programmiermodell dar, dessen Einheiten, die mobilen Agenten, wie Softwareroboter in einer (künstlichen) Umgebung interagieren können. Diese Interaktion schließt Kommunikation mit anderen Agenten und Rechnern mit ein, ebenso wie Einwirkung auf diese Umwelt, solange diese Einwirkung definiert ist. Mobile Agenten stellen als Technik auf der anderen Seite jedoch auch eine Middleware dar, die eine Plattform für Applikationen bietet, und deren Anforderungen in die Kommunikationsaufrufe und andere Dienstleistungen der darunterliegenden Rechnersystemschicht umsetzt. Technisch gesehen schließlich sind mobile Agenten Einheiten aus Programmcode und Zustandsdaten, die es einem Agenten erlauben, Berechnungen, die auf einem Knoten angefangen wurden, auf einem anderen Knoten weiterzuführen.

Mobile Agenten sind immer noch ein junges Gebiet, das allerdings immer mehr Aufmerksamkeit nicht nur von seiten der Forschung, sondern auch von Seiten der Industrie erfährt, wie sich durch die Zunahme der Gruppen, die sich mit diesem Thema beschäftigen, deutlich wird. Dieses Interesse wird nicht nur durch ein Gebiet geweckt, dessen Eigenschaften interessante Forschungsthemen erschließen, sondern vor allem durch die Eigenschaften der Technik der mobilen Agenten, die zumindest für einige Anwendungen wesentliche Vorteile gegenüber der herkömmlichen Client-Server-Technik bietet.

Das AIDA-Projekt versucht, auf der Ebene des Agentensystems Verfahren und Mechanismen zu entwickeln, die es Anwendungen erlauben, die Vorteile mobiler Agenten auszunutzen. Da vor allem zum Zeitpunkt des Beginns von AIDA I kaum Systeme und Modelle in diesem Bereich vorhanden waren, wurde als erster Schritt auf der Basis möglichst einfacher Modelle ein offenes Agentensystem erarbeitet, um damit die Forschung der Systemmechanismen zu ermöglichen.

2 Entwicklung des Gebietes

Die Forschung auf dem Gebiet der mobilen Agenten ist derzeit zum einen geprägt von der sprunghaften Zunahme von Gruppen, die beginnen, auf diesem Gebiet zu arbeiten und damit einhergehend, von neuen Agentensystemen auf Prototypenebene. Diese Vermehrung von gegeneinander inkompatiblen Systemen ist für eine Technik schädlich, die auf einer für viele Anwendungen wichtigen breiten Installationsbasis beruht. Daher gibt es zunehmend Bestrebungen, die Interopabilität der Systeme durch Standardisierungsbemühungen zu ermöglichen. Die zwei wichtigsten Institutionen auf diesem Gebiet sind die Object Management Group, die einen "Call for Proposals" bereits 1995 veröffentlichte, sowie die Foundation for Intelligent Physical Agents (FIPA), deren Vorschläge nicht nur Aspekte mobiler, sondern auch intelligenter Agenten umfassen. Zum anderen ist das Gebiet geprägt von der Suche nach Anwendungen, die diese Technologie auch kommerziell interessant machen, den "Killerapplikationen" für mobile Agenten.

Die Entscheidung, für AIDA, Java als Programmiersprache zu verwenden, hat sich im Nachhinein als sehr vorteilhaft erwiesen, da sich zum einen Java sehr stark verbreitet hat und viele Firmen Java für ihre Rechnerplattformen anbieten und es immer mehr Entwicklungsumgebungen und Werkzeuge für diese Sprache gibt. Zum anderen eignet sich diese Sprache in ihrem Aufbau sehr gut für diese Zwecke, und es gibt zunehmend neue Bibliotheken, die zum Teil in

Seite 3: vorherige Seite | nächste Seite | Übersicht

4

die Sprachspezifikation eingebaut werden und die wichtige Funktionalität wie Cryptoverfahren oder Datenbankanbindung einbringen. Die Hinwendung zu Java spiegelt sich auch in den neuen Agentensystemen wieder, die fast komplett Java verwenden. Dadurch scheint auch die Argumentationslinie für Agentensysteme schwächer zu werden, die einen Mehrsprachenansatz propagieren. Das Problem ist, daß man die Eigenschaften, die Java bieten kann, wie Threads, Sicherheit und dynamisches Laden von Code, nicht von allen anderen Programmiersprachen erwarten kann. Das bedeutet, daß entweder nur "geeignete" Sprachen eingebaut werden können, oder daß sehr massiv in die Implementation der Laufzeitumgebungen eingegriffen werden muß. Zusammen mit dem Problem der Datenkonversion zwischen verschiedenen Programmiersprachen sind Mehrsprachensysteme sehr viel schwerer zu realisieren und bieten daher auch nur wenige Programmiersprachen an. Zudem ist es unter den derzeitigen Gegebenheiten allenfalls unklar, ob mehrere Sprachen auch wirklich gebraucht werden.

3 Aufbau der Forschungsgruppe am IPVR

Beginnend mit dem Start von AIDA I wurde am IPVR eine Gruppe aufgebaut, die sich schwerpunktmäßig mit dem Bereich "Mobile Agenten" beschäftigt. Diese Gruppe besteht z.Zt. aus fünf Forschern und einer Vielzahl an Studenten. Gleichzeitig mit dem Aufbau der Gruppe konnten Forschungskontakte ins In- und Ausland geknüpft werden. So initiierte die IPVR- Gruppe die Bildung des "Deutschen Mobile-Agenten-Treffen" (DeMAT) mit, das sich alle sechs Monate trifft und Forschungsergebnisse austauscht. Von den bisher fünf Treffen der DeMAT wurde eines mitorganisiert, und an allen teilgenommen. Durch die Mitorganisation und Teilnahme an Workshops zum Thema (Mitorganisation des Workshops auf der ECOOP '96 in Linz, der ECOOP'97 in Jväskylä und des Dagstuhlseminars "Mobile Software-Agents"

im Oktober 1997, Teilnahme außerdem am W3C/OMG Workshop zum Thema "Mobile Code", an der DAIS'97, sowie der PDPTA'97) konnten zahlreiche Forschungskontakte zu anderen Gruppen geknüpft werden, die sich mit diesem Thema beschäftigen.

Diese Kontakte konnten genutzt werden, um im April 1997 in Berlin den ersten internationalen Workshop zum Thema "Mobile Agents" zu initiieren und mitzuorganisieren. Da von den über 100 Teilnehmer aus der ganzen Welt sehr positive Reaktionen kamen, wurde von Programmkommittee ein Folge-Workshop 1998 in Stuttgart am IPVR beschlossen, den die Forschergruppe organisieren wird.

Neben einer Reihe von Artikeln konnten auch Proceedings der mitveranstalteten Workshops mitherausgebracht werden (MA'97 Proceedings bei Springer, Workshopanteil an den ECOOP'96 und ECOOP'97 Workshop Proceedings).

Entscheidend mitgeprägt wurde die Arbeit der Mitarbeiter in der Forschergruppe durch Studien- und Diplomarbeiter, sowie die Mithilfe der wissenschaflichen Hilfskräfte. Betreut werden konnten etwa 20 Studien- bzw. Diplomarbeiten ([Ahe97a], [Ahe97b], [Bec96], [Bec97], [Joc97], [Kir96], [Kla96], [Kla97], [Kub97], [Kuh97], [Nit97], [Pin96], [Rie96], [Rö96], [Röh97], [Sch96], [Sza97], [Voi96], [Wie97], [Zep96]), deren Ausarbeitungen im WWW elektronisch verfügbar sind.

Schließlich konnte die Arbeit der Forschungsgruppe, nicht zuletzt auch die des AIDA I - Projektes, in mehreren Präsentationen für Gäste des Instituts, an anderen Hochschulen wie der Universität Genf oder in der Industrie (Siemens, Deutsche Bank, Tandem usw.) vorgeführt werden.

Durch die Teilnahme am Stand der Baden-Württembergischen Hochschulen auf der CeBIT

Seite 4: vorherige Seite | nächste Seite | Übersicht

5

1997 in Hannover konnte das Projekt darüber hinaus in der Öffentlichkeit präsentiert werden. Neben der Wissensvermittlung an ein breites Publikum stand die Kontaktaufnahme mit über 100 zum Teil hochkäratigen Kontakten im Vordergrund.

4 Definition des Verarbeitungsmodells

Mobile Agenten sind vor allem ein Programmiermodell, in dem Begriffe wie Agent, Platz oder Dienst auftaucht. In diesem Kapitel werden daher diese Begriffe erklärt. Nähere Informationen hierzu lassen sich in [SBH96] finden.

4.1 Agenten

Es existiert zur Zeit keine allgemein anerkannte Definition von mobilen Agenten; die meisten Definitionen sind eher Umschreibungen, weil es schwerfällt, über einer gegebenen Definition Systeme auszuschließen, die nicht in diese Kategorisierung fallen (siehe [FG96] für eine Diskussion der Definitionsproblematik). Einen ersten Eindruck mag aber die folgende Beschreibung liefern: Agenten sind die aktiven Verarbeitungseinheiten in einem Mobile-Agenten- System. Wie eine Art "Softwareroboter" sind sie in der Lage, sich autonom von einem Ort des Agentensystems zu einem anderen zu bewegen (falls nichts dazwischenkommt), sie können mit der "Umwelt" an einem Ort interagieren und mit anderen Agenten kommunizieren. Sie arbeiten autonom in dem Sinne, daß sie keine ständige Verbindung zu einem menschlichen Benutzer benötigen.

Eine für die Programmierer sehr wichtige Forderung an die Verarbeitung mittels Agenten ist, daß sie nicht plötzlich verschwinden, etwa weil ein Knoten abgestürzt ist. Es ist daher beim Design des Agentensystems darauf zu achten, daß Agenten im Bezug auf ihre Existenz persistent sind, auch weil sie z.B. wertvolle Daten transportieren (z.B. elektronisches Geld).

Im Mole-Agentenmodell gibt es zwei Arten von Agenten: Benutzeragenten und Systemagenten. Benutzeragenten sind mobil, und zunächst einmal Fremde an jedem Ort. Sie können daher ohne weiteres nicht auf sicherheitssensitive Ressourcen wie Festplatten oder das Netzwerk zugreifen. Systemagenten dagegen haben vollen Zugriff auf alle Systemressourcen (bzw. soviel, wie ihnen die Benutzerkennung, unter dem der Knoten läuft, zugesteht). Ihre Hauptaufgabe ist es daher auch, Systemressourcen des unterliegenden Rechnersystems in die Agentenwelt zu hinein anzubieten. Das kann z.B. bedeuten, daß Agenten in eine Datenbank schreiben bzw. aus ihr lesen können, indem sie mit dem "Datenbank-Gateway-Agenten" kommunizieren. Da Systemagenten systemabhängige Einzelheiten kennen müssen, macht es keinen Sinn, daß sie mobil sind. Da also Systemagenten auch stationäre Agenten sind, ist es einfach, ihnen den vollen Zugang zum System zu gewähren, da sie vom Verwalter eines Ortes installiert werden, also keinen neuen Code enthalten. Wenn Benutzeragenten Zugang zu sicherheitssensitiven Ressourcen haben wollen, müssen sie die Systemagenten davon "überzeugen", ihnen entweder Zugang zu verschaffen oder ihnen Dienstleistungen auf diesen Ressourcen zu erbringen. Ein Beispiel für den ersten Fall könnte ein Datensammelagent eines Netzwerkmanagementsystems sein, der die Daten eines Netzknotens erfahren will und sich daher mittels eines Ausweises beim zuständigen Systemagenten als Berechtigter authentifiziert. Ein Beispiel für den zweiten Fall könnte ein "Speicheragent" sein, ein Systemagent, der Benutzeragenten in einem Abrechnugsverfahren anbietet, ihre Daten zu speichern bzw. bereitzustellen.

Seite 5: vorherige Seite | nächste Seite | Übersicht

6

4.2 Plätze

Eine der wesentlichen Fähigkeiten eines mobilen Agenten ist die der Migration, also der selbständigen Bewegung zwischen zwei "Orten". Diese Fähigkeit setzt die Existenz von etwas voraus, zu dem ein Agent hinmigrieren kann. Für diese Migrationsziele gibt es im wesentlichen drei Möglichkeiten:

1. abstrakte "Plätze" als Migrationsziel. Da Plätze auf einem Rechner liegen, gibt es keine volle Ortstransparenz, sondern eine Transparenz vom physikalischen Ort. 2. physikalische Einheiten (z.B. Rechner) als Migrationsziel. Es gibt keine Ortstransparenz.

Die zweite Möglichkeit ist eine der Eigenschaften, die von verteilten Systemen zu überwinden versucht wird, ist doch eine der wichtigsten Erkenntnisse hier, daß Ortstransparenz sehr wichtig ist. Diese Möglichkeit, der Einsatz von Plätzen als Migrationsziel, kann folgendermaßen charakterisiert werden:

- ein Platz ist ein Gebiet gemeinsamer Fehler, wenn er auf einem Rechnerknoten installiert ist, d.h. alle Agenten auf diesem Platz sind entweder erreichbar oder nicht - auf einem Platz kostet die Kommunikation zwischen allen Agenten gleichviel - die Kommunikation auf einem Platz ist mindestens genauso billig, wie die zwischen Agenten auf verschiedenen Plätzen

Wir verwenden daher die zweite Möglichkeit. Wie in anderen Agentensystemen (z.B. in Telescript) auch, gibt es addressierbare Plätze als Migrationsziele.

Aus technischer Sicht sind Plätze nicht nur Migrationsziele. Sie stellen auch die Ausführungsumgebungen für Agenten, die ja spezielle Programme sind, dar. Sie bestehen in der Implementierung daher meist aus einem oder mehreren Interpretern und den Komponenten, die die Systemmechanismen erbringen. Da Plätze stationär sind, lassen sich einige Eigenschaften zwischen Plätzen messen, z.B. die Netzwerkverzögerung und, über der Zeit, die Übertragungsgeschwindigkeit.

Schaubild 1 verdeutlicht noch einmal die Zusammenhänge zwischen Plätzen und Agenten.

migration

place B

place C
application

service agent

H

mobile agent

place A

Schaubild 1: Modell

Seite 6: vorherige Seite | nächste Seite | Übersicht

7

4.3 Dienste

Man muß Dienste in einem Agentenmodell vorsehen, um a priori die Agenten klassifizieren zu können, die für eine Interaktion in Frage kommen und um das Agentensystem als Rahmen für das Anbieten bzw. Inanspruchnehmen von Dienstleistungen zu benutzen zu können. Ein Dienst ist dabei eine Funktionalität, die ein Agent anbietet, und ein anderer Agent in Anspruch nehmen kann. Agenten, die bestimmte Dienste anbieten, können über eine Systemkomponente gefunden werden, die Einzelheiten der Dienstinanspruchnahme ist in der Dienstbeschreibung festgelegt. Ein Agent kann mehrere Dienste anbieten. Details übber dieses Thema lassen sich ebenfalls in [SBH97] finden.

4.4 Agentengruppen

Dadurch, daß Agenten autonome Einheiten sind, die eine größtmögliche Flexibilität bezüglich der Abhängigkeit zu anderen Agenten, bezüglich möglicher Kommunikationspartner und der Kommunikationsart haben, ist es nicht ohne weiteres möglich, die Relationen und Kommunikationsbeziehungen von Agenten herauszufinden, die zur selben Anwendung gehören oder zusammenarbeiten. Um einer Anwendung nicht alle Arbeit zuzumuten, ihre Teilnehmer und deren Kommunikations selbst verwalten zu müssen, wurde das Konzept der Agentengruppe eingeführt.

Eine Agentengruppe besteht aus einer Menge von Agenten oder Unteragentengruppen, die zusammen an einer Aufgabe arbeiten. Innerhalb dieser Menge haben einzelne Agenten bestimmte Rollen. Der Group Initiator erzeugt die Agentengruppe initial und vergibt die Rollen. Der Group Receiver of Results ist die Instanz, die das "Gruppenergebnis" bekommt. Der Group Administrator ist für die Kontrolle der Lebenszeit der Gruppe zuständig und damit auch für die Terminierung und eine eventuelle Waisenerkennung. Die Group Members sind die Träger der eigentlichen Berechnung; sie unterliegen von ihrer Lebenszeit her der Gruppenkoordination.

Group
Coordinator

Group
Member

Group
Member Group
Member

Group
Member

Group
Admin. Group Initiator
Group
Receiver of
Results

Schaubild 2 Group Model

Seite 7: vorherige Seite | nächste Seite | Übersicht

8

Der Group Coordinator schließlich koordiniert die Gruppe. Dazu werden die Abhängigkeiten der Gruppenmitglieder und des Gruppenziels durch Events und einen Regelsatz modelliert, der auf den Events arbeitet und wiederum Events erzeugt. Eine solche Regel besteht aus einer Bedingung und einem Aktionsteil, der angewandt wird, wenn die Bedingung erfüllt ist. Der Aktionsteil besteht aus einfachen Anweisungen, die z.B. Ausgabe-Events erzeugen, den Zustand innerhalb des Koordinators ändern usw.

Obwohl der Gruppenkoordinator logisch eine Einheit ist, ist er "physikalisch" verteilt in jedem Group Member implementiert, so daß z.B. Netzwerkpartitionierungen u.U. aufgefangen werden können.

Nähere Informationen zum Gruppenkonzept lassen sich in [BHR97] und [BR97] finden.

5 Agenteninteraktion und -migration

5.1 Agenteninteraktion

5.1.1 Namen

Namenskonzepte sind die Grundlage für die Interaktion von Agenten, Plätzen und Diensten. In diesem Abschnitt sollen diese Konzepte kurz erläutert werden.

Namen von Plätzen

Namen von Plätzen sollen transparent sein bezüglich der Netzwerkadresse des verwendeten Rechnerknotens. Daher wurde ein Verzeichnisdienst benötigt, der in der Lage ist, zum Teil frei wählbare Strings auf (Netzwerkadresse, Portnummer)-Paare abzubilden. Da DNS für diesen Zweck geeignet erschien, und da mit diesem Mechanismus ein erprobter und performanter Dienst zur Verfügung steht, der darüberhinaus in TCP/IP-Netwerken auf jeden Fall vorhanden ist, wurde diese Abbildung über DNS-Einträge vorgenommen. DNS eignet sich für diese Abbildung deshalb, weil die Dynamik der Abbildung sehr ähnlich der Dynamik des eigentlichen Einsatzgebietes erscheint.

Um Plätze addressieren zu können, mussten daher jeweils DNS-Einträge vorgenommen werden. Um die Einträge zur Adressierung benutzen zu können, musste eine eigene DNS-Resolver- Funktion für Java geschrieben werden, da die Portnummer in einem zusätzlichen Attribut (TXT) kodiert ist. Dieses Vorgehen, obwohl funktionierend, ist in der Benutzung zu umständlich, da Betreiber von Plätzen erst den DNS-Adminstrator finden müssen (was vor allem in gro- ßen Organisationen problematisch zu sein scheint), und ihn dann bitten müssen, die richtigen

group coordinator

output
input

rules

state

Internal Rule: if (collected offers are better than offers held so far) {
send(new offers);
adjust held offers list;
}
External Rule: if (member has completed its search) { inc (members completed); if (members completed == no members) then send (result to receiver of results); }

events events

Schaubild 3 Group Coordinator

Seite 8: vorherige Seite | nächste Seite | Übersicht

9

DNS-Einträge zu machen (was aufgrund der Unkenntnis vieler Benutzer von DNS ein Problem ist). Daher wäre bei Verwendung von DNS eigentlich eine Komponente notwendig, die es erlaubt, DNS-Einträge automatisch vornehmen zu lassen, was aber eine sehr plattform-abhängige Installation dieser Komponente beim DNS-Server notwendig machen würde und erfahrungsgemäß von vielen DNS-Administratoren nicht sehr gerne gesehen wird, da DNS eine sicherheitssensitive Systemkomponente ist. Die Alternative zu DNS wäre ein System mit gleicher Funktionalität (eventuell sogar unter Verwendung gleicher Protokolle), das unabhängig vom Netzwerk-DNS ist, und automatische Verwaltung gestattet.

Um zumindest den lokalen Test von Agentenbasierten Anwendungen zu ermöglichen, ohne einen echten DNS-Eintrag zu benötigen, wurde in Mole eine lokale Abbildungstabelle von Platznamen implementiert.

Namen von Agenten

In Mole ist jeder Agent eine eindeutige Einheit, eine Sicht, die durch eine global eindeutige und auf die Lebenszeit des Agenten bezogen gleiche Bezeichner für jeden Agenten unterstützt wird. Die Eindeutigkeit des Namens kann dabei nur dann garantiert werden, wenn das Agentensystem dieses Bezeichners erzeugt. Der Prozeß der Erzeugung neuer Namen ist dabei am einfachste, wenn dies ohne globales Wissen geschehen kann. Tabelle 1 zeigt die Struktur dieser Bezeichner.

Der Bezeichner teilt sich auf in den Teil, der die namensgebende Einheit kennzeichnet und einen Teil, der die individuelle Nummer des Agenten enthält. Die namensgebende Einheit, die Engine, an der der Agent erzeugt wurde, wird durch die Adresse im IPv6-Format gekennzeichnet sowie durch die Portnummer des Engine-Prozesses. Falls diese Adresse für einen Knoten nicht ermittelt werden kann, weil er keine global eindeutige IP-Adresse hat, dann wird dieser Teil aus einer Zufallszahl gebildet, wobei der mögliche Raum eine Kollision unwahrscheinlich macht. Pro Engine gibt es dann noch einen "Crash Counter", der bei jedem Hochfahren des Engineprozesses erhöht wird und deshalb persistent auf Platte gespeichert werden muß. Der letzte Teil ist ein Zähler, der pro neuem Agentenbezeichner um eins erhöht wird und nicht persistent gehalten werden muß. Sollte der (seltene) Fall eintreten, daß dieser letzte Teil nicht ausreicht, wird der Crash Counter um eins erhöht.

Da aus dem Namen keine Informationen über den Aufenthaltsort des Agenten folgen, und auch keine sonstigen Informationen enthalten sind, bedarf es eines Verzeichnisdienstes, um diese Informationen zu Agentenbezeichnern zu assoziieren.

Ein weiteres Konzept, Agenten, mit denen interagiert werden soll, zu benennen, sind die Badges (Namensschilder). Agenten können sich beliebige Badges, die aus einem einfachen String bestehen, "anheften". Andere Agenten können dann mit einem oder mehreren Agenten, die einen

Tabelle 1: Die Komponenten der Agenten_Bezeichner

# Bytes Meaning

4 Dynamic Counter, incremented for every new agent id

4 Crash counter, incremented every time the system is started. Also incremented if dynamic counter overflows.

12 IP Version 6 address of the system on which the engine runs

2 The port number of the engine

2 Reserved for future use (set to 0)

Seite 9: vorherige Seite | nächste Seite | Übersicht

10

bestimmten Badge haben, interagieren. Detailliertere Informationen hierzu finden sich in [SBH97].

Namen von Diensten

Da der Bereich "Trading" nicht verfolgt werden konnte, wurden Dienste in Mole nur insoweit bereitgestellt, als daß sich Agenten lokal an einem Platz unter einem String, der als Dienstname fungiert, registrieren lassen können. Andere Agenten können dann zu einem String die Liste der registrierten Agenten abfragen.

5.1.2 Kommunikation zwischen Agenten

Das initiale Modell der Kommunikation bestand in der Möglichkeit, an andere Agenten Nachrichten zu schicken, bzw. Prozeduren anderer Agenten aufzurufen.

Nachrichten

Eine Nachricht besteht aus einem beliebigen Objekt, das -wie eine Email- an eine Adresse geschickt wird, die aus einem Agentennamen und einem Platznamen aufgebaut ist. Falls der Empfänger an diesem Ort existent ist, wird die Prozedur receiveMessage mit der Nachricht als Parameter in einem eigenen Thread aufgerufen. Falls der Agent nicht anwesend ist, wird -in Abhängigkeit von der anzugebenden Fehlersemantik- die Nachricht entweder einfach gelöscht oder der Absender wird durch eine andere Nachricht von diesem Umstand informiert

Remote Procedure Call (RPC)

Ähnlich wie bei einer Nachricht wird der RPC an eine Kombination aus Agenten- und Platznamen adressiert. Falls der Agent dort vorhanden ist , wird ein Thread erzeugt und über eine Dispatch-Prozedur die eigentliche Prozedur aufgerufen. Das Ergebnis der Prozedur, das ebenso wie die Parameter beliebige Objekte sein können, wird dem Aufrufer als Resultat seines Aufrufs übergeben1. Falls der adressierte Agent nicht am spezifizierten Platz vorhanden ist, wird eine Fehlermeldung zurückgegeben.

Dieser Ansatz hatte, obwohl für für einige Anwendungen durchaus ausreichend, zwei wesentliche Probleme: Die Adressierung von Agenten und die Tatsache, daß mit diesen Mechanismen effizient nur zustandslose Interaktion möglich war. Das Problem bei der Adressierung war, daß man im Voraus den Agenten kennen musste, mit dem man kommunizieren wollte. Wollte man nur ein Merkmal des Kommunikationspartners angeben, oder diesen gar nicht spezifizieren wollen, war das nicht möglich. Das Problem bei Interaktionen, die Zustand haben, war, daß es keine Möglichkeit gab, diesen Zustand zu adressieren, es sei denn man hätte den Zustand explizit mitgeschickt, was ab einer gewissen Größe nicht mehr tragbar ist. Nun sind aber gerade zustandsbehaftete Interaktionen (z.B. mit einem Cursor in einer Datenbank) in realen Anwendungen oft notwendig. Um diese Probleme zu beheben, wurden zwei weitere Mechanismen eingeführt: Session-orientierte Kommunikation und anonyme Kommunikation mittels Events.

Session-orientierte Kommunikation

Mit diesem Mechanismus wird für eine bestimmte Zeit eine Interaktionsbeziehung zwischen

1. In Mole mussre die Dispatch-Prozedur von Hand geschrieben werden, da es zum damaligen Zeitpunkt nicht möglich war, Prozeduren generisch, also unter Angabe des Prozedurnamens als String, aufzurufen. Die RPC-Konstruktion musste selbst implementiert werden, da das Java-eigene RPC-Paket, RMI, nicht in der Lage war, Agentenobjekte zu adressieren.

Seite 10: vorherige Seite | nächste Seite | Übersicht