Kapitel 5Middleware für Systeme mobiler Agentenin der Automatisierung

Hagen Stanek

Zusammenfassung Das Ziel dieses Artikels ist es, eine Middleware zu finden, diees ermöglicht, darauf basierend Systeme mobiler Agenten, d. h. solche, die ihrenZustand und Kode zu einem anderen Computer transferieren können, in der Auto-matisierung zukunftsträchtig zu entwickeln und zu betreiben. Keinesfalls geschiehtdas unter der Annahme, schon „die“ Lösung zu finden. Stattdessen möchte dieserArtikel einen Anstoß zu reger Diskussion und zu realen Entwicklungen bzw. Wei-terentwicklung existierender Middleware bzw. Plattformen für Agenten-Systememit der Middleware als Basis geben.

5.1 Einleitung

Derzeit gibt es eine Reihe von Frameworks, die sich als Middleware anbieten.Dieser Artikel analysiert die vielversprechendsten Ansätze systematisch. Vor- undNachteile einer Technik werden unter Berücksichtigung der Anforderungen der Au-tomatisierungstechnik beleuchtet. Dabei werden auch weichere Gründe für eineTechnik diskutiert. Hierzu zählt etwa die tatsächliche Entwicklungsgeschwindig-keit, mit der die Möglichkeiten einer Middleware oder deren bisherige Verbrei-tung in kommerziellen Anwendungen erweitert werden können. Diese Aspekte dür-fen nicht unbeachtet bleiben und müssen gewichtet werden, will man nachhaltigeSoftware-Entwicklung bei niedrigem Kostenaufwand betreiben.

Mit Middleware ist in diesem Artikel eine Software gemeint und keine Hardwa-re. Gerade jetzt entwickeln sich im Umfeld des Cloud-Computing und im Bereichder Telefonie interessante Lösungen. Die Erwartung ist, dass eine solche Softwareaufgrund einer weiten Verbreitung eine höhere Stabilität, bessere Dokumentationund stärkere Werkzeugunterstützung aufweist. Das wird einer Plattform für Sys-

Hagen Stanek (B)genRob GmbH, Würmhalde 31, 71134 Aidlingen, Deutschlande-mail: stanek@genRob.com

79P. Göhner (Hrsg.), Agentensysteme in der Automatisierungstechnik, Xpert.press,DOI 10.1007/978-3-642-31768-2_5,© Springer-Verlag Berlin Heidelberg 2013

80 H. Stanek

Abb. 5.1 Einordnung von Middleware, Plattform für Agenten und System mit Agenten beispiel-haft für 2 Rechner

teme von Agenten, die darauf basiert, eine größere Stabilität verleihen und sieeinfacher warten und weiterentwickeln lassen (vgl. Abb. 5.1).

Abschnitt 5.2 erläutert, wie eine Middleware systematisch auf ihre Tauglichkeitgeprüft wird. Zunächst wird der Begriff Middleware geklärt. Dann ziehen wir dieDefinition von mobilen Agenten heran. Aus dieser leiten wir grundlegende Anfor-derungen ab, die durch eine Middleware erfüllt sein müssen. Natürlich reicht dieDefinition mobiler Agenten alleine nicht aus. Die Automatisierungsindustrie ist einetablierter wirtschaftlicher Zweig mit vielen Standards, Normen und Vorschriften,die helfen, einen sicheren und stabilen Betrieb von Anwendungen zu gewährleisten.Zusammen mit den Einsatzbedingungen der Automatisierung, ergeben sich weitereAnforderungen an eine Middleware.

Um in einer kompakten Form eine Beurteilung bestehender Middleware-Ansätzevorzunehmen, werden in Abschn. 5.3 die wichtigsten Anforderungen zusammen-geführt. Daraus ergibt sich ein Schema, nach dem im folgenden Abschn. 5.3.2 dieeinzelnen Techniken untersucht und beurteilt werden. Die Schlussfolgerungen ausdiesen Einzelanalysen zeigen, welche Techniken derzeit die vielversprechendstenAnsätze für Systeme mobiler Agenten sind. Offene Fragen, Probleme und Her-ausforderungen bleiben, auf deren Lösung am Ende dieses Textes im Abschn. 5.4gedeutet wird.

5 Middleware für Systeme mobiler Agenten in der Automatisierung 81

5.2 Grundlegende Anforderungen an eine Middleware

5.2.1 Middleware und verteilte Anwendungen

Im allgemeinsten Sinne ist Middleware (dt. Diensteschicht, Vermittlungs-Software)eine Computer-Software, welche anwendungsneutrale Dienste für Software-An-wendungen anbietet, die über die vom Betriebssystem Angebotenen hinausge-hen [1, 2]. Dies kann in Form von Software-Bibliotheken geschehen und auchüber diensteanbietende Anwendungen (Server). Die Middleware nutzt ihrerseitsdie Dienste des Betriebssystems oder anderer Middleware und verbirgt damit Kom-plexität. Ist die Middleware für verschiedene Betriebssysteme verfügbar, so werdenzusätzlich Unterschiede zwischen den Betriebssystemen und der unterliegendenHardware ausgeglichen [2].

