Agenten im Echteinsatz: Living markets

Die Agenten sind los!

Christian Dannegger, Rolf Katzenberger und Christoph Kluge

Nach den einführenden und grundlagenorientierten Beiträgen unserer Serie über Agenten in Java stellen wir Ihnen im vorliegenden Artikel das Agentensystem living markets dar, welches seit vier Jahren bereits auf Agententechnologien setzt. In diesem Zusammenhang beantworten wir die Fragen: Welche Grundfunktionalität muss ein Agentensystem für den professionellen Einsatz zur Verfügung stellen? Wie sieht ein Softwareprojekt bzw. die Softwareentwicklung mit Agentensystemen aus?

Seit Jahren beschäftigt sich die Wissenschaft mit Softwareagenten. Zahlreiche Beispielsysteme wurden entwickelt, die veranschaulichen, wie Agenten lernen, Fußball spielen oder sich im Internet bewegen. Die meisten Systeme konzentrieren sich dabei jedoch nur auf bestimmte Teilaspekte, wie zum Beispiel die Agentenkommunikation, Sicherheitsmechanismen oder Verzeichnisdienste, bieten aber keine all-umfassende Lösung. Erfahrungs-berichte über den praktischen Einsatz von Agenten-systemen in einem Software-Projekt sind so gut wie überhaupt nicht vorhanden, da es sich fast ausschließlich um Prototypen handelt.
Der erste Teil dieses Artikel beschäftigt sich daher mit der Frage, was notwendig ist, um ein Softwareprojekt auf Basis eines Agentensystems zu realisieren. Im zweiten Teil wird auf das Design von Agenten-Systemen und die Toolunterstützung der einzelnen Entwicklungs-phasen eingegangen.
Artikel, die das Agentenparadigma in der Tiefe erläutern [2], sowie der praktische Einsatz von Agententechnologie [3] verstärken den Anreiz, sich mit diesem Thema intensiv zu beschäftigen. Außerdem sind im Java Magazin bereits einige Beiträge zur Thematik erschienen (siehe [4], [5], und [6]).

Was braucht der Profi?

Welche dieser zahlreichen wissenschaftlichen Ergebnisse und welche Grund- bzw. Rahmenfunktionalität benötigt man für den ernsthaften Einsatz von Agenten? Die living systems AG hat in den vergangenen vier Jahren über dreißig agentenbasierte Lösungen entwickelt und produktiv gestellt. Dazu gehören u.a. aus dem B2B-Bereich netbid.de, reway.com und optimad.com sowie im C2C-Umfeld bereits Anfang 1999 ebay.de und dooyoo.de. Aus diesen Erfahrungen haben sich folgende Anforderungen als wesentlich herauskristallisiert:
Selbstverständlich ist Kommunikation das zentrale Bindglied für die vernetzten und kollaborativen Systeme der Gegenwart und Zukunft. Entgegen einem Experimentierumfeld, in dem ein einziges Protokoll zum Testaufbau reicht, muss ein Produkt zum Echteinsatz durch Auswahlmöglichkeiten beim Kommunikations-protokoll möglichst große Offenheit zeigen. Die Unterstützung von RMI als üblicher Java-Standard, HTTP zur Vermeidung von Firewall-Problemen, raw Sockets auf Basis von TCP/IP, JMS oder auch CORBA sind wünschenswert. Eine Architektur (siehe Abb. 1), die die Austauschbarkeit der Kommunikationsschicht (communication) ermöglicht, zeigt sich bei den aufgeführten Protokollen flexibel und zukunftssicher.

Abb. 1: Die Architektur eines Agenten von living markets

