Aktuelle AMETAS-Projekte

Stand:
2002-04-13

Auf dieser Seite finden Sie eine Übersicht über abgeschlossene und aktuelle Projekte im AMETAS-Umfeld.

Der IntraManager ist eine Netz- und Systemmanagement-Anwendung auf Basis mobiler AMETAS-Agenten. In modernen Netzwerken wird das sinvolle, effektive und effiziente Management der angeschlossenen Ressourcen und Anwendungen zunehmend zu einem Problem. Herkömmliche zentralistische Ansätze sind aufgrund mangelnder Skalierbarkeit und Flexibilität nicht mehr in der Lage dieses Problem zu lösen. Daher werden seit einiger Zeit dezentrale Ansätze auf Basis verschiedener Technologien erforscht. Eine dieser Technologien sind mobile Agenten, welche autonom durch ein Netzwerk reisen können, um diverse Managementaufgaben zu erledigen. Dabei übernehmen Sie eigenständig im Rahmen der ihnen zur Verfügung stehenden Intelligenz die Verantwortung für bestimmte Managemententscheidungen oder informieren hierarchisch höherstehende Instanzen (wie z.B. einen menschlichen Administrator), wenn vordefinierte Ereignisse eintreten. Durch die Verteilung und Dezentralisierung des Netzmanagements wird das Netzwerk entlastet. Es werden nicht mehr große Mengen von Rohdaten zur zentralen Auswertung übertragen, sondern die Software zur Auswertung dieser Daten wandert in Form mobiler Agenten zur Quelle der Daten. Dies erhöht die Skalierbarkeit, die Robustheit und die Flexibilität solcher Management-Anwendungen und ermöglicht die Einbettung von Mechanismen aus dem Bereich der Künstlichen Intelligenz. Im IntraManager werden hier insbesondere Neuronale Netze zu Erstellung von Lastprognosen verwendet. Das IntraManager-Projekt ist von der DFS (Deutsche Flugsicherung) finanziert.

Sowohl Agentensysteme als auch klassische objektorientierte Systeme wie CORBA zählen zur Software-Kategorie der Middleware. Als solche stellen sie eine Grundlage für die Erstellung verteilter Anwendungen dar. Jedoch treffen hier zwei völlig unterschiedliche Paradigmen aufeinander, deren Interoperabilität grundlegende Fragen aufwirft. AMETAS bietet auf Grund seiner strengen, inhärenten Asynchronität einen neuen Blick auf die Kommunikation in objektorientierten Verteilungsplattformen. Dies scheint zunächst einer Integration mit CORBA entgegenzustehen; denn die meisten CORBA-Anwendungen basieren auf dem klassischen synchronen Kommunikations-Paradigma wie man es von der Kommunikation von Objekten im lokalen Fall kennt. CAI soll eine Interoperabilität zwischen Multiagenten-Anwendungen im AMETAS-System und herkömmlichen CORBA-Objekten ermöglichen. So soll es CORBA-Klienten in transparenter Weise mögliche sein, Agenten-basierte Dienste zu nutzen. Ebenso sollen mobile Agenten in der Lage sein, CORBA-basierte Dienste in Anspruch zu nehmen. Das Ziel der Arbeit ist eine transparente Interoperabilität zum Nutzen beider Welten. CAI wird zur Zeit im Rahmen einer Diplomarbeit entwickelt.

KQML ist eine Agenten-Kommunikationssprache (ACL), welche auf den Prinzipien der Sprachakttheorie basiert. Sie stellt sogenannte Performatives bereit, mit denen Agenten Wissen austauschen können. Dieses Wissen kann dabei in einer beliebigen Inhaltssprache, wie z.B. KIF (Knowledge Interchange Format), XML oder Prolog formuliert sein. Die grundlegende Kommunikations-Architektur von AMETAS baut auf dem asynchronen Austausch von Nachrichten auf, deren Inhalt keinem allgemeinen Format entsprechen muss und in der Regel von der jeweiligen Anwendung zu interpretieren ist. Auf diesem System baut das KQML-Rahmenwerk auf. Es bildet eine Kommunikationsschicht, auf der Wissen in einem bestimmten Format über Nachrichten ausgetauscht werden kann, welche der KQML-Spezifikation entsprechen. Hierdurch wird den Nachrichten von der Nachrichtensyntax eine Struktur verliehen, welche die Interpretation des enthaltenen Wissens auf eine standardisierte Basis stellt. Die Semantik einer Nachricht ist nun nicht mehr anwendungsspezifisch, sondern allgemein interpretierbar. Das AMETAS-KQML-Rahmenwerk wurde im Rahmen einer Diplomarbeit erstellt und wird in naher Zukunft in AMETAS-Standarddistribution eingebunden.

E-Commerce bildet seit jeher eine der meist genannten Anwendungsdomänen für mobile Agenten. Um effektive Agenten-basierte E-Commerce-Systeme betreiben zu können, ist jedoch zunächst eine Informations-Infrastruktur notwendig, welche Käufer und Anbieter zusammenführt. Eine solche Infrastruktur sollte offen und dezentral gestaltet werden, damit das Gesamtsystem von Anbietern und Käufern dynamisch erweitert werden kann und die Robustheit und Skalierbarkeit sichergestellt ist. Der DYPS ist ein solches dezentrales offenes Informationssystem für mobile Agenten im e-Commerce. Informationen über das Angebot und den Standort von Anbietern werden mit Push- und Pull-Mechanismen verbreitet, welche entfernt an das Prinzip des Usenet angelehnt sind. Hierbei werden mobile Agenten eingesetzt, welche als intelligente Informationskuriere dienen und eine sinnvolle Verbreitung der Information innerhalb des Systems sicherstellen. Die mobilen Käufer-Agenten einer e-Commerce-Anwendung können auf diese Information zugreifen und aus ihr einen individuellen Reiseplan erstellen, welcher sie zu den für sie interessanten Anbieterdiensten führt.