Eine Middleware hat allgemein ein breiteres Einsatzgebiet, weshalb eine größerePraxiserprobtheit, geringere Fehlerquellen und bessere Werkzeuge für die Entwick-lung und den Einsatz vorliegen.

In Bezug auf Middleware kann ein Software-System mit mobilen Agenten alsverteilte Anwendung aufgefasst werden. Eine verteilte Anwendung ist eine Softwa-re, die in einem verteilten System, also auf mehreren Rechnern/Prozessoren, abläuftund unter diesen Informationen austauscht. Zur Erfüllung der Gesamtaufgabe müs-sen alle Anwendungsteile der verteilten Anwendung mitwirken und untereinanderkommunizieren [3]. In verteilten Anwendungen bedeutet Middleware meist eineSoftware, welche Kommunikation und Datenverwaltung vermittelt [1].

5.2.2 Definition mobiler Agenten

Generell wird ein Agent als mobil angesehen, wenn er mit seinem Programmkodeund Laufzeitdaten selbsttätig zu einem anderen Computer wechseln kann, um dortseine Ausführung fortzusetzen [4].

Ein mobiler Agent ist eine Form von Software-Agent und ist daher darüber hin-aus autonom (unabhängig von Benutzereingriffen), proaktiv (Aktionen aufgrundeigener Initiative), reaktiv (reagiert auf Änderungen der Umgebung), robust (kom-pensiert äußere und innere Störungen), adaptiv (ändert aufgrund der eigenen Zu-stände und der Zustände der Umgebung seine eigenen Einstellungen), kognitiv(lernfähig und lernt aufgrund zuvor getätigter Entscheidungen bzw. Beobachtun-gen) und sozial (kommuniziert mit anderen Agenten) [5].

Mehr softwaretechnisch gesehen ist ein mobiler Agent eine Art Prozess, welcherseinen Zustand von einer Umgebung in eine andere unter Erhalt seines Zustandestransferieren kann. Dabei kann der Agent selbst entscheiden wohin und wann trans-feriert wird. Transferiert wird durch Zustandsfeststellung in Form transferierbarerDaten, Transportieren dieser Daten in die neue Umgebung, Zustandswiederherstel-

82 H. Stanek

lung aus diesen Daten und Fortführung des Agenten mit dem wiederhergestelltenZustand in der neuen Umgebung [4].

Nimmt man die Idee mobiler Programme hinzu, so transferiert ein mobiler Agentzusätzlich zu seinem Zustand auch noch seinen Kode zur neuen Umgebung. In die-sem Falle muss die neue Umgebung den Kode des mobilen Agenten a priori nichtkennen, aber verstehen und ausführen.

Autonomie, Proaktivität, Reaktivität, Robustheit, Adaptivität, Kognitivität undSozialität wird im Wesentlichen möglich, wenn eine freie Programmierbarkeit z. B.in Form einer höheren Programmiersprache vorliegt. Zusätzlich muss ein passen-der Ablaufmechanismus für die resultierenden Programme gegeben sein, sodass dieProgramme geladen, gestartet, beendet oder angehalten und schließlich entladenwerden können.

Reaktivität erfordert zusätzlich einen Zugriff auf die Umgebung und damitnormalerweise auf die passenden Ressourcen in Form von Hard- oder Software-Diensten. Sobald solche Ressource-Zugriffe durch mehrere Agenten parallelerfolgen könnten, müssen sie dann auch synchronisiert sein. Aus der Sozialitätleitet sich weiterhin ab, dass besondere Dienste zur Verfügung stehen müssen, dieden Agenten sozialen Kontakt ermöglichen. Das sind normalerweise Kommunika-tionsdienste lokal und für das Netz. Damit ein Agent sich selbst transferieren kann,muss sein Zustand und sein Kode transferiert werden können. Dazu sind ebensospezielle Kommunikationsdienste erforderlich. Diese sind dann mit den o. g. Ab-laufmechanismen gekoppelt. Und letztlich ergibt sich noch aus der Tatsache, dassdie Ressourcen wie erwähnt parallel genutzt werden können und Agenten über dieAblaufmechanismen unerwartet enden können, dass eine sehr zuverlässige Lauf-zeitumgebung existieren muss, welche die Ablaufmechanismen bereitstellt und dieRessourcen verwaltet.

5.2.3 Bedingungen der Automatisierung

Als hauptsächliche Gründe für die Automatisierung werden die Verbesserung undVergleichsmäßigung der Produktqualität, die Erhöhung der Durchsatzleistung, derErsatz von Baugruppen, für die keine Ersatzteile mehr verfügbar sind, die Einspa-rung von Personalkosten und die Entlastung des Menschen von schwerer körperli-cher oder monotoner Arbeit genannt [6].

