1 EINLEITUNG UND MOTIVATION
2 GRUNDLAGEN
2.1 Grundlagen des EPC-Netzwerks
2.1.1 Die Grundidee hinter dem EPC-Netzwerk
2.1.2 Das Auto-ID Center
2.1.3 Beispielanwendung des EPC-Netzwerks
2.1.4 Die Systemkomponenten des EPC-Netzwerks
2.2 Grundlagen der Software-Agenten
2.2.1 Definitionen für Software-Agenten
2.2.2 Eigenschaften von Software-Agenten
2.2.3 Agentenorientierte Software, ein Paradigma zur Software-Entwicklung
2.2.4 Aufgaben von Software-Agenten
2.3 Grundlagen der Darstellung und Verteilung von Wissen
2.3.1 Darstellungsformen von Wissen
2.3.2 Sprechakttypen: Frage, Mitteilung oder Anweisung
2.3.3 Ontologie: Nicht nur die Syntax verstehen, sondern auch den Inhalt
2.3.4 Lernen: Alte Fehler vermeiden, neue Fähigkeiten erlernen
2.4 Realisierung von kooperativen Software-Agenten
2.4.1 Der erste Schritt zur Kooperation: Die Fähigkeit zur Kommunikation
2.4.2 Der zweite Schritt zur Kooperation: Eine Sprache, die nicht nur Daten überträgt
2.5 Realisierung von mobilen Software-Agenten
2.5.1 Anforderungen an die Programmiersprache
2.5.2 Die Suche nach Informationsquellen
2.6 Agenten-Plattformen
2.6.1 Aufbau und Aufgabe der Agenten-Laufzeitumgebung
2.6.2 Übersicht Agenten-Plattformen
2.6.3 Beschreibung der Agenten-Plattform JADE
2.6.4 Beschreibung der Agenten-Plattform Aglets
3 EPC-NETZWERK UND SOFTWARE-AGENTEN
3.1 Wie erhalten Software-Agenten Zugang zum EPC-Netzwerk
3.2 Die Wissensdarstellung der Software-Agenten
3.2.1 Wissensaustausch mit dem EPC-Netzwerk
3.2.2 Definition der Ontologie für den Einsatz im EPC-Netzwerk
3.2.3 Definition der Sprechakttypen für den Einsatz im EPC-Netzwerk
3.2.4 Eine typische Unterhaltung zweier Agenten
3.2.5 Austausche von Wissen zwischen Agenten und EPC-Netzwerk
3.3 Szenariobeispiele für den Einsatz von Software-Agenten im EPC-Netzwerk
3.3.1 Integrieren von nicht standardkonformen RFID-Lesegeräten
3.3.2 Inventur
3.3.3 Suche nach vermissten Produkten
3.3.4 Suche nach bestimmten Fehlermustern
3.3.5 Modellierung des EPC-Netzwerks mit Hilfe von Software-Agenten
3.3.6 Jedes Produkt wird durch einen mobilen Agenten begleitet
4 BESCHREIBUNG DER AM SYSTEM BETEILIGTEN AGENTEN
4.1 Programmierung von mobilen Agenten mit Aglets
4.1.1 Die Aglet Klasse
4.1.2 "Hello World"-Beispiel mit einem Aglet
4.1.3 Erweiterung des Beispiel um die Mobilität
4.1.4 Probleme der schwachen Migration, am Beispiel einen Datenbankzugriffs
4.2 Beschreibung der erzeugten Java-Klassen
4.2.1 C_Knowledge: Eine Klasse zur Verwaltung der Wissensbasis
4.2.2 C_Predicate: Eine Klasse zur Verwaltung einer Klausel
4.2.3 C_Aglet: Oberklasse für Software-Agenten mit Aglets
4.3 Beschreibung der erzeugten Software-Agenten
4.3.1 Ein stationärer Schnittstellenagent als Verbindung zum EPC-Netzwerk
4.3.2 Ein mobiler Suchagent für die Informationssuche
5 RESÜMEE UND AUSBLICK
ABBILDUNGS-, TABELLEN- UND PROGRAMMVERZEICHNIS
GLOSSAR
QUELLENVERZEICHNIS
"Ich glaubeüberhaupt nicht daran, daßman die globalen Probleme auch global lösen kann. Auch die Natur löst globale Probleme, indem sie lokal etwas verä ndert, auf eine solche Art und Weise, die allmä hlich in gr öß ere Dimensionen hereinwä chst."
(Hans-Peter Dürr, dt. Physiker, 1987)
Die Globalisierung der Produktion und des Wirtschaftsverkehrs nimmt zu. Produkte werden nicht mehr an den Orten hergestellt, wo sie gebraucht, sondern wo Arbeitskräfte billig, das Know-how vorhanden oder Subventionen gezahlt werden. Dieser Trend birgt neben den sozialen auch technische Probleme. Für die Logistik dedeudet das beispielsweise: Die Waren müssen zur richtigen Zeit am richtigen Ort in der richtigen Menge verfügbar sein und in den Warenfluss sollen so wenig Menschen wie möglich eingreifen. Zusätzlich müssen neue oder lokale Gesetze beachtet und integriert werden. Ein solches Gesetz ist zum Beispiel die lückelose Dokumentation der kompletten Produkthistorie für jede einzelne Arzneimittelnpackung. Eine mögliche Lösung dieser Probleme könnte die Vernetzung der realen Welt mit der virtuellen Welt darstellen. Ein Lösungsansatz stellt das EPC-Netzwerk dar. Ein globales Netzwerk braucht jedoch Komponenten, die lokal in das Geschehen eingreifen und Produkte, die im Netz verloren gegangen sind, wieder finden oder die vorhandenen Informationen auf Stimmigkeit über-prüfen. Diese Arbeit könnten mobile kooperative Software-Agenten übernehmen.
Im Mittelpunkt der vorliegenden Arbeit stehen deshalb diese zwei Technologien, das EPC- Netzwerk und die Software-Agenten. Ziel ist es, diese beiden grundsätzlich voneinander unabhängigen Technologien miteinander zu verbinden. Dabei sollen kooperative und mobile Software-Agenten auf die im EPC-Netzwerk zur Verfügung stehenden Informationen zugreifen. Zu beweisen soll sein, ob diese daraus gewonnenen Synergieeffekte Informationen in einer bisher nicht zur Verfügung stehenden Qualität und Form liefern.
Dazu ist es wichtig, in einem ersten Schritt die vorhandenen Denkansätze in der Literatur zusammenzutragen, auszuwerten und darzustellen. In einem zweiten Schritt wird mithilfe der gewonnenen Grundlagen ein Konzept erarbeitet, wie Software-Agenten und EPC-Netzwerk theoretisch miteinander verbunden werden können. Anhand von Szenariobeispielen soll anschließend der Mehrwert dieses Verbundes gezeigt werden. In einem letzten Schritt wird das erarbeitete Konzept mit seiner Theorie prototypisch in die Praxis überführt. Dabei unterstützt ein statischer Software-Agent einen mobilen Software-Agenten bei der Suche nach Informationen im EPC-Netzwerk.
Die Idee zur vorliegenden Arbeit entstand im Rahmen einer Kompetenzbildungsmaßnahme an der Fraunhofer Arbeitsgruppe der Technologien der Logistik-Dienstleistungswirtschaft ATL in Nürnberg.
Dieses Kapitel stellt das EPC-Netzwerk vor, einem auf RFID-Transpondertechnik basierenden "Internet der Dinge", entwickelt vom Auto-ID Center. Dazu sollen Objekte der realen Welt über das Internet mit passenden Informationsquellen verbunden werden. Zu jedem Gegenstand sollen Informationen, wie zum Beispiel der aktuelle Aufenthaltsort, verfügbar sein. Das Auto-ID Center schuf dazu entsprechende Normen für Transponder, Lesegeräte und die unterstützende Infrastruktur. Der Electronic Product Code (EPC) soll dabei nicht nur den EAN-Barcode als Produktidentifikationsnummer ablösen, sondern das darauf basierende Netzwerk soll "[ … ] kosteneffiziente, auf Echtzeit basierende, korrekte Informationenüber den Aufenthaltsort von Produkten, deren Entstehungsgeschichte und die Anzahl innerhalb der Supply Chain[ … ]" (aus EAN-Austria 2004) zur Verfügung stellen. Die Idee dabei ist, jedem Produkt, wie etwa einer Milchtüte, eine weltweit eindeutige Nummer zuzuweisen. Über diese Nummer sind dann Ressourcen im Internet, wie zum Beispiel eine HTML-Seite, verknüpft. Eine Ressource enthält wiederum alle interessanten Informationen zu diesem Produkt. Bei der Milchtüte könnten das der aktuelle Standort und das Ablaufdatum sein. (vgl. Floerkemeier 2004 Seite 1)
Gegründet wurde das Auto-ID Center vom Massachusetts Instiute of Technology (MIT) im Jahr 1999. Seit der Gründung haben sich eine Reihe von Universitäten beteiligt, unter anderem die Universität Cambridge und die Universität St. Gallen. Zusätzlich wird das Auto- ID Center noch von über 100 industriellen Partnern unterstützt. Darunter sind hauptsächlich Firmen aus dem Handel und der Konsumgüterindustrie wie Coca-Cola, Gillette, Procter & Gamble und Wal-Mart. Ende Oktober 2003 wurde die Forschungsarbeit beendet und eine Nachfolgeorganisation gegründet mit dem Namen EPCglobal. (vgl. Floerkemeier 2004 Seite 2)
Im Folgenden wird das Zusammenspiel der einzelnen Komponenten des EPC-Netzwerks kurz in ihrer Anwendung gezeigt. Eine genaue Beschreibung der Komponenten folgt in Absatz 2.1.4. Es wird eine Dose von der Produktion bis zum Ladenausgang begleitet und die Einbindung des EPC-Netzwerks in diese Folge von logistischen Prozessen gezeigt. Der Informationsfluss, den die Dose auslöst, wird am Ende dieses Absatzes genauer dargestellt.
Der 1. Schritt
Ein Produkt, in diesem Beispiel eine Dose, wird in der Fabrik hergestellt. Abbildung 1 links zeigt eine Dose nach dem Befüllen. Neben dem üblichen Etikett wird zusätzlich ein RFID- Transponder mit einer noch unverbrauchten EPC aufgebracht. In diesem Beispiel die Nummer '01-A-B-001'. Das A steht für die Kennung des Herstellers, B für den Produkttyp, also in diesem Fall die Dose, und die 001 ist die Seriennummer dieser speziellen Dose.
Abbildung 1 Schritte 1 bis 3 EPC-Netzwerk
Abbildung in dieser Leseprobe nicht enthalten
(vgl. EAN-Austria 2004)
Der 2. Schritt
In Abbildung 1 Mitte, werden mehrere Dosen in eine Transportkiste verpackt. Diese Transportkiste besitzt einen eigenen RFID-Transponder mit EPC.
Der 3. Schritt
Abbildung 1 ganz rechts zeigt ein RFID-Lesegerät, das die RFID-Transponder der Dosen und der Transportkiste beim Verlassen der Fabrik und vor dem Verladen in einen Transporter erfasst.
Der 4. Schritt
Das RFID-Lesegerät leitet die gelesenen Nummern an sein Savant-System weiter. Das Savant-System prüft die EPCs und entscheidet, ob etwas zu tun ist. Zum Beispiel müsste das System die EPCs nicht verarbeiten, die sich seit dem letzten Erfassen nicht weiterbewegt haben und schon verarbeitet wurden. Aber in diesem Fall seien das alles neue EPCs, die das Savant-System noch nicht verarbeitet hat.
Der 5. Schritt
Die Aufgabe des Savant-Systems ist es die Produktinformation zu den neu erfassten Dosen zu ergänzen. Das Savant-System stellt eine Anfrage an einen Server, auf dem der Object Name Service (ONS) läuft, um in Erfahrung zu bringen, wo sich die zu den einzelnen EPC gehörenden Informationen befinden. Der ONS teilt dem Savant-System mit, dass eine Datei für die Dose '01-A-B-001’ unter der URL: http://meinefirma.de/01AB001.pml zur Verfügung steht.
Der 6. Schritt
Das Savant-System besorgt sich diese Datei und fügt einige Informationen hinzu. Zum Beispiel kann der Datei der letzte Aufenthaltsort hinzugefügt werden, in diesem Fall Ausgang Fabrik, und der EPC der Transportkiste, in der sich die Dose jetzt befindet. Abbildung 2 links zeigt die beteiligten Komponenten.
Abbildung 2 Schritte 4, 7 und 8 im EPC-Netzwerk (EAN-Austria 2004)
Abbildung in dieser Leseprobe nicht enthalten
Der 7. Schritt
Abbildung 2 Mitte zeigt ein Verteilzentrum. Hier werden die Lieferungen für die einzelnen Läden aus den Lieferungen der verschiedenen Hersteller zusammengestellt. Ohne dass der Karton geöffnet werden muss, werden die ankommenden Produkte erkannt und die Lageristen können die Produkte auf die richtigen Lastwagen verteilen. Durch das EPC- Netzwerk stehen dem Lageristen Informationen zur Verfügung, um die Lieferungen den richtigen Läden zuzuteilen. Auch diese Informationen besorgt sich dieses Savant-System, wie im 5. und 6. Schritt gezeigt ist. Nach dem Verlassen des Verteilzentrums wird die Dose wieder von einem RFID-Lesegerät erfasst und der Aufenthaltsort wird angepasst.
Der 8. Schritt
Abbildung 2 rechts zeigt, wie ein Supermarkt seine Lieferung mit Dosen erhält. Über das EPC-Netzwerk war der Supermarkt über den Zustand seiner Bestellung informiert. Beim Eintreffen der Lieferung nimmt ein RFID-Lesegerät alle Produkte auf, das Savant-System fügt diese Produkte automatisch dem Inventarsystem des Supermarktes hinzu und verändert die passenden PML-Dateien beim Hersteller, mit dem neuen Aufenthaltsort der Dose oder trägt den neuen Besitzer ein.
Der 9. Schritt
In Abbildung 3 links zeigt, dass die Regale im Supermarkt ebenfalls mit RFID-Lesegeräten ausgestattet sind. Die Regale melden ihre erfassten EPCs wieder einem Savant-System. Dadurch ist jederzeit der genaue Bestand an Produkten in den Regalen bekannt. Beim Entnehmen von Produkten bemerkt das Savant-System, dass ein Produkt nicht mehr im Regal ist und meldet es dem Inventarsystem des Supermarktes. Das Savant-System kann auch bemerken, wenn ein Produkt im falschen Regal liegt und einen Lageristen beauftragen das Produkt in das richtige Regal zu legen.
Abbildung 3 Schritte 9 und 10 im EPC-Netzwerk (EAN-Austria 2004)
Abbildung in dieser Leseprobe nicht enthalten
Der 10. Schritt
Abbildung 3 rechts zeigt, dass am Ausgang des Supermarktes ein RFID-Lesegerät angebracht ist. Dort wird der Inhalt des Einkaufswagens des Kunden gescannt und die Dose kann dem Kunden in Rechnung gestellt werden.
Gesamtübersicht: Objektbewegung - Informationsfluss
Das EPC-Netzwerk soll Informationen zu jedem Objekt verfügbar machen, dabei gibt es statische Informationen, die ein Objekt während seiner ganzen Lebenszyklus behält, zum Beispiel den Namen, das Gewicht oder Verfallsdatum. Zusätzlich gibt es Informationen, wie zum Beispiel den aktuellen Aufenthaltsort, die nur eine bestimmte Zeit gültig sind oder ständig aktualisiert werden müssen. Der folgenden Absatz zeigt an welchen Orten, zwischen der Herstellung und dem Verkauf einer Dose, das ändern der dynamischen Informationen erfolgt.
Abbildung 4 Informationsfluss im EPC-Netzwerk
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4 zeigt noch mal die Schritte 1. bis 10. in einem Bild zusammengefasst. Der dicke schwarze Pfeil zeigt die Bewegung der Dose vom Ausgang der Fabrik, über das Verteil- zentrum und den Ladeneingang zum Einkaufswagen des Kunden auf dem Parkplatz des Ladens. Die dünn gestrichelten Linien zeigen den Informationsfluss, der durch die Dose an den verschiedenen Orten ausgelöst wird. Am Ausgang der Fabrik wird die Dose von einem RFID-Lesegerät erfasst und die EPC dem angeschlossenen Savant-System gemeldet. Diese sucht die Adresse des PML-Servers des Herstellers über den ONS im Internet, besorgt sich die passende PML-Datei und ergänzt diese durch neue Informationen. Dieser Vorgang wiederholt sich an allen Stellen, an denen die Dose ein RFID-Lesegerät passiert. Nur die Informationen, die in der PML-Datei geändert und hinzugefügt werden, sind unterschiedlich. In den letzten beiden Phasen der Produktbewegung kommt eine weitere Komponente hinzu: Die Enterprise Application des Händlers in Form eines Programms, das der Inventar- verwaltung oder Rechnungsstellung dient. In allen Fällen sind die Savant-Systeme die einzigen von sich aus aktiven Komponenten. Durch die Bewegung in der realen Welt löst die Dose jeweils die Ereignisse aus, die ein betroffenes Savant-System zum Handeln bewegen, die anderen Komponenten werden von dem Savant-System genutzt oder mit Informationen versorg.
In diesem Kapitel werden die einzelnen Komponenten des EPC-Netzwerks beschrieben.
Eine weltweit eindeutige Nummer: Der Electronic Product Code Der Electronic Product Code ist eine Möglichkeit der Produktidentifikation. Dabei bekommt jedes Produkt eine eigene, weltweit einmalige Nummer, vergleichbar mit den MAC-Adressen heutiger Netzwerkkarten. "Im Unterschied zu den Ziffernfolgen auf Barcodes, die auf Ver- packungen im Einzelhandel zu finden sind, enthä lt der EPC neben Hersteller- und Produktnummer auch eine Seriennummer." (aus Floerkemeier 2004 Seite 3) Diese Seriennummer ist das Neue am EPC. Der gebräuchliche EAN-Barcode besitzt nur die Hersteller- und Produktnummer.
So kann anhand des EAN-Barcodes sowohl 'Milchtüte mit 3.5% Fett' und 'Milchtüte mit 1.5% Fett' von Hersteller A, als auch 'Milchtüte mit 3,5% Fett' von Hersteller A von 'Milchtüte mit 3,5% Fett' von Hersteller B unterschieden werden. Die Seriennummer erweitert die Unterscheidungsmöglichkeiten. Mit ihrer Hilfe kann man 'Milchtüte mit 3.5% Fett', produziert um 12:00 Uhr, von der Milchtüte, die um 12:01 Uhr produziert wird, unterscheiden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5 Beispiel 96 Bit EPC
(vgl. Floerkemeier 2004 Seite 5)
Der EPC wird zur besseren Verwaltung und Lesbarkeit in vier unterschiedliche Bereiche geteilt, wobei jeder Bereich eine unterschiedliche Länge und Bedeutung hat. Der EPC beginnt mit einem Header, der das Format des EPC definiert. Im Header sind unter anderem die Gesamtlänge des EPC und die Größe der einzelnen Bereiche codiert. Der nächste Bereich identifiziert den Hersteller des Produktes, der dritte Bereich den Typ des Produktes und der letzte Bereich ist eine Seriennummer. Mit dem in Abbildung 5 gezeigten 96 Bit langen EPC lassen sich 268 Millionen Firmen unterscheiden. Jede dieser Firmen kann 16 Millionen verschiedene Produkte in ihrer Produktpalette haben. Jedes dieser 268 * 16 Millionen denkbaren Produkte kann 68 Milliarden Mal produziert und trotzdem noch voneinander unterschieden werden.
Trägermedium der Information: RFID-Transponder und Lesegerät
Ein RFID-Transponder ist ein kleiner Mikrochip mit einer Antenne. Wenn der Mikrochip über die Antenne mit Strom versorgt wird, versendet der Chip die in ihm gespeicherte Information. Dadurch kann die gespeicherte Information ohne direkten Sichtkontakt ausgelesen werden. Abbildung 6 oben zeigt, wie bisher Produktidentifikation betrieben wurde. Es muss dabei immer ein Sichtkontakt zwischen Sender und Empfänger bestehen. Die gängigste und be- kannteste Technik ist das Auslesen eines Barcodes mithilfe eines entsprechenden Laser- scanners. Abbildung 6 unten zeigt das Auslesen eines RFID-Transponder und Lesegerät. Es muss kein direkter Sichtkontakt zwischen Informationsträger und Lesegerät bestehen. Das Auslesen kann durch andere Produkte, Wände oder Verpackungen hindurchgeschehen.
Abbildung 6 Auslesen von Produktidentifikation mit und ohne Blickkontakt
Abbildung in dieser Leseprobe nicht enthalten
Der EPC wird auf einen solchen RFID-Transponder gespeichert. Diese RFID-Transponder können kostengünstig hergestellt werden, da alle Informationen, die dieser Transponder zu speichern hat, nur ein kurzer Bitstring ist. Diese Information muss nur einmal im Transponder gespeichert und nie wieder geändert werden. Alle weiteren Zugriffe auf die Informationen im Transponder erfolgen nur noch lesend. Ein RFID-Lesegerät, das mit einer TCP/IP- Schnittstelle ausgestattet ist und die passende Protokolle beherrscht, kann die empfangenen Informationen weiterleiten. Solche RFID-Lesegeräte gibt es mit verschiedenen Reichweiten, Protokollen und von verschiedenen Herstellern. Deswegen hat das Auto-ID Center ein Referenzsystem erstellt, das vorgibt, was ein RFID-Lesegerät leisten muss, um im EPC- Netzwerk einsetzbar zu sein. Die Technik der RFID-Lesegeräte ist mittlerweile soweit, dass bis zu einer bestimmten Grenze, die Informationen auf Produkten einer ganzen Palette oder eines Einkaufswagens auf einmal ausgelesen werden können und nicht jedes Produkt einzeln am Lesegeräte vorbeigezogen werden muss. (vgl. Floerkemeier 2004 Seite 5ff)
Auskunftsdienst über den Aufenthaltsort der Informationen, Object Name Service Im Folgenden wird die Technologie vorgestellt, die einen EPC mit den Adressen der Informationsquellen verbindet, das heißt, zu einem gegebenen EPC die dazugehörende URL auflöst. Der Object Name Service (ONS), basierend auf dem Dynamic Name Service (DNS), kann einer gegebenen Nummer die Adresse einer Ressource zuordnen. Die Auflösung einer EPC kann auch mehrere Adressen als Ergebnis besitzen. Die Ressourcen sind meisten durch URLs adressiert. Hinter diesen URL(s) können Ressourcen gefunden werden, die Informationen zu der EPC enthalten oder Dienste die Informationen zu dieser EPC entgegennehmen.
Abbildung 7 zeigt den ONS in der Praxis: Ein Savant-System, das die Informationsquelle zu der EPC: '01.A.B.0815' benötigt, stellt eine Anfrage an den ONS über das Internet. Der ONS übermittelt dem Savant-System darauf die URL: www.A.com/01AB0815.pml. Unter dieser Adresse können Informationen zu der gesuchten EPC abgefragt oder ergänzt werden. Dabei übernehmen die Techniken des Internets die Entgegennahme der Anfrage, die Weiterleitung an den ONS und die Zustellung der Antwort an das Savant-System. Savant- System und ONS brauchen dazu nur eine Verbindung zum Internet. (vgl. Floerkemeier 2004 Seite 7-8)
Abbildung 7 ONS löst EPC in URL auf
Abbildung in dieser Leseprobe nicht enthalten
Standardisierte Sprache zum Informationsaustausch: Physical Markup Language Wie die entsprechende Ressource auszusehen hat, kann jeder Hersteller selbst entscheiden. Analog zu den Webseiten im World Wide Web von heute, kann der Hersteller Informationen zu seinen mit EPCs versehenen Produkten für jeden veröffentlichen oder nicht. Keiner ist verpflichtet, Informationen anderen zur Verfügung zu stellen. Ressourcen zu einem EPC können in verschiedenen Formen vorliegen, der Hersteller kann eine einfache HTML-Seite präsentieren, aber auch einen Webservice zur Verfügung stellen, der es erlaubt, diese Informationen nicht nur zu lesen, sondern auch zu verändern. Das Auto-ID Center hat angefangen für die Beschreibung der Informationen zu einem Produkt eine Standardsprache zu entwickeln, die auf XML basierende Physical Markup Language (PML). Die PML ist als Standard gedacht, die es auch den Maschinen ermöglicht, die Informationen über ein Produkt zu verarbeiten. Das Ziel der PML ist es, eine Kollektion von gemeinsamen, standardisierten Vokabeln zur Verfügung zu stellen, um Informationen zu Objekten weltweit an alle möglichen Quellen verteilen zu können. Die Sprache wird sich in verschiedene Vokabulare teilen. Eines dieser Vokabulare, das PML-Core, ist hauptsächlich darauf ausgerichtet, den einzelnen Sensoren, wie zum Beispiel den RFID-Lesegeräten, ein standardisiertes Format für den Datenaustausch zur Verfügung zu stellen. Programmbeispiel 1 zeigt eine PML-Core Nachricht. Eine solche Nachricht wird von einem RFID-Lesegerät erzeugt, wenn es seinem Savant-System etwas mitteilen will. In diesem Fall hat das Lesegerät mit der EPC: '1.4.16.36' zwei Produkte um 4:34 Uhr mit den EPCs '1.2.24.400' und '1.2.24.401' erfasst. Die erste Definition des PML-Core liegt als XML-Schema vor. Dieses Schema definiert auch wie messbare physikalische Größen, wie Zeit, Wärme oder Druck, anzugeben sind. Es gibt zurzeit noch ein weiteres Vokabular für die Kommunikation von Savant-Systemen untereinander und es werden in Zukunft noch weitere entwickelt. (vgl. Floerkemeier 2003 Seite 6 und 7)
Programmbeispiel 1 PML-Core Nachricht eines RFID-Lesegerät an ein Savant-System (vgl. Floerkemeier 2003 Seite 34)
Abbildung in dieser Leseprobe nicht enthalten
Die Schnittstelle der realen Welt und World Wide Web: Savant-System
Das Savant-System ist die Schnittstelle der RFID-Lesegeräte zu den Enterprise Applications. Es stellt den Enterprise Applications verschiedene Funktionen zur Verfügung. Die Lesegeräte melden alle EPCs, die sie erfassen, an ihr Savant-System weiter. Somit ist das Savant-System die Softwaretechnologie, die das Nervensystem eines EPC-Netzwerks darstellt. Es verwaltet die ihm zur Verfügung stehenden Informationen und erfragt passend neue Informationen. Dabei gibt es nicht ein Savant-System, sondern wie bei Webservern viele an unterschiedlichen Orten verteilte Rechner, auf denen die Savant Software läuft. Das Auto-ID Center hat lediglich eine Spezifikation veröffentlicht, was eine Implementierung enthalten soll, um im EPC-Netzwerk einsetzbar zu sein. Eine entsprechende Implementierung der Spezifikation stellt zum Beispiel die Firma SUN her.(vgl. SUN 2004 und Clark 2003 Seite 8)
Ein Savant-System hat folgende Aufgaben (vgl. Clark 2003 Seite 10):
- Eine standardisierte Schnittstelle zwischen RFID-Lesegerät und EA anbieten.
- Das Datenvolumen durch Filtern und Zusammenfassen von EPC-Daten zu reduzieren.
Abbildung 8 zeigt den Aufbau des Savant-Systems. Der Kern eines Savant-Systems ist der Container mit den Verarbeitungsmodulen. Je nach Aufgabe des Savant-Systems können in diesem Container die verschiedensten Module verwendet und miteinander kombiniert werden. Dabei unterscheidet man zwei Typen von Modulen. Einerseits die Standardverarbeitungsmodule, die allgemeine Aufgaben, wie das Weiterleiten der erfassten EPCs an eine Enterprise Application, bearbeiten und anderseits die speziellen oder eigenen Verarbeitungsmodule, die auf die Aufgabe eines bestimmten Savant-Systems zugeschnitten sind. Ein solches Modul kann zum Beispiel auf ein bestimmtes Anwendungsgebiet zugeschnittene Algorithmen zur Reduktion der EPC-Daten enthalten.
Von diesem Kern werden die verschiedensten Schnittstellen angesteuert. Die Hauptschnittstellen des Savant-Systems verbinden die RFID-Lesegeräte auf der einen Seite und die Enterprise Applications auf der anderen Seite. Zusätzlich kann ein Savant-System noch zu anderen Savant-Systemen, dem ONS und weiteren Diensten Schnittstellen besitzen.
Abbildung 8 Aufbau Savant-System (vgl. Clark 2003 Seite 12)
Abbildung in dieser Leseprobe nicht enthalten
Den Geheimagenten kennt man vielleicht noch, aber generell ist das Wort 'Agent' nicht sehr gebräuchlich im Deutschen. Der Agent der Pate für die Namensgebung des SoftwareAgenten gestanden hat, ist der Mitarbeiter einer Agentur der für andere Personen Aufgaben erfüllt, wie zum Beispiel das Organisieren von Reisen.
Abbildung 9 Software-Agent und seine Umwelt
Abbildung in dieser Leseprobe nicht enthalten
Es gibt keine feste Definition, was Software-Agenten sind, aber betrachtet man sich einige Definitionsversuche, werden die wichtigsten Merkmale eines Software-Agenten klar: - "Softwareagent: Eine Softwareentitä t, die vom Anwender delegierte Aufgaben autonom erfüllt" (aus Caglayan 1998 Seite 10)
- "An agent is a computer system that is situated in some environment, and that is capable of autonomous action in this environment in order to meet its design objectives." (aus Wooldridge 2002 Seite 15)
- "An agent is a program that assists people and acts on their behalf. Agents function by allowing people delegate work to them." (aus Lange 1998 Seite 2)
- "Im Sinne einer ersten Arbeitsdefinition verstehen wir unter intelligenten Agenten
Software, die in einer digitalen, vernetzten Umgebung selbststä ndig Aufgaben im Auftrag eines Benutzer erledigt." (aus Brenner 1998 Seite 11)
Diese vier Definitionen zusammen ergeben ein teilweise unterschiedliches Bild von Software-Agenten, haben aber ein paar Gemeinsamkeiten. Software-Agenten sind demnach Programme, die in einer Umwelt (oder Environment, Umgebung, usw.) selbstständig Aufgaben für andere erledigen. Abbildung 9 zeigt einen Agenten in der Umwelt, in die ihn sein Benutzer geschickt hat. Der Agent wird dabei von seinem Benutzer in diese Umgebung mit einem Auftrag geschickt. Dabei kann je nach Typ und Aufgabe des Agenten die Umwelt unterschiedlich aussehen und aus Programmen, Datenbanken, dem Internet, spezieller Hardware aber auch anderen Agenten und der Interaktion mit Menschen bestehen. Die Aufgaben, die ein Agent in dieser Umwelt erledigen kann, sind ebenfalls vielfältig und schwer in einem Satz zu fassen. Zusammenfassend lässt sich folgende Arbeitsdefinition für die Aufgaben eines Software-Agenten festhalten: Die Aufgaben eines Software-Agenten können vieles umfassen. Es sind Aufgaben, die prinzipiell auch ein Mensch in der digitalen Welt erledigen könnte, und die keine allzu großen Anforderungen an die Intelligenz, Kreativität oder sonstige bis jetzt noch alleinige menschliche Eigenschaften stellen.
Da es keine allgemein gültige Definition gibt, was Software-Agenten sind, beschreibt dieses Kapitel, welche Eigenschaften ein Programm haben sollte, um als Software-Agent bezeichnet zu werden. Allerdings muss ein Programm nicht alle der folgenden Eigenschaften besitzen. So ist die Mobilität zwar die bekannteste Eigenschaft, aber nicht jedes Programm, das mobil ist, ist ein Agent und nicht jeder Agent ist mobil. Der Übergang vom Programm zum Software-Agenten kann sehr fließend sein, es gibt keine scharfe Grenze, wann ein Programm ein Software-Agent ist. Es folgt eine Liste der wichtigsten Eigenschaften von Software-Agenten (vgl. Brenner 1998 Seite 25 und Wooldridge 2002 Seite 23):
- Fähigkeit zum autonomen Handeln
- Reaktivität
- Proaktivität
- Lernfähigkeit und automatisches Schließen - Kommunikationsfähigkeit
- Kooperationsfähigkeit - Mobilität
In den folgenden Absätzen werden die Eigenschaften genauer beschrieben.
Die Fähigkeit zum autonomen Handeln
Ein autonom handelnder Software Agent hat die Fähigkeit, seine Ziele zu großen Teilen ohne Eingriffe oder Anweisungen aus seiner Umwelt zu verfolgen. Ein Agent sollte nicht jeden seiner Schritte mit seinem Benutzer oder anderen Agenten abstimmen, sondern er sollte größtenteils selbstständig handeln. Der Benutzer gibt dem Agenten Anweisungen, Vorstellungen und Interessensgebiete. Der Agent erfüllt daraufhin seine Aufgabe, ohne den Benutzer noch einmal zu belästigen. Abbildung 10 links zeigt einen nicht autonom handelnden Agenten, der bei seinem Benutzer jeden Schritt nachfragen muss. Auf der rechten Seite in Abbildung 10 ist ein autonomer Agent abgebildet. Der Agent bekommt einen Auftrag und der Agent meldet sich wieder, wenn der Auftrag ausgeführt ist.
Abbildung 10 nicht autonomer Agent (links) und autonomer Agent (rechts)
Abbildung in dieser Leseprobe nicht enthalten
Benutzer Agent Benutzer Agent
"Um autonom Handeln zu können, mußein Agent zum einen die Kontrolleüber seine Aktionen und internen Zustä nde besitzen [...] und zum anderenüber die zur Lösung seiner Aufgaben notwendigen Ressourcen und Fä higkeiten verfügen." (aus Brenner 1998 Seite 29) Die Ressourcen, die ein Agent benötigt, um autonom handeln zu können, sind dabei eng mit der Aufgabe verbunden, die der Agent bearbeiten soll. Die Fähigkeiten, die ein Agent benötigt, sind Kombinationen aus den später beschriebenen Eigenschaften von Software- Agenten, besonders die Lernfähigkeit und das automatische Schließen. Zusätzlich besitzen Agenten ein spezielles Programmierkonzept ähnlich der Objektorientierung, das wichtige Fähigkeiten für autonomes Handeln zur Verfügung stellt. Ein Beispiel, wie wichtig autonomes Handeln sein kann, geben die Weltraumsonden der NASA. Die Deep Space 1 (DS1), eine Sonde die 1998 gestartet wurde, besitzt ein autonomes und agentenbasiertes Steuerungs- system. In der Zeit vor DS1 wurden bis zu 300 Menschen benötigt, um Weltraummissionen zu überwachen. Diese Mitarbeiter trafen alle Entscheidungen und übermittelten diese an die Sonde. Für kritische Situationen, in denen eine Sonde schnell handeln musste, war dieses Verfahren nicht praktikabel, allein durch die Signallaufzeiten von der Erde bis zur Sonde. DS1 trifft daher wichtige Entscheidungen selbst, besonders bei kritischen Problemen und bekommt von den Wissenschaftlern nur die Langzeitziele mitgeteilt. Dieses selbstständige Handeln hat solche Missionen robuster gemacht und zusätzlich die Gesamtkosten reduziert. (vgl. Wooldridge 2002 Seite 5)
Agenten könnten in vielen Bereichen autonomer handeln, aber oft ist dies nicht vom Benutzer erwünscht, besonders bei Fällen, in denen rechtliche oder finanzielle Konsequenzen durch eine Handlung entstehen, möchten die meisten Benutzer lieber die Entscheidung selbst treffen. Zum Beispiel könnte ein Einkaufsagent nicht nur das gesuchte Produkt günstig finden, sondern es auch gleich kaufen. Aber solche Entscheidung treffen die meisten Menschen lieber selbst.
Reaktivität und Proaktivität
Dieser Absatz soll die beiden Eigenschaften veranschaulichen, die nötig sind, dass ein Software-Agent seine Umwelt wahrnimmt und in ihr handelt. Besitzt der Agent eine Vorstellung von seiner Umwelt ist es ein proaktiver Agent, reagiert der Agent nur auf Veränderungen und Ereignisse aus der Umwelt ist es ein reaktiver Agent.
Abbildung 11 Architektur eines reaktiven Agenten am Beispiel eines Thermostats (vgl. Brenner 1998 Seite 57)
Abbildung in dieser Leseprobe nicht enthalten
Mit Reaktivität wird die Eigenschaft bezeichnet, mit der ein Software-Agent seine Umwelt wahrnimmt, auf Änderungen in dieser reagiert und die Umwelt daraufhin verändert. Die Reaktionen können ausgelöst werden durch:
- Informationen
- Messdaten (z. B. gemessene Temperatur)
- Anweisungen (z. B. der Befehl: Verlasse diesen Rechner, suche eine bestimmte Information)
- Störungen (z. B. der Rechner fährt herunter) - Ereignisse (z. B. ein neuer Agent trifft ein)
Abbildung 11 zeigt den Aufbau eines reaktiven Software-Agenten. Der Agent besitzt Sensoren, um Informationen aus seiner Umwelt zu entnehmen und damit seine Umwelt wahrzunehmen. Der Agent entscheidet mithilfe seiner Kompetenzmodule bei jedem Signal, das über die Sensoren hereinkommt, was als Nächstes zu tun ist, indem eine Regel und der/die passenden Aktor(en) ausgewählt werden. Er reagiert auf das Signal mithilfe seiner Aktoren, mit denen er Einfluss auf seine Umwelt nehmen kann. Ein einfaches Beispiel für die Reaktivität ist der Thermostat (vgl. Weiss 1999 Seite 31). Ein einfaches elektromechanisches Gerät, das die Temperatur in einem Raum überwacht und regelt. Über einen Sensor, dem Temperaturfühler, kann der Thermostat seine Umwelt wahrnehmen. Der Thermostat besitzt drei sehr einfache Kompetenzmodule. Jedes dieser Module besteht aus einer einfachen Regel, siehe Programmbeispiel 2. Mithilfe seines Aktors, der Heizungssteuerung, nimmt der Thermostat wieder Einfluss auf seine Umwelt, je nachdem, welche Regel zutrifft. Abbildung 11 zeigt den Sensor, wie er 15°C Raumtemperatur erfasst. Der Sensor wandelt das Mess- ergebnis in eine Größe um, die von den Regeln verarbeitet werden kann, in diesem Fall '< 20°'. Die Regeln werden nacheinander abgearbeitet. Die erste Regel, siehe Programmbeispiel 2, trifft nicht zu. Deswegen wird die zweite Regel geprüft, diese trifft zu. Die Verarbeitung wird an dieser Stelle abgebrochen, es ist eine gültige Aktion gefunden worden, die Regel identifiziert den passenden Aktor, hier die Heizungssteuerung mit dem Befehl 'Heizung aus'. Der Thermostat verändert darauf hin seine Umwelt, indem er die Heizung einschaltet.
Programmbeispiel 2 prozedurale Regeln für ein Thermostat
Abbildung in dieser Leseprobe nicht enthalten
Folgende Vorteile von reaktiven Software-Agenten sind festzuhalten (vgl. Wooldridge 2002 Seite 96 und Brenner 1998 Seite 56):
- Einfachheit
- Kompaktheit
- Nachvollziehbarkeit der Entscheidungen - Robustheit
- Flexibilität
Die Intelligenz der reaktiven Agenten ergibt sich aus der Interaktion mit ihrer Umwelt, speziell den anderen Agenten und nicht aus intelligenten Kompetenzmodulen. Es gibt aber auch Nachteile, die zu anderen Architekturen, wie Software-Agenten mit ihrer Umwelt umgehen, geführt haben. Folgende Nachteile schränken die reaktiven Agenten ein (vgl. Wooldridge 2002 Seite 97):
- Sie sind überfragt, wenn Situationen eintreffen, für die sie keine Regeln besitzen.
- Sie haben nur ein Kurzzeitgedächtnis; getroffene Entscheidungen werden nicht ge- speichert; eine Entscheidung hat keine Auswirkung auf den Agenten nur auf die Umwelt. - Sie können schwer dazulernen, zum Beispiel wegen des Kurzzeitgedächtnisses - Sie werden immer komplexer, wenn die Zahl unterschiedlicher Ereignisse, auf die sie re- agieren sollen, steigt.
Diese Probleme sollen proaktive Agenten im Gegensatz zu reaktiven Agenten nicht haben. Ein proaktiver Agent plant sein nächstes Vorgehen durch Schlussfolgern. Die proaktiven Agenten werden auch deshalb deliberative oder zielgerichtete Agenten genannt. Ein proaktiver Agent versucht bei seinen Aufgaben zwei Fragestellungen für sich immer wieder zu beantworten (vgl. Wooldridge 2002 Seite 66):
- Was will ich alles erreichen, welche Ziele habe ich? - Wie will ich eines dieser Ziele erreichen?
Dazu besitzen proaktive Agenten ein Modell von ihrer Umwelt und können anhand dieses Modells selbstständig logische Schlüsse ziehen. "Die Modellierung der Umwelt geschieht dabei in der Regel vorab und bildet die wesentliche Komponente der Wissensbasis eines Agenten." (aus Brenner 1998 Seite 52) Darin liegt der Unterschied zu den reaktiven Agenten, welche kein Modell ihrer Umwelt besitzen. Das Modell ist meist eine symbolische Repräsentation der Umwelt.
Die bekanntesten Vertreter der proaktiven Agenten besitzen die BDI-Architektur und wurden Mitte der 80er Jahre eingeführt. Dabei steht BDI für:
- Beliefs (Überzeugungen): Wissen über die Umgebung.
- Desires (Wünsche): Menge aller Handlungsoptionen, auch gegenseitig widersprechende Handlungsoptionen können enthalten sein.
- Intentions (Intentionen): Gewählte Handlungsoptionen
Abbildung 12 zeigt den Aufbau eines BDI-Agenten, die Überzeugungen, die Wünsche und die Intentionen. Aus dem gesamten Wissen, das ein Agent besitzt, leitet dieser seine Überzeugungen ab. Das ist nötig, weil ein Agent viel Wissen besitzen kann, das er für seine weiteren Verarbeitungsschritte nicht benötigt. Zum Beispiel kann der Agent wissen, zu welchem Zeitpunkt er erschaffen wurde; dieses Wissen hat keinen Einfluss auf die zu- künftigen Entscheidungen des Agenten. Aus den Überzeugungen ergeben sich Wünsche.
Aus allen seinen Wünschen leitet der Agent seine nächste Intention ab und damit seine nächste Aktion. In neueren Ansätzen der BDI-Architektur kommen zudem Ziele und Pläne hinzu. Als Ziele sind die Wünsche zu verstehen, die der Agent erfüllen kann, also keine widersprechende Handlungsoptionen mehr. Die Pläne sind die zusammengefassten Intentionen, die der Agent bearbeitet. (vgl. Brenner 1998 Seite 53ff)
Abbildung 12 erweiterte BDI-Architektur eines proaktiven Agenten (vgl. Brenner 1998 Seite 53)
Abbildung in dieser Leseprobe nicht enthalten
Programmbeispiel 3 zeigt einen solchen BDI-Agenten: Als Überzeugungen hat der Agent das Wissen der Positionen mehrerer Goldquellen und eines Monsters. Seine Wünsche sind, alles Gold zu sammeln und dem Monster fern zu bleiben. Aus diesen beiden Wünschen wählt er für seine nächste Aktion aus, das Gold in seiner Nähe einzusammeln.
Programmbeispiel 3 BDI-Agent sucht Gold
(vgl. Kopp 2000)
Abbildung in dieser Leseprobe nicht enthalten
Da aber "deliberative Agenten nur bedingt für den Einsatz in dynamischen Umgebungen geeignet sind" (aus Brenner 1998 Seite 53) gibt es zusätzlich noch die hybriden Agenten. "Wä hrend die reaktive Komponente vor allem zur Interaktion mit der Umwelt verwendet wird, liegt der Schwerpunkt des deliberativen Subsystems, mit seinem [..] Umweltmodell und seiner komplexen Schlußfolgerungsfä higkeit, im Bereich der Planung und Entscheidungs findung." (aus Brenner Seite 60) Welche Komponenten eine Entscheidung treffen, hängt von der Anwendung ab. Die meisten hybriden Agenten besitzen eine Schichtenarchitektur, in der die reaktive Komponente weit unten, also früh Entscheidungen trifft oder auch nur die Rohinformationen sammelt. Während die proaktive Komponente die langfristige Planung und Zielsetzung übernimmt. (vgl. Brenner 1998 Seite 60)
Lernfähigkeit und automatisches Schließen
Ein Software-Agent muss einen gewissen Umfang an Eigenintelligenz besitzen, um zum Beispiel selbstständig zu handeln. Die Software-Agenten bedienen sich dabei dieser drei Techniken, um als intelligent zu erscheinen (vgl. Brenner 1998 Seite 28): - Der Besitz einer internen Wissensbasis.
- Die Fähigkeit, automatische Schlüsse anhand der Wissensbasis zu ziehen.
- Die Fähigkeit zu lernen, also die eigene Wissensbasis zu erweitern und zu verändern.
Die Grundlagen zu diesen drei Techniken werden im Kapitel 2.3 ab Seite 32 genauer behandelt. Grundsätzlich lässt sich festhalten: Die Schlussfolgerungen eines Agenten sollten ihn immer näher zu seinem Ziel führen. Die Schlüsse können mithilfe klassischer Verfahren der Künstlichen Intelligenz, wie etwa regelbasierten Systemen, wissensbasierten Systemen oder neuronalen Netzen, oder neuen agentenorientierten Ansätzen, wie den evolutionären Algorithmen, gezogen werden. Durch die Fähigkeit zum Lernen sollen künftige Entscheidungen des Software-Agenten durch gemachte Fehler und gegebene Vorgaben beeinflusst werden.
Kommunikationsfähigkeit
Kommunikationsfähigkeit ist die Eigenschaft, die es Software-Agenten erlaubt, Daten mit anderen Objekten in ihrer Umgebung auszutauschen. Objekte, mit denen ein Agent Daten austauschen könnte, sind (vgl. Brenner 1998 Seite 31):
- Menschen
- Andere Software-Agenten
- Informationsquellen, wie etwa normale Programme, Datenbanken oder Webseiten
- Spezielle Hardware mit Schnittstellen zu Kommunikationsverfahren
Ein Software-Agent kann sich dabei vieler Verfahren bedienen. Zur Kommunikation eines Agenten mit einer Datenbank kann der Agent auf Schnittstellen wie ODBC und JDBC zurückgreifen. Auf eine Textdatei kann ein Agent über Dateioperationen zugreifen. Die meisten Agenten kommunizieren aber über ein Verfahren, das man im OSI-Modell einordnen kann, da viele Datenquellen, Programme und Software-Agenten Schnittstellen zur Verfügung stellen, wobei "[...]intelligente Agenten [ … ] in der Regel innerhalb der Anwendungsschicht angesiedelt sind" (aus Brenner 1998 Seite 49).
Die häufigste Technik, die Agenten kommunikationsfähig macht, sind die Remote Procedure Calls. Beim Zugriff auf Informationsquellen im Internet oder Intranet kommen jedoch auch Webservices und einfache HTTP-Anfragen vor. Zur Kommunikation mit dem Menschen können die Software-Agenten alle Techniken benutzen, die normale Programme auch benutzen, um Informationen mit dem Menschen auszutauschen. Beispiele sind hierfür die Texteingabe über die Konsole, eine grafische Benutzeroberfläche oder die Spracheingabe.
Kooperationsfähigkeit
Die freie Enzyklopädie Wikipedia gibt folgende Definition von Kooperation an : "Kooperation (soviel wie Zusammenarbeit) ist das Zusammenbringen von Handlungen zweier oder mehrerer Personen / Systeme, derart, dass die Wirkungen der Handlungen zum Nutzen aller dieser Personen / Systeme führen. [ … ] In einer gem äß igteren Form kann man sagen, dass keine Handlungen erwünscht sind, die zum Nachteil einer Seite führen. Kooperation ist damit zumindest für deren Dauer ein Zusammenschluss im Sinne von Systembildung. Es bildet sich gewissermaßen auf einer höheren Ebene (zeitweise) ein neues System. Deren Elemente - die Kooperationspartner - erwarten ein der Kooperation entsprechendes Verhalten. Diese Art von Erwartungen können als Rechte und Pflichten verhandelt und fixiert werden." (aus Wikipedia Begriff Kooperation)
Im Folgenden wird gezeigt, wie man den Begriff 'Kooperation' auf Software-Agenten übertragen kann. Die Kommunikationsmechanismen helfen Software-Agenten beim Zugriff auf externe Ressourcen und beim Führen einfacher Dialoge, wie zum Beispiel die Auftrags- annahmen des Software-Agenten von seinem Benutzer. Aber je komplexer die Aufgaben, umso schwieriger ist es, einen Agenten herzustellen, der alle nötigen Fähigkeiten besitzt. So kann nicht jeder Agent die Fähigkeit zur Kommunikation zu einer bestimmten Datenbank besitzen. Wenn ein Agent dennoch Information aus dieser Datenbank erhalten möchte, kann er mit einem anderen Agenten kooperieren, der die passende Fähigkeit besitzt und die Datenbankabfragen für den Agenten durchführt. Kooperative Agenten bedienen sich Fähigkeiten anderer Agenten, um komplexe Aufgaben schneller und besser lösen zu können, für die ein einzelner Agent überfordert wäre. Zusätzlich tauschen kooperative Software-Agenten ihre Ziele und Wissensbasen untereinander aus, um anderen Agenten zu helfen oder von diesen Hilfe zu bekommen. (vgl. Brenner 1998 Seite 32)
Ein Beispiel für kooperierende Software-Agenten: Drei Agenten bekommen den Auftrag, das aktuelle Datum ihrem jeweiligen Benutzer mitzuteilen. Nur einer dieser Agenten besitzt die Fähigkeit einen Kalender zu lesen. Die beiden anderen Agenten bitten den Agenten, für sie das Datum zu ermitteln und warten, bis dieser mit einem Ergebnis zurückkommt. Der Agent schaut das Datum im Kalender nach und bevor er mit dem Ergebnis zu seinem Benutzer zurückkehrt, teilt er das Datum den anderen beiden Agenten mit. So konnten alle Agenten ihre Aufgabe erledigen. Dabei mussten zwei Agenten gar nicht über die Fähigkeit verfügen, diese Aufgabe direkt auszuführen und der Kalender musste auch nur einmal statt dreimal befragt werden.
Mobilität
Nicht jeder Software-Agent muss mobil sein, die meisten Agenten können ihre Aufgaben auf dem Rechner, auf dem sie erschaffen wurden, bearbeiten. Sie bedienen sich dabei konventioneller Mittel der Kommunikation, um mit ihrer Umwelt zu interagieren. Ein mobiler Software-Agent dagegen ist nicht an den Rechner gebunden, auf dem er erschafften wurde. Er kann sich selbst, also seinen Sourcecode und aktuellen Zustand, über ein Netzwerk zu anderen Rechnern transportieren. Dort kann er mit der Verarbeitung fortfahren, mit der er auf dem letzten Rechner aufgehört hat. Darin unterscheidet sich der mobile Software-Agent von anderen Arten mobilen Sourcecodes, wie Applets und Servlets. Diese, einmal auf ihr Zielsystem übertragen, beginnen dort ihrer Aufgabe immer von neuem, eventuell nur durch unterschiedliche Startparameter verändert. Ein mobiler Software-Agent macht hingegen dort weiter, wo er aufgehört hat und besitzt ein Gedächtnis auch über Systemgrenzen hinweg. (vgl. Lange 1998 Seite 2)
Abbildung 13 Java Applet vs. mobile Agent am Beispiel eines Zählers
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 13 zeigt auf der linken Seite ein Java-Applet, das die Aufgabe hat, sobald es von einem Server auf einem neuen Host übertragen worden ist, bis zwei zu zählen. Dieses Applet wird auf drei Rechner ausgeliefert und zählt dort jedes Mal bis zwei. Auf der rechten Seite dagegen ist ein mobiler Agent abgebildet. Dieser wird vom Server zum ersten Rechner übertragen, zählt dort bis zwei, wird vom Host 1 zu Host 2 übertragen, zählt hier von zwei bis vier, um dann beim dritten Host von vier bis sechs zu zählen.
Zusammenfassend lassen sich folgende Gründe für den Einsatz mobiler Software-Agenten festhalten (vgl. Lange 1998 Seite 4 und 5):
- Reduktion von Netzwerklast: Abbildung 14 zeigt zwei unterschiedliche Ansätze auf einen entfernten Dienst zuzugreifen. In Abbildung 14 oben wird der klassische Weg ge- zeigt. Ein Programm tauscht über einen Remote Procedure Call Daten mit dem entfernten Dienst aus. Abbildung 14 unten zeigt den Ansatz auf einen Dienst mithilfe eines mobilen Software-Agenten zuzugreifen. Der Agent reist mit allen nötigen Daten von seinem Host zu dem Host des entfernten Dienstes. Dort angekommen nutzt der Agent den Dienst lokal. Nachdem ein Gesamtergebnis feststeht und der Dienst nicht mehr benötigt wird, reist der mobile Agent wieder zu seinem Host zurück. Die Zwischenergebnisse müssen in diesem Fall nicht über das Netzwerk übertragen werden. Das dadurch Netzwerklast reduziert werden kann, zeigt das Beispiel des Durchsuchens einer Datenbank. Der Agent begibt sich mit der Suchanfrage zu dem Rechner, auf dem die Datenbank läuft, stellt dort die Anfrage lokal an die Datenbank, durchsucht alle Antworten, filtert die unnötigen Antworten heraus und reist wieder weiter. Je nach Suchanfrage und Filteralgorithmus kann hier die Netzwerklast deutlich reduziert werden. - Reduktion von Signallaufzeiten: In Fällen, bei denen Programme kritische Entschei- dungen in Echtzeit treffen müssen, können mobile Software-Agenten diese Entschei- dungen vor Ort treffen und den eigentlichen Rechner nur periodisch informieren. Auch hier zeigt Abbildung 14 das Prinzip. Die Quelle, die die Ereignisse erzeugt, sitzt in Host 2. Das Programm, das eigentlich für die Überwachung zuständig ist, sitzt in Host 1. Im RPC-basierten Ansatz muss jedes Signal, das die Quelle erzeugt, von Host 2 zu Host 1 übertragen und ausgewertet werden und das Ergebnis zurück zu Host 2. Mobile Agenten können hier die Entscheidung direkt vor Ort auf Host 2 treffen und ihr Programm nur gelegentlich über Veränderungen informieren. Der mobile Agent sitzt direkt auf dem gleichen Host wie die Quelle der Ereignisse, dadurch können die Reaktionen schneller erfolgen.
- Asynchrones Verarbeiten: Mobile Software-Agenten können ihre Rechner verlassen, ihre Aufgabe erledigen und wieder zurückkehren. In der Zwischenzeit muss der Rechner nicht online oder eingeschaltet sein. Bei teuren Netzwerkverbindungen wie GSM oder UMTS ist das ein entscheidender Grund.
- Überall einsetzbar: Hard- und Software innerhalb der meisten Netzwerke sind heterogen. Mobile Software-Agenten sind normalerweise unabhängig von bestimmten Computern, Betriebssystemen, Prozessoren und Transportprotokollen. Dadurch sind mobile Software-Agenten grundsätzlich in einem Netzwerk überall einsetzbar. - Robustheit und Fehlertoleranz: Mobile Software-Agenten können besser auf unvorher- gesehene Ereignisse reagieren. Ein Beispiel wäre das Verlassen des aktuellen Rechners, weil dieser im Begriff ist, herunterzufahren.
Abbildung 14 Reduktion von Netzwerklast durch mobile Agenten (vgl. Lange 1998 Seite 4)
Abbildung in dieser Leseprobe nicht enthalten
Neben den sieben gezeigten Eigenschaften, gibt es eine ganze Reihe von speziellen Eigenschaften, die wie die Mobilität, nur in ganz bestimmten Anwendungen Sinn machen. Zum Beispiel die Fähigkeit des Klonens oder menschliche Gefühle, wie Freude oder Ärger, zu zeigen.
Die Techniken der Software-Agenten geben eine sehr gute Grundlage und Impulse zur Softwareentwicklung der Zukunft. Agentenorientierte Programmierung und Modellierung könnte die Objekt-Orientierung an einigen Stellen ablösen. Die Software-Agenten dehnen das Konzept der Objekte, die bisher 'nur' aus Attributen und Methoden bestehen, um einige Komponenten aus, zum Beispiel der Interaktion oder den Zielen:
"Indeed, many researchers now believe that in the future, computation itself will be understood chiefly as a process of interaction. Just as we can understand many systems as being composed of essentially passive objects, which have a state and upon which we can perform operations, so we can understand many others as being made up of interacting, semiautonomous agents. This recognition has led to the growth of interest in agents as a new paradigm for software engineering." (aus Wooldridge 2002 Seite 7) Interaktion ist wahrscheinlich die wichtigste Eigenschaft von komplexen Programmen. Programme, deren Architektur viele dynamische interagierende Komponenten besitzen, sind viel schwieriger herzustellen, als Programme, die zu einer gegebenen Eingabe eine Ausgabe erzeugen. Die Anzahl der interagierenden Programme wird künftig immer mehr zunehmen. Gleichzeitig wird seit Jahren nach einer Möglichkeit gesucht, solche Anwendungen , zu ver- stehen, zu modellieren und zu implementieren. Mit autonom handelnden und kooperierenden Software-Agenten können solche Umgebungen modelliert und umgesetzt werden. (vgl. Wooldridge 2002 Seite 7)
Um die Erweiterung von Objekten zu Agenten darzustellen ein kleines Beispiel. Ein Objekt o1 hat die öffentliche Methode m1(int arg). Ein Objekt o2, das diese Methode aufrufen will, würde zum Beispiel in Java folgenden Aufruf ausführen: o1.m1(arg). Wobei arg der Parameter ist, den o2 an o1 übergeben möchte. Das Objekt o2 trifft in diesem Fall die Entscheidung eine Methode von o1 aufzurufen.
Das gleiche Beispiel mit den Agenten a1 und a2. Wobei a1 eine Fähigkeit f1 besitzt, die mit der Methode m1 von Objekt o1 vergleichbar ist. Es gibt in der agentenorientierten Welt kein Konzept, das es a2 erlaubt, diese Fähigkeit direkt zu benutzen, weil jeder Agent autonom handelt. Der Agent a2 kann sich nicht darauf verlassen, dass a1 seine Fähigkeit für a2 einsetzt, nur weil a2 das will, aber er kann a1 natürlich trotzdem fragen, ob er die Fähigkeit für a2 einsetzt. In diesem Fall ist die Kontrolle, ob etwas ausgeführt wird, vom Aufrufenden zum Aufgerufenen verschoben worden. Die beiden Agenten sind voneinander unabhängig, können aber miteinander kooperieren. (vgl. Wooldridge 2002 Seite 164)
Suchen, Sammeln und Filtern von Daten und Informationen
Beim Suchen, Sammeln und Filtern von Daten und Informationen stellen sich folgende Probleme:
- Informationsquellen müssen gefunden werden.
- Informationsquellen müssen in eine Form übersetzt werden, die es erlaubt die Informa- tionen weiter zuverarbeiten.
- Informationen müssen in unsinnigen und sinnvolle Informationen unterschieden werden.
[...]