Schnittstellenvielfalt: Schnittstellen und deren Standardisierung sind und bleiben wohl ein ewiges Thema. Die Lösung der grundsätzlichen Kommunikation ist noch leicht zu bewerkstelligen, da es um die technische Seite des Datenaustausches geht. Bei den Inhalten (im Agentenumfeld redet man von Ontologien) sieht es anders aus. XML löst leider nicht das Problem der richtigen Interpretation der auszutauschenden Daten. Mapping- und Übersetzungs-Aufgaben von Datenstrukturen werden z. B. durch XSL und XSLT allgemein gelöst. Damit ist es möglich, Mappinginformation getrennt vom eigentlichen Agentencode (Geschäftslogik und Strategie) zu halten. Die zentrale Einbindung dieser oder einer vergleichbaren Technologie ist deshalb essentiell. Sie sollte direkt an der Kommunikationsschnittstelle des Agenten ansetzen. Ein Agent kann so mit seiner eigenen Ontologie arbeiten und doch mit beliebig vielen (konfigurierbaren) Fremdsystemen reden.
Die Offenheit eines Systems, d.h. dass man sich keine zukünftigen Möglichkeiten verbaut, ist natürlich der permanente Wunsch eines Entwicklers. Dies betrifft einerseits die gerade besprochenen Punkte Kommunikation und Schnittstellen. Hinzu kommt aber auch die Offenheit der Programmiersprache und Laufzeitumgebung. Gerade deshalb ist Java der ideale Partner für Agentenentwickler. Insbesondere bei der Laufzeitumgebung – dem Agentenserver – ist es wichtig, dass der Entwickler Kontrolle über den Agenten (Thread) behält und auch alle weiteren Möglichkeiten, die Java bietet, zur Verfügung stehen.
Als grundlegender Standard für Dokumentenaustausch, d.h. Kommunikation, ist XML einfach ein Muss. Ideal ist eine Verwendung von XML im innersten Kern, wie auch bei der Konfiguration des Gesamtsystems und der Agentenstrategie (Businesslogik, Abläufe, Verhalten). Da Geschwindigkeit im Produktivumfeld immer über den Einsatz einer Lösung entscheidet, muss dieser gerade im Umgang mit XML erhöhte Aufmerksamkeit gewidmet werden. Deshalb unsere klare Empfehlung: (a) durchgängig und nach außen hin transparente Verwendung von XML und (b) optimierter Austausch von XML-Objekten durch Referenzen im Innenverhältnis des Agentenservers.

Sicherheitsmechanismen: So offen, wie wir die Systeme immer gerne haben, so kritisch sollten wir sein, wenn es um die Sicherheit geht. Dabei sind verschiedene Dinge zu betrachten:

  • (a) der Zugriff auf einen Agenten,
  • (b) die Verschlüsselung des Datenverkehrs zwischen Agentenservern und Fremdsystemen und
  • (c) der Schutz vor Programmierfehlern oder feindlichen Agenten.

(a) Den Agentenzugriff regelt ein Access-Control-System, in dem man für jeden Agenten konfiguriert (selbstverständlich in XML), von welchem Agenten er welche Message (d.h. Subject der Message) akzeptiert. Nicht jeder Agent darf zum Beispiel einen anderen Agenten beenden, indem er eine entsprechende terminate-Nachricht schickt.
(b) Da Agenten oft auch private oder geheime Informationen zwischen sich oder ihrem Auftraggeber austauschen, sind entsprechende Verschlüsselungstechniken für den Inhalt einer Nachricht unerlässlich. Diese lassen sich am besten über der Kommunikationsschicht implementieren (siehe Abb. 1). Somit ist es dem Entwickler überlassen, welche Sicherheitsstufe er benutzt – z. B. über eine konfigurierbare Schlüssellänge.
(c) Mit dem verstärkten Aufkommen von Peer-to-Peer-Systemen, für die sich Agentensysteme im besonderen eignen, wird die Anforderung an Sicherheits-mechanismen vor feindlichen Agenten immer wichtiger. Feindliche Agenten sind vergleichbar mit trojanischen Pferden, die sich nach außen hin wie andere Agenten verhalten aber virulenten Code enthalten. Agentensysteme müssen in der Lage sein, diese Trojaner automatisch zu erkennen und vom System zu entfernen.