Die Automatisierungstechnik, die zum Ziel hat, Maschinen oder Anlagen au-tomatisiert, also selbstständig und ohne Mitwirkung von Menschen, zu betreiben,befasst sich dabei mit Methoden und Lösungen, wie Messen, Steuern, Regeln, Kom-munikation, Bedienen, Sicherheit und Implementierung. Die Grenze für den Einsatzder Automatisierung ergibt sich heutzutage meistens aus der Wirtschaftlichkeit [7].

In der Praxis haben in der Automatisierungstechnik eine große Zahl von An-bietern und lange Zeiträume zu einer stark heterogenen Welt geführt. Diese Ent-wicklung wird sich fortsetzen. Aus Sicht der Informationsverarbeitung betrifft dieseHeterogenität der Zukunft deshalb sämtliche Bereiche, wie Peripherie, Rechentech-

5 Middleware für Systeme mobiler Agenten in der Automatisierung 83

nik, Betriebssystem u. a. m. und auch besonders dann, wenn komplette Prozessevon Web über Leitsystem hin zu Automatisierungsgerät einheitlich abbildbar seinsollen. Eine Middleware für Systeme mobiler Agenten muss eine Brücke über dieHeterogenität spannen. Nur dann kann damit ein System frei transferierender mobi-ler Agenten geschaffen werden. Letztlich führt diese Anforderung zu den virtuellenMaschinen.

5.2.4 Virtuelle Maschinen

Um den Kode eines mobilen Agenten in einer heterogenen Welt nutzbar machenzu können, muss virtualisiert werden. Auf irgendeiner Ebene muss derart abstra-hiert werden, sodass ein solcher Agent laufen kann. Zum einen muss der Kodegrundsätzlich interpretiert werden können und zum anderen der Zugriff auf die Pe-ripherie einheitlich möglich sein. Generell werden solche Konstruktionen virtuelleMaschinen genannt.

Eine virtuelle Maschine (VM) ist eine Software-Implementierung einer Maschi-ne, welche Kode wie eine physische Maschine ausführt. Als ein wesentliches Merk-mal solcher Maschinen wird der ausgeführte Kode auf die Ressourcen begrenzt, diedie virtuelle Maschine bereitstellt [8].

Virtuelle Maschinen lassen sich abhängig von ihrem Einsatz und Grad der Über-einstimmung mit existierenden physischen Maschinen in System-virtuelle Maschi-nen und Prozess-virtuelle Maschinen einteilen. System-virtuelle Maschinen bieteneine zum Teil perfekte Übereinstimmung mit physischen Maschinen und werdeneingesetzt, um vollständige Betriebssysteme zu virtualisieren. Prozess-virtuelle Ma-schinen laufen demgegenüber als ein einzelner Prozess in einem Betriebssystemund bieten den Programmen eine von physischen Maschinen unabhängige Maschi-nendefinition [8].

In der Praxis laufen System-virtuelle Maschinen nur jeweils auf gewissen Artenphysischer Maschinen und Betriebssystemen, bieten ihrerseits dann aber wiederdie Virtualisierung weiterer physischer Maschinen. Die lange Zeiträume in der Au-tomatisierung und die nötigen Mindestanforderungen sprechen gegen den EinsatzSystem-virtueller Maschinen. Lange Zeiträume können zum Problem werden, wenngewisse Arten physischer Maschinen einmal nicht mehr oder nur noch in geringenStückzahlen gebaut werden und dann dadurch Ersatzteileinschränkungen auftreten.Die Größe solcher virtuellen Maschinen bedingt normalerweise auch eine gewissegrößere Mindestgröße für das physische System mit entsprechendem Stromver-brauch, Wärmeentwicklung etc. Schließlich wächst mit der Größe statistisch auchdie Fehlerzahl.

Die Prozess-virtuellen Maschinen sind der Idee nach demgegenüber nicht aufphysische Maschinen und darauf laufende Betriebssysteme eingeschränkt. Dass derzu interpretierende Kode in der Regel nicht direkt von der physischen Maschineverarbeitet werden kann und deshalb interpretiert werden muss, gleichen spezielleTechniken aus.

84 H. Stanek

Die vermutlich mit Abstand verbreitetsten Prozess-virtuellen Maschinen sind dieJava-Virtual-Machine und die Virtual-Machine der Common-Language-Runtimeals Teil des.NET-Framework. Die Verbreitung des.NET-Frameworks beschränktsich Stand heute im Wesentlichen auf Windows-Systeme mit einer relativen hohenGrundleistung. Da in der Automatisierung aber möglichst viele Betriebssystemeund Hardware-Leistungsstufen für die mobilen Agentensysteme potenziell zumEinsatz kommen sollen, wird im Folgenden nur die Java-Virtual-Machine (JVM)betrachtet werden. Für die gesuchte Middleware bedeutet es daher zwingend, dasssie auf Java als Technologie-Plattform aufsetzen muss.

