21

Authentifikation von Agenten, Interpretern, Code und Benutzern

Um die Identität dieser Parteien sicherzustellen, müssen Agenten, Interpreter und Benutzer authentifiziert werden können. Um Manipulationen an Code auszuschließen, muß die Integrität von Code sichergestellt werden, oder, aus einer anderen Sicht, muß auch hier die Identität gewahrt sein. Betrachten wir die Teilaspekte einzeln:

Authentifikation von Agenten Agenten müssen gegenüber Interpreterm und gegenüber anderen Agenten authentifiziert werden. Abhängig davon, ob ein Agent einem Interpreter vorliegt, oder der Agent von einem anderen Interpreter aus kommuniziert, kann im ersten Fall die Authentifizierung aus der Datenform des Agenten geschlossen werden, die in den konstanten Teilen (konstante Daten und konstanter Code) vom Benutzer oder einer authorisierten Seite aus signiert sein muß. Dazu ist die Signatur über dem Datenzustand des Agenten zu prüfen, wozu wiederum Kontrolldaten der signierenden Institution (z.B. ein öffentlicher Schlüssel) vorhanden sein müssen. Falls ein Agent einem Interpreter nicht vorliegt, sondern von einem anderen Interpreter aus kommuniziert, muß die Authentifizierung den "normalen" Weg über die Kenntnis eines Geheimnisses, gehen. Dieses Geheimnis, im Allgemeinen ein geheimer Schlüssel des Agenten oder des Besitzers, wird durch das Stellen einer Anfrage und die Prüfung der Antwort erfolgen (siehe z.B. [NS78] für einen gängigen Authentifizierungsalgortihmus). Dabei ist zu beachten, daß wenn es böswillige Interpreter gibt, auf denen der Agent war, und der Agent seine Daten nicht schützen kann, dieses Geheimnis auch anderen Seiten bekannt sein kann.

Die Authentifizierung von Agenten gegenüber anderen Agenten kann entweder über die Authentifizierung von Agenten gegenüber dem Interpreter des anfragenden Agenten erfolgen, wenn der anfragende Agent diesem Interpreter vertrauen kann. Falls dieses Vertrauen nicht gegeben ist, muß der Agent diese Authentifizierung selbst übernehmen, wobei auch hier die "normale" Authentifizierung über das Nachweisen der Kenntnis eines Geheimnisses erfolgen wird. Da der Agent in diesem Fall seinem Interpreter nicht vertraut, muß er die Möglichkeit haben, die Authentifizierung vollziehen zu können, ohne von seinem Interpreter beeinflusst zu werden. Falls der Interpreter z.B. Zugriff auf die Kontrolldaten der Authentifizierung (z.B. den öffentlichen Schlüssel des zu authentifizierenden Agenten) hätte, könnte er diese Daten so ändern, daß die Authentifizierung erfolgreich ist. Selbst, falls das der Fall ist, muß der Agent sicher diese Authentifizerungsdaten bekommen, d.h. er trägt sie bereits bei sich (und kann sie vor dem Interpreter verbergen), oder er kann sie vom Schlüsselverteilmechanismus bekommen, ohne dabei vom Interpreter manipuliert zu werden.

Authentifikation von Interpretern Interpreters müssen gegenüber anderen Interpretern und Agenten authentifiziert werden. Die Authentifizierung gegenüber anderen Interpretern ist dasselbe wie die Authentifizierung zweier Rechner in einem herkömmlichen verteilen System, und kann daher wieder den Nachweisen der Kenntnis eines Geheimnisses benutzen. Auch hier ist es dazu wichtig, von der Schlüsselverteilkomponente die Kontrolldaten (öffentlicher Schlüssel) sicher zu bekommen.

Die Authentifizierung gegenüber Agenten kann im Prinzip genauso funktionieren, solange das oben bei der Authentifizierung von anderen Agenten zutrifft, nämlich, daß der Interpreter den Authentifizierungsprozeß nicht manipulieren kann und daß der Agent die Kontrolldaten sicher bekommen kann. Zu beachten ist allerdings, daß es unmöglich sein muß, daß der Interpreter mittels eines anderen Agenten auf dem "richtigen" Interpreter, die Authentifizerung umgehen und sich selbst maskieren kann, da einer Authentifizierung zwischen Agent und Interpreter wahrscheinlich nicht die Einrichtung eines sicheren Kommunikationskanals folgen wird, da

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