Dieser letzte Punkt wird aber sicher erst in der zweiten Agentenwelle zu einem echten Thema, da kollaborative Systeme in den nächsten Jahren meist intern oder in Unternehmens- bzw. Industrie-Verbänden Verwendung finden. Dabei ist die Zusammenarbeit durch Verträge geregelt, die malicious agents von vorne herein ausschließen.
Wenn’s um Geld geht (und wo ist das nicht der Fall 😉 ?) ist Datenintegrität und Transaktionssicherheit oberstes Gebot. Agenten und Agentenserver, die Bestellungen abwickeln und Finanzdienstleistungen anbieten, müssen daher (Datenbank-) Transaktionen unterstützen. Wird die Java Transaction API (JTA) unterstützt, lassen sich alle verteilte Objekte, die diesen Standard einhalten, in eine Transaktion einbinden (Two-Phase-Commit).
Persistenz: Und immer quält die Frage: Was passiert mit den Agenten, wenn der Server abschmiert? Zum einen gibt es die Möglichkeit, die wichtigsten Zustandswechsel eines Agenten (transaktionsgesichert) in der Datenbank abzulegen. Unabhängig von der Datenbank kann ein Agentenserver aber auch die Persistenz eines gesamten Agenten garantieren. Ein idealer Server erlaubt die regelmäßige Sicherung des Agenten – gesteuert durch dessen Businesslogik – und stellt das System beim Neustart automatisch mit den gesicherten Agentenzuständen wieder her.
Jetzt hat man ein erfolgreiches Agentensystem online gestellt und die Anwender danken es einem mit hohen Zugriffszahlen. Das sollte einen Agentenentwickler nicht beunruhigen. Ein Agentenserver kann und muss die Skalierbarkeit garantieren. Auch hier existieren mehrere Möglichkeiten: Das Agentenparadigma erlaubt und sieht vor, Agenten zu klonen. Dadurch lässt sich die Last der Zugriffe auf verschiedene Agenten und auch mehrere Rechner verteilen. Die Skalierbarkeit ist nur möglich, wenn die Messages zu den Agenten intelligent geroutet werden. Bei living markets sorgt der MessageRouter-Agent für die Weiterleitung an abgereiste Agenten. Alternativ zum expliziten Starten mehrerer Agenten bietet LARS, das living agents runtime system, einen Thread-Pool an: jeder Agent steht dadurch automatisch mehrfach zur Verfügung.

Clustering von Agentenservern: Mit der Skalierbarkeit einher geht die Verbindung mehrerer Agentenserver zu einer logischen Einheit (Cluster). Der Ausfall eines Servers des Clusters darf das Gesamtsystem nicht stören. Genauso geräuschlos muss sich ein Server nach dem Reboot wieder ins Netz eingliedern. Routing, Forwarding, Broadcasts etc. sind durch entsprechende Abstimmungsprotokolle abzudecken.
Der Anspruch an die Flexibilität von Lösungen ist fast so hoch, wie der an Integrität und Geschwindigkeit. Heutige Systeme müssen für die Veränderung konstruiert sein. Als sinnvoll hat es sich erwiesen, die Grundfähigkeiten (Capabilities) der Agenten von deren Strategie (Geschäftslogik) zu trennen. Vorteilhaft ist dabei nicht nur die Flexibilität bei Änderungen der Strategie, sondern auch, dass sich der Softwareentwickler auf die Entwicklung granularer Teilaspekte konzentrieren kann. Der Strategie-Designer sollte in der Lage sein, über eine einfache Hochsprache Businessprozesse zu beschreiben und damit sein System konfigurieren können.

Entwicklungs- und Konfigurationstool: Für die schnelle und effektive Entwicklung und Pflege einer Agentenlösung ist ein umfassendes Tool notwendig, das nicht nur ein Java-Entwickler bedienen kann, sondern das auch einen Kunden in die Lage versetzt, Veränderungen auf Geschäftsmodellebene vorzunehmen. living markets beinhaltet ein solches Tool, das wir weiter unten näher vorstellen.

Testsuites für Agenten: Automatische Tests gehören in der Produktentwicklung zum Standard. Hier bietet sich JUnit an, ein bewährtes Framework, das aber um agentenspezifische Zusätze erweitert werden muss. Über JUnit lässt sich kontinuierlich und automatisiert prüfen, ob sich das Verhalten eines Agenten nach Änderung seiner Codebasis oder Konfiguration geändert hat. Durch diese Prüfungen kann sichergestellt werden, dass Agenten oder Systeme, die sich dessen Agenten bedienen, auch weiterhin lauffähig bleiben. Auch die Integration mit weiteren, Open-Source-basierten Erweiterungen von JUnit gestaltet sich einfach, beispielsweise zur Realisierung von Interoperabilitätstests von Agentenservern, Webservern und Servlet Engines.
Zieht man alle diskutierten Teilaspekte eines Agentensystem in Betracht, wird einem der lange Weg von einem experimentellen zu einem produktionsreifen Agentensystem erst richtig bewusst. Die living systemsAG hat in den vergangenen fünf Jahren mit living markets eines dieser produktionsreifen Agentensysteme entwickelt.