5.2.5 Zusammenfassung der grundlegenden Anforderungenan eine Middleware

Zusammenfassend kann man daher folgende grundlegende Anforderungen ablei-ten, die eine Middleware erfüllen muss, damit ein System mobiler Agenten möglichwird: Es muss eine zuverlässige Laufzeitumgebung für die mobilen Agenten basie-rend auf der Java-Virtual-Machine existieren, die den Zugriff für jeden mobilenAgenten auf Hard- und Software-Dienste, insbesondere Kommunikationsdiensteund Transferdienste inklusive Ablaufmechanismen bereitstellt.

5.3 Middleware

In den vergangenen Jahren sind eine Reihe von Frameworks entstanden, die aufden ersten Blick als Middleware für mobile Agenten geeignet erscheinen. DieserAbschnitt beschreibt im Folgenden, um welche Frameworks es sich handelt undwas sie zu bieten haben.

5.3.1 Existierende Middleware

Die im nachfolgenden vorgestellte Middleware wurde bei der Suche im Internet mitBegriffen wie „distributed“, „computing“, „java“, „parallel“, „concurrent“, „frame-work“, „middleware“, „operating system“, „grid“ und den entsprechenden deut-schen Begriffen gefunden. Die Suche fand im Mai 2012 statt. Es wurden nur diespontan glaubwürdigsten Kandidaten ausgewählt, da es sehr viele kleinere Midd-leware gibt, die z. B. einfach im Rahmen von Arbeiten von Studenten entstandenund keine repräsentativen Anwendungen zu erkennen sind. Weiterhin wurde dieMiddleware weggelassen, für die gar kein kommerzieller Einsatz erlaubt ist.

Tabelle 5.1 zeigt das Ergebnis der Suche in alphabetischer Reihenfolge.

5 Middleware für Systeme mobiler Agenten in der Automatisierung 85

Tab. 5.1 Die existierende Middleware

Middleware Update URL

Akka 22.5.2012 http://akka.io

Blitz JavaSpaces 7.5.2012 http://www.dancres.org/blitz

Cajo 21.2.2011 http://java.net/projects/cajo

Cleversave Produkt http://www.cleversafe.com

Clutch 2008 http://clutch.sourceforge.net

Cougaar 21.8.2007 http://www.cougaar.org

DAC 2009 http://www.dacframe.org

Globus Toolkit 26.4.2012 http://www.globus.org

GridEngine Oracle-Produkt

http://www.oracle.com/us/products/tools/oracle-grid-engine-075549.html

Gridgain 14.5.2012 http://www.gridgain.com

Hadoop 16.5.2012 http://hadoop.apache.org

Hazelcast 2.5.2012 http://www.hazelcast.com

Ibis 9.12.2009 http://www.cs.vu.nl/ibis

JADIF 6.2010 http://jadif.sourceforge.net

Java CoG Kit 2006 http://wiki.cogkit.org

JavaParty 30.3.2007 http://svn.ipd.uni-karlsruhe.de/trac/javaparty

JCAF 18.5.2011 http://www.daimi.au.dk/~bardram/jcaf

JPPF 1.4.2012 http://www.jppf.org

Korus 2.2010 http://code.google.com/p/korus

P-GRADE portal 3.5.2011 http://portal.p-grade.hu

Pegasus 3.2012 http://pegasus.isi.edu

ProActive 12.4.2007 http://proactive.inria.fr

Red dwarf server 27.10.2010 http://www.reddwarfserver.org

Roblet 1.3.2012 http://roblet.org

nebulaframework 1.9.2008 http://code.google.com/p/nebulaframework

UNICORE 13.4.2012 http://www.unicore.eu

5.3.2 Reduzierung der Middleware-Liste

Eine Middleware sollte sich in der Weiterentwicklung befinden. Dies kennzeich-net eine aktuelle Nutzung. Zu diesem Zweck wurde die Liste der existierendenMiddleware auf die eingeschränkt, die innerhalb der letzten 12 Monate einen neu-en Software-Stand veröffentlicht haben: Akka, Blitz JavaSpaces, Cleversave, Glo-bus Toolkit, GridEngine, Gridgain, Hadoop, Hazelcast, JPPF, Pegasus, Roblet undUNICORE.

86 H. Stanek

Bewertungskriterien

Für eine sinnvolle und vergleichbare Bewertung werden acht Kriterien vorgeschla-gen, anhand derer eine Middleware für die Umsetzung eines Systems mobiler Agen-ten für die Automatisierung beurteilbar wird.

Zusätzlich wird noch das vom Hersteller publizierte Anwendungsziel seinerMiddleware angegeben. Erfahrungsgemäß können zu breite Zielsetzungen der Be-nutzbarkeit schaden; zu enge Zielsetzungen können Anwendungsfälle ausschließenoder für deren Umsetzung unsaubere Nutzungen eines Frameworks erfordern.

Java