22

die Kommunikation lokal und damit sicher ist.

Authentifikation von Benutzern Um die Abrechnung und eine Haftbarkeit des Besitzers eines Agenten sicherzustellen, muß gewährleistet sein, daß der Besitzer eines Agenten authentifiziert werden kann. Dieser Vorgang ist allerdings mehr organisatorischer Natur und betrifft die Institution, die die Organisation der Abrechnung und der juristischen Aspekte übernimmt. Ohne eine solche Authentifikation sind alle Agenten im rechtlichen Sinne anonym und eine Abrechnung muß anders bewerkstelligt werden (etwa über elektronisches Geld).

Authentifikation von Code Es muß sichergestellt werden, daß der Code eines Agenten nicht unauthorisiert verändert wurde. Falls der Code sich während der Verarbeitung nicht ändert, kann diese Zusicherung auf die Prüfung gegen eine vor der Migration eines Agenten erstellten Signatur des Codes geprüft werden. Diese Signatur kann sich auf einen Teil des Codes beziehen, etwa eine Klasse. Dann ist es sinnvoll, wenn der Autor dieses Teil signiert. Sie kann aber auch den gesamten Code eines Agenten signieren, dann kann die Signatur vom Eigentümer des Agenten vorgenommen werden. Dazu muß allerdings der Umfang des Codes des Agenten von vorneherein feststehen. Dazu ist es nicht unbedingt notwendig, den Code jeweils in einem Stück zu migrieren, falls es effizienter ist, den Code dynamisch aus anderen Quellen als dem Absendehost zu bekommen (vgl. [HKB97] für eine Diskussion eines solchen Systems), dann kann die Signatur des Eigentümers auch nur die Liste der Kontrollinformationen der Signaturen der Codeteile umfassen. Dieses Vorgehen hat den Vorteil, daß nur eine Kontrollinformation, die der Signatur des Eigentümers, besorgt werden muß, was wahrscheinlich sowieso der Fall ist, wenn der Eigentümer bekannt sein muß.

Verschlüsselung der Kommunikation zwischen Interpretern und Agenten

Um die Kommunikation zwischen zwei Interpreter zu schützen, muß diese verschlüsselt werden. Dieser Aspekt ist in verteilten Systemen seit langem erforscht, so daß auch hier auf ein bekanntes Verfahren benutzt werden kann. Da auch Agenten Interpreter zum Transport von Kommunikation benutzen, ist damit auch diese Kommunikation vor Dritten geschützt, wenn den Interpretern vertraut werden kann. Ist das nicht der Fall, müssen die Agenten wiederum selbst verschlüsseln, was eine sichere Übermittlung von Schlüsseln an die Agenten bedingt.

Schlüsselverteilung

Um den Beteiligten benötigte Schlüssel für die Authentifizierung, die sichere Kommunikation und andere Zwecke geben zu können, muß es eine Komponente geben, die diese Aufgabe übernimmt. Diese Komponente muß

- sicher gegen Manipulation sein - ausfallsicher sein - performant genug sein - Schlüssel an alle Beteiligten sicher ausgeben können, insbesondere an Agenten - in das "Betriebsmodell" des Agentensystems passen, also z.B. veteilt sein, wenn es keine zentrale Authorität gibt usw.

Es ist zu prüfen, ob hier ein existierender Mechanismus, etwa X.509, benutzt werden kann, oder ob ein existierender Mechanismus modifiziert werden oder gar neu entwickelt werden muß.

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

23

Authorisierung

Um Agenten Zugriff auf Systemressourcen zu geben, muß es eine Komponente geben, die diesen Zugriff kontrolliert. Diese Authorisierung kann entweder auf der Basis der Identität des Agenten erfolgen, oder sie kann Ergebnis einer Befragung der Authorisierungspolitiken sein, die z.B. den Typ des Agenten miteinbeziehen. Diese of "Security Policies" genannten Mechanismen erlauben es, auf verschiedenen Ebenen Regeln zu formulieren, die beschreiben, welche Rechte welchen Agenten zu welchen Bedingungen eingeräumt werden. Dieser Aspekt wird im Abschnitt "Sicherheitsmodelle" ausführlicher diskutiert.

Abrechnung (für Electronic Commerce)