Abb. 2: Agentenorientiertes Design

Entgegen der objektorientierten Analyse (OOA/OOD) beginnt der Entwurf eines Agentensystems eine Stufe höher. Bei der Modellierung einer Lösung beginnt man mit der Definition und Beschreibung der Rollen (siehe Abb. 2), die am System beteiligt sind – der Einheiten, die eben eine Rolle spielen. Der Definition und Zuordnung von Rollen sind dabei keine Grenzen gesetzt – Phantasie ist gefragt.
Naheliegend ist es, z.B. im Logistikumfeld, einem Agenten die Rolle LKW-Fahrer zuzuordnen. Er hat die Aufgabe, Fracht zu laden, zum Zielort zu fahren und sie dort wieder abzuladen. Mit dieser Aufgabe übernimmt der Agent auch die Verantwortung, diese korrekt durchzuführen, was er aufgrund seines Expertenwissens (Fahren, Streckenauswahl, Fahrzeiten, etc.) auch kann. In diesem Fall hat der LKW-Fahrer die aktive Rolle, sich eine Fracht zu suchen.
Etwas ungewöhnlicher ist es, eine Ladung oder einen Artikel als Agenten mit Rollenverständnis zu modellieren. Dies ist aber auch möglich. Dann sucht sich die Fracht einen LKW. Die Granularität, in der man die Agenten modelliert, unterliegt natürlich der Erfahrung des System-Designers.
Nach der Rollendefinition überlegt man sich die Ziele jeder Rolle, d.h. der einzelnen Agenten. In der Realität übernimmt eine Person fast immer mehrere Rollen. In der Agentenwelt werden diese Rollen idealerweise jeweils einem Agenten zugeordnet, der dann zielorientiert seine Aufgabe wahrnimmt. Da ein Agent mehrere Ziele haben kann, sind aber auch mehrere Rollen je Agent nicht ausgeschlossen.
Im dritten Schritt legt man die Aktionen fest, die zur Zielerreichung notwendig sind und wann diese angewendet werden müssen. Oft handelt es sich dabei um komplexe Netzwerke von Regeln und Aktionen mit denen der Agent konfiguriert wird.
Nun aber muss man herausfinden, wie man denn die festgelegten Ziele erreicht. Dies bedeutet, Aufgaben (tasks) zu definieren, die ganz oder teilweise zur Erreichung eines Zieles führen. Die einzelnen Aufgaben bestehen aus mehreren Einzelschritten, die sich als (Mikro-)Workflow innerhalb eines Agenten konfigurieren lassen.
Die Übersicht über die Konfiguration eines Agenten und auch eines gesamten Agentensystems zu behalten, erfordert den Einsatz eines Konfigurationstools. Dieses kann schon zu Beginn der Software-entwicklung eingesetzt werden, um die Business Prozesse bzw. den Workflow eines Agenten zu beschreiben.
Um genau die oben erläuterten vier Schritte (roles, goals, tasks und workflows) nicht erst (auf Papier) zu entwerfen und dann zu implementieren, unterstützt living markets genau diesen Modellierungsprozess durch die living markets development suite (LMDS). Das Verhalten der Agenten wird grafisch konfiguriert und in XML-Konfigurationsdateien festgehalten, die direkt die Geschäftslogik des Agenten darstellen.

Die living markets development suite

Die living markets development suite (LMDS) unterstützt folgenden Phasen der Software Entwicklung: Analysis & Design, Product Development und Customization. Abpictureung 3 veranschaulicht, wie die LMDS in den Gesamtzyklus eines Sofwareprojektes eingeordnet werden kann.

Abb. 3: living markets Solution Lifecycle