Wie zuvor diskutiert, ist die Nutzung von Java und einer JVM als virtuelle Ma-schine in der Automatisierung der vielversprechendste Ansatz, um verteilte hete-rogene Systeme wirtschaftlich zu verbinden. Wie unterstützt die Middleware denEinsatz von Java? Residiert die diskutierte Middleware direkt in der JVM als Java-Programm oder kommt ein Java-Container zum Einsatz, in dem die Middlewarezum Laufen gebracht wird?

Kommunikationsdienst

Kommunikation ist ein wichtiger Bestandteil eines Agentensystems. Wie weiteroben beschrieben, ist er nötig, damit die einzelnen Agenten miteinander kommu-nizieren können. Gängig ist hier das Austauschen von Nachrichten in Form vonserialisierbaren Objekten. Die dazu nötigen Mechanismen sind oftmals nicht trivial,da sich in allgemeineren Fällen keine direkte Verbindung zwischen den Komponen-ten, auf denen die kommunizierenden Agenten residieren, herstellen lässt. Vielmehrmuss dann ein effizienter Routing-Mechanismus einspringen, der auch mit Fehlersi-tuationen im Netz klarkommt. An dieser Stelle sei betont, dass es nicht reicht, wenndie Rechner sich alle in einem IP-Netz befinden bzw. die Routing-Mechanismenvon IP eine Verbindung herstellen können. Es muss ein Routing auf Agenten-Ebenestattfinden.

Transferdienst

Mobile Agenten müssen sich transferieren können. Dabei sind meist nicht nur Da-ten, sondern auch Kode zu verschieben. Unterstützt die Middleware direkt einenTransfer und in welcher Form?

5 Middleware für Systeme mobiler Agenten in der Automatisierung 87

Umgebungszugang

In der Automatisierungstechnik sollen mobile Agenten auf die Automatisierungs-anlagen zugreifen können. Dabei sollen Zustandsinformationen über eine Anlageerfassbar sein und Aktorik angesprochen werden können. Wie wird ein solcher Zu-griff auf dedizierte Hardware durch die Middleware unterstützt? Sichert die Midd-leware die Hardware-Schnittstellen bei parallel laufenden Agenten, in dem sie z. B.den Zugriff synchronisiert bzw. Mechanismen dafür bereitstellt?

Laufzeitumgebung

Laufzeitumgebung beschreibt den Teil einer Middleware, der den Zugriff für jedenmobilen Agenten auf Hard- und Software-Dienste, insbesondere Kommunikations-dienste und Transferdienste regelt und Ablaufmechanismen bereitstellt. Im Falleunkooperativen Verhaltens eines mobilen Agenten muss über die Ablaufmechanis-men dieser abgebrochen oder alternativ die Laufzeitumgebung neu gestartet werdenkönnen.

Kode-Größe

Die Kode-Größe beeinflusst das Zeitverhalten einer verteilten Anwendung sowohlbeim (Neu-)Start der verteilten Komponenten, als auch beim Verteilen der Agenten.Je größer der Kode, umso mehr muss möglicherweise beim Start einer Anwendungverteilt werden. Das muss dann bei möglicherweise begrenzter oder unzuverlässi-ger Bandbreite mit berücksichtigt werden. Dieser Einfluss erstreckt sich von derEntwicklungsphase bis zum Produktiv-Einsatz und weiter hin zur Fehlersuche inproduktiven Systemen.

Dokumentationsgrad

Um ein System mobiler Agenten auf Basis einer Middleware zu erstellen, ist einegute Dokumentierung von großer Bedeutung. Neben einer Einführung und Schnitt-stellenbeschreibung sind Beispiele und Tutorials – auch in Form von Videos – in derPraxis sehr hilfreich. Weiterhin sind auch die Webseiten der verschiedenen Midd-leware verschieden übersichtlich aufgebaut. Insgesamt sollte der Aufwand, den dieEinarbeitung in die Middleware bedingt, so gering wie möglich bleiben.

Werkzeuge

Neben den notwendigen Programmierschnittstellen einer Middleware sind Werk-zeuge für Betrieb und Entwicklung hilfreich. Werkzeuge reichen von einzelnen

88 H. Stanek

Dateien zur Einbindung in Entwicklungsumgebungen bis zu Programmen, die ver-teilte Komponenten überwachen.

Bewertung

Anhand der zuvor aufgestellten Kriterien lassen sich nun die aktuellen Entwick-lungsstände der unterschiedlichen Middleware beurteilen. Es sind nur die Kriterienkommentiert, zu denen sich klare Aussagen aufgrund der verfügbaren Dokumenta-tion machen lassen.

Weitere Kriterien, wie Größe zur Laufzeit, Boot-Up-Zeit in verschiedenen Um-gebungen, Netzwerktoleranz, Medienbrüche, Sicherheit und Stabilität, bedürfen ei-ner tieferen Untersuchung und waren nicht im Rahmen dieses Artikels möglich.

Akka

Ziel: Entwicklung und Betrieb verteilter Anwendungen mithilfe eines Aktor-Konzepts vereinfachen