Der Agenten-Monitor ist ein Werkzeug zur Visualisierung und Überwachung von AMETAS-Anwendungen. Insbesondere die Migrationstätigkeit mobiler AMETAS-Agenten kann hiermit beobachtet und analysiert werden. Der Monitor dient im Wesentlichen der Analyse und Verbesserung bestehender AMETAS-Anwendungen und soll die Entwicklung neuer Anwendungen unterstützen.

Die Effizienz einer Verteilungsplattform sollte während des Entwicklungsprozesses stets kritisch betrachtet werden, damit in späteren Anwendungen nicht die fehlende Effizienz der Plattform zu einem beschränkenden Faktor wird. Um Effizienz erfassen, bewerten und vergleichen zu können, ist ein System notwendig, welches den Entwicklungsprozess der Verteilungsplattform unterstützt und genormte, nachvollziehbare Tests zulässt. In AMETAS füllt diese Rolle das AMETAS-BMS aus. Es gestattet die Erstellung eigener Benchmark-Module, welche in das Grundsystem integriert und zu komplexen Testabläufen zusammengestellt werden können. Das BMS erlaubt es vergleichende Tests anzustellen und so Auswirkungen von Änderungen auf die Effizienz zu bewerten.

Bei der wachsenden Komplexität moderner verteilter Anwedungen kommt dem Management dieser Anwendungen eine zunehmende Bedeutung zu. Die Aufgabe des Anwendungsmanagement ist bereits in Systemen ohne Mobilität eine große Herausforderung. Anwendungen, welche aus marodierenden Horden mobiler Agenten bestehen ;-) werfen in dieser Hinsicht spezielle Probleme auf. Welchen Einfluss hat die Mobilität auf das Management? Wie kann sich ein Administrator ein konsistentes Bild der Gesamtanwendung machen? Wie kann z.B. Performanz und Fehlerverhalten solcher Anwendungen gemessen, beurteilt und positiv beeinflusst werden? Diese und ähnliche Fragen gilt es innerhalb dieser Diplomarbeit anzugehen.

Für die Unterstützung des Entwicklungsprozesses herkömmlicher Software gibt es eine Unzahl von Werkzeugen, die große Teile des Programmcodes automatisch erzeugen und es dem Entwickler so ermöglichen, sich auf das Wesentliche zu konzentrieren: die Funktion. Ist so etwas auch für Mobile-Agenten-Software möglich? Die Schwierigkeit besteht hierbei darin, dass Muster für die Entwicklung mobiler Agenten noch nicht allgemein erforscht sind. Die Mobilität fügt zur Komplexität solcher Anwendungen eine weitere Dimension hinzu. Wie spezifiziert man, was ein Agent tun soll? Wie gibt man an, wie wann und wohin er reisen soll? Welche Forderungen stellt die Autonomie und die asynchrone Kommunikation an den Entwurfsprozess? Diese Fragen sind schwer zu beantworten, was ein Werkzeug zur allgemeinen Entwicklungsunterstützung im Sinne der visuellen Programmierung im Moment in weite Ferne rückt. Identifiziert man jedoch einen begrenzten Anwendungskontext und damit verbundene Einschränkungen und Anforderungen an mobile Agenten einer speziellen Anwendung, so kann die Entwicklung durchaus so weit vereinfacht werden, dass man keine Zeile Code mehr selbst schreiben muss. Der AgentBuilder ist ein Rahmenwerk, das genau dies ermöglicht. Durch ein Zusatzpaket, einen sogenannten Wizzard, welcher spezifisch für eine bestimmte Anwendung ist, kann der AgentBuilder in die Lage versetzt werden, mobiler Agenten für diese Anwendung zusammenzubauen. Dabei muss der Entwickler keine Java- oder AMETAS-Kenntnisse besitzen. Er triff lediglich High-Level-Entscheidungen über das Design des Agenten und läßt dann den Code erzeugen. Dieser Code kann manuell nachbearbeitet werden und später erneut in den AgentBuilder geladen und verändert werden.

Das Hybridtypsystem erlaubt die Verwendung einer mächtigen Typbeschreibung für Stellennutzer, den so genannten Hybridtypen. Diese erlauben es, einen Stellennutzer präzise zu beschreiben; es werden Eingangs- sowie Ausgangsnachrichten ähnlich einer Schnittstellenbeschreibung aufgelistet, das Nachrichtenaustauschprotokoll mittels eines endlichen Automaten beschrieben sowie semantische Annotationen zu Nachrichten, Zuständen oder dem gesamten Stellennutzer geliefert. Eine Suche nach einem bestimmten Stellennutzer gestaltet sich jetzt nicht mehr derart, dass man seinen Namen kennen muss - man muss stattdessen wissen, was er tut und dies in einer Anfrage formalisieren. Man könnte also einen Dienst suchen, „der das Sicherheitssystem konfiguriert“ und muss nicht wissen, wie der Klassenname heißt. Oder man kann testen, ob der angebotene Agent in der Lage ist, dieselben Nachrichten zu verstehen, die eine gegebene andere Version von ihm beherrschte, also ob der neue Agent ein Subtyp des erwarteten Agenten ist. Dazu gehört insbesondere, dass er sich in Bezug auf die Abfolge der Kommunikation so wie erwartet verhält.