Abrechnung von erbrachten Leistungen des Agentensystems, des Interpreters oder anderer Agenten kann zu zwei Zwecken erhoben werden: entweder intern, um damit z.B. den Ressourcenverbrauch eines Agenten quantitativ kontrollieren zu können, oder extern, wenn mit abzurechnenden Leistungen Gegenwerte in der realen Welt, z.B. Geld, verbunden ist.

Wenn in einem Agentensystem externe Abrechnung vorgesehen ist, muß gewährleistet werden, daß diese nicht manipulierbar ist und daß keine der Parteien dabei betrogen werden kann. Sie sollte daher von einem neutralen Dritten vorgenommen werden oder objektiv nachvollziehbar sein. Dieser Aspekt ist allen Anwendungen gemein, die den Charakter von Electronic Commerce haben; daher können Mechanismen aus diesem Umfeld auch hier eingesetzt werden, solange diese mit mobilen Teilnehmern zurecht kommen.

Da die interne Abrechnung nur administrativen Zwecken dient, und von einer neutralen Anwendung durch den Interpreter ausgegangen werden kann, muß diese nicht so großen Ansprüchen genügen. Hier können die Mechanismen angewandt werden, die zur Abrechnung von Leistungen in einem Betriebssystem benutzt werden.

Ressourcenkontrolle

Ressourcenkontrolle ist die quantitative Kontrolle des Ressourcenverbrauchs durch die Agenten. Auch dieser Aspekt ist Teil des Sicherheitsmodells und wird dort behandelt.

"Denial-of-service"-Gegenmaßnahmen

Um Denial-of-service-Attacken zu verhindern, müssen alle möglichen Angriffe dieser Art in Betracht gezogen werden. Grob kann man diese zwar in - Angriffe gegen Agenten und - Angriffe gegen Interpreter einteilen,

eine komplette Aufzählung ist allerdings kaum möglich und verlangt in jedem Fall die genaue Kenntnis eines Agentensystems, auf das es sich bezieht. Daher kann man auch nicht unbedingt auf die Existenz eine Komponente schließen, die alle Denial-of-service-Attacken verhindert, vielmehr scheint es so zu sein, daß verschiedene Maßnahmen im Einzelfall dazu führen können, daß einige dieser Attacken unterbleiben. Dieser Aspekt ist aber in jedem Fall Teil der Sicherheitsproblematik jeden normalen verteilten Systems, und Problemlösungen aus diesem Gebiet sollten sich auch hier anwenden lassen.

6.2 Sicherheitsmodelle

In diesem Abschnitt sollen kurz drei Sicherheitsmodelle vorgestellt werden, sowie deren Anwendbarkeit im Bezug auf mobile Agenten. Ein Sicherheitsmodell modelliert dabei alle relevanten Parteien, ihre erlaubten Aktionen sowie den Regelformalismus, der eine Sicher-

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

24

heitspolitik sicherstellt.

6.2.1 OMG Security Service [OMG97]

Das Sicherheitsmodell der OMG ist ein abstraktes Dokument, das - wie bei der OMG üblich - keine Implementierung vorschreibt und im wesentlichen einen Rahmen definiert, innerhalb dessen sich Produkte, die diesen Vorschlag implementieren, bewegen können. Er ist nicht auf mobile Agenten ausgerichtet, sondern beschreibt Funktionen, die sehr viele Anwendungen benötigen. Dazu gehören: - Identifikation und Authentifikation von Benutzern und Objekten - Authorisierung und Zugriffskontrolle - Abrechnung
- Sicherung der Kommunikation inklusive Authentifikation, Integritätsschutz und Verschlüsselung von Nachrichten - Nicht-Abstreitbarkeit von Interaktionen - Administration von Sicherheitsaspekten

Die OMG Security Spezifikation enthält somit fast alle Komponenten, die auch für mobile Agenten gebraucht werden, der Bereich, der fehlt, ist der Schutz vor Denial-of-Service-Attakken, der aber ein Forschungsthema ist. Trotzdem muß ein Sicherheitsmodell für mobile Agenten mehr umfassen, als in der OMG Spezifikation beschrieben, weil die Mobilität z.T. neue Aspekte aufbringt, z.B. das erwähnte Problem der böswilligen Interpreter. Weiter ist das OMG Modell abstrakt und will eine Vielzahl von verschiedenen Implementierungen einbeziehen, die verschiedene Crypto-Mechanismen benutzen. Diese Ausrichtung ist bei einem Modell für mobile Agenten, nicht gegeben. Schließlich beruht das Sicherheitsmodell auf der generellen OMG-Architektur, insbesondere dem Object Request Broker (ORB), der in einem Mobile- Agenten-System nicht vorhanden sein muß. Ein anderes Sicherheitsmodell, das auf dem OMG-Modell aufbaut, aber auf ein Mobile-Agentensystem ausgerichtet ist, ist das des MAF Proposals.