1. Java: als Teil eines AppServers oder hauseigener AppServer2. Kommunikationsdienst: Inter-Aktor-Kommunikation über Nachrichten3. Transferdienst: vermutlich keine eingebaute automatische Kode-Verteilung4. Umgebungszugang: vermutlich direkt, unsynchronisiert per Java5. Laufzeitumgebung: höchstwahrscheinlich JVM6. Kode-Größe: 20 MByte – umfasst Scala-Teile7. Dokumentationsgrad: gut und übersichtlich – mindestens zur Einführung – stets

Scala- und Java-Beispiele8. Werkzeuge: Integrationshilfe für verschiedene Entwicklungsumgebungen

Schlussfolgerung: Ist wegen Aktor-Konzept ein guter Kandidat, aber leider sehrgroß.

Blitz JavaSpaces

Ziel: Implementierung von „Tupelräumen“, d. h. eines verteilten assoziativen Spei-chers.

1. Java: Reines Java

Schlussfolgerung: Die Grundzüge der Idee sind sehr weit weg von möglichenAgenten-Konzepten.

5 Middleware für Systeme mobiler Agenten in der Automatisierung 89

Cleversave

Ziel: Aufteilung von Daten in unkenntliche Datenstücke und Verteilung derselbenüber sichere Verbindungen in ein verteiltes Speichernetz.

1. Java: Vermutlich reines Java

Schlussfolgerung: Die Grundzüge der Idee sind sehr weit weg von möglichenAgenten-Konzepten.

Globus Toolkit

Ziel: Web-Service-basiertes System zur Bereitstellung von Grid-Infrastruktur.

1. Java: Java nur in zweiter Ebene, d. h. Java nur als Teilkonzept.

Schlussfolgerung: Die Grundzüge der Idee sind sehr weit weg von möglichenAgenten-Konzepten.

GridEngine

Ziel: System zur Verwaltung verteilter Ressourcen zur Erreichung höchstmöglicherRechenauslastung

Vormals SGE (Sun Grid Engine)

1. Java: Vermutlich reines Java

Schlussfolgerung: Die Grundzüge der Idee sind sehr weit weg von möglichenAgenten-Konzepten.

Gridgain

Ziel: Verarbeitung großer Datenmengen in Echtzeit im Speicher und inkl. HPC

1. Java: Java + Groovy + Scala + AOP + REST + JUnit + u. a.m. – C#-Client2. Kommunikationsdienst: Messaging3. Transferdienst: eingebaute automatische Kode-Verteilung4. Umgebungszugang: vermutlich direkt, unsynchronisiert per Java5. Laufzeitumgebung: JVM6. Kode-Größe: 85 MByte – umfasst Scala- und Groovy-Teile u. v. a. m.7. Dokumentationsgrad: gut und übersichtlich – mindestens zur Einführung – stets

Scala/Groovy- und Java-Beispiele8. Werkzeuge: Erhältlich über die „Professional“-Version

Schlussfolgerung: Sehr vielseitige Technik, die als allgemeine Grundlage dienenkönnte, aber leider sehr groß.

90 H. Stanek

Hadoop

Ziel: Zuverlässiges verteiltes Arbeiten auf Daten – dateibasierte Datenverarbeitung

1. Java: Gewisse Kernteile sind für Linux; Rest der Implementierung ist Java; Da-tenarbeit beliebige Anwendungen

Schlussfolgerung: Die Grundzüge der Idee sind sehr weit weg von möglichenAgenten-Konzepten.

Hazelcast

Ziel: In-Memory-Data-Grid

1. Java: rein2. Kommunikationsdienst: Möglicherweise über Daten-Verteilungsmechanismus

realisierbar3. Transferdienst: vermutlich keine eingebaute automatische Kode-Verteilung4. Umgebungszugang: höchstwahrscheinlich direkt, unsynchronisiert per Java, da

nicht thematisiert5. Laufzeitumgebung: höchstwahrscheinlich JVM6. Kode-Größe: 2 MByte7. Dokumentationsgrad: gut und übersichtlich – mindestens zur Einführung8. Werkzeuge: Programm zur Anzeige von Daten

Schlussfolgerung: Mit einer anderen Zielstellung entwickelt, aber möglicherwei-se passend weiterentwickelbar.

JCAF

Ziel: Entwicklung kontextsensitiver Anwendungen

1. Java: Reines Java2. Kommunikationsdienst: Reines RMI lt. Dokumentation, REST u. a. lt. beilie-

gender Bibliotheken3. Transferdienst: nach eigenen Angaben unsichere Kode-Verteilung per RMI bzw.

da Android auch unter den Bibliotheken ist, wohl aktuell gar nicht mehr4. Umgebungszugang: vermutlich direkt, unsynchronisiert per Java5. Laufzeitumgebung: höchstwahrscheinlich JVM6. Kode-Größe: 2,3 MByte7. Dokumentationsgrad: grundlegende Einführung8. Werkzeuge: keine vorhanden