Während die LMDS die Phasen der Software-Entwicklung unterstützt, erlaubt das LARS cockpit die Kontrolle des Systems zu Laufzeit. Damit verwaltet man das laufende System, überwacht es und kann direkt eingreifen.
Im Folgenden beschreiben wir anhand eines Beispiels, wie die oben erwähnten Entwicklungszyklen durch ein entsprechendes Tool unterstützt ablaufen können.

Beispiel: ein Logistiknetzwerk

Zunächst legt man nach dem Start der LMDS (siehe Abb. 4) ein Project an (hier: logistics example). Innerhalb eines Projektes lassen sich mehrere Sichten auf eine Problemstellung verwalten und entwerfen. LMDS nennt diese Sichten Scenarios. Ein Scenario (hier: on the road) stellt den Workspace für die Agenten dar. Dort definiert man die Agenten und deren Rollen. Zur ersten Einordnung und Dokumentation des Agenten beschreibt man diesen im Dokumentationsfeld und gibt ihm ggf. ein Icon zur besseren Visualisierung der Rolle des Agenten. Ein Agent kann auch in mehreren Szenarios verwendet werden.

Abb. 5: living markets development suite – Agent Properties

Anschließend erfolgt die Beschreibung der Kommunikation zwischen den Agenten. Durch das Verbinden der Konnektoren zweier Agenten mit der Maus erzeugt man eine Message. Diese wird im nächsten Schritt detailliert (Subject, Content der Nachricht) beschrieben. Nach und nach erhält man ein Bild des Kommunikations-scenarios und der Abläufe in einem dynamischen Umfeld. Jede Verbindung erzeugt im empfangenden Agenten automatisch einen leeren Workflow (Task), die es bei der weiteren Konfiguration (Properties) zu spezifizieren gilt.
Ein Scenario gibt also den allgemeinen Überblick einer Lösung. Das Verhalten und die Aufgaben jedes einzelnen Agenten stellt man in einem detaillierten Properties-Window zusammen. Dieses Properties-Window erlaubt die komplette Entwicklung bzw. Konfiguration des Agenten.
Unter Basics findet man die allgemeine Beschreibung des Agenten. Bei Beans stellt man die Grundfunktionalität zusammen, was gleichbedeutend ist mit dem Expertenwissen des Agenten. Beans sind z.B. CommerceBean, LogisticsBean, FinanceBean oder das SystemBean. Jedes Bean enthält Fähigkeiten in Form von Action- und Perception-Methoden. Aus diesen Fähigkeiten baut man nun per Drag&Drop einen Workflow bzw. ein Verhaltensnetzwerk (Behavior) auf (siehe Abb. 5). Verhaltensnetzwerke (Extended Behavior Networks) wurden im Java Magazin 9.01 behandelt (siehe [6]).
Die durch Beans angebotene Grundfunktionalität ist in Form von Java-Methoden implementiert. Damit gibt es für die Entwicklung von Agenten keinerlei Einschränkung in der Verwendung vorhandener Bibliotheken und Technologien.
Alle Einstellungen des Tools sowie der Agenten werden in XML-Dateien gespeichert. Diese XML-Konfiguration wird direkt vom Agentensystem gelesen, d.h. es wird ein Agent mit der hier spezifizierten Strategie (Workflow oder Verhaltensnetzwerk) als Business-Logik gestartet. Weitere Compile- oder Deployment-Vorgänge sind nicht notwendig.
Die Basisagenten zur Verarbeitung der Verhaltensnetzwerke bzw. Workflows beinhalten entsprechende Logic-Engines. Über die beiden vorhandenen Grundlogiken hinaus sind weitere in Vorbereitung: Plan Engine, Constraint Satisfaction Engine, sowie eine Rules Engine. Die Architektur ist heute schon vorbereitet auf den dynamischen Einsatz beliebiger weiterer Lösungsalgorithmen, d.h. Logic-Engines.


manager.log

INFO

agents/lars/AgentManager.cfg

Nachdem ein Agentenserver läuft, muss man ihn unter Kontrolle bekommen (und behalten). Dazu dient das LARS cockpit. Dieses Tool erlaubt die Verbindung mit einem beliebigen Agentenserver, um dann direkt auf Kommandoebene zahlreiche Befehle auszuführen, wie: list, send, read inbox, read outbox, set trace level, new (start agent), kill, delete (agent) usw. Obwohl eingefleischte Unix-Admins die Kommandoebene bevorzugen, wird die nächste Version von living markets um eine grafische Oberfläche erweitert werden.
Nach dem Start und der Verbindung mit dem Server eröffnet einem das LARS cockpit einen Satz an Kommandos, der noch beliebig erweitert werden kann.