6.2.2 MAF Proposal Security Model [MAF97]

Auf den Request for Proposals zu einer "Mobile Agent Facility" (MAF) reichte eine Gruppe bestehend aus Vertretern von IBM, General Magic, GMD Fokus, The Open Group und Crystaliz einen Vorschlag ein, der auch ein abstraktes Sicherheitsmodell umfasst.

Dieses Sicherheitsmodell geht über den Security Service von CORBA hinaus, da er nicht alle Bedürfnisse von Mobile-Agenten-Systemen befriedigen kann. Hier wird er aber zumindest als Grundlage benutzt, und es existiert eine (informale) Umsetzung der Funktionen des Proposal Modells auf Funktionen des CORBA Security Services.

Das Sicherheitsmodell umfasst die Existenz von Sicherheitspolitiken, definiert verschiedene Kommunikationsparameter, die ein Agent wählen kann und macht Aussagen über Authentifikation und Delegation.

Sicherheitspolitiken beinhalten Regeln für:

- das Einschränken oder Gewähren von bestimmten Eigenschaften wie dem Erzeugen neuer Agenten, der Migration oder dem Ausgeben von elektronischem Geld - das Setzen von Limits für den Verbrauch von Systemressourcen - das Einschränken oder Gewähren von Zugang zu bestimmten Zielen Sie können vom Agent und vom Agentensystem definiert werden.

Falls ein Agent migriert, oder sonstige Kommunikationsdienste des Interpreters in Anspruch

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

25

nimmt, kann er folgende Sicherheitsmaßnahmen fordern:

- Verschlüsselung der Kommunikation - Überprüfung der Integrität der Kommunikation - Authentifizierung des Kommunikationspartners - Prüfung auf mehrfaches Vorhandensein des gleichen Agenten

Authentifikation von Interpretern geschieht über die existierenden Mechanismen

Authentifikation von Agenten aufgrund des Problems böswilliger Interpreter dürfen Agenten keine Schlüssel mit sich tragen. Daher werden Agenten mit anderen Mitteln, nämlich mithilfe der sogenannten "Authenticators" authentifiziert. Diese sind Algorithmen, von denen es mehrere Typen gibt, und die z.B. die Identität des Ausgangsortes oder des Eigentümers des Agenten in Betracht ziehen. Ein Typ, die "one-hop authenticators" betrachten einen Agenten als authentifiziert, sobald der Agent dieselbe Autorität als Besitzer hat wie der Ausgangsort und der Ausgangsort authentifiziert werden kann, sonst nicht. Authenticators, die mehrere Stationen (Hops) in Betracht ziehen können, werden erst für zukünftige Überarbeitungen des Proposals vorgesehen.

Delegation
Falls ein Agent einen entfernten Methodenaufruf macht, werden die Rechte des Agenten diesem Aufruf mitgegeben, damit er mit diesen Rechten ablaufen kann

Das Sicherheitsmodell des MAF Proposals ist ein erster Ansatzpunkt für ein Modell, das ein Mobile-Agenten-System schützt. Allerdings deckt es nicht alle Bereiche der Sicherheit ab, es macht keine Aussagen über Lösungen der Probleme, die auftauchen, wenn böswillige Interpreter auftauchen und es führt das abstrakte Modell vollständig nicht auf die Ebene der Implementierung, so daß zwei Agentensysteme, deren Sicherheitskomponente diesem Modell folgen würde, nicht unbedingt kompatibel wären.

6.2.3 Aglets Security Model [KLO97]

Dieses Modell ist im Umfeld des Aglets-Systems der IBM Japan zu sehen. Dieses System implementiert mobile Agenten auf der Basis von Java und ist in Binärform frei verfügbar. Da diese Gruppe auch zu den Autoren des MAF Proposals gehören, verwundert es nicht, daß es wie eine Verfeinerung des obigen Modells wirkt.

Das Modell stellt Mechanismen bereit, die: - den Transfer und die Kommunikation eines Agenten schützen - die Zugriffkontrolle und das Auditing beim Ausführen eines Agenten erlauben - es verhindern, daß Agenten sich gegenseitig angreifen - es verhindern, das Agenten das Interpretersystem angreifen

Dazu stellt das Modell Formalismen bereit, die es - dem Programmierer eines Agenten - dem Besitzer eines Agenten - dem Verwalter der Ausführungsumgebung - dem Verwalter der Domain

erlauben, Sicherheitspolitiken zu definieren, die festlegen

- unter welchen Bedingungen Agenten auf andere Objekte zugreifen dürfen - welche Authentifizierung von Benutzern und anderen Parteien verlangt wird - welche Aktionen eine authentifizierte Einheit durchführen kann

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

26

- ob Einheiten ihre Rechte weitergeben können - welche Kommunikationssicherheit zwischen Agenten und ihren Interpretern gefordert ist - welcher Grad an Abrechnung für die sicherheitsrelevanten Aktivitäten gefordert ist

Die Sicherheitspolitiken der obigen Parteien werden dabei immer von denen der übergeordneten Parteien "überschrieben". Domains sind dabei Bereiche mit der gleichen Sicherheit, wobei Interpreter innerhalb dieser Domains von anderen Institutionen betrieben werden dürfen, als der, die die Domain betreibt.

Die Authorisierungssprache, die beschreibt, welche Agenten unter welchen Umständen auf welche Ressourcen zugreifen dürfen, erlaubt, positive und negative Regeln aufzustellen.

Das Aglets Sicherheitsmodell stellt einige der von einer Sicherheitskomponente benötigten Funktionen bereit und realisiert damit viele der Funktionen, die sich mit existierender Technik implementieren lassen. Allerdings macht es keine Aussagen zur Schlüsselverteilung und betrachtet das Problem böswilliger Interpreter als unlösbar.

6.3 Sicherheit: Zusammenfassung

Zusammenfassend läßt sich sagen: Sicherheit ist für das Gebiet der mobilen Agenten ein wichtiges Thema, weil es zum einen Einfluß auf die Akkzeptanz der Technik hat und zum anderen einige Anwendungsbereiche wie Eletronic Commerce erst ermöglicht. Durch den Aspekt der Mobilität von Agenten kommen nicht in allen Teilgebieten neue Aspekte hinzu; vieles kann unter Verwendung bestehender Techniken gelöst werden. Der Aspekt des Schutzes des Interpreters vor böswilligen Agenten hat über das Gebiet der mobilen Agenten hinaus Einfluß auf jeden Einsatz unbekannter Programme auf einem Rechner.

Ein Teilgebiet, das des Schutzes von mobilen Agenten vor böswilligen Interpretern ist jedoch zum einen wichtig, zum anderen stellt es ein neues Problem dar, das anspruchsvoll ist, und bisher noch nicht technisch gelöst wurde. Wichtig deshalb, weil Agenten auf der einen Seite geldwerte Daten transportieren können, und weil sie u.U. auf der anderen Seite Geheimnisse oder persönliche Daten des Eigentümers transportieren können, die dieser nicht preisgeben will. Bisherige Ansätze halten dieses Problem für technisch kaum lösbar und gehen andere Wege, die allerdings nur Teillösungen darstellen oder Restriktionen aufweisen. Die Sicherheit des Agenten ist daher die große Herausforderung auf dem Gebiet der Sicherheit bei mobilen Agenten; sie soll durch den Ausbau des Ansatzes der "Blackbox Security" angegangen werden.

7 Entwurf von Protokollen zur Waisenerkennung und zur Ter-

minierung in Mobile-Agenten-Systemen [Bau97]

Waisenerkennung und Terminierung ist im Bereich der verteilten Systeme ein gut erforschtes Gebiet, innerhalb dessen viele Problemlösungen existieren. Diese Lösungen nutzen die wohldefinierten Beziehungen zwischen Eltern- und Kind-Entitäten (verteilte Prozesse oder Objekte) aus. Diese Lösungen sind jedoch im Bereich der Mobile-Agenten-System nicht anwendbar, da keine entsprechenden, aus der Aufrufstruktur automatisch ableitbaren Beziehungen zwischen Agenten existieren. Deshalb müssen in diesem Bereich neue Protokolle definiert werden.

Innerhalb des Berichtszeitraumes wurde ein Konzept entwickelt, daß sowohl Waisenerkennung als auch Terminierung erlaubt. Dieses Konzept baut auf zwei anderen Konzepten auf, dem sogenannten Energiekonzept, und dem Pfadkonzept. Das Energiekonzept bietet Waisenerkennung, das Pfadkonzept bietet die Möglichkeit, Agenten zu finden und damit zu terminieren.

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

27

Beide Konzepte haben Nachteile. Durch geschickte Kombination erhalten wir ein Protokoll, daß die Vorteile der Konzepte vereinigt, und zur gleichen Zeit die Nachteile minimiert. Dieses Protokoll ist das sogenannte ?Schatten?-Protokoll. Es nutzt die Idee eines Platzhalters (Schatten) des Benutzers, der vom System jedem Agenten des Benutzers zugeordnet wird. Dieser Schatten speichert Informationen über alle abhängigen Agenten. Wenn dieser Schatten entfernt wird, sind alle abhängigen Agenten Waisen und können terminiert werden.

Wir werden jetzt das Energiekonzept und das Pfadkonzept präsentieren, um darauf aufbauend das Schattenprotokoll diskutieren zu können.

7.1 Das Energiekonzept

Ein Agent benötigt im Rahmen seiner Ausführung Ressourcen wie CPU-Zeit, Speicher, I/O, und benutzt vom System angebotene Dienste. Wir nehmen an, daß jeder in Anspruch genommene Dienst und jede benutzte Ressource eine bestimmte Menge Energie des Agenten benötigen. Zu Beginn seines Lebens bekommt der Agent eine bestimmte Menge Energie, und sobald diese vollständig verbraucht ist, wird der Agent zur Waisen erklärt und kann terminiert werden.

Dies bietet eine simple Methode um Waisen erkennen zu können, mit dem Vorteil, daß die Aktivität eines Agenten (also die Nutzung der Ressourcen) seine Lebensspanne bestimmt. Der Nachteil dieses Konzeptes ist, daß, sollte die Lösung eines Problems mehr Energie benötigt werden als von der Applikation (die die Anfangsenergie ausgibt) angenommen, der Agent terminiert wird, ohne die Aufgabe beenden zu können. In solchen Fällen wäre es sehr wertvoll, wenn der Agent zusätzliche Energie von der Applikation anfordern könnte. Ein Agent, der bemerkt, daß sein Energiestand gefährlich niedrig wird, könnte eine Nachricht an die Applikation senden, sich schlafen legen (und damit nur wenig Energie verbrauchen), und darauf warten, daß die Applikation mit zusätzlicher Energie antwortet. Dabei spielt es keine Rolle, ob die Applikation sofort reagiert, solange gewährleistet ist, daß die zusätzliche Energie innerhalb der verbleibenden Lebenszeit des Agenten ankommt. Dies bedeutet, daß das Konzept gegen kurzzeitige Netzwerkfehler oder Abstürze von beteiligten Rechensystemen unempfindlich ist. Die maximale Zeit, die ein solcher Fehler unbehoben existieren darf, ist schlicht die verbleibende Lebenszeit des Agenten minus der Nachrichtenlaufzeit.

Wenn die Applikation entscheidet, daß der Agent keine zusätzliche Energie bekommen soll (z.B. weil ein anderer Agent die Aufgabe bereits gelöst hat), antwortet sie einfach nicht. Das System garantiert die Terminierung nach Verbrauch der verbleibenden Energie.

Es muß allerdings sichergestellt werden daß dieser Mechanismus nicht überlistet werden kann. Wenn ein Agent einen anderen erzeugt, dann darf dieser nicht die gleiche Energie bekommen, die der erzeugende Agent ursprünglich bekam. Wenn dies der Fall wäre, könnte ein bösartiger Agent einfach einen Kindagenten erzeugen, der schläft, bis der Originalagent stirbt, dann seinerseits ein Kind erzeugt, und damit durch die Kette von Kindern unbegrenzt viel Energie bekommt. Die offensichtliche Lösung für dieses Problem ist, die Energie des Kindes dem Elternagenten in Rechnung zu stellen. Auch muß die maximale Menge an Energie, die ein Agent bekommen kann, begrenzt sein, um nicht, eine weitere potentielle Umgehungsmöglichkeit des Mechanismus zuzulassen.