Schlussfolgerung: Mit einer anderen Zielstellung entwickelt, aber möglicherwei-se passend weiterentwickelbar.

5 Middleware für Systeme mobiler Agenten in der Automatisierung 91

JPPF

Ziel: Ausgerichtet auf verteiltes Rechnen im Grid

1. Java: Reines Java2. Kommunikationsdienst: Nicht vorgesehen – ausgerichtet auf verteiltes Rechnen3. Transferdienst: eingebaute automatische Kode-Verteilung4. Umgebungszugang: vermutlich direkt, unsynchronisiert per Java5. Laufzeitumgebung: höchstwahrscheinlich JVM6. Kode-Größe: 1,5 MByte bei Optimierung über das Dateisystem – ein vielfaches,

wenn nicht optimiert7. Dokumentationsgrad: gut und übersichtlich – mindestens zur Einführung8. Werkzeuge: Graphisches Monitoring-Werkzeug

Schlussfolgerung: Mit einer anderen Zielstellung entwickelt, aber möglicherwei-se passend weiterentwickelbar.

Pegasus

Ziel: Konfigurierbares System zur Verteilung und Ausführung abstrakter Workflowsin einer großen Anzahl Ausführungsumgebungen einschließlich Laptops, Rechen-zentren, Grids und Clouds

1. Java: Teilweise Java mit vielen System-spezifischen Anteilen

Schlussfolgerung: Die Grundzüge der Idee sind sehr weit weg von möglichenAgenten-Konzepten.

Roblet

Ziel: Verteilte heterogene Systeme insbesondere der autonomen mobilen Robotik

1. Java: Reines Java2. Kommunikationsdienst: Über eine technikeigene-Kommunikation implemen-

tierbar3. Transferdienst: eingebaute automatische Kode-Verteilung4. Umgebungszugang: synchronisiert implementierbar5. Laufzeitumgebung: Sub-JVM – über „protection domains“ und „Einheiten“ von

der Basis-JVM und untereinander abgeschirmte Roblets6. Kode-Größe: 0,5 MByte7. Dokumentationsgrad: mindestens zur Einführung8. Werkzeuge: Grundlegende Kommandozeilenprogramme

Schlussfolgerung: Dem Konzept nach auf die verteilte Ausführung von Kode mitDatenübertragung ausgelegt, was gut als Basis für Agenten-Systeme dienen könnte.

92 H. Stanek

Tab. 5.2 Zusammenfassung der Vergleich der Middleware

Akka Gridgain Hazelcast JCAF JPPF Roblet

1) Java (–) (–) (+) (+) (+) (+)

2) Kommunikationsdienst (++) (+) (–) (o) (–) (o)

3) Transferdienst (–) (++) (–) (–) (+) (++)

4) Umgebungszugang (o) (o) (o) (o) (o) (+)

5) Laufzeitumgebung (o) (o) (o) (o) (o) (++)

6) Kode-Größe (–) (–) (+) (+) (+) (++)

7) Dokumentationsgrad (++) (++) (+) (o) (+) (+)

8) Werkzeuge (+) (+) (+) (–) (+) (o)

UNICORE

Ziel: HPC- und Grid-Computing – Ist darauf ausgelegt, dateibasiert Werte an An-wendungen zu geben und nach Abarbeitung wieder zu übernehmen.

1. Java: Reines Java, Eclipse-Java

Schlussfolgerung: Die Grundzüge der Idee sind sehr weit weg von möglichenAgenten-Konzepten.

Zusammenfassung

Die Bewertungen zeigen, dass mehr als die Hälfte der Middleware eher für dasHPC- oder Grid-Computing gedacht sind. Letztendlich wird das sicherlich durchdie momentan starken Fortschritte im Cloud-Computing und den damit auf einfa-chere Weise verfügbaren Ressourcen begünstigt.

Für die Automatisierung bleiben nur noch 6 Middleware übrig, die in Tab. 5.2zusammengefasst sind. Dabei wird eine qualitative Beurteilung in Form von (++),(+), (o), (–) und (–) vorgenommen, die damit von sehr gut bis eher negativ reicht.

Die meisten Produkte benutzen direkt die JVM zur Ausführung. Akka benö-tigt einen (möglicherweise nur einfachen) Anwendungs-Container. Bei Gridgain istAOP im Einsatz, was teilweise Kompilationen zur Laufzeit in einer separaten JVMzur Folge hat.

Akka bietet wegen des Aktor-Konzeptes einen hervorragenden Kommunikati-onsdienst. Bei Gridgain kann ein einfacher Kommunikationsdienst vermutlich so-fort realisiert werden. Bei JCAF und Roblet lässt sich ein solcher Dienst architek-tonisch begünstigt sicher realisieren. Dabei wird der Aufwand etwas größer sein,als bei Gridgain, aber vermutlich ist dann auch die Flexibilität höher. Hazelcast undJPPF scheinen nicht auf Kommunikation ausgelegt.

