Verteilte SystemeOliverBRAUNReneBROTHUHNRonnySCHLEICHER(Hrsg.)FakultatInformatikFachhochschuleSchmalkaldenWintersemester2010/2011VorwortDie Entwicklung groerer Softwaresysteme ber uhrt in der heutigen Zeit sehr haugdasGebietderverteiltenSysteme.Dabei istesganzunerheblichobdieSystemetatsachlich auf unterschiedlichen Ressourcen verteilt sind oder nur entsprechendeTechnologiengenutztwerden.EinesehrvielversprechendeAbstraktionbeispiels-weisebietendieActors. DassindSoftwarekomponenten, dieeigenstandigarbei-tenundausschlielich uberasynchroneKommunikationmiteinanderinteragierenkonnen. Aber auchvieleandereAnsatzesindsehr interessant undwert etwasgenauer betrachtet zuwerden. Eingutes theoretisches Fundament ist einwe-sentlicherAspekteinerVielzahl solcherAnsatze.Dar uberhinausentscheidetdieNutzbarkeiteinesbestimmtenFrameworksinderRegel dar uber, obesineinemProjektgenutztwerdensoll.Verteilte Systeme ist einer der Schwerpunkte im Masterstudiengang ,,Media Pro-cessingandInteractiveServicesanderFakultatInformatikderFachhochschuleSchmalkalden. Im ersten Durchlauf des 4-semestrigen Studienganges vom Winter-semester 2009/2010 bis Sommersemester 2011 war die weiterf uhrende VertiefungeinePichtveranstaltungf ur alleStudierendeundwurdeimSeminarstil durch-gef uhrt. Jeder Studierende konnte selbst ein Thema vorschlagen oder aus einer Lis-te wahlen und musste dazu einen 35-min utigen Vortrag halten. Zusatzlich musstejedereineetwazehnDINA5-SeitenumfassendeAusarbeitungerstellen. Umdiezum groten Teil sehr guten Arbeiten einem groeren Personenkreis verf ugbar zumachen,werdensieindiesemBuchveroentlicht.DadieeinzelnenKapitel weit uberdasgesamteFeldderverteiltenSystemever-streutsind, habenwirversuchtsieeinigermaensinnvoll in5Teileaufzuteilen.Den Beginn machen Beispiele f ur die Nutzung von Agenten und Aktoren in Teil I.AnschlieendwirdeinTeil derzugrundeliegendenProzesstheorieunddieunmit-telbareUmsetzunginder Programmierungvorgestellt. Teil III beschaftigt sichmitTechnologienzurInteraktionvonProzessen,wiesieaufvolligverschiedenenPlattformengenutzt werden. EineaktuelleTechnologie, dieWebServices, sindGegenstandvonTeil IV. SchlielichgibtesnocheinenkurzenEinblickinGrid-,Cluster-undMonitoringtechnologieninTeilV.OliverBraunReneBrothuhnRonnySchleicherSchmalkalden,August2011IVInhaltsverzeichnisI AktorenundAgenten 11 AkkaGrundlagen. . . . . . . . . . . . . . . . . . . . . . . . . . 3FlorianSchuhmann2 AkkaHandson. . . . . . . . . . . . . . . . . . . . . . . . . . . 13ToralfMende3 JavaAgentDEvelopmentFramework . . . . . . . . . . . . . . . 25TobiasGartner4 Janus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37ReneKassel5 FIPAStandards. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51MarcoKretzschmarII ProzesstheorieundunmittelbareUmsetzung 616 CommunicatingSequential Processes . . . . . . . . . . . . . . . 63WenqiYan(ReneBrothuhn)7 -Kalk ul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79ReneBrothuhn8 ConcurrencyinGo . . . . . . . . . . . . . . . . . . . . . . . . . . 91BenjaminL udicke9 CommunicatingSequential Processesf urJava . . . . . . . . . . 101MartinEngelVI InhaltsverzeichnisIII Interprozesstechnologien 11110InterprozesskommunikationmitCOM . . . . . . . . . . . . . . . 113RonnySchleicher11HawtDispatch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125TobiasGieler12DistributedProgramminginMozart . . . . . . . . . . . . . . . . 139SebastianStallenberger13ZeroMQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151ChristopherEzell14RemoteFunctionCall inSAP-Systemen . . . . . . . . . . . . . . 165SebastianReidemeisterIV WebServices 17515Web-Services-Architektur . . . . . . . . . . . . . . . . . . . . . . 177SebastianLeisen16ApacheCXF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191MartinHerrmannV Grid,ClusterundMonitoring 20317GlobusToolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205MartinBaumbach18ApacheHadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215ThomasHohn19MonitoringDistributedReal-TimeSystems . . . . . . . . . . . . 227MaikHellerTeil IAktorenundAgenten1 AkkaGrundlagenFlorianSchuhmannInhaltsverzeichnis1.1 AkkaDasFramework. . . . . . . . . . . . . . . . . . . 31.2 FeaturesundMethodiken . . . . . . . . . . . . . . . . . . 41.2.1 Actors . . . . . . . . . . . . . . . . . . . . . . . 41.2.2 SoftwareTransactionalMemory. . . . . . . . . . 91.2.3 Fault-tolerance. . . . . . . . . . . . . . . . . . . 101.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1 AkkaDasFrameworkAkka ist ein Open-Source-Projekt von Jonas Boner. Die Firma Scalable Solutionsbietet Consulting zu Akka und kostenpichtige Erweiterungen wieAkka Cloud,AkkaAdvancedundAkkaMonitoring&Managementan.Akkaistderzeitinder Version1.0RC3verf ugbar undstehtdamitkurzvor derVeroentlichungderVersion1.0. WeiterhinbietetAkkaeineAPI f urScalaundJavasowieeinesehrguteDokumentationmitvielenBeispielen.DasFrameworkkannauf zwei unterschiedlicheWeisengenutztwerden. EinmalalsStand-Alone-Version, wennder Mikrokernel genutzt wird, oder alsErweite-rungsbibliothek,welchebspw.inEclipse-Projekteeingebundenwerdenmuss.AlsLeitbildderEntwickleristfolgendesZitatvonJonasBonerzuverstehen:Writing correct concurrent, fault-tolerant and scalable applications is toohard.Mostofthetimeitsbecauseweareusingthewrongtoolsandthewronglevelofabstraction.Akkaisanattempttochangethat[2].Das Schreiben von nebenlaugen, fehlertoleranten und skalierbaren Program-menistsehr schwer undgenaudiesesProblemwollendieEntwickler mitAkkalosen. Die Idee hinter diesemFramework ist, dass das Abstraktionslevel, wel-chesf urdieProgrammierungbenotigtwird, erhohtwerdensoll umleichterne-benlauge, fehlertolerante und skalierbare Applikationen erstellen zu konnen. DieErhohung der Abstraktion wird durch das Zusammenspiel des Actor-Modells4 1AkkaGrundlagenmit Software Transactional Memory erreicht. Die Entwickler haben sich f urdasLet it Crash-Modell als Strategie f ur die Fehlertoleranz in Akka ent-schieden. Akkaimplementiert alsoeineeinzigartigeMischungvonMethodiken,Abbildung1.1:Akka-Architektur1welche aus Erlang stammt undim folgenden Abschnitt vorgestelltwird.Abbildung1.1zeigtdieArchitek-tur des Frameworks. Es ist in CoreServices,Add-onModuleundEn-terprise Module eingeteilt. Der l.u.dargestellte Core enthalt Techni-kenf ur dieSkalierbarkeit, Fehler-toleranz und Nebenlaugkeit. Die-se werden durch Add-ons (l.o.)bspw. f ur REST, Spring, Mon-goDB oder Cassandra erganzt. DieEnterprise Module (r.o.) zahlen zudenkostenpichtigenErweiterun-genderFirmaScalableSolutions.WiedieDarstellungzeigt, istAk-ka, trotzder kurzenZeitseitderesverf ugbarist,einsehrumfang-reichesFramework.DiesverdanktAkkanichtnurJonasBoner,son-dernauchderbereitssehrgroenEntwicklergemeinde.1.2 FeaturesundMethodikenImerstenAbschnitt wurdedasAkka-FrameworkimAllgemeinenvorgestellt. Indiesem Abschnitt folgen technische Details zu den verwendeten Methodiken. Hier-bei handelt es sich um Grundlagen zu den Themen Actor-Modell, Software Tran-sactionalMemoryundFault-Tolerance.1.2.1 ActorsUm sich dem Thema der nebenlaugen Berechnung mit Actors nahern zu konnen,werdenimFolgendendieProblemedesMultithreadingsangesprochen.1EigeneDarstellunginAnlehnungan[3]1.2FeaturesundMethodiken 5ProblemebeimMultithreadingReproduzierbarkeitvonFehlernFehler, die in einer Menge von Threads auftreten, sind oft schwer nachzuvoll-ziehen, da das entsprechende Programm durch unterschiedliche Systembedin-gungenmoglicherweiseimmerwiederandersausgef uhrtwird.InkonsistenzenSchreibe- undLeseoperationenm ussensynchronisiert werden, sonst konnenWiderspr ucheindenDatenauftreten.DeadlocksWenneine Menge vonProzessenvorhandenist undjeder dieser Prozesseauf einErgebnis wartet, das voneinemanderenProzess aus dieser Mengebereitgestelltwerdensoll,entstehenDeadlocks.StarvationStarvationtrittauf,wennzweiProzesseaufRessourcenzugreifenwollen,diederjeweilsandereProzessf ursichbeansprucht.ZurLosungdieserProblemem ussenzuallererstdiekritischenAbschnitteinderApplikationidentiziertwerden. Bei dieser Sichtungkommtesauf dasrichtigeMaan, dennwennzuvieleAbschnittealskritischgekennzeichnetwerden, be-deutetdies,dassvieleThreadswartenm ussenunddieParallelitatverlorengeht.Nach dieser schwierigen Aufgabe konnen verschiedene Techniken, wie Locks, Con-ditions, Blocking Queues oder Synchronized, eingesetzt werden, um die ProblemebeimMultithreadingmehroderwenigerindenGrizubekommen.Um diesen Problemen aus dem Weg zu gehen, nutzt Akka das Actor-Modell sowiedas Konzept des Software Transactional Memory. Durch diese Verfahren wird dasAbstraktionslevel erhoht undder Entwickler musssichumdieobengenanntenProblemekeineGedankenmehrmachen.DasActor-ModellDas Actor-Modell ist ein mathematisches Modell f ur nebenlauge Berechnungen.EswurdeimJahr1973erstmalsvonCarl HewittimPaperAUniversal Modu-larActorFormalismforArticial Intelligencebeschrieben. DasModell gewanndurchdieSpracheErlanganPopularitat.ErlanggehortzudenfunktionalenPro-grammiersprachenundfolgt imBereichder Nebenlaugkeit denPrinzipiendesActor-Modells.IndiesemModell giltdasGrundprinzip:everythingisanactor.WeiterhinsindActors von Natur aus nebenlaug und ihre Kommunikation ndet asynchron undnur uberNachrichtenstatt.6 1AkkaGrundlagenEinActorkannalsReaktionaufeineempfangeneNachricht(parallel):eineendlicheAnzahlvonNachrichtenanandereActorssenden,eineendlicheAnzahlneuerActorserstellen,f urdienachsteNachrichteinbestimmtesVerhaltenfestlegen.DieIdentizierungderActorserfolgt ubereinesogenannteMailing-Adresse.EinActorkenntnurandereActorsdieerentweder:selbsterzeugtodervondenenerNachrichtenerhaltenhat.WiemanandiesenBeschrankungensieht, spielt indiesemModell dieKapse-lungeinegroeundwichtigeRolle.Esistsomitabzusehen,dassauchZustandenicht geteilt werden. Ein Actor kann den Zustand eines anderen Actors nur uber das VersendenvonNachrichtenbeeinussen. Der Empfanger nimmt dieZustandsanderungaberselbstvor.AkkaActorsDieinAkkaverwendeteImplementierungdesActor-ModellsisteineParallelent-wicklungzudeninScalagenutztenActors. IndenletztenVersionenvonScalawurdendie Ideender AkkaActors teilweise mit indie StandardbibliothekderProgrammierspracheaufgenommen. DasAPI derAkkaActorsistdaherahnlichderScalaActors. BeideImplementierungenorientierensichweiterhinsehrstarkandieSyntaxvonErlangundnutzeneinenexplizitenMessageHandler,welchereinPatternMatchingauf alleempfangenenNachrichtenanwendet. BeimPat-ternMatchingder receive-Methodeder AkkaActorsistdarauf zuachten, dassallemoglichenNachrichten, dieempfangenwerdenkonnten, behandelt werdenm ussen.DieAkkaActorskonnenaufdiezweifolgendenWeisenimplementiertwerden:Der leichtesteund k urzeste Weg, um einenAkka Actorzu implementieren istdie actor Methode. Hierbei wird ein anonymer Actor erzeugt, welcher implizitgestartet wird. Die Implementierung des Message Handlers erfolgt direkt uberdasdargestelltePatternMatching(Listing1.1).import akka.actor._val myActor = actor {case "test" => println("received test")1.2FeaturesundMethodiken 7case _ => println("received unknown message")}Listing1.1:ErstelleneinesanonymenActors[1]EineAlternativeistdieErstellungeinerKlasse, welchevonderActor-Klasseaus Akkaabgeleitet ist unddie receive-Methodeimplementiert. UmdenerstelltenActorzustarten,mussexplizitdiestart-MethodedesActorsauf-gerufenwerden(Listing1.2).class MyActor extends Actor {def receive = {case "test" => println("received test")case _ => println("received unknown message")}}val myActor = Actor.actorOf[MyActor]myActor.startListing1.2:ErstellungeinesActors uberVererbung[1]Der Aufruf der Factory-Methode actorOf liefert eine Instanz von ActorRefzur uck. Dies ist einneues Konzept, welches seit der Version0.9inAkkaent-haltenist.DieErzeugungeinesActors,wieinListing1.3dargestellt,erfolgtnunnichtmehr uberdenAufrufmitnew,sondern uberdiebereitserwahnteFactory-Methode.val a = new MyActora ! msgListing1.3:EinenActormitnewerstellen[1]Diedabei erhalteneInstanzder ActorRefmuss genutzt werden, ummit demeigentlichenActorzuinteragieren(Listing1.4).Durchdieses VorgehenwirdeineActor-Referenz erzeugt, welcheserialisierbar,unveranderlichundnetwork-awareist.Dasheit,dieseReferenzkannohnePro-bleme uber das Netzwerk verteilt werden. Dabei merkt sie sich ihre Herkunft undkannwiegewohntundohnezusatzlichenAufwandgenutztwerden.val a = actorOf[MyActor]a ! msgListing1.4:ActorReferstellen[1]8 1AkkaGrundlagenDie Nachrichten ubermittlung ist die Interaktionsmoglichkeit zwischen den Actors.DiesesammelnihreNachrichtenineinersogenanntenorderedmessagequeueundarbeitendie Nachrichtennacheinander ab. ImFolgendenwerdendie dreimoglichenUbermittlungsartenderAkkaActorsaufgezeigt.re-and-forgetHierbei handelt essichumdieeinfachsteUbermittlungsart. EineNachrichtwirdaneinenActorgesendetundderSenderwartetnichtaufeineAntwort,sondernerarbeitetdirektweiter.myActor !"test"Send-And-Receive-EventuallyBei dieser Art der Nachrichten ubermittlung wird eine Nachricht gesendet undeswirdeinebestimmteZeitaufeineAntwortgewartet. DieseMethodegibteinOption[Any]zur uck,welchesbeimErhalteinerAntwortSome(result)istoderbeimErreichendesTimeoutsNoneenthalt.val resultOption = actor !!("Hello", 1000)Send-And-Receive-FutureDiesesVorgehenlieferteinFuturezur uck,wobei hierbeachtetwerdenmuss,dass kein Timeout angegeben wird. Falls also keine Antwort eintrit, konntenweitere Bearbeitungsschritte, die auf das Future angewiesen sind, nicht durch-gef uhrt.val future = actor !!!"Hello"Der letzte, aber dennochentscheidende Punkt, der hier angesprochenwerdensoll,istdieWahldesDispatchers.Dieserentscheidet uberdieArtdesActors.Sokonnenentwederevent-basierteoderthread-basierteActorserstelltwerden.HiereinekleineAufzahlungdermoglichenDispatcher.Thread-basedEvent-basedWork-stealingHawtDispatch-basedevent-drivenDie Actors sind damit ein Kernbestandteil von Akka und das zurecht, wie folgen-desBeispielderEntwicklerzeigt:Ein event-basierter Actor ist ca 600 Byte gro. Dies bedeutet, dass auf einem PCmit4GBArbeitsspeichercirca6.5MillionenActorserstelltwerdenkonnten.1.2FeaturesundMethodiken 91.2.2 SoftwareTransactional MemoryDas Konzept des Software Transactional Memory ist ein Kontrollmechanismus f urgemeinsamgenutztenSpeicher.DerHauptspeichereinesRechnerswirdzueinerArtDatenbankoderzueinemtransactional dataset[1]. STMimplementiertdieerstendreiBuchstabendesACID-KonzeptesausderDatenbankwelt.AAtomaritat-EineTransaktionwirdganzodergarnichtausgef uhrt.CKonsistenz-EineTransaktionhinterlassteinenkonsistentenDatenbestand.I Isolation-Transaktionenbeeinussensichnichtgegenseitig.DDauerhaftigkeit-Anderungenbleibendauerhafterhalten.DieDauerhaftigkeitmachtimArbeitsspeichernat urlichkeinenSinn.DurchdieIntegrationdiesesKonzeptesindieProgrammierungkonnenTransak-tionen wie in Datenbanken durchgef uhrt werden. Das heit, es gibt die Moglichkeitvonbegin,commit,abort undrollback nunauchimSpeicher. Somitkonnten viele Actors auf dem selben Teil des Speichers lesen und schreiben. Fallsdabei einKonikt zwischenzwei Transaktionenentsteht, werdendieseeinfachabgebrochen und neu ausgef uhrt.Einfach abgebrochenbedeutet in diesem Zu-sammenhang, dass es ein Rollback gibt und der Speicher in den Zustand gebrachtwird,bevordieTransaktionengestartetwurden.DieSTM-ImplementierungvonAkkabasiertaufdenIdeenvonClojure.SiesetztManagedReferencesein, welcheauf einenTeil desSpeichersreferenzierenundeinenunveranderlichenWertenthalten.STMverwaltetdenZugriaufdieseRe-ferenzen.DaherbestehtbeispielsweisedieMoglichkeiteineDatenstrukturineinerlokalenAnwendungmit Actors zunutzen. Einderartiger Zugriist normalerweisenurmit groeremAufwand(bspw. uber Locking)moglichunderonet dabei auchGefahrenquellen.Einweiteres Einsatzgebiet ist das allseits beliebte Bankbeispiel. WennhierbeiActorsgenutztwerden,m usstendieinternenActor-Zustandeangepasstwerden.Dadiesnur uber Nachrichtenmoglichist, m usstenanalleActorsNachrichtenversendet werden. Bei diesem Beispiel m usste dies aber atomar erfolgen und somitentstehteineriesigeTransaktion.STMhatdenVorteil,dasseseinsehroptimistischerAnsatzist.Esblockiertnurdie nicht lesenden und f uhrt alle schreibenden Zugrie, die ohne Konikte ablau-fen,biszumCommitaus.DadurchentstehteinhoherGradanParallelisierung.10 1AkkaGrundlagenTransactorsAkkabietet dieMoglichkeit SoftwareTransactional MemoryunddieActorszukombinieren. Dabei entsteht einTransactor, wassoviel heit wieTransactionalActor. Dies ist der Versuch, die Eigenschaften der Actors mit denen von STM zuverbinden. SomitkonnteeinatomarerNachrichtenuss, wieimvorigenBeispielbeschrieben,erstelltwerden.1.2.3 Fault-toleranceDie Entwickler des Akka-Frameworks haben auch an die Fehlertoleranz vonk unftigen Anwendungen gedacht. Sie nutzen hier dasLet it crash-Modell. Die-ses wirdinder Telekommunikationsindustriemit groemErfolgeingesetzt umAnwendungenzuerstellen,diesichselbstwiederherstellenkonnen.DieEntwick-lerhabeneswiefolgtformuliert:lookaterrorsassomethingnaturalandsomethingthatwillhappenandinsteadoftryingtopreventit;embraceit[1]Es geht darum, bei der Entwicklung von Anwendungen Fehler mit einzubeziehen,siesollensogar bereitwilligangenommenwerden. Dennes wirdsiesooder sogeben.Die daraus resultierende Mentalitat und dasLet it crash-Modell sind in Akka beidemUmgangmitFehlerneingeossen.Exceptions,dieineinemActorgeworfenwerden,sindmeistnichthilfreich.EinegeworfeneExceptionw urdedenThread,indemderActorlauft,nurunnotigaufblahenundeskonnteauchnurimStackTraceherausgefundenwerden,dass uberhauptetwasschiefgelaufenist.EinenbesserenWegbietethierAkkadurchdieMoglichkeitActorszuverlinken.SokonnenSets vonActors erstellt werden. Diese Sets bietenSicherheit uberdie Zustande (dead/alive) der einzelnenActors. Es besteht die MoglichkeitSupervisorHierarchienaufzubauen(sieheAbbildung1.2).Abbildung1.2:AkkaSupervisorHierarchie1.3Fazit 11Der Supervisor hatdieMoglichkeit, dieihmunterstelltenActorszustarten, zustoppenundzubeobachten. Hierbei bietet Akka die zwei folgendenRestart-Strategienan.OneForOneFalls diese Strategie genutzt wird und ein Fehler bei einem Actor auftritt, wirdnur dieser Actor neu gestartet. Durch diesen Neustart wird das System wiederineinenstabilenZustandgebracht.AllForOneBei dieser Strategie wird nicht nur der fehlerhafte Actor neu gestartet, sondernalleActors, diedemSupervisor unterstellt sind. IndiesemFall w urdeaucheinunterstellter Supervisor neugestartet werden. Der AusgangszustandistinAbbildung1.2zusehen, dasbeschriebeneVerhaltenvonAllForOneinAbbildung1.3. DurcheinederartigeSchachtelungkonnenkomplexeNetzevonActorsverwaltetwerden.Abbildung1.3:AllForOneineinerHierarchie(restartall)1.3 FazitDasAkka-FrameworkbietetguteKonzepteundvieleweitereIdeenzurparallelenProgrammierung. DieEntwicklergemeinderundumJonas Boner ist sehr aktivundveroentlicht inkurzenIntervallennicht nur BugxesundkleineUpdates,sondern auch grundlegende Neuentwicklungen und Erweiterungen zum bestehen-denFramework.DurchdiesehrguteDokumentationunddieangebotenenAPIsf urJavaundScalafalltdieEinarbeitungsehrleicht. Abschlieendistzusagen,dassAkkaeinsehrleichtverstandlichesundexiblesFrameworkist, welchesinZukunftsichernochoftimGesprachseinwird.12 1AkkaGrundlagenLiteraturverzeichnis[1] ScalableSolutions,AkkaHomepage.http://www.akka.io,2011.[2] Jonas Boner, IntroducingAkka. http://www.jonasboner.com/2010/01/04/introducing-akka.html,04.01.2010.[3] Jonas Boner, Akka - Scala Summit OSCON 2010. http://www.slideshare.net/jboner/akka-scala-summit-oscon-2010,20.07.2010.[4] Jonas Boner, Akka Google Group. http://groups.google.com/group/akka-user[5] JonasBoner,AkkaGithub.https://github.com/jboner[6] Lothar Piepmeyer, Grundkursfunktionale Programmierung mit Scala. CarlHanserVerlagM unchenWien,2010.[7] Christos K. K. Loverdos andApostolos Syropoulos, Steps inScala: AnIn-troductiontoObject-Functional Programming.CambridgeUniversityPress,2010.[8] Oliver Braun, Scala: ObjektfunktionaleProgrammierung. Hanser Fachbuch-verlag,2010.2 AkkaHandsonToralfMendeInhaltsverzeichnis2.1 Akka-MasterandServant. . . . . . . . . . . . . . . . . 132.2 Nachrichten. . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.1 Master . . . . . . . . . . . . . . . . . . . . . . . 152.3.2 Servant . . . . . . . . . . . . . . . . . . . . . . . 182.4 Main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.1 Ablauf . . . . . . . . . . . . . . . . . . . . . . . 202.1 Akka-MasterandServantImKapitel 1wurdedasFrameworkAkkavorgestellt, inwelchemgrundlegendeFeatureswieActorsundFaulttoleranceerlautertwurden. IndiesemKapitel sollnunanhandeines Beispiels dieProgrammierungmit demJava-API des Akka-Frameworks demonstriert werden. DiebenotigtenAkka-Modulewerdenals Er-weiterungsbibliotheken in das Projekt eingebunden. Dadurch ist es moglich, AkkaActors (im folgenden Actors) in einem Java-Projekt zu nutzen. In diesem Beispielwerdenzwei ArtenvonActorsimplementiert. EinerdieserActors(Master)wirdandere Actors (Servants) kontrollieren, ihnen Nachrichten schicken und sie erneutstarten, wennsieausfallen. DazuwerdenverschiedeneTypenvonNachrichten,welchezwischendenActorsausgetauschtwerden, alseigeneKlassenimplemen-tiert.ZumSchlusswirdnocheineMainKlasseimplementiert,indereinMastererzeugt und gestartet wird. Diesem Master werden Nachrichten gesendet, auf dieerunterschiedlichreagiert.2.2 NachrichtenZuerst solltendieTypenvonNachrichten, welchezwischendenActors ausge-tauscht werden, deniert werden. Beim Festlegen der Nachrichten bestehen meh-rereMoglichkeiten. EineMoglichkeitistes, eineeinzigeNachrichtzudenieren14 2AkkaHandsonund in dieser Attribute zu verwenden, damit der Actor, der diese Nachricht spaterempfangt, entscheiden kann, ob und wie er auf diese Nachricht reagiert. Eine ande-re, weitaus ubersichtlichere Moglichkeit ist, f ur jede Nachricht eine eigeneKlassezudenierenundbeimempfangendenActor denTypder Nachrichtzupr ufen.DieseNachrichtensindeinfacheJava-Klassen, welchedasInterfaceSerializableimplementieren.Diesistnotwendig,umdieNachrichtenauch uberRechnergren-zenhinausaustauschenzukonnen.IndiesemBeispielistf urjedeNachrichteineeigene Klasse deniert. Da diese sich alle sehr ahneln, sollen hier jedoch nur zweiNachrichtengezeigtwerden.public class StartMaster implements Serializable {private String id = null; private String strategy = null;public StartMaster(String id, String strategy) {this.id = id; this.strategy = strategy;}public String getStrategy() {return strategy;}public String getId() {return this.id;}}Listing2.1:NachrichtenobjektzumStarteneinesMastersDieinListing2.1gezeigteNachrichtdientdazu,einemMastermitzuteilen,dassein weiterer Master gestartet werden soll. Diese Nachricht besitzt zwei Attribute,diebereitsbeimErzeugeneinerInstanzdieserNachrichtgesetztwerdenm ussen.ZumeinenmusseineIDangegebenwerden, umdiegestartetenMaster spatervoneinanderunterscheidenzukonnen, zumandereneinString, welcherdieBe-zeichnungderNeustartstrategiebeinhaltet.DieinListing2.2gezeigteNachrichtsignalisiert einem Master, dass er einem ihm untergebenen Servant eine Nachrichtsendensoll. DasAttributIDbeinhaltetdieBezeichnungdeszukontaktierendenServants.public class ScareServant implements Serializable {private String id = null;public ScareServant(String id) {this.id = id;}public String getId() {return this.id;}}Listing2.2:NachrichtenobjektzumErschreckeneinesServantsNeben den zwei hier gezeigten Nachrichtentypen existieren noch weitere Nachrich-ten, beispielsweise um einen untergebenen Actor zu stoppen, einen Absturz einesServantszusimulierenodereineReferenzaufeinenanderenActoranzufordern.2.3Actors 152.3 ActorsWiebereitszuBeginnerwahnt,existierenindiesemBeispiel zwei ArtenvonAc-tors.ImfolgendenAbschnittsoll aufeinigeAspektederenImplementierungein-gegangenwerden.HierbeiwirdzunachstdasErzeugeneinersogenanntenFault-HandlingStrategy sowie dieUbergabe dieser andenFaultHander des Mastersgezeigt. Anschlieendwirdgezeigt, wieMaster undServants auf verschiedeneNachrichtenandererActorsreagieren.2.3.1 MasterEin Master ist ein Actor, dem andere Actors in einer Hierarchie untergeordnet sind.Ihm konnen sowohl Servants als auch andere Master untergeordnet sein. Fallt einerder Untergeordneten aus, so startet der Master diese entsprechend der gewahltenFaultHandlingStrategyerneut. Damit der Master eine Neustartstrategie umsetzenkann,besitztereinenFaultHandler.(Listing2.3)public class Master extends UntypedActor {private FaultHandlingStrategy fhStrategy = null;public Master(String id,String strategy) {getContext().setId(id);if (strategy.equalsIgnoreCase("AllForOne")) {this.fhStrategy = new AllForOneStrategy(new Class[] { Exception.class },3,5000);}else if (strategy.equalsIgnoreCase("OneForOne")){this.fhStrategy = new OneForOneStrategy(new Class[] { Exception.class },3,5000);}getContext().setFaultHandler(fhStrategy);} ...Listing2.3:FaultHandlerdesMastersDer Master kann je nach Bedarf mit der OneForOne- oder der AllForOne-Strategie(sieheAbschnitt 1.2.3)gestartet werden. DazuwirdimKonstruktor zuerst einneuesObjektderjeweiligenStrategieerzeugt. BeimInstanzierendesStrategie-objektsm ussendreiParameterangegebenwerden.AlsersterParameterwirdeinArrayderzubehandelndenExceptionklassenerwartet.DerzweiteunddrittePa-rameter gibt die maximale Anzahl der Neustartversuche an und den Zeitraum (in16 2AkkaHandsonMillisekunden), uber dendasNeustartenversuchtwerdensoll. DassoerzeugteStrategieobjektwirdabschlieenddemFaultHandlerdesMasters ubergeben.KommunikationDieKommunikationzwischenActorserfolgt, wiebereitsimKapitel 1erlautert,ausschlielich uberNachrichten.UmaufNachrichtenreagierenzukonnen,mussinderKlassedesjeweiligenActorsdieonReceive-Methoderedeniertwerden.IndieserMethodewirddieArtderNachrichtgepr uftundeineReaktionfestgelegt.DiessollnunanhandvonzweimoglichenNachrichtengezeigtwerden....@Overridepublic void onReceive(final Object message) throws Exception {if (message instanceof StartServant) {final StartServant msg = (StartServant) message;ActorRef servant = UntypedActor.actorOf(newUntypedActorFactory() {public UntypedActor create() {return new Servant(msg.getId());}});System.out.println(getContext().getId() + " starting "+msg.getId());getContext().startLink(servant);this.linkedServants.put(msg.getId(), servant);}...Listing2.4:ReaktioneinesMastersaufeineStartServant-NachrichtDerMasterindiesemBeispielreagiert,wieinListing2.4gezeigt,aufeineNach-richt vomTypStartServant. Dazuwirdzuerst gepr uft, vonwelchemTypdasempfangeneObjektist. HandeltessichumeinStartServant-Objekt, wird ubereine UntypedActorFactory ein neuer Actor vom Typ Servant erzeugt. Dieser wirdanschlieend durch getContext().startLink(. . . ) an den Master gebunden und ge-startet. Hinter der startLink-Methode verbergen sich die zwei Methoden link(. . . )und start(), welche auch unabhangig voneinander aufgerufen werden konnen. Zu-letztwirddieReferenzaufdenerzeugtenServant ineinerListegespeichert.Diesistnotig,umdemServantNachrichtensendenzukonnen,daeinActornurmitdenActorskommunizierenkann,welcheihmbekanntsind.EinweitererNachrichtentyp,aufdenderMasterreagierensoll,istdieScareSer-vant-Nachricht (Listing2.5). Diesewirdgesendet, umihnaufzufordern, einen2.3Actors 17seiner untergeordnetenServants zuerschrecken. DaeinMaster jedochauchselbsteinemanderenMasteruntergeordnetseinkann, kanndieNachrichtauchvonseinemVorgesetztenempfangenwerden.Dasheit,derMastermussandersaufeinesolcheNachrichtreagieren, wennerselbsterschrecktwird, alswennereinen seiner Servants erschrecken soll. In diesem Beispiel dient das ID-Attribut imNachrichtenobjektdazu, dieEmpfanger zuunterscheiden. BeimEmpfangeinerScareServant-Nachricht muss also zuerst gepr uft werden, ob die mit der Nachricht ubermittelteIDder IDdesMastersentspricht. Istdiesder Fall, wirdder Mas-terlediglicheineAusgabeindieKonsoleschreiben. Entsprichtdie ubermittelteIDjedochnichtseinereigenen, versuchtderMasterdieReferenzaufseinenun-tergebenenServantmitdieserIDausseinergespeichertenListezuholen.Wenneinsolcher Servantexistiert, sendetder Master ihmeineNachricht, umihnzuerschrecken. IndiesemBeispiel istdaseineinfacherString. EinStringkannalsNachrichtgesendetwerden,daStringsstandardmaigserialisierbarsind....else if (message instanceof ScareServant) {final ScareServant msg = (ScareServant) message;if (getContext().getId().compareTo(msg.getId()) == 0) {System.out.println(getContext().getId() + ": Im serving "+ getContext().getSupervisor().getId());} else {ActorRef servant = this.linkedServants.get(msg.getId());if (servant != null) {System.out.println("\n"+getContext().id()+ " says \"Boo!\" to " + msg.getId());servant.sendOneWay("Boo!");}}} ...Listing2.5:ReaktioneinesMasteraufeineScareServant-NachrichtCall-Back-MethodenAbschlieendsollesdemMasternochermoglichtwerden,allseineuntergebenenServants freizugeben und zu stoppen, wenn er selbst gestoppt wird. Um das Ver-halteneinesActorsauerhalbseinerNachrichtenbehandlungsteuernzukonnen,besitztderUntypedActordesAkka-FrameworksfolgendeCallback-Methoden:preStart()-wirdausgef uhrtbevorderActorgestartetwirdpostStop()-wirdausgef uhrtnachdemderActorgestopptwurde18 2AkkaHandsonpreRestart()-wirdausgef uhrtbevorderActorneugestartetwirdpostRestart()-wirdausgef uhrtnachdemderActorneugestartetwurdeDiepreStart-MethodewirdindiesemBeispiel nurdazugenutzt, eineKonsolen-ausgabe zu erzeugen, die das Starten des Masters anzeigt. Die postStop-Methodewirdgenutzt, umallenochaktivenuntergebenenActorsdesMasterssauberzubeendenundihreRessourcenfreizugeben.... @Overridepublic void postStop() {for (ActorRef servant : getContext().linkedActors().values()) {System.out.println(getContext().getId() + " releasing " +servant.getId());getContext().unlink(servant);servant.stop();}System.out.println(getContext().getId() + " is shutting down...");} ...Listing2.6:postStop-MethodedesMasters2.3.2 ServantDie Servants stellen die Arbeiter in diesem Beispiel dar. Allerdings beschrankt sichdasArbeitenaufeinekurzeKonsolenausgabe, nachdemsiedurcheineNach-richt von ihrem Master dazu aufgefordert wurden. Dazu wird auch im Servant dieonReceive-Methode uberschrieben,inwelcherdieunterschiedlichenNachrichten-typenbehandeltwerden.EinServantreagiertaufdreiunterschiedlicheNachrich-ten. Auf eineKill -Nachricht, welchevoneinemMaster gesendet wird, reagierteinServant, indemer eineExceptionwirft. Dies dient dazu, denServant zumAbsturzzuzwingen, damitderMasterdiesenneustartenmuss. Auf eineScare-Servant-Nachricht reagiert der Servant, indem er sich erschrickt und dies auf derKonsoleausgibt. ErhaltderServanteineShutDown-Nachricht, rufterdiestop-MethodedesUntypedActorauf, welchedenActorsauberbeendetundall seineRessourcenwiederfreigibt.EmpfangtderServanteineandereNachricht,teilterdemAbsendermit,dasserdieseNachrichtnichtkennt.public class Servant extends UntypedActor {public Servant(String id) {getContext().setId(id);}2.4Main 19@Overridepublic void onReceive(Object msg) throws Exception {if (msg instanceof Kill) {throw new Exception("Restart requested by "+getContext().getSupervisor().getId());} else if (msg instanceof Shutdown) {getContext().stop();} else if (msg instanceof ScareServant){System.out.println("\n"+getContext().getId() + ":Wah!");} else {System.out.println("\nReceived unknown Message");getContext().getSender().get().sendOneWay("unknown Message");}}@Overridepublic void preStart() {System.out.println(getContext().getId() + " ready to serve "+ getContext().getSupervisor().getId());}@Overridepublic void postStop() {System.out.println(getContext().getId() + " is dead");}}Listing2.7:Servant2.4 MainAbschlieendsoll nuneine Starter-Klasse implementiert werden, welche einenMasterselbststartenwird.DiesemMasterwerdenanschlieendNachrichtenge-sendet, umihnaufzufordern, sowohl einenMaster, als auchmehrereServantszu erzeugen und zu starten. Weiterhin werden Nachrichten an den Master gesen-det, um untergeordnete Servants zu erschrecken. Auerdem wird der Master einenServant gezielt zum Absturz bringen, um zu zeigen, wie die gewahlte Neustartstra-tegie umgesetzt wird. Zuletzt wird der Master sauber heruntergefahren, wodurcherall seineuntergeordnetenServantsebenfallssauberstoppt, sowiederenRes-sourcenwiederfreigibt.DieAbbildung2.1zeigteinenschematischenAblaufdesProgramms, aus Gr unden derUbersicht sind darin jedoch nur ein Master und einServantabgebildet.20 2AkkaHandson2.4.1 Ablaufmaster.start()ServantMasterservant.start()StartServant()ScareServant()sendOneWay("Buh")print("wah")StopServant()ShutDown()stop()StopMaster()stop()Abbildung2.1:SequenzdiagramAls erstes werden zwei Actors vomTypMastererzeugt. F urdeners-ten Master geschieht dies uber dieFabrikmethode actorOf(. . . ). Dader Konstruktor des Masters Pa-rameter erwartet, muss der MastermitHilfeeiner InstanzvonUnty-pedActorFactory erzeugt werden.DamitkonnenActorsmitbeliebi-gemKonstruktorerzeugtwerden.Bei der Verwendung dieser Me-thodesolltesichergestelltwerden,dass niemand eine Referenz aufdieInstanzdesActorserhalt.Da uberdieReferenzderStatusdesActorsdirektbeeinusstwerdenkann, konnenRace-Conditionsentstehen. IndiesemBeispielsollenjedochauchNachrichtendirektaneinenActorgesendetwerden, welchervoneinemMastererzeugtundgestartetwurde.DazukanneineGetRefTo(. . . )-NachrichtaneinenMastergesendetwerden, umeineReferenzauf einenseinerUntergebenenzuerhalten. DurchdasSendeneiner solchenNachrichtaneinenMaster wird dieser also mit einer Referenz auf den gew unschten Actor antworten.Wie in Listing 2.8 zu sehen ist, wird der erste Master (Master1) durch eine Start-Master -Nachricht dazu aufgefordert, einen weiteren Master (Master2) zu starten.Dieser wird Mater 1 untergeordnet sein. Um Nachrichten auch direkt an Master2sendenzukonnen, wirdals nachstes vonMaster1durchdasSendeneiner Ge-tRefTo(. . . )-Nachricht eine Referenz auf denzuvor erzeugtenundgestartetenMaster2 angefordert. Als nachstes werden an die beiden Master je drei Nachrich-tengesendet, umsieaufzufordern, neueServants zuerzeugenundzustarten.Abbildung2.2zeigtdiedadurchentstehendeHierarchie.Zuletzt werden dann folgende Nachrichten an Master1 und Master2 gesen-det. Master2 erhalt eine Auorderung, einen seiner untergeordneten Servantszu stoppen. Dadurch wird der entsprechende Servant sauber heruntergefah-renundseine Ressourcenwerdenwieder freigegeben. Als nachstes wirdMas-ter1 aufgefordert, einen seiner Servants zu erschrecken. Nach Erhalt dieserScareServant-Nachricht wirdMaster1seinemServant eineNachricht schicken,wodurch der Servant sich erschrickt und dies auf der Konsole ausgibt. Zu-letzt wird eine RestartServant-Nachricht an Master2 gesendet. Bei Empfangeiner solchen Nachricht reagiert der Master, indemer eine Kill -Nachricht2.4Main 21M1M2 S1.1 S1.2 S1.3S2.1 S2.1 S2.1Abbildung2.2:entstehendeHierarchiean den entsprechenden Servant sen-det. Der Servant wiederumreagiertauf diese Nachricht, indem er eine Ex-ceptionwirft. Dieses Verhaltendientdazu, den Servant zumAbsturz zuzwingen, um die Neustartstrategie desMasters zuveranschaulichen. Indie-semBeispiel setzt der Master2 dieAllForOne-Strategie um. Das heit, erwird alle ihmuntergeordneten Ser-vantsneustarten, nachdemeineraus-gefallenist. Master1hingegenw urdelediglichdenausgefallenenServanterneutstarten,daerdieOneForOne-Strategieumsetzt.public class Starter {private static ActorRef master1 = null;private static ActorRef master2 = null;public static void main(String[] agrs) {master1 = UntypedActor.actorOf(new UntypedActorFactory() {@Overridepublic UntypedActor create() {return new Master("Master1", "OneForOne");}}).start();master1.sendOneWay(new StartMaster("Master2", "AllForOne"));master2 = (ActorRef) master1.sendRequestReply(newGetRefTo("Master2"));for (int i = 1; i >> Master2 restarting Servant2.1Servant1.2:Wah!Servant2.2 is dead>>> [akka:event-driven:dispatcher:global-6] [ERROR]...Exception wheninvoking...Servant2.1...with message [messages.Kill@e020c9]java.lang.Exception: Restart requested by Master2...[akka:event-driven:dispatcher:global-8] ... Restarting actor[Servant2.3]... Servant2.3 ready to serve you Master2[akka:event-driven:dispatcher:global-8] ... Restarting actor[Servant2.1]... Servant2.1 ready to serve you Master2Listing2.9:KonsolenausgabeLiteraturverzeichnis 23Literaturverzeichnis[1] Scalable Solutions, Akka - Untyped Actors, http://www.akka.io/untyped-actors-java,2011.24 2AkkaHandson3 JavaAgentDEvelopmentFrameworkTobiasGartnerInhaltsverzeichnis3.1 Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 DasAgentenparadigma. . . . . . . . . . . . . . . . . . . 263.3 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 AlsowasistJADE?. . . . . . . . . . . . . . . . . . . . . 283.5 DieArchitekturvonJADE . . . . . . . . . . . . . . . . . 293.6 EntwickelnmitJADE. . . . . . . . . . . . . . . . . . . . 303.6.1 DieAgentenklasse . . . . . . . . . . . . . . . . . 303.6.2 VerhaltenvonAgenten . . . . . . . . . . . . . . 313.6.3 Agentenkommunikation . . . . . . . . . . . . . . 333.6.4 NamenundNamensdienst. . . . . . . . . . . . . 353.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . 36DasJavaAgentDEvelopmentFramework, kurzJADE, lasstsichalseineMidd-lewarezurEntwicklungundAusf uhrungvonPeer-to-Peer -Anwendungendenie-ren, die auf dem Agentenparadigma basieren und nahtlos miteinander interagierenkonnen.Dazuistesnotwendig,dieseBegrieetwasgenauerzubetrachten.3.1 Peer-to-PeerDasClient-Server-ModellistdasReferenzmodell,dasweitreichendbekanntistund hauptsachlich in verteilten Anwendungen in einer Variante angewendet wird.Es basiert auf einer Rollenverteilung zwischen den Klienten und einem oder meh-reren Servern. Server bieten dabei einen Dienst, also die Fahigkeiten des verteiltenSystems an. Sie konnen aber keinerlei Initiative ergreifen, da sie stets nur auf einenAufrufdurcheinenKlientenwarten.Dieseliegtbei denKlienten.Siegreifenauf26 3JavaAgentDEvelopmentFrameworkdieangebotenenDienstezu,wasmeistaufgrundvonNutzeranfragennotwendigwird. Klienten bieten sonst aber keinerlei zusatzliche Fahigkeiten in dem verteiltenSystem.KlientenkonnendemverteiltenSystemjederzeitbeitretenundeswiederverlas-senundkonnendabeiineinembestimmtenRahmenbeliebigeNetzwerkadressenhaben. Die Server hingegen operieren an einer festen bekannten Adresse und ihrePrasenzmussgarantiertsein.DieKlientenkommunizierenmitdemServer,abernieuntereinander.Das Internet ist eintypisches Beispiel f ur eineAnwendungbasierendauf demClient-Server-Modell.DieWebseitenwerdenvondenWebservernangebotenunddie Browser sind die Klienten die mit den Servern interagieren, um ihren NutzerndieInhaltedarzustellen.ImPeer-to-Peer-Modell gibteskeineUnterscheidungvonRollenmehrundjederPeer besteht aus einer Mischungaus InitiativeundDienstangebot. Jeder PeerkanndieKommunikationinitiierenoder Adressatder Kommunikationsein. DieAnwendungslogikist nicht ineinemServer konzentriert, sondernauf allePeersimNetzwerkverteilt.Dabei konnendiePeersjederzeiteinanderentdecken,demNetzwerk beitreten und verlassen. Das System und die Dienstleistung ist komplettzwischendengleichberechtigtenPeersverteilt.Ein wichtiger Unterschied ist also, wie die Kommunikationspartner entdeckt wer-den konnen. In einem Client-Server-System m ussen die Klienten den Server, abernicht die anderen Klienten kennen, da diese nie direkt untereinander kommunizie-ren. InPeer-to-Peer-SystemenmusseshingegeneinenMechanismusgeben, deres erlaubt, dem Netzwerk beizutreten, es zu verlassen und, einer Art Telefonbuchgleich,PeersmitihrenangebotenenFahigkeitenzunden.AufdiesenFaktenbasierendlassensichzwei Peer-to-Peer-Netzwerkmodelleun-terscheiden: reinePeer-to-Peer-NetzwerkeundhybridePeer-to-Peer-Netzwerke.ReinePeer-to-Peer-NetzwerkesindkomplettdezentralisiertundihrePeersarbei-ten komplett autonom. Ohne einen festen Index ist es schwierig, die Koharenz desNetzwerkeszuwahrenundPeerszuentdecken. DiehybrideArchitektur hinge-gensetzteinenspeziellenIndexein,dereinenDienstzumeinfacherenAundenaktiverPeersundderenFahigkeitenanbietet.3.2 DasAgentenparadigmaDas Agentenparadigma wendet Konzepte der k unstlichen Intelligenz und derSprechakttheorie auf die Technologie der verteilten Objekte an und basiert darauf,einenAgentenalsSoftwarekomponentezuabstrahieren, dieautonom, proaktivundsozialist:3.2DasAgentenparadigma 27autonom:Agentenhabeneingewisses MaanKontrolle uber ihreeigenenAktionen,kontrollierensichselbstundkonnenjederzeiteigeneEntscheidungentreen.proaktiv:Agenten reagieren nicht einfach nur als Antwort auf externe Ereignisse(z. B.einementferntenMethodenaufruf)sondernzeigenaucheinzielgerich-tetesVerhaltenundergreifenselbstdieInitiative.sozial:AgentensindfahigundgezwungenmitanderenAgentenzuinteragieren,umihreAufgabezuerf ullenundihrenTeilamGesamtzieldesverteiltenSystemszuleisten.AgentenbasiertenSystemenwohnt alsoder Peer-to-Peer-Charakter inne: JederAgentisteinPeer,dersowohleineKommunikationzueinembeliebigenanderenAgenten aufbauen kann, als auch seine eigenen Fahigkeiten anderen Agenten an-bieten kann. Die Kommunikation ist ein sehr wichtiger Aspekt in agentenbasiertenSystemenundbautaufdenfolgendendreiHauptkriterienauf:1. AgentensindaktiveEinheiten,dieeineAktionablehnenkonnenundnurlosegekoppelt sind. Daher erfolgt die Kommunikation zwischen Agenten asynchronund nachrichtenbasiert und nicht durch entfernte Methodenaufrufe. Ein Agentsendet also einfach eine Nachricht an den Agenten, mit dem er kommunizierenmochte. Der Empfanger kann nun selbst entscheiden, auf welche Nachrichtener inwelcher Reihenfolgeantwortet oder welcheer verwirft. Der sendendeAgentwirddadurchauchnichtblockiert,bisderEmpfangerantwortet.Diesentfernt die kurzfristige Abhangigkeit zwischen Sender und Empfanger, da derEmpfanger zum Zeitpunkt des Kommunikationsversuchs nicht verf ugbar oder uberhauptnichtprasentseinkann.2. Agentenf uhrenAktionendurchunddieKommunikationistnureineweitereArtvonAktion.DieKommunikationaufdieselbeStufe,wiedieAktionendesAgentenzusetzen, erlaubt eseinenPlanzuerortern, der sowohl physischeals auchkommunikativeAktionenbeinhaltet. Umdieseplanenzukonnen,m ussenAuswirkungenundVorbedingungenjedermoglichenKommunikationklardeniertsein.3. JedeKommunikationhateinesemantischeBedeutung.WenneinAgenteineNachricht empfangt, muss er diesegenauverstehenkonnenundauchver-stehen, warumdieseAktiondurchgef uhrtwurde, alsodiebezweckteAbsichterkennen. DiessetzteineallgemeineSemantikvorausundf uhrtzumBedarfnacheinemStandard.28 3JavaAgentDEvelopmentFramework3.3 MiddlewareDerBegriMiddlewarebeschreibtmeistBibliothekenaufhoherenEbeneninei-nemkomplexenSoftwaresystem,dieeineeinfachereundeektivereEntwicklungeiner Vielfalt von verschiedenen Anwendungen ermoglichen. Diese bieten verschie-deneDienstef urz. B.Dateizugrie,Kommunikationusw.an.DieselbenDienstewerdenauchdirektvomBetriebssystemangeboten, aberdasZiel einerMiddle-wareist einebetriebssystemunabhangigeAPI mit wiederverwendbarenMitteln.Diesem ussensomitnichtinjederAnwendungneuentwickeltwerden, waseinegroeZeitersparnis bedeutet. EineSoftwarekomponente, diemit einer anderenSoftwarekomponentekommunizierenmochte,nutztalsodaf urSchnittstellenderMiddlewareanstatt uberBetriebssystemmittel direktmitihrzukommunizieren.Eine Antwort wird dann von der Middleware uber denselben Weg zur uck geleitet,dendieurspr unglicheNachrichtgenommenhat.3.4 AlsowasistJADE?JADE ist die durch das italienische Telekommunikationsunternehmen TILAB ent-wickelteMiddlewarezurEntwicklungverteilterMultiagentenanwendungenbasie-rendaufderPeer-to-Peer-Architektur. DieLogik, dieInitiative, DatenundRes-sourcenunddieKontrollekannsowohl auf mobileEndgerate, alsauchauf festeingerichteteComputer imNetzwerkverteilt werden, daJADEinJavaimple-mentiert wurdeundinnahezujeder JavaVirtual Maschine(auer JavaCard)ausgef uhrtwerdenkann.Die Umgebung kann sich dynamisch mit ihren Peers (in JADE Agenten genannt)entwickeln, die erscheinen und verschwinden, je nach dem, wie die Bed urfnisse desAnwendungssystemssind. DieKommunikationzwischendeneinzelnenAgentenist symmetrisch. Jeder Agent ist in der Lage sowohl Absender, als auch EmpfangereinerNachrichtzusein.JADEbasiertauffolgendenPrinzipien:Interoperabilitat:JADE ist standardkonform zu den FIPA-Spezikationen (siehe Kapitel 5) Da-her sind JADE-Agenten fahig, mit allen Agenten zu interagieren, die ebenfallsdenselbenStandarderf ullen.UniformitatundPortabilitat:JADEbietet einehomogeneMengeanAPIs an, dieunabhangigvomvor-handenenNetzwerkundder Java-Versionsind: JADE-AgentensindindenJava-UmgebungenJ2EE,J2SEundJ2MElauahig.3.5DieArchitekturvonJADE 29Einfachnutzbar:Die Komplexitat der Middleware wirddemEntwickler durcheinfache undintuitiveAPI-Aufrufeverborgen.Nur-das-was-man-braucht-Philosopie:Entwicklerm ussennichtalleFunktionenderMiddlewarenutzen.UberFunk-tionen,dienichtbenotigtwerden,brauchtmanauchnichtszuwissen.3.5 DieArchitekturvonJADEDasJADE-Frameworkbeinhaltetsowohl dieJava-Klassen, diebenotigtwerden,umeigeneSoftwareagentenzuentwickeln, alsaucheineLaufzeitumgebung, diediegrundlegendenDiensteanbietet, mithilfederer dieSoftwareagentenauf ei-nemgeeignetenZielgerat ausgef uhrt werdenkonnen. Eine Instanz der JADE-LaufzeitumgebungwirdContainer genannt undbeinhaltet die Agenten. DieGesamtmengederUmgebungenwirdPlattformgenannt.Abbildung3.1:ContainerundPlattformeninJADE(Quelle:[2])DiesePlattformbildeteinehomogeneSchichtab, diejeglicheKomplexitatundVerschiedenheitderdarunterliegendenHardware, Betriebssystem, NetzwerkundVirtual MachinevordenAgentenverbirgt.MindestenseinContaineristinjederPlattform prasent: derMain-Container. Der erste in der Laufzeitumgebung ge-30 3JavaAgentDEvelopmentFrameworkstarteteContaineristtypischerweisedieserHauptcontainer.DieserunterscheidetsichvonanderenContainern, daerzwei spezielleAgentenbeinhaltet, dieauto-matischgestartetwerden.DieseAgentensinddasAgentManagementSystem(AMS) und derDirectory Facilitator(DF). Das AMS bietet einen Namensdienstundstelltsicher,dassjederAgenteineneindeutigenNamenhatundermoglicht,einen Agenten in einem entfernten Container zu starten oder zu stoppen. Der DFbietet einenVerzeichnisdienst an, uber denAgentendieFunktionalitat andererAgentenabrufenkonnen. InderAbbildung3.1istdergesamteZusammenhanggraschdargestellt.3.6 EntwickelnmitJADEImFolgendensoll beschriebenwerden,wiemitdemJADE-Frameworkeinagen-tenbasiertesSystemerstelltwerdenkann.DazuwirdimWesentlichendirektaufdieKlassenunddievonihnenangebotenenMethodeneingegangen.3.6.1 DieAgentenklasseEinen JADE-Agenten zu erzeugen, beschrankt sich zunachst darauf, eine Klasse zuschreiben, die die Klassejade.core.Agent erweitert und die Methodesetup()redeniert,wiediesinListing3.1gezeigtwird.import jade.core.Agent;public class HelloWorldAgent extends Agent {@Overrideprotected void setup() {System.out.println("Hello World! My name is " +getLocalName());}}Listing3.1:BeispielcodeeinessehreinfachenAgentenDie Methodesetup() ist daf ur vorgesehen, den Agenten zu initialisieren. Die ei-gentliche Arbeit wird mit entsprechendem Verhalten abgebildet und sollte nicht indieserMethodevorgenommenwerden.VerhaltenwirdmitderspatererlautertenKlasse Behaviour oder abgeleiteten Klassen dieser Klasse aus demPackagejade.core.behaviours abgebildet, wobei die Instanzen des Verhaltens wahrend3.6EntwickelnmitJADE 31des Setup erzeugt werden konnen. Das Gegenst uck zum Setup stellt die MethodetakeDown() dar. Hier konnen Aufraumarbeiten durchgef uhrt werden, die kurz vorder BeendigungeinesAgenten, z. B.nachErledigenseiner Aufgabe, notigwer-den. Ein Agent kann sein eigenes Beenden durch Aufruf der Methode doDelete()veranlassen.3.6.2 VerhaltenvonAgentenWie bereits erwahnt, wird die zu erledigende Aufgabe eines Agenten mit Verhaltenabgebildet.SolcheinVerhaltenwirddurcheineInstanzeinerKlasseangegeben,dievonder KlasseBehaviourabgeleitetwurde. DamiteinVerhaltenvondemAgentenausgef uhrtwird,istesnotwendigdiesesVerhaltenzumAgentenhinzu-zuf ugen,d. h.dieMethodeaddBehaviour() des Agentenaufzurufen.Dies kannjederzeitgeschehen:wahrenddesSetupsoderauchinnerhalbandererVerhalten.JedeAbleitungderKlasseBehaviourmussdieabstraktenMethodenaction()unddone()denieren. Ersteredeniert diedurchgef uhrtenOperationenwenndasVerhaltenausgef uhrt wird. DiezweiteMethodezeigt uber denbooleschenR uckgabewertan,obdasVerhaltenabgeschlossenwurdeundvomPooldervomAgenten zugeordneten Verhalten entfernt werden kann. Sind keine Verhalten mehrvorhanden, wird der Thread des Agenten schlafen gelegt, um keine CPU-Zeit mehrzu konsumieren und wird wieder aufgeweckt sobald ein Verhalten ausgef uhrt wer-denkann.EinAgentkannmehrereVerhaltengleichzeitigausf uhren.DiePlanungdeszeit-lichenAblaufsvonVerhalteneinesAgentenistjedochnichtpraemptiv, wiebeiThreads, sondern kooperativ. Soll das Verhalten ausgef uhrt werden, wird die Me-thodeaction()aufgerufenundlauftunterbrechungsfreibiszurBeendigung.Esobliegt also dem Programmierer, zu entscheiden, wann von einem Verhalten zumnachstenumgeschaltenwird. EineEndlosschleifesollteinjedemFall vermiedenwerden. EswerdenfolgendedarausresultierendeVorteiledieserLosungangege-ben:Eserlaubt, nur eineneinzigenThreadf ur jedenAgentenzunutzen, wasinUmgebungenmitlimitiertenRessourcen,wieMobiltelefonenwichtigist.Die Umschaltung zwischen Verhalten ist wesentlich schneller als das Umschal-tenzwischenThreads.DieSynchronisationvonnebenlaugenVerhalten, diedieselbenRessourcenverwenden entfallt, da alle Verhalten eines Agenten in demselben Thread aus-gef uhrtwerden.32 3JavaAgentDEvelopmentFrameworkBei derUmschaltungdesVerhaltensenthaltderStatuseinesAgentenkeineStackdatenundesistmoglichdenStatusfestzuhalten(Persistenz)unddenAgentenanzuhalten,umdiesenspaterfortzusetzenoderihnineinenanderenContaineraufeinementferntenSystemzutransferieren(Mobilitat).InJADEwurdemehrereVerhaltenbereits vordeniert, umbestimmtewieder-kehrendeMuster abzubilden. DiesesindUnterklassender besprochenenKlasseBehaviour.GenerischesVerhaltenGenerischesVerhaltenwirddurchdirekteNachfahrenderKlasseBehaviourab-gebildet undenthalt eineArt StatusunddieAusf uhrungdesVerhaltenshangtvondiesemStatusab. DiesesVerhaltenistabgeschlossenwenneinbestimmterZustand erreicht wurde. Es ist mit einem Zustandsautomaten vergleichbar. In derMethodeaction() andert sich der Zustand. Die einzelnen Zustande werden ein-zeln sequentiell abgearbeitet, bis die Methodedone() durch R uckgabe vontruedasVerhaltenabschliet.EinmaligesVerhaltenDieses Verhaltenwirdunverz uglichabgeschlossenunddieMethode action()wird nur ein einziges Mal ausgef uhrt. Die Klasse OneShotBehaviour imple-mentiert die Methode done() bereits durch R uckgabe von true, sodass dieAusf uhrungdesVerhaltensnachdemerstenMalbereitsabgeschlossenist.WiederkehrendesVerhaltenWiederkehrendes Verhalten ist niemals abgeschlossen und die Methode action()f uhrt bei jedem Aufruf dieselben Operationen aus. Die KlasseCyclicBehaviourimplementiert die Methode done() durch R uckgabe von false. Dieses Verhaltenwirdsolangeimmerwiederausgef uhrt,bisderausf uhrendeAgentbeendetwird.VerzogertesVerhaltenDie Klasse WakerBehaviour implementiert beide abstrakte Methoden vonBehaviourundf uhrt die abstrakte Methode handleElapsedTimeout()ein,dieeinmalignachAblauf einer uber denKonstruktor angegebenenZeitspanneausgef uhrtwird.3.6EntwickelnmitJADE 33IntervallverhaltenDies stellt eine Kombination aus wiederkehrendem und verzogertem Verhalten dar.DieKlasseTickerBehaviourf uhrteineabstrakteMethodeonTick()ein, diewiederkehrend nach Ablauf einer uber den Konstruktor anzugebenden Zeitspanneausgef uhrtwird.DiesesVerhaltenwirdniemalsabgeschlossen.KomplexesVerhaltenJADEermoglicht das KombinierenvoneinfachenVerhaltensmusternzukom-plexemVerhalten. An dieser Stelle sind die Klassen SequentialBehaviour,ParallelBehaviourundFSMBehaviourzunennen.3.6.3 AgentenkommunikationEinesderwichtigstenFahigkeitenvonJADE-AgentenistdieFahigkeit,zukom-munizieren.DasinJADEangewendeteKommunikationsparadigmaistdasasyn-chroneNachrichtenversenden. Jeder AgenthateineArtBriefkastenindemdieNachrichtenanderer AgentendurchdieJADE-Laufzeitumgebungabgelegtwer-den. GelangtNachrichtindieseWarteschlange, wirdderbetreendeAgentbe-nachrichtigt.ObundwannderAgentdieNachrichtverarbeitet,liegtinderEnt-scheidungsgewaltdesProgrammierers.Abbildung3.2:AsynchronousMessagePassingParadigmainJADE(Quelle:[2])Die ausgetauschten Nachrichten werden durch die ACL-Sprache bestimmt, welchedurchdieFIPA1speziziertwurde.EineNachrichtbestehtdementsprechendauseinigenFeldern:1FIPA: IEEEFoundationforIntelligentPhysical Agents; http://www.pa.org(sieheauchKa-pitel 5)34 3JavaAgentDEvelopmentFrameworkDemAbsenderderNachrichtEinerListvonEmpfangernDemGrund der Kommunikation: REQUESTwennder Absender mochte,dassderEmpfangereinebestimmteAktionausf uhrt, INFORMinformiertdenEmpfanger ubereineSache, QUERYIFwennderSendereinebestimmteBe-dingungpr ufenmochte oder eine der folgendenwahrendder Verhandlungzwischen Agenten: CFP (call for proposal, Angebotsanfrage), PROPOSE (Ange-bot),ACCEPTPROPOSAL (Angebotsannahme),REJECTPROPOSAL (Angebots-ablehung)etc.DemInhaltderNachricht,z. B.dieAktiondiebei einerREQUEST-Nachrichtausgef uhrtwerdensollDie Spache der Nachricht bzw. die genutzte Syntax, die Sender undEmpfangerverstehenm ussenDieOntologie,alsodasVokabularderverwendetenSymboleundderenBe-deutung,diezwischendenKommunikationspartnernnichtabweichendarfWeitereFelder, umnebenlaugeKommunikationzusteuernoder Timeoutsf urdenErhalteinerAntwortanzugebenEine solche Nachricht wird in JADE durch ein Objekt der Klasse ACLMessage ver-wendet, dass entsprechende Get- und Set-Methoden f ur den Zugri auf die Felderder Nachricht implementiert. F ur das Senden einer Nachricht bietet die Basisklas-seAgentdieMethodesend()undf urdasEntnehmeneinerNachrichtausderWarteschlangedieMethodereceive(). Vor demSendenist dasNachrichten-objektg ultigmitWertenzuf ullen.DieEmpfangsmethodelieferteinNullobjekt,wennsichkeineNachricht inder Warteschlangebendet. Umdirekt eineAnt-wort auf eineNachricht zuerzeugen, bietet sichdieMethodecreateReply()derKlasseACLMessagean.F urdasAbrufenderNachrichtenbietetsicheinzyklischesVerhaltenan. Dabeimussmanbeachten, dassdaspermanenteAbfrageneinehoheCPU-Lastgene-riert,waseigentlichvermiedenwerdensollte.DielasstsichmitderangebotenenMethodenblock()der Klasse Behaviourverhindern, diedas Ausf uhrenvonVerhaltendesAgentenblockiert.DieLaufzeitumgebungsetztblockierteVerhal-tenbeiErhalt von Nachrichtenselbsttatig fort. Blockierenwird empfohlen,wenndieWarteschlangeeinesAgentenleerist.Anstellevonreceive()sollindiesemZusammenhangdieMethodeblockingReceive()einesAgentenerwahntsein.DieseblockiertallerdingsalleVerhalteneinesAgentenundnichtnurdasaktuellabzuarbeitende und wird daher nicht f ur die Verwendung innerhalb von Verhaltenempfohlen.3.6EntwickelnmitJADE 353.6.4 NamenundNamensdienstJeder Agent besitzt eineAgentenidentizierung, welchedurcheineInstanzderKlasseAIDreprasentiertwird. Dieseumfasseneinenglobal eindeutigenNamen,welchersichinJADEdurchdenNamendesAgentenundderBezeichnungderPlattformzusammensetzt, undAdressen, diebenotigtwerden, wennder AgentmitanderenAgentenaufanderenPlattformenkommunizierenmochte.Bendensichdie kommunizierendenAgentenauf derselbenPlattform, kannmaneinenAgenten uberdenNamenundderAngabederKonstanteAID.ISLOCALNAMEalszweitenParameter imKonstruktor der KlasseAIDidentizieren. Bei einfachenAnwendungen kann man so eine feste Liste mit Kommunikationspartnern aufbau-en.WenndieListederpotentiellenKommunikationspartnernichtderartstatischist,wirdeinMechanismusbenotigt,dereserlaubt,alleAgentenzunden,dieeinenbestimmtenServiceanbieten.HierkommtderNamensdienst,derinJADEauchalsdieGelbenSeitenbenanntwird,insSpiel.UberdieseGelbenSeitenkanneinAgent seineangebotenenDiensteveroentlichenunddieangebotenenDienstevonanderenAgentenerfahren, umsiezunutzen. DieGelbenSeitenwerdeninJADEdurchdenAgentenDF(DirectoryFacilitator)realisiert,derinjederPlatt-formbereitsstandardmaiglauft. WeitereDF-Agentenkonnenaktiviertundsoverbundenwerden,dassdieseeinenverteiltenKatalogf uhren.Da der DF ebenfalls ein Agent ist, reicht es f ur die Interaktion aus, ACL-Nachrichtenandiesenzuversenden. Dabei wirddiepassendeSprache, dieSL0,undpassendeOntologie,dieFIPA-agent-managementOntologie,verwendet,umkonform zur FIPA-Spezikation zu sein. Allerdings bietet JADE zur VereinfachungdieKlasseDFServicean, um uberMethodenaufrufeDienstezuveroentlichenoderzusuchen.UmeinenDienst zuveroentlichen, muss einAgent diesenpassendbeschrei-ben. Darunter fallen die AID des Agenten, die Liste der moglichen Spra-chen und Ontologien, die andere Agenten benotigen, umkommunizieren zukonnen, sowie die Liste der veroentlichten Dienste. F ur jeden dieser Diens-te m ussen wiederumdie Sprachen und Ontologien und einige Dienstspezi-scheEigenschaftenangegebenwerden. F urdiesenZweckbietetJADEdieKlas-senDFAgentDescription, ServiceDescriptionundPropertyimPackagejade.domain.FIPAAgentManagement. DieeigentlicheRegistrierungwirddanndurch einen Aufruf der Methode register() der Klasse DFService durch-gef uhrt. Dieswird ublicherweiseinder SetupphasedesAgentenerledigt. DieseRegistrierung sollte beim Beenden (Methodetakedown()) des Agenten uber dieMethodederegister()wiederr uckgangiggemachtwerden.36 3JavaAgentDEvelopmentFrameworkUmeinenveroentlichtenDienst uber dieKlasseDFServicezusuchen, mussman dieser uber die Methode search() eine entsprechende Schablone einerAgentenbeschreibung, ahnlichder beimRegistrieren, ubergeben. Das Ergebnisder Suche ist eine Liste von Agentenbeschreibungen, die mit allen in der Schablo-neangegebenenWerten ubereinstimmen.TypischerweisesolltedasSucheneinesAgentenzeitnahzur Nutzungdes entsprechendenDienste erfolgen, da Agen-tenprinzipiell jederzeit demSystembeitretenundverschwindenkonnen. DerDFunterst utzt allerdings auch uber dieMethodensearchUntilFound()undcreateSubscriptionMessage()das Beobachtendes Katalogs, bis einAgenteinenentsprechendenDienstveroentlicht.3.7 ZusammenfassungIndiesemKapitel wurdezunachsterklart,umwasessichbeimJavaAgentDE-velopment Framework handelt. Es wurde dargelegt, wie die gundlegende Strukturdes Frameworks ist undversucht, die Funktionsweise zuerklaren. ImzweitenTeil konntederinteressierteLeserlernenunderfahren,wieeinfachdasErstellenvonagentenbasiertenSystemenmitEinsatzdesJADE-Frameworksist.Eskonn-tenicht auf erweiterteFunktionalitatenvonJADEwiez. B.dieMobilitat vonAgenteneingegangenwerden.Literaturverzeichnis[1] F. Bellifemine et al., JADE A White Paper, http://jade.cselt.it/papers/2003/WhitePaperJADEEXP.pdf,expVolume3-September2003.[2] Giovanni Caire, JADEProgrammingFor Beginners, http://jade.tilab.com/doc/tutorials/JADEProgramming-Tutorial-for-beginners.pdf, Stand vom Juni2009.[3] F. Bellifemine et al., JADE Programmers Guide, http://jade.tilab.com/doc/programmersguide.pdf,StandvomApril2010.4 JanusReneKasselInhaltsverzeichnis4.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.1 Agenten . . . . . . . . . . . . . . . . . . . . . . 374.1.2 Multiagentensystem . . . . . . . . . . . . . . . . 384.1.3 CRIOEinorganisatorischesMetamodell . . . . 394.1.4 Maven . . . . . . . . . . . . . . . . . . . . . . . 404.2 Janus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.1 DasJanus-Projekt . . . . . . . . . . . . . . . . . 404.2.2 DieVorbereitungeinesJanus-Projektes . . . . . . 404.2.3 DerLebenszykluseinesAgenteninJanus. . . . . 414.2.4 DasStarteneinesAgenten . . . . . . . . . . . . . 424.2.5 DieAgent-to-AgentDirectCommunication. . . . 434.3 PraktischeBeispiele . . . . . . . . . . . . . . . . . . . . . 444.3.1 Market-LikeCommunity . . . . . . . . . . . . . . 444.3.2 Boids . . . . . . . . . . . . . . . . . . . . . . . . 464.3.3 AntColony. . . . . . . . . . . . . . . . . . . . . 474.4 Schlusswort . . . . . . . . . . . . . . . . . . . . . . . . . 494.1 GrundlagenDer folgende Abschnitt f uhrt die grundlegendenBegriichkeitenein, die zumVerstandnisdiesesKapitelsnotwendigsind.4.1.1 AgentenAls Agent wird ein Computerprogrammbezeichnet, das zu autonomen (ei-genstandigen) Verhalten fahig ist. Dies bedeutet, dass ein bestimmter Verar-beitungsvorgangabhangigvonverschiedenenZustandenablauft, ohnedassvonaueneinStartsignalgegebenwirdodereinSteuerungseingriwahrenddesVor-gangeserfolgt. EsgibtkeineallgemeinanerkannteDenitionf urAgenten. Eine38 4Janussehr gute Denition ist folgende:Ein Agent ist ein Computersystem das sich in ei-ner bestimmten Umgebung bendet und welches fahig ist, eigenstandige AktionenindieserUmgebungdurchzuf uhren,umseineZielezuerreichen.[2]DerEinsatzvonAgentenAgentenkommeninverschiedenenBereichenzumEinsatz. DazuzahlendasE-Commerce, die Informationsrecherche, die Simulationsowie das ErledigenvonRoutineaufgaben. DieSimulationbildet dabei einSpezialgebiet. Sokann ubereineMulti-AgentensimulationeineigenerMarktsimuliertwerden, auf demz.B.einneuesSoftwareproduktgetestetwerdenkann.DieAgententypenEs gibt Unterschiede in der Art und Weise, wie sich ein Agent verhalt. Dabei wirdzwischendreiverschiedenenBereichenvonAgententypenunterschieden:ReaktiveAgenten:Diese verf ugen nicht uber eigenes Wissen. Sie agieren nur aufgrund ihrer eige-nenWahrnehmungunddirekt.Bei derReaktionaufeineBegebenheitndetkeinEntscheidungsprozessstatt.AdaptiveAgenten:DieseverwalteneinModell dereigenenProzess-undParameterstruktur. SiekonnenanauereBedingungenangepasst werden, welchedurchdieAgen-tengemessenodererkanntwurden. DadurchwirdeineoptimaleAusf uhrunggewahrleistet.KognitiveAgenten:DieseverwalteneinModellihrerUmweltineinereigenenDatenstruktur.DasermoglichteinePlanungderAktionenundeinzielgerichtetesHandeln.4.1.2 MultiagentensystemHierbei handelt es sichumeinSystemaus mehrerengleichartigenoder unter-schiedlichspezialisiertenhandelndenAgenten, welche gemeinsameinProblemlosen. Diese Systeme zahlenzumForschungsgebiet der VerteiltenK unstlichenIntelligenz. Multiagentensysteme beschaftigen sich damit, wie autonome, ver-teilteundintelligenteSystemealsEinheitihr spezischesWissen, ihreZiele,FahigkeitenundPlaneabstimmen,umkoordiniertzuhandelnoderProblemezulosen.4.1Grundlagen 394.1.3 CRIOEinorganisatorischesMetamodellJanus basiert auf denKonzeptendes CRIOMetamodells. Es dient dazu, denASPECTDevelopmentProcessumzusetzen. Dabei formuliertASPECTeinenAgentenorientierten Softwareprozess, welcher zur Entwicklung komplexer Anwen-dungendient.CRIOistwiefolgtdeniert:OrganisationDies ist eine Sammlung von Rollen, die systematisch in verschiedenen Interaktions-musternzusammenarbeiten. DieRollenstehenineinemgemeinsamenKontext.DieserbestehtausgemeinsamenWissen, sozialenRegelnundNormen, sozialenGef uhlenetc.,welchemiteinanderinVerbindungstehen.Ziel einerOrganisationistdiegemeinschaftlicheErf ullungeinerAufgabe.RollenEineRolleist einstrukturiertes Verhalten, was nachfestgelegtenRechtenundPichtenerfolgt. Das Ziel einer jedenRolleist es zur Erf ullungder Aufgabeneiner Organisation beizutragen. Es gibt interne Rollen (Common Role) und externeRollen(BoundaryRole).InterneRolle:DiesebeschreibteineRolle, dieinnerhalbdesSystemsentworfenwurde. SiekannmiteinerinternenundeinerexternenRolleinteragieren.ExterneRolle:Hierbei handelt es sich um eine Rolle, die aus dem System heraus nach auenkommuniziert. DieGesamtheit der externenRollendenierendas Interface(dieSchnittstelle)zumSystem(GUI,Datenbank).InteraktionInteraktionisteinedynamische, nichtvorher bekannteAbfolgevonEreignissendie zwischenRollenausgetauscht werdenoder zwischenRollenundEntitatenauerhalbdesAgentensystemsentwickeltwerden.RollenreagierenjenachihremVerhaltenaufdieEreignisse.Kapazitat/CapacityIn diesem Kapitel wird Capacity frei ubersetzt mit Fahigkeit. Es handelt sich dabeiumabstraktesWissen,welchesderAgentbesitztbzw.wasihmzugewiesenwird.DasKonzeptabstrahiertsozusagenKnow-HowvonderkonkretenRealisierung.40 4Janus4.1.4 MavenMavenisteinBuild-Management-Tool derApacheSoftwareFoundation.Esba-siertauf Java. MitihmkannmaninsbesondereJava-Programmestandardisierterstellenundverwalten. EswirdintausendenOpen-Source-undkommerziellenSoftwareprojekteneingesetzt, umdieSoftwareentwicklungzuvereinfachen. Ma-venwirdvonderJanus-Communityempfohlen,umdieEntwicklungeinesMutli-agentensystems mittels Janus zu vereinfachen. Alle Janus-Module sind f ur Maven-Module vorgesehen, welche uber das Maven-Repository von Janus erreichbar sind.4.2 JanusIndiesemAbschnittwirddasJanus-Projektselbstunddiewichtigsten,grundle-gendenEigenschaftenvonJanusbeschrieben.4.2.1 DasJanus-ProjektDasProjektbautaufeinerReihevonwissenschaftlichenArbeiten uberdieMo-dellierung und Simulation von komplexen Systemen auf. Besonderes Interesse giltdabei dem Bereich derholonic multiagent systems. Das Janus-Projekt bem uhtsich, dieganzeMethodikunddieUnterst utzungwerkzeugef urdieAnalyse, dasDesignunddieImplementierungvonkomplexenAnwendungenimZusammen-hangmitholonicmultiagent-systemszubieten.Ziel derCommunityist, einestep-by-step-AnleitungvondenAnforderungenbishin zur Implementierung zu geben. Janus ist eine Multiagentenplattform, die spe-ziell daf urentworfenwurdeholonic-undmultiagent-systemszuimplementierenundbereitzustellen.EsistinJAVA1.5geschriebenundbasiertaufdemCRIO-Metamodell.SchwerpunktistdieUnterst utzungundImplementationvonRollenundOrganisationenbei Agenten. JanusbieteteinumfassendesSetanFeaturesf urdieEntwicklung, Ausf uhrung, AnzeigeundUberwachungvonmultiagenten-basiertenAnwendungenundeignetsichdamitsehrgutzurEntwicklungdieser.4.2.2 DieVorbereitungeinesJanus-ProjektesJanus verwendet Maven f ur die Verwaltung seiner Module. Diese Arbeit be-schrankt sichauf dieErstellungeiner AnwendunginEclipse. F ur EclipsewirdeinPluginnamesM2Eclipsegeliefert,welchesinstalliertwerdenmuss.ZudemsindArchetypennotwendig, welchevonderJanus-CommunityineinemReposi-toryzurVerf ugunggestelltwerden.NachdemdasPlugininstalliertwurde,musseskonguriertunddieVerbindungzudemRepositoryhergestelltwerden.4.2Janus 41NachdemdieseSchrittevollzogensind, kanneineJanus-Anwendungimplemen-tiert werden. Dazu wird ein neues Maven-Projekt aus der Kategorie Maven ange-legt.SofortnachdemAnlegenwerdenallenotwendigenDatenzurImplementie-rung einer Janus-Anwendung von dem Repository gezogen. Anschlieend kann mitderEntwicklungdesMultiagentensystemsbegonnenwerden. ImNachfolgendenwerdeneinfacheImplementierungsgrundlagenvorgestellt.4.2.3 DerLebenszykluseinesAgenteninJanusJeder Agent inJanus durchlebt verschiedene Zustande. Sie sinddurchunter-schiedlicheAktivitatengepragt.Activate:Diese Aktivitat entspricht der Initialisierungsphase eines Agenten. ActivatewirdautomatischvomJanus-Kernel aufgerufen, wenneinAgent gestartetwird. Indieser PhasekanndemAgenteneineRollezugewiesenwerden, diederAgenteinnehmensoll.Live:Diese Phase bildet den Hauptteil des Agentenlebenszyklus. Die Live-Methodewird das Verhalten aufrufen, das der Agent in seiner Rolle besitzt. Jeder AufrufderMethodef uhrteinenSchrittdesRollenverhaltenaus.End:DiesistdieAktivitat,durchwelchederAgentbeendetwird.AlleRessourcen,welchedurchdenAgentenreserviertundverwendetwurden,werdenindieserMethodefreigegeben.Abbildung4.1:Agentenlebenszyklus[4]DieAbbildung4.1veranschaulichtdenstandardisiertenLebenszyklus mit dendazugehorigenAktivitaten. Der Agentstartet als unborn, bis die activate-Methode aufgerufen wird. Wahrend desalive-Zustandes des Agenten wirdkon-tinuierlich die live-Methode in einerSchleife durch den Janus Kernel aufge-rufen. DieseSchleifebrichtab, sobalddiekill -Methodeaufgerufenwird.Dar-aufhinwechselt derAgent in dendied-Zustand und ruft die end-Methode auf.Listing4.1beschreibtdietypischeArchitektureinesAgenteninJanus.Umeineneigenen Agenten zu implementieren, muss zunachst von der Klasse Agent aus dem42 4Janus@AgentActivationPrototype(fixedParameters={})public class MyAgent extends Agent {public MyAgent() {}@Overridepublic Status activate(Object... parameters) {return StatusFactory.ok(this);}@Overridepublic Status live() {Status status = super.live();//Dosomethingreturn status;}}Listing4.1:DietypischeArchitektureinesAgenten[4].Janus-Package abgeleitet werden. In der genannten Klasse sind alle grundlegendenMechanismen vorimplementiert. Um einen minimalen Agenten zu implementieren,m ussen nur die entsprechenden Methoden redeniert werden. Im Beispiel werden 2Statusmethoden redeniert (activate, live). In der Methode activate wird uber denAufruf StatusFactory.ok(this) dem System angezeigt, dass alles richtig abgelaufenist. In der Methode livewird die Methode liveder Basisklasse aufgerufen. Danachkann eigener Code ausgef uhrt werden, welcher entscheidend f ur das Verhalten desAgentenist.AmEndewirdderStatuszur uckgegeben.4.2.4 DasStarteneinesAgentenInJanusexistierenzwei verschiedeneArtendesStartenseinesAgenten.EswirdzwischendemHeavyAgentunddemLightAgentunterschieden.HeavyAgent:Jeder dieser Agentenhat seineneigenenThreadf ur seineAusf uhrung. EinHeavyAgentistdadurchvolligselbststandiginBezugaufseineRessourcen.LightAgent:DieserteiltseinenThreadmitanderenAgenten.DerZugrizudengemein-samen Ressourcen wird von einem Heavy Agentverwaltet. Janus liefert einenStandardverwalterf urdieHandhabungderAusf uhrungenvonLightAgents.EsbestehtjedochdieMoglichkeitseineneigenenVerwalterentwickeln.4.2Janus 43Der folgende Quellcode zeigt die unterschiedlichen Arten des Startens eines Agen-ten:public class MyMASApplicationLauncher {public static void main(String[] args) throwsInterruptedException {Kernel kernel = Kernels.get(false);MyAgent mylightagent = new MyAgent(); //nonthreadedkernel.launchLightAgent(mylightagent, "My Light Agent Name");MyAgent myheavyagent = new MyAgent(); //threadedkernel.launchHeavyAgent(myheavyagent, "My Heavy Agent Name");Kernels.killAll();}}Listing4.2:StarteneinesAgenten[4].Die Klasse MyMASApplicationLauncherdient dazu die Agenten zu starten. Hierzubenotigt sie nur eine main-Methode, in welcher zunachst ein Kernel f ur die Agen-teninitialisiert wird. Danachwerdenzwei Instanzender KlasseAgent erzeugt.Der ersteAgent wirdals lightAgent gestartet, welcher nicht ineinemeigenenThreadlauft. DerzweiteAgentwirdalsheavyAgent gestartet. DieserbekommteineneigenenThreadzugeteilt. AmEndederBeispielklassewirdanalleAgentseinKill-Signalgesendet,welchesdieAgentenwiederbeendet.4.2.5 DieAgent-to-AgentDirectCommunicationIn Janus gibt es verschiedene Kommunikationsmechanismen. Es gibt die einfacheAgent-to-Agent Direct Communication, aber auch die komplexere OrganizationalCommunication, welche auf Rollen- und Gruppenkonzepten basiert. Dieses Kapitelbeschrankt sichauf dieeinfacheAgent-to-Agent Direct Communication. DiesekannnochmalsunterschiedenwerdeninOne-to-OneCommunicationundOne-to-ManyCommunication.44 4JanusOne-to-OneCommunicationSoll eineNachrichtvoneinemAgentenzueinemanderengesendetwerden,wirdfolgendeMethodebenotigt[4]:AgentAddress sendMessage(Message message, AgentAddress agents)Der Methodenname lautet sendMessage. Sie hat als Parameter die Nachrichtselbst und den Zielagenten, an den die Nachricht gesendet werden soll. AlsR uckgabewert bekommt man die Adresse des Agenten, der die Nachricht erhaltenhat.One-to-ManyCommunicationSoll eineNachrichtvoneinemAgentenzuvielenanderengesendetwerden,wirdfolgendeMethodeverwendet[4]:void broadcastMessage(Message message, AgentAddress agents)Der Methodenname lautet broadcastMessage. Diese hat als Parameter wieder dieNachrichtselbstunddieZielagenten.SiebesitztkeinenR uckgabewert.4.3 PraktischeBeispieleIn diesemTeil folgen einige praktische Beispiele, welche durch die Janus-Community entwickelt wurden. Diese erweitern die eben vorgestellten grundlegen-denEigenschafteneinesAgentenumRollenunddiedadurchmoglicheZusam-menarbeitvonAgentenineinerOrganisation.DieImplementierungwurdeunterBer ucksichtigungdesCRIO-MetamodellsmitderJanus-Plattformdurchgef uhrt.4.3.1 Market-LikeCommunityDiesesBeispiel zeigtdieImplementierungvonRollenalsFirst-Class-Entities,dieDynamikindenRollenundKommunikationzwischendenRollen. Dieswirdineiner marktahnlichenGemeinschaft veranschaulicht. Das Beispiel wirdf ur denInlands-Reisemarktangewendet.Eswerden3einfacheAgententypenverwendet:EinClient(Kunde)4.3PraktischeBeispiele 45EinBroker(Makler)4Provider(Anbieter)Diesekommunizieren uberRollenmiteinanderinunterschiedlichenorganisatori-schenKontext. Ziel desClientsistes, dasbesteReiseangebotinBezugauf dieReisezeitoderaufdenPreiszubekommen. DerClientgibtseinenVorschlagabundsendetdiesenandenCBroker, welcherf urdenClientzustandigist. Dieserschickt die Informationen an den PBroker, welcher sie an alle verf ugbaren Providerweiterleitet. Die Broker bilden die Schnittstelle zwischen dem Client und dem Pro-vider.AbhangigvondemKriteriumdasderClientzuBeginngewahlthat(PreisoderZeit),bestimmtderPBrokerdenbestenVorschlagundteiltihndenClientmit. Der Client undder besteProvider bildendanneineOrganisationnamensContractingOrganisation (Vertragsnehmer) umdieBestellungabzuschlieenunddieZahlungzutatigen. Somitwirdf urdieUmsetzungdesvorgeschlagenenBeispielsfolgendesbenotigt:3Agententypen(Client(Agent1),Provider(Agent3,4,5),Broker(Agent2))3Organisationen(Purchase(Kauf), Providing(Bereitstellung), Contracting(Vertragsnehmer))6RollenDie Abbildung4.2veranschaulicht die einzelnenAgententypenunddie durchsiegebildetenOrganisationensowiedieKommunikationzwischenihnen.Wiezusehenist, besitztdasBeispiel 3Organisationen, jededavonistaus2Rollenzu-sammengesetzt.Purchase:DieseverwaltetdieInteraktionenzwischendemClientunddemBroker. DieHauptaufgabe liegt in der Formatierung und Weiterleitung der Client-Anfrage.Providing:DieOrganisationverwaltetdieInteraktionenzwischendemBrokerunddemProvider.Zielistes,dieAnfragevomClientanalleProviderweiterzuleiten.Contracting:SieverwaltetdieInteraktionenzwischendemClientunddemProvider, umdenKaufabzuwickeln.Dabei kann eine Organisation dynamisch als Gruppe instanziiert werden. EinAgent nimmt eine Rolle in dieser Gruppe ein. Wird also eine solche Gruppebenotigt,kanndiesebeiBedarfdurchdieAgentenerstelltwerden.46 4JanusAbbildung4.2:Market-LikeCommunity[7]4.3.2 BoidsBoids wurde 1986 als ein Computer Modell vorgeschlagen, dass koordinierte Tier-bewegungsimuliert, wiez.B. Vogel-oderFischschwarme. EswirdhauginderComputergrak (Animation und Computer Aided Design) genutzt, die eine realis-tische Darstellung von Vogeln oder anderen Lebewesen liefern. Ein Beispiel f ur dieVerwendungvonBoidsliefert dieVogelsimulationinHalfLife. DieKomplexitatderBoidsergibtsichausderInteraktiondereinzelnenAgenten(hierdenBoids).DiesefolgeneinfachenRegeln. DieRegelnbeschreibendieVerhaltenssteuerungeines Boid. Diesebeziehensichauf diePositionundGeschwindigkeit. ZudeneinfachstenRegelnzahlen:Separation(Trennung):Das bedeutet, dass der Boid eine Richtung wahlt, um eine Haufung von Boidszuvermeiden.Alignment(Angleichen):DahinterverbirgtsichdieRichtungswahl,diedermittlerenRichtungderbe-nachbartenBoidsentspricht.Cohesion(Zusammenhalt):Diese Regel beschreibt die Wahl einer Richtung, die der mittleren Position derbenachbartenBoidsentspricht.Zu diesen konnen weitere Regeln hinzugef ugt werden, z.B. die Zielsuche oder dasAusweichenvonHindernissen.DieBewegungsmusterderBoidskonneninchao-4.3PraktischeBeispiele 47tisch (zufallige Bewegung, Aufbrechen des Schwarms) und geordnet unterschiedenwerden.DasBeispielzeigtmehrereverschiedeneWolkenvonDreieckeninunter-schiedlichenFarben.AlleDreieckestellendabeidieBoids,bzw.dieAgentendar.Diesesindzunachstchaotischangeordnet.NachkurzerZeitorganisierensichdieAgentenselbstundordnensichnachFarben.NunistesdemBenutzermoglich,eineDreieckswolkeeinerbestimmtenFarbe uberdieAnwendungzulegen.BoidsgleicherFarbenahernsichderdurchdenBenutzerplatziertenWolkean, BoidsandererFarbenhingegenmeidendieAnnaherungandieplatzierteWolke.4.3.3 AntColonyDiesesBeispiel zeigtdieSimulationeinesAmeisenstaatesmitHilfeeinesMulti-agentensystems. EslieferteinemoglicheImplementierungvondemebenvorge-stelltenBoids-Konzept.DasAntColonyPrinzipEine einzelne Ameise hat kein globales Wissen uber die Aufgabe, die sie ausf uhrt.DieAktionen, welchevonder Ameiseausgef uhrt werden, basierenauf lokalenEntscheidungenundsindmeist unvorhersehbar. DasintelligenteVerhaltenent-stehtdurchdieSelbstorganisationundindirektenKommunikationzwischendenAmeisen.DenitionderUmweltDieUmweltistineinRasterzerlegt. JedeZelledesRasterskanneineKolonie,einPheromonodereineNahrungsquellesein.DasBeispielbehandeltzweiTypenvonPheromonen:DasFood-Pheromon:DiesgibtdieRichtungderNahrungsquellean.DasColony-Pheromon:DiesgibtdieRichtungderAmeisenkoloniean.DenitionderAntColonyOrganisationDie Organisation besteht aus 2 Rollen. Diese werden durch den Patroller und denForagergebildet.Patroller:Dieser lauft zufallig durch die Kolonie und verstreut dasColony Pheromon.Er kehrt zur Kolonie zur uck, wenn er abschatzt, dass seine Pheromone auf dieHalftedesUrsprungswertesgesunkensind.48 4JanusForager:Dieser sucht zufallignachFutterquellen. Wahrendder Suche wirft er dasColony Pheromon aus. Nachdem er eine Futterquelle gefunden hat, versuchter zur Kolonie zur uckzukehren mit Hilfe des Colony Pheromons. Auf dem Wegzur uckzur Koloniewirft erFood-Pheromonsaus umdieNahrungsquellespater wieder zunden. Damitermoglichter denanderenAmeisenausderKolonieebenfallsdasAundenderFutterquelle.Abbildung4.3:Ant-Colony-Application[11]DieAbbildung4.3zeigt das Beispiel ineiner graschenDarstellung. Hier sindverschiedensteFormenundFarbenzusehen.InderMittederweienKreisebe-nden sich die unterschiedlichen Kolonien. Bewegliche Ameisen sind durch gr unePunkte, unbewegliche(sesshafte)alsgelbePunktedargestellt. DierotenPunk-tezeigenFutterquellen,nachwelchendieAmeisensuchen.Zusatzlichdazusindweie und pinke Kurven zu sehen. Die weien symbolisieren den Weg derColonyPheromonesunddiepinkendesFood-Pheromones. DiePheromonewurdenalsoentlangderKurvenausgeworfen.Auch dieses Beispiel zeigt wieder die Selbststandigkeit und Eigenorganisation derAgenten. Alle Agenten (Ameisen) verfolgen einheitliche Ziele, die vorwiegend ausdemAundenderFutterquellenbestehenundlosengemeinschaftlichdieseAuf-gabe indem sie verschiedene Rollen verteilen. Jede Rolle bildet eine Teillosung derAufgabeundgemeinsamerreichensieihrZiel.4.4Schlusswort 494.4 SchlusswortAnhandder vorgestelltenBeispieleist zusehen, welchekomplexenMultiagen-tensystememitJanusumgesetztwerdenkonnen. Dabei zeigtdiesesKapitel nurgrundlegendeBegriichkeitenbzw. KonzepteundeinfacheBeispiele. Letztend-lichbildetJanuseinesehrguteAlternativezuJADE(sieheKapitel 3).Esbietetsehr viele Moglichkeiten zur Entwicklung einer Multiagentenplattform. Zudem istein solches Projekt relativ leicht vorzubereiten und durch seine groe Anzahl vor-implementierterFunktionenkonnenmitwenigAufwandsehrumfangreicheMul-tiagentensystemeentwickeltwerden.Literaturverzeichnis[1] Janus-Project,Home.http://www.janus-project.org/Home,15.12.2010.[2] Wooldridge, M., Jennings, N. R.,Intelligent agents: Theory and practice. TheKnowledgeEngineeringReview.1995.[3] Janus-Project, MavenSupport. http://www.janus-project.org/Maven:Deve-lopment,19.12.2010.[4] Janus-Project,Agent.http://www.janus-project.org/Agent,04.01.2011.[5] Reining,J.,MultiagentensystemeEinigeBeispiele.2002.[6] Wikipedia, Software-Agent. http://de.wikipedia.org/wiki/Software-Agent,17.11.2010.[7] Janus-Project, Market-like-Community. http://www.janus-project.org/Mar-ket-like-Community,07.01.2011.[8] Cossentino,M.,Gaud,N.,Hilaire,V.,Galland,S.,Koukam,A.,ASPECS:anagent-orientedsoftwareprocessforengineeringcomplexsystems.2009.[9] Janus-Project,Boids.http://www.janus-project.org/Boids,07.01.2011.[10] CraigReynolds,Boids.http://www.red3d.com/cwr/boids/,20.01.2011.[11] Janus-Project, Ants with Jaak. http://www.janus-project.org/Ants-with-Jaak,09.01.2011.50 4Janus5 FIPAStandardsMarcoKretzschmarInhaltsverzeichnis5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2 DieFIPA-Organisation . . . . . . . . . . . . . . . . . . . 525.2.1 Ziele . . . . . . . . . . . . . . . . . . . . . . . . 525.2.2 Geschichte . . . . . . . . . . . . . . . . . . . . . 525.2.3 Organisationsstruktur . . . . . . . . . . . . . . . 535.3 DieFIPA-Standards. . . . . . . . . . . . . . . . . . . . . 545.3.1 EinteilungderFIPA-Standards . . . . . . . . . . 545.3.2 LebenszyklusderSpezikationen . . . . . . . . . 555.3.3 Spezikations-Identizierer . . . . . . . . . . . . 555.4 ZweiStandardskurzvorgestellt . . . . . . . . . . . . . . 565.4.1 AgentManagementReferenceModel . . . . . . . 565.4.2 FIPAACLMessageStructure . . . . . . . . . . . 585.5 FIPA-StandardsinderPraxis. . . . . . . . . . . . . . . . 585.1 EinleitungDiepraktischeNutzungvonAgentensystemen1ist starkvonder Verf ugbarkeitinternational anerkannter Standards abhangig. Diezwei wichtigstenStandardi-sierungsorganisationenf urAgentensystemesinddieOMG(ObjectManagementGroup)unddieFIPA(Foundationfor Intelligent Physical Agents). AuchwennimNamender FIPAdieBegriePhysical Agents stehen, entwickelt diesenurStandardsf ur Softwareagenten. DieOMGhat mit ihremMASIF-Standard, dersich vordergr undig mit der Zusammenarbeit von Agentenplattformen beschaftigt,einenweitverbreiteterStandarddeniert.DagegenhabendieFIPA-StandardsinderPraxiseineweitgeringereBedeutung.TrotzdembesitzensieihreDaseinsbe-rechtigung,denndieFIPAbetrachteteinenBereichdendieOMGfastkomplettvernachlassigt:dieKommunikationzwischendenAgenten.1Ein(Software-)Agentensystembestehtausmehrerenheterogenoderhomogenen,autonomen,spezialisiertenSoftware-Agenten. Diese Software-Agentenlosenihnengestellte AufgabenimKollektiv.52 5FIPAStandardsIndiesemArtikel sollendieFIPAalsOrganisationundderenStandardsimVor-dergrundstehen.Dabei wirdimerstenKapitel aufdieZiele,GeschichteunddieOrganisationsstrukturderFIPAeingegangen. ImzweitenKapitel gehtesdarumsich einenUberblick zu verschaen in welche Ebenen sich die Standards aufteilen,welchen Lebenszyklus die Spezikationen durchlaufen und wie die Spezikationenidentiziert werden konnen. Das dritte Kapitel stellt kurz zwei wichtige StandardsderFIPAvor.ImletztenKapitel soll kurz uberdieFIPA-StandardsinderPraxisberichtetwerden.5.2 DieFIPA-OrganisationDieFIPA(Foundationfor IntelligentPhysical Agents)isteinenichtgewinnori-entierteOrganisationundbestehtderzeitaus57MitgliedernausIndustrieundForschung (Stand: Jan/2011). Darunter bekannte Firmen wie Boing, Siemens undToshiba,aberauchUniversitatenwiedieQueenMaryUniversityofLondon,dieRWTHAachenoderdieUniversitatDuisburg-Essen[1].5.2.1 ZieleZielderFIPAistes,internationalakzeptierteStandardsf urheterogeneAgenten-systemezuschaen. DadurchwirdesermoglichtdasAgentensystemevonver-schiedenenAnbieternmiteinander kommunizierenundkooperierenkonnen. DieFIPA setzt ihren Schwerpunkt dabei auf die praktisch genutzten industriellen undgewerblichenAgentensystemen,beschaftigtsichaberauchmitintelligentenundkognitivenAgenten.DieFIPAverdeutlichtdasmitihremoziellenMissionsstatement:The promotion of technologies and interoperability specications that fa-cilitate the end-to-end interworking of intelligent agent systems in moderncommercialandindustrialsettings[1].5.2.2 GeschichteDieFoundationfor Intelligent Physical Agents wurde1996inGenf gegr undet.SchoneinJahrnachderGr undungderOrganisationwurdendieerstenSpezi-kationenunterdemTitel FIPA97veroentlicht. DieseSpezikationenbefasstensichhauptsachlichmit der Agentenkommunikation, demAgentenmanagementund der Integration von Agenten. In den folgenden Jahren wurden diese StandardsweiterentwickeltundunterdemNamenFIPA98undFIPA99freigegeben. Diesebefasstensichzusatzlichmit der Sicherheit undMobilitat vonAgenten, sowie5.2DieFIPA-Organisation 53der Mensch-Agent Interaktion. Im Jahr 2000 wurde mit dem FIPA2000-Standarddas alteNamenschemaabgeschat unddurcheineneindeutigen5-stelligenCodeersetzt. Durchdieses neueSchemaist es moglichdieeinzelnenStandards un-abhangigvoneinander zuandern. Der FIPA2000Standardhat bis heute seineG ultigkeit. Im Jahr 2005 schloss sich die FIPA der IEEE Computer Society an undwurdeihrelftesMitglied[1].5.2.3 OrganisationsstrukturDieFIPAstrukturiertsichinzwei Hauptbereiche. EinBereichistf ur Finanzen,Verwaltungetc. verantwortlichundder andereBereichistf ur diePlanungundUmsetzungder Spezikationenzustandig(sieheAbbildung5.1). IndiesemAb-schnittwerdendieeinzelnenBereichederOrganisationkurzvorgestellt.Abbildung5.1:FIPA-Organisationsstruktur[1]DasBoardofDirectoristverantwortlichf urdieLeitungundDurchf uhrungderlaufendenGeschafteinder Organisation. UmnanzielleFragender FIPAunddieVerwaltungderMitgliederk ummertsichdasSecretariat.DasImageCom-mitteekoordiniertdieOentlichkeitsarbeitderFIPAunderstelltunteranderemNewsletter und Pressemitteilungen. Der Finanz- und Pr ufungsausschuss der FIPAistdas FinanceandAuditCommittee.Espr uftRechnungenunddieFinanzie-rungder FIPAundbereitetdenAudit-Berichtf ur denVerwaltungsratvor. DasMembership and Nomination Committee pr uft die Qualikation der BewerberdieMitgliedinderFIPAwerdenwollen[1].Das FIPAArchitecture Board ist eine Einrichtung innerhalb der FIPA. Siegewahrleistet die Genauigkeit und Konsistenz, sowie die Eignung der technischen54 5FIPAStandardsArbeitenderFIPA.Zusatzlich uberwachtundgenehmigtdasArchitectureBoarddieArbeitenvonFachaussch ussenunddenWorkingGroups.Die Durchf uhrung von technischen Arbeiten der FIPA ubernehmen die TechnicalCommittees.DieAufgabenwerdendurchArbeitsplanedeniertdievomArchi-tectureBoardgenehmigt wurden. DieArbeitsplaneenthaltendieBeschreibungderdurchzuf uhrendenArbeiten, sowiedenfestenBearbeitungszeitraum. Diety-pischen Aufgaben der Technical Committees sind die Entwicklung neuer oder dieAnderungenbestehenderSpezikationen.Die Working Groups der FIPA f uhren Arbeiten durch, die nicht unbedingt mit dertechnischenDenitioneinerSpezikationzutunhaben.F urdieWorkingGroupsstehendieAnwendungender AgentenplattformenunddieZusammenarbeitmitanderen Standards im Vordergrund. Wie schon bei den Technical Committees wer-denvomArchitectureBoardeingenehmigterArbeitsplanmitdurchzuf uhrendenAufgabenundeinBearbeitungszeitraumvorgegeben.ImNormalfall erstellendieWorking Groups Informationsdokumente oder andern bestehende Spezikationen.DieSpecial InterestGroupswurdeneingerichtetumHilfstatigkeiteninnerhalbderFIPAzu ubernehmen,dieimInteressederMitgliederliegen[1].5.3 DieFIPA-StandardsDie FIPA-Standards sindeine SammlungvonSpezikationen, die das Zusam-menarbeitenvonheterogenenAgentenunddenDienstendiesiereprasentierenunterst utzensollen.DieSpezikationensindinderLageeinvollstandigesMulti-agentensystemzubeschreiben.5.3.1 EinteilungderFIPA-StandardsDieFIPAStandardslassensichindreiEbenen(sieheAbbildung5.2)unterteilen.InderEbeneApplicationswerdenBeispielapplikationenvorgestelltindenendieFIPA Agenten eingesetzt werden konnen. Um die Agentendienst und Agentenum-gebungenrealisierenzukonnenwerdeninder EbeneAbstract ArchitecturediebenotigtenabstraktenArchitekturenvorgestellt[1].DieuntersteEbeneunterteilensichindiedrei Bereiche:AgentCommunication,AgentManagementundAgentMessageTransport.ImBereichAgentCommunicationwirddieKommunikation,derNachrichtentyp,sowie die Interaktionsprotokolle und Content Language deniert. Der Aufbau derAgentenplattformwirdimBereichAgentManagementbeschrieben.DerBereichAgent Message Transport ist f ur die Transportprotokolle und die DarstellungsformderNachrichtverantwortlich[1].5.3DieFIPA-Standards 55Abbildung5.2:StrukturderFIPA-Standards[1]5.3.2 LebenszyklusderSpezikationenJedeFIPA-SpezikationdurchlauftverschiedeneZustande(sieheAbbildung5.3)diesichinPreliminary,Experimental,Standard,DeprecatedundObsoleteunter-teilen.Abbildung5.3:LebenszyklusderSpezikationen[1]Der ersteStatusPreliminarybedeutet, dasseseinevorlaugeSpezikationist.Der Status Experimental sagt aus,dass die Spezikation von der FIPA schon ak-zeptiertwurde,esabernochkeineImplementierunggibt.WennmindestenseineImplementierungvorhandenist, wechseltderStatusvonExperimental zuStan-dard. Zurzeit gibt es 25 Spezikationen die den Status Standard haben. VeralteteSpezikationenbekommendenStatus Deprecatedundeinhalbes Jahr spaterObsolete[1].5.3.3 Spezikations-IdentiziererUmeineSpezikationeindeutigidentizierenzukonnenbesitztjedeSpezikati-on eine Identikationsnummer. Die FIPA verwendet dabei zum Einen interne, undzum Anderen ozelle Identikationsnummern. Die interne Identikationsnummer56 5FIPAStandardssetzt sichaus demStatus des Lebenszyklus, demTypundeiner DokumentenNummer zusammen. Diese Identikationsnummernsindf ur die Entwickler ge-dacht, dadieseNummerndenaktuellenStatus unddenTypder Spezikationerkennenlassen. AlsBeispiel dienendieinTabelle5.1dargestelltenIdentikati-onsnummernXI00081undSC00033.SpezikationsIdentizierer ErklarungXI00081 X=Status:Experimental;I=Typ:informativ;00081=DokumentennummerSC00033 S=Status:Standard;C=Typ:Komponente;00033=DokumentennummerTabelle5.1:IdentikationsnummernDieozellenIdentikationsnummern, welcheunter andereninexternenDoku-mentenverwendetwerden,setztsichausdemOrganisationsnamenundderDo-kumentennummer zusammen. Die in der Tabelle genannte Spezikationen w urdenalsooziellFIPA00081undFIPA00033heien.5.4 Zwei StandardskurzvorgestelltIn diesem Abschnitt soll auf zwei zentrale Bestandteile der FIPA-Standards einge-gangenwerden.ZumEinenaufdasAgentManagementPreferenceModel,zumAnderen auf die FIPA ACL Message Structure. Beide werden nur kurz vorgestelltundkonnendetailliertaufderHomepagewww.FIPA.orgnachgelesenwerden.5.4.1 AgentManagementReferenceModelDas Agent Management Reference Model beschreibt eine Umgebung, in der Agen-tenexistierenundoperierenkonnen.DasModelistinderSpezikationSC00023vom 18.03.2004 deniert und ermoglicht das Erstellen, Registrieren, Lokalisieren,KommunizierenundMigrierenvonAgenten.DieStrukturderAgentenplattformwirdinAbbildung5.4verdeutlicht.DasGesamtsystemistdieAgentenplattformundbestehtausmehrerenKompo-nenten. Der Agent spielt dabei eine zentrale Rolle, er kann selbst Dienste anbietenund nutzen. Aber auch mit anderer Software oder dem Benutzer interagieren [2].MitHilfedesAgentIdentier(AID)konnenAgentenaufderPlattformeindeu-5.4ZweiStandardskurzvorgestellt 57Abbildung5.4:StrukturderFIPAStandards[2]tigidentiziertwerden.DerNamederimAgentIdentierenthaltenistkannausverschiedenenKombinationenbestehen, wiez.B. demlokalenNamenundderPlattformadresse.Mit Software sind alle Nicht-Agenten gemeint. Es handelt sich hierbei um Softwa-resammlungendiez.B.dasHinzuf ugenvonDiensten,ProtokollenoderAlgorith-men ermoglichen. Das Agent Management System (AMS) verwaltet die Agentender Plattform. NachdemeinAgent erzeugt wordenist, muss er sichimAMSregistrierenunderhalt dadurchseine AID. Das AMGkontrolliert anschlieenddieUbergange im Lebenszyklus-Modell des Agenten. Wenn die Agentenplattformauch mobile Agenten unterst utzt, muss sich das AMS ebenfalls darum k ummern.EineoptionaleKomponentederPlattformistderDirectoryFacilitator(DF).DerDFbietetf ur AgenteneinenGelbeSeiten-Dienstan, wobei sichjeder AgentmitseinemDienstdortanmeldenkann.Will einAgenthingegennurdenDienstnutzen, kannerdurcheineSuchanfrageerfahren, welcherAgentdengesuchtenDie