Command> connect -id lars -ip 192.168.52.14 -type socket -port 8005

Das Kommando list kontaktiert den Agent Manager (am) und erhält von diesem die Liste aller gerade laufender Agenten (siehe Listing 2).

Listing 2

Command> list
service             list_of_agents
type                single
sender              am@192.168.52.14-lars
receiver            Cockpit.997979206354@192.168.52.14-lars
replyWith           null
inReplyTo           3
qualityOfService    QOS_REPLY_ERROR
priority            20
sentTime            997979679296
currentHops         2
expireHops          10

Press  to continue.
content             {agent40=AgentFactory0@192.168.52.14-lars,
agent9=AgentAuctionBid@192.168.52.14-lars,
agent8=AgentCurrencyRates@192.168.52.14-lars,
agent7=AgentStore0@192.168.52.14-lars,
agent6=AgentTruck1@192.168.52.14-lars,
agent5=at@192.168.52.14-lars}

Das Hilfesystem gibt detailliert Auskunft über jedes einzelne Kommando (siehe Listing 3).

Listing 3

Command> help new
creates a new agent
Usage:  new
-class [className] (e.g. 'com.ls.lars.server.TestAgent')
-name [agentName] (e.g. 'AgentTest')
-replyWith [id] (id to get a answer with, if an answer will be sent)
-cfg [configFile(s)] (one or more config files separated by commas)
-xml/-string [content] (class name, agent name and     config files)
-type [messageType] (single, serviceSingle, serviceBroadcast,
group and multicast messages)
-platform [platfromName] (the name of the platform to send service
messages to)
-priority [priority] (priority to send the message with)
-expireHops [hopCount] (the hops available to send a message)
Example:    new -class com.ls.internet.auction.AgentExchange -name
AgentExchange -cfg Database.cfg, AgentExchange.cfg

Command>

Dem Einsatz von Agentensystemen steht nichts mehr im Wege. Mit dem living agents runtime system (LARS), Bestandteil von living markets, steht ein Agentenserver zur Verfügung, der sehr viele der theoretischen Grundlagen verwendbar macht, sodass eine Verwendung im rauen Produktivalltag problemlos möglich ist. Über 30 B2B-Plattformen, sowie der harte Test durch die ebay-User, eine der größten C2C-Gemeinden, zeugen von einer reifen Technologie. Endlich ist es möglich, die Agententechnologie, die viele begeistert, einzusetzen. Nicht zuletzt die Modellumgebung Robocup (siehe Java Magazin 9.01 – [6]) zeigt anschaulich, wie robust sich ein zielorientiertes System in einem dynamischen, nicht-deterministischen Umfeld verhält, in dem permanent schnelle Entscheidungen zu treffen sind.

Christian Dannegger ist CTO (Chief Technology Officer), Christoph Kluge Senior Software Architect und Rolf Katzenberger Director Product Development bei der living systems AG.

  • [1] living systems AG: www.living-systems.de
  • [2] Yu, Eric: Agent orientation as a modelling paradigm. In: Wirtschaftsinformatik 43 (2001) 2
  • [3] Sundermeyer, Kurt; Bussmann, Stefan: Einführung der Agententechnologie in einem produzierenden
    Unternehmen – ein Erfahrungsbericht. In: Wirtschaftsinformatik 43 (2001) 2
  • [4] Christian Dannegger, Dr. Klaus Dorer: Agenten in Java I: Grundlagen und Hintergründe, Java Magazin 7.2001
  • [5] Christian Dannegger, Dr. Klaus Dorer: Agenten in Java II: Der technologische Unterbau, Java Magazin 8.2001
  • [6] Christian Dannegger, Dr. Klaus Dorer: Agenten in der Wissenschaft: Der RoboCup, Java Magazin 9.2001
Geschrieben von
Christian Dannegger, Rolf Katzenberger und Christoph Kluge
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.