Kode-Transfer in praktischer Form, nämlich im Grunde transparent auf der Ebe-ne von Java-Objekten, bieten nur Gridgain und Roblet. Die Middleware, die kei-nen Kode-Transfer einsetzt, ist kritisch einzuschätzen. Die Fähigkeit zum Kode-

5 Middleware für Systeme mobiler Agenten in der Automatisierung 93

Transfer bedingt, dass die Middleware intern darauf ausgerichtet ist. Eine Softwarelässt sich mit derartiger Technologie erfahrungsgemäß nur mit hohem Aufwandnachrüsten.

Der Zugang auf die Umgebung des jeweiligen Rechners ist nur bei Roblet mitMechanismen versehen, die eine Synchronisation erzwingen können. Bei allen an-deren Middleware müssen eigene Bibliotheken erstellt werden und die Entwicklermüssen die in der Praxis auch nutzen. Das bedingt eine gewisse Unsicherheit, diemit möglicherweise Prüf-Programmen kompensiert werden müsste.

Bei den Laufzeitumgebungen ist nur bei Roblet ein Mechanismus vorhanden, derdie zukünftigen Agenten sicher von der unterliegenden JVM und anderen Agententrennt. Unkooperative Agenten lassen sich in dieser Laufzeitumgebung beenden,ohne dass die JVM neu gestartet werden muss. Die Agenten können dazu schadlosvon den Ressourcen getrennt werden bzw. diese können passend auf eine Abtren-nung reagieren. Das hat zur Folge, dass andere Agenten in dieser JVM ohne Unter-brechung weiterlaufen können. Würde man die JVM neu starten müssen, so mussdie Startzeit der JVM, der Middleware, der Netzwerkaufbau, das Laden und Startender Agenten u. a. m. in einem solchen Szenarium mit berücksichtigt werden.

Hinsichtlich der Kode-Größe sind Akka und GridGain eher schlecht einzustufen.Alle anderen sind gut bis sehr gut. Kode-Größe macht sicher spätestens in produk-tiven Systemen bemerkbar, wenn zur Suche von Fehlern neue Software-Versionenauf alle Komponenten verteilt werden müssen. Auch der Start der Middleware gehtlangsamer vonstatten.

Die Dokumentation war bei keiner Middleware schlecht. Akka und Gridgainfielen durch viel Aufwand und hohe Qualität auf.

Werkzeugunterstützung ist äußerst unterschiedlich und nur JCAF scheint garnichts zu bieten.

5.4 Zusammenfassung

Theoretisch wäre Akka der Idee mobiler Agenten am nächsten. Viele Problem-stellungen, die entstehen, wenn man verteilte Anwendungen erstellt, die eher nichthomogen sind, werden durch den Aktoren-Ansatz aufgegriffen. Dazu gehört auchder ausgereifte Kommunikationsdienst mit Adressierungsschema u. a. Aber Akkaunterstützt von Haus aus keinen Kode-Transfer und im Grunde zu groß. Den Kode-Transfer bieten nur Gridgain und Roblet praktisch ausgereift. GridGain ist für dieAnwendung in der Automatisierung auch zu groß und hat als Laufzeitumgebungnur die JVM. Für Roblet spricht, dass die Laufzeitumgebung und der Umgebungs-zugang auf den einzelnen Agenten ausgelegt ist. Im Grunde wäre deshalb eineEntwicklung anzustreben, die alle Vorteile von Akka mit denen von Roblet ver-bindet. Das bedeutet, die Erfahrungen mit den Aktoren wären mit der Kompaktheitund Stabilität der Roblet-Technik zu kombinieren.

94 H. Stanek

Literatur

[1] Wikipedia (2012). Middleware. http://en.wikipedia.org/wiki/Middleware. Zugegriffen:31. Mai 2012

[2] Wikipedia (2012). Middleware. http://de.wikipedia.org/wiki/Middleware. Zugegriffen:31. Mai 2012

[3] Wikipedia (2012). Verteilte Anwendung. http://de.wikipedia.org/wiki/Verteilte_Anwendung.Zugegriffen: 31. Mai 2012

[4] Wikipedia (2012). Mobile agent. http://en.wikipedia.org/wiki/Mobile_agent. Zugegriffen:31. Mai 2012

[5] Wikipedia (2012). Software-Agent. http://de.wikipedia.org/wiki/Software-Agent. Zugegriffen:31. Mai 2012

[6] Wikipedia (2012). Automatisierung. http://de.wikipedia.org/wiki/Automatisierung. Zugegrif-fen: 31. Mai 2012

[7] Wikipedia (2012). Automatisierungstechnik.http://de.wikipedia.org/wiki/Automatisierungstechnik. Zugegriffen: 31. Mai 2012

[8] Wikipedia (2012). Virtual machine. http://en.wikipedia.org/wiki/Virtual_machine. Zugegrif-fen: 31. Mai 2012