7.2 Das Pfadkonzept

Wenn jeder Agent, der sich innerhalb des Agentensystems bewegt, eine Spur hinterläßt, dann kann man jeden Agenten dadurch finden, daß man dieser Spur vom Ort der Erzeugung des

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

28

Agenten bis zu seinem momentanen Aufenthaltsort folgt. Nachdem der Agent gefunden worden ist, kann er problemlos terminiert werden. Diese Idee ist im Bereich der verteilten System nicht neu, wurde aber im Bereich der mobilen Agenten bisher nicht verwendet.

7.3 Das Schattenkonzept

Beim Schattenkonzept erzeugt die Applikation einen oder mehrere Schatten, eine Struktur auf einem Platz, der möglichst gut erreichbar ist für die zu erzeugenden abhängigen Agenten. Dieser Platz muß nicht notwendigerweise der gleiche sein, auf dem die erzeugende Applikation läuft. Jeder Agent der von der Applikation erzeugt wird, hängt von einem solchen Schatten ab. Sobald der Schatten von der Applikation entfernt wird, kann jeder abhängige Agent vom System terminiert werden. Solange der Schatten existiert, ist kein Kontakt zwischen Agenten und der Applikation oder dem System, auf dem die Applikation läuft, notwendig. Der Agent hängt nur noch vom Schatten ab, nicht mehr direkt von der Applikation. In regelmäßigen Abständen (time to live) kontaktiert das Agentensystem den Platz, auf dem der Schatten instantiiert wurde, um zu überprüfen, daß er nicht in der Zwischenzeit entfernt wurde. Wenn der Schatten zwischenzeitlich entfernt wurde, wird der abhängige Agent zur Waisen erklärt und terminiert.

Wenn ein Agent einen neuen Agent erzeugt, dann bekommt dieser neue Agent den gleichen Schatten wie der erzeugende Agent zugeordnet, und die gleiche verbleibende Zeit bis zur nächsten Überprü- fung. Es ist notwendig, die verbleibende Zeitspanne bis zur nächsten Überprüfung auf die verbleibende Zeit des erzeugenden Agenten zu beschränken, um zu verhindern, daß entsprechend der beim Energiekonzept skizzierten Möglichkeit bösartige Agenten eine unbeschränkte Lebensspanne bekommen können.

Wenn ein Platz, auf dem sich ein Schatten befindet, vom überprüfenden System nicht erreicht werden kann, wird ein Timer gestartet. Wenn nach Ablauf dieser Zeit das System wieder nicht erreicht werden kann, wird der Timer erneut gestartet und ein Zähler herabgezählt. Wenn der Zähler 0 erreicht, wird der Platz als unerreichbar angesehen, der Schatten als nicht mehr existent angesehen, und die abhängigen Agenten werden terminiert. Durch die Wahl von Timeout und Zähler können verschiedene Reaktionen auf Kommunikationsprobleme erreicht werden.

Diese einfache Version des Protokolls implementiert ein Konzept, das dem Energiekonzept vergleichbar ist, nur wurde der Energiebegriff ersetzt durch eine time to live. Der Nachteil dieses Ansatzes ist, daß unabhängig von der tatsächlichen Tätigkeit des Agenten in regelmäßigen Abständen Kommunikation stattfinden muß, um die Existenz des Schattens zu überprüfen. Der Vorteil ist, daß für die Zeit bis zur Terminierung nach der Entfernung eine obere Grenze angegeben werden kann.

Applikation erzeugt

Platz
Agent

Schatten

Schaubild 5: Die Erzeugung eines Schatten

erzeugt

Platz

Agent

Schatten

Platz

abhängig

Agent

Schaubild 6: Erzeugen eines neuen Agenten

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

29

In dieser einfach Form unterstützt das Protokoll nur passive Terminierung. Durch die Entfernung des Schatten werden alle abhängigen Agenten zu Waisen erklärt, und nach Ablauf der der time to live ist garantiert, daß alle Agenten terminiert wurden. Durch Hinzufügen des Pfadkonzeptes erlauben wir auch aktive Terminierung. Dies wird durch die sogenannten Agenten-Proxies erreicht.

7.3.1 Agenten-Proxies

Agenten-Proxies sind Datenstrukturen, die bei jedem Platz existieren, und die die Bewegungen aller Agenten verfolgen, die zu einem Schatten gehören. Sie implementieren die Pfade aus dem letzten Abschnitt, die es mittels der Erweiterung der Shattenfunktionalität ermöglichen, Agenten aktiv zu terminieren. Wir können den Beginn eines jeden Pfades dadurch ermitteln, daß wir den Platz speichern, an dem der Agent das letzte Mal überprüft wurde.

Wenn ein Agent an einem Platz ankommt, an dem noch kein Proxy existiert, wird automatisch eine solcher erzeugt (Schaubild 7a). Sobald der Agent auf einen anderen Platz migriert, wird der Zielplatz als Teil der "Reiseroute" zusammen mit der "time to live" abgespeichert (Schaubild 7b).

Wenn das Ende des "time to live" erreicht ist, wird der Schatten des Agenten um eine Verlängerung des Lebenszeit des Agenten gebeten, daher wird ihm der neue Platz des Agenten bekannt gemacht (Schaubild 8a). Der Pfad, der bei den verschiedenen entlang des Migrationsweges des Agenten gespeichert ist, ist nun überflüssig und kann mithilfe des "time to live" gelöscht werden

Schaubild 7: Proxies

migrates

created by the system

depends on

(a) (b)

A

Loc1

Loc2

migrates Loc1

Loc3

A

Loc2

Shadow

Agent Proxy

A - Loc3

A - Loc2 A - Loc2

Path

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

30

(Schaubild 8b). Ein Eintrag kann ebenfalls gelöscht werden, wenn der Agent zu diesem Platz zurückmigriert (in diesem Fall ist das einfach eine Abkürzung des nun zirkulären Pfades.

Ein Proxy existiert genau so lange, wie er Einträge enthält. Ist dies nicht mehr der Fall, kann er gelöscht werden. Das ist besonders dann hilfreich, wenn die Agenten aktiv terminiert werden. In diesem Fall werden alle Einträge aus dem Proxy gelöscht, was es dem System erlaubt, auch den Proxy zu löschen.

Nähere Informationen zu diesem Kapitel finden sich in [Bau97].

8 Anwendungen

Aus verschiedenen Anlässen wurden auf der Basis von Mole prototypische Anwendungen als Studien- oder Diplomarbeiten implementiert.

8.1 Reiseroutenplanung [Pin96]

Um die Eignung von Mobile-Agenten-Systemen in Informationssystem-Anwendungen zu eruieren wurde in Zusammenarbeit mit der Daimer-Benz AG wurde eine prototypische Anwendung erstellt, die in der Lage ist, basierend auf Mole, ausgehend von einem Startort, Zielort sowie einer Startzeit, eine Reiseroute zu bestimmen, die aus mehreren Verkehrsmitteln bestehen kann. Dazu fragt ein Routenplanungsagent mehrere Informationsquellenagenten, die Informationen von im Internet zugänglichen Informationsquellen wie z.B. einer über eine WWW-Seite abfragbare Datenbank holen können. Die Vorteile von mobilen Agenten liegen hier einerseits in der einheitlichen Dienstearchitektur, die es Programmen erlaubt, Daten anderer Programme über Agenten abzufragen, darin, daß in Agentensystemen nicht nur Dienstinanspruchnahmen, sondern auch Dienste selbst dynamisch angeboten werden können sowie in der Fähigkeit von Agenten, von konkreten Implementierungen auf der Ebene des Informationsaustausches abstrahieren zu können. Der Hauptnachteil des gewählten Ansatzes lag dabei nicht auf der Seite der mobilen Agenten, sondern in der Tatsache, daß die häufigen Änderungen im Zugriff auf die WWW-basierten Informationen, die einem menschlichen Benutzer nicht stören, zu der Notwendigkeit einer ebenso häufigen Änderung der Informationsquellenagenten führte, und die Anwendung damit chronisch "hinterherhinkte".

Schaubild 8: Update o fProxies created by the system depends on

(a) (b)

Shadow
Agent Proxy

Loc1

Loc3

A

Loc2

Loc1

Loc3

A

Loc2

A - Loc2

A - Loc3

comm.
with
shadow

A - Loc3

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