Mobile Agenten – Ende der 90er Jahre noch als revolutionäre Softwaredisziplin gefeiert, hat sich in den letzten Jahren vielfach Ernüchterung breit gemacht. Einige Gründe hierfür, sowie Möglichkeiten, wie Mobile Agenten doch die Bedeutung erlangen könnten, werde ich im hinteren Teil dieser Arbeite beleuchten, nicht jedoch ohne vorher die nötigen Grundlagen beleuchtet zu haben.
Hierzu will ich mich in erster Linie auf (die wenigen) vorhandenen Standards
(z.B. MAFO) stützten, die im letzten Kapitel
dann näher ausgeführt werden.
Der Begriff „Mobiler Agent“ sieht sich glücklicherweise nicht ganz so vielen Definitionsversuchen ausgesetzt, wie es bei dem Begriff eines Software-Agent der Fall ist. Grundsätzlich kann man hier zwei unterschiedliche Ansätze antreffen:
1. Mobiler Agent als Kurzform für „mobiler Software-Agent“,
also eine um die Eigenschaft Mobilität erweiterte Softwareentität
2. Mobiler Agent als Form eines Software-Agenten der mobil ist, jedoch dadurch
auch geprägt von anderen Eigenschaften oder Ausprägungen ist
Der MAFO-Standard [vgl MAF], die wohl bedeutendste Spezifikation zu diesem Thema, definiert einen Mobilen Agenten nach dem ersten Muster, wonach dieser zunächst ein (Software-)Agent und damit ein „ablauffähiges Programm, welches autonom im Auftrag einer Person oder Organisation handelt“ darstellt und darüber hinaus die Eigenschaft besitzt zwischen verschiedenen Agenten-Systemen – welche die Laufzeitumgebungen des Agenten darstellen, wechseln kann.
Entsprechend ist hier ein Stationärer Agent als Agent zu betrachten, der nur auf einem Agentensystem ausgeführt wird.
In dieser recht kurzen Definition befinden zwei entscheidende Aussagen: 1. Ein Agent handelt immer im Auftrag von jemandem (einer sog. Autorität) und 2. er existiert nur innerhalb eines Agentensystems (AS). In den meisten Fällen wird dieser mit Multiagenten-Systemen (MAS) gleichgesetzt, mehrere Agenten zur gleichen Zeit enthalten können.
Auch wird statt Agentensystem oft der Begriff Umgebung (engl. Environment)
verwendet, die jedoch einer abstrakteren Betrachtung zugrunde liegt und auch
einen bestimmten Bereich innerhalb eines Agentensystems darstellen.
Die MAFO-Definitionen will ich als Grundlage nehmen, komme jedoch nicht darum,
diese nach dem zweiten Muster entsprechend anzupassen. Dies soll im Folgenden
anhand der Eigenschaften eines mobilen Agenten geschehen, wie sie von den meisten
Autoren in diesem Zusammenhang genannt werden:
1. Mobilität
Der Agent kann zwischen verschiedenen Agentensystemen wechseln. Man sagt: er
migriert auf ein anderes Agentensystem. Hierfür müssen zwei Vorraussetzungen
erfüllt sein:
- Der Agent kann als Datenstrom dargestellt werden
- Der Agent kann von der Zielplattform entfangen und interpretiert / ausgeführt
werden
2. Autonomität
Der Agent entscheidet selbstständig anhand bestimmter Kriterien über
seine nächste Aktion . D.h er arbeitet unabhängig von einer kontrollierenden
Instanz (z.B. einem Anwender).
3. Soziale Kompetenz
Der Agent kommuniziert mit anderen Agenten, (Agenten-)Systemen oder auch Menschen.
Vorraussetzung hierfür:
- gemeinsame Protokolle
- gemeinsame Ontologien
- gemeinsame Interaktionsvereinbarungen (Sprechakte)
4. Reaktivität
| Der Agent reagiert auf Änderungen seiner Umgebung. Hierzu besitzt er Sensoren mit denen er diese wahrnehmen kann (z.B. Temperaturerhöhung) und Regeln die eine bestimmte Aktion (z.B. Heizung anstellen) auslösen, oder den empfangenen Reiz ignorieren. | |
Proaktivität (Zielorientiertheit)
Agenten reagieren nicht nur auf Reize ihrer Umgebung, sondern besitzen zudem internen Zustand (engl. State) und sind zu zielgerichtetem Planung und Handeln fähig. Man sagt:sie ergreifen die Initiative. Über diese recht simple Betrachtung von Zustand und Regeln lassen sich zudem weitere Eigenschaften wie Intelligenz oder Persönlichkeit über eine entsprechende Komplexität beider Komponenten, sowie der Beziehungen zwischen ihnen abbilden. |
 |
6. Persistenz
Der Agent bleibt auch nach einen Umgebungswechsel mitsamt seines Zustandes erhalten,
d.h. er wird nicht schlicht kopiert, sondern setzt seine Ausführung innerhalb
der neuen Umgebung fort.
Sicherlich ließen sich hier noch weitere Eigenschaften aufzählen die mobile Agenten besitzen können, die innerhalb dieser Betrachtung allerdings weniger Relevanz besitzen.
Was Mobile Agenten für die Softwareentwicklung bedeuten, lässt sich
am anschaulichsten darstellen, wenn man dieses mit anderen Konzepten (auch:
Paradigmen) vergleicht, die gemeinüblich zur Programmierung von Netzwerkanwendungen
eingesetzt werden.
Hierunter soll jegliche Software verstanden werden, die auf einem entfernten System aufgeführt wird.
Beispiele für Mobilen Code sind:
Mobile Agenten stellen somit eine spezielle Form von Mobilem Code dar.
Bösartiger mobiler CodeOft werden unter Mobilen Agenten Software-Schädlinge wie Würmer, Viren oder Trojaner verstanden.
Diese stellen bezogen auf die eingangs dargestellte Definition Mobiler Agenten jedoch keinen solchen dar, da diese nicht auf einem Agentensystem aufsetzen. Stattdessen handelt es sich dabei um sogenannten bösartigen Mobilen Code, der hier nicht weiter Beachtung finden soll.
Hierbei stellt der Client an den Server Anfragen (requests), die dieser ausführt und seinerseits mit entsprechenden Antworten (responses) erwidert. Beide Übertragungen basieren dabei auf ein vom Server vorgegebenem Format (Protokoll).
Abstrahiert kann man sagen, dass hier beim Server die Funktionalität, aber auch der Grossteil des Ressourcenverbrauchs einer Anfrage liegt.
Beispiele: HTTP oder FTP.
Anstatt Anfragen vollständig auf der Serverseite zu bearbeiten, dient diese hier lediglich zur Auslieferungen eines Stücks Software an den Client. Der – nun in der Lage dieses zu interpretieren – führt es darauf mit eigenen, lokalen Ressourcen aus.
Der Vorteil neben der Entlastung der Server-Ressourcen, besteht bei diesem Ansatz auch in der Reduzierung der Netzwerkkommunikation, die während der Ausführung der Anwendung sogar gleich null ist.
Beispiel: Java Applets
Einen etwas anderen und auch komplizierteren Ansatz bietet die Entfernte Ausführung (Remote Evaluation). Der Grundgedanke: Eine Clientanwendung ruft eine Prozedur auf, wobei es für ihn transparent ist, ob diese lokal, oder auf einem entfernten Rechner ausgeführt wird.
Realisiert wird dies durch den Einsatzlokaler Stellvertreter, sogenannter Stubs
(engl. für Stummel). Der Client ruft dabei nicht die „echte“
Prozedur auf dem entfernten Rechner, sondern den lokalen Stub dieser Prozedur
auf.
Über den Stub wird nun die direkte Netzwerkkommunikation mit dem Stub auf
der Gegenseite hergestellt , worüber schließlich die „echte“
Prozedur aufgerufen wird und deren Ergebnisse über den gleichen Weg an
den ursprünglichen Aufruf zurückgibt.
Es gibt zahlreiche Implementierungen dieses Konzepts, Beispiele sind RPC,
RMI (Java spezifisch), DCOM
(W32 spezifisch) und Corba , die
diesen Ansatz auf unterschiedliche Weise (teilweise unter Einsatz eines zusätzlichen
Namensdienstes) umsetzen.
Grundsätzlich lässt sich jedoch ein Aufruf von drei Methoden (A(),B()
und C()) auf allen Implementierungen, immer wir folgt darstellen:
Bezogen auf die vorgestellten Konzepte, besitzen Mobile Agenten in diesem Kontext teilweise Ähnlichkeiten mit CoD (Code on Demand), nur dass hierbei die Softwareentität eben nicht vom Client abgerufen, sondern von diesem erzeugt und auf den Server zur Verarbeitung übertragen wird.
Die Ressourcen werden somit beim Server verbraucht, während die Funktionalität (jedenfalls theoretisch) vom Client vollständig vorgegeben werden.
Insofern besitzen beide Konzepte (CoD und MA) die gleiche Motivation: den eigenen
Ressourcenverbrauch und die Netzwerkbelastung minimal zu halten. Einmal aus
Sicht des Servers, einmal aus Sicht des Clients.
Da viele Autoren den Grundgedanken hinter Entwicklung Mobiler Agenten hauptsächlich in der Schaffung einer Alternative zu Remote Procedure Calls (RPCs) sehen, liegt der direkte Vergleich beider Konzepte an dieser Stelle nahe. Der Idee hierhinter war, dass Mobile Agenten durch ihre Architektur, prinzipiell die gleichen Möglichkeiten wie RPCs bieten, dabei jedoch ohne deren Nachteile auskommen. Die da wären:
1. Bandbreite:
Jeder Prozeduraufruf und dessen Antwort vom Server wird über das Netzwerk
übertragen. Bei hundert Aufrufen während der Ausführung eines
Programms ergäbe sich somit eine beträchtliche Netzwerkbelastung.
Mobile Agenten hingen werden nur einmal versendet und empfangen.
Auf der andren Seite können RPCs bei nur geringer Kommunikation aber auch weitaus effektiver als Mobile Agenten sein (schließlich muss hier kein Agentencode übertragen werden. Strasser und Schwem [Strasser1997] haben dies wie folgt ermittelt:
2. Latenzzeit
Die Dauer zwischen Prozeduraufruf und Antwort liegt bei der lokalen Kommunikation des Mobilen Agenten gewiss deutlich unter der von RPCs, welche gewöhnlich über das Netzwerk erfolgen.
Allerdings kann auch hier ein RPC durchaus lokal oder in räumlicher Nähe zum Client erfolgen, was dann nur noch sehr geringe Unterschiede zu Mobilen Agenten bedeuten würde.
Hingegen wäre für eine beträchtliche Entfernung beider Seiten – etwa wie bei der zwischen Hamburg und Taipeh, RPCs sicherlich eine denkbar ineffektive Variante und Mobilen Agenten klar unterlegen.
3. Ausfallsicherheit
Bei Netzwerkübertragungen besteht stets die Gefahr, dass die übertragene Nachricht nicht oder nur unbrauchbar ankommt.
In beiden Fällen müsste eine entsprechende Funktionalität implementiert (z.B. Timeouts) oder genutzt werden, wodurch ein höherer Aufwand und potenziell längere Übertragungsdauer, bestehen würde. Bei der rein lokalen Kommunikation Mobiler Agenten besteht dieser Nachteil nicht.
Vereinfacht kann man die vorgestellten Konzepte wie folgt voneinander abgrenzen:
|
Ressourcenverbrauch |
Funktionalität |
|
|
CS |
Server |
Server |
|
CoD |
Client |
Server |
|
ReV |
Server |
Client / Server* |
|
MA |
Server |
Client |
Mobile Agenten muten hier leicht als veridealisierte Disziplin an: Der Client darf Funktionalität der Anwendung selbst vollständig bestimmten, ohne dabei lokale Ressourcen zur Verfügung stellen zu müssen.
Der direkte Vergleich zu RPCs macht jedoch deutlich, dass der zusätzliche Aufwand für die Erstellung eines Mobilen Agenten als Ersatz für ein bestehendes RPC-Konzept, stark vom jeweiligen Szenario abhängt. Sind viele Aufrufe über weiter Entfernung oder ist ein großes Datenaufkommen zu erwarten bieten sich Mobile Agenten an, bei räumlich naher Entfernung beider Seiten oder nur wenig Kommunikation mit geringem Datenaufkommen dagegen sind klassische RPCs wiederum im Vorteil.
Was hier allerdings bisher noch nicht betrachtet wurde, ist die Möglichkeiten
Mobiler Agenten gänzlich neue Anwendungsfelder, die für konventionelle
Konzepte bisher kaum vorstellbar waren, zu erschließen.
Ein Benutzer Bob möchte eine Internet Recherche betrieben.
Bisher:
Bob fängt bei einem Suchdienst an, wobei er meist nur wenige Worte als Suchanfrage angibt und überfliegt dann die ersten paar Ergebnisse, spezialisiert darauf eventuell seine Anfrage oder wechselt auf die angebotenen Inhalte, wobei er immer wieder Verweisen folgt. Ergebnis: Die Recherche dauert sehr lange, wobei viele relevante Informationen von Bob nicht wahrgenommen werden.
Durch Mobile Agenten:
Bob definiert (etwa durch eine GUI) seine Suchanfrage. Er sagt was er will
und in welchem Kontext (z.B. Kohl im Kontext Politik) stehen soll. Er schickt
einen Suchagenten auf verschiedene Datenbanken. Trifft der Agent nun auf eine
relevante Information (die er durch seine KI selektiert), so speichert er diese.
Trifft er auf einen Verweis zu einer weiteren Quelle, klont er sich und schickt
seinen Klon zu der angegebenen Ressourcen. Der Klon verfährt genauso, usw..
Die Klone kehren nach einiger Zeit zu ihrem Erschaffer zurück, übergeben
ihm die gefundenen Informationen und terminieren. Schließlich tut dies
auch der einst von Bob erzeugte Agent, der nun die Information sämtlicher
Klone an Bob gibt.
Ergebnis: für die Recherche muss Bob nur seine Suchanfrage formulieren,
und erhält sehr umfangreiche Resultate, die er lokale schnell selektieren
kann.
Ein Agent wird auf ein Börsen System geschickt, überwacht dabei sämtliche Kursverläufe und vollzieht Aktionen entsprechend der ihm mitgegebenen Parameter (z.B. Verkauf wenn Aktie um 0,2 Prozent fällt).
Bob möchte von unterwegs eine sehr umfangreiche Formel berechnen. Da er in seinem PDA hierfür nicht über die nötigen Ressourcen verfügt, schickt er einen Mobilen Agenten an einen leistungsfähigen Rechner, auf dem er Formel ausrechnen lässt und zusammen mit dem Ergebnis auf den PDA zurückkehrt.
Bob möchte eine günstige Reise nach Kuba buchen. Dafür erstellt
er einen Shopping Agenten, der zwischen verschiedenen Reise-Anbietern wechselt,
die günstigsten Preise ermittelt, eventuell diese sogar bucht und mit den
Ergebnissen an Bob zurückkehrt.
Wie problematisch speziell dieser Einsatz ist, soll im Abschnitt zu Sicherheit
von Mobilen Agenten, näher dargestellt werden.
Abschließend bleibt hier noch zu sagen, dass bisher keine Killer-Applikation für den Einsatz Mobiler Agenten existieren, die also etwa den Aufbau von weltweiten Agentensystemen ökonomisch rechtfertigen würde. Wie später gezeigt, sprechen auch andere Gründe gegen ein solches Vorhaben.