Verteilte Systeme 2010

Verteilte Systeme
Oliver BRAUN
Rene BROTHUHN
Ronny SCHLEICHER
(Hrsg.)
Fakultat Informatik
Fachhochschule Schmalkalden
Wintersemester 2010/2011
Vorwort
Die Entwicklung groerer Softwaresysteme ber uhrt in der heutigen Zeit sehr haug
das Gebiet der verteilten Systeme. Dabei ist es ganz unerheblich ob die Systeme
tatsachlich auf unterschiedlichen Ressourcen verteilt sind oder nur entsprechende
Technologien genutzt werden. Eine sehr vielversprechende Abstraktion beispiels-
weise bieten die Actors. Das sind Softwarekomponenten, die eigenstandig arbei-
ten und ausschlielich uber asynchrone Kommunikation miteinander interagieren
konnen. Aber auch viele andere Ansatze sind sehr interessant und wert etwas
genauer betrachtet zu werden. Ein gutes theoretisches Fundament ist ein we-
sentlicher Aspekt einer Vielzahl solcher Ansatze. Dar uber hinaus entscheidet die
Nutzbarkeit eines bestimmten Frameworks in der Regel dar uber, ob es in einem
Projekt genutzt werden soll.
Verteilte Systeme ist einer der Schwerpunkte im Masterstudiengang ,,Media Pro-
cessing and Interactive Services an der Fakultat Informatik der Fachhochschule
Schmalkalden. Im ersten Durchlauf des 4-semestrigen Studienganges vom Winter-
semester 2009/2010 bis Sommersemester 2011 war die weiterf uhrende Vertiefung
eine Pichtveranstaltung f ur alle Studierende und wurde im Seminarstil 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 musste
jeder eine etwa zehn DIN A5-Seiten umfassende Ausarbeitung erstellen. Um die
zum groten Teil sehr guten Arbeiten einem groeren Personenkreis verf ugbar zu
machen, werden sie in diesem Buch veroentlicht.
Da die einzelnen Kapitel weit uber das gesamte Feld der verteilten Systeme ver-
streut sind, haben wir versucht sie einigermaen sinnvoll in 5 Teile aufzuteilen.
Den Beginn machen Beispiele f ur die Nutzung von Agenten und Aktoren in Teil I.
Anschlieend wird ein Teil der zugrundeliegenden Prozesstheorie und die unmit-
telbare Umsetzung in der Programmierung vorgestellt. Teil III beschaftigt sich
mit Technologien zur Interaktion von Prozessen, wie sie auf vollig verschiedenen
Plattformen genutzt werden. Eine aktuelle Technologie, die Web Services, sind
Gegenstand von Teil IV. Schlielich gibt es noch einen kurzen Einblick in Grid-,
Cluster- und Monitoringtechnologien in Teil V.
Oliver Braun
Rene Brothuhn
Ronny Schleicher
Schmalkalden, August 2011
IV
Inhaltsverzeichnis
I Aktoren und Agenten 1
1 Akka Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Florian Schuhmann
2 Akka Hands on . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Toralf Mende
3 Java Agent DEvelopment Framework . . . . . . . . . . . . . . . 25
Tobias Gartner
4 Janus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Rene Kassel
5 FIPA Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Marco Kretzschmar
II Prozesstheorie und unmittelbare Umsetzung 61
6 Communicating Sequential Processes . . . . . . . . . . . . . . . 63
Wenqi Yan (Rene Brothuhn)
7 -Kalk ul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Rene Brothuhn
8 Concurrency in Go . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Benjamin L udicke
9 Communicating Sequential Processes f ur Java . . . . . . . . . . 101
Martin Engel
VI Inhaltsverzeichnis
III Interprozesstechnologien 111
10 Interprozesskommunikation mit COM . . . . . . . . . . . . . . . 113
Ronny Schleicher
11 HawtDispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Tobias Gieler
12 Distributed Programming in Mozart . . . . . . . . . . . . . . . . 139
Sebastian Stallenberger
13 ZeroMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Christopher Ezell
14 Remote Function Call in SAP-Systemen . . . . . . . . . . . . . . 165
Sebastian Reidemeister
IV Web Services 175
15 Web-Services-Architektur . . . . . . . . . . . . . . . . . . . . . . 177
Sebastian Leisen
16 Apache CXF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Martin Herrmann
V Grid, Cluster und Monitoring 203
17 Globus Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Martin Baumbach
18 Apache Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Thomas Hohn
19 Monitoring Distributed Real-Time Systems . . . . . . . . . . . . 227
Maik Heller
Teil I
Aktoren und Agenten
1 Akka Grundlagen
Florian Schuhmann
Inhaltsverzeichnis
1.1 Akka Das Framework . . . . . . . . . . . . . . . . . . . 3
1.2 Features und Methodiken . . . . . . . . . . . . . . . . . . 4
1.2.1 Actors . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Software Transactional Memory . . . . . . . . . . 9
1.2.3 Fault-tolerance . . . . . . . . . . . . . . . . . . . 10
1.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1 Akka Das Framework
Akka ist ein Open-Source-Projekt von Jonas Boner. Die Firma Scalable Solutions
bietet Consulting zu Akka und kostenpichtige Erweiterungen wie
Akka Cloud,
Akka Advanced und
Akka Monitoring & Management an.

Akka ist derzeit in der Version 1.0RC3 verf ugbar und steht damit kurz vor der
Veroentlichung der Version 1.0. Weiterhin bietet Akka eine API f ur Scala und
Java sowie eine sehr gute Dokumentation mit vielen Beispielen.
Das Framework kann auf zwei unterschiedliche Weisen genutzt werden. Einmal
als Stand-Alone-Version, wenn der Mikrokernel genutzt wird, oder als Erweite-
rungsbibliothek, welche bspw. in Eclipse-Projekte eingebunden werden muss.
Als Leitbild der Entwickler ist folgendes Zitat von Jonas Boner zu verstehen:
Writing correct concurrent, fault-tolerant and scalable applications is too

hard. Most of the time its because we are using the wrong tools and the
wrong level of abstraction. Akka is an attempt to change that [2].
Das Schreiben von nebenlaugen, fehlertoleranten und skalierbaren Program-
men ist sehr schwer und genau dieses Problem wollen die Entwickler mit Akka
losen. Die Idee hinter diesem Framework ist, dass das Abstraktionslevel, wel-
ches f ur die Programmierung benotigt wird, erhoht werden soll um leichter ne-
benlauge, fehlertolerante und skalierbare Applikationen erstellen zu konnen. Die
Erhohung der Abstraktion wird durch das Zusammenspiel des Actor-Modells
4 1 Akka Grundlagen
mit Software Transactional Memory erreicht. Die Entwickler haben sich f ur
das
Let it Crash-Modell als Strategie f ur die Fehlertoleranz in Akka ent-

schieden. Akka implementiert also eine einzigartige Mischung von Methodiken,
Abbildung 1.1: Akka-Architektur
1
welche aus Erlang stammt und
im folgenden Abschnitt vorgestellt
wird.
Abbildung 1.1 zeigt die Architek-
tur des Frameworks. Es ist in Core
Services, Add-on Module und En-
terprise Module eingeteilt. Der l.u.
dargestellte Core enthalt Techni-
ken f ur die Skalierbarkeit, Fehler-
toleranz und Nebenlaugkeit. Die-
se werden durch Add-ons (l.o.)
bspw. f ur REST, Spring, Mon-
goDB oder Cassandra erganzt. Die
Enterprise Module (r.o.) zahlen zu
den kostenpichtigen Erweiterun-
gen der Firma Scalable Solutions.
Wie die Darstellung zeigt, ist Ak-
ka, trotz der kurzen Zeit seit der
es verf ugbar ist, ein sehr umfang-
reiches Framework. Dies verdankt
Akka nicht nur Jonas Boner, son-
dern auch der bereits sehr groen
Entwicklergemeinde.
1.2 Features und Methodiken
Im ersten Abschnitt wurde das Akka-Framework im Allgemeinen vorgestellt. In
diesem Abschnitt folgen technische Details zu den verwendeten Methodiken. Hier-
bei handelt es sich um Grundlagen zu den Themen Actor-Modell, Software Tran-
sactional Memory und Fault-Tolerance.
1.2.1 Actors
Um sich dem Thema der nebenlaugen Berechnung mit Actors nahern zu konnen,
werden im Folgenden die Probleme des Multithreadings angesprochen.
1
Eigene Darstellung in Anlehnung an [3]
1.2 Features und Methodiken 5
Probleme beim Multithreading
Reproduzierbarkeit von Fehlern
Fehler, die in einer Menge von Threads auftreten, sind oft schwer nachzuvoll-
ziehen, da das entsprechende Programm durch unterschiedliche Systembedin-
gungen moglicherweise immer wieder anders ausgef uhrt wird.
Inkonsistenzen
Schreibe- und Leseoperationen m ussen synchronisiert werden, sonst konnen
Widerspr uche in den Daten auftreten.
Deadlocks
Wenn eine Menge von Prozessen vorhanden ist und jeder dieser Prozesse
auf ein Ergebnis wartet, das von einem anderen Prozess aus dieser Menge
bereitgestellt werden soll, entstehen Deadlocks.
Starvation
Starvation tritt auf, wenn zwei Prozesse auf Ressourcen zugreifen wollen, die
der jeweils andere Prozess f ur sich beansprucht.
Zur Losung dieser Probleme m ussen zu allererst die kritischen Abschnitte in der
Applikation identiziert werden. Bei dieser Sichtung kommt es auf das richtige
Ma an, denn wenn zu viele Abschnitte als kritisch gekennzeichnet werden, be-
deutet dies, dass viele Threads warten m ussen und die Parallelitat verloren geht.
Nach dieser schwierigen Aufgabe konnen verschiedene Techniken, wie Locks, Con-
ditions, Blocking Queues oder Synchronized, eingesetzt werden, um die Probleme
beim Multithreading mehr oder weniger in den Gri zu bekommen.
Um diesen Problemen aus dem Weg zu gehen, nutzt Akka das Actor-Modell sowie
das Konzept des Software Transactional Memory. Durch diese Verfahren wird das
Abstraktionslevel erhoht und der Entwickler muss sich um die oben genannten
Probleme keine Gedanken mehr machen.
Das Actor-Modell
Das Actor-Modell ist ein mathematisches Modell f ur nebenlauge Berechnungen.
Es wurde im Jahr 1973 erstmals von Carl Hewitt im Paper
A Universal Modu-
lar Actor Formalism for Articial Intelligence beschrieben. Das Modell gewann
durch die Sprache Erlang an Popularitat. Erlang gehort zu den funktionalen Pro-
grammiersprachen und folgt im Bereich der Nebenlaugkeit den Prinzipien des
Actor-Modells.
In diesem Modell gilt das Grundprinzip:
everything is an actor. Weiterhin sind

Actors von Natur aus nebenlaug und ihre Kommunikation ndet asynchron und
nur uber Nachrichten statt.
6 1 Akka Grundlagen
Ein Actor kann als Reaktion auf eine empfangene Nachricht (parallel):
eine endliche Anzahl von Nachrichten an andere Actors senden,
eine endliche Anzahl neuer Actors erstellen,
f ur die nachste Nachricht ein bestimmtes Verhalten festlegen.
Die Identizierung der Actors erfolgt uber eine sogenannte Mailing-Adresse. Ein
Actor kennt nur andere Actors die er entweder:
selbst erzeugt oder
von denen er Nachrichten erhalten hat.
Wie man an diesen Beschrankungen sieht, spielt in diesem Modell die Kapse-
lung eine groe und wichtige Rolle. Es ist somit abzusehen, dass auch Zustande
nicht geteilt werden. Ein Actor kann den Zustand eines anderen Actors nur
uber das Versenden von Nachrichten beeinussen. Der Empfanger nimmt die
Zustandsanderung aber selbst vor.
Akka Actors
Die in Akka verwendete Implementierung des Actor-Modells ist eine Parallelent-
wicklung zu den in Scala genutzten Actors. In den letzten Versionen von Scala
wurden die Ideen der Akka Actors teilweise mit in die Standardbibliothek der
Programmiersprache aufgenommen. Das API der Akka Actors ist daher ahnlich
der Scala Actors. Beide Implementierungen orientieren sich weiterhin sehr stark
an die Syntax von Erlang und nutzen einen expliziten Message Handler, welcher
ein Pattern Matching auf alle empfangenen Nachrichten anwendet. Beim Pat-
tern Matching der receive-Methode der Akka Actors ist darauf zu achten, dass
alle moglichen Nachrichten, die empfangen werden konnten, behandelt werden
m ussen.
Die Akka Actors konnen auf die zwei folgenden Weisen implementiert werden:
Der leichteste und k urzeste Weg, um einen Akka Actor zu implementieren ist
die actor Methode. Hierbei wird ein anonymer Actor erzeugt, welcher implizit
gestartet wird. Die Implementierung des Message Handlers erfolgt direkt uber
das dargestellte Pattern Matching (Listing 1.1).
import akka.actor._
val myActor = actor {
case "test" => println("received test")
case _ => println("received unknown message")
}
Listing 1.1: Erstellen eines anonymen Actors [1]
Eine Alternative ist die Erstellung einer Klasse, welche von der Actor-Klasse
aus Akka abgeleitet ist und die receive-Methode implementiert. Um den
erstellten Actor zu starten, muss explizit die start-Methode des Actors auf-
gerufen werden (Listing 1.2).
class MyActor extends Actor {
def receive = {
case "test" => println("received test")
case _ => println("received unknown message")
}
}
val myActor = Actor.actorOf[MyActor]
myActor.start
Listing 1.2: Erstellung eines Actors uber Vererbung [1]
Der Aufruf der Factory-Methode actorOf liefert eine Instanz von ActorRef
zur uck. Dies ist ein neues Konzept, welches seit der Version 0.9 in Akka ent-
halten ist. Die Erzeugung eines Actors, wie in Listing 1.3 dargestellt, erfolgt nun
nicht mehr uber den Aufruf mit new, sondern uber die bereits erwahnte Factory-
Methode.
val a = new MyActor
a ! msg
Listing 1.3: Einen Actor mit
newerstellen [1]
Die dabei erhaltene Instanz der ActorRef muss genutzt werden, um mit dem
eigentlichen Actor zu interagieren (Listing 1.4).
Durch dieses Vorgehen wird eine Actor-Referenz erzeugt, welche serialisierbar,
unveranderlich und network-aware ist. Das heit, diese Referenz kann ohne Pro-
bleme uber das Netzwerk verteilt werden. Dabei merkt sie sich ihre Herkunft und
kann wie gewohnt und ohne zusatzlichen Aufwand genutzt werden.
val a = actorOf[MyActor]
a ! msg
Listing 1.4: ActorRef erstellen [1]
8 1 Akka Grundlagen
Die Nachrichten ubermittlung ist die Interaktionsmoglichkeit zwischen den Actors.
Diese sammeln ihre Nachrichten in einer sogenannten
ordered message queue

und arbeiten die Nachrichten nacheinander ab. Im Folgenden werden die drei
moglichen

Ubermittlungsarten der Akka Actors aufgezeigt.
re-and-forget
Hierbei handelt es sich um die einfachste

Ubermittlungsart. Eine Nachricht
wird an einen Actor gesendet und der Sender wartet nicht auf eine Antwort,
sondern er arbeitet direkt weiter.
myActor !"test"
Send-And-Receive-Eventually
Bei dieser Art der Nachrichten ubermittlung wird eine Nachricht gesendet und
es wird eine bestimmte Zeit auf eine Antwort gewartet. Diese Methode gibt
ein Option[Any] zur uck, welches beim Erhalt einer Antwort Some(result)
ist oder beim Erreichen des Timeouts None enthalt.
val resultOption = actor !!("Hello", 1000)
Send-And-Receive-Future
Dieses Vorgehen liefert ein Future zur uck, wobei hier beachtet werden muss,
dass kein Timeout angegeben wird. Falls also keine Antwort eintrit, konnten
weitere Bearbeitungsschritte, die auf das Future angewiesen sind, nicht durch-
gef uhrt.
val future = actor !!!"Hello"
Der letzte, aber dennoch entscheidende Punkt, der hier angesprochen werden
soll, ist die Wahl des Dispatchers. Dieser entscheidet uber die Art des Actors. So
konnen entweder event-basierte oder thread-basierte Actors erstellt werden. Hier
eine kleine Aufzahlung der moglichen Dispatcher.
Thread-based
Event-based
Work-stealing
HawtDispatch-based event-driven
Die Actors sind damit ein Kernbestandteil von Akka und das zurecht, wie folgen-
des Beispiel der Entwickler zeigt:
Ein event-basierter Actor ist ca 600 Byte gro. Dies bedeutet, dass auf einem PC
mit 4 GB Arbeitsspeicher circa 6.5 Millionen Actors erstellt werden konnten.
1.2.2 Software Transactional Memory
Das Konzept des Software Transactional Memory ist ein Kontrollmechanismus f ur
gemeinsam genutzten Speicher. Der Hauptspeicher eines Rechners wird zu einer
Art Datenbank oder zu einem
transactional data set [1]. STM implementiert

die ersten drei Buchstaben des ACID-Konzeptes aus der Datenbankwelt.
A Atomaritat - Eine Transaktion wird ganz oder garnicht ausgef uhrt.
C Konsistenz - Eine Transaktion hinterlasst einen konsistenten Datenbestand.
I Isolation - Transaktionen beeinussen sich nicht gegenseitig.
D Dauerhaftigkeit -

Anderungen bleiben dauerhaft erhalten.
Die Dauerhaftigkeit macht im Arbeitsspeicher nat urlich keinen Sinn.
Durch die Integration dieses Konzeptes in die Programmierung konnen Transak-
tionen wie in Datenbanken durchgef uhrt werden. Das heit, es gibt die Moglichkeit
von
begin,
commit,
abort und
rollback nun auch im Speicher. Somit

konnten viele Actors auf dem selben Teil des Speichers lesen und schreiben. Falls
dabei ein Konikt zwischen zwei Transaktionen entsteht, werden diese einfach
abgebrochen und neu ausgef uhrt.
Einfach abgebrochen bedeutet in diesem Zu-

sammenhang, dass es ein Rollback gibt und der Speicher in den Zustand gebracht
wird, bevor die Transaktionen gestartet wurden.
Die STM-Implementierung von Akka basiert auf den Ideen von Clojure. Sie setzt
Managed References ein, welche auf einen Teil des Speichers referenzieren und
einen unveranderlichen Wert enthalten. STM verwaltet den Zugri auf diese Re-
ferenzen.
Daher besteht beispielsweise die Moglichkeit eine Datenstruktur in einer lokalen
Anwendung mit Actors zu nutzen. Ein derartiger Zugri ist normalerweise nur
mit groerem Aufwand (bspw. uber Locking) moglich und eronet dabei auch
Gefahrenquellen.
Ein weiteres Einsatzgebiet ist das allseits beliebte Bankbeispiel. Wenn hierbei
Actors genutzt werden, m ussten die internen Actor-Zustande angepasst werden.
Da dies nur uber Nachrichten moglich ist, m ussten an alle Actors Nachrichten
versendet werden. Bei diesem Beispiel m usste dies aber atomar erfolgen und somit
entsteht eine riesige Transaktion.
STM hat den Vorteil, dass es ein sehr optimistischer Ansatz ist. Es blockiert nur
die nicht lesenden und f uhrt alle schreibenden Zugrie, die ohne Konikte ablau-
fen, bis zum Commit aus. Dadurch entsteht ein hoher Grad an Parallelisierung.
10 1 Akka Grundlagen
Transactors
Akka bietet die Moglichkeit Software Transactional Memory und die Actors zu
kombinieren. Dabei entsteht ein Transactor, was soviel heit wie Transactional
Actor. Dies ist der Versuch, die Eigenschaften der Actors mit denen von STM zu
verbinden. Somit konnte ein atomarer Nachrichtenuss, wie im vorigen Beispiel
beschrieben, erstellt werden.
1.2.3 Fault-tolerance
Die Entwickler des Akka-Frameworks haben auch an die Fehlertoleranz von
k unftigen Anwendungen gedacht. Sie nutzen hier das
Let it crash-Modell. Die-

ses wird in der Telekommunikationsindustrie mit groem Erfolg eingesetzt um
Anwendungen zu erstellen, die sich selbst wiederherstellen konnen. Die Entwick-
ler haben es wie folgt formuliert:
look at errors as something natural and something that will happen and
instead of trying to prevent it; embrace it [1]
Es geht darum, bei der Entwicklung von Anwendungen Fehler mit einzubeziehen,
sie sollen sogar bereitwillig angenommen werden. Denn es wird sie so oder so
geben.
Die daraus resultierende Mentalitat und das
Let it crash-Modell sind in Akka bei

dem Umgang mit Fehlern eingeossen. Exceptions, die in einem Actor geworfen
werden, sind meist nicht hilfreich. Eine geworfene Exception w urde den Thread,
in dem der Actor lauft, nur unnotig aufblahen und es konnte auch nur im Stack
Trace herausgefunden werden, dass uberhaupt etwas schief gelaufen ist.
Einen besseren Weg bietet hier Akka durch die Moglichkeit Actors zu verlinken.
So konnen Sets von Actors erstellt werden. Diese Sets bieten Sicherheit uber
die Zustande (dead / alive) der einzelnen Actors. Es besteht die Moglichkeit
Supervisor Hierarchien aufzubauen (siehe Abbildung 1.2).
Abbildung 1.2: Akka Supervisor Hierarchie
1.3 Fazit 11
Der Supervisor hat die Moglichkeit, die ihm unterstellten Actors zu starten, zu
stoppen und zu beobachten. Hierbei bietet Akka die zwei folgenden Restart-
Strategien an.
OneForOne
Falls diese Strategie genutzt wird und ein Fehler bei einem Actor auftritt, wird
nur dieser Actor neu gestartet. Durch diesen Neustart wird das System wieder
in einen stabilen Zustand gebracht.
AllForOne
Bei dieser Strategie wird nicht nur der fehlerhafte Actor neu gestartet, sondern
alle Actors, die dem Supervisor unterstellt sind. In diesem Fall w urde auch
ein unterstellter Supervisor neu gestartet werden. Der Ausgangszustand ist
in Abbildung 1.2 zu sehen, das beschriebene Verhalten von
AllForOne in
Abbildung 1.3. Durch eine derartige Schachtelung konnen komplexe Netze
von Actors verwaltet werden.
Abbildung 1.3:
AllForOne in einer Hierarchie (restart all)

1.3 Fazit
Das Akka-Framework bietet gute Konzepte und viele weitere Ideen zur parallelen
Programmierung. Die Entwicklergemeinde rund um Jonas Boner ist sehr aktiv
und veroentlicht in kurzen Intervallen nicht nur Bugxes und kleine Updates,
sondern auch grundlegende Neuentwicklungen und Erweiterungen zum bestehen-
den Framework. Durch die sehr gute Dokumentation und die angebotenen APIs
f ur Java und Scala fallt die Einarbeitung sehr leicht. Abschlieend ist zu sagen,
dass Akka ein sehr leicht verstandliches und exibles Framework ist, welches in
Zukunft sicher noch oft im Gesprach sein wird.
12 1 Akka Grundlagen
Literaturverzeichnis
[1] Scalable Solutions, Akka Homepage. http://www.akka.io, 2011.
[2] Jonas Boner, Introducing Akka. 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] Jonas Boner, Akka Github. https://github.com/jboner
[6] Lothar Piepmeyer, Grundkursfunktionale Programmierung mit Scala. Carl
Hanser Verlag M unchen Wien, 2010.
[7] Christos K. K. Loverdos and Apostolos Syropoulos, Steps in Scala: An In-
troduction to Object-Functional Programming . Cambridge University Press,
2010.
[8] Oliver Braun, Scala: Objektfunktionale Programmierung. Hanser Fachbuch-
verlag, 2010.
2 Akka Hands on
Toralf Mende
Inhaltsverzeichnis
2.1 Akka - Master and Servant . . . . . . . . . . . . . . . . . 13
2.2 Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Master . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Servant . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1 Ablauf . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Akka - Master and Servant
Im Kapitel 1 wurde das Framework Akka vorgestellt, in welchem grundlegende
Features wie Actors und Faulttolerance erlautert wurden. In diesem Kapitel soll
nun anhand eines Beispiels die Programmierung mit dem Java-API des Akka-
Frameworks demonstriert werden. Die benotigten Akka-Module werden als Er-
weiterungsbibliotheken in das Projekt eingebunden. Dadurch ist es moglich, Akka
Actors (im folgenden Actors) in einem Java-Projekt zu nutzen. In diesem Beispiel
werden zwei Arten von Actors implementiert. Einer dieser Actors (Master) wird
andere Actors (Servants) kontrollieren, ihnen Nachrichten schicken und sie erneut
starten, wenn sie ausfallen. Dazu werden verschiedene Typen von Nachrichten,
welche zwischen den Actors ausgetauscht werden, als eigene Klassen implemen-
tiert. Zum Schluss wird noch eine Main Klasse implementiert, in der ein Master
erzeugt und gestartet wird. Diesem Master werden Nachrichten gesendet, auf die
er unterschiedlich reagiert.
2.2 Nachrichten
Zuerst sollten die Typen von Nachrichten, welche zwischen den Actors ausge-
tauscht werden, deniert werden. Beim Festlegen der Nachrichten bestehen meh-
rere Moglichkeiten. Eine Moglichkeit ist es, eine einzige Nachricht zu denieren
14 2 Akka Hands on
und in dieser Attribute zu verwenden, damit der Actor, der diese Nachricht spater
empfangt, entscheiden kann, ob und wie er auf diese Nachricht reagiert. Eine ande-
re, weitaus ubersichtlichere Moglichkeit ist, f ur jede Nachricht eine eigene Klasse
zu denieren und beim empfangenden Actor den Typ der Nachricht zu pr ufen.
Diese Nachrichten sind einfache Java-Klassen, welche das Interface Serializable
implementieren. Dies ist notwendig, um die Nachrichten auch uber Rechnergren-
zen hinaus austauschen zu konnen. In diesem Beispiel ist f ur jede Nachricht eine
eigene Klasse deniert. Da diese sich alle sehr ahneln, sollen hier jedoch nur zwei
Nachrichten gezeigt werden.
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;}
}
Listing 2.1: Nachrichtenobjekt zum Starten eines Masters
Die in Listing 2.1 gezeigte Nachricht dient dazu, einem Master mitzuteilen, dass
ein weiterer Master gestartet werden soll. Diese Nachricht besitzt zwei Attribute,
die bereits beim Erzeugen einer Instanz dieser Nachricht gesetzt werden m ussen.
Zum einen muss eine ID angegeben werden, um die gestarteten Master spater
voneinander unterscheiden zu konnen, zum anderen ein String, welcher die Be-
zeichnung der Neustartstrategie beinhaltet. Die in Listing 2.2 gezeigte Nachricht
signalisiert einem Master, dass er einem ihm untergebenen Servant eine Nachricht
senden soll. Das Attribut ID beinhaltet die Bezeichnung des zu kontaktierenden
Servants.
public class ScareServant implements Serializable {
private String id = null;
public ScareServant(String id) {this.id = id;}
public String getId() {return this.id;}
}
Listing 2.2: Nachrichtenobjekt zum Erschrecken eines Servants
Neben den zwei hier gezeigten Nachrichtentypen existieren noch weitere Nachrich-
ten, beispielsweise um einen untergebenen Actor zu stoppen, einen Absturz eines
Servants zu simulieren oder eine Referenz auf einen anderen Actor anzufordern.
2.3 Actors 15
2.3 Actors
Wie bereits zu Beginn erwahnt, existieren in diesem Beispiel zwei Arten von Ac-
tors. Im folgenden Abschnitt soll auf einige Aspekte deren Implementierung ein-
gegangen werden. Hierbei wird zunachst das Erzeugen einer so genannten Fault-
HandlingStrategy sowie die

Ubergabe dieser an den FaultHander des Masters
gezeigt. Anschlieend wird gezeigt, wie Master und Servants auf verschiedene
Nachrichten anderer Actors reagieren.
2.3.1 Master
Ein Master ist ein Actor, dem andere Actors in einer Hierarchie untergeordnet sind.
Ihm konnen sowohl Servants als auch andere Master untergeordnet sein. Fallt einer
der Untergeordneten aus, so startet der Master diese entsprechend der gewahlten
FaultHandlingStrategy erneut. Damit der Master eine Neustartstrategie umsetzen
kann, besitzt er einen FaultHandler. (Listing 2.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);
} ...
Listing 2.3: FaultHandler des Masters
Der Master kann je nach Bedarf mit der OneForOne- oder der AllForOne-Strategie
(siehe Abschnitt 1.2.3) gestartet werden. Dazu wird im Konstruktor zuerst ein
neues Objekt der jeweiligen Strategie erzeugt. Beim Instanzieren des Strategie-
objekts m ussen drei Parameter angegeben werden. Als erster Parameter wird ein
Array der zu behandelnden Exceptionklassen erwartet. Der zweite und dritte Pa-
rameter gibt die maximale Anzahl der Neustartversuche an und den Zeitraum (in
16 2 Akka Hands on
Millisekunden), uber den das Neustarten versucht werden soll. Das so erzeugte
Strategieobjekt wird abschlieend dem FaultHandler des Masters ubergeben.
Kommunikation
Die Kommunikation zwischen Actors erfolgt, wie bereits im Kapitel 1 erlautert,
ausschlielich uber Nachrichten. Um auf Nachrichten reagieren zu konnen, muss
in der Klasse des jeweiligen Actors die onReceive-Methode redeniert werden. In
dieser Methode wird die Art der Nachricht gepr uft und eine Reaktion festgelegt.
Dies soll nun anhand von zwei moglichen Nachrichten gezeigt werden.
...
@Override
public void onReceive(final Object message) throws Exception {
if (message instanceof StartServant) {
final StartServant msg = (StartServant) message;
ActorRef servant = UntypedActor.actorOf(new
UntypedActorFactory() {
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);
}
...
Listing 2.4: Reaktion eines Masters auf eine StartServant-Nachricht
Der Master in diesem Beispiel reagiert, wie in Listing 2.4 gezeigt, auf eine Nach-
richt vom Typ StartServant. Dazu wird zuerst gepr uft, von welchem Typ das
empfangene Objekt ist. Handelt es sich um ein StartServant-Objekt, wird uber
eine UntypedActorFactory ein neuer Actor vom Typ Servant erzeugt. Dieser wird
anschlieend 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-
letzt wird die Referenz auf den erzeugten Servant in einer Liste gespeichert. Dies
ist notig, um dem Servant Nachrichten senden zu konnen, da ein Actor nur mit
den Actors kommunizieren kann, welche ihm bekannt sind.
Ein weiterer Nachrichtentyp, auf den der Master reagieren soll, ist die ScareSer-
vant-Nachricht (Listing 2.5). Diese wird gesendet, um ihn aufzufordern, einen
2.3 Actors 17
seiner untergeordneten Servants zu erschrecken. Da ein Master jedoch auch
selbst einem anderen Master untergeordnet sein kann, kann die Nachricht auch
von seinem Vorgesetzten empfangen werden. Das heit, der Master muss anders
auf eine solche Nachricht reagieren, wenn er selbst erschreckt wird, als wenn er
einen seiner Servants erschrecken soll. In diesem Beispiel dient das ID-Attribut im
Nachrichtenobjekt dazu, die Empfanger zu unterscheiden. Beim Empfang einer
ScareServant-Nachricht muss also zuerst gepr uft werden, ob die mit der Nachricht
ubermittelte ID der ID des Masters entspricht. Ist dies der Fall, wird der Mas-
ter lediglich eine Ausgabe in die Konsole schreiben. Entspricht die ubermittelte
ID jedoch nicht seiner eigenen, versucht der Master die Referenz auf seinen un-
tergebenen Servant mit dieser ID aus seiner gespeicherten Liste zu holen. Wenn
ein solcher Servant existiert, sendet der Master ihm eine Nachricht, um ihn zu
erschrecken. In diesem Beispiel ist das ein einfacher String. Ein String kann als
Nachricht gesendet werden, da Strings standardmaig serialisierbar sind.
...
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!");
}
}
} ...
Listing 2.5: Reaktion eines Master auf eine ScareServant-Nachricht
Call-Back-Methoden
Abschlieend soll es dem Master noch ermoglicht werden, all seine untergebenen
Servants freizugeben und zu stoppen, wenn er selbst gestoppt wird. Um das Ver-
halten eines Actors auerhalb seiner Nachrichtenbehandlung steuern zu konnen,
besitzt der UntypedActor des Akka-Frameworks folgende Callback-Methoden:
preStart() - wird ausgef uhrt bevor der Actor gestartet wird
postStop() - wird ausgef uhrt nachdem der Actor gestoppt wurde
18 2 Akka Hands on
preRestart() - wird ausgef uhrt bevor der Actor neu gestartet wird
postRestart() - wird ausgef uhrt nachdem der Actor neu gestartet wurde
Die preStart-Methode wird in diesem Beispiel nur dazu genutzt, eine Konsolen-
ausgabe zu erzeugen, die das Starten des Masters anzeigt. Die postStop-Methode
wird genutzt, um alle noch aktiven untergebenen Actors des Masters sauber zu
beenden und ihre Ressourcen freizugeben.
... @Override
public 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...");
} ...
Listing 2.6: postStop-Methode des Masters
2.3.2 Servant
Die Servants stellen die Arbeiter in diesem Beispiel dar. Allerdings beschrankt sich
das Arbeiten auf eine kurze Konsolenausgabe, nachdem sie durch eine Nach-
richt von ihrem Master dazu aufgefordert wurden. Dazu wird auch im Servant die
onReceive-Methode uberschrieben, in welcher die unterschiedlichen Nachrichten-
typen behandelt werden. Ein Servant reagiert auf drei unterschiedliche Nachrich-
ten. Auf eine Kill -Nachricht, welche von einem Master gesendet wird, reagiert
ein Servant, indem er eine Exception wirft. Dies dient dazu, den Servant zum
Absturz zu zwingen, damit der Master diesen neustarten muss. Auf eine Scare-
Servant-Nachricht reagiert der Servant, indem er sich erschrickt und dies auf der
Konsole ausgibt. Erhalt der Servant eine ShutDown-Nachricht, ruft er die stop-
Methode des UntypedActor auf, welche den Actor sauber beendet und all seine
Ressourcen wieder freigibt. Empfangt der Servant eine andere Nachricht, teilt er
dem Absender mit, dass er diese Nachricht nicht kennt.
public class Servant extends UntypedActor {
public Servant(String id) {
getContext().setId(id);
}
2.4 Main 19
@Override
public 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");
}
}
@Override
public void preStart() {
System.out.println(getContext().getId() + " ready to serve "
+ getContext().getSupervisor().getId());
}
@Override
public void postStop() {
System.out.println(getContext().getId() + " is dead");
}
}
Listing 2.7: Servant
2.4 Main
Abschlieend soll nun eine Starter-Klasse implementiert werden, welche einen
Master selbst starten wird. Diesem Master werden anschlieend Nachrichten ge-
sendet, um ihn aufzufordern, sowohl einen Master, als auch mehrere Servants
zu erzeugen und zu starten. Weiterhin werden Nachrichten an den Master gesen-
det, um untergeordnete Servants zu erschrecken. Auerdem wird der Master einen
Servant gezielt zum Absturz bringen, um zu zeigen, wie die gewahlte Neustartstra-
tegie umgesetzt wird. Zuletzt wird der Master sauber heruntergefahren, wodurch
er all seine untergeordneten Servants ebenfalls sauber stoppt, sowie deren Res-
sourcen wieder freigibt. Die Abbildung 2.1 zeigt einen schematischen Ablauf des
Programms, aus Gr unden der

Ubersicht sind darin jedoch nur ein Master und ein
Servant abgebildet.
20 2 Akka Hands on
2.4.1 Ablauf
master.start()
Servant
Master
servant.start()
StartServant()
ScareServant()
sendOneWay("Buh")
print("wah")
StopServant()
ShutDown()
stop()
StopMaster()
stop()
Abbildung 2.1: Sequenzdiagram
Als erstes werden zwei Actors vom
Typ Master erzeugt. F ur den ers-
ten Master geschieht dies uber die
Fabrikmethode actorOf(. . . ). Da
der Konstruktor des Masters Pa-
rameter erwartet, muss der Master
mit Hilfe einer Instanz von Unty-
pedActorFactory erzeugt werden.
Damit konnen Actors mit beliebi-
gem Konstruktor erzeugt werden.
Bei der Verwendung dieser Me-
thode sollte sichergestellt werden,
dass niemand eine Referenz auf
die Instanz des Actors erhalt. Da uber die Referenz der Status des Actors direkt
beeinusst werden kann, konnen Race-Conditions entstehen. In diesem Beispiel
sollen jedoch auch Nachrichten direkt an einen Actor gesendet werden, welcher
von einem Master erzeugt und gestartet wurde. Dazu kann eine GetRefTo(. . . )-
Nachricht an einen Master gesendet werden, um eine Referenz auf einen seiner
Untergebenen zu erhalten. Durch das Senden einer solchen Nachricht an einen
Master 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 Master2
senden zu konnen, wird als nachstes von Master1 durch das Senden einer Ge-
tRefTo(. . . )-Nachricht eine Referenz auf den zuvor erzeugten und gestarteten
Master2 angefordert. Als nachstes werden an die beiden Master je drei Nachrich-
ten gesendet, um sie aufzufordern, neue Servants zu erzeugen und zu starten.
Abbildung 2.2 zeigt die dadurch entstehende Hierarchie.
Zuletzt werden dann folgende Nachrichten an Master1 und Master2 gesen-
det. Master2 erhalt eine Auorderung, einen seiner untergeordneten Servants
zu stoppen. Dadurch wird der entsprechende Servant sauber heruntergefah-
ren und seine Ressourcen werden wieder freigegeben. Als nachstes wird Mas-
ter1 aufgefordert, einen seiner Servants zu erschrecken. Nach Erhalt dieser
ScareServant-Nachricht wird Master1 seinem Servant eine Nachricht schicken,
wodurch der Servant sich erschrickt und dies auf der Konsole ausgibt. Zu-
letzt wird eine RestartServant-Nachricht an Master2 gesendet. Bei Empfang
einer solchen Nachricht reagiert der Master, indem er eine Kill -Nachricht
2.4 Main 21
M1
M2 S1.1 S1.2 S1.3
S2.1 S2.1 S2.1
Abbildung 2.2: entstehende Hierarchie
an den entsprechenden Servant sen-
det. Der Servant wiederum reagiert
auf diese Nachricht, indem er eine Ex-
ception wirft. Dieses Verhalten dient
dazu, den Servant zum Absturz zu
zwingen, um die Neustartstrategie des
Masters zu veranschaulichen. In die-
sem Beispiel setzt der Master2 die
AllForOne-Strategie um. Das heit, er
wird alle ihm untergeordneten Ser-
vants neustarten, nachdem einer aus-
gefallen ist. Master1 hingegen w urde lediglich den ausgefallenen Servant erneut
starten, da er die OneForOne-Strategie umsetzt.
public class Starter {
private static ActorRef master1 = null;
private static ActorRef master2 = null;
public static void main(String[] agrs) {
master1 = UntypedActor.actorOf(new UntypedActorFactory() {
@Override
public UntypedActor create() {
return new Master("Master1", "OneForOne");
}
}).start();
master1.sendOneWay(new StartMaster("Master2", "AllForOne"));
master2 = (ActorRef) master1.sendRequestReply(new
GetRefTo("Master2"));
for (int i = 1; i <= 3; i++) {
master1.sendOneWay(new StartServant("Servant1." + i));
master2.sendOneWay(new StartServant("Servant2." + i));
}
master2.sendOneWay(new StopServant("Servant2.2"));
master1.sendOneWay(new ScareServant("Servant1.2"));
master2.sendOneWay(new RestartServant("Servant2.1"));
master1.stop();
}
}
Listing 2.8: Starter-Klasse
Mit master1.stop() wird abschlieend der Master1 heruntergefahren. Dabei wird
seine postStop-Callbackmethode ausgef uhrt. worin all seine untergeordneten Mas-
ter und Servants ebenfalls sauber beendet werden, wie im Abschnitt 2.3.1
22 2 Akka Hands on
erlautert. Listing 2.9 zeigt abschlieend die Konsolenausgabe des Beispielpro-
gramms Master and Servant.
Master1 is starting up
Master1 starting Master2
Master2 ready to serve Master1
Master2 starting Servant2.1
Servant1.1 ready to serve you Master1
Master2 releasing Servant2.2
Master1 says Boo! to Servant1.2
>>> Master2 restarting Servant2.1
Servant1.2:Wah!
Servant2.2 is dead
>>> [akka:event-driven:dispatcher:global-6] [ERROR]...Exception when
invoking...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 Master2
Listing 2.9: Konsolenausgabe
Literaturverzeichnis 23
[1] Scalable Solutions, Akka - Untyped Actors, http://www.akka.io/untyped-
actors-java,2011.
24 2 Akka Hands on
3 Java Agent
DEvelopment
Framework
Tobias Gartner
Inhaltsverzeichnis
3.1 Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Das Agentenparadigma . . . . . . . . . . . . . . . . . . . 26
3.3 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Also was ist JADE? . . . . . . . . . . . . . . . . . . . . . 28
3.5 Die Architektur von JADE . . . . . . . . . . . . . . . . . 29
3.6 Entwickeln mit JADE . . . . . . . . . . . . . . . . . . . . 30
3.6.1 Die Agentenklasse . . . . . . . . . . . . . . . . . 30
3.6.2 Verhalten von Agenten . . . . . . . . . . . . . . 31
3.6.3 Agentenkommunikation . . . . . . . . . . . . . . 33
3.6.4 Namen und Namensdienst . . . . . . . . . . . . . 35
3.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . 36
Das Java Agent DEvelopment Framework, kurz JADE, lasst sich als eine Midd-
leware zur Entwicklung und Ausf uhrung von Peer-to-Peer -Anwendungen denie-
ren, die auf dem Agentenparadigma basieren und nahtlos miteinander interagieren
konnen. Dazu ist es notwendig, diese Begrie etwas genauer zu betrachten.
3.1 Peer-to-Peer
Das Client-Server-Modell ist das Referenzmodell, das weitreichend bekannt ist
und 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 verteilten
Systems an. Sie konnen aber keinerlei Initiative ergreifen, da sie stets nur auf einen
Aufruf durch einen Klienten warten. Diese liegt bei den Klienten. Sie greifen auf
26 3 Java Agent DEvelopment Framework
die angebotenen Dienste zu, was meist aufgrund von Nutzeranfragen notwendig
wird. Klienten bieten sonst aber keinerlei zusatzliche Fahigkeiten in dem verteilten
System.
Klienten konnen dem verteilten System jederzeit beitreten und es wieder verlas-
sen und konnen dabei in einem bestimmten Rahmen beliebige Netzwerkadressen
haben. Die Server hingegen operieren an einer festen bekannten Adresse und ihre
Prasenz muss garantiert sein. Die Klienten kommunizieren mit dem Server, aber
nie untereinander.
Das Internet ist ein typisches Beispiel f ur eine Anwendung basierend auf dem
Client-Server-Modell. Die Webseiten werden von den Webservern angeboten und
die Browser sind die Klienten die mit den Servern interagieren, um ihren Nutzern
die Inhalte darzustellen.
Im Peer-to-Peer-Modell gibt es keine Unterscheidung von Rollen mehr und jeder
Peer besteht aus einer Mischung aus Initiative und Dienstangebot. Jeder Peer
kann die Kommunikation initiieren oder Adressat der Kommunikation sein. Die
Anwendungslogik ist nicht in einem Server konzentriert, sondern auf alle Peers
im Netzwerk verteilt. Dabei konnen die Peers jederzeit einander entdecken, dem
Netzwerk beitreten und verlassen. Das System und die Dienstleistung ist komplett
zwischen den gleichberechtigten Peers verteilt.
Ein wichtiger Unterschied ist also, wie die Kommunikationspartner entdeckt wer-
den konnen. In einem Client-Server-System m ussen die Klienten den Server, aber
nicht die anderen Klienten kennen, da diese nie direkt untereinander kommunizie-
ren. In Peer-to-Peer-Systemen muss es hingegen einen Mechanismus geben, der
es erlaubt, dem Netzwerk beizutreten, es zu verlassen und, einer Art Telefonbuch
gleich, Peers mit ihren angebotenen Fahigkeiten zu nden.
Auf diesen Fakten basierend lassen sich zwei Peer-to-Peer-Netzwerkmodelle un-
terscheiden: reine Peer-to-Peer-Netzwerke und hybride Peer-to-Peer-Netzwerke.
Reine Peer-to-Peer-Netzwerke sind komplett dezentralisiert und ihre Peers arbei-
ten komplett autonom. Ohne einen festen Index ist es schwierig, die Koharenz des
Netzwerkes zu wahren und Peers zu entdecken. Die hybride Architektur hinge-
gen setzt einen speziellen Index ein, der einen Dienst zum einfacheren Aunden
aktiver Peers und deren Fahigkeiten anbietet.
3.2 Das Agentenparadigma
Das Agentenparadigma wendet Konzepte der k unstlichen Intelligenz und der
Sprechakttheorie auf die Technologie der verteilten Objekte an und basiert darauf,
einen Agenten als Softwarekomponente zu abstrahieren, die autonom, proaktiv
und sozial ist:
3.2 Das Agentenparadigma 27
autonom:
Agenten haben ein gewisses Ma an Kontrolle uber ihre eigenen Aktionen,
kontrollieren sich selbst und konnen jederzeit eigene Entscheidungen treen.
proaktiv:
Agenten reagieren nicht einfach nur als Antwort auf externe Ereignisse
(z. B. einem entfernten Methodenaufruf) sondern zeigen auch ein zielgerich-
tetes Verhalten und ergreifen selbst die Initiative.
sozial:
Agenten sind fahig und gezwungen mit anderen Agenten zu interagieren, um
ihre Aufgabe zu erf ullen und ihren Teil am Gesamtziel des verteilten Systems
zu leisten.
Agentenbasierten Systemen wohnt also der Peer-to-Peer-Charakter inne: Jeder
Agent ist ein Peer, der sowohl eine Kommunikation zu einem beliebigen anderen
Agenten aufbauen kann, als auch seine eigenen Fahigkeiten anderen Agenten an-
bieten kann. Die Kommunikation ist ein sehr wichtiger Aspekt in agentenbasierten
Systemen und baut auf den folgenden drei Hauptkriterien auf:
1. Agenten sind aktive Einheiten, die eine Aktion ablehnen konnen und nur lose
gekoppelt sind. Daher erfolgt die Kommunikation zwischen Agenten asynchron
und nachrichtenbasiert und nicht durch entfernte Methodenaufrufe. Ein Agent
sendet also einfach eine Nachricht an den Agenten, mit dem er kommunizieren
mochte. Der Empfanger kann nun selbst entscheiden, auf welche Nachrichten
er in welcher Reihenfolge antwortet oder welche er verwirft. Der sendende
Agent wird dadurch auch nicht blockiert, bis der Empfanger antwortet. Dies
entfernt die kurzfristige Abhangigkeit zwischen Sender und Empfanger, da der
Empfanger zum Zeitpunkt des Kommunikationsversuchs nicht verf ugbar oder
uberhaupt nicht prasent sein kann.
2. Agenten f uhren Aktionen durch und die Kommunikation ist nur eine weitere
Art von Aktion. Die Kommunikation auf dieselbe Stufe, wie die Aktionen des
Agenten zu setzen, erlaubt es einen Plan zu erortern, der sowohl physische
als auch kommunikative Aktionen beinhaltet. Um diese planen zu konnen,
m ussen Auswirkungen und Vorbedingungen jeder moglichen Kommunikation
klar deniert sein.
3. Jede Kommunikation hat eine semantische Bedeutung. Wenn ein Agent eine
Nachricht empfangt, muss er diese genau verstehen konnen und auch ver-
stehen, warum diese Aktion durchgef uhrt wurde, also die bezweckte Absicht
erkennen. Dies setzt eine allgemeine Semantik voraus und f uhrt zum Bedarf
nach einem Standard.
3.3 Middleware
Der Begri Middleware beschreibt meist Bibliotheken auf hoheren Ebenen in ei-
nem komplexen Softwaresystem, die eine einfachere und eektivere Entwicklung
einer Vielfalt von verschiedenen Anwendungen ermoglichen. Diese bieten verschie-
dene Dienste f ur z. B. Dateizugrie, Kommunikation usw. an. Dieselben Dienste
werden auch direkt vom Betriebssystem angeboten, aber das Ziel einer Middle-
ware ist eine betriebssystemunabhangige API mit wiederverwendbaren Mitteln.
Diese m ussen somit nicht in jeder Anwendung neu entwickelt werden, was eine
groe Zeitersparnis bedeutet. Eine Softwarekomponente, die mit einer anderen
Softwarekomponente kommunizieren mochte, nutzt also daf ur Schnittstellen der
Middleware anstatt uber Betriebssystemmittel direkt mit ihr zu kommunizieren.
Eine Antwort wird dann von der Middleware uber denselben Weg zur uck geleitet,
den die urspr ungliche Nachricht genommen hat.
3.4 Also was ist JADE?
JADE ist die durch das italienische Telekommunikationsunternehmen TILAB ent-
wickelte Middleware zur Entwicklung verteilter Multiagentenanwendungen basie-
rend auf der Peer-to-Peer-Architektur. Die Logik, die Initiative, Daten und Res-
sourcen und die Kontrolle kann sowohl auf mobile Endgerate, als auch auf fest
eingerichtete Computer im Netzwerk verteilt werden, da JADE in Java imple-
mentiert wurde und in nahezu jeder Java Virtual Maschine (auer Java Card)
ausgef uhrt werden kann.
Die Umgebung kann sich dynamisch mit ihren Peers (in JADE Agenten genannt)
entwickeln, die erscheinen und verschwinden, je nach dem, wie die Bed urfnisse des
Anwendungssystems sind. Die Kommunikation zwischen den einzelnen Agenten
ist symmetrisch. Jeder Agent ist in der Lage sowohl Absender, als auch Empfanger
einer Nachricht zu sein. JADE basiert auf folgenden Prinzipien:
Interoperabilitat:
JADE ist standardkonform zu den FIPA-Spezikationen (siehe Kapitel 5) Da-
her sind JADE-Agenten fahig, mit allen Agenten zu interagieren, die ebenfalls
denselben Standard erf ullen.
Uniformitat und Portabilitat:
JADE bietet eine homogene Menge an APIs an, die unabhangig vom vor-
handenen Netzwerk und der Java-Version sind: JADE-Agenten sind in den
Java-Umgebungen J2EE, J2SE und J2ME lauahig.
3.5 Die Architektur von JADE 29
Einfach nutzbar:
Die Komplexitat der Middleware wird dem Entwickler durch einfache und
intuitive API-Aufrufe verborgen.
Nur-das-was-man-braucht-Philosopie:
Entwickler m ussen nicht alle Funktionen der Middleware nutzen.

Uber Funk-
tionen, die nicht benotigt werden, braucht man auch nichts zu wissen.
3.5 Die Architektur von JADE
Das JADE-Framework beinhaltet sowohl die Java-Klassen, die benotigt werden,
um eigene Softwareagenten zu entwickeln, als auch eine Laufzeitumgebung, die
die grundlegenden Dienste anbietet, mithilfe derer die Softwareagenten auf ei-
nem geeigneten Zielgerat ausgef uhrt werden konnen. Eine Instanz der JADE-
Laufzeitumgebung wird
Container genannt und beinhaltet die Agenten. Die

Gesamtmenge der Umgebungen wird
Plattform genannt.
Abbildung 3.1: Container und Plattformen in JADE (Quelle: [2])
Diese Plattform bildet eine homogene Schicht ab, die jegliche Komplexitat und
Verschiedenheit der darunterliegenden Hardware, Betriebssystem, Netzwerk und
Virtual Machine vor den Agenten verbirgt. Mindestens ein Container ist in jeder
Plattform prasent: der
Main-Container. Der erste in der Laufzeitumgebung ge-

startete Container ist typischerweise dieser Hauptcontainer. Dieser unterscheidet
sich von anderen Containern, da er zwei spezielle Agenten beinhaltet, die auto-
matisch gestartet werden. Diese Agenten sind das
Agent Management System

(AMS) und der
Directory Facilitator (DF). Das AMS bietet einen Namensdienst

und stellt sicher, dass jeder Agent einen eindeutigen Namen hat und ermoglicht,
einen Agenten in einem entfernten Container zu starten oder zu stoppen. Der DF
bietet einen Verzeichnisdienst an, uber den Agenten die Funktionalitat anderer
Agenten abrufen konnen. In der Abbildung 3.1 ist der gesamte Zusammenhang
grasch dargestellt.
3.6 Entwickeln mit JADE
Im Folgenden soll beschrieben werden, wie mit dem JADE-Framework ein agen-
tenbasiertes System erstellt werden kann. Dazu wird im Wesentlichen direkt auf
die Klassen und die von ihnen angebotenen Methoden eingegangen.
3.6.1 Die Agentenklasse
Einen JADE-Agenten zu erzeugen, beschrankt sich zunachst darauf, eine Klasse zu
schreiben, die die Klasse jade.core.Agent erweitert und die Methode setup()
redeniert, wie dies in Listing 3.1 gezeigt wird.
import jade.core.Agent;
public class HelloWorldAgent extends Agent {
@Override
protected void setup() {
System.out.println("Hello World! My name is " +
getLocalName());
}
}
Listing 3.1: Beispielcode eines sehr einfachen Agenten
Die Methode setup() ist daf ur vorgesehen, den Agenten zu initialisieren. Die ei-
gentliche Arbeit wird mit entsprechendem Verhalten abgebildet und sollte nicht in
dieser Methode vorgenommen werden. Verhalten wird mit der spater erlauterten
Klasse Behaviour oder abgeleiteten Klassen dieser Klasse aus dem Package
jade.core.behaviours abgebildet, wobei die Instanzen des Verhaltens wahrend
3.6 Entwickeln mit JADE 31
des Setup erzeugt werden konnen. Das Gegenst uck zum Setup stellt die Methode
takeDown() dar. Hier konnen Aufraumarbeiten durchgef uhrt werden, die kurz vor
der Beendigung eines Agenten, z. B. nach Erledigen seiner Aufgabe, notig wer-
den. Ein Agent kann sein eigenes Beenden durch Aufruf der Methode doDelete()
veranlassen.
3.6.2 Verhalten von Agenten
Wie bereits erwahnt, wird die zu erledigende Aufgabe eines Agenten mit Verhalten
abgebildet. Solch ein Verhalten wird durch eine Instanz einer Klasse angegeben,
die von der Klasse Behaviour abgeleitet wurde. Damit ein Verhalten von dem
Agenten ausgef uhrt wird, ist es notwendig dieses Verhalten zum Agenten hinzu-
zuf ugen, d. h. die Methode addBehaviour() des Agenten aufzurufen. Dies kann
jederzeit geschehen: wahrend des Setups oder auch innerhalb anderer Verhalten.
Jede Ableitung der Klasse Behaviour muss die abstrakten Methoden action()
und done() denieren. Erstere deniert die durchgef uhrten Operationen wenn
das Verhalten ausgef uhrt wird. Die zweite Methode zeigt uber den booleschen
R uckgabewert an, ob das Verhalten abgeschlossen wurde und vom Pool der vom
Agenten zugeordneten Verhalten entfernt werden kann. Sind keine Verhalten mehr
vorhanden, wird der Thread des Agenten schlafen gelegt, um keine CPU-Zeit mehr
zu konsumieren und wird wieder aufgeweckt sobald ein Verhalten ausgef uhrt wer-
den kann.
Ein Agent kann mehrere Verhalten gleichzeitig ausf uhren. Die Planung des zeit-
lichen Ablaufs von Verhalten eines Agenten ist jedoch nicht praemptiv, wie bei
Threads, sondern kooperativ. Soll das Verhalten ausgef uhrt werden, wird die Me-
thode action() aufgerufen und lauft unterbrechungsfrei bis zur Beendigung. Es
obliegt also dem Programmierer, zu entscheiden, wann von einem Verhalten zum
nachsten umgeschalten wird. Eine Endlosschleife sollte in jedem Fall vermieden
werden. Es werden folgende daraus resultierende Vorteile dieser Losung angege-
ben:
Es erlaubt, nur einen einzigen Thread f ur jeden Agenten zu nutzen, was in
Umgebungen mit limitierten Ressourcen, wie Mobiltelefonen wichtig ist.
Die Umschaltung zwischen Verhalten ist wesentlich schneller als das Umschal-
ten zwischen Threads.
Die Synchronisation von nebenlaugen Verhalten, die dieselben Ressourcen
verwenden entfallt, da alle Verhalten eines Agenten in demselben Thread aus-
gef uhrt werden.
Bei der Umschaltung des Verhaltens enthalt der Status eines Agenten keine
Stackdaten und es ist moglich den Status festzuhalten (Persistenz) und den
Agenten anzuhalten, um diesen spater fortzusetzen oder ihn in einen anderen
Container auf einem entfernten System zu transferieren (Mobilitat).
In JADE wurde mehrere Verhalten bereits vordeniert, um bestimmte wieder-
kehrende Muster abzubilden. Diese sind Unterklassen der besprochenen Klasse
Behaviour.
Generisches Verhalten
Generisches Verhalten wird durch direkte Nachfahren der Klasse Behaviour ab-
gebildet und enthalt eine Art Status und die Ausf uhrung des Verhaltens hangt
von diesem Status ab. Dieses Verhalten ist abgeschlossen wenn ein bestimmter
Zustand erreicht wurde. Es ist mit einem Zustandsautomaten vergleichbar. In der
Methode action() andert sich der Zustand. Die einzelnen Zustande werden ein-
zeln sequentiell abgearbeitet, bis die Methode done() durch R uckgabe von true
das Verhalten abschliet.
Einmaliges Verhalten
Dieses Verhalten wird unverz uglich abgeschlossen und die Methode action()
wird nur ein einziges Mal ausgef uhrt. Die Klasse OneShotBehaviour imple-
mentiert die Methode done() bereits durch R uckgabe von true, sodass die
Ausf uhrung des Verhaltens nach dem ersten Mal bereits abgeschlossen ist.
Wiederkehrendes Verhalten
Wiederkehrendes Verhalten ist niemals abgeschlossen und die Methode action()
f uhrt bei jedem Aufruf dieselben Operationen aus. Die Klasse CyclicBehaviour
implementiert die Methode done() durch R uckgabe von false. Dieses Verhalten
wird solange immer wieder ausgef uhrt, bis der ausf uhrende Agent beendet wird.
Verzogertes Verhalten
Die Klasse WakerBehaviour implementiert beide abstrakte Methoden von
Behaviour und f uhrt die abstrakte Methode handleElapsedTimeout() ein,
die einmalig nach Ablauf einer uber den Konstruktor angegebenen Zeitspanne
ausgef uhrt wird.
Intervallverhalten
Dies stellt eine Kombination aus wiederkehrendem und verzogertem Verhalten dar.
Die Klasse TickerBehaviour f uhrt eine abstrakte Methode onTick() ein, die
wiederkehrend nach Ablauf einer uber den Konstruktor anzugebenden Zeitspanne
ausgef uhrt wird. Dieses Verhalten wird niemals abgeschlossen.
Komplexes Verhalten
JADE ermoglicht das Kombinieren von einfachen Verhaltensmustern zu kom-
plexem Verhalten. An dieser Stelle sind die Klassen SequentialBehaviour,
ParallelBehaviour und FSMBehaviour zu nennen.
3.6.3 Agentenkommunikation
Eines der wichtigsten Fahigkeiten von JADE-Agenten ist die Fahigkeit, zu kom-
munizieren. Das in JADE angewendete Kommunikationsparadigma ist das asyn-
chrone Nachrichtenversenden. Jeder Agent hat eine Art Briefkasten in dem die
Nachrichten anderer Agenten durch die JADE-Laufzeitumgebung abgelegt wer-
den. Gelangt Nachricht in diese Warteschlange, wird der betreende Agent be-
nachrichtigt. Ob und wann der Agent die Nachricht verarbeitet, liegt in der Ent-
scheidungsgewalt des Programmierers.
Abbildung 3.2: Asynchronous Message Passing Paradigma in JADE (Quelle: [2])
Die ausgetauschten Nachrichten werden durch die ACL-Sprache bestimmt, welche
durch die FIPA
1
speziziert wurde. Eine Nachricht besteht dementsprechend aus
einigen Feldern:
1
FIPA: IEEE Foundation for Intelligent Physical Agents; http://www.pa.org (siehe auch Ka-
pitel 5)
Dem Absender der Nachricht
Einer List von Empfangern
Dem Grund der Kommunikation: REQUEST wenn der Absender mochte,
dass der Empfanger eine bestimmte Aktion ausf uhrt, INFORM informiert den
Empfanger uber eine Sache, QUERY IF wenn der Sender eine bestimmte Be-
dingung pr ufen mochte oder eine der folgenden wahrend der Verhandlung
zwischen Agenten: CFP (call for proposal, Angebotsanfrage), PROPOSE (Ange-
bot), ACCEPT PROPOSAL (Angebotsannahme), REJECT PROPOSAL (Angebots-
ablehung) etc.
Dem Inhalt der Nachricht, z. B. die Aktion die bei einer REQUEST-Nachricht
ausgef uhrt werden soll
Die Spache der Nachricht bzw. die genutzte Syntax, die Sender und
Empfanger verstehen m ussen
Die Ontologie, also das Vokabular der verwendeten Symbole und deren Be-
deutung, die zwischen den Kommunikationspartnern nicht abweichen darf
Weitere Felder, um nebenlauge Kommunikation zu steuern oder Timeouts
f ur den Erhalt einer Antwort anzugeben
Eine 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 Felder
der Nachricht implementiert. F ur das Senden einer Nachricht bietet die Basisklas-
se Agent die Methode send() und f ur das Entnehmen einer Nachricht aus der
Warteschlange die Methode receive(). Vor dem Senden ist das Nachrichten-
objekt g ultig mit Werten zu f ullen. Die Empfangsmethode liefert ein Nullobjekt,
wenn sich keine Nachricht in der Warteschlange bendet. Um direkt eine Ant-
wort auf eine Nachricht zu erzeugen, bietet sich die Methode createReply()
der Klasse ACLMessage an.
F ur das Abrufen der Nachrichten bietet sich ein zyklisches Verhalten an. Dabei
muss man beachten, dass das permanente Abfragen eine hohe CPU-Last gene-
riert, was eigentlich vermieden werden sollte. Die lasst sich mit der angebotenen
Methoden block() der Klasse Behaviour verhindern, die das Ausf uhren von
Verhalten des Agenten blockiert. Die Laufzeitumgebung setzt blockierte Verhal-
ten bei Erhalt von Nachrichten selbsttatig fort. Blockieren wird empfohlen, wenn
die Warteschlange eines Agenten leer ist. Anstelle von receive() soll in diesem
Zusammenhang die Methode blockingReceive() eines Agenten erwahnt sein.
Diese blockiert allerdings alle Verhalten eines Agenten und nicht nur das aktuell
abzuarbeitende und wird daher nicht f ur die Verwendung innerhalb von Verhalten
empfohlen.
3.6.4 Namen und Namensdienst
Jeder Agent besitzt eine Agentenidentizierung, welche durch eine Instanz der
Klasse AID reprasentiert wird. Diese umfassen einen global eindeutigen Namen,
welcher sich in JADE durch den Namen des Agenten und der Bezeichnung der
Plattform zusammensetzt, und Adressen, die benotigt werden, wenn der Agent
mit anderen Agenten auf anderen Plattformen kommunizieren mochte. Benden
sich die kommunizierenden Agenten auf derselben Plattform, kann man einen
Agenten uber den Namen und der Angabe der Konstante AID.ISLOCALNAME als
zweiten Parameter im Konstruktor der Klasse AID identizieren. Bei einfachen
Anwendungen kann man so eine feste Liste mit Kommunikationspartnern aufbau-
en.
Wenn die Liste der potentiellen Kommunikationspartner nicht derart statisch ist,
wird ein Mechanismus benotigt, der es erlaubt, alle Agenten zu nden, die einen
bestimmten Service anbieten. Hier kommt der Namensdienst, der in JADE auch
als die Gelben Seiten benannt wird, ins Spiel.

Uber diese Gelben Seiten kann ein
Agent seine angebotenen Dienste veroentlichen und die angebotenen Dienste
von anderen Agenten erfahren, um sie zu nutzen. Die Gelben Seiten werden in
JADE durch den Agenten DF (Directory Facilitator) realisiert, der in jeder Platt-
form bereits standardmaig lauft. Weitere DF-Agenten konnen aktiviert und so
verbunden werden, dass diese einen verteilten Katalog f uhren.
Da der DF ebenfalls ein Agent ist, reicht es f ur die Interaktion aus, ACL-
Nachrichten an diesen zu versenden. Dabei wird die passende Sprache, die SL0,
und passende Ontologie, die FIPA-agent-management Ontologie, verwendet, um
konform zur FIPA-Spezikation zu sein. Allerdings bietet JADE zur Vereinfachung
die Klasse DFService an, um uber Methodenaufrufe Dienste zu veroentlichen
oder zu suchen.
Um einen Dienst zu veroentlichen, muss ein Agent diesen passend beschrei-
ben. Darunter fallen die AID des Agenten, die Liste der moglichen Spra-
chen und Ontologien, die andere Agenten benotigen, um kommunizieren zu
konnen, sowie die Liste der veroentlichten Dienste. F ur jeden dieser Diens-
te m ussen wiederum die Sprachen und Ontologien und einige Dienstspezi-
sche Eigenschaften angegeben werden. F ur diesen Zweck bietet JADE die Klas-
sen DFAgentDescription, ServiceDescription und Property im Package
jade.domain.FIPAAgentManagement. Die eigentliche Registrierung wird dann
durch einen Aufruf der Methode register() der Klasse DFService durch-
gef uhrt. Dies wird ublicherweise in der Setupphase des Agenten erledigt. Diese
Registrierung sollte beim Beenden (Methode takedown()) des Agenten uber die
Methode deregister() wieder r uckgangig gemacht werden.
Um einen veroentlichten Dienst uber die Klasse DFService zu suchen, muss
man dieser uber die Methode search() eine entsprechende Schablone einer
Agentenbeschreibung, ahnlich der beim Registrieren, ubergeben. Das Ergebnis
der Suche ist eine Liste von Agentenbeschreibungen, die mit allen in der Schablo-
ne angegebenen Werten ubereinstimmen. Typischerweise sollte das Suchen eines
Agenten zeitnah zur Nutzung des entsprechenden Dienste erfolgen, da Agen-
ten prinzipiell jederzeit dem System beitreten und verschwinden konnen. Der
DF unterst utzt allerdings auch uber die Methoden searchUntilFound() und
createSubscriptionMessage() das Beobachten des Katalogs, bis ein Agent
einen entsprechenden Dienst veroentlicht.
3.7 Zusammenfassung
In diesem Kapitel wurde zunachst erklart, um was es sich beim Java Agent DE-
velopment Framework handelt. Es wurde dargelegt, wie die gundlegende Struktur
des Frameworks ist und versucht, die Funktionsweise zu erklaren. Im zweiten
Teil konnte der interessierte Leser lernen und erfahren, wie einfach das Erstellen
von agentenbasierten Systemen mit Einsatz des JADE-Frameworks ist. Es konn-
te nicht auf erweiterte Funktionalitaten von JADE wie z. B. die Mobilitat von
Agenten eingegangen werden.
[1] F. Bellifemine et al., JADE A White Paper, http://jade.cselt.it/papers/2003/
WhitePaperJADEEXP.pdf, exp Volume 3 - September 2003.
[2] Giovanni Caire, JADE Programming For Beginners, http://jade.tilab.com/
doc/tutorials/JADEProgramming-Tutorial-for-beginners.pdf, Stand vom Juni
2009.
[3] F. Bellifemine et al., JADE Programmers Guide, http://jade.tilab.com/doc/
programmersguide.pdf, Stand vom April 2010.
4 Janus
Rene Kassel
Inhaltsverzeichnis
4.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.1 Agenten . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2 Multiagentensystem . . . . . . . . . . . . . . . . 38
4.1.3 CRIO Ein organisatorisches Metamodell . . . . 39
4.1.4 Maven . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Janus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1 Das Janus-Projekt . . . . . . . . . . . . . . . . . 40
4.2.2 Die Vorbereitung eines Janus-Projektes . . . . . . 40
4.2.3 Der Lebenszyklus eines Agenten in Janus . . . . . 41
4.2.4 Das Starten eines Agenten . . . . . . . . . . . . . 42
4.2.5 Die Agent-to-Agent Direct Communication . . . . 43
4.3 Praktische Beispiele . . . . . . . . . . . . . . . . . . . . . 44
4.3.1 Market-Like Community . . . . . . . . . . . . . . 44
4.3.2 Boids . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.3 Ant Colony . . . . . . . . . . . . . . . . . . . . . 47
4.4 Schlusswort . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1 Grundlagen
Der folgende Abschnitt f uhrt die grundlegenden Begriichkeiten ein, die zum
Verstandnis dieses Kapitels notwendig sind.
4.1.1 Agenten
Als Agent wird ein Computerprogramm bezeichnet, das zu autonomen (ei-
genstandigen) Verhalten fahig ist. Dies bedeutet, dass ein bestimmter Verar-
beitungsvorgang abhangig von verschiedenen Zustanden ablauft, ohne dass von
auen ein Startsignal gegeben wird oder ein Steuerungseingri wahrend des Vor-
ganges erfolgt. Es gibt keine allgemein anerkannte Denition f ur Agenten. Eine
38 4 Janus
sehr gute Denition ist folgende:
Ein Agent ist ein Computersystem das sich in ei-

ner bestimmten Umgebung bendet und welches fahig ist, eigenstandige Aktionen
in dieser Umgebung durchzuf uhren, um seine Ziele zu erreichen.[2]
Der Einsatz von Agenten
Agenten kommen in verschiedenen Bereichen zum Einsatz. Dazu zahlen das E-
Commerce, die Informationsrecherche, die Simulation sowie das Erledigen von
Routineaufgaben. Die Simulation bildet dabei ein Spezialgebiet. So kann uber
eine Multi-Agentensimulation ein eigener Markt simuliert werden, auf dem z.B.
ein neues Softwareprodukt getestet werden kann.
Die Agententypen
Es gibt Unterschiede in der Art und Weise, wie sich ein Agent verhalt. Dabei wird
zwischen drei verschiedenen Bereichen von Agententypen unterschieden:
Reaktive Agenten:
Diese verf ugen nicht uber eigenes Wissen. Sie agieren nur aufgrund ihrer eige-
nen Wahrnehmung und direkt. Bei der Reaktion auf eine Begebenheit ndet
kein Entscheidungsprozess statt.
Adaptive Agenten:
Diese verwalten ein Modell der eigenen Prozess- und Parameterstruktur. Sie
konnen an auere Bedingungen angepasst werden, welche durch die Agen-
ten gemessen oder erkannt wurden. Dadurch wird eine optimale Ausf uhrung
gewahrleistet.
Kognitive Agenten:
Diese verwalten ein Modell ihrer Umwelt in einer eigenen Datenstruktur. Das
ermoglicht eine Planung der Aktionen und ein zielgerichtetes Handeln.
4.1.2 Multiagentensystem
Hierbei handelt es sich um ein System aus mehreren gleichartigen oder unter-
schiedlich spezialisierten handelnden Agenten, welche gemeinsam ein Problem
losen. Diese Systeme zahlen zum Forschungsgebiet der Verteilten K unstlichen
Intelligenz. Multiagentensysteme beschaftigen sich damit, wie autonome, ver-
teilte und
intelligente Systeme als Einheit ihr spezisches Wissen, ihre Ziele,

Fahigkeiten und Plane abstimmen, um koordiniert zu handeln oder Probleme zu
losen.
4.1 Grundlagen 39
4.1.3 CRIO Ein organisatorisches Metamodell
Janus basiert auf den Konzepten des CRIO Metamodells. Es dient dazu, den
ASPECT Development Process umzusetzen. Dabei formuliert ASPECT einen

Agentenorientierten Softwareprozess, welcher zur Entwicklung komplexer Anwen-
dungen dient. CRIO ist wie folgt deniert:
Organisation
Dies ist eine Sammlung von Rollen, die systematisch in verschiedenen Interaktions-
mustern zusammenarbeiten. Die Rollen stehen in einem gemeinsamen Kontext.
Dieser besteht aus gemeinsamen Wissen, sozialen Regeln und Normen, sozialen
Gef uhlen etc., welche miteinander in Verbindung stehen. Ziel einer Organisation
ist die gemeinschaftliche Erf ullung einer Aufgabe.
Rollen
Eine Rolle ist ein strukturiertes Verhalten, was nach festgelegten Rechten und
Pichten erfolgt. Das Ziel einer jeden Rolle ist es zur Erf ullung der Aufgaben
einer Organisation beizutragen. Es gibt interne Rollen (Common Role) und externe
Rollen (Boundary Role).
Interne Rolle:
Diese beschreibt eine Rolle, die innerhalb des Systems entworfen wurde. Sie
kann mit einer internen und einer externen Rolle interagieren.
Externe Rolle:
Hierbei handelt es sich um eine Rolle, die aus dem System heraus nach auen
kommuniziert. Die Gesamtheit der externen Rollen denieren das Interface
(die Schnittstelle) zum System (GUI, Datenbank).
Interaktion
Interaktion ist eine dynamische, nicht vorher bekannte Abfolge von Ereignissen
die zwischen Rollen ausgetauscht werden oder zwischen Rollen und Entitaten
auerhalb des Agentensystems entwickelt werden. Rollen reagieren je nach ihrem
Verhalten auf die Ereignisse.
Kapazitat / Capacity
In diesem Kapitel wird Capacity frei ubersetzt mit Fahigkeit. Es handelt sich dabei
um abstraktes Wissen, welches der Agent besitzt bzw. was ihm zugewiesen wird.
Das Konzept abstrahiert sozusagen Know-How von der konkreten Realisierung.
40 4 Janus
4.1.4 Maven
Maven ist ein Build-Management-Tool der Apache Software Foundation. Es ba-
siert auf Java. Mit ihm kann man insbesondere Java-Programme standardisiert
erstellen und verwalten. Es wird in tausenden Open-Source- und kommerziellen
Softwareprojekten eingesetzt, um die Softwareentwicklung zu vereinfachen. Ma-
ven wird von der Janus-Community empfohlen, um die Entwicklung eines Mutli-
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 Janus
In diesem Abschnitt wird das Janus-Projekt selbst und die wichtigsten, grundle-
genden Eigenschaften von Janus beschrieben.
4.2.1 Das Janus-Projekt
Das Projekt baut auf einer Reihe von wissenschaftlichen Arbeiten uber die Mo-
dellierung und Simulation von komplexen Systemen auf. Besonderes Interesse gilt
dabei dem Bereich der
holonic multiagent systems. Das Janus-Projekt bem uht

sich, die ganze Methodik und die Unterst utzungwerkzeuge f ur die Analyse, das
Design und die Implementierung von komplexen Anwendungen im Zusammen-
hang mit
holonic multiagent-systems zu bieten.

Ziel der Community ist, eine step-by-step-Anleitung von den Anforderungen bis
hin zur Implementierung zu geben. Janus ist eine Multiagentenplattform, die spe-
ziell daf ur entworfen wurde holonic- und multiagent-systems zu implementieren
und bereit zu stellen. Es ist in JAVA 1.5 geschrieben und basiert auf dem CRIO-
Metamodell. Schwerpunkt ist die Unterst utzung und Implementation von Rollen
und Organisationen bei Agenten. Janus bietet ein umfassendes Set an Features
f ur die Entwicklung, Ausf uhrung, Anzeige und

Uberwachung von multiagenten-
basierten Anwendungen und eignet sich damit sehr gut zur Entwicklung dieser.
4.2.2 Die Vorbereitung eines Janus-Projektes
Janus verwendet Maven f ur die Verwaltung seiner Module. Diese Arbeit be-
schrankt sich auf die Erstellung einer Anwendung in Eclipse. F ur Eclipse wird
ein Plugin names
M2Eclipse geliefert, welches installiert werden muss. Zudem

sind Archetypen notwendig, welche von der Janus-Community in einem Reposi-
tory zur Verf ugung gestellt werden. Nachdem das Plugin installiert wurde, muss
es konguriert und die Verbindung zu dem Repository hergestellt werden.
4.2 Janus 41
Nachdem diese Schritte vollzogen sind, kann eine Janus-Anwendung implemen-
tiert werden. Dazu wird ein neues Maven-Projekt aus der Kategorie Maven ange-
legt. Sofort nach dem Anlegen werden alle notwendigen Daten zur Implementie-
rung einer Janus-Anwendung von dem Repository gezogen. Anschlieend kann mit
der Entwicklung des Multiagentensystems begonnen werden. Im Nachfolgenden
werden einfache Implementierungsgrundlagen vorgestellt.
4.2.3 Der Lebenszyklus eines Agenten in Janus
Jeder Agent in Janus durchlebt verschiedene Zustande. Sie sind durch unter-
schiedliche Aktivitaten gepragt.
Activate:
Diese Aktivitat entspricht der Initialisierungsphase eines Agenten. Activate
wird automatisch vom Janus-Kernel aufgerufen, wenn ein Agent gestartet
wird. In dieser Phase kann dem Agenten eine Rolle zugewiesen werden, die
der Agent einnehmen soll.
Live:
Diese Phase bildet den Hauptteil des Agentenlebenszyklus. Die Live-Methode
wird das Verhalten aufrufen, das der Agent in seiner Rolle besitzt. Jeder Aufruf
der Methode f uhrt einen Schritt des Rollenverhalten aus.
End:
Dies ist die Aktivitat, durch welche der Agent beendet wird. Alle Ressourcen,
welche durch den Agenten reserviert und verwendet wurden, werden in dieser
Methode frei gegeben.
Abbildung 4.1: Agentenlebenszyklus [4]
Die Abbildung 4.1 veranschaulicht den
standardisierten Lebenszyklus mit den
dazugehorigen Aktivitaten. Der Agent
startet als unborn, bis die activate-
Methode aufgerufen wird. Wahrend des
alive-Zustandes des Agenten wird kon-
tinuierlich die live-Methode in einer
Schleife durch den Janus Kernel aufge-
rufen. Diese Schleife bricht ab, sobald
die kill -Methode aufgerufen wird. Dar-
aufhin wechselt der Agent in den died-
Zustand und ruft die end-Methode auf.
Listing 4.1 beschreibt die typische Architektur eines Agenten in Janus. Um einen
eigenen Agenten zu implementieren, muss zunachst von der Klasse Agent aus dem
42 4 Janus
@AgentActivationPrototype(fixedParameters={})
public class MyAgent extends Agent {
public MyAgent() {}
@Override
public Status activate(Object... parameters) {
return StatusFactory.ok(this);}
@Override
public Status live() {
Status status = super.live();
// Do something
return status;
}
}
Listing 4.1: Die typische Architektur eines Agenten[4].
Janus-Package abgeleitet werden. In der genannten Klasse sind alle grundlegenden
Mechanismen vorimplementiert. Um einen minimalen Agenten zu implementieren,
m ussen nur die entsprechenden Methoden redeniert werden. Im Beispiel werden 2
Statusmethoden redeniert (activate, live). In der Methode activate wird uber den
Aufruf StatusFactory.ok(this) dem System angezeigt, dass alles richtig abgelaufen
ist. In der Methode live wird die Methode live der Basisklasse aufgerufen. Danach
kann eigener Code ausgef uhrt werden, welcher entscheidend f ur das Verhalten des
Agenten ist. Am Ende wird der Status zur uck gegeben.
4.2.4 Das Starten eines Agenten
In Janus existieren zwei verschiedene Arten des Startens eines Agenten. Es wird
zwischen dem Heavy Agent und dem Light Agent unterschieden.
Heavy Agent:
Jeder dieser Agenten hat seinen eigenen Thread f ur seine Ausf uhrung. Ein
Heavy Agent ist dadurch vollig selbststandig in Bezug auf seine Ressourcen.
Light Agent:
Dieser teilt seinen Thread mit anderen Agenten. Der Zugri zu den gemein-
samen Ressourcen wird von einem Heavy Agent verwaltet. Janus liefert einen
Standardverwalter f ur die Handhabung der Ausf uhrungen von Light Agents.
Es besteht jedoch die Moglichkeit seinen eigenen Verwalter entwickeln.
4.2 Janus 43
Der folgende Quellcode zeigt die unterschiedlichen Arten des Startens eines Agen-
ten:
public class MyMASApplicationLauncher {
public static void main(String[] args) throws
InterruptedException {
Kernel kernel = Kernels.get(false);
MyAgent mylightagent = new MyAgent(); // nonthreaded
kernel.launchLightAgent(mylightagent, "My Light Agent Name");
MyAgent myheavyagent = new MyAgent(); // threaded
kernel.launchHeavyAgent(myheavyagent, "My Heavy Agent Name");
Kernels.killAll();
}
}
Listing 4.2: Starten eines Agenten[4].
Die Klasse MyMASApplicationLauncher dient dazu die Agenten zu starten. Hierzu
benotigt sie nur eine main-Methode, in welcher zunachst ein Kernel f ur die Agen-
ten initialisiert wird. Danach werden zwei Instanzen der Klasse Agent erzeugt.
Der erste Agent wird als lightAgent gestartet, welcher nicht in einem eigenen
Thread lauft. Der zweite Agent wird als heavyAgent gestartet. Dieser bekommt
einen eigenen Thread zugeteilt. Am Ende der Beispielklasse wird an alle Agents
ein Kill-Signal gesendet, welches die Agenten wieder beendet.
4.2.5 Die Agent-to-Agent Direct Communication
In Janus gibt es verschiedene Kommunikationsmechanismen. Es gibt die einfache
Agent-to-Agent Direct Communication, aber auch die komplexere Organizational
Communication, welche auf Rollen- und Gruppenkonzepten basiert. Dieses Kapitel
beschrankt sich auf die einfache Agent-to-Agent Direct Communication. Diese
kann nochmals unterschieden werden in One-to-One Communication und One-
to-Many Communication.
44 4 Janus
One-to-One Communication
Soll eine Nachricht von einem Agenten zu einem anderen gesendet werden, wird
folgende Methode benotigt[4]:
AgentAddress sendMessage(Message message, AgentAddress agents)
Der Methodenname lautet sendMessage. Sie hat als Parameter die Nachricht
selbst und den Zielagenten, an den die Nachricht gesendet werden soll. Als
R uckgabewert bekommt man die Adresse des Agenten, der die Nachricht erhalten
hat.
One-to-Many Communication
Soll eine Nachricht von einem Agenten zu vielen anderen gesendet werden, wird
folgende Methode verwendet[4]:
void broadcastMessage(Message message, AgentAddress agents)
Der Methodenname lautet broadcastMessage. Diese hat als Parameter wieder die
Nachricht selbst und die Zielagenten. Sie besitzt keinen R uckgabewert.
4.3 Praktische Beispiele
In diesem Teil folgen einige praktische Beispiele, welche durch die Janus-
Community entwickelt wurden. Diese erweitern die eben vorgestellten grundlegen-
den Eigenschaften eines Agenten um Rollen und die dadurch mogliche Zusam-
menarbeit von Agenten in einer Organisation. Die Implementierung wurde unter
Ber ucksichtigung des CRIO-Metamodells mit der Janus-Plattform durchgef uhrt.
4.3.1 Market-Like Community
Dieses Beispiel zeigt die Implementierung von Rollen als First-Class-Entities, die
Dynamik in den Rollen und Kommunikation zwischen den Rollen. Dies wird in
einer marktahnlichen Gemeinschaft veranschaulicht. Das Beispiel wird f ur den
Inlands-Reisemarkt angewendet. Es werden 3 einfache Agententypen verwendet:
Ein Client (Kunde)
4.3 Praktische Beispiele 45
Ein Broker (Makler)
4 Provider (Anbieter)
Diese kommunizieren uber Rollen miteinander in unterschiedlichen organisatori-
schen Kontext. Ziel des Clients ist es, das beste Reiseangebot in Bezug auf die
Reisezeit oder auf den Preis zu bekommen. Der Client gibt seinen Vorschlag ab
und sendet diesen an den CBroker, welcher f ur den Client zustandig ist. Dieser
schickt die Informationen an den PBroker, welcher sie an alle verf ugbaren Provider
weiterleitet. Die Broker bilden die Schnittstelle zwischen dem Client und dem Pro-
vider. Abhangig von dem Kriterium das der Client zu Beginn gewahlt hat (Preis
oder Zeit), bestimmt der PBroker den besten Vorschlag und teilt ihn den Client
mit. Der Client und der beste Provider bilden dann eine Organisation namens
Contracting Organisation (Vertragsnehmer) um die Bestellung abzuschlieen

und die Zahlung zu tatigen. Somit wird f ur die Umsetzung des vorgeschlagenen
Beispiels folgendes benotigt:
3 Agententypen (Client (Agent 1), Provider (Agent 3,4,5), Broker(Agent 2))
3 Organisationen (Purchase (Kauf), Providing (Bereitstellung), Contracting
(Vertragsnehmer))
6 Rollen
Die Abbildung 4.2 veranschaulicht die einzelnen Agententypen und die durch
sie gebildeten Organisationen sowie die Kommunikation zwischen ihnen. Wie zu
sehen ist, besitzt das Beispiel 3 Organisationen, jede davon ist aus 2 Rollen zu-
sammengesetzt.
Purchase:
Diese verwaltet die Interaktionen zwischen dem Client und dem Broker. Die
Hauptaufgabe liegt in der Formatierung und Weiterleitung der Client-Anfrage.
Providing:
Die Organisation verwaltet die Interaktionen zwischen dem Broker und dem
Provider. Ziel ist es, die Anfrage vom Client an alle Provider weiterzuleiten.
Contracting:
Sie verwaltet die Interaktionen zwischen dem Client und dem Provider, um
den Kauf abzuwickeln.
Dabei kann eine Organisation dynamisch als Gruppe instanziiert werden. Ein
Agent nimmt eine Rolle in dieser Gruppe ein. Wird also eine solche Gruppe
benotigt, kann diese bei Bedarf durch die Agenten erstellt werden.
46 4 Janus
Abbildung 4.2: Market-Like Community[7]
4.3.2 Boids
Boids wurde 1986 als ein Computer Modell vorgeschlagen, dass koordinierte Tier-
bewegung simuliert, wie z.B. Vogel- oder Fischschwarme. Es wird haug in der
Computergrak (Animation und Computer Aided Design) genutzt, die eine realis-
tische Darstellung von Vogeln oder anderen Lebewesen liefern. Ein Beispiel f ur die
Verwendung von Boids liefert die Vogelsimulation in HalfLife. Die Komplexitat
der Boids ergibt sich aus der Interaktion der einzelnen Agenten (hier den Boids).
Diese folgen einfachen Regeln. Die Regeln beschreiben die Verhaltenssteuerung
eines Boid. Diese beziehen sich auf die Position und Geschwindigkeit. Zu den
einfachsten Regeln zahlen:
Separation (Trennung):
Das bedeutet, dass der Boid eine Richtung wahlt, um eine Haufung von Boids
zu vermeiden.
Alignment (Angleichen):
Dahinter verbirgt sich die Richtungswahl, die der mittleren Richtung der be-
nachbarten Boids entspricht.
Cohesion (Zusammenhalt):
Diese Regel beschreibt die Wahl einer Richtung, die der mittleren Position der
benachbarten Boids entspricht.
Zu diesen konnen weitere Regeln hinzugef ugt werden, z.B. die Zielsuche oder das
Ausweichen von Hindernissen. Die Bewegungsmuster der Boids konnen in chao-
4.3 Praktische Beispiele 47
tisch (zufallige Bewegung, Aufbrechen des Schwarms) und geordnet unterschieden
werden. Das Beispiel zeigt mehrere verschiedene Wolken von Dreiecken in unter-
schiedlichen Farben. Alle Dreiecke stellen dabei die Boids, bzw. die Agenten dar.
Diese sind zunachst chaotisch angeordnet. Nach kurzer Zeit organisieren sich die
Agenten selbst und ordnen sich nach Farben. Nun ist es dem Benutzer moglich,
eine Dreieckswolke einer bestimmten Farbe uber die Anwendung zu legen. Boids
gleicher Farbe nahern sich der durch den Benutzer platzierten Wolke an, Boids
anderer Farben hingegen meiden die Annaherung an die platzierte Wolke.
4.3.3 Ant Colony
Dieses Beispiel zeigt die Simulation eines Ameisenstaates mit Hilfe eines Multi-
agentensystems. Es liefert eine mogliche Implementierung von dem eben vorge-
stellten Boids-Konzept.
Das Ant Colony Prinzip
Eine einzelne Ameise hat kein globales Wissen uber die Aufgabe, die sie ausf uhrt.
Die Aktionen, welche von der Ameise ausgef uhrt werden, basieren auf lokalen
Entscheidungen und sind meist unvorhersehbar. Das intelligente Verhalten ent-
steht durch die Selbstorganisation und indirekten Kommunikation zwischen den
Ameisen.
Denition der Umwelt
Die Umwelt ist in ein Raster zerlegt. Jede Zelle des Rasters kann eine Kolonie,
ein Pheromon oder eine Nahrungsquelle sein. Das Beispiel behandelt zwei Typen
von Pheromonen:
Das
Food-Pheromon: Dies gibt die Richtung der Nahrungsquelle an.

Das
Colony-Pheromon: Dies gibt die Richtung der Ameisenkolonie an.

Denition der Ant Colony Organisation
Die Organisation besteht aus 2 Rollen. Diese werden durch den Patroller und den
Forager gebildet.
Patroller:
Dieser lauft zufallig durch die Kolonie und verstreut das
Colony Pheromon.
Er kehrt zur Kolonie zur uck, wenn er abschatzt, dass seine Pheromone auf die
Halfte des Ursprungswertes gesunken sind.
48 4 Janus
Forager:
Dieser sucht zufallig nach Futterquellen. Wahrend der Suche wirft er das
Colony Pheromon aus. Nachdem er eine Futterquelle gefunden hat, versucht

er zur Kolonie zur uckzukehren mit Hilfe des Colony Pheromons. Auf dem Weg
zur uck zur Kolonie wirft er
Food-Pheromons aus um die Nahrungsquelle

spater wieder zu nden. Damit ermoglicht er den anderen Ameisen aus der
Kolonie ebenfalls das Aunden der Futterquelle.
Abbildung 4.3: Ant-Colony-Application[11]
Die Abbildung 4.3 zeigt das Beispiel in einer graschen Darstellung. Hier sind
verschiedenste Formen und Farben zu sehen. In der Mitte der weien Kreise be-
nden sich die unterschiedlichen Kolonien. Bewegliche Ameisen sind durch gr une
Punkte, unbewegliche (sesshafte) als gelbe Punkte dargestellt. Die roten Punk-
te zeigen Futterquellen, nach welchen die Ameisen suchen. Zusatzlich dazu sind
weie und pinke Kurven zu sehen. Die weien symbolisieren den Weg der
Colony
Pheromones und die pinken des
Food-Pheromones. Die Pheromone wurden

also entlang der Kurven ausgeworfen.
Auch dieses Beispiel zeigt wieder die Selbststandigkeit und Eigenorganisation der
Agenten. Alle Agenten (Ameisen) verfolgen einheitliche Ziele, die vorwiegend aus
dem Aunden der Futterquellen bestehen und losen gemeinschaftlich diese Auf-
gabe indem sie verschiedene Rollen verteilen. Jede Rolle bildet eine Teillosung der
Aufgabe und gemeinsam erreichen sie ihr Ziel.
4.4 Schlusswort 49
4.4 Schlusswort
Anhand der vorgestellten Beispiele ist zu sehen, welche komplexen Multiagen-
tensysteme mit Janus umgesetzt werden konnen. Dabei zeigt dieses Kapitel nur
grundlegende Begriichkeiten bzw. Konzepte und einfache Beispiele. Letztend-
lich bildet Janus eine sehr gute Alternative zu JADE (siehe Kapitel 3). Es bietet
sehr viele Moglichkeiten zur Entwicklung einer Multiagentenplattform. Zudem ist
ein solches Projekt relativ leicht vorzubereiten und durch seine groe Anzahl vor-
implementierter Funktionen konnen mit wenig Aufwand sehr umfangreiche Mul-
tiagentensysteme entwickelt werden.
[1] Janus-Project, Home. http://www.janus-project.org/Home, 15.12.2010.
[2] Wooldridge, M., Jennings, N. R.,Intelligent agents: Theory and practice. The
Knowledge Engineering Review. 1995.
[3] Janus-Project, Maven Support. 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.,Multiagentensysteme Einige Beispiele. 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: an
agent-oriented software process for engineering complex systems. 2009.
[9] Janus-Project, Boids. http://www.janus-project.org/Boids, 07.01.2011.
[10] Craig Reynolds, 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 4 Janus
5 FIPA Standards
Marco Kretzschmar
Inhaltsverzeichnis
5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Die FIPA-Organisation . . . . . . . . . . . . . . . . . . . 52
5.2.1 Ziele . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.2 Geschichte . . . . . . . . . . . . . . . . . . . . . 52
5.2.3 Organisationsstruktur . . . . . . . . . . . . . . . 53
5.3 Die FIPA-Standards . . . . . . . . . . . . . . . . . . . . . 54
5.3.1 Einteilung der FIPA-Standards . . . . . . . . . . 54
5.3.2 Lebenszyklus der Spezikationen . . . . . . . . . 55
5.3.3 Spezikations-Identizierer . . . . . . . . . . . . 55
5.4 Zwei Standards kurz vorgestellt . . . . . . . . . . . . . . 56
5.4.1 Agent Management Reference Model . . . . . . . 56
5.4.2 FIPA ACL Message Structure . . . . . . . . . . . 58
5.5 FIPA-Standards in der Praxis . . . . . . . . . . . . . . . . 58
5.1 Einleitung
Die praktische Nutzung von Agentensystemen
1
ist stark von der Verf ugbarkeit
international anerkannter Standards abhangig. Die zwei wichtigsten Standardi-
sierungsorganisationen f ur Agentensysteme sind die OMG (Object Management
Group) und die FIPA (Foundation for Intelligent Physical Agents). Auch wenn
im Namen der FIPA die Begrie Physical Agents stehen, entwickelt diese nur
Standards f ur Softwareagenten. Die OMG hat mit ihrem MASIF-Standard, der
sich vordergr undig mit der Zusammenarbeit von Agentenplattformen beschaftigt,
einen weit verbreiteter Standard deniert. Dagegen haben die FIPA-Standards in
der Praxis eine weit geringere Bedeutung. Trotzdem besitzen sie ihre Daseinsbe-
rechtigung, denn die FIPA betrachtet einen Bereich den die OMG fast komplett
vernachlassigt: die Kommunikation zwischen den Agenten.
1
Ein (Software-)Agentensystem besteht aus mehreren heterogen oder homogenen, autonomen,
spezialisierten Software-Agenten. Diese Software-Agenten losen ihnen gestellte Aufgaben im
Kollektiv.
52 5 FIPA Standards
In diesem Artikel sollen die FIPA als Organisation und deren Standards im Vor-
dergrund stehen. Dabei wird im ersten Kapitel auf die Ziele, Geschichte und die
Organisationsstruktur der FIPA eingegangen. Im zweiten Kapitel geht es darum
sich einen

Uberblick zu verschaen in welche Ebenen sich die Standards aufteilen,
welchen Lebenszyklus die Spezikationen durchlaufen und wie die Spezikationen
identiziert werden konnen. Das dritte Kapitel stellt kurz zwei wichtige Standards
der FIPA vor. Im letzten Kapitel soll kurz uber die FIPA-Standards in der Praxis
berichtet werden.
5.2 Die FIPA-Organisation
Die FIPA (Foundation for Intelligent Physical Agents) ist eine nicht gewinnori-
entierte Organisation und besteht derzeit aus 57 Mitgliedern aus Industrie und
Forschung (Stand: Jan/2011). Darunter bekannte Firmen wie Boing, Siemens und
Toshiba, aber auch Universitaten wie die Queen Mary University of London, die
RWTH Aachen oder die Universitat Duisburg-Essen [1].
5.2.1 Ziele
Ziel der FIPA ist es, international akzeptierte Standards f ur heterogene Agenten-
systeme zu schaen. Dadurch wird es ermoglicht das Agentensysteme von ver-
schiedenen Anbietern miteinander kommunizieren und kooperieren konnen. Die
FIPA setzt ihren Schwerpunkt dabei auf die praktisch genutzten industriellen und
gewerblichen Agentensystemen, beschaftigt sich aber auch mit intelligenten und
kognitiven Agenten.
Die FIPA verdeutlicht das mit ihrem oziellen Missionsstatement:
The promotion of technologies and interoperability specications that fa-

cilitate the end-to-end interworking of intelligent agent systems in modern
commercial and industrial settings [1].
5.2.2 Geschichte
Die Foundation for Intelligent Physical Agents wurde 1996 in Genf gegr undet.
Schon ein Jahr nach der Gr undung der Organisation wurden die ersten Spezi-
kationen unter dem Titel FIPA97 veroentlicht. Diese Spezikationen befassten
sich hauptsachlich mit der Agentenkommunikation, dem Agentenmanagement
und der Integration von Agenten. In den folgenden Jahren wurden diese Standards
weiterentwickelt und unter dem Namen FIPA98 und FIPA99 freigegeben. Diese
befassten sich zusatzlich mit der Sicherheit und Mobilitat von Agenten, sowie
5.2 Die FIPA-Organisation 53
der Mensch-Agent Interaktion. Im Jahr 2000 wurde mit dem FIPA2000-Standard
das alte Namenschema abgeschat und durch einen eindeutigen 5-stelligen Code
ersetzt. Durch dieses neue Schema ist es moglich die einzelnen Standards un-
abhangig voneinander zu andern. Der FIPA2000 Standard hat bis heute seine
G ultigkeit. Im Jahr 2005 schloss sich die FIPA der IEEE Computer Society an und
wurde ihr elftes Mitglied [1].
5.2.3 Organisationsstruktur
Die FIPA strukturiert sich in zwei Hauptbereiche. Ein Bereich ist f ur Finanzen,
Verwaltung etc. verantwortlich und der andere Bereich ist f ur die Planung und
Umsetzung der Spezikationen zustandig (siehe Abbildung 5.1). In diesem Ab-
schnitt werden die einzelnen Bereiche der Organisation kurz vorgestellt.
Abbildung 5.1: FIPA-Organisationsstruktur[1]
Das Board of Director ist verantwortlich f ur die Leitung und Durchf uhrung der
laufenden Geschafte in der Organisation. Um nanzielle Fragen der FIPA und
die Verwaltung der Mitglieder k ummert sich das Secretariat. Das Image Com-
mittee koordiniert die

Oentlichkeitsarbeit der FIPA und erstellt unter anderem
Newsletter und Pressemitteilungen. Der Finanz- und Pr ufungsausschuss der FIPA
ist das Finance and Audit Committee. Es pr uft Rechnungen und die Finanzie-
rung der FIPA und bereitet den Audit-Bericht f ur den Verwaltungsrat vor. Das
Membership and Nomination Committee pr uft die Qualikation der Bewerber
die Mitglied in der FIPA werden wollen [1].
Das FIPA Architecture Board ist eine Einrichtung innerhalb der FIPA. Sie
gewahrleistet die Genauigkeit und Konsistenz, sowie die Eignung der technischen
54 5 FIPA Standards
Arbeiten der FIPA. Zusatzlich uberwacht und genehmigt das Architecture Board
die Arbeiten von Fachaussch ussen und den Working Groups.
Die Durchf uhrung von technischen Arbeiten der FIPA ubernehmen die Technical
Committees. Die Aufgaben werden durch Arbeitsplane deniert die vom Archi-
tecture Board genehmigt wurden. Die Arbeitsplane enthalten die Beschreibung
der durchzuf uhrenden Arbeiten, sowie den festen Bearbeitungszeitraum. Die ty-
pischen Aufgaben der Technical Committees sind die Entwicklung neuer oder die
Anderungen bestehender Spezikationen.

Die Working Groups der FIPA f uhren Arbeiten durch, die nicht unbedingt mit der
technischen Denition einer Spezikation zu tun haben. F ur die Working Groups
stehen die Anwendungen der Agentenplattformen und die Zusammenarbeit mit
anderen Standards im Vordergrund. Wie schon bei den Technical Committees wer-
den vom Architecture Board ein genehmigter Arbeitsplan mit durchzuf uhrenden
Aufgaben und ein Bearbeitungszeitraum vorgegeben. Im Normalfall erstellen die
Working Groups Informationsdokumente oder andern bestehende Spezikationen.
Die Special Interest Groups wurden eingerichtet um Hilfstatigkeiten innerhalb
der FIPA zu ubernehmen, die im Interesse der Mitglieder liegen [1].
5.3 Die FIPA-Standards
Die FIPA-Standards sind eine Sammlung von Spezikationen, die das Zusam-
menarbeiten von heterogenen Agenten und den Diensten die sie reprasentieren
unterst utzen sollen. Die Spezikationen sind in der Lage ein vollstandiges Multi-
agentensystem zu beschreiben.
5.3.1 Einteilung der FIPA-Standards
Die FIPA Standards lassen sich in drei Ebenen (siehe Abbildung 5.2) unterteilen.
In der Ebene Applications werden Beispielapplikationen vorgestellt in denen die
FIPA Agenten eingesetzt werden konnen. Um die Agentendienst und Agentenum-
gebungen realisieren zu konnen werden in der Ebene Abstract Architecture die
benotigten abstrakten Architekturen vorgestellt [1].
Die unterste Ebene unterteilen sich in die drei Bereiche: Agent Communication,
Agent Management und Agent Message Transport.
Im Bereich Agent Communication wird die Kommunikation, der Nachrichtentyp,
sowie die Interaktionsprotokolle und Content Language deniert. Der Aufbau der
Agentenplattform wird im Bereich Agent Management beschrieben. Der Bereich
Agent Message Transport ist f ur die Transportprotokolle und die Darstellungsform
der Nachricht verantwortlich [1].
5.3 Die FIPA-Standards 55
Abbildung 5.2: Struktur der FIPA-Standards [1]
5.3.2 Lebenszyklus der Spezikationen
Jede FIPA-Spezikation durchlauft verschiedene Zustande (siehe Abbildung 5.3)
die sich in Preliminary, Experimental, Standard, Deprecated und Obsolete unter-
teilen.
Abbildung 5.3: Lebenszyklus der Spezikationen [1]
Der erste Status Preliminary bedeutet, dass es eine vorlauge Spezikation ist.
Der Status Experimental sagt aus, dass die Spezikation von der FIPA schon ak-
zeptiert wurde, es aber noch keine Implementierung gibt. Wenn mindestens eine
Implementierung vorhanden ist, wechselt der Status von Experimental zu Stan-
dard. Zurzeit gibt es 25 Spezikationen die den Status Standard haben. Veraltete
Spezikationen bekommen den Status Deprecated und ein halbes Jahr spater
Obsolete [1].
5.3.3 Spezikations-Identizierer
Um eine Spezikation eindeutig identizieren zu konnen besitzt jede Spezikati-
on eine Identikationsnummer. Die FIPA verwendet dabei zum Einen interne, und
zum Anderen ozelle Identikationsnummern. Die interne Identikationsnummer
56 5 FIPA Standards
setzt sich aus dem Status des Lebenszyklus, dem Typ und einer Dokumenten
Nummer zusammen. Diese Identikationsnummern sind f ur die Entwickler ge-
dacht, da diese Nummern den aktuellen Status und den Typ der Spezikation
erkennen lassen. Als Beispiel dienen die in Tabelle 5.1 dargestellten Identikati-
onsnummern XI00081 und SC00033.
Spezikations Identizierer Erklarung
XI00081 X = Status: Experimental;
I = Typ: informativ;
00081 = Dokumentennummer
SC00033 S = Status: Standard;
C = Typ: Komponente;
00033 = Dokumentennummer
Tabelle 5.1: Identikationsnummern
Die ozellen Identikationsnummern, welche unter anderen in externen Doku-
menten verwendet werden, setzt sich aus dem Organisationsnamen und der Do-
kumentennummer zusammen. Die in der Tabelle genannte Spezikationen w urden
also oziell FIPA00081 und FIPA00033 heien.
5.4 Zwei Standards kurz vorgestellt
In diesem Abschnitt soll auf zwei zentrale Bestandteile der FIPA-Standards einge-
gangen werden. Zum Einen auf das Agent Management Preference Model, zum
Anderen auf die FIPA ACL Message Structure. Beide werden nur kurz vorgestellt
und konnen detailliert auf der Homepage www.FIPA.org nachgelesen werden.
5.4.1 Agent Management Reference Model
Das Agent Management Reference Model beschreibt eine Umgebung, in der Agen-
ten existieren und operieren konnen. Das Model ist in der Spezikation SC00023
vom 18.03.2004 deniert und ermoglicht das Erstellen, Registrieren, Lokalisieren,
Kommunizieren und Migrieren von Agenten. Die Struktur der Agentenplattform
wird in Abbildung 5.4 verdeutlicht.
Das Gesamtsystem ist die Agentenplattform und besteht aus mehreren Kompo-
nenten. Der Agent spielt dabei eine zentrale Rolle, er kann selbst Dienste anbieten
und nutzen. Aber auch mit anderer Software oder dem Benutzer interagieren [2].
Mit Hilfe des Agent Identier (AID) konnen Agenten auf der Plattform eindeu-
5.4 Zwei Standards kurz vorgestellt 57
Abbildung 5.4: Struktur der FIPA Standards [2]
tig identiziert werden. Der Name der im Agent Identier enthalten ist kann aus
verschiedenen Kombinationen bestehen, wie z.B. dem lokalen Namen und der
Plattformadresse.
Mit Software sind alle Nicht-Agenten gemeint. Es handelt sich hierbei um Softwa-
resammlungen die z.B. das Hinzuf ugen von Diensten, Protokollen oder Algorith-
men ermoglichen. Das Agent Management System (AMS) verwaltet die Agenten
der Plattform. Nachdem ein Agent erzeugt worden ist, muss er sich im AMS
registrieren und erhalt dadurch seine AID. Das AMG kontrolliert anschlieend
die

Ubergange im Lebenszyklus-Modell des Agenten. Wenn die Agentenplattform
auch mobile Agenten unterst utzt, muss sich das AMS ebenfalls darum k ummern.
Eine optionale Komponente der Plattform ist der Directory Facilitator (DF). Der
DF bietet f ur Agenten einen
Gelbe Seiten-Dienst an, wobei sich jeder Agent

mit seinem Dienst dort anmelden kann. Will ein Agent hingegen nur den Dienst
nutzen, kann er durch eine Suchanfrage erfahren, welcher Agent den gesuchten
Dienst anbietet. Des Weiteren kann der DF auch Kommunikationsinformationen
des dienstanbietenden Agenten bereitstellen [2].
Vom Message Transport Service wird ein Nachrichtenkommunikationsdienst an-
geboten (Spezizierung FIPA00067).
58 5 FIPA Standards
Ein weiterer wichtiger Teil der Spezikation ist die Agent Management Ontology
(AMO), welche die Semantik und Syntax der benotigten Anfragen beschreibt. Sie
ermoglicht die plattform ubergreifende Kooperation von Agentenpattformen [2].
5.4.2 FIPA ACL Message Structure
Damit Agenten miteinander kommunizieren und sich gegenseitig lokalisieren
konnen, bedarf es einer gemeinsamen Sprache. In der Spezikation SC00061 wer-
den die Grammatik und die Syntax der ACL festgelegt. Doch um diese Sprache
vollstandig nutzen zu konnen, bedarf es noch einiger weiterer Spezikationen,
auf die im Dokument verwiesen wird. Ein Beispiel f ur die ACL ist die folgende
Nachricht:
Der Agent Preisnder mochte vom Agent Haendler den Preis f ur ein Produkt
erfahren. Der Haendler antwortet wie in Listing: 5.1 dargestellt:
(inform
:sender (agent-identifier :name Haendler)
:receiver (set (agent-identifier :name Preisfinder))
:content ("Preis (Produkt, 120,95)")
:language FIPA-SL
:ontology Preise)
Listing 5.1: ACL Nachricht
Der Anfang der Nachricht wird mit (inform (Speziziert in SC00037) eingeleitet.
Die Teilnehmer der Kommunikation sind einmal der :sender (sender der Nachricht)
und der :receiver (Empfanger der Nachricht). Den Inhalt der Nachricht ist in :con-
tent zu nden. Der Content wird mit :language (Sprache der Content-Parameter)
und :ontology (Kontext der Anfrage) beschrieben [3].
5.5 FIPA-Standards in der Praxis
Wahrend Ende der 90er Jahre die Agentensysteme noch als revolutionar galten,
hat sich in den vergangenen Jahren eine Stagnation breit gemacht. Die Software-
agenten haben mit Sicherheitsproblemen zu kampfen, auch wenn die FIPA seit
ein paar Jahren bestrebt ist dies zu verbessern. Im Repository der FIPA bemerkt
man schnell das Ausma der Probleme, denn viele Standards sind aus dem Jahr
2003 und fr uher.
Dessen ungeachtet werden die FIPA-Standards von einer Reihe Frameworks und
Plattformen verwendet. Darunter sind das Java Intelligent Agent Componentware
(JIAC) Framework, sowie die SPADE Multiagent and Organizations Plattform.
Eines von den bekannteren Frameworks ist Jade (Java Agent Development Fra-
mework). Es ist eine freie Middleware f ur agentenbasierte Anwendungen und folgt
ebenfalls den FIPA Standards (Siehe Kapitel 3 - Java Agent DEvelopment Fra-
mework).
Ob und wann sich die Agentensysteme wieder mehr in die Softwarelandschaft
etablieren, ist zum jetzigen Zeitpunkt nicht absehbar. Es ist aber mageblich von
den kommenden Entwicklungen der OMG und FIPA abhangig.
[1] FIPA Homepage. http://www.pa.org
[2] FIPA Repository. http://www.pa.org/specs/pa00023/SC00023K.pdf
[3] FIPA Repository. http://www.pa.org/specs/pa00061/SC00061G.pdf
60 5 FIPA Standards
Teil II
Prozesstheorie und
unmittelbare Umsetzung
6 Communicating Sequenti-
al Processes
Wenqi Yan (Rene Brothuhn)
Inhaltsverzeichnis
6.1 Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1.1 Denitionen und Gesetze . . . . . . . . . . . . . 64
6.1.2 Spuren und Operationen auf Spuren . . . . . . . 66
6.1.3 Spuren eines Prozesses . . . . . . . . . . . . . . . 67
6.2 Parallele Systeme . . . . . . . . . . . . . . . . . . . . . . 68
6.2.1 Interaktion . . . . . . . . . . . . . . . . . . . . . 68
6.2.2 Nebenlaugkeit . . . . . . . . . . . . . . . . . . 69
6.2.3

Anderung des Symbols . . . . . . . . . . . . . . . 70
6.3 Nichtdeterminismus . . . . . . . . . . . . . . . . . . . . . 70
6.3.1 Nichtdeterministisches ODER . . . . . . . . . . . 71
6.3.2 Allgemeine Auswahl . . . . . . . . . . . . . . . . 71
6.3.3 Ablehnungen . . . . . . . . . . . . . . . . . . . . 72
6.3.4 Verbergen . . . . . . . . . . . . . . . . . . . . . 73
6.4 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . 74
6.4.1 Ein- und Ausgabe . . . . . . . . . . . . . . . . . 74
6.4.2 Kommunikation . . . . . . . . . . . . . . . . . . 74
6.5 Sequentielle Prozesse . . . . . . . . . . . . . . . . . . . . 75
6.5.1 Gesetze und Mathematische Betrachtung . . . . . 75
6.5.2 Unterbrechungen . . . . . . . . . . . . . . . . . . 77
6.5.3 Zuweisung . . . . . . . . . . . . . . . . . . . . . 77
6.1 Prozesse
Communicating Sequential Processes (CSP) ist eine Prozessalgebra zur Beschrei-
bung von Interaktionen zwischen kommunizierenden Prozessen. Die Idee wurde
1978 von C.A.R. Hoare an der Universitat Oxford vorgeschlagen und erstmals
64 6 Communicating Sequential Processes
vorgestellt. In CSP besteht ein konkurrierendes System aus mehreren, parallel ab-
laufenden sequentiellen Teilprozessen. Die Teilprozesse haben dabei keinen Zugri
auf Variablen anderer Prozesse.
Unter Prozess versteht man die mathematische Abstraktion der Interaktionen zwi-
schen einem System mit seiner Umgebung. Mit Prozessen lasst sich das Verhalten
von Objekten beschreiben. Das Verhalten wird durch eine begrenzte Menge von
Ereignissen aus einem festgelegten Alphabet beschrieben. Im folgenden Beispiel
eines einfachen Automaten (V MS) gibt es zwei Ereignisse:
coin eine M unze wird in den Automaten eingeworfen,
choc der Automat gibt eine Schokolade aus.
Folgende Konventionen werden verwendet:
1. Worter in Kleinbuchstaben bezeichnen Ereignisse, z.B. coin, choc, in2p, out1p
oder a, b, c, d, e.
2. Worter in Grobuchstaben bezeichnen Prozesse, z.B.
V MS - Simple Vending Machine
V MC - Complex Vending Machine
3. Die Buchstaben A, B, C bezeichnen eine Menge von Ereignissen.
4. Die Buchstaben X, Y , Z bezeichnen Prozessvariablen.
5. Das Alphabet eines Prozess P ist mit P gekennzeichnet, z.B. V MS =
coin, choc.
Ein Prozess mit dem Alphabet A, in welchem keines der Ereignisse aus A auf-
tritt, wird STOP
A
genannt. Hiermit kann das Verhalten eines defekten Objektes
beschrieben werden.
6.1.1 Denitionen und Gesetze
Im Folgenden werden einige Notationen eingef uhrt, mit deren Hilfe Objekte be-
schrieben werden konnen.
Prax
Wenn x ein Ereignis ist und P ein Prozess, dann wird mit dem Ausdruck (x P)
1
ein Objekt beschrieben, in dem zuerst x ausgef uhrt wird und sich dann so verhalt
wie in P beschrieben.
1
gesprochen x dann P
6.1 Prozesse 65
Es ist deniert, dass der Prozess (x P) das gleiche Alphabet besitzt wie Prozess
P. Daher darf diese Notation nur verwendet werden, wenn x in dem Alphabet
enthalten ist: (x P) = P, wenn x P.
Beispiel: (coin STOP
V MC
) bedeutet, der Automat akzeptiert vor dem De-
fekt eine M unze.
Rekursion
Die Prax-Notation kann das gesamte Verhalten eines Prozesses, der schlielich
stoppt, beschreiben. Es ware jedoch sehr m uhsam das Verhalten eines Automaten
f ur seine gesamte Lebensdauer zu beschreiben. Deshalb benotigen wir eine Metho-
de, um wiederkehrendes Verhaltens durch eine k urzere Notation zu beschreiben.
Beispiel: Eine Uhr, die nichts anderes tut als: tick, tick, tick, ...
(CLOCK) = tick und (tick) CLOCK
So wird die Uhr rekursiv beschrieben durch:
CLOCK = (tick CLOCK).
Auswahl
Mit der Prax-Notation und der Rekursion ist es nur moglich Objekte mit nur
einem einzigen Verhaltensstrom zu beschreiben. Viele Objekte andern jedoch ihr
Verhalten durch Interaktion mit der Umgebung. F ur die Auswahl eines Ereignisses,
welches eine Interaktion mit der Umgebung darstellt, nutzen wir die Auswahl-
Notation:
[.
(x P [ y Q) beschreibt ein Objekt, f ur welches entweder das Ereignis x oder
y greift. Wenn zuerst das Ereignisse x auftritt, dann folgt darauf das Verhalten des
Objekts wie in P beschrieben. Umgekehrt, wenn zuerst Ereignis y auftritt, dann
folgt das Verhalten des Objekts wie in Q beschrieben. Da x und y verschiedene
Ereignisse sind, wird die Wahl zwischen P und Q durch das zuerst auftretende
Ereignis bestimmt. Es gilt:
(x P [ y Q) = P, wenn x, y P und P = Q.
Gesetze
L 1 (x : A P(x) = (y : B Q(y)) (A = B x : A P(x) = Q(x))
Gibt an, dass zwei durch Auswahl denierte Prozesse identisch sind, falls das nach-
folgende Verhalten jeweils gleich ist. Ist das Verhalten nach dem ersten Schritt
jedoch unterschiedlich, so sind auch die Prozesse unterschiedlich.
L 2 (Y = F(Y ) (Y = X F(X))
Gilt, wenn F(X) ein uberwachter Ausdruck ist.
L 3 falls (i : S (X
i
= F(i, X) Y
i
= F(i, Y ))) dann X = Y
6.1.2 Spuren und Operationen auf Spuren
Eine Spur gibt das Verhalten eines Prozesses als eine endliche Folge von Ereig-
nissen bis zu einem bestimmten Zeitpunkt wieder. Sie wird in spitzen Klammern
und als eine Folge von durch Komma getrennten Symbolen notiert:
< x, y > besteht aus zwei Ereignissen, x gefolgt von y
< x > enthalt nur Ereignis x
<> ist leere Abfolge, enthalt kein Ereignis
Spuren spielen eine zentrale Rolle bei der Aufzeichnung, Beschreibung und dem
Verstandnis des Verhaltens von Prozessen. Es gilt folgendes:
s, t, v werden als Spuren bezeichnet
S, T, U werden als Mengen von Spuren bezeichnet
f, g, h werden als Funktionen bezeichnet
Verkettung
Die wichtigste Operation auf Spuren ist die Verkettung. Aus einem Paar von
Operanden s und t wird durch Zusammensetzung eine neue Spur konstruiert.
Die mit s
t bezeichneten Spuren s und t werden gema ihrer Reihenfolge zu st

zusammengesetzt z.B.
< a, b >
< a, c >=< a, b, a, c >

Es gelten dar uber hinaus folgende Gesetze:
L 4 s
<>=<>
s = s
L 5 s
(t
u) = (s
t)
u
L 6 s
t = s
u t = u
L 7 s
t = u
t s = u
Beschrankung
Der Ausdruck (t A) bezeichnet die Symbole von Spur t mit der Beschrankung
auf die Symbole der Menge A. Alle Symbole, die nicht in der Menge A enthalten
sind werden weggelassen. Beispiel:
< a, b, a, c, e > b, e =< b, e >
6.1 Prozesse 67
Weiterhin gelten folgende Gesetze:
L 8 <> A =<>
L 9 (s
t) A = (s A)
(t A)
L 10 < x > A =< x > falls x A
L 11 < y > A =<> falls y / A
L 12 s =<>
L 13 (s A) B = s (A B)
Stern
Die Menge A
ist die Menge aller endlichen Spuren, die mit den Symbolen in der
Menge A gebildet werden konnen. A
ist deniert durch:

A
= s [ s A = s
Es gelten folgende Gesetze:
L 14 <> A
L 15 < x > A
x A
L 16 (s
t) A
s A
t A
Lange
Die Lange einer Spur t wird mit #t bezeichnet, z.B. # < a, b, c >= 3.
L 17 # <>= 0
L 18 < x >= 1
L 19 (s
t) = (#s) + (#t)
6.1.3 Spuren eines Prozesses
Die Spur eines Prozesses ist die sequentielle Aufzeichnung seines Verhaltens bis
zu einem bestimmten Zeitpunkt. Wie die Spur eines Prozesses aussieht, ist beim
Start des Prozesses unbekannt. Die komplette Menge aller moglichen Spuren eines
Prozesses P kann jedoch im Voraus bekannt sein. Die Funktion traces(P) ist so
deniert, dass sie alle Mengen von Spuren eines Prozesses liefert, z.B.
traces(STOP) = <>.
Gesetze
L 20 traces(STOP) = t [ t =<> = <>
Das Verhalten des Prozess STOP ist nur die leere Spur.
L 21 traces(c P) = <> < c >
t [ t traces(P)
Jede nichtleere Spur beginnt mit c, gefolgt von einer moglichen Spur von P.
Nach-Operator
Falls s traces(P) dann ist P/s
2
ein Prozess, der sich wie P verhalt, nachdem
alle Ereignisse von Spur s aufgetreten sind. Folgende Gesetze gelten f ur den /
Operator:
L 22 P/ <>= P
Nach einer leeren Spur bleibt der Prozess unverandert.
L 23 P/(s
t) = (P/s)/t)
Das Verhalten nach s
t ist das Gleiche wie das Verhalten von (P/s) nach t.

L 24 traces(P/ < s >= t [ s
t traces(P) vorausgesetzt s traces(P)

6.2 Parallele Systeme
Mehrere Prozesse konnen zu Systemen zusammengesetzt werden, in denen die
einzelnen Teile untereinander und mit ihrer Umgebung interagieren. Ein solches
System kann selbst als ein Prozess betrachtet werden, dessen Verhalten durch
seine Teilprozesse deniert ist. Das System selbst kann dabei wiederum in einer
weiteren Umgebung enthalten sein.
6.2.1 Interaktion
Sind zwei Prozesse zu einem System zusammengefasst, so sollen sie gewohnlich
miteinander interagieren. Besitzen die Prozesse P und Q das gleiche Alphabet,
so wird die Notation P [ [ Q genutzt, um einen Prozess zu bezeichnen, welcher
sich wie ein System verhalt, in welchem die Prozessen P und Q uber gemeinsame
Ereignisse miteinander interagieren.
Gesetze
L 25 P [ [ Q = Q[ [ P
Zeigt die logische Asymmetrie zwischen einem Prozess und seiner Umgebung.
2
gesprochen P nach s
6.2 Parallele Systeme 69
L 26 P [ [ (Q[ [ R) = (P [ [Q) [ [ R
Die Reihenfolge, in der Prozesse zusammengesetzt werden spielt keine Rolle.
L 27 P [ [ STOP
P
= STOP
P
P [ [ RUN
P
= P
Ein Deadlock (STOP) in einem Prozess f uhrt im ganzen System zu einen Dead-
lock, die Zusammensetzung mit RUN
P
andert jedoch nichts.
L 28 (x : A P(x)) [ [ (y : B Q(y)) = (z : (A B) (P(z) [ [ Q(z)))
Ein nebenlaug deniertes System kann auf andere Weise ohne Nebenlaugkeit
beschrieben werden.
L 29 traces(P [ [ Q) = traces(P) traces(Q)
L 30 (P [ [ Q)/s = (P/s [ [ Q/s)
6.2.2 Nebenlaugkeit
Der Operator [ [ aus dem vorhergehenden Abschnitt, kann verallgemeinert werden,
f ur den Fall, dass die Prozesse P und Q unterschiedliche Alphabete haben. Wenn
solche Prozesse gleichzeitig ausgef uhrt werden, erfordern nur Ereignisse, welche
in beiden Alphabeten enthalten sind, eine gemeinsame Interaktion, andernfalls
nicht. Daher ergibt die Vereinigung der beiden Alphabete das Gesamtalphabet
des Systems:
(P [ [ Q) = P Q wenn P ,= Q.
Beispiel: Ein Zahler beginnt in der Mitte unten einer 2x3 Matrix, und kann sich
nach oben, unten, links oder rechts bewegen. Die Denition:
P = up, down, P = (up down P)
Q = right, left, Q = (right left Q[ left right Q)
beschreibt dann mit der Komposition P [ [ Q das Verhalten dieses Zahlers. Da die
Prozesse P und Q keine gemeinsamen Ereignisse haben, ist die Bewegung des
Zahlers eine beliebige Verschachtelung von P und Q.
Gesetze
L 31 P [ [ STOP
P
= STOP
P
L 32 P [ [ RUN
P
= P
L 33 (c P) [ [ (c Q) = c (P [ [ Q)
L 34 (a P) [ [ (c Q) = a (P [ [ (c Q))
L 35 traces(P [ [ Q) = t [ (t P) traces(P) (t Q) traces(Q) t
(P Q)
Sei t eine Spur von (P [ [ Q), dann ist jedes Ereignis in t, welches zum Alphabet von
P gehort, auch ein Ereignis im Leben von P gewesen. Jedes Ereignis in t, welches
nicht zu P gehort, ist dann ohne die Beteiligung von P aufgetreten. Deswegen
ist (t P) eine Spur von all jenen Ereignissen, bei denen P teilgenommen hat
und ist daher auch eine Spur von P.
6.2.3

Anderung des Symbols
Im Folgenden wird eine einfache Methode vorgestellt, um eine Menge von Prozes-
sen mit ahnlichem Verhalten zu denieren. Sei f eine injektive Funktion, welche
das Alphabet von P auf eine Menge von Symbolen in A abbildet:
f : P A
Nun wird f(P) als ein Prozess deniert, welcher immer f(c) ausf uhrt, wenn c in
P auftritt:
f(P) = f(P)
traces(f(P)) = f
(s) [ s traces(P)
Gesetze
L 36 f(STOP
A
) = STOP
f(A)
Nach

Anderung des Symbols, f uhrt STOP kein Ereignis im geanderten Alphabet
aus.
L 37 f(P [ [ Q) = f(P) [ [ f(Q)
Anderung des Symbols kann durch parallele Kompositionen verteilt werden.

L 38 f(g(P)) = ( f g)(P)
Die Zusammensetzung zweier

Anderungen eines Symbols, wird durch die Zusam-
mensetzung der beiden Funktionen deniert.
6.3 Nichtdeterminismus
Nichtdeterminismus ist eine sinnvolle Technik zur abstrakten Beschreibung von
Systemen. Algorithmen konnen somit nicht nur genau eine Berechnung zu einer
bestimmten Eingabe durchlaufen, sondern sie konnen bei gleicher Eingabe aus
mehreren Moglichkeiten wahlen.
6.3 Nichtdeterminismus 71
6.3.1 Nichtdeterministisches ODER
Wenn P und Q zwei Prozesse sind, dann beschreibt die Notation P Q
3
einen
Prozess, der sich entweder wie P oder wie Q verhalt, jedoch die Auswahl zwischen
ihnen willk urlich erfolgt. Die Alphabete der beiden Operanden wird hierbei als
gleichen angenommen:
(P Q) = P = Q
Gesetze
L 39 P P = P
Die Auswahl zwischen P und P ist gleich P.
L 40 P Q = Q P
Die Reihenfolge der Auswahl spielt keine Rolle.
L 41 P (Q R) = (P Q) R
Die Auswahl zwischen drei Alternativen lasst sich in zwei aufeinander folgenden,
binaren Entscheidungen aufteilen. Die Reihenfolge spielt dabei keine Rolle.
L 42 x (P Q) = (x P) (x Q)
Ein Prozess, der zuerst x ausf uhrt und danach zwischen P und Q wahlt, ist gleich
dem Prozess, der zuerst auswahlt und danach x ausf uhrt.
L 43 P [ [ (Q R) = (P [ [ Q) (P [ [ R)
L 44 (P Q) [ [ R = (P [ [ Q) (Q[ [ R)
L 45 f(P Q) = f(P) f(Q)
Wenn s eine Spur von P ist, dann ist s auch eine mogliche Spur von (P Q) f ur
den Fall, dass P ausgewahlt wurde. Umgekehrt, wenn falls s eine Spur von Q ist,
dann ist s auch eine Spur von (P Q):
traces(P Q) = traces(P) traces(Q).
6.3.2 Allgemeine Auswahl
Die Umgebung von (P Q) hat keinen Einuss bzw. Kenntnis uber die Auswahl,
die zwischen P und Qgetroen wird. Die Umgebung muss daher auf das Auftreten
von P oder Qvorbereitet sein. Mit der verallgemeinerten Operation P2Qkann die
Umgebung beeinussen, welcher Prozess von P und Q ausgewahlt wird. Hierbei
sollte (P2Q) = P = Q erf ullt sein.
3
gesprochen P oder Q
F ur den Fall, dass das initiale Ereignis von P f ur Q keine Moglichkeit ist, verhalt
sich der allgemeine Auswahl-Operator wie der normale Auswahl-Operator:
(c P2d Q) = (c P | d Q) falls c ,= d.
Gesetze
L 46 P2Q = Q2P
L 47 P2(Q2R) = (P2Q)2R
L 48 P2(Q R) = (P2Q) (Q2R)
L 49 P2STOP = P
L 50 P (Q2R) = (P Q)2(Q R)
Spuren
L 51 traces(P2Q) = traces(P) traces(Q)
Jede Spur von traces(P2Q) ist entweder eine Spur von P oder von Q.
L 52 (P2Q)/s = P/s, falls s traces(P) traces(Q)
L 53 (P2Q)/s = Q/s, falls s traces(Q) traces(P)
L 54 (P2Q)/s = (P/s) (Q/s), falls s traces(P) traces(Q)
6.3.3 Ablehnungen
Wenn die Moglichkeit besteht, dass es im Prozess P wahrend seiner ersten Ar-
beitsschritte in der Umgebung X zu einen Deadlock kommt, so ist X eine Ab-
lehnung von P.
Die Menge aller Ablehnungen von P wird bezeichnet mit:
refusals(P).
Gesetze
L 55 refusals(STOP
A
) = alle Teilmengen von A (einschlielich A)
Der Prozess STOP tut nichts und lehnt alles ab.
L 56 refusals(c P) = X[ X (P c
Prozess c P lehnt alle Mengen ab, die das Ereignis c nicht enthalten.
6.3 Nichtdeterminismus 73
L 57 refusals(P Q) = refusals(P) refusals(Q)
Wenn P X ablehnen kann, dann lehnt auch P Q X ab, falls P ausgewahlt
wurde. Ebenso ist jede Ablehnung von Q auch eine mogliche Ablehnung von
P Q.
L 58 refusals(P2Q) = refusals(P) refusals(Q)
Wenn X keine Ablehnung von P ist, dann kann X weder von P, noch von (P2Q)
abgelehnt werden.

Ahnlich gilt, falls X ist keine Ablehnung von Q ist, dann ist
X auch keine Ablehnung von (P2Q).
L 59 refusals(P)
L 60 (X Y ) refusals(P) X refusals(P)
6.3.4 Verbergen
Im Allgemeinen enthalt das Alphabet eines Prozesses nur die f ur ihn relevanten
Ereignisse plus Ereignisse, welche f ur die Interaktion mit der Umgebung notwen-
dig sind. In Wirklichkeit sollen jedoch nur die Ereignisse eines Prozesses sichtbar
sein, welche nicht durch die Umgebung beeinusst werden. Wenn C eine begrenz-
te Menge von Ereignissen ist, welche verborgen werden soll, dann ist PC ein
Prozess, der sich wie P verhalt, bei dem die Ereignisse aus C jedoch verborgen
sind. Das Ziel ist:
(PC) = (P) C.
Gesetze
L 61 P = P
Verbergen einer leeren Menge hat kein Auswirkung.
L 62 (PB)C = P(B C)
Verbergen von Symbolen nacheinander ist gleich dem gleichzeitigen verbergen
aller Symbolen zusammen.
L 63 (P Q)C = (PC) (QC)
Verbergung wird auf die nichtdeterministische Auswahl verteilt.
L 64 STOP
A
C = STOP
AC
Verbergen beeinusst nicht das Verhalten eines gestoppten Prozesses, sondern
nur dessen Alphabet.
6.4 Kommunikation
Die Kommunikation ist ein besonderer Fall der Interaktion zwischen zwei Prozes-
sen, bei der die Ausgabe eines Prozesses gleichzeitig die Eingabe eines anderen
Prozesses ist. Die Kommunikation muss daher synchronisiert ablaufen.
Eine Kommunikation ist ein Ereignis, welche durch die Notation c.v beschrieben
wird, wobei c der Name des Kanals ist, uber den kommuniziert wird und v die zu
ubertragende Nachricht. Die Menge aller Nachrichten, die P uber c kommunizie-
ren kann ist deniert durch:
c(P) = v [ c.v P.
Zusatzlich sind zwei Funktionen deniert, welche den Kanal und die Nachricht
aus einer Kommunikation extrahieren:
channel(c.v) = c, message(c.v) = v.
6.4.1 Ein- und Ausgabe
Sei v in c(P) enthalten, so ist ein Prozess, welcher zuerst v auf dem Kanal c
ausgibt und sich dann wie P verhalt wie folgt deniert:
(c!v P) = (c.v P)
Das einzige Ereignis, worauf dieser Prozess zu Beginn vorbereitet ist, ist das
Kommunikationsereignis c.v.
Ein Prozess, welcher f ur die Eingabe der Nachricht x uber den Kanal c vorbereitet
ist und sich dann wie P verhalt, ist wie folgt deniert:
(c?x P(x)) = (y : y [ channel(y) = c P(message(y)))
6.4.2 Kommunikation
Seien P und Q Prozesse und sei c der Kanal der f ur die Ausgabe von P und f ur
die Eingabe von Q verwendet wird. Die Menge aller Kommunikationen der Form
c.v ist dann die Schnittmenge der Alphabete von P und Q. Wenn diese Prozesse
im System (P [ [ Q) zusammengesetzt sind und gleichzeitig ablaufen, kann eine
Kommunikation c.v nur auftreten, wenn beide Prozesse gleichzeitig dieses Ereignis
ausf uhren, d.h. wenn P den Wert v auf den Kanal ausgibt und Q gleichzeitig den
gleichen Wert v uber c empfangt.
6.5 Sequentielle Prozesse 75
Gesetze
L 65 (c!v P) [ [ (c?x Q(x)) = c!v (P [ [ Q(v))
Die Ausgabe kann somit als ein spezieller Fall der Prax-Operation angesehen
werden und die Eingabe als ein spezieller Fall der Auswahl-Operation.
L 66 ((c!v P) [ [ (c?x Q(x)))C = (P [ [ Q(v))C wobei C = c.v [ v
c
Die interne Kommunikation kann mit Hilfe des Verbergen-Operators aus der par-
allelen Komposition der beiden Prozesse verborgen werden.
6.5 Sequentielle Prozesse
Im Folgenden wird dargestellt, wie die konventionelle sequentielle Programmie-
rung im Rahmen von CSP integriert werden kann.
Wenn ein Prozess alles erreicht hat, wof ur er entworfen wurde, so kann er an-
halten. Einen solchen Prozess bezeichnen wir als erfolgreich terminiert und wir
verwenden daf ur das Ereignis

(erfolgreich). Ein sequentieller Prozess ist ein
Prozess, welcher

in seinem Alphabet enthalt, wobei

das letzte Ereignis ist,
mit dem er beschaftigt ist. Das Ereignis

darf niemals in einer Alternative einer
Auswahl erscheinen:
(x : B P(x))) ist ung ultig falls

B
SKIP
A
= A
SKIP
A
ist dabei ein Prozess der nichts tut, auer erfolgreich zu terminieren.
Wenn ein Prozess eine komplexe Aufgabe erledigen soll, so ist es meist sinnvoll,
die Aufgabe in zwei Teilaufgaben aufzuteilen. Dabei muss die eine Teilaufgabe erst
erfolgreich abgeschlossen werden, bevor mit der anderen Teilaufgabe begonnen
werden kann.
Seien P und Q zwei sequentielle Prozesse mit gleichem Alphabet, dann wird die
sequenzielle Komposition der Prozesse durch P; Q ausgedr uckt. Dies beschreibt
ein Prozess, der sich zunachst wie P verhalt und sich nach erfolgreichem Abschluss
von P wie Q verhalt. Wenn P nicht erfolgreich endet, dann wird auch P; Q
niemals erfolgreich enden.
6.5.1 Gesetze und Mathematische Betrachtung
Die Gesetze zur sequentiellen Komposition von Prozessen sind ahnlich der Ver-
kettung im Abschnitt 6.1.2.
Gesetze
L 67 SKIP; P = P; SKIP = P
L 68 (P; Q); R = P; (Q; R)
L 69 (x : B P(x)); Q = (x : B (P(x); Q))
L 70 (a P); Q = a (P; Q)
L 71 STOP; Q = STOP
L 72 SKIP
A
[ [ SKIP
B
= SKIP
AB
Wenn sequenzielle Operatoren zusammengesetzt sind, kann die Kombination nur
dann erfolgreich terminieren, wenn auch die einzelnen Komponenten erfolgreich
terminieren.
Mathematische Betrachtungen
Operationen auf deterministische Prozesse sind deniert durch die Spuren ihrer
Ergebnisse:
L 73 traces(SKIP) = <>, <

>
Der Prozess SKIP enthalt nur diese zwei Spuren, da er nur erfolgreich terminie-
ren kann.
L 74 traces(P; Q) = s; t [ s traces(P) t traces(Q))
Die Spur von (P; Q) besteht aus der Spur von P und wenn P mit

endet wird
durch die Spur von Q ersetzt.

L 75 P/s = SKIP wenn s
<

> traces(P)
Die sequentielle Komposition von nichtdeterministischen Prozessen bringt eine
Reihe von Problemen mit sich. Ein nichtdeterministischer Prozesse wie SKIP
(c SKIP) erf ullt z.B. nicht das Gesetzt 75. Eine Losung daf ur bietet:
L 76 s
<

> traces(P) (P/s) SKIP
P kann immer terminieren, auch ohne ein alternatives Ereignis f ur die Umgebung
anzubieten.
L 77 CHAOS ; P = CHAOS
Ein divergenter Prozess bleibt divergent, unabhangig von seiner erfolgreichen Ter-
minierung.
L 78 (P Q); R = (P; R) (Q; R)
Eine sequentielle Komposition kann auf eine nichtdeterministische Auswahl auf-
geteilt werden.
6.5 Sequentielle Prozesse 77
6.5.2 Unterbrechungen
Im Folgenden wird eine andere Art der sequentiellen Komposition deniert
(PQ), welche nicht von einer erfolgreichen Beendigung von P abhangt. Statt-
dessen kann der Ablauf von Prozess P durch ein erstes Auftreten eines Ereignisses
von Prozess Q unterbrochen werden. Ist P einmal unterbrochen, kann P nicht
wieder anlaufen.
Daraus folgt, dass die Spur von (PQ) eine Spur von P bis zu einem bestimmten
Punkt ist, an dem eine Unterbrechung auftrat, und darauf dann eine beliebigen
Spur von Q folgt.
(PQ) = P Q
traces(PQ) = s
t [ s traces(P) t traces(Q)
Es wird vereinbart, dass

nicht in P enthalten sein darf.
Gesetze
L 79 (x : B P(x))Q = Q2(x : B (P(x)Q))
Beschreibt, dass der Start von Q durch ein Ereignis aus der Umgebung bestimmt
ist und nicht durch ein Ereignis von P.
L 80 (PQ)R = P(QR)
Beschreibt, dass wenn (PQ) von R unterbrochen werden kann, dann auch P
von (QR) unterbrochen werden kann.
L 81 PSTOP = P = STOPP
Da STOP kein Anfangsereignis anbietet, kann es auch nicht von der Umgebung
ausgelost werden.
L 82 P(Q R) = (PQ) (PR)
Der Unterbrechungs-Operator f uhrt seinen beiden Operanden maximal einmal aus,
daher kann es auf die nichtdeterministische Auswahl aufgeteilt werden.
L 83 CHAOS P = CHAOS = P CHAOS
6.5.3 Zuweisung
Sei x eine Programmvariable, e ein Ausdruck und P ein Prozess, dann ist (x :=
e; P) ein Prozess der sich wie P verhalt, wobei der Anfangswert von x durch den
Anfangswert vom Ausdruck e bestimmt ist. Die Bedeutung der Zuweisung kann
so deniert werden:
(x := e) = (X := e; SKIP).
Gesetzte
In den folgenden Gesetzen stehen x und y f ur Listen von eigenstandigen Varia-
blen, e, f(x) und f(e) stehen f ur Listen von Ausdr ucken, die moglicherweise die
Variablen x oder y enthalten.
L 84 (x := x) = SKIP
L 85 (x := e; x := f(x)) = (x := f(e))
L 86 Falls x, y eine Liste von verschiedenen Variablen ist, dann
(x := e) = (x, y := e, y)
L 87 Falls x, y, z von gleicher Lange wie e, f, g ist, dann
(x, y, z := e, f, g) = (x, y, z := e, g, f)
[1] C.A.R. Hoare, Communicating Sequential Processes. Prentice Hall, 2004.
7 -Kalk
ul
Rene Brothuhn
Inhaltsverzeichnis
7.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.2 Prozesskalk ule . . . . . . . . . . . . . . . . . . . . . . . . 80
7.2.1 Entwicklungsgeschichte . . . . . . . . . . . . . . 80
7.3 CCS - Calculus of Communicating Systems . . . . . . . . 81
7.3.1 Beispiel CCS . . . . . . . . . . . . . . . . . . . . 81
7.3.2 Mobile Prozesse . . . . . . . . . . . . . . . . . . 84
7.4 Der -Kalk ul . . . . . . . . . . . . . . . . . . . . . . . . 84
7.4.1 Strukturelle Kongruenz . . . . . . . . . . . . . . 85
7.4.2 Reduktionsregeln . . . . . . . . . . . . . . . . . . 86
7.4.3 Beispiel Reduktion . . . . . . . . . . . . . . . . . 87
7.4.4 Forschungsergebnisse . . . . . . . . . . . . . . . 87
7.4.5 Anwendung . . . . . . . . . . . . . . . . . . . . . 88
7.1 Einleitung
Schon seit einigen Jahren ist zu beobachten, dass sich die Informatik mit sei-
nen Anwendungen zunehmend von der sequentiellen Abarbeitung hin zu ne-
benlaugen bzw. verteilten und damit auch konkurrierenden Systemen entwickelt.
Dieser Trend ist nicht zuletzt durch die zunehmende Vernetzung und die Entwick-
lung von Mehrkern-Prozessorarchitekturen gekennzeichnet. Viele Eigenschaften
nebenlauger und konkurrierender Systeme sind jedoch noch nicht ausreichend
erforscht. Insbesondere die Programmierung solcher Systeme wirft noch viele Fra-
gen auf. Hierbei spielt immer die Kommunikation und Synchronisation der kon-
kurrierenden Systeme eine groe Rolle.
Zur Erforschung solcher Systeme bieten sich stark abstrahierte, theoretische Kon-
strukte an, welche es erlauben, die entscheidenden Fragestellungen auf ein theo-
retisches, mathematisches Fundament zu stellen. Ein solches Fundament bietet
der -Kalk ul. Das Hauptaugenmerk liegt beim -Kalk ul auf mobile, konkurrieren-
de Systeme, bei denen sich die Kommunikationsstruktur andern kann. Was dies
genau bedeutet, soll in den nachsten Abschnitten beleuchtet werden.
80 7 -Kalk ul
7.2 Prozesskalk ule
Prozesskalk ule beschaftigen sich mit der formalen Beschreibung konkurrierender
und kommunizierender Systeme. Dieses Systeme unterscheiden sich grundlegend
von sequentiellen Systemen. Sie erlauben Interaktion, Kommunikation und Syn-
chronisation zwischen den beteiligten Komponenten. Die zur Verf ugung stehenden
Modellierungswerkzeuge f ur sequentielle Systeme (z.B. Turing-Maschine oder -
Kalk ul) sind gut erforscht, jedoch unzureichend f ur konkurrierende Systeme. Die-
se Unzulanglichkeit f uhrte zur Idee der Prozessalgebren, welche die Modellierung
konkurrierender Systeme erlaubt. Beispiele f ur Prozessalgebren sind:
CSP Communicating Sequential Processes, C.A.R. Hoare
CCS Calculus of Communicating Systems, R. Milner
ACP Algebra of Communicating Processes, J. Bergstra
-Kalk ul, R. Milner
7.2.1 Entwicklungsgeschichte
Um die Einordnung des -Kalk uls besser zu verstehen, soll nun ein kurzer
Uberblick uber die Entwicklungsgeschichte der Prozessalgebren wiedergegeben

werden:
1973 Robin Milner beginnt mit der Entwicklung von CCS, inspiriert durch das
Actor-Modell von C. Hewitt
1978 C.A.R. Hoare veroentlicht erste Version von CSP als imperative Sprache
1980 CSP und CCS entstehen gleichzeitig und beeinussen sich gegenseitig
Hoare entwickelt CSP weiter zu einem algebraischen System
Robin Milner veroentlicht CCS als algebraisches System
Die Prozessalgebren zu dieser Zeit beschranken sich jedoch zunachst auf statische
Kommunikationsstrukturen.
1990 Robin Milner veroentlicht
A Calculus of Mobile Process Der -Kalk ul

Der -Kalk ul kann als eine Erweiterung von CCS f ur veranderbare Kommunikati-
onsstrukturen verstanden werden.
7.3 CCS - Calculus of Communicating Systems 81
7.3 CCS - Calculus of Communicating Systems
Da der -Kalk ul aus dem Kalk ul kommunizierender Systeme (CCS) entstanden ist,
soll zum besseren Verstandnis zunachst dieser Kalk ul hier in Ausz ugen eingef uhrt
werden. Die Syntax von CCS ist wie folgt deniert:
0 leerer Prozess
a.P Aktion a wird ausgef uhrt, danach Prozess P
P + Q Alternative, P oder Q wird ausgef uhrt
P|Q paralleles Ausf uhren von Prozess P und Q
a.P sendet Label a
a.P empfangt Label a
Zu beachten ist, dass die Kommunikation zwischen den Prozessen synchron ist,
d.h. ein Prozess, der ein Label empfangt, muss warten, bis ein anderer Prozess
dieses Label sendet. Umgekehrt muss der sendende Prozess warten, bis ein anderer
Prozess ein Label mit den entsprechenden Namen empfangt. Auf diese Weise
konnen sich Prozesse synchronisieren:
a.A[a.B wird nach der Kommunikation uber a zu A[B
7.3.1 Beispiel CCS
Um den Unterschied von CCS zum -Kalk ul darzustellen, soll nun ein einfaches
Beispiel in CCS entworfen werden. Als Beispiel dient ein Prozess, welcher in ei-
nem Funknetzwerk mit einem Server kommuniziert (z.B. ein Programm auf einem
Notebook). Die Kommunikation soll dabei immer uber den nachstgelegenen Rou-
ter erfolgen. Entfernt sich der Prozess aus dem Empfangsbereich eines Routers,
so soll ihm, um die Verbindung mit dem Server aufrecht zu erhalten, vom Server
eine neue Verbindung zu einem nahergelegenen Router zugewiesen werden.
1
Das Gesamtsystem ist in Abb. 7.1 dargestellt und besteht aus folgenden vier
Komponenten:
dem Prozess P, der uber einen Router mit dem Sever kommuniziert
dem Router RA, uber dem mit dem Server kommuniziert wird
dem Router RB, der bereit ist, die Kommunikation zu ubernehmen
dem Server S, der die Verbindung uber die Router steuert
Der Prozess P darf dabei zu jedem Zeitpunkt nur mit einem Router in Verbin-
dung stehen. Beim Wechsel des Routers muss der Server sicherstellen, dass die
Verbindung zum Prozess nicht verloren geht.

Uber eine Nachricht vom Server
1
In einem realen WLAN-Netzwerk erfolgt die Zuweisung zu einem Router nicht vom Server aus.
82 7 -Kalk ul
S
RA
c
o
m
m
A
s
w
i
t
c
h
_
t
o
B
l
o
o
s
e
A
l
o
o
s
e
B
P
RB
c
o
m
m
B
s
w
i
t
c
h
_
t
o
A
Abbildung 7.1: Einem Prozess wird eine neue Verbindung zugewiesen
erhalt der Prozess die Anweisung, sich mit einem neuen Router zu verbinden.
Wie der Server feststellt, dass sich der Prozess aus dem Empfangsbereich begibt,
soll aus Gr unden der Einfachheit nicht weiter betrachtet werden. Aus gleichem
Grund wird auch nur die Steuerung des Verbindungsstatus betrachtet und der
eigentliche Kommunikationsvorgang zwischen Prozess und Server ignoriert.
Da es zwei Router im System gibt, ergeben sich f ur den Prozess P zwei Zustande:
er kann, wie in Abb.7.2 zu sehen, entweder mit Router A (RA) oder Rou-
ter B (RB) verbunden sein. F ur die jeweilige Verbindung sendet er entweder
die commA oder commBNachricht an den entsprechenden Router, um die
Kommunikation uber diesen Router zu signalisieren. Erhalt er eine switch to
Nachricht, wechselt er in den anderen Zustand.
A B
switch_toA
switch_toB

commA

commB
Abbildung 7.2: Zustandsgraph des Prozesses
Formal konnen die zwei Zustande des Prozesses mit Hilfe von zwei Gleichungen
in CCS beschrieben werden:
P
A
= commA.P
A
+switch toB.P
B
P
B
= commB.P
B
+switch toA.P
A
7.3 CCS - Calculus of Communicating Systems 83
Ist der Prozess im Zustand P
A
, sendet er ein commASignal und bleibt im Zu-
stand P
A
. Alternativ wartet er auf eine switch toBNachricht und wechselt im
Falle ihres Eintreens in den Zustand P
B
. Zustand P
B
funktioniert analog mit
entsprechend geanderten Nachrichten bzw. Zustanden.
In Abb. 7.3 ist der Zustandsgraph f ur Router RA dargestellt. Erhalt RA ei-
ne commANachricht verandert sich nichts und die Verbindung bleibt erhalten.
Empfangt er jedoch eine looseANachricht, sendet er daraufhin eine switch toB
Nachricht, worauf der Prozess P in den Zustand B wechselt. F ur Router RB sieht
RA

switch_toB
looseA
commA
Abbildung 7.3: Zustandsgraph von Router A
der Zustandsgraph ahnlich aus, nur mit entsprechend vertauschten Nachrichten.
Die formale Beschreibung f ur die beiden Router sieht so aus:
RA = commA.RA+looseA.switch toB.RA
RB = commB.RB +looseB.switch toA.RB
Der Server gestaltet sich etwas einfacher. Stellt der Server fest, dass der Prozess
aus dem Empfangsbereich eines Routers verschwindet, sendet er eine entspre-
chende looseNachricht. Die formale Beschreibung des Server ist daher recht
einfach:
S = looseA.S +looseB.S
Durch Parallelausf uhrung aller Komponenten lasst sich nun der Zustand des Sys-
tems aus Abb. 7.1 wie folgt beschreiben:
System = P
A
[RA[S[looseA.RB
Der Prozess P ist zunachst mit Router RA verbunden und bendet sich daher
im Zustand P
A
. Router RA ist gleichzeitig aktiv und erwartet entweder eine
commA oder eine looseANachricht. Um dem Prozess P die neue Verbindung
zuzuweisen, wird am Ende parallel die looseANachricht gesendet und danach
Router RB aktiviert.
2
2
Die looseANachricht sollte durch den Server initiiert werden, aus Gr unden der Einfachheit
wurde jedoch nicht modelliert, wie der Server erkennt, dass der Prozess den Empfangsbereich
verlasst.
84 7 -Kalk ul
7.3.2 Mobile Prozesse
In CCS konnen sich Prozesse nur uber gemeinsam bekannte Labels synchronisie-
ren. Das gezeigte Beispiel im vorhergehenden Abschnitt funktioniert nur, da allen
beteiligten Komponenten die notwendigen Labels bekannt sind. Sollen neue Kom-
ponenten mit neuen Verbindungen in das System integriert werden, m usste allen
Komponenten die neue Verbindung mitgeteilt werden. Da jedoch nur Labels und
keine Informationen ubertragen werden konnen, ist dies in CCS nicht moglich.
Eine einfache Erweiterung des CCS Kalk uls zum

Ubertragen von Informationen
konnte in Anlehnung an [1] wie folgt aussehen:
ax.P sendet uber Kanal a den Wert x
a(y).P empfangt uber den Kanal a einen Wert und bindet ihn an die Variable y
Auf diese Weise ist auch das Versenden eines Kanals als Wert moglich und wir
konnen unser Beispiel aus dem vorhergehenden Abschnitt umstellen.
Damit Prozess P nun keine Kenntnis mehr uber die Kommunikationsstruktur
besitzen muss, bekommt er im Falle des Wechsels zu einem anderen Router die
neue Verbindung zugesendet. Prozess P benotigt daher auch keine Zustande
mehr:
P = communicate.P +switch(communicate).P
Uber den switchKanal bekommt P einen neuen Kommunikationskanal zuge-

sendet und wird der Variablen communicate zugewiesen. Zugleich bedeutet der
Empfang von switch ein Wechsel des Kommunikationskanals. In der Alternati-
ve communicate.P wird die Variable communicate verwendet und so uber den
neuen Kanal kommuniziert.
Schauen wir uns zunachst den Server an. Dieser sendet nun uber den jeweiligen
Kanal die neue Verbindung.

Uber den Kanal looseA sendet er dem Router RA
die Verbindung zum Router RB, umgekehrt uber looseB die Verbindung zu RA:
S = looseAcommB.S +looseBcommA.S
Die beiden Router m ussen jetzt nur noch die uber loose erhaltene neue Verbin-
dung uber den switchKanal an den Prozess P weiterreichen:
RA = commA.RA+looseA(commB).switchcommB.RA
RB = commB.RB +looseB(commA).switchcommA.RB
7.4 Der -Kalk ul
Mit Hilfe der vorgestellten Erweiterung f ur CCS zum

Ubertragen von Informa-
tionen ist man dem -Kalk ul schon sehr nahe. Laut [1, Seite 6] scheint jedoch
7.4 Der -Kalk ul 85
die Unterscheidung zwischen Variablen, Kanalen und Werten f ur ein Kalk ul zu
aufwandig zu sein. Zwischen den Begrien Variablen, Kanale und Werte soll da-
her nicht weiter unterschieden und daf ur nur noch der Begri Name verwendet
werden. Ein Prex, z.B. a.P, wird dadurch zu einem Platzhalter f ur einen Namen,
welcher als Eingabe empfangen werden kann. Bei jeder Kommunikation wird nun
nur noch ein Name empfangen bzw. gesendet, woraufhin weitere Kommunikation
ausgef uhrt werden kann. Diese einfache Denition reicht aus, um jegliche Art von
Berechnung auszudr ucken. Der -Kalk ul wird dadurch zum universellen Kalk ul
f ur konkurrierende Systeme, ahnlich dem -Kalk ul f ur Funktionen[1, Seite 7].
Im Folgenden soll die Syntax des -Kalk uls dargestellt werden. Aufgrund der
besseren Verstandlichkeit wird in der Beschreibung der Regeln die Unterscheidung
zwischen Kanalen und Werten beibehalten:
0 leerer Prozess
ax.P sendet uber Kanal a den Wert x
a(y).P empfangt uber den Kanal a einen Wert y
.P Tau-Operation, eine von auen nicht beeinussbare Aktion
P + Q Altenative, P oder Q wird ausgef uhrt
P|Q paralleles Ausf uhren von Prozess P und Q
(a).P erzeugt einen neuen Kanal a in P ( - Aussprache n u/new)
!P repliziert P, Replikate laufen parallel
Es ist anzumerken, dass die Kommunikation wie bei CCS synchron bleibt. Die
vorgestellte Syntax ist jedoch nur eine Moglichkeit, in der Literatur nden sich
unterschiedliche Denitionen, mit mehr oder weniger Regeln, prinzipiell gleichen
sie sich jedoch alle.
7.4.1 Strukturelle Kongruenz
Mit Hilfe der strukturellen Kongruenz lassen sich Prozessausdr ucke abstrahieren
und Prozesse auf

Aquivalenz untersuchen. Zwei Prozesse sind strukturell kongru-
ent, wenn sie eine identische Struktur besitzen. Die KongruenzBeziehung wird
mit Hilfe von ausgedr uckt.
Folgende Beziehungen denieren die strukturelle Kongruenz:
P Q wenn gebundene Namen umbenannt sind (-Konversion) (7.1)
(x)0 0; (x)(y)P (y)(x)P (7.2)
(x)(P[Q) (x)P[Q wenn x nicht in Q vorkommt (7.3)
P[Q Q[P; (P[Q)[R P[(Q[R); P[0 P (7.4)
!P P[!P (7.5)
86 7 -Kalk ul
Viele dieser Beziehungen sind mehr oder weniger selbsterklarend:
Bei 7.1 (-Konversion) werden f ur die gleichen Objekte lediglich unterschiedli-
che Namen verwendet, da sie beim Senden an einen anderen Prozess an einen
anderen Namen gebunden werden konnen.
Nach 7.2 kann ein neu erzeugter Name in einem leeren Prozess an keinen
anderen Prozess gesendet werden. Unabhangig davon kann die Reihenfolge
der Erzeugung neuer Namen vertauscht werden.
Beziehung 7.3 zeigt, wenn ein Name in einem parallelen Prozess nicht vor-
kommt, muss er auch nicht an diesen Prozess gebunden werden. Die -
Konversion kann helfen einen gebundenen Namen zu entfernen, siehe Beispiel
in Abschn. 7.4.3.
Nach Beziehung 7.4 ist die Reihenfolge nebenlauger Aktionen nicht relevant.
Replizierte Prozesse laufen nach Beziehung 7.5 parallel und lassen sich durch
Parallelausf uhrung aufrollen.
7.4.2 Reduktionsregeln
Uber die strukturelle Kongruenz hinaus lassen sich manche Prozesse reduzieren.
Eine Reduktion wird ausgedr uckt durch P Q. Dies bedeutet, dass P in einem
einzelnen Berechnungsschritt in Q umgewandelt werden kann.
Die wichtigste Reduktionsregel ist folgende:
xz.P[x(y).Q P[Q[z/y] (7.6)
Sie besagt, dass paarweise Kommunikation (Senden und Empfangen) reduziert
und in einem Schritt ausgef uhrt werden kann. [z/x] bezeichnet eine -Konversion,
jedes Vorkommen von y in Q wird durch den Namen z ersetzt.
Die weiteren Reduktionsregeln sind wieder mehr oder weniger selbsterklarend:
wenn P Q dann ist auch P[R Q[R (7.7)
wenn P Q dann ist auch (x)P (x)Q (7.8)
P P
und P
und Q
Q dann ist auch P Q (7.9)

Regel 7.7 besagt, dass parallele Aktionen nicht beeintrachtigt werden. Wenn
ein Prozess R parallel neben P laufen kann, so kann er auch neben Q laufen.
Regel 7.8 besagt, dass ein gebundener Name erhalten bleibt.
Regel 7.9 besagt, dass strukturell kongruente Prozesse reduziert werden
konnen.
7.4 Der -Kalk ul 87
7.4.3 Beispiel Reduktion
Mit Hilfe der Reduktionsregeln und der strukturellen Kongruenz soll nun ein Pro-
zessausdruck vereinfacht werden. Gegeben ist folgender Prozess:
(x)(xz.0[x(y).yx.0)
Es handelt sich um zwei nebenlauge Komponenten, die uber den Kanal x mit-
einander kommunizieren. Der erste Prozess sendet uber x den Namen z und
terminiert daraufhin. Der zweite Prozess empfangt zunachst uber x den zuvor
gesendeten Namen z und bindet ihn an y.

Uber y (und damit das urspr ungliche z
aus dem ersten Prozess) wird dann x gesendet und der zweite Prozess terminiert.
Durch Anwenden der Regel 7.6 wird jedes y durch z ersetzt und wird daher
zunachst zu:
(x)(xz.0[x(z).zx.0)
Da nun die paarweise Kommunikation oensichtlich ist, kann diese nun ebenfalls
durch Regel 7.6 reduziert werden:
(x)(0[zx.0)
Zieht man nun noch die Beziehung 7.4 hinzu folgt:
(x)(zx.0)
Weiter lasst sich der Prozess nicht vereinfachen. Es ist zu erkennen, dass die
Aufgabe des gesamten Prozesses darin besteht, den gebundenen Namen x uber
den Kanal z zu versenden.
7.4.4 Forschungsergebnisse
Aufgrund des einfachen Aufbaus des -Kalk uls eignet es sich gut zum Erforschen
konkurrierender Systeme. Einige wichtige Ergebnisse sollen nun kurz vorgestellt
werden.
Turingvollstandigkeit
Turingvollstandigkeit besagt, dass ein System in der Lage ist, alles zu berech-
nen, was sich nach der Berechenbarkeitstheorie berechnen lasst [5]. In [4] wurde
eine Moglichkeit aufgezeigt, wie der -Kalk ul mit Hilfe des -Kalk uls simuliert
werden kann. Da der -Kalk ul turingvollstandig ist, ist damit auch die Turing-
vollstandigkeit des -Kalk uls bewiesen.
88 7 -Kalk ul
Synchrone Kommunikation ist ausdrucksstarker als asynchrone
Der -Kalk ul arbeitet synchron. Es ist seit langeren bekannt, dass sich mit Hilfe
einer
Nachricht in Sendung asynchrone Kommunikation mit synchroner Kom-

munikation modellieren lasst. Die Frage, ob dies auch andersherum gilt wurde in
[6] mit nein beantwortet.
-Kalk ul hoherer Ordnung ist nicht ausdrucksstarker
Ein -Kalk ul hoherer Ordnung kann neben Namen auch ganze Prozesse als Nach-
richt versenden. Es konnte jedoch gezeigt werden, dass das Senden der Referenz
(Kanal, Name) auf einen Prozess die gleiche Ausdrucksstarke besitzt [3].
7.4.5 Anwendung
Der -Kalk ul ist ein theoretisches Instrument zur Darstellung von kommunizieren-
den Prozessen. Er kann insbesondere zur Modellierung von mobilen, kommunizie-
renden Prozessen eingesetzt werden, da er im Gegensatz zu CSP oder CCS den
Aspekt mobiler Systeme ber ucksichtigt. Praktische Anwendungen lassen sich auf-
grund der Einfachheit des Kalk uls jedoch nur sehr aufwendig darstellen. Dennoch
gibt es einige Bereiche, in dem der -Kalk ul eingesetzt wird:
Uberpr ufung der Richtigkeit von Kommunikationsprotokollen (z.B. in ad-hoc

Netzwerken)
Anwendung in der Molekularbiologie, um zellulare Kommunikation zu be-
schreiben
Theoretischer Hintergrund f ur die Business Process Modeling Language
(BPML)
Programmiersprachen Occam- oder Pict
[1] R. Milner, J. Parrow and D. Walker, A Calculus of Mobile Processes, Part I.
University of Edingburgh, 1990.
[2] R. Milner, J. Parrow and D. Walker, A Calculus of Mobile Processes, Part II.
University of Edingburgh, 1990.
[3] R. Milner, The Polyadic -Calculus: a Tutorial. University of Edingburgh,
1991.
[4] R. Milner, Functions as Processes. Mathematical Structures in Computer
Science, 1992.
[5] Wikipedia, Turingvollstandigkeit. http://de.wikipedia.org/wiki/Turing-Voll-
standigkeit, 2011
[6] C. Palamidessi, Comparing the Expressive Power of the Synchronous and the
Asynchronous -calculi. Math. Struct. in Comp. Science, 2002.
90 7 -Kalk ul
8 Concurrency in Go
Benjamin L udicke
Inhaltsverzeichnis
8.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.1.1 Communicating Sequential Processes (CSP) . . . 92
8.2 CSP in Go . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.2.1 Go Routine . . . . . . . . . . . . . . . . . . . . . 93
8.2.2 Kommunikation zwischen Threads . . . . . . . . 94
8.2.3 Kommunikation uber das Netzwerk . . . . . . . . 97
8.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
8.1 Einleitung
Manche von Ihnen konnen sich vielleicht noch an die Zeit erinnern, wo es keine
Mehrkernprozessoren gab, Programme strikt sequentiell abliefen und paralleles
arbeiten nur in anspruchsvollen Anwendungen stattfand. In dieser Zeit ist auch
die Programmiersprache C++ entstanden. In der System- und Anwendungspro-
grammierung ist C++ bis heute eine der am meisten eingesetzten Programmier-
sprachen. Viele aktuelle Anwendungen die wir in unserem Alltag nutzen wurden
in C++ erstellt und es kommen standig weitere Anwendungen hinzu, welche
neuen Anforderungen gen ugen m ussen. Die neuen Anforderungen stellen auch
hohere Anspr uche an die Hardware, wobei der Trend nicht zu hoheren Takt-
frequenzen f uhrt, sondern Mehrkernprozessoren eingesetzt werden um paralleles
Rechnen zu ermoglichen. Nat urlich gibt es in Hochsprachen wie in C++ oder
in Java Moglichkeiten diese Anforderung umzusetzen, allerdings sind diese nicht
einfach zu handhaben und somit konnen schnell Fehler entstehen. Google hat die
neue Programmiersprache Go unter Ber ucksichtigung des neuen Trends entwickelt
und ermoglicht ein leichtes Erzeugen von Multithreaded Software. Dabei orien-
tiert sich Go an der von Tony Hoare entwickelten Prozessalgebra
Communicating
Sequential Processes (CSP), siehe auch Kapitel 8.1.1. Damit man sich vorstel-
len kann, was CSP genau ist, wird im nachsten Unterkapitel kurz die Verwen-
dung von CSP vorgestellt. Danach wird gezeigt wie einfach Nebenlaugkeit in Go
umgesetzt werden kann und wie Threads untereinander kommunizieren konnen.
92 8 Concurrency in Go
Anschlieend wird auf die Feinheiten bei der Kommunikation eingegangen und
an kleinen Beispielen verdeutlicht. Somit ist dieser Artikel auch gleich ein kleines
Tutorial, welches die wichtigsten Eigenschaften zum Thema
Nebenlaugkeit in
Go vorstellt.
8.1.1 Communicating Sequential Processes (CSP)
Zunachst sei gesagt, dass dieser kurze Abschnitt bei weitem nicht ausreichen
w urde, um CSP umfassend zu erlautern. F ur eine ausf uhrliche Beschreibung von
CSP wird das Standardwerk von Tony Hoare empfohlen [1]. In diesem Abschnitt
werden ausschlielich kleine Ausschnitte dargestellt, um zu zeigen welcher Teil,
laut dem Autor, von CSP als Inspiration f ur die Programmiersprache Go diente.
CSP ist ein mathematisches Konzept, um Interaktionen zwischen Prozessen dar-
zustellen [1, S. v]. In CSP wird davon ausgegangen, dass alle nebenlaugen Syste-
me Prozesse sind und diese durch sogenannte Events charakterisiert werden. Ein
Prozess P mit den Events a, b und c ist in Listing 8.1 dargestellt.
1 P = {a, b, c}
Listing 8.1: Ein Prozess in CSP
In CSP ist es moglich, dass parallel laufende Prozesse untereinander kommu-
nizieren konnen. Dies geschieht uber Kanale, welche ein Event ubertragen. Im
folgenden Beispiel (siehe Listing 8.2) wird davon ausgegangen dass v ein Event, c
ein Kanal und P ein Prozess ist. Das Ausrufezeichen ist ein Symbol und bedeutet,
das ein Prozess in einen Kanal schreibt.
1 (c!v -> P)
Listing 8.2: Ein Prozess P schreibt v in einen Kanal c
In diesem Beispiel wird beschrieben, wie ein Prozess ein Event v in den Kanal
c schreibt und sich anschlieend wie der Prozess P verhalt. In Listing 8.3 ist
dargestellt, wie ein Prozess einen Wert aus einem Kanal liest.
1 (c?x -> P(x))
Listing 8.3: Ein Prozess P liest x aus einem Kanal c
In diesem Beispiel wurde verdeutlicht, wie ein Prozess, ein Event x aus dem Kanal
c liest und sich anschlieend wie der Prozess P(x) verhalt.
Das waren nat urlich nur sehr kleine Beispiele uber CSP, aus dem Buch von Tony
Hoare [1]. Wenn man CSP verstanden hat, kann man damit die komplette Prozess-
8.2 CSP in Go 93
kommunikation abbilden und somit mogliche Deadlocks, Livelocks usw. erkennen
und dadurch versuchen vermeiden. Somit wird CSP zum Beispiel oft genutzt,
um sicherheitskritische Anwendungen in Luft- und Raumfahrt zu verizieren. Die
eben gezeigten Beispiele, enthalten auch den wesentlichen Bestandteil dessen,
was in Go umgesetzt wurde. Gemeint ist damit das Kommunizieren zwischen
nebenlaugen Prozessen uber Kanale, welches in den nachsten Kapiteln naher
betrachtet wird.
8.2 CSP in Go
Im Kapitel 8.1.1 wurde kurz dargestellt wie Prozesse untereinander kommunizie-
ren. Das Konzept zur Kommunikation zwischen nebenlaugen Prozessen wurde
von den Go-Entwicklern umgesetzt und somit ist es moglich, in Go Kanale zur
Kommunikation einzusetzen. Damit jedoch Kanale genutzt werden konnen, ist es
notwendig Prozesse oder Threads zu erzeugen. In dem nachfolgenden Abschnitt
wird das Erzeugen von Threads beschrieben und danach genauer auf die Umset-
zung von Kanalen in Go eingegangen.
8.2.1 Go Routine
Das Erzeugen von Threads in Go ist sehr einfach. Es ist nicht notwendig, dass
eine Klasse ein Interface oder bestimmte Methoden implementieren muss. In Go
kann jede Funktion ein Thread sein. Das Starten eines Threads wird durch das
Schl usselwort go erreicht.
1 package main
2 import ("fmt"
3 "time")
4
5 func printDelay(v string){
6 time.Sleep(1*1e9)
7 fmt.Println(v)
8 }
9
10 func main(){
11 go printDelay("Hallo Welt!")
12 time.Sleep(2*1e9)
13 }
Listing 8.4: Thread starten mit dem Schl usselwort go
Das Beispiel im Listing 8.4 zeigt ein vollstandiges Programm in dem zwei Me-
thoden implementiert sind. Die Methode printDelay(v string) in Zeile 5 gibt
eine Zeichenkette, um eine Sekunde verzogert, auf der Konsole aus. Die Me-
thode main() in Zeile 10 muss in jedem Go-Programm vorhanden sein und
wird automatisch beim Programmstart ausgef uhrt. In Zeile 11 wird die Methode
printDelay(v string) durch Angabe des Schl usselwortes go als Thread ge-
startet. Weil in Go alle Threads spatestens terminieren, wenn die Hauptfunktion
beendet wird, ist es notwendig zu warten bis alle Threads beendet wurden [2].
In Zeile 12 wird deshalb etwas langer gewartet, als der zuletzt gestartete Thread
zum Abarbeiten benotigt. Das ist nat urlich nicht sehr elegant, aber funktioniert
auch. Im folgenden Abschnitt wird gezeigt, wie man das besser umsetzen kann.
8.2.2 Kommunikation zwischen Threads
Dieser Abschnitt macht den Hauptteil des Kapitels aus. Hier wird verdeut-
licht, wie Threads und Prozesse mittels Kanale untereinander kommunizieren
konnen. In den folgenden Abschnitten wird dabei auf die verschiedenen Anwen-
dungsmoglichkeiten und Besonderheiten von Kanalen in Go eingegangen.
Grundlagen zu Kanalen
Ein Kanal wie er in CSP verwendet wird, ist in Go ein Datentyp namens
Channel.
Ein Kanal ist ein Objekt welches zur Kommunikation und Synchronisation genutzt
werden kann. In Listing 8.5 ist beschrieben, wie in Go ein Kanal mit oder ohne
Initialisierung deklariert werden kann.
1 c := make(chan string) //Deklaration und Initialisierung
2 var c chan string //nur Deklaration
Listing 8.5: Erzeugen eines Kanals
Hierbei wird ein Kanal erstellt, welcher in der Lage ist Werte vom Typ String zu
transportieren. Um einen Wert in einen Kanal zu schreiben oder aus einem Kanal
zu lesen, gibt es in Go spezielle Operatoren. Der Ausdruck MeinChannel<- wird
genutzt um in einen Kanal zu schreiben und der Ausdruck <-MeinChannel um
aus einen Kanal zu lesen. In Listing 8.6 wird der vorher gezeigte Beispielcode so
modiziert, dass ein Kanal zur Kommunikation eingesetzt wird und somit das
Warten auf den Thread mit Hilfe der Funktion time.Sleep() ersetzt werden
kann.
1 ...
2 func printDelay(c chan string){
3 time.Sleep(1*1e9)
8.2 CSP in Go 95
4 c<-"Hallo Welt!"
5 }
6
7 func main(){
8 c := make(chan String)
9 go printDelay(c)
10 fmt.Println(<-c)
11 }
Listing 8.6: Kommunikation uber Channel
Wie in dem Beispiel zu erkennen ist, wird in der Hauptfunktion zuerst ein Kanal
initialisiert, um Daten vom Typ String transportieren zu konnen. Dieser Kanal
wird der Methode printDelay(c chan string) ubergeben, welche durch das
Schl usselwort go in einem Thread gestartet wird. Die Fortf uhrung der Hauptfunk-
tion wird in Zeile 11 blockiert, da noch kein Wert aus dem Kanal gelesen werden
kann. Das Schreiben in den Kanal erfolgt in Zeile 5, worauf die Hauptfunktion
einen Wert aus dem Kanal lesen kann und diesen auf der Konsole ausgibt. Ein
Kanal verhalt sich demnach ahnlich wie eine
BlockingQueue in Java und kann

zur Synchronisation genutzt werden.
Gepuerte und nicht blockierende Kanale
Nicht immer ist es gewollt, dass ein Thread sofort blockiert, wenn der Kanal
schon ein Element enthalt. Um dieses Verhalten zu verandern, kann ein Kanal
mit einem Puer ausgestattet werden. Somit konnen mehrere Elemente in den
Kanal geschrieben werden, bis dieser seine maximale Kapazitat erreicht hat. Das
Listing 8.7 zeigt einen Kanal f ur Werte vom Typ Integer, welcher in seinem
Puer 20 Elemente aufnehmen kann.
1 c := make(chan int, 20)
Listing 8.7: Ein gepuerter Kanal
Ein gepuerter Kanal ist laut Autor von Vorteil, wenn die Leser unregelmaig
Werte aus dem Kanal verarbeiten, aber prinzipiell nicht langsamer als die Schreiber
sind. Ein Puer in einem Kanal ist jedoch kein Garant, dass die Schreiber oder
die Leser nicht blockieren. Einen Kanal mit unendlich groem Puer kann in Go
nicht umgesetzt werden, da die Puergroe technisch bedingt immer begrenzt sein
wird. Eine Umgehung des Problems ist die so genannte
Komma, Ok Syntax,
die ein Blockieren des Threads vermeidet [2]. Somit ist es nicht von Relevanz ob
ein Kanal gepuert/nicht gepuert oder der Puer voll/leer ist. Beim lesenden
Zugri auf einen Kanal sieht das folgendermaen aus (siehe Listing 8.8).
1 element, ok = <-c
Listing 8.8:
Komma Ok Syntax beim Lesen

Die Variable element hat den gleichen Datentyp wie die Werte im Kanal c und
die Variable ok hat einen Booleschen Typ. Wenn das Lesen eines Wertes aus dem
Kanal erfolgreich war, wird der Wert der Booleschen Variable auf true gesetzt
und die Variable element erhalt den ausgelesenen Wert. Falls es nicht moglich
war einen Wert aus dem Kanal zu lesen, weil dieser leer war, wird die Boolesche
Variable auf false gesetzt und die Variable element bekommt den Nullwert des
jeweiligen Typs. Bei einer Variablen des Datentyps Pointer, ware das der Wert nil
[3]. Wenn ein schreibender Thread nicht blockiert werden soll, sieht die
Komma,
Ok Syntax ahnlich aus, wie in Listing 8.9 zu erkennen ist.
1 ok := c<-"Hallo Welt!"
Listing 8.9:
Komma Ok Syntax beim Schreiben

In diesem Beispiel wird versucht den String Hallo Welt! in den Kanal c zu
schreiben. Wie auch bei dem vorherigen Beispiel nimmt die Variable den Wert
true bei Erfolg und den Wert false bei Misserfolg an. Der Wert der Variable
ok kann danach mit einer if-Anweisung abgefragt werden.
Select-Anweisung auf Kanale
Soll in einem Thread aus mehreren Kanalen gelesen werden, ist es nicht unbe-
dingt performant, wenn er bei jedem Kanal nacheinander so lange blockiert bis
ein Wert gelesen werden kann. Dar uber hinaus ware der Code durch die vielen
if-Verzweigungen schwerer zu verstehen, wenn man die
Komma, Ok Syntax
einsetzen w urde. Aus diesem Grund ist es in Go moglich eine select-Anweisung
auf Kanale anzuwenden. Die select-Anweisung ahnelt der switch-Anweisung in
Go, ist allerdings auf Kanale beschrankt.
1 select {
2 case v := <-c1: //mach was mit v
5 }
Listing 8.10: Select-Anweisung auf Kanale
In dem eben gezeigten Beispiel 8.10 existieren in einem Thread die drei Kanale c1,
c2 und c3 aus denen ein Wert gelesen und in der Variable v abgespeichert werden
8.2 CSP in Go 97
soll. Durch die select-Anweisung ist es moglich auf alle drei Kanale gleichzeitig zu
warten. Sobald einer der Kanale einen Wert liefert, wird dieser in der Variablen
v abgespeichert. Dabei wird v implizit der passenden Typ zugewiesen. Nach dem
: ist es moglich weiteren Code auszuf uhren. Dies kann zum Beispiel das Starten
eines weiteren Threads sein, dem v als Parameter ubergeben wird. Wie auch bei
der
Komma, Ok Syntax ist es moglich das blockierende Verhalten zu umgehen.

Umgesetzt wird das durch die Angabe eines default-Blocks, wie es im nachsten
Beispielcode dargestellt wird. Weil die select-Anweisung nur einmal ausgef uhrt
werden w urde, ist es moglich diese in einer for-Schleife auszuf uhren und so oft zu
wiederholen, bis die Schleife explizit unterbrochen wird (siehe Listing 8.11).
1 for {
2 select {
6 default: //mach was anderes
7 ...
8 }
9 }
Listing 8.11: Erweiterte select-Anweisung und for-Schleife
8.2.3 Kommunikation uber das Netzwerk
Das besondere an Go ist, dass die Kommunikation uber Kanale nicht nur innerhalb
einer Anwendung funktioniert, sondern auch uber das Netzwerk genutzt werden
kann. Somit ist es moglich, dass auch zwei verschiedene Prozesse untereinan-
der kommunizieren konnen. Durch das Einbinden des Pakets
netchan konnen
typsichere Netzwerkkanale erstellt werden. Netzwerkkanale sind nicht synchroni-
siert und verhalten sich wie gepuerte Kanale [4]. Das Erstellen ist jedoch etwas
komplizierter als es bei den einfachen Kanalen der Fall ist, da ein sogenannter
Exporter und ein
Importer benotigt wird. Die Aufgabe des Exporters ist es

eine gewisse Anzahl an Kanalen bereit zu stellen, mit denen sich der Importer
verbinden kann. Dabei muss jeder Kanal einen eindeutigen Namen haben und die
Datentypen der Kanale m ussen auf beiden Seiten bekannt sein. Das Listing 8.12
zeigt, wie unter Verwendung des Pakets netchan ein Netzwerkkanal exportiert
wird.
1 package main
2 import (."netchan"; f"fmt")
3
4 func main(){
5 send, err1 := NewExporter("tcp", "127.0.0.1:1234")
6 if err1!=nil{
7 f.Println("Fehler beim Erstellen des Exporters!")
8 s := make(chan string)
9 err2 := send.Export("exStringSend", s, Send)
10 if err2!=nil{
11 f.Println("Fehler beim Exportieren des Kanals!")
12 s<-"Wert eins"
13 s<-"Wert zwei"
14 }
15 close(s)
16 }
17 }
Listing 8.12: Bereitstellen eines Netzwerkkanals durch einen Exporter
In Zeile 5 wird ein neuer Exporter angelegt. Dieser bekommt als Parameter das zu
verwendende Protokoll, sowie eine Netzwerkadresse und einen Port auf dem der
Kanal spater zu erreichen ist. In Zeile 8 wird ein normaler Kanal erzeugt, uber dem
spater die Kommunikation stattnden soll. In Zeile 9 wird der zuvor erstellte Kanal
s exportiert und bekommt den Namen exStringSend als Parameter ubergeben.
Des Weiteren wird die Sende-/Empfangsrichtung festgelegt. In diesem Beispiel
bedeutet der Parameter Send, dass der Exporter nur in den Kanal schreiben
kann. In den Zeilen 12 und 13 werden Werte in den Kanal geschrieben, welche
von einem Importer gelesen werden konnen. Ein Importer ist dem Exporter sehr
ahnlich und wird im Listing 8.13 dargestellt.
1 func main(){
2 recv, err1 := NewImporter("tcp", "127.0.0.1:1234")
3 if err1!=nil{
4 f.Println("Fehler beim erstellen des Importers!")
5 r := make(chan string)
6 err2 := recv.Import("exStringSend", r, Recv)
7 if err2!=nil{
8 f.Println("Fehler beim importieren des Kanals!")
9 f.Println(<-r)
10 f.Println(<-r)
11 }
12 close(r)
13 }
14 }
Listing 8.13: Lesen aus einem Netzwerkkanal durch einen Importer
8.3 Fazit 99
Anders als beim Exporter muss diesmal ein Importer erstellt werden, welcher das
Protokoll, die Netzwerkadresse und den Port als Parameter ubergeben bekommt.
Diese Verbindungsdaten m ussen mit denen des Exporters ubereinstimmen, damit
eine Kommunikation stattnden kann. In Zeile 5 wird ein Kanal erstellt, uber den
die gesendeten Informationen empfangen werden konnen. In der Zeile 6 wird der
Kanal mit dem Namen exStringSend importiert. Der Parameter Recv bedeutet,
dass der Importer aus dem Kanal nur lesen kann. In den Zeilen 9 und 10 konnen
nun die zwei gesendeten Werte ausgelesen werden. Soll es moglich sein, dass der
Exporter und der Importer Senden und Empfangen konnen, m ussen zwei weitere
Kanale erstellt werden. Somit kann uber den einen Kanal gesendet und uber den
anderen Empfangen werden.
8.3 Fazit
In diesem Artikel wurde gezeigt, wie einfach es ist mit Go nebenlauge Prozesse
und Threads zu erzeugen. Durch das hohe Abstraktionsniveau beim Starten von
Go Routinen bleibt der Code ubersichtlich und kompakt. Des Weiteren ist die
Kommunikation uber Kanale eine einfache Moglichkeit Threads zu synchronisie-
ren und Informationen auszutauschen. Obwohl es auch in anderen Programmier-
sprachen wie in C++ oder in Java Bibliotheken gibt, welche die Kommunikation
uber Kanale ermoglichen, sind die bereitgestellten Funktionen nicht so einfach
anzuwenden wie in Go. Ob Go sich auerhalb von Google durchsetzen wird, ist
ungewiss. Es ist sicher nicht auszuschlieen, dass Go spater im Android Betriebs-
system eingesetzt wird, um systemnahe Aufgaben zu erledigen. Ein Compiler f ur
die ARM-Architektur existiert bereits [2].
[1] C. A. R. Hoare, Communicating Sequential Processes. Prentice Hall Interna-
tional, 2004.
[2] Rainer Falke, Steen Blass, Programmierung in Google Go. Addison-Wesley,
2010.
[3] Google, The Go Programming Language Specication. http://golang.org/,
2010.
[4] Google, Package netchan. http://golang.org/pkg/netchan/, 2010.
9 Communicating Sequenti-
al Processes f
ur Java
Martin Engel
Inhaltsverzeichnis
9.1 Einf uhrung . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.2 Prozessorientierung in Java mit JCSP . . . . . . . . . . . 102
9.2.1 Hintergrund . . . . . . . . . . . . . . . . . . . . 102
9.2.2 Prozessorientiertes Design . . . . . . . . . . . . . 103
9.3 Die JCSP Bibliothek . . . . . . . . . . . . . . . . . . . . 105
9.3.1 Prozesse . . . . . . . . . . . . . . . . . . . . . . 105
9.3.2 Passive Strukturierungselemente . . . . . . . . . 106
9.3.3 Channels . . . . . . . . . . . . . . . . . . . . . . 106
9.3.4 Alternation . . . . . . . . . . . . . . . . . . . . . 107
9.3.5 Einfache Beispielimplementierung . . . . . . . . . 107
9.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . 109
JCSP ist eine Implementierung der von Tony Hoare im Jahr 1987 entwickelten for-
malen Sprache CSP (siehe Kapitel 6) f ur Java. Sie erlaubt Interaktionen zwischen
nebenlaugen Prozessen und daraus folgend die Entwicklung von prozessorien-
tierten Java Applikationen, deren Verhalten vollumfanglich beschreibbar ist.
9.1 Einf uhrung
Durch die Entwicklung von Mehrkernprozessoren ist es den CPU-Herstellern ge-
lungen, die Leistungsfahigkeit der aktuellen Prozessorgeneration durch die Paral-
lelisierung multipler Prozesse um ein Vielfaches zu steigern. Diese Art der Ver-
arbeitung erlaubt es, mehrere Rechenoperationen in einem Taktzyklus zu erledi-
gen, sofern diese eine parallele Abarbeitung erlauben. Dies entspricht auch der
nat urlichen Verarbeitungsweise, die wir aus unserem Alltag kennen. Dort ndet
eine Zuteilung von Teilaufgaben je nach Fahigkeiten des Mitarbeiters statt, die
dann parallel bearbeitet werden. Der gesamte Prozess besteht aus der Gesamtheit
seiner Teilaufgaben [1].
102 9 Communicating Sequential Processes f ur Java
In der technische Welt nimmt jedoch aufgrund der parallelen Tasks die Komple-
xitat eines solchen nebenlaugen Prozesses stark zu. F ur einen Softwareentwickler
kann es bereits bei kleinen Anwendungen zu unvorhergesehenen Problemen kom-
men, weil konkurrierende Tasks auf gemeinsame Ressourcen zugreifen. Als Beispiel
sei hier das Erzeuger-Verbraucher-Problem zu nennen. Die Synchronisation von
abhangigen Prozessen spielt hier eine wichtige Rolle, damit es nicht zu unvorher-
gesehenen Ergebnissen kommt. M ussen diese Tasks im Verlauf ihres Lebenszyklus
synchronisiert werden, so stellt dies meist zusatzliches Problempotential dar [3].
Dieser Artikel soll einen

Uberblick uber die JCSP Elemente geben, sowie das
grundlegenden Konzept hinter der Klassenbibliothek beschreiben. Eine Beispiel-
implementation zeigt den Aufbau und die Verbindung von Prozessen in einer JCSP
Anwendung.
9.2 Prozessorientierung in Java mit JCSP
In Java existieren bereits zahlreiche Konzepte zur Synchronisation von Threads,
wie z.B. das Monitorkonzept oder der Semaphormechanismus. Zur Kommuni-
kation zwischen Prozessen wird Remote Method Invocation (RMI) bereitgestellt.
Deren Mechanismen sind zwar einfach zu verstehen, jedoch bleibt die Anwendung
der Konzepte oft schwierig und deren Auswirkungen auf die einzelnen Threads
sind nicht immer vorhersehbar [2][3].
Im folgenden Abschnitt werden zunachst die Gr unde beleuchtet, die zur Entwick-
lung von JCSP gef uhrt haben. Anschlieend werden die grundlegenden Elemente
der Bibliothek untersucht.
9.2.1 Hintergrund
Ein Objekt kapselt sowohl Eigenschaften, als auch Methoden zur Anzeige oder
Manipulation dieser Daten und ist stets eine Instanz einer Klasse, die wiederum
zu anderen Klassen in Beziehung steht und dabei deren Verhalten erweitert. Das
heit, dass Klassen in einer Spezialisierungsrelation einer anderen Klasse stehen.
Elemente des objektorientierten Paradigmas, wie etwa Vererbung und Polymor-
phie, sind zwar aus der nat urlichen Welt entnommen und haben das Software-
design revolutioniert, haben jedoch in einigen Bereichen Schwachen. Speziell bei
der prozessorientierten Herangehensweise und hier insbesondere bei nebenlaugen
Prozessen, wirken sie oft storend. Zunachst ist festzuhalten, dass Objekte kein
Eigenleben besitzen. Das heit, dass samtliche Methoden eines Objekts direkt
oder indirekt nur durch einen in der Ausf uhrung bendlichen Thread aufgerufen
werden konnen (Welch nennt diese Eigenschaft: caller-oriented) [3].
9.2 Prozessorientierung in Java mit JCSP 103
Im seriellen objektorientierten Design muss der Mainthread alle Objekte bedienen,
um diese vor ubergehend zu aktivieren. Das ist solange notig wie deren Metho-
den ausgef uhrt werden. In einem nebenlaugen System sind die Objekte direkt
abhangig von der Ausf uhrung durch einen im Sichtbarkeitsbereich bendlichen
Thread. Dar uber hinaus ist es nicht moglich, die Ausf uhrung einer Methode zu
verhindern. Generell spielen die Grenzen eines Objekts eine untergeordnete Rol-
le, weil die Datenkapselung mehr und mehr zusammenbricht. Der Grund daf ur
ist, dass Attribute eines Objekts meist selbst Objekte sind, die dann haug wie-
derum in einer Vielzahl von anderen Objekten Verwendung nden. Durch diese
Umstande besitzt ein Objekt kaum individuelle Kontrolle uber seinen eigenen Le-
benszyklus und seine Attribute. Es droht ein un ubersichtliches Chaos, selbst wenn
ausschlielich primitive Datentypen Verwendung nden. Welch vergleicht diesen
Umstand mit dem Einsatz von globalen Variablen in manchen Programmierspra-
chen [3][4]. Allerdings ist zu beachten, dass die aufgef uhrten Unzulanglichkeiten
nicht aufgrund von Nebenlaugkeit zustande kommen. Es sind Schwachen des
objektorientierten Design.
1
9.2.2 Prozessorientiertes Design
Nebenlauges Verhalten von Objekten in einem System entspricht dem normalen
Verstandnis und sollte daher nicht schwierig zu implementieren sein. Es sollte
eher ein machtiges Hilfsmittel zur vereinfachten Beschreibung eines Systems sein.
Daraus ergibt sich oft bereits eine Performanceverbesserung.
Traditionelle Ansatze zum Anwendungsdesign waren entweder datenorientiert
oder prozessorientiert. Beim datenorientierte Ansatz wird die Struktur der Infor-
mationen und die Beziehungen untereinander modelliert, wohingegen beim pro-
zessorientierten Design die Aktion im Vordergrund steht, die durch ein Software-
artefakt ausgef uhrt wird [5].
Zur Beschreibung von Prozessen und deren Verhalten wurde CSP entwickelt. CSP
ist eine mathematisches Modell zur Spezikation und Verikation von komplexen
Verhaltensweisen, die durch die Interaktion zwischen nebenlaugen Objekten auf-
treten konnen [3]. Zur Anwendungsentwicklung ist es allerdings nicht notig, die
formale Sprache anzuwenden. Die meisten Modelle konnen auch hier durch Dia-
gramme beschrieben werden.
CSP basiert auf Prozessen, Prozessnetzwerken und zahlreichen Arten von Syn-
chronisation und Kommunikation zwischen diesen. Ein Prozessnetzwerk ist auch
wieder ein Prozess, wodurch sich Anwendungen haug in Schichtenarchitekturen
strukturieren lassen[3].
1
Einen Ausweg bietet das aus der funktionalen Programmierung bekannte Konzept von immu-
table data.
Prozesse
Ein Prozess in CSP ist eine Komponente, die sowohl die Datenstruktur, als auch
die Algorithmen zur Manipulation der Daten beinhaltet. Sowohl Daten, als auch
Algorithmen sind im Sichtbarkeitsbereich als private deniert. Das heit, dass die
Auenwelt keinen lesenden oder schreibenden Zugri auf die Daten hat und die
Algorithmen nicht ausf uhrbar sind. Jeder Prozess ist aktiv und f uhrt seine Algo-
rithmen auf seine eigenen gekapselten Daten aus [2]. Untereinander interagieren
Prozesse ausschlielich uber Channels, da sie keinen Zugri auf die Methoden der
Gegenseite haben.
Synchronized Channels
Die einfachste Art der Prozessinteraktion ist synchronisiertes message passing
uber Channels. Vergleichbar ist diese Art der Kommunikation mit einer direkten
Kabelnetzwerkverbindung zweier Hardwaregerate [2].

Prozess A
c
Prozess B
Abbildung 9.1: einfaches Prozessnetzwerk
Das Beispiel in Abbildung 9.1 zeigt zwei Prozesse A und B, die uber einen Chan-
nel verbunden sind. Dieser besitzt keinerlei Kapazitat um Informationen auf-
zunehmen, sondern er ist ausschlielich Medium zur Nachrichten ubertragung.
Damit kein Informationsverlust auftreten kann, muss Channel-Kommunikation
synchronisiert sein [3]. Das bedeutet, dass Prozess A nach dem Senden ei-
ner

Ubertragungseinheit solange blockiert bis Prozess B bereit ist, eine weitere
Ubertragungseinheit aufzunehmen. Dementsprechend blockiert B, wenn A noch

nicht ubertragen hat. Wenn beide Prozesse bereit sind, wird der Transfer initiiert
und die Daten von A in den Zustandsraum von B ubertragen.
Networks
Das prozessorientierte Design basiert auf geschachtelten Prozessen, die ein Netz-
werk bilden. Ein Netzwerk ist damit eine parallele Struktur von Prozessen, die
uber eine Menge von Objekten passiv synchronisiert werden. Jeder Prozess erf ullt
eine Aufgabe f ur seiner Umgebung, die wiederum festlegt, welche Funktion der
Prozess ausf uhren soll. Zusatzlich ubernimmt die Umgebung die Synchronisation
zum Einholen von Informationen und zum Sammeln der Ergebnisse [2].
9.3 Die JCSP Bibliothek 105
Die Kommunikation zwischen Prozessen passiert hier nicht direkt, sondern aus-
schlielich uber die von der Umgebung bereitgestellten Mechanismen. Durch diese
Kapselung wird eine hohe Unabhangigkeit zwischen den Prozessen erreicht, die
ahnlich einer Komponentenschnittstelle wiederverwendet werden kann [2][3].
9.3 Die JCSP Bibliothek
JCSP ist eine Java-Klassenbibliothek, die eine grundlegende Palette von CSP-
Primitiven und eine Vielzahl von Erweiterungen zur Verwendung in Applikationen
anbietet. Ebenfalls in der aktuellen Version 1.1 RC4 enthalten ist ein Wrapperpa-
ket zur Verwendung von Channels in AWT-Widgets und in Grakelementen.
Die JCSP Bibliothek erlaubt Entwicklern Softwaresysteme auf Basis der CSP Syn-
chronisationsprinzipien (Channels, Events, usw.) zu designen, zu implementieren
und zu verizieren. Diese Software ist frei von Gefahren wie Deadlocks, Livelocks,
Starvation oder Race Conditions [3].
In den folgenden Abschnitten werden die grundlegenden Konzepte vorgestellt.
9.3.1 Prozesse
Ein Prozess in JCSP ist die Instanz einer Klasse, welche die Schnittstelle CSPro-
cess implementiert. Das Verhalten eines solchen Prozesses wird durch die Imple-
mentation der run()-Methode deniert. Ein Channel muss jedem Prozess mittels
oentlichem Konstruktor oder Set- und Get-Methoden (solange der Prozess nicht
lauft) bereitgestellt werden.
Wahrend ein Prozess lauft, ist es nicht sicher, Daten uber Zugrismethoden zu
extrahieren. Weiterhin sollten Zugrismethoden ausschlielich durch den Prozess
aufgerufen werden, der das Objekt erstellt hat. Dieser Basisprozess ist ebenfalls
verantwortlich daf ur, die run()-Methode auszuf uhren. Eine Prozessinstanz kann
dabei zwar mehrmals hintereinander, jedoch nicht mehrfach gleichzeitig gestartet
werden. Unterschiedliche Instanzen der selben Klasse konnen dagegen nebenlaug
existieren [3].
Ein laufender Prozess, ist nur f ur seine privaten Felder verantwortlich. Sein Thread
verlasst niemals die Prozessgrenzen und kein fremder Thread kann auf diesen
Bereich zugreifen oder ihn verandern. Jegliche Zustandsveranderung kann nur
mittels Kommunikation uber den Channel erfolgen, wobei die letztendliche Um-
setzung immer vom Prozess selbst ausgehen muss [3]. Beide Kommunikationspart-
ner m ussen aktiv kooperieren, um Informationen untereinander auszutauschen.
9.3.2 Passive Strukturierungselemente
Bei passiven Strukturierungselemente handelt es sich um Knoten, die Prozesse
logisch miteinander verkn upfen und damit die Struktur eines Prozessnetzwerks
herstellen. Um sie beliebig verschachteln und kombinieren zu konnen, sind diese
von der Schnittstelle CSProcess abgeleitet. So gibt es etwa Knoten wie: Parallel,
XOR, AND, sowie zahlreiche andere zur Strukturierung von Prozessen geeignete
Klassen [7].
Wie bereits in Abschnitt 9.3.1 beschrieben, muss nur der Basisprozess mit der
run()-Methode gestartet werden. Die in diesen Prozess verschachtelten Prozesse
und Strukturierungselemente werden je nach Position im Prozessgraph durchlau-
fen.
9.3.3 Channels
Wie in Abschnitt 9.2.2 bereits erwahnt, werden Channels zur Kommunikation
zwischen Prozessen (in Prozessnetzwerken) benotigt. Zu den Wichtigsten zahlen:
One2OneChannel: Erlaubt 1:1 Verbindungen zwischen einem schreibenden
und einem lesenden Prozess. Multiple Leser oder Schreiber sind nicht erlaubt.
One2AnyChannel: Ermoglicht Verbindungen von einem Schreiber und vielen
Lesern, wobei stets nur ein Leser und der Schreiber zur gleichen Zeit den
Channel benutzen d urfen. Aus diesem Grund handelt es sich nicht um Broad-
casting. Die Leser konkurrieren bei diesem Verfahren um den Zugri auf den
Channel.
Any2OneChannel: Vergleichbar mit dem One2AnyChannel konkurrieren hier
mehrere Schreiber um den Zugri auf den Channel. Es ist nur ein Leser erlaubt.
Any2AnyChannel: Es konkurruieren sowohl Leser, als auch Schreiber um den
Zugri auf das Medium, wobei auch hier jeweils nur ein Leser und ein Schreiber
gleichzeitig zugreifen konnen. Dies wird durch den Channel verwaltet.
Jeder Channel besitzt sogenannte Ends. Sie werden Prozessen hinzugef ugt und
ermoglichen den Zugri auf den Channel. Es muss sowohl Input Ends, als auch
Output Ends geben [6][7]. Diese nehmen Objekte des Typs Object auf und konnen
daher samtliche Datentypen aufnehmen und ubertragen.
Samtliche Channel enthalten standardmaig einen ZeroBuer [7], konnen jedoch
mit einem anderen Puerobjekt erstellt werden. Es gibt unterschiedliche Arten
von Puern in JCSP:
Buer: einfacher FIFO-Puer mit fester Groe. Der Schreiber wird blockiert,
wenn die denierte Groe erreicht wird.
9.3 Die JCSP Bibliothek 107
InniteBuer: nimmt stets Objekte auf.
OverFlowingBuer: ist der Puer voll, wird jedes weitere Objekt verworfen.
OverWriteOldestBuer: nimmt stets Objekte auf. Ist der Puer voll, wird der
alteste Eintrag uberschrieben.
OverWritingBuer: nimmt stets Objekte auf, uberschreibt jedoch den letzten
Eintrag, wenn der Puer voll ist.
ZeroBuer: Kein Puer. Synchronisiert Leser und Schreiber eines Channels.
9.3.4 Alternation
Die JCSP Klassenbibliothek implementiert weitere wichtige Elemente des CSP zur
Prozessverarbeitung. Ein wichtiger Operator ist Alternation, der es erlaubt, dass
ein Prozess auf das Auslosen unterschiedlicher Ereignisse reagiert. Dazu konnen
die entsprechenenden Input Ends mit Hilfe eines Guards kombiniert und je nach
Ereignis entsprechend behandelt werden [2]. Anhand unterschiedlicher Zugrisme-
thoden auf den Guard kann aus zahlreichen Scheduling-Modi (z.B. Fair Queuing)
ausgewahlt werden, falls mehrere Ereignisse aufgetreten sind.
9.3.5 Einfache Beispielimplementierung
Es folgt ein einfaches Channel-Beispiel. In der Hauptklasse JCSP Main (Listing
9.1) wird eine 1:1 Channelverbindung angelegt. Es wird ein paralleler Hauptprozess
erstellt, der wiederum mit einem Array von zwei Prozessen JCSP Producer und
JCSP Consumer angelegt wird.
import org.jcsp.lang.CSProcess;
import org.jcsp.lang.Channel;
import org.jcsp.lang.One2OneChannelInt;
import org.jcsp.lang.Parallel;
public class JCSP_Main {
public static void main(String[] args) {
One2OneChannelInt ch = Channel.one2oneInt();
new Parallel(new CSProcess[] {
new JCSP_Producer(ch.out()),
new JCSP_Consumer(ch.in())
}
).run();
}
}
Listing 9.1: JCSP Main.java
Der Erzeuger (Listing 9.2) bekommt uber seinen Konstruktor ein Channel Out-
put End, welches die Schnittstelle ChannelOutputInt implementiert, ubergeben.
Das bedeutet, dass uber dieses Objekt Int-Werte auf den Channel gegeben wer-
den konnen. Entsprechend bekommt der Verbraucher (Listing 9.3) einen Channel
Input End, das Int-Werte entnehmen kann.
import org.jcsp.lang.CSProcess;
import org.jcsp.lang.ChannelOutputInt;
class JCSP_Producer implements CSProcess{
private ChannelOutputInt outChannel;
public JCSP_Producer(ChannelOutputInt ch) {
outChannel = ch;
}
public void run() {
outChannel.write(5);
}
}
Listing 9.2: JCSP Producer.java
Mit dem Start des Hauptprozesses werden parallel die beiden enthaltenen Prozesse
gestartet. Der Erzeuger legt eine Zahl auf den Channel und blockiert aufgrund der
synchronisierten

Ubertragung bis der Verbraucher den Channel ausliest. Ebenso
blockiert der Erzeuger, wenn sich auf dem Channel kein Objekt bendet. Das
Verhalten entspricht also dem einer SynchronousQueue in Java.
class JCSP_Consumer implements CSProcess{
private ChannelInputInt inChannel;
public JCSP_Consumer(ChannelInputInt ch) {
inChannel = ch;
}
public void run() {
int n = inChannel.read();
System.out.println("n="+n);
}
}
Listing 9.3: JCSP Consumer.java
9.4 Zusammenfassung 109
9.4 Zusammenfassung
JCSP ist eine machtige, aber dennoch einfach anzuwendende Bibliothek zur Ent-
wicklung von prozessorientierten Java Applikationen. Dabei enthalt sie viel mehr
Klassen, als die erwahnten. Sie stellt zudem die grundlegenden CSP Primitiven
(z.B. Channel, Events) bereit, die zur Kommunikation von Prozessen benotigt
werden. Damit ist es moglich, Anwendungen zu entwickeln, die frei von Gefah-
ren wie Deadlocks, Livelocks, Starvation oder Race Conditions sind. Das Chan-
nel Konzept, welches in dieser Klassenbibliothek implementiert ist, stellt einen
nat urlichen Weg dar, solche Anwendungen ohne Schwierigkeiten mit Java Threads
zu programmieren. Der Vorteil dabei ist, dass die Kommunikation vollstandig von
den Channels ubernommen wird.
Da die Regeln des CSP immer eingehalten werden, ist garantiert, dass die Kom-
munikation zwischen Prozessen korrekt ablauft. Der Entwickler benotigt dabei
keine mathematischen Kenntnisse uber das CSP und protiert dennoch von des-
sen Regeln.
[1] A, Kosek, J. Kerridge and A. Syed, Modelling a Multi-Core Media Processor
Using JCSP. IOS Press, 2008.
[2] N. Schaller, G. Hilderink und P. Welch, Using Java for Parallel Computing
JCSP versus CTJ, a Comparision. IOS Press, 2000.
[3] P. Welch, Process Oriented Design for Java: Concurrency for All. International
Conference on Parallel and Distributed Processing Techniques and Applicati-
ons, Las Vegas, 2000.
[4] G. Oprean, J. Pedersen, Asynchronous Active Objects in Java. IOS Press,
2008.
[5] B. Preiss, Data Structures and Algorithms with Object-Oriented Design Pat-
terns in Java. Wiley & Sons, 1998.
[6] P. Welch, N. Brown, J. Moores, K. Chalmers und B. Sputh, Integrating and
Extending JCSP. IOS Press, 2007.
[7] P. Welch, P. Austin, JCSP 1.1-rc4 API Specikation. 2010.
Teil III
Interprozesstechnologien
10 Interprozesskommunika-
tion mit COM
Ronny Schleicher
Inhaltsverzeichnis
10.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 114
10.2 Was ist COM? . . . . . . . . . . . . . . . . . . . . . . . 114
10.3 Eigenschaften der COM Technologie . . . . . . . . . . . . 114
10.3.1 Sprachunabhangigkeit . . . . . . . . . . . . . . . 114
10.3.2 Versionsunabhangigkeit . . . . . . . . . . . . . . 115
10.3.3 Plattformunabhangigkeit . . . . . . . . . . . . . . 115
10.3.4 Objektorientierung . . . . . . . . . . . . . . . . . 115
10.3.5 Ortsunabhangigkeit . . . . . . . . . . . . . . . . 115
10.3.6 Automation . . . . . . . . . . . . . . . . . . . . 115
10.4 Entwicklungsgeschichte . . . . . . . . . . . . . . . . . . . 116
10.4.1 Basistechnologien . . . . . . . . . . . . . . . . . 116
10.4.2 Geburt der COM Technologie . . . . . . . . . . . 116
10.4.3 Weiterf uhrende Entwicklungen . . . . . . . . . . 117
10.5 Implementieren mit COM . . . . . . . . . . . . . . . . . 117
10.5.1 Exemplarische COM-Server-Implementierung . . . 118
10.5.2 Exemplarische COM-Client Implementierung . . . 119
10.5.3 Marshalling . . . . . . . . . . . . . . . . . . . . . 119
10.6 COM-Server-Varianten . . . . . . . . . . . . . . . . . . . 120
10.6.1 In-Prozess-COM-Server . . . . . . . . . . . . . . 120
10.6.2 Out-of-Prozess-COM-Server . . . . . . . . . . . . 120
10.6.3 Remote-COM-Server . . . . . . . . . . . . . . . . 120
10.7 COM-Organisationsstruktur . . . . . . . . . . . . . . . . 121
10.8 Einsatzgebiete von COM . . . . . . . . . . . . . . . . . . 122
10.8.1 COM in der eigenen Applikation . . . . . . . . . 122
10.8.2 COM als Schnittstelle f ur Integrationen . . . . . . 123
10.9 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
114 10 Interprozesskommunikation mit COM
10.1 Einleitung
Ziel dieses Kapitels ist es einen ersten

Uberblick uber die Microsoft COM Techno-
logie zu geben. Die folgenden Seiten sollen ein Gef uhl daf ur vermittelt was COM
ist, wie COM funktioniert und wo COM eingesetzt wird.
Alle Publikationen, die sich mit COM auseinander setzen, umfassen mehrere hun-
dert Seiten und sind teilweise aus sehr unterschiedlicher Sichtweise verfasst. Im
Literaturverzeichnis bendet sich eine Auswahl an Veroentlichungen die mir,
neben der oziellen Microsoft-Dokumentation, als Basis gedient haben.
10.2 Was ist COM?
COM steht f ur
Component Object Model und bezeichnet eine Microsoft-

Plattformtechnologie. Hierbei handelt es sich um ein binares objektorientiertes
Kommunikationsprotokoll, dass in einem Prozessraum, zur Interprozesskommuni-
kation, oder mit DCOM, auch uber Rechnergrenzen hinweg, eingesetzt werden
kann und dem eine Client-Server-Architektur zugrunde liegt. COM ist aufgrund
seiner binaren Spezikation sprach- und betriebssystemunabhangig und wurde
primare entwickelt um die Wiederverwendbarkeit von Softwarekomponenten zu
erleichtern. COM-Komponenten werden ausschlielich uber Interfaces verwendet
bzw. genutzt und gewahrleisten Interoperabilitat.
10.3 Eigenschaften der COM Technologie
Die wichtigsten Eigenschaften der COM Technologie sind Sprach-, Versions-,
Plattform- und Ortsunabhanigkeit, sowie Objektorientierung und Automation.
Hierbei zeichnet COM im Besonderen die Kombination all dieser Eigenschaften
aus.
10.3.1 Sprachunabhangigkeit
Aufgrund der binaren Protokolldenition ist COM per se sprachunabhangig. Le-
diglich die Einschrankungen durch bestimmte Hardware- oder Softwarevorausset-
zungen in Bezug auf eine Sprache oder ein Betriebssystem konnen den Einsatz
von COM erschweren oder gar verhindern. Des Weiteren wird von vielen Software-
entwicklern eine Unterst utzung von COM in der von ihnen verwendeten Sprache
mittels Bibliotheken oder anderen Erweiterungen erwartet. Folglich ist es nicht
verwunderlich das Sprachen wie C++ mit ATL oder Qt, C#, Visual Basic, Java
mit JCOM, Prolog in VP 7.0 oder Haskell solche Erweiterungen bieten.
10.3 Eigenschaften der COM Technologie 115
10.3.2 Versionsunabhangigkeit
Durch Multi-Interface-Denitions ist es theoretisch moglich eine volle Versions-
unabhangigkeit zu erreichen. Hierbei wird bei der Erweiterung einer bestehenden
Implementierung nicht das dazugehorige Interface geandert, sondern ein komplett
neues Interface hinzugef ugt. Dadurch soll gewahrleistet werden das Implementie-
rungen, die das alte Interface nutzen, weiterhin problemlos funktionieren.
10.3.3 Plattformunabhangigkeit
Da COM ein Protokoll ist und Protokolle im Prinzip auf jedem System imple-
mentiert werden konnen, ist COM plattformunabhangig. SUN Microsystems (seit
2010 Oracle) hat bereits 1997 einen DCOM Server f ur sein hauseigenes Betriebs-
system Solaris freigegeben [7]. Allerdings konnen auch hier, ahnlich wie bei der
Sprachunabhangigkeit, bestimmte Beschrankungen der Betriebssysteme die Platt-
formunabhangigkeit einschranken.
10.3.4 Objektorientierung
Mit COM wird meist objektorientiert entwickelt. Zum einen liegt das daran, dass
viele Sprachen die COM nutzen, objektorientiert sind, zum anderen daran das
COM selbst objektorientiert ist, wie der Name schon sagt. Allerdings besteht
das binare Speicherabbild der COM-Objekte letztendlich aus V-Tables und Me-
thodenzeigern (die Interfaces sind lediglich Methodenzeiger) die sich auch mit
Assembler, prozeduralen Sprachen wie C, logische Sprachen wie Prolog oder mit
rein funktionalen Sprachen wie Haskell erzeugen und verarbeiten lassen.
10.3.5 Ortsunabhangigkeit
Um COM-Objekte zu benutzen, ist es notig sie an einer zentralen Stelle dem Ge-
samtsystem bekannt zu machen bzw. zu registrieren. Unter Windows wird hierf ur
die Windows-Registry verwendet, bei anderen Betriebssystemen wie Solaris kom-
men aquivalente Techniken zum Einsatz. F ur den Programmierer ist es unerheb-
lich wo sich die COM-Objekte, die er nutzen will, benden. Er instanziiert und
verwendet die COM-Objekt immer auf die gleiche Art und Weise, egal ob sie
im gleichen Prozessraum, einem anderen Prozessraum oder auf einem anderer
Rechner (DCOM) lokalisiert sind.
10.3.6 Automation
Wenn ein Programm seine Fahigkeiten in COM-Objekte verpackt, und so ande-
ren Programmen zur Verf ugung stellt, wird das als Automation bezeichnet. Der
Vorteil dieser Technik ist, dass diese COM-Objekte, in der Literatur werden sie
auch als Automationsobjekte bezeichnet, nicht komplett in die Client Applikation
eingebettet werden. Die Kommunikation wird uber selbst geschriebenen, applika-
tionseigenen Programmcode, also implementierte Interfaces, realisiert.
10.4 Entwicklungsgeschichte
COM ist das Entwicklungsergebniss verschiedener Basistechnologien. Um COM zu
verstehen ist es deshalb wichtig die Beweggr unde zu kennen, die zur Entwicklung
von COM und ahnlichen Technologien gef uhrt haben.
10.4.1 Basistechnologien
Bis 1991 bot Microsoft in Windows 3.0 als Technologie f ur den Datenaustausch
zwischen Applikationen
Dynamic Data Exchange, kurz DDE, an. 1992 wur-

de mit Windows 3.1 und den Softwarepaketen Word 2.0 und Excel 4.0 die OLE
(Object Linking and Embedding) 1.0 Technik eingef uhrt. Damit konnten Objekte
der Serveranwendung mit Verweisen in Clientanwendungen verkn upft oder einge-
bettet werden. Exemplarisch steht daf ur die Einbettung eines Excel-Diagramms
in ein Word-Dokument. Der Doppelklick auf das verkn upfte oder eingebetteten
OLE-Objekt f uhrt zum automatischen Start der Serveranwendung.
1993 wurde mit OLE 2.0 f ur Windows 3.1 und Oce 4.x das OLE-Konzept kom-
plett uberarbeitet. Eine der wichtigsten Neuerungen war die Einf uhrung der GUID
(Globally Unique Identier) bzw. der CLSID (Class Identier), die eine eindeutige
Registrierung von Klassen in der Windows Registry gewahrleistete. Es war damit
moglich zwischen Client- und Serveranwendungen eine wirkliche Kommunikation
zu realisieren und Befehle zu verarbeiten. Mit OLE 2.0 wurde auch Automation
eingef uhrt und es gab Zusatzsteuerelemente, die auf bestimmte Ereignisse (z.B.
Click-Events) reagierten.
10.4.2 Geburt der COM Technologie
Mit der Einf uhrung von ActiveX versuchte Microsoft die eigentliche Schnittstelle
von der verwendeten Technologie zu trennen. Infolgedessen wurden die Nomenkla-
turen
ActiveX Steuerelement und
ActiveX Automation gepragt. OLE wurde

im Bereich des Objektaustausches zwischen Programmen, besonders im Rahmen
der Oce-Produktreihe, ebenfalls weiterentwickelt.
Ziel der Entwicklung von Microsoft war es allerdings, dass die beiden Techno-
logien ActiveX und OLE auf eine gemeinsame Basistechnik aufsetzen, die die
10.5 Implementieren mit COM 117
Problematiken beim Datenaustausch zwischen Programmen implementiert, also
Kommunikationsprotokolle und Datenformate deniert. Als Ergebnis entstand das
Component Object Model, bekannt unter dem Akronym COM.
Mit der Veroentlichung von Windows NT im Jahr 1996 wird COM als fester
Bestandteil f ur die Realisierung von OLE und ActiveX verwendet. Da gerade
im Bezug auf die Beziehungen zwischen ActiveX, OLE und COM oft Fragen
auftauchen, soll Abbildung 10.1 verdeutlichen, dass COM die gemeinsam genutzte
Basistechnologie (Backbone) f ur OLE und ActiveX darstellt.
Abbildung 10.1: COM als gemeinsam genutzte Basistechnologie f ur OLE und ActiveX.
10.4.3 Weiterf uhrende Entwicklungen
Im Fr uhjahr 1997 wurde DCOM (Ditributed Component Object Model) als Erwei-
terung f ur Windows 95 vorgestellt. Wirkliche Relevanz bekam es allerdings erst ab
Ende 1998 mit dem Release des Windows NT SP4, bei dem es fester Bestandteil
war. DCOM erweitert das COM Protokoll um eine Netzwerktechnologie, die mit
TCP/IP uber mehrere Ports kommuniziert. Mit COM+ und dem MTS (Microsoft
Transaction Server) kommen Lastverteilung und Transaktionen hinzu.
Windows 2000 lost mit dem DOT-NET-Remoting 1.0 das DCOM Protokoll ab.
Ein wesentlicher Vorteil hierbei ist die Unterst utzung mehrere Netzwerkprotokolle.
Die aktuellste Implementierung stellt das DOT-NET-Remoting 2.0 dar, dass nun
unter anderem auch IPv6 und Remoting-Channel-IPC, also lokale Kommunikation
ohne Netzwerkprotokollstack, unterst utzt.
10.5 Implementieren mit COM
Eine zentrale Komponente beim Arbeiten mit COM ist das gemeinsame Basisin-
terface IUnknown. Dieses Interface muss von allen COM-Objekten implementiert
werden und ist in der MIDL (Microsoft Interface Denition Language) beschrie-
ben, die der Syntax der Sprache C entspricht und um einige Elemente erweitert
wurde. QueryInterface(...), AddRef() und Release() sind die 3 Funktionen,
die das Basisinterface IUnknown deniert. Mit AddRef() und Release() wer-
den Referenzahler auf das COM-Objekt manipuliert und QueryInterface(...)
dient dazu die unterst utzten Schnittstellen zu ermitteln.
[
local,
object,
uuid(CB630F0C-017F-4c46-BC75-88B6CE44071F)
]
interface IUnknown
{
[restricted]
HRESULT QueryInterface( [in] GUID* rrid,
[out] void** ppvObj);
[restricted]
ULONG AddRef();
[restricted]
ULONG Release();
}
Listing 10.1: IDL-Denition der Basisschnittstelle IUnknown [1]
Allerdings ist es in den wenigsten Sprachen notwendig diese Schnittstelle direkt
zu implementieren oder damit zu arbeiten, da dieses Interface meist durch Klas-
senbibliotheken gekapselt wird und sich somit ohne Problem in die spezische
Arbeitsweise integriert. Auch andere Mechanismen wie der explizite Einsatz eines
MIDL-Compilers zum

Ubersetzen vom in der unterst utzten Sprache geschrieben
Quellcodes zu COM konformen Quellcode wird meist automatisiert durchgef uhrt
oder kann durch spezielle Werkzeuge, die den Bibliotheken beiliegen, in die Ent-
wicklungsumgebung integriert werden.
10.5.1 Exemplarische COM-Server-Implementierung
Das folgende Codebeispiel implementiert einen COM-Server mit C++ und Qt[8]:
class MyComServer : public QObject
{
Q_OBJECT
10.5 Implementieren mit COM 119
Q_CLASSINFO("ClassID", "{768B81C6-035C-4304-8BCC-123A6935D231}")
Q_CLASSINFO("InterfaceID", "{FD70DC7F-65C7-44ee-8871-6D58009FD285}")
Q_CLASSINFO("EventsID", "{EC7B399D-990E-4524-9790-9E582EA941F3}")
public slots:
int addValues(int a, int b){return a+b;};
};
Listing 10.2: COM-Server mit C++ und Qt[8]
10.5.2 Exemplarische COM-Client Implementierung
Die dazugehorige Implementierung des COM-Client mit Java und JCOM sieht
wie folgt aus:
import IMyComServer.*;
import ezjcom.*;
public class MyComServerClient {
public static void main( String[] args ){
try {
Application mycomserver = new Application();
_Application app = mycomserver.get_Application();
int sum = app.addValues(50, 29);
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
Listing 10.3: COM-Client mit Java und JCOM.
10.5.3 Marshalling
Um den Datenaustausch zwischen COM-Client und COM-Server uber ver-
schiedenen Programmiersprachen hinweg, hier exemplarisch Java und C++, zu
ermoglichen, werden die Daten beim Sender vom Format der jeweiligen Sprache in
ein einheitliches, in COM deniertes Datenformat umgewandelt, zum Empfanger
transportiert und dort im Format der genutzten Sprache wiederhergestellt. Das
Umwandeln und Wiederherstellen der Daten am Interface des Empfangers bzw.
Senders wird als Marshalling bzw. Unmarshalling (auch Demarshalling) bezeichnet
und ist keine COM-spezische Technik.
10.6 COM-Server-Varianten
Beim Einsatz von COM wird zwischen den folgenden 3 Varianten unterschieden.
Die dritte Variante
Remote COM-Server ist genau genommen Bestandteil von

DCOM, wird aber in der Praxis oft dem Leistungsspektrum vom COM zugeordnet
und deshalb mit aufgef uhrt.
10.6.1 In-Prozess-COM-Server
Der COM-Server ist hier in einer DLL- oder einer OCX-Datei lokalisiert, die im
System registriert ist und beim Instanziieren durch den Client in dessen Pro-
zessraum geladen wird. Die Tatsache, dass der COM-Server in nur einer Datei
registriert ist, schliet allerdings nicht aus, dass beim Laden der DLL/OCX-Datei
weitere Komponenten durch Abhangigkeiten nachgeladen werden.
Bei Mehrfachnutzung eines In-Prozess-Servers durch verschiedene Prozesse wird
der COM-Server auch mehrfach instanziiert und verbraucht demzufolge pro In-
stanz Speicher und andere Systemressourcen.
Allerdings hat ein In-Prozess-COM-Server aufgrund der Eigenschaft, dass er im
Prozessraum des jeweiligen Clients arbeitet, im Vergleich zu den anderen beiden
Varianten die geringste Lade- und Ausf uhrungszeit.
10.6.2 Out-of-Prozess-COM-Server
Als Out-of-Prozess-COM-Server oder auch Local-COM-Server werden ausf uhr-
bare Programme (.EXE) bezeichnet, die COM-Server-Komponenten enthalten.
Durch clientseitige Instanziierung eines Out-of-Prozess-COM-Servers wird das
korrespondierende Programm automatisch gestartet, falls es noch nicht aktiv ist.
Der grote Unterschied zum In-Prozess-COM-Server ist die Tatsache, dass hier
immer nur eine Instanz des COM-Servers existiert, diese Instanz in einem an-
deren Prozessraum wie der Client lokalisiert ist und diese Instanz Anfragen von
mehreren Clients verarbeitet. Demzufolge ist diese Variante Ressourcensparender,
aber aufgrund der Prozess ubergange mittels RPCs langsamer, als die In-Prozess-
Variante.
10.6.3 Remote-COM-Server
Der Remote-COM-Server hat im wesentlichen die gleichen Eigenschaften wie der
Out-of-Prozess COM-Server. Allerdings liegen hier zwischen COM-Client und
COM-Server nicht nur Prozessgrenzen, sondern Rechnergrenzen. Als Protokoll
wird DCOM genutzt, welches als Basis ein vollstandig implementiertes RPC ver-
wendet. DCOM ermoglicht zusatzlich durch seine Netzwerkfahigkeit die Kom-
10.7 COM-Organisationsstruktur 121
munikation zwischen verschiedenen Betriebssystemen, die ebenfalls das DCOM
Protokoll unterst utzen.
10.7 COM-Organisationsstruktur
Damit es moglich ist einen COM-Server zu nutzen, indem man einfach eine
Instanz erzeugt und damit arbeitet, ohne sich Gedanken um die Lokalisierung
machen zu m ussen, ist im Hintergrund eine Organisationsstruktur notig, die so
etwas leisten kann. COM schat mit seinem GUID- bzw. CLSID-Konzept zwar
die notigen Voraussetzungen um eine solche Organisationsstruktur aufzubauen,
macht aber keine konkreten Aussagen dar uber wie diese umzusetzen ist. Mit der
Organisationsstruktur sind hier Mechanismen zur Registrierung, zur Lokalisierung,
zum Laden und zum Verwalten von COM-Objekten gemeint. Als zentrales Instru-
ment wird bei den Windows-Betriebssystemen die Windows-Registry eingesetzt,
die samtliche CLSID-Eintrage mit den jeweiligen Pfaden enthalt. Beim Instanziie-
ren eines COM-Objektes durch einen Client sucht ein Dienstprogramm, dass f ur
die Verwaltung der COM-Objekte verantwortlich ist, mit Hilfe der CLSID in der
Windows-Registry den absoluten Pfad des Moduls (DLL, OCX, EXE) indem sich
das COM-Objekt bendet. Anschlieend wird ermittelt ob dieses Modul geladen
werden muss oder nur der Referenzzahler auf das Objekt zu inkrementiert ist. Eine
ahnliche Verarbeitung ndet statt wenn der Referenzzahler auf ein COM- Objekt
dekrementiert wird. Die wichtigste Entscheidung dabei ist, ob das Modul (DLL,
OCX, EXE) entladen wird oder weiter im System verbleibt. Ein Referenzzahler
der den Wert 0 erreicht bedeutet nicht zwangslaug das ein Modul entladen oder
eine EXE aus der Prozessliste genommen wird. Hier sorgen bestimmte Scheduling-
Abbildung 10.2: Windows Registry mit Eintragen zu einem COM-Server.
Verfahren daf ur, dass ein hauges Laden und Entladen hochfrequentierter Module
bzw. Applikationen vermieden wird. Abbildung 10.2 zeigt die Windows-Registry
mit einer markierten CLSID und dem dazugehorigen absoluten Pfad zum korre-
spondierenden Module, in diesem Fall einer DLL.
10.8 Einsatzgebiete von COM
COM ist mit ActiveX und OLE in jedem aktuellen Microsoftprodukt zu nden. Ne-
ben der MS-Oce-Softwarepalette, die einen Groteil ihrer gesamten Funktiona-
litat als COM-Server bereitstellt, besitzen auch das Visual Studio, MS-SQL-Server
und zahllose Systemdienste eine COM-Schnittstelle. Auch Softwareprodukte von
bekannten Firmen wie Adobe, T-Online, AOL, AGFA, Google, NVidia, Avira u.v.a.
verf ugen fast ausnahmslos uber COM-Schnittstellen.
Unter Microsoft Windows ist zudem der Drag-and-Drop-Mechanismus zwischen
Applikationen mit COM realisiert und somit ist COM in diesem Kontext bei der
taglichen Arbeit allgegenwartig.
10.8.1 COM in der eigenen Applikation
COM-Server-Schnittstellen anderer Anbieter stellen f ur selbst entwickelte Softwa-
re groes Potential dar. Um zum Beispiel aus einer eigenen Applikation heraus
eine E-Mail zu versenden, muss nicht ein kompletter SMTP Client mit da-
zugehoriger Adress- und Personenverwaltung implementiert werden, sondern es
konnen mit COM die von MS Outlook bereitgestellten Funktionalitaten genutzt
werden. Wenn die Anforderung besteht diese E-Mail in eine PDF zu konvertieren
und anzuzeigen muss lediglich der Adobe Acrobat Creator in Kombination mit
dem Reader via COM genutzt werden. So ist moglich mit weniger Zeilen selbst
geschriebenen Quellcodes die generierte PDF eingebettet in der eigenen Applika-
tion mit dem vollen Komfort des Acrobat Reader wie Inhaltsverzeichnis, Suche,
Zoom- und Druckfunktion darzustellen.
Durch eine solche Auslagerung von Funktionalitaten wird zum einen der Nachim-
plementierung schon vorhandener Funktionalitat in anderer Software entgegenge-
wirkt, was zu deutlich weniger Test- und Entwicklungsaufwand f uhrt. Ein weiterer
positiver Eekt ist, dass sich die eigene Softwarelosung primar auf die eigentli-
che Problemstellung und somit auf die Kernaufgaben konzentrieren kann. Hinzu
kommt, dass Softwarekomponenten die man nicht selbst programmiert keinen
Wartungsaufwand erzeugen. Falls zum Beispiel Adobe das PDF-Format aufgrund
von neuen Problemstellungen weiterentwickelt und verbessert, wird die eigene
Software automatisch davon protieren.
10.9 Fazit 123
10.8.2 COM als Schnittstelle f ur Integrationen
COM ist im Bereich der Integration bei Softwareprojekten ein haug eingesetz-
tes Mittel, um heterogene Softwaresysteme verschiedener Anbieter miteinander
interagieren zu lassen. Die Eigenschaften der COM-Technologie, insbesondere die
Sprach- und Ortsunabhangigkeit sind hierf ur tragende Gr unde. Die Hersteller der
einzelnen Produkte konnen die Schnittstellen in der von ihnen eingesetzten Spra-
che entwickeln (Sprachunabhangigkeit) und konnen Schnittstellen der Integrati-
onspartner ohne Kenntnisse uber deren Programmstruktur und Lokalitat benut-
zen (Ortsunabhangigkeit). Dies stellt f ur den Implementierungsaufwand solcher
Schnittstellen einen erheblichen Benet dar.
10.9 Fazit
Entwicklern wird mit COM eine interessante Moglichkeit zur Interprozesskommu-
nikation geboten. Gerade die groe Verbreitung von COM-Servern in aktueller
Windows-Software und den damit nutzbaren Funktionalitaten ist beeindruckend.
Durch die Sprachunabhangigkeit und meist gute Unterst utzung in den jeweili-
gen Programmiersprachen ist das Erlernen des Umgangs mit COM meist keine
groe H urde. COM bietet eine attraktive Alternative zu anderen Technologie wie
CORBA und f ur Sprachen die von Haus aus keine Moglichkeit zur Interprozess-
kommunikation bereitstellen.
[1] Don Box, COM, Addison-Wesley, 1998, ISBN 3-8273-1385.
[2] Geb. Eddon, Inside Distributed COM, Microsoft Press, 1998,
ISBN 3-86063-459-3 (DEU), ISBN-1-57231-849-X (USE).
[3] Alan Gordon, The COM and COM+ Programming Prime,
Microsoft Technologie Series, 2000, ISBN 0-13-085032-2.
[4] Hofmann, Jobst, Schabenberger, Programmieren mit COM und Corba, Han-
ser, 2001, ISBN 3-8273-1385.
[5] Microsoft, Microsoft - What is COM?, 2011,
http://www.microsoft.com/com/default.mspx
[6] Microsoft, Microsoft - MSDN, 2011,
http://msdn.microsoft.com/de-de/default.aspx
[7] Windows IT Pro, Sun Solaris DCOM Release, 1997,
http://www.windowsitpro.com/article/news2/dcom-for-solaris-released.aspx
[8] Nokia qt, Nokia Qt, 2011, http://qt.nokia.com/
11 HawtDispatch
Tobias Gieler
Inhaltsverzeichnis
11.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 125
11.2 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
11.2.1 Klasse Dispatch . . . . . . . . . . . . . . . . . . 126
11.2.2 Interface DispatchQueue . . . . . . . . . . . . . . 126
11.2.3 Interfaces DispatchSource und Suspendable . . . 128
11.3 HawtDispatch und Java New I/O . . . . . . . . . . . . . 129
11.3.1 Java New I/O (NIO) . . . . . . . . . . . . . . . . 129
11.3.2 NIO DispatchSource . . . . . . . . . . . . . . . . 129
11.3.3 Benutzerdenierte DispatchSource . . . . . . . . 130
11.4 Asynchrones Aufraumen . . . . . . . . . . . . . . . . . . 131
11.5 Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . 133
11.5.1 Aufbau des Echo-Server . . . . . . . . . . . . . . 133
11.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Das folgende Kapitel gibt eine Einf uhrung in den Aufbau und die Nutzung von
HawtDispatch. Es werden die wichtigsten Klassen und Methoden vorgestellt. An-
schlieend wird anhand einiger Code-Beispiele das Arbeiten mit HawtDispatch
erlautert.
11.1 Einleitung
HawtDispatch ist ein Framework, welches die Programmierung verteilter paralleler
Anwendungen vereinfachen soll. Insbesondere die Programmierung von Anwen-
dungen, die Java New I/O nutzen. HawtDispatch orientiert sich an der libdispatch
API, welche von der Firma Apple entwickelt wurde.
126 11 HawtDispatch
11.2 Aufbau
Der folgende Abschnitt beschreibt die wichtigsten Klassen und Methoden des
HawtDispatch-Frameworks. Damit die gezeigten Code-Ausschnitte funktionieren,
m ussen folgende Import-Anweisungen genutzt werden.
import org.fusesource.hawtdispatch._
import org.fusesource.hawtdispatch.ScalaDispatch._
11.2.1 Klasse Dispatch
Die Klasse Dispatch, siehe Abbildung 11.1, bietet Fabrik-Methoden, um Objekte
der Klassen DispatchQueue, DispatchSource und CustomDispatchSource zu
erzeugen. Diesen Objekten konnen Tasks zur parallelen Ausf uhrung ubergeben
werden. F ur das Programmieren in Scala wird die Klasse ScalaDispatch be-
reitgestellt. Diese erweitert die Klasse Dispatch lediglich um scala-spezische
Syntax und stellt keine neue Funktionalitat bereit [1].
Abbildung 11.1: Klasse Dispatch
11.2.2 Interface DispatchQueue
Abbildung 11.2: Interface DispatchQueue
11.2 Aufbau 127
Objekten des Typs DispatchQueue konnen Tasks zur parallelen Ausf uhrung
ubergeben werden. Es existieren zwei Arten von DispatchQueue-Objekten:
ConcurrentDispatchQueue-Objekte und SerialDispatchQueue-Objekte.
ConcurrentDispatchQueue: Die Tasks, die einer ConcurrentDispatchQueue
ubermittelt werden, werden parallel ausgef uhrt und m ussen aus diesem Grund
thread-sicher sein. Die Reihenfolge in der die ubermittelten Tasks ausgef uhrt wer-
den, ist nicht deterministisch. Es existieren nur drei ConcurrentDispatchQueue-
Objekte, welche systemweit geteilt werden. Diese drei ConcurrentDispatchQueu-
es besitzen unterschiedliche Prioritaten. Auf die ConcurrentDispatchQueue-
Objekte kann durch die Methode getGlobalQueue(priority) der Klasse
Dispatch zugegrien werden.
val concurrentQueue = getGlobalQueue(DispatchPriority.HIGH)
SerialDispatchQueue: In einer SerialDispatchQueue werden die ubermit-
telten Tasks in der Reihenfolge ausgef uhrt, in der sie ubermittelt wurden.
Die Tasks werden seriell nacheinander und ohne Parallelitat ausgef uhrt. Ledig-
lich Tasks verschiedener SerialDispatchQueue-Objekte konnen parallel aus-
gef uhrt werden. SerialDispatchQueue-Objekte konnen durch die Methode
createQueue der Klasse Dispatch erzeugt werden.
val serialQueue = createQueue()
Damit Tasks asynchron ausgef uhrt werden konnen, m ussen diese Tasks den
DispatchQueue-Objekten ubergeben werden. Um dies zu erreichen, kann die
Methode execute genutzt werden.
serialQueue.execute(new Runnable(){
def run() {
println("Hallo Welt!")
}
})
In Scala konnen dar uber hinaus die folgenden drei Syntax-Varianten verwendet
werden.
concurrentQueue { // Variante 1
println("Hallo Welt")
}
concurrentQueue << ^{ // Variante 2
}
128 11 HawtDispatch
^{ // Variante 3
} >>: concurrentQueue
Auch in diesen Fallen wird ein Runnable- Objekt erzeugt, dessen run- Methode
den Inhalt der geschweiften Klammern hat.
Die Autoren von HawtDispatch weisen darauf hin, dass alle Runnables, die durch
HawtDispatch asynchron ausgef uhrt werden, nicht blockieren sollten. Falls blo-
ckierende Runnables ausgef uhrt werden m ussen, sollte dies in einem zusatzlichen
Thread geschehen, der nicht durch HawtDispatch verwaltet wird.
11.2.3 Interfaces DispatchSource und Suspendable
DispatchSource-Objekte nutzen Events, um die Ausf uhrung eines Tasks zu star-
ten. Objekte des Typs DispatchSource werden unter anderem dazu genutzt,
Java New I/O -Events zu verarbeiten. Es konnen dar uber hinaus auch benutzer-
denierte DispatchSources erstellt werden, die unterschiedliche Events zu einem
einzigen Event zusammenfassen. Abbildung 11.3 zeigt den Aufbau des Interfaces.
Abbildung 11.3: Interfaces DispatchSource und Suspendable
Das Interface DispatchSource erbt von dem Interface Suspendable. Dadurch
muss eine Klasse, die das Interface DispatchSource implementiert, auch das
Interface Suspendable implementieren. Suspendable stellt Methoden bereit,
um ein Objekt in einen Ruhezustand zu versetzen, es wieder aufzuwecken und
abzufragen, ob sich das Objekt in einem Ruhezustand bendet.
Das Interface DispatchSource deklariert die Methoden setCancelHandler und
setEventHandler. Diesen Methoden wird ein Runnable ubergeben, welches bei
dem Aufruf der Methode cancel oder bei dem Auftreten eines bestimmten Events
ausgef uhrt werden soll. Die Methode isCancelled soll Auskunft dar uber geben,
ob die Methode cancel bereits ausgef uhrt wurde.
Bei den in HawtDispatch vorhandenen Implementationen von DispatchSource
wird ein Objekt so initialisiert, dass es sich standardmaig in einem Ruhezu-
stand bendet. Das bedeutet, dass das DispatchSource-Objekt nicht auf Events
reagiert. Nach dem Erstellen des Objekts muss zuerst sein EventHandler kon-
11.3 HawtDispatch und Java New I/O 129
guriert werden. Durch den EventHandler wird festgelegt, auf welche Events
reagiert werden muss. Abschlieend muss die Methode resume ausgef uhrt wer-
den, um den Ruhezustand zu beenden. Ab diesem Zeitpunkt reagiert das erstellte
DispatchSource- Objekt auf Events.
11.3 HawtDispatch und Java New I/O
Das Java-API New I/O (NIO) wird in HawtDispatch durch das Interface
DispatchSource integriert [2]. Der folgende Abschnitt erlautert, welche Funk-
tionalitat durch NIO bereitgestellt wird und wie eine Integration in das HawtDis-
patch-Framework vorgenommen werden kann.
11.3.1 Java New I/O (NIO)
NIO ist eine Sammlung von Java-APIs, welche Funktionalitaten f ur intensive
I/O-Operationen bieten. Eingef uhrt wurde NIO mit der J2SE 1.4, um den exis-
tieren I/O Standard zu erganzen. NIO wurde entworfen, um Zugri auf low-level
I/O-Operationen moderner Betriebssysteme zu ermoglichen. Damit sollte es Java-
Applikationen ermoglicht werden, die ezienten Operationen eines Betriebssys-
tems zu nutzen [3].
Laut [4] besitzt NIO folgende Eigenschaften und Funktionalitaten:
Puer f ur primitive Datentypen
Encoder und Decoder f ur Zeichensatze
Mustererkennung auf Basis von regularen Ausdr ucken
I/O-Abstraktion durch Channels
ein File -Interface, welches Locks und memory mapping von Dateien un-
terst utzt
nicht blockierendes I/O
11.3.2 NIO DispatchSource
Ein DispatchSource-Objekt kann auf Ereignisse in einem SelectableChannel
reagieren, um so NIO in HawtDispatch einzubinden. Um dies zu erreichen, m ussen
der Methode Dispatch.createSource als Parameter ein SelectableChannel,
eine DispatchQueue und eine Operation, auf welche die DispatchQueue rea-
gieren soll, ubergeben werden. Listing 11.1 zeigt ein DispatchSource-Objekt,
welches aus einem SocketChannel Daten liest und ausgibt. Durch die angege-
130 11 HawtDispatch
bene Operatoin OP READ wird das Runnable des EventHandler nur ausgef uhrt,
wenn Daten gelesen werden konnen.
val address = new InetSocketAddress("localhost", 8080)
val queue = createQueue()
val channel = SocketChannel.open(address)
val source = createSource(channel, SelectionKey.OP_READ, queue)
source.setEventHandler(^{
val buffer = ByteBuffer.allocate(1024)
var count = channel.read(buffer)
var input = ""
while ( count > 0 ) {
buffer.flip()
input = new String(buffer.array())
input = input.substring(buffer.position(), buffer.limit())
buffer.clear()
println(input)
count = channel.read(buffer)
}
})
source.resume()
Listing 11.1: DispatchSource: In Anlehnung an NIO DispatchSource [2]
11.3.3 Benutzerdenierte DispatchSource
Benutzerdenierte DispatchSource-Objekte dienen dem Zweck, mehrere Er-
gebnisse zu einem einzigen Ergebnis zu b undeln. Durch eine benutzerdenierte
DispatchSource kann die Kommunikation zwischen Threads verringert werden,
da mehrere generierte Ergebnisse zu dem verarbeitenden Thread als ein zusam-
mengefasstes Ergebnis weitergereicht werden.
Wenn eine benutzerdenierte DispatchSource erzeugt wird, bekommt sie einen
Aggregator zugewiesen. Der Aggregator bestimmt, wie die eintreenden Ergeb-
nisse zusammengefasst werden. Mogliche Aggregatoren sind:
EventAggregators.INTEGER ADD: Fasst Integer-Werte durch Aufaddie-
ren zusammen.
EventAggregators.LONG ADD: Fasst Long-Werte durch Aufaddieren zu-
sammen.
EventAggregators.INTEGER OR: Fasst Integer-Werte zusammen, indem
sie bitweise ODER-verkn upft werden.
11.4 Asynchrones Aufraumen 131
EventAggregators.linkedList(): Fasst Objekte durch Einf ugen in eine Lin-
kedList zusammen.
Threads, die ein Ergebnis ubermitteln wollen, konnen hierf ur die Methode merge
der benutzerdenierten DispatchSource nutzen. Durch den Aufruf der Methode
merge wird der EventHandler der DispatchSource aufgerufen. Auf das Ergeb-
nis, welches durch den Aggregator zusammengefasst wurde, kann mit Hilfe der
Methode getData zugegrien werden.
In Listing 11.2 werden 1.000.000 Zwischenergebnisse erzeugt und an den
EventHandler der benutzerdenierten DispatchQueue weitergeleitet. Dort wird
durch die Ergebnisse die Methode Semaphore.release ausgef uhrt. Die letzte An-
weisung in Listing 11.2 versucht, die Methode Semaphore.acquire auszuf uhren.
Da das entsprechende Semaphor mit einer negativen Zahl initialisiert wurde, ist
dies erst moglich, wenn alle Ergebnisse verarbeitet wurden.
val done = new Semaphore(1 - (1000 * 1000))
val source = createSource(EventAggregators.INTEGER_ADD, queue)
source.setEventHandler(^{
val count = source.getData().intValue()
println("got: " + count)
done.release(count)
})
source.resume()
// 1 000 000 Ergebnisse uebermitteln
for (i <- 1 to 1000) {
globalQueue ^{
for (j <- 1 to 1000) {
source.merge(1)
}
}
}
done.acquire() // Auf Semaphore warten
Listing 11.2: Benutzerdenierte DispatchSource: In Anlehnung an Custom Dispatch
Source [2].
11.4 Asynchrones Aufraumen
In vielen Fallen ist eine Ressource mit mehreren Tasks verbunden. Diese Ressource
muss nach dem Beenden der Tasks wieder freigegeben werden.
132 11 HawtDispatch
Dies kann in HawtDispatch erreicht werden, indem ein disposer callback
f ur eine DispatchQueue oder eine DispatchSource deniert wird. Disposer
callbacks besitzen einen Referenzzahler, welcher durch die Methoden retain
und release manipuliert werden kann. Der Referenzzahler wird mit dem Wert
1 initialisiert. Sobald der Referenzzahler den Wert 0 erreicht, wird das disposer
callback ausgef uhrt.
In dem folgenden Beispiel wird eine Ressource von mehreren Tasks genutzt. Bei
der Ressource handelt es sich um einen PrintStream, welcher geschlossen werden
soll, sobald die Tasks ihn nicht mehr benotigen.
val stream = new PrintStream("File.txt")
queue.setDisposer(^{stream.close})
for (i <- 1 to 10) {
queue.retain()
getGlobalQueue() << ^{
val output = "Eintrag Nr. "+i
queue << ^{
stream.println(output)
queue.release()
}
}
}
queue.release()
Listing 11.3: Asynchrones Aufraumen: In Anlehnung an Asynchronous Cleanup [2].
In Listing 11.3 wird anfangs ein PrintStream und eine SerialDispatchQueue
erzeugt. Der SerialDispatchQueue wird durch die Methode setDisposer ein
Runnable-Objekt ubergeben. Dieses wird ausgef uhrt, sobald der Referenzzahler
von queue den Wert 0 erreicht. In diesem Fall wird durch das Runnable
der PrintStream stream geschlossen, welcher von mehreren Tasks genutzt
wird. Anschlieend werden in einer for-Schleife 10 Tasks erzeugt und einer
ConcurrentQueue zur Ausf uhrung ubergeben. Die erzeugten Tasks erzeugen wie-
derum einen Task, welcher der SerialDispatchQueue queue ubergeben wird.
Die Tasks selbst reduzieren den Referenzzahler mit Hilfe der Methode release, so-
bald sie ihre Arbeit mit dem PrintStream beendet haben. Die Methode release
wird ein weiteres Mal nach dem Durchlaufen der for-Schleife ausgef uhrt. Dies
ist notig, da der Referenzzahler von queue automatisch mit 1 initialisiert wurde.
Die Ressource stream wird somit geschlossen, sobald alle Tasks ihre Arbeit mit
der Ressource beendet haben.
11.5 Anwendungsbeispiel 133
11.5 Anwendungsbeispiel
In diesem Abschnitt soll die Anwendung von HawtDispatch an einem Beispiel de-
monstriert werden. Ziel ist die Implementierung eines Echo-Servers, der die ihm
zugesendeten Nachrichten unverandert zur ucksendet. Der Echo-Server entspricht
dem Beispiel aus [2]. Es wurden lediglich aus Gr unden der Lesbarkeit einige Ver-
einfachungen vorgenommen.
11.5.1 Aufbau des Echo-Server
Der Echo-Server besteht aus den zwei Klassen Session und Server. Server
enthalt die Funktionalitat, Verbindungen mit Clients aufzubauen. Die Klasse
Session verwaltet diese aufgebauten Verbindungen. In der Klasse Session wer-
den die Nachrichten der Clients gelesen und an die Clients zur uckgesendet.
Klasse Server
Um Verbindungen von Clients entgegennehmen zu konnen, nutzt die Klasse
Server ein Objekt der Klasse ServerSocketChannel und ein Objekt der Klasse
DispatchSource. Die DispatchSource wartet darauf, dass ein Client sich mit
dem ServerSocketChannel verbinden will und verarbeitet dieses Ereignis.
Sobald ein Client versucht, eine Verbindung mit dem Objekt der Klasse Server
aufzunehmen, wird ein Objekt der Klasse SocketChannel erzeugt, uber das Client
und Server miteinander kommunizieren. Des Weiteren wird ein Session-Objekt
erzeugt, welches die Kommunikation mit dem Client verwaltet. Zu diesem Zweck
wird dem Session-Objekt eine Referenz auf den SocketChannel ubergeben.
Die Klasse Server ist entsprechend des Listings 11.4 implementiert.
class Server(val port: Int) {
private[this] val serverSocketChannel = ServerSocketChannel.open
serverSocketChannel.socket.bind(
new InetSocketAddress("localhost", port))
serverSocketChannel.configureBlocking(false)
private[this] val queue = createQueue("server")
private[this] val accept_source = createSource(
serverSocketChannel,
SelectionKey.OP_ACCEPT,
queue)
accept_source.setEventHandler(^ {
val socketChannel = serverSocketChannel.accept()
try {
134 11 HawtDispatch
socketChannel.configureBlocking(false)
new Session(socketChannel).start()
} catch {
case e: Exception => socketChannel.close
}
})
accept_source.setDisposer(^ {
serverSocketChannel.close
println("Closed port: "+port)
})
println("Listening on port: "+port)
def start() = {
accept_source.resume()
this
}
def stop() = {
accept_source.release()
queue.release
}
}
Listing 11.4: Klasse Server: In Anlehnung an EchoServer [2].
Klasse Session
Die Klasse Session enthalt zwei DispatchSource-Objekte, welche die Ereignisse
Lesen und Schreiben auf einem SocketChannel uberwachen. Es handelt sich
dabei um die Objekte read source und write source. Tritt eines der genannten
Ereignisse ein, so wird der entsprechende EventHandler ausgef uhrt.
Es ist zu beachten, dass read source und write source nicht gleichzeitig auf
Ereignisse warten. Wird eine Session gestartet, wartet nur die read source auf
Ereignisse. Erst nachdem das Ereignis Lesen eingetreten ist, nimmt write source
seine Arbeit auf und read source wird in einen Ruhezustand versetzt. Nach
dem Ereignis Schreiben wird wiederum die write source in einen Ruhezustand
versetzt und read source wartet wieder auf Ereignisse. Lesen und Schreiben
wechseln sich also ab.
In Listing 11.5 ist die Implementierung der Klasse Session aufgef uhrt.
class Session(val socketChannel: SocketChannel) {
private[this] val buffer = ByteBuffer.allocate(1024)
private[this] val queue = createQueue("session")
private[this] val read_source = createSource(
11.5 Anwendungsbeispiel 135
socketChannel,
SelectionKey.OP_READ,
queue)
private[this] val write_source = createSource(
socketChannel,
SelectionKey.OP_WRITE,
queue)
private[this] val remote_address =
socketChannel.socket.getRemoteSocketAddress.toString
def start() {
println("Accepted connection from: "+remote_address)
read_source.resume
}
def close() {
read_source.release
write_source.release
queue.release
}
queue.setDisposer(^ {
socketChannel.close()
close()
println("Closed connection from: "+remote_address)
})
read_source.setEventHandler(^{
try {
if (socketChannel.read(buffer) == -1) {
println("Closed socketChannel")
close()
} else {
buffer.flip
println("Received from client: "+
new String(buffer.array()))
if (buffer.remaining > 0) {
read_source.suspend
write_source.resume
} else {
buffer.clear
}
}
} catch {
case e: IOException => close
}
})
write_source.setEventHandler(^ {
136 11 HawtDispatch
try {
println("Send to client: "+new String(buffer.array()))
socketChannel.write(buffer)
if (buffer.remaining() == 0) {
buffer.clear
write_source.suspend
read_source.resume
}
} catch {
case e: IOException => close
}
})
}
Listing 11.5: Klasse Session: In Anlehnung an EchoServer [2].
11.6 Fazit
HawtDispatch ermoglicht das Erstellen nebenlauger und verteilter Anwendung-
en. Es sind nur wenige Klassen notig, um eine nebenlauge Anwendung zu kon-
struieren. Dies gestaltet die Programmierung komfortabel und einfach. Allerdings
ist zu beachten, dass HawtDispatch nicht geeignet ist, blockierende Threads zu
koordinieren.
F ur die Programmierung verteilter Anwendungen greift HawtDispatch auf Java
New I/O zur uck. Man muss sich daher mit dieser Technologie vertraut machen,
bevor das Erstellen verteilter Anwendungen moglich ist. HawtDispatch nimmt kei-
ne Abstraktion von dieser Technologie vor. Die Komplexitat des low-level Ansatzes
von Java New I/O bleibt dadurch leider erhalten.
Laut Meinung des Autors ist HawtDispatch vor allem f ur das Erstellen ne-
benlauger Anwendungen geeignet. Die Programmierung von verteilten Anwen-
dungen wird hingegen nur unwesentlich vereinfacht.
[1] H. Chirino, HawtDispatch API Reference. 2010.
[2] HawtDispatch Projektseite, http://hawtdispatch.fusesource.org/.
30.12.2010.
[3] Wikipedia-Artikel: New I/O, http://en.wikipedia.org/wiki/New_I/O.
31.12.2010.
[4] Oracle, New I/O APIs. http://download.oracle.com/javase/1.4.2/
docs/guide/nio/, 31.12.2010.
138 11 HawtDispatch
12 Distributed Program-
ming in Mozart
Sebastian Stallenberger
Inhaltsverzeichnis
12.1 Einf uhrung . . . . . . . . . . . . . . . . . . . . . . . . . 139
12.1.1 Was ist Mozart? . . . . . . . . . . . . . . . . . . 140
12.1.2 Paradigmen . . . . . . . . . . . . . . . . . . . . 140
12.1.3 Die Entwicklungsumgebung . . . . . . . . . . . . 141
12.2 Verteilte Programmierung in Mozart . . . . . . . . . . . . 142
12.2.1 Language Entities . . . . . . . . . . . . . . . . . 142
12.2.2 Umsetzung der Verteilung . . . . . . . . . . . . . 146
12.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
12.1 Einf uhrung
Die Welt der Programmierparadigmen hat sich in den letzten Jahrzehnten stark
gewandelt. Bisher waren in der Industrie besonders die prozeduralen und objek-
torientierten Programmiersprachen verbreitet, die imperative Ansatze verfolgen.
Jedoch halten nun auch immer mehr die Paradigmen der funktionalen und lo-
gischen Programmierung Einzug in den Mainstream. Diese ordnet man den de-
skriptiven Sprachen zu [1].
Allerdings halten sich nicht alle Sprachen streng an nur ein Paradigma. So ge-
nannte Multi-Paradigmen-Sprachen vereinen Eigenschaften mehrerer Paradigmen
in einer Programmiersprache. Zu dieser Art von Sprachen gehort auch Oz. In
dieser Arbeit soll das auf Oz basierende Programmiersystem Mozart vorgestellt
werden. Es wird vor allem auf die wichtigsten Elemente der verteilten Program-
mierung in Mozart eingegangen.
140 12 Distributed Programming in Mozart
12.1.1 Was ist Mozart?
Das Mozart Programming System wurde in den fr uhen 90ern urspr unglich als
DFKI
1
Oz von Gert Smolka und seiner Forschungsgruppe an der Universitat
des Saarlandes entwickelt. 1999 wurde die Entwicklung von einer internationalen
Gruppe, dem Mozart Consortium, wieder aufgenommen. Das Mozart Consortium
war ein Zusammenschluss der Universitat des Saarlandes, dem Swedish Institute
of Computer Science (SICS) und der Universite catholique de Louvain. Zusatzlich
wurde das Projekt von diversen anderen Institutionen unterst utzt. Im Jahre 2005
wurde die Verantwortung f ur die Weiterentwicklung des Projekts an das Mozart
Board ubertragen [3]. Auch heute noch bildet das System den Schwerpunkt einiger
Forschungsprojekte an den genannten Standorten.
Mozart wurde urspr unglich dazu entworfen, in mobilen Agenten verwendet zu wer-
den und Probleme mit k unstlicher Intelligenz zu losen. Heutzutage gehoren An-
wendungsgebiete wie Multiagentsysteme, Sprachverarbeitung und Virtuelle Rea-
litat zum Repertoire.

Ahnlich wie bei Java wird bei Oz plattformunabhangiger
Bytecode von einer virtuellen Maschine ausgef uhrt [2]. Zusatzlich zu den in Mo-
zart integrierten Paketen gibt es ein Modularchiv (Mogul) f ur Module von Dritt-
anbietern. Dass Mozart nicht mehr nur eine reine Forschungssprache ist, zeigt das
Archiv vergangener und laufender Projekte auf GForge [4].
12.1.2 Paradigmen
Wie in Abschnitt 12.1 angesprochen, kombiniert Mozart diverse Paradigmen. Wie
diese Paradigmen umgesetzt werden, wird nun Anhand einiger Beispiele erlautert.
Objektorientierte Programmierung: Mozart arbeitet mit Klassen und Objects.
Es konnen auch abstrakte Datentypen und Vererbung genutzt werden.
Funktionale Programmierung: Mozart nutzt eine kompositionale Syntax. Au-
erdem kommen First Class-Procedures und Lexical Scoping zum Einsatz.
Logische und Constraint-Programmierung: Es gibt logische Variablen, disjunk-
tive Konstrukte und programmierbare Suchstrategien.
Nebenlaugkeit: Man kann Threads erzeugen, die miteinander kommunizieren.
Verteilung: Mehrere Sites konnen miteinander verbunden werden und sich Va-
riablen, Objects, Klassen und Prozeduren teilen. Sites beenden Verbindungen
automatisch, wenn keine Abhangigkeiten mehr existieren.
Sicherheit: Eine Anwendung hat keinen Zugri auf Referenzen, wenn dieser
ihr nicht ausdr ucklich erlaubt wurde.
1
Deutsches Forschungszentrum f ur K unstliche Intelligenz
12.1 Einf uhrung 141
Dies waren nur ausgewahlte Moglichkeiten, die genannten Paradigmen in Mozart
umzusetzen. Im Abschnitt 12.2 wird naher auf die Verteilung in Mozart eingegan-
gen.
12.1.3 Die Entwicklungsumgebung
Die Entwicklungsumgebung von Mozart basiert auf dem Editor Emacs (siehe
Abbildung 12.1). Sie ist f ur alle gangigen Betriebssysteme erhaltlich. Neben einem
Compiler, Debugger und einem Emulator enthalt sie den sogenannten Buer und
den Browser.
Abbildung 12.1: Die auf Emacs basierende Entwick-
lungsumgebung von Mozart.
Der Buer nimmt den oberen
Teil der Arbeitsumgebung ein
und stellt die Einheit dar, in
der vom Nutzer Programmco-
de eingegeben und bearbeitet
werden kann. Der untere Teil
wird abwechselnd vom Com-
piler und dem Emulator ge-
nutzt. Beim Kompilieren wer-
den dem Nutzer die Ausga-
ben des Compilers angezeigt.
Grundsatzlich gibt es in Mo-
zart zwei Moglichkeiten Texte
auszugeben.
Der Emulator arbeitet wie ei-
ne Konsole. Er stellt Ausgaben
des laufenden Programms dar
und nimmt Benutzer-Eingaben an. Texte konnen uber die Funktion Show auf
dem Emulator ausgegeben werden. Folgender Befehl gibt den Text Hello World
auf dem Emulator aus: Show Hello World.
Wird der Browser eingesetzt, onet er sich in einem eigenen Fenster. Er stellt
eine ahnliche Funktionalitat wie der Emulator bereit und kann uber die Funktion
Browse aufgerufen werden. Der nachfolgende Befehl zeigt den Text Hello World
im Browser: Browse Hello World.
Mit modernen, komfortablen Entwicklungsumgebungen wie Eclipse oder Netbeans
kann man die Entwicklungsumgebung von Mozart nicht vergleichen, da weder
Code Completion noch eine Projektverwaltung in der sehr minimalistisch gehal-
tenen Umgebung integriert sind.
12.2 Verteilte Programmierung in Mozart
In diesem Abschnitt soll zuerst geklart werden, was verteilte Programmierung be-
deutet. Laut [5] versteht man unter einem verteilten System
eine Menge von lose

gekoppelten Prozessen, d.h. von Prozessen, die unabhangig voneinander Berech-
nungen ausf uhren und miteinander kommunizieren konnen. [...] Typischerweise
sind verteilte Systeme raumlich, d.h. auf mehrere Rechner verteilt; aber wir be-
trachten auch eine Menge von lose gekoppelten Prozessen auf einem Rechner als
verteiltes System, da die relevanten Fragestellungen und Probleme die gleichen
sind[5]. In Bezug auf Mozart ausgedr uckt heit das, zwei oder mehr Anwen-
dungen teilen sich eine Referenz auf eine Sprachentitat, die es diesen erlaubt,
Informationen auszutauschen. In Mozart werden die Basiseinheiten der geogra-
schen Verteilung Sites genannt. Eine Site ist in unserem Fall ein Prozess auf einer
Maschine. Somit kann ein Multitasking-System auch mehrere Sites hosten [2].
F ur die folgenden Kapitel gilt, wenn nicht anders angegeben, [2] als Quelle.
12.2.1 Language Entities
Um eine Verteilung zu realisieren, stellt Mozart bzw. Oz eine groe Anzahl von
Sprachkonstrukten zur Verf ugung. Die Wichtigsten sollen in den folgenden Ab-
schnitten erlautert werden.
Stateful entities - Objects
Stateful entities sind Konstrukte, die einen Zustand besitzen.

Andert sich der Zu-
stand eines solchen Konstrukts, muss das in der gesamten verteilten Anwendung
global geschehen. Die am haugsten in Mozart eingesetzten Stateful Entities,
welche von Sites erzeugt werden konnen, sind Objects. Eine Site, die ein Object
erstellt hat, wird Owner Site genannt. Entfernte Sites, die das Object nutzen
wollen, heissen Proxy Sites. Objects konnen in drei Unterarten eingeteilt werden.
Gemeinsamkeiten und Unterschiede werden im Folgenden dargestellt.
Cached Objects werden auch Mobile Objects genannt und sind die Default-
Objects. Sie werden immer lokal von der Site, welche die Methode aufgerufen
hat, ausgef uhrt. Eine Site mit dem Vorhaben, eine Methode auszuf uhren, holt
sich zuerst das Object. Dies kann vom Kommunikationsaufwand her bis zu drei
Netzwerk-Messages benotigen. Solange das Object dann aber auf der Site bleibt,
sind keine zusatzlichen Messages mehr notig. Wollen mehrere Sites auf das gleiche
Object zugreifen, bekommt jede Site die Nutzung nach dem Fair-Share-Verfahren
zugeteilt. Der Ablauf einer Object-
Ubergabe lasst sich wie folgt beschreiben:

12.2 Verteilte Programmierung in Mozart 143
1. Die Site (A), die auf ein entferntes Object zugreifen will, schickt zuerst eine
Message an die Owner Site (C).
2. Site (C) sendet daraufhin einen Forwarding Request an die Site (B), die das
Object gerade hostet.
3. Site (B) sendet dann Site (A) einen Zeiger auf das Object.
Die Klasse eines Cached Objects wird auf jede Site kopiert, die das Object aufruft.
Dies geschieht lazily. Die Klasse wird also nur bei ihrer ersten Verwendung kopiert.
Davor und danach nden keine Kopien statt.
Um Cached Objects zu erstellen, wird das Schl usselwort Newgenutzt.
Bsp.: Obj=New Class Init
Stationary Objects werden besonders gerne f ur Server genutzt, da sie auf ihrer
Owner Site bleiben. Jeder Methodenaufruf nutzt zwei Messages: Die erste, um die
Methode zu starten. Die zweite, um sich mit dem Aufrufenden zu synchronisieren,
wenn die Methode beendet wurde. Auftretende Exceptions werden im Thread
der aufrufenden Site ausgelost. Jede aufgerufene Methode wird in einem eigenen
Thread auf der Site ausgef uhrt, die das Object erstellt hat.
Zur Erstellung von Stationary Objects nutzt man das Schl usselwort NewStat.
Bsp.: Obj=NewStat Class Init
Sequential Asynchronous Stationary Objects nutzen im Gegensatz zu den
Stationary Objects nur eine Message und warten nicht, bis die Methode beendet
wurde. Alle Methodenaufrufe werden im gleichen Thread ausgef uhrt. Es ndet
also eine komplett sequentielle Ausf uhrung statt. Exceptions, die in einer Methode
nicht abgefangen werden, werden von der aufrufenden Site ignoriert.
Sequential Asynch. Stationary Objects nutzen das Schl usselwort NewSASO.
Bsp.: Obj=NewSASO Class Init
Andere Stateful Entities
Neben den vorgestellten Objects gibt es noch andere Konstrukte, die einen Zu-
stand haben konnen.
Ein Thread f uhrt eine Folge von Anweisungen aus. Er ist stationar auf der Site,
von der er erzeugt wurde. Threads kommunizieren uber gemeinsame Daten. Sind
diese Daten nicht verf ugbar, blockieren sie. Dies kann zum Beispiel auftreten,
wenn versucht wird, auf eine ungebundene logische Variable zuzugreifen.
Ports in Mozart sollten nicht mit den aus der Netzwerktechnik bekannten Ports
verwechselt werden. Wahrend sich bei Ports in der Netzwerktechnik um ein Kon-
zept auf Betriebssystem-Ebene handelt, ist es bei Mozart ein Sprachkonzept. Ein
Port ist ein asynchroner n:1 Kanal, der nach dem FIFO Prinzip arbeitet. Wie auch
Threads ist ein Port stationar auf seiner Owner Site. Neue Messages werden an
einen Stream der Owner Site des Ports angehangt. Schickt ein Thread mehre-
re Messages, werden sie in der Reihenfolge an den Stream gehangt, in der sie
abgesendet wurden. Der Stream eines Ports wird von einem sogenannten Future
beendet. Was ein Future ist, wird weiter unten genauer erlautert.
Eine Cell ist ein veranderbarer Zeiger auf ein anderes Konstrukt. Cells haben
prinzipiell die gleiche verteilte Semantik wie Cached Objects. Um einen Zeiger zu
aktualisieren, benotigt man also bis zu drei Messages.
Ein Thread-Reentrant Lock erlaubt nur einem einzigen Thread, einen bestimm-
ten Programmabschnitt zu betreten. Locks haben ebenfalls die gleiche verteilte
Semantik wie Cached Objects.
Single-Assignment Entities
Grob lassen sich die Single-Assignment Entities in Dataow-Variables und Streams
einteilen. Sie konnen gebunden und gelesen werden. Wird eine Dataow-Variable
gebunden, bindet man alle verteilten Referenzen auf diese an den gleichen Wert.
Zwei Unterarten von Dataow Variables sind in Mozart integriert. Die Logic Va-
riables ahneln einer nal-Variable in Java. Zwei dieser logischen Variablen konnen
aneinander gebunden werden, bevor ihnen ein Wert zugeordnet wurde. Gr unde f ur
den Einsatz von Logic Variables gibt es mehrere. Zum einen sind sie der Basis-
Mechanismus der nebenlaugen Programmierung. Zum anderen werden sie aus
Ezienzgr unden eingesetzt, da sie als Platzhalter verwendet werden konnen. Ei-
ne Logic Variable kann man bereits einsetzen, bevor sie einen Wert hat. Wird ihr
dann ein Wert zugewiesen, wird dieser an alle Sites geschickt, die eine Referenz
diese Logic Variable haben. Theoretisch liee sich das auch mit Cells realisieren,
ware aber deutlich weniger performant, da das Protokoll hinter Logic Variables
ezienter als das hinter Cells ist.
Ein Future hingegen ist eine Logic Variable, die nur lesbar ist. Versucht eine
Site, ein Future zu binden, so blockt dieses. Futures konnen daf ur genutzt wer-
den, Logic Variables davor zu sch utzen, von unautorisierten Sites gebunden zu
werden. Zusatzlich nden sie, wie in einem vorgehenden Abschnitt angesprochen,
Verwendung im Umgang mit Ports.
Ein Stream ist ein Kanal zur 1:n Kommunikation. Somit kann mit der Kombina-
tion eines Ports und eines Streams ein asynchroner m:n Kanal aufgebaut werden.
Detaillierter betrachtet ist ein Stream eine Liste, deren letztes Element eine Da-
taow Variable ist. Wird ein Stream an die Owner Site gebunden, wird diese
Bindung asynchron an alle Sites geschickt, die diese Variable besitzen. Bindungen
sind im Stream in der Reihenfolge angeordnet, in der sie im Thread auftreten.
Stateless Entities
Wie dem Namen entnommen werden kann, sind Stateless Entities Sprachkon-
strukte ohne internen Zustand. Ein solches Konstrukt andert sich nie und kann
somit als Konstante bezeichnet werden. Das hat den groen Vorteil, dass eine
solche Konstante sehr ezient in einer einzigen Message uber das Netz verteilt
werden kann. Die verschiedenen Arten von Stateless Entities lassen sich zum
einen dadurch unterscheiden, auf welche Weise sie kopiert werden, eagerly oder
lazily, zum anderen dadurch wieviele Kopien eines solchen Konstrukts auf einer
Site existieren d urfen. Im Folgenden sollen nun die verschiedenen Moglichkeiten
des Kopierens erlautert werden und anschlieend die Typen der Stateless Entities
diesen zugeordnet werden.
Lazy (on demand): Eine Kopie wird nur dann erstellt, wenn sie auch wirklich
benotigt wird. Dies hat den Vorteil, dass eine geringere Anzahl von Messages
entsteht, bringt aber eine erhohte Latenz mit sich.
Eager (on supply; always send): Der Wert ist in der Message enthalten. Hier-
durch wird eine minimale Latenz erreicht, kann aber durch die vielen Messages
zur Netz uberlastung f uhren.
Eager (on supply; send, if not present): Der Wert ist nicht Teil der Message.
Ist der Wert bis zum Empfang der Message nicht vorhanden, wird er angefordert.
Dieses Verfahren wird f ur die meisten Anwendungsfalle empfohlen.
Zu den Stateless Entities in Mozart zahlen:
Records und Numbers werden eagerly kopiert.
Procedures, Functions, Classes, Chunks, Atoms und Names werden auch Si-
ted Components genannt. Sie werden eagerly ubers Netzwerk kopiert, d urfen
allerdings nur einmal auf einer Site existieren.
Object-records werden lazily kopiert.
Abbildung 12.2: Prozessorientierte Ansicht des verteilten Modells in Mozart in Anleh-
nung an [6].
Ein beispielhafter, schematischer

Uberblick uber die genannten Konstrukte ist in
Abbildung 12.2 zu nden.
12.2.2 Umsetzung der Verteilung
In den vorigen Kapiteln wurde auf die verschiedenen Sprachkonstrukte in Mozart
eingegangen. Nun werden die von Mozart bereitgestellten Techniken beschrieben,
mit denen die Verteilung umgesetzt werden kann. Vorher sollten allerdings noch
wesentliche Grundlagen zur verteilten Programmierung geschaen werden.
Arten der Verteilung
Grundsatzlich unterscheidet man zwischen oener und geschlossener Verteilung.
In der oenen Verteilung kann ein Prozess unabhangig von anderen Prozessen
eine Berechnung durchf uhren ohne zu wissen, mit welchem Prozess er sich verbin-
den oder welchen Typ Information er austauschen konnte. In der geschlossenen
Verteilung startet und erschat ein Prozess selbst andere Prozesse auf verschie-
denen Maschinen, auf die er Zugri hat. In beiden Fallen ist es wichtig, dass
Klarheit uber die Namensgebung der verteilten Konstrukte herrscht. Das f uhrt
uns zum nachsten Punkt.
Global Naming
Um Verwirrungen bei der Kommunikation zu vermeiden, sollten gleiche Konstruk-
te in verschiedenen Sites uberall gleich benannt sein. Um diese Namensgebung
f ur Konstrukte korrekt umzusetzen, gibt es in Mozart diverse Techniken.
Eine Reference stellt eine falschungssichere Moglichkeit dar, auf eine Entitat
zuzugreifen. Programmen gegen uber ist es transparent, was bedeutet, dass bei
benotigtem Zugri darauf dereferenziert wird. Eine Referenz kann lokal auf eine
Entitat in der gleichen Site oder verteilt auf eine Entitat in einer entfernten Site
angelegt werden. Beispielsweise kann ein Thread eine Referenz auf eine Entitat
anlegen, welche in einer entfernten Site beheimatet ist.
Names sind falschungssichere Konstanten, die dazu genutzt werden, abstrakte
Datentypen zu implementieren.
URLs sind globale Referenzen auf Dateien, die auf einem oder mehreren Webser-
vern liegen.
Tickets zahlen zu den wichtigsten Techniken in Mozart, um Verteilung zu reali-
sieren. Prinzipiell ist ein Ticket eine globale Moglichkeit, auf jede Spracheinheit
zuzugreifen. Tickets sind References sehr ahnlich, allerdings sind Tickets uberall,
also auch auerhalb eines Mozart Prozesses g ultig. Reprasentiert werden sie durch
ASCII Strings, z.B. oz-ticket://192.168.6.115:9000/h4074176#1*.
Ein Ticket kann uber jegliche Kommunikationsprotokolle zwischen Prozessen
kommunizieren, z.B. TCP/IP oder SNMP. Die Verteilung eines Tickets kann lokal
uber das File System (auch LAN) oder global uber einen Webserver stattnden.
Theoretisch konnte ein Ticket aber auch per Telefon oder Mail weitergegeben
werden. Tickets werden normalerweise nur in Verbindung mit simplen Datenty-
pen genutzt. Sie konnen aber theoretisch f ur alle Falle eingesetzt werden, in denen
eine Information in ASCII-Form codiert werden kann.
Module
Um die angesprochenen Techniken umzusetzen, stellt Mozart Module bereit.
Connection stellt den Basis-Mechanismus Tickets bereit, uber den aktive An-
wendungen miteinander Kontakt aufnehmen konnen. Mozart macht es dem Pro-
grammierer einfach, indem es das Handling der Verbindungen ubernimmt und
eine verteilte Garbage Collection bereitstellt. Die drei Methoden der Connections
sind:
Anbieten eines Tickets kann uber zwei Methoden realisiert werden:
Connection.offerOnce X T erzeugt ein Ticket T f ur das Sprachkonstrukt
X. Der Versuch, das Ticket mehr als einmal zu referenzieren, lost eine Excep-
tion aus.
Connection.offerMany X T verhalt sich ahnlich wie oerOnce, allerdings
kann ein Ticket hier mehrmals referenziert werden.
Annehmen eines Tickets mittels Connection.take
Connection.take T X erzeugt eine Referenz X aus dem Ticket T.
Pickle erlaubt es Applikationen beliebige Daten ohne Zustand aus Dateien und
von URLs zu laden und auch zu schreiben.
Pickle.save X PathV speichert X auf den Pfad PathV.
Pickle.load UrlV Value ladt einen Wert Value von dem Ort UrlV.
Will man Daten verteilen, die einen Zustand haben, kann man dies uber Cells
(z.B. C=NewCell unit) realisieren.
Wie zu Beginn des Abschnitts angesprochen, unterscheidet man zwischen oener
und geschlossener Verteilung. Ein Modul, das f ur die geschlossene Verteilung
genutzt werden kann, ist Remote. Es erlaubt einer aktiven Anwendung, eine
neue Site als lokalen oder entfernten Prozess zu erschaen und sich damit zu
verbinden. Der Code f ur die Erstellung und Initiierung eines solchen Konstrukts
konnte zum Beispiel wie folgt aussehen:
R=New Remote.manager init(host:eine.entfernte-maschine.de,
fork: automatic)
Die Init-Funktion nimmt die Parameter host und fork entgegen. Unter host wird
die Adresse der Maschine, auf der der Prozess erstellt werden soll, angegeben.
Die Default-Einstellung f ur fork ist rsh, also Remote Shell. Alternativ kann hier
aber auch automatic, sh oder ssh angeben werden. Der Shell-Zugang auf dem
unter host angegebenen Gerat muss allerdings vorher eingerichtet worden sein.
Wenn in der init-Funktion f ur host localhost und f ur fork automatic angegeben
wurde, kommunizieren die Sites uber Shared Memory statt uber Sockets, da dies
deutlich ezienter ist.
Wurde die Verbindung initiiert, konnen uber die Methode apply() neue Funkto-
ren installiert werden. Funktoren sind in Mozart Kompilierungs-Einheiten, die als
Sourcecode oder Objectcode vorliegen konnen. Beim Aufruf R apply(F X)
installiert den Funktor F auf dem Remoteprozess und gibt das Modul dann in X
zur uck.
DP
2
stellt Techniken bereit, mit denen die Verteilung von Konstrukten, die Feh-
lerentdeckung und die Fehlerbehandlung konguriert werden konnen.
12.3 Fazit
Mozart verfolgt interessante Ansatze und stellt Techniken bereit, welche die ver-
teilte Programmierung erleichtern. Die in diesem Kapitel vorgestellten Techniken
decken hierbei bei weitem noch nicht das gesamte Repertoire von Mozart ab.
Projekte aus der Praxis zeigen, dass es zwar eher eine in der Forschung eingesetz-
te Sprache ist, aber in der Losung spezieller Problemstellungen auch praktische
Anwendung ndet.
[1] Wolfgang Reisig and Johann-Christoph Freytag, Informatik: Aktuelle Themen
Im Historischen Kontext. Springer Verlag Berlin Heidelberg, 2006.
[2] Peter Van Roy, Seif Haridi, Per Brand and Raphael Collet, Mozart Documen-
tation. http://www.mozart-oz.org/documentation/, 2011-01-24
[3] Peter Van Roy, Seif Haridi, Per Brand and Raphael Collet, Mozart Governance.
http://www.mozart-oz.org/governance.html, 2011-01-24
[4] Mozart Projects, http://gforge.info.ucl.ac.be/plugins/wiki/index.php?id=17
&type=g, 2011-01-24
2
Modul General Distributed Programming Support
[5] Arnd Poetzsch-Heter,Konzepte objektorientierter Programmierung: Mit ei-
ner Einf uhrung in Java, Springer Verlag Berlin Heidelberg, 2009.
[6] Peter Van-Roy and Seif Haridi,Concepts, techniques, and models of computer
programming, Massachusetts Institute of Technology, 2004.
13 ZeroMQ
Christopher Ezell
Inhaltsverzeichnis
13.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 151
13.2 Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . 152
13.3 Vorteile von ZeroMQ . . . . . . . . . . . . . . . . . . . . 152
13.3.1 Asynchrone Ein- und Ausgabe . . . . . . . . . . . 153
13.3.2 Verf ugbare Sprachbindings . . . . . . . . . . . . . 153
13.4 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 154
13.4.1 Concurrency modell . . . . . . . . . . . . . . . . 154
13.4.2 Mailbox-System von MQ . . . . . . . . . . . . 155
13.5 Schritte um MQ einzusetzen . . . . . . . . . . . . . . . 155
13.5.1 Wahlen eines Transportmechanismus . . . . . . . 155
13.5.2 Wahlen einer Infrastruktur . . . . . . . . . . . . . 156
13.5.3 Auswahlen eines Nachrichten-Fluss-Musters . . . 157
13.6 Sicherheit in ZeroMQ . . . . . . . . . . . . . . . . . . . . 159
13.7 Hands on ZeroMQ! . . . . . . . . . . . . . . . . . . . . . 160
13.7.1 Installation . . . . . . . . . . . . . . . . . . . . . 160
13.7.2 Beispiele . . . . . . . . . . . . . . . . . . . . . . 161
13.8 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
MQ, gesprochen ZeroMQ stellt ein Framework zur asynchronen Kommunika-
tion dar. Es ist eine in C++ geschriebene Socket-Bibliothek, die auf asynchro-
ne Kommunikation baut. Sie dient zum Versand von Nachrichten uber inter-
process communication (IPC), Transmission Control Protocol (TCP) und einem
Multicast-Mechanismus innerhalb eines Computers oder innerhalb eines Netzwer-
kes. Am 30. Marz 2010 wurde die Version 1.0 veroentlicht. Entwickelt wird MQ
von der iMatix-Corporation und einer Open-Source-Community.
13.1 Einleitung
Die Entwicklung von verteilten Anwendungen hat in den letzten Jahren stark zu-
genommen. Es wurden immer machtigere Frameworks zur Entwicklung solcher
152 13 ZeroMQ
Systeme programmiert. Ein Nachteil dieser Systeme sind die immer groer wer-
denden Anforderungen an die Hardware alleine zum Betreiben der Middleware.
MQ mochte hier einen neuen Weg beschreiten und bietet ein sehr schlankes und
leicht verstandliches Interface zum Austausch von Nachrichten. Hierbei baut es
auf die Verwendung von asynchronen I/O-Techniken [7] um eine optimale Aus-
lastung der Hardware zu gewahrleisten. Die Entwickler von MQ bezeichnen es
als ein message queueing-System. Es unterscheidet sich von klassischen MOMs
(Message oriented Middleware) durch die Abwesenheit einer Broker-Architektur.
Dies bedeutet, dass es per se keinen zentralen Verwalter der Nachrichten gibt,
sondern die einzelnen Knoten gleichberechtigt in dem Netz existieren und agieren.
Es wird unter der LGPL-Lizenz in C++ entwickelt und vertrieben. Ziel des MQ-
Projektes ist es die Entwicklung eines komplexen Systems ohne viel Aufwand zu
ermoglichen. Aber es wird auf der Projekthomepage explizit gesagt, dass MQ
kein
out-of-the-box Produkt ist, sondern es ist auf den meisten Plattformen

nur als Quellcode verf ugbar. Es gibt aber auch hier Ausnahmen (so gibt es f ur
manche Sprachbindings installierbare Pakete). Es kann als eine Art Abstraktion
von der blanken Socket-API gesehen werden, die die unliebsamen Details vom
Entwickler fern halt. Alle in diesem Kapitel verwendeten Informationen sind von
der ZeroMQ Website [1], speziell von dem Guide [2].
13.2 Geschichte
MQ wurde anfanglich von der Firma iMatix-Corporation und dort im speziel-
len von dem Ernder von MQ, Pieter Hintjensals, entwickelt. Es entstand aber
schnell eine groe Community rund um MQ. Pieter Hintjensals (CEO von iMa-
trix) war anfanglich ein Mitentwickelter des AMQP-Protokolls[3]. Er fand dieses
Protokoll aber nach einiger Zeit zu komplex und unbrauchbar. Daher verlie er die
AMQP working group. Er wollte gerne eine schlankere Alternative. Aus diesem
Gedanken entstand MQ. Die aktuelle Version ist 2.0.10 (Stand: Januar 2011).
13.3 Vorteile von ZeroMQ
Bei naherem Betrachten liegen die Vorteile von MQ auf der Hand. Es verspricht
von sich selber:
The socket library that acts as a concurrency framework. Man

kann also mit Hilfe dieser Bibliothek eine asynchrone Kommunikation aufbauen,
ohne selber diese Techniken im Detail beherrschen zu m ussen. Das Zitat von
einem MQ-Entwickler zu der Verwendung von ZeroMQ gegen uber normalen
Sockets ist das Folgende: If youve done any work with threads, protocols,
or networks, youll realize this is pretty much impossible. Its a dream. Even
13.3 Vorteile von ZeroMQ 153
connecting a few programs across a few sockets is plain nasty, when you
start to handle real life situations. Es macht klar, dass er viele Probleme, die
in der Verwendung von Sockets gr unden, in der komplexen Handhabung dieser
liegen. Man macht schnell Fehler und braucht zu viel Expertenwissen um gute
Socket-Programme zu schreiben. Die Verwendung von MQ bietet in seinen
Augen die folgenden Vorteile:
Skalierbarkeit:
Verbindung von einem MQ-Socket zu mehreren anderen MQ-Sockets
moglich (Multicasting)
Einfachheit:
simple und einfache API
Performance:
kein Overhead durch komplexes Protokoll
13.3.1 Asynchrone Ein- und Ausgabe
Asynchrone Ein- und Ausgabe (Asynchronous I/O oder auch non-blocking I/O ge-
nannt) ist die Art mit I/O Verarbeitung in einem Rechnersystem umzugehen. Der
Unterschied zu nicht asynchronen Ein- und Ausgaben, ist die Moglichkeit wahrend
der Verarbeitung von Festplattenzugrien oder dem Senden eines IP Paketes
in der Hardware, das eigentliche Programm in der CPU weiter auszuf uhren[6].
Die Verarbeitung geschieht also asynchron (nicht synchronisiert). Wenn die I/O-
Verarbeitung fertig ist, kann mit Callbacks oder einer Poll-Methode darauf rea-
giert werden. Dies ist bei Programmen, die viel I/O benotigen (wie zum Beispiel
Netzwerkprogramme), ein sehr groer Geschwindigkeitsvorteil. Der Grund liegt in
der sehr viel groeren Verarbeitungs-Geschwindigkeit des Prozessors gegen uber
der Festplatte und Netzwerkkarten. ZeroMQ nutzt diese Art der Verarbeitung f ur
die Kommunikation zwischen Prozessen auf einem Rechnersystem oder zwischen
mehreren im Netzwerk. Hierdurch entsteht eine viel eektivere Methode solche
Mechanismen in einem Rechner zu parallelisieren, aber trotzdem die Details dieser
Technik vor dem Nutzer von MQ zu verbergen.
13.3.2 Verf ugbare Sprachbindings
Ein weiterer Vorteil von ZeroMQ ist die Interoperabilitat der Programme und Por-
tierbarkeit auf verschiedene Sprachen durch die uber 20 Sprachbindings. Nachfol-
gend sind einige aufgelistet:
Ada, Basic, C, C++, C#, Common Lisp, D, Erlang, Go, Haskell,
Objective-C, Perl, PHP, Python, Racket, Ruby, Ruby, Tcl, Lua
154 13 ZeroMQ
13.4 Architektur
Abbildung 13.1: ZeroMQ Stack
Sehen wir uns nun die Architektur von MQ
an. In diesem Kapitel soll geklart werden, wie
MQ funktioniert und was f ur eine Architek-
tur hier zugrunde liegt. Wir schauen uns zu-
erst das
Concurrency-Model an und dann

das Mailboxsystem. Grundlegend zur Architek-
tur ist zu sagen, dass MQ wie in Abbildung
13.1 zu sehen auf der Schicht 5 in dem ISO
OSI Modell [5] angesiedelt ist, wenn es uber
TCP lauft.
13.4.1 Concurrency modell
In MQ gibt es generell zwei Arten von Threads. Die einen werden I/O Threads
genannt. Sie sind daf ur zustandig die asynchrone Eingabe und Ausgabe intern
in MQ zu regeln. Wie viele es von ihnen gibt, kann man uber einen Para-
meter beim Erstellen des Kontextes regeln. Auf der anderen Seite stehen die
Application-Threads. Diese werden verwendet um von auen auf die libary zu-
zugreifen (siehe Abbildung 13.2). Zur Synchronisierung ist noch zu sagen, dass
MQ, von der Synchronisierung der Mailboxen (nachstes Kapitel) abgesehen,
komplett auf Mutexe, Entscheidungs-Variablen und Semaphoren verzichtet. Hier-
durch kann eine hohere Geschwindigkeit durch weniger Synchronisationsaufwand
erreicht werden. Des Weiteren wird intern so gearbeitet, dass jedes Objekt in
seinem eigenen Thread lauft und auch nicht auf Datenstrukturen eines anderen
Threads zugreift, daher der wenige Synchronisationsaufwand.
Abbildung 13.2: Threading Modell in MQ
13.5 Schritte um MQ einzusetzen 155
13.4.2 Mailbox-System von MQ
Kommen wir nun zu dem Mailbox-System, das in MQ Anwendung ndet. In
MQ ist jedes Objekt ein eigener Thread, der einer Mailbox zugeordnet ist. Eine
Mailbox ist eine Art
Queue, die Nachrichten und Kommandos f ur ein Objekt

erhalt. Wobei hier zwischen
Nachrichten und
Kommandos hart unterschieden

wird. Nachrichten sind verschickte Informationen auf Userlevel und Kommandos
auf Objektlevel. Das Objekt (der Thread) kann diese Mailbox nun abrufen und
so Nachrichten empfangen. Objekte sind also nichts weiter als Threads mit einer
Mailbox.
Abbildung 13.3: Zwei Threads mit Mailbox in MQ
13.5 Schritte um MQ einzusetzen
Um nun eine konkrete Umsetzung eines Systems mithilfe von MQ zu erstellen
empfehlen die Entwickler folgende drei Entscheidungen (Schritte) als Reihenfolge.
13.5.1 Wahlen eines Transportmechanismus
Als erstes uberlegt man sich in welchem Kontext die Applikation laufen soll, also
ob es uber Rechnergrenzen hinweg oder nur auf einem Rechner lauft. Hier werden
von MQ folgende Techniken unterst utzt.
156 13 ZeroMQ
INPROC
Dieser Modus ist f ur eine Kommunikation innerhalb eines Prozesses gedacht
und kann hier sehr performant eingesetzt werden. Aber es gibt nur wenige
Situationen, in der dieser Mechanismus sinnvoll eingesetzt werden kann.
IPC
Dieser Modus ist f ur die Kommunikation zwischen Prozessen geeignet und
kann nur lokal genutzt werden.
MULTICAST
Der Multicast von MQ baut auf den Mechanismus von PGM auf (siehe [10]).
TCP
Dies ist das bekannte TCP, dass auch uber Rechnergrenzen hinweg genutzt
werden kann. Hier konnen mithilfe einer gesicherten

Ubertragung Nachrichten
versendet und empfangen werden [4].
13.5.2 Wahlen einer Infrastruktur
Nachdem nun klar ist, in welchem Kontext das Programm lauft, gilt es nun zu
entscheiden, welche Infrastruktur das Netz von Knoten haben soll. Es stehen
folgende Moglichkeiten zur Wahl:
Abbildung 13.4: Forwarder
13.5 Schritte um MQ einzusetzen 157
QUEUE
Dieses Modell einer Infrastruktur ist eine Kommunikation uber einen War-
teschlangenmechanismus. Daten, die von einem Knoten eingebracht werden,
werden nach dem FIFO-Prinzip an den anderen Knoten geleitet.
FORWARDER
Ein so genannter FORWARDER dient dazu, in einem PUB/SUB (siehe
Nachrichten-Fluss-Muster), die Moglichkeit zur Traversierung zu bieten. Er
dient als eine Art Proxy in dieser Struktur (siehe Abbildung 13.4).
STREAMER
Ein FORWARDER mit pipelineartigem Nachrichtenuss.
13.5.3 Auswahlen eines Nachrichten-Fluss-Musters
Als dritter Punkt sollte noch geklart werden, wie der Fluss von Nachrichten in
dem System ablauft. Also Wer? Wem? Wann? eine Nachricht schicken kann. Hier
gibt es vier generelle Verfahren:
REQUEST/REPLY:
Dies ist der klassische Fall. Ein Kommunikationspartner ubernimmt den
REQUEST-Part und sendet Anfragen (normalerweise der Client). Der andere
ubernimmt den REPLY-Part und antwortet (normalerweise der Server). Dieses
Muster kann angewendet werden, wenn ein Part im System einen Dienst f ur
andere anbietet.
PUBLISH/SUBSCRIBE:
Durch diese Kommunikationsmethode ist es moglich, mehreren Empfangern
gleichzeitig eine Nachricht zu senden. Dies funktioniert uber so genannte
To-
pics, also Themengebiete. Ein Sender stellt f ur gewisse Interessengebiete neue
Nachrichten zur Verf ugung. Empfanger, die sich auf diese Gebiete
angemel-
det haben, konnen diese Nachrichten empfangen (dies ist in Abbildung 13.5
dargestellt).
UPSTREAM / DOWNSTREAM
Diese Methode kann man sich als einen Verbund von virtuellen Pipelines vor-
stellen. In dieser Pipeline sind verteilte Knoten miteinander verbunden. Am
oberen Ende ist ein Sender, der Daten in die verschiedenen Pipelines einf ullt
(siehe Abbildung 13.6). In der Mitte sind ein oder mehrere Empfanger, die die
Daten verandern und weiterleiten. Am Ende sind ein oder mehrere Empfanger
der Daten. Man kann sagen, dass dieser Kommunikations-Mechanismus ein
spezieller Fall des
Pipes and Filters-Patterns ist[11].

PAIR
Hier werden ganz klassisch immer zwei Kommunikationspartner miteinander
158 13 ZeroMQ
fest verbunden, die uber einen Kanal kommunizieren konnen. Diese Art, Kno-
ten miteinander zu verbinden, hat in neueren Applikationen nur noch zweit-
rangige Bedeutung.
#define ZMQ_PAIR 0
#define ZMQ_PUB 1
#define ZMQ_SUB 2
#define ZMQ_REQ 3
#define ZMQ_REP 4
#define ZMQ_XREQ 5
#define ZMQ_XREP 6
#define ZMQ_PULL 7
#define ZMQ_PUSH 8
#define ZMQ_UPSTREAM ZMQ_PULL
#define ZMQ_DOWNSTREAM ZMQ_PUSH
Listing 13.1: Denition der Socket-Typen in zmq.h.
Abbildung 13.5: PUBLISH/SUBSCRIBE
Zusammenspiel von Socket-Typen
In MQ gibt es unterschiedliche Socket-Typen. Diese sind in der zmq.h deniert.
Sie konnen nur in bestimmter Kombination verwendet werden. Und zwar in den
folgenden: PUB und SUB, REQ und REP, REQ und XREP, XREQ und REP,
XREQ und XREP, XREQ und XREQ, XREP und XREP, PUSH und PULL,
PAIR und PAIR. In anderen Kombinationen funktioniert der Mechanismus nicht.
13.6 Sicherheit in ZeroMQ 159
Abbildung 13.6: UPSTREAM/DOWNSTREAM
Dies ist eine wichtige Information f ur MQ Entwickler, da sonst unerwartete Feh-
ler auftreten konnen oder auch das gar nichts passiert. Zu sehen ist die Denition
in Listing 13.1.
13.6 Sicherheit in ZeroMQ
Ein weiterer wichtiger Punkt bei MQ ist das Thema Sicherheit. Es ist den
Entwicklern von MQ sehr wichtig ein sehr robustes und stabiles System zu
liefern. Viele Performance- und Stabilitatstests werden durchgef uhrt um die
Qualitat der Software immer weiter zu verbessern. Am 13.10.2010 startete die
MQCommunity zu diesem Zweck ein Spiel [12]. In diesem Spiel geht es dar-
um, einen Fehler in dem Design von MQ zu nden und mittels eines dazu
praparierten IP-Paketes die Software zum Absturz zu bringen. Durch dieses Spiel
soll es gelingen die Sicherheit der Software innerhalb k urzester Zeit erheblich zu
verbessern. Jedem, den es gelingt einen solchen Fehler zu benennen, bekommt
einen Punkt. Jeder der es schat, diesen Fehler mittels eines Patches zu beheben,
bekommt sogar drei Punkte. Der Gewinner, der am Ende der Aktion die meisten
Punkte hat, bekommt einen speaker-slot auf der MQ-Konferenz und die Reise
dorthin, inklusive Hotel.
160 13 ZeroMQ
13.7 Hands on ZeroMQ!
Kommen wir uns nun zum praktischen Teil des Kapitels. In diesem Abschnitt wol-
len wir anhand eines einf uhrenden Beispiels die Verwendung von MQ verdeutli-
chen. Hierzu werden wir erst die Installation von MQ betrachten, um dann im
zweiten Teil einige Beispiele durch zu gehen, um die grundlegenden Mechanismen
von ZeroMQ zu verdeutlichen. Weitere Beispiele in allen verf ugbaren Sprachen
sind uber [8] erreichbar.
13.7.1 Installation
Zur Installation wird auf der Website von MQ geraten sich unter [9] den Source-
Code des Projektes zu laden und auf seinem Rechner selbst zu kompilieren. Dies
geht nach der Erfahrung des Autors auf einem Linux System mit
make am bes-
ten. Es gibt auch die Moglichkeit, es auf einem Windows-System mit dem Visual
Studio zu kompilieren. Auch die meisten Bindings zu anderen Programmierspra-
chen sind nur im Source-Code vorhanden.
#include <zmq.hpp>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
int main () {
// Prepare our context and socket
zmq::context_t context (1);
zmq::socket_t socket (context, ZMQ_REP);
socket.bind ("tcp://*:6666");
while (true) {
zmq::message_t request;
// Wait for next request from client
socket.recv (&request);
printf ("Received request: [%s]\n",
(char *) request.data ());
// Do some work
sleep (1);
// Send reply back to client
zmq::message_t reply (6);
memcpy ((void *) reply.data (), "World", 6);
13.7 Hands on ZeroMQ! 161
socket.send (reply);
}
return 0;
}
Listing 13.2: Beispiel eines Hello World Servers in ZeroMQ.
13.7.2 Beispiele
Wir fangen, wie in allen ersten Tutorials, mit einem kleinem Hello World-
Programm an. Es ist ein in C++ geschriebener Client und Server, die sich ge-
genseitig Hello und World Pakete schicken. Dieses ist in Listing 13.2 gezeigt. Als
erstes wird der Server erstellt. Er soll Pakete annehmen und ein Paket mit dem
Inhalt World zur uckschicken. Um eine MQ-Applikation zu starten, muss man
zuerst den MQ-Kontext erstellen. Hier werden Thread-Pools angelegt und wei-
tere Initialisierungen durchgef uhrt. Die Zahl, die als Parameter an den Kontext
ubergeben wird ist die Anzahl an IO-Threads, die erzeugt werden sollen. Nun
wird mithilfe des erstellten Kontextes ein MQ-Socket erzeugt. Hier wird der
Parameter REP (f ur Reply) ubergeben. Dieser zeigt an, dass dieses Socket auf
Anfragen antwortet. Danach wird das erstellte Socket an einen Endpunkt gebun-
den (bind). Dies ist hier ein TCP-Endpunkt mit dem Port 6666. Das Sternchen
fungiert als Platzhalter, da es sich um eine Verbindung handelt, die von einem an-
deren Teilnehmer aufgerufen wird. Daher kann die gebundene IP immer wechseln.
Nun folgt die Endlosschleife in der die Verarbeitung stattndet. Hier wird zuerst
eine Message erzeugt (request genannt), dieser wird die Methode socket.recv()
ubergeben und, wenn eine Anfrage vorhanden ist, mit Daten gef ullt. Wenn dies
der Fall ist, werden die gesendeten Daten mit printf() ausgegeben und eine Mil-
lisekunde mit sleep(1) gewartet. Danach wird eine Antwortmessage erzeugt und
World hinein geschrieben und per socket.send() zur uck geschickt. Das return 0
wird nie erreicht.
#include <zmq.hpp>
#include <string.h>
#include <stdio.h>
int main ()
{
// Prepare our context and socket
zmq::context_t context (1);
zmq::socket_t socket (context, ZMQ_REQ);
printf ("Connecting to hello world server...\n");
162 13 ZeroMQ
socket.connect ("tcp://localhost:6666");
// Do 10 requests, waiting each time for a response
for (int request_nbr = 0; request_nbr != 10; request_nbr++) {
zmq::message_t request (6);
memcpy ((void *) request.data (), "Hello", 6);
printf ("Sending request %d...\n", request_nbr);
socket.send (request);
// Get the reply.
zmq::message_t reply;
socket.recv (&reply);
printf ("Received reply %d: [%s]\n", request_nbr,
(char *) reply.data ());
}
return 0;
}
Listing 13.3: Beispiel eines Hello World Client in ZeroMQ.
Im Client-Code zu diesem Beispiel (Listing 13.3) sehen die ersten Zeilen wieder
ahnlich aus. Es wird ein Kontext erstellt und ein Socket generiert (diesmal mit
REQ f ur Request). Das Socket wird auf die localhost-Adresse mit dem Port 6666
und TCP gebunden. Danach werden in einer for-Schleife 10 Request an den Server
abgesendet und der Reply ausgegeben.
13.8 Fazit
In diesem Artikel wurde eine praktische Einf uhrung in die Programmierung mit
MQ gegeben. Nachdem Grundlagen uber die Historie, Architektur und Verwen-
dung von MQ erlautert wurden, verdeutlichte ein praktisches Beispiels die Ver-
wendung. Mein Fazit aus der Arbeit an MQ ist positiv. Nach einigen Startschwie-
rigkeiten, die die Kompilierung und den Integrationsanforderungen von MQ ge-
schuldet sind, kann man sehr schnell auch komplexere Anwendung erstellen und
praktisch umsetzen. Es ist durch die vielen vorhandenen Beispiele und den guten
Einf uhrungen einfach zu erlernen und man sieht schnell Erfolge. Ich kann jedem,
der sich f ur asynchrone Kommunikation und verteilte Anwendungen interessiert
empfehlen, sich mit MQ zu beschaftigen und auch gerne mal in den Quellco-
de zu schauen, da dieser sehr gut kommentiert ist. F ur mich war die Erfahrung,
die ich mit diesem Framework gemacht habe, sehr lehrreich und es hat mich
weitergebracht.
[1] ZeroMQ Website, http://www.zeromq.org/. 31.01.2011.
[2] ZeroMQ Guide, http://zguide.zeromq.org/chapter:all. 31.01.2011.
[3] Advanced Message Queuing Protocol, http://www.amqp.org/conuence/dis-
play/AMQP/Advanced+Message+Queuing+Protocol. 31.01.2011.
[4] TCP, http://www.faqs.org/rfcs/rfc793.html. 31.01.2011.
[5] OSI Modell, http://de.wikipedia.org/wiki/OSI-Modell. 31.01.2011.
[6] Asynchronous-I/O, http://en.wikipedia.org/wiki/Asynchronous I/O. 31.01.
2011.
[7] Pearl Module for ZeroMQ, http://search.cpan.org/dmaki/ZeroMQ-0.02
01/lib/ZeroMQ.pm. 31.01.2011.
[8] ZeroMQ Beispiele, https://github.com/imatix/zguide/tree/master/examples
31.01.2011.
[9] ZeroMQ Source, git://github.com/zeromq/zeromq2.git. 31.01.2011.
[10] RFC Pragmatic General Multicast, http://tools.ietf.org/html/rfc3208. 31.
01.2011.
[11] Pipes and Filters, http://msdn.microsoft.com/en-us/library/647419.aspx.
31.01.2011.
[12] ZeroMQ the Game, http://www.zeromq.org/blog:0mq-the-game. 31.01.
2011.
164 13 ZeroMQ
14 Remote Function Call in
SAP-Systemen
Sebastian Reidemeister
Inhaltsverzeichnis
14.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 166
14.2 RFC - Allgemein . . . . . . . . . . . . . . . . . . . . . . 166
14.3 RFC - Kommunikation . . . . . . . . . . . . . . . . . . . 168
14.4 RFC-Arten . . . . . . . . . . . . . . . . . . . . . . . . . 170
14.4.1 Synchroner RFC (sRFC) . . . . . . . . . . . . . . 170
14.4.2 Asynchroner RFC (aRFC) . . . . . . . . . . . . . 170
14.4.3 Transaktionaler RFC (tRFC) . . . . . . . . . . . 171
14.4.4 Queued RFC (qRFC) . . . . . . . . . . . . . . . 171
14.4.5 Background RFC (bgRFC) . . . . . . . . . . . . . 172
14.5 Programmierung . . . . . . . . . . . . . . . . . . . . . . 173
14.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Dieses Kapitel beschaftigt sich mit dem Aspekt der Kommunikation zwischen
verschiedenen Systemen im SAP-Umfeld. Dabei soll ein kurzer Einblick in die
Standardkommunikation mittels der Remote Function Calls, kurz RFC, gegeben
werden.
F ur die Programmierung von RFCs sind ein paar grundlegende Informationen
wichtig. Diese werden im Abschnitt 14.1 dieses Textes kurz erlautert. Danach wird
geklart, was man unter der RFC-Technik versteht. Ebenso wird kurz auf mogliche
Kommunikationsszenarien, die mit dem RFC ermoglicht werden konnen, einge-
gangen. Nachdem der Kontext des RFC naher erlautert wurde, werden im darauf
folgenden Teil alle momentan existierenden Arten des RFC erlautert. Am Ende
wird ein kurzer Ablaufplan f ur die Programmierung und eine Zusammenfassung
gegeben.
166 14 Remote Function Call in SAP-Systemen
14.1 Grundlagen
Um einen RFC in SAP programmieren zu konnen, kann man sich der Program-
miersprache ABAP bedienen. Sie ist eine Eigenentwicklung von SAP. ABAP be-
deutete bei ihrer Entstehung
Allgemeiner Berichts-Anwendungs-Prozessor. Sie

diente hauptsachlich dazu, um Auswertungen von Daten aus dem SAP-System
heraus zu gestalten. Heute hat sich die Bezeichnung in
Advanced Business App-

lication Programming geandert und ermoglicht es, eigenstandige Applikationen
innerhalb des SAP-Systems zu schreiben. Dabei werden nicht nur Daten ausge-
wertet sondern auch auf der Datenbank manipuliert. ABAP bildet seit 1990 die
Grundlage der SAP R/3-Module. Die Erstellung von ABAP-Programmen erfolgt
meist in der hauseigenen Programmierumgebung. Die ABAP-Workbench ist bei-
spielsweise in die SAP NetWeaver-Plattformen integriert.
Ein wichtiges Programmierkonzept in ABAP ist die Nutzung von Funktionsbau-
steinen. Unter einem Funktionsbaustein kann man sich eine Sammlung von einigen
inhaltlich zusammengehorigen Funktionen vorstellen. Sie liefern dem Program-
mierer schon vorgefertigte Funktionen f ur die Erledigung bestimmter Aufgaben-
stellungen. Funktionsbausteine besitzen eine klar denierte Schnittstelle. Diese
Schnittstelle besteht aus Import- und Export-Parametern, die f ur die Bearbeitung
und Reprasentation von Ergebnissen notwendig sind. Weiterhin gibt es Changing-
und Tabellen-Parameter, die interne Tabellenstrukturen f ur die Bearbeitung re-
prasentieren. Das letzte Element der Schnittstelle sind die Ausnahmen. In diesem
Bereich werden alle Ausnahmen deniert, die bei der Bearbeitung des Funkti-
onsbausteins auftreten konnen. Ein Funktionsbaustein ist nicht nur an das lokale
System gebunden. Es besteht die Moglichkeit, Funktionsbausteine auf einem ent-
fernten System (bspw. an einem anderen Firmenstandort) zu nutzen. Dabei sind
diese Funktionsbausteine als remote-fahig im System gekennzeichnet. Dieser Um-
stand wird bei der Technologie der Remote Function Calls ausgenutzt.
14.2 RFC - Allgemein
Der Remote Function Call ist die Standard-Schnittstelle des SAP-Systems, die
die Kommunikation zwischen Anwendungen verschiedener (entfernter) Systeme
organisiert. Diese Anwendungen konnen auf SAP-Systemen, wie SAP-NetWeaver-
Systeme, und auf anderen Systemen, die z.B. in Java programmiert wurden, be-
trieben werden. Der RFC ruft eine Funktion auf, die in einem entfernten bzw.
anderen System ausgef uhrt werden soll. Dabei wird vom Client ein Funktionsbau-
stein aufgerufen, der beim Server als remote-fahig deniert ist. Daher wird z.B.
bei einem ABAP-Programm auf dem Client der Funktionsbaustein-Aufruf
CALL
FUNCTION um einige Parameter erweitert, um bspw.
DESTINATION.
14.2 RFC - Allgemein 167
Bei der Organisation der Kommunikation bietet der RFC einige wesentliche Funk-
tionen die nicht mehr nur alleine durch den Programmierer realisiert werden, son-
dern die das System teilweise selbst erledigt. Unter anderem organsiert der RFC
den Aufruf und die Steuerung der Kommunikationsroutinen, die f ur die Kommuni-
kation mit entfernten Systemen benotigt werden. Dazu gehort beispielsweise auch
die Anmeldung bzw. die Abmeldung am entfernten System. Wird eine Kommu-
nikation aufgebaut, so pr uft der RFC, ob der gew unschte Funktionsbaustein bzw.
die ubergeordnete Funktionsgruppe f ur den aufrufenden Nutzer freigegeben ist
und somit auch benutzt werden darf. Eine weitere Funktion des RFC ist die Kon-
vertierung von Aktualparametern. Es werden alle Daten, die f ur die Bearbeitung
des Aufrufs wichtig sind, in die jeweilig benotigten Datentypen konvertiert. Dies
konnen eventuell plattformabhangige Konvertierungen, beispielsweise bei unter-
schiedlichen Codepages oder Byte-Reihenfolgen, sein. Selbstverstandlich enthalt
der RFC eine Fehlerbehandlung, die auftretende Fehler bei der Kommunikation
abfangt und an den Aufrufer weiterreicht.
Kommunizieren nun zwei unterschiedliche SAP-System miteinander, so treten
meist zwei ABAP-Programme miteinander in Kontakt. Bei der Kommunikation
eines SAP-Systems mit einem Fremdsystem tritt meist ein ABAP-Programm mit
einem Programm in einer anderen Programmiersprache in Kontakt. Dabei hat
ABAP die Moglichkeit eine Verbindung mit den gangigsten Programmiersprachen,
wie z. B. C, C++, Visual Basic, Java oder .NET, aufzubauen. Deshalb kann die
RFC-Schnittstelle aus zwei Sichten betrachtet werden.
Zum einen gibt es die Schnittstelle aus ABAP-Sicht. Danach kann jedes beliebige
ABAP-Programm einen remote-fahigen Funktionsbaustein aufrufen. Dabei muss
dieser aufgerufene Funktionsbaustein als remote-fahig im aufgerufenen System
registriert sein. Durch eine Erweiterung des ublichen Funktionsbaustein-Aufrufs
in ABAP (
CALL FUNCTION) mit dem Parameter
DESTINATION, wird dem

System mitgeteilt, dass sich der benotigte Funktionsbaustein auf einem anderen
Systeme bendet und die Kommunikation nun uber die RFC-Schnittstelle realisiert
werden soll. Je nach Art des RFC konnen noch weitere Parameter bzw. ABAP-
Befehle hinzukommen (z.B.:
STARTING NEW TASK beim asynchronen RFC).

Dazu aber mehr im Kapitel RFC-Arten und Funktionsweisen.
Die andere Sicht auf die RFC-Schnittstelle betrit die Kommunikation mit Pro-
grammen in anderen Programmiersprachen. Ist nun das aufrufende oder das ge-
rufene Programm ein nicht SAP-Programm, so muss es so programmiert werden,
dass es vollstandig an der RFC-Kommunikation teilnehmen kann. Dazu bietet
SAP eine Losung uber sogenannte Connectoren an. Diese Connectoren stellen
die benotigten RFC-Bibliotheken f ur alle von SAP unterst utzten Betriebssyste-
me, wie Microsoft Windows, Unix, Linux usw., zur Verf ugung. Die bekanntesten
Connectoren sind zum Beispiel der SAP Java Connector, der SAP Java Ressource
Adapter, der SAP .NET Connector und der SAP Business Connector. Sie verf ugen
uber die Funktionalitaten um einen Daten- bzw. Informationsaustausch uber die
RFC-Schnittstelle zu ermoglichen.
14.3 RFC - Kommunikation
Wie schon im vorigen Text erwahnt, stellt die Programmierung einer Kommuni-
kation zwischen entfernten Systemen einen Spezialfall des Aufrufs von Funktions-
bausteinen dar. Wahrend in einem lokalen System der Funktionsbaustein uber den
Befehl
CALL FUNCTION aufgerufen wird, muss f ur eine Kommunikation zwi-

schen entfernten bzw. SAP-fremden Systemen diese Befehlsfolge um bestimmte
Parameter erweitert werden. Durch diesen modizierten Aufruf ist es dem rufen-
den SAP-System jetzt moglich, eine Verbindung zu externen nicht-SAP-Systemen,
alteren R/2-Systemen, Applikationsservern eines anderen R/3-Systems oder sogar
zu einem Applikationsserver des eigenen R/3-Systems aufzubauen. Diese Remote-
Systeme m ussen deshalb die RFC-Schnittstelle unterst utzen und die benotigten
remote-fahigen Funktionsbausteine zur Verf ugung stellen. Die folgende Abbildung
stellt die Kommunikation in SAP zusammenfassend dar. Folgende Abbildung fasst
das eben Besprochene noch einmal zusammen.
Abbildung 14.1: Kommunikation
Man kann bei der Kommunikation uber die RFC-Schnittstelle verschiedene Sze-
narien unterscheiden. Das erste Szenario stellt die Kommunikation zwischen
14.3 RFC - Kommunikation 169
zwei Applikationsservern ABAP dar. Beide Applikationsserver besitzen die RFC-
Schnittstelle. Jedes beliebige ABAP-Programm kann nun auf die remote-fahigen
Funktionsbausteine der Applikationsserver zugreifen. Der typische Aufruf des
Funktionsbausteins ist
CALL FUNCTION DESTINATION.

Das zweite Szenario ist die Kommunikation zwischen einem Applikationsserver
ABAP und einem Fremdsystem. Das Fremdsystem muss um die RFC-Schnittstelle
erweitert werden. Dies geschieht mit Hilfe der RFC-API, die von SAP zur
Verf ugung gestellt wird. Mit Hilfe des RFC SDK von SAP kann dies in das Fremd-
system implementiert werden. Diese API stellt alle funktionalen Informationen f ur
die RFC-Schnittstelle zur Verf ugung, wie z. B. verschiedene RFC Client-/ Server-
Programme und plattformspezische RFC-Bibliotheken.
Die Kommunikation zwischen dem Applikationsserver ABAP und dem Applika-
tionsserver Java stellt das dritte Kommunikationsszenario dar. Meist sind beide
Applikationsserver Bestandteil der NetWeaver-Produkte von SAP. Sie treten nach
auen jedoch nur als ein Applikationsserver des jeweiligen Systems auf. Daher
benotigen sie intensive Kommunikationsmoglichkeiten. So muss es moglich sein,
dass ABAP-Funktionen aus einem Java-Programm bzw. umgekehrt aufgerufen
werden konnen, ohne dass ein Performanceverlust entsteht. Damit nun der AS
Java mit dem AS ABAP kommunizieren kann, muss der AS Java um eine Kom-
ponente erweitert werden, die die Datenstrukturen des ABAP-Programms f ur das
Java-Programm verstandlich macht. Dies geschieht durch den Einsatz des SAP
Java Connector (JCo). Der JCo setzt dabei auf die RFC-Bibliotheken auf und
transformiert den ABAP-Datenstrom auf Java und umgekehrt. Er dient dem AS
Java sozusagen als Schnittstelle. Die Kommunikation zwischen den beiden AS
erfolgt immer uber RFC, da es intern als remote-Verbindung angesehen wird.Die
zweite Einsatzmoglichkeit des SAP JCo betrit die Kommunikation zwischen ei-
nem AS ABAP und einem Java-System, welches nicht von SAP stammt. Der JCo
wird nun als eigenstandige Komponente genutzt. Die RFC-Schnittstelle des AS
ABAP kommuniziert mit dem JCo. Dieser transformiert den ABAP-Datenstrom in
Java. Der transformierte Datenstrom kann dann von dem Java-System (bzw. Pro-
gramm) zur Verarbeitung genutzt werden. Dem entsprechend funktioniert auch
die Kommunikation von dem Java-System zum AS ABAP.
Eine Besonderheit zwischen der Kommunikation des AS ABAP und des AS Ja-
va ist die Nutzung des AS Java als reinem Client. An dieser Stelle wird anstatt
des erwarteten JCo der SAP Java Ressource Adapter (JRA) genutzt. Der JRA
benotigt jedoch Funktionen des JCo. Daher kommen diese beiden Komponen-
ten verzahnt zur Anwendung. Der JRA stellt einen standardisierten Zugang zu
allen extern verf ugbaren Funktionen des AS ABAP dar. Er basiert auf der J2EE-
Connector-Architektur, welche genau standardisiert ist. F ur den Programmierer
bedeutet das, dass er das J2EE-Standardinterface in sein Programm implemen-
tieren muss. Alle weiteren benotigten Einstellungen konnen im AS Java mit Hilfe
einer Benutzeroberache konguriert werden. Dies betrit hauptsachlich Sicher-
heitskongurationen, Transaktionsverwaltung, Verbindungsaufbau und die Syn-
chronisierung.
14.4 RFC-Arten
Es konnen f unf Arten von RFCs unterschieden werden. Die erste RFC-Art ist der
synchrone RFC (sRFC). Er stellt die Grundform der RFC dar. Die zweite RFC-Art
ist der asynchrone RFC (aRFC). Er ist eine Erweiterung des sRFC und ermoglicht
eine fast asynchrone Kommunikation. Die nachste RFC-Form ist der transaktiona-
le RFC (tRFC), welcher vollstandig asynchron kommuniziert. Die vierte betrachte-
te Art ist der queued RFC (qRFC). Zu seinen Starken zahlt die Garantie, dass die
gerufenen Funktionsbausteine in genau der Reihenfolge ausgef uhrt werden, wie
die Aufrufe erstellt wurden. Als letzte Art wird der background RFC (bgRFC) be-
trachtet. Er ermoglicht es, bestimmte Daten aufzuzeichnen, die spater ubertragen
werden sollen.
14.4.1 Synchroner RFC (sRFC)
Er ermoglicht die Ausf uhrung externer Funktionen aus einem AS ABAP heraus.
Die Grundlage daf ur bildet die synchrone Kommunikation. Das bedeutet, dass
alle beteiligten Systeme, also rufendes und gerufenes System, zur Zeit des Aufrufs
verf ugbar sein m ussen. Ist das Zielsystem nicht erreichbar, f uhrt das unweigerlich
zu einem Fehler und dem Abbruch des Programms. Das ABAP Programm fangt
dabei zwei Exceptions ab. Zum einen ist das die
SYSTEM FAILURE-Exception
und zum anderen die
COMMUNICATION FAILURE-Exception. Dieser RFC

wird also hochstens einmal ausgef uhrt und nicht wiederholt.
Der Ablauf bei der Kommunikation erfolgt programm-technisch folgendermaen:
Das ABAP-Programm ruft einen entfernten Funktionsbaustein auf einem ent-
fernten System (CALL FUNCTION DESTINATION). Dieser Aufruf ubertragt die
Daten an das entfernte System. Dort wird der gerufene Funktionsbaustein aus-
gef uhrt. Wahrenddessen wartet das aufrufende Programm bis das Ergebnis des
entfernten Systems eintrit. Nach Eintreen der Daten des gerufenen Systems
wird das rufende Programm weiter ausgef uhrt.
14.4.2 Asynchroner RFC (aRFC)
Man kann die Kommunikation uber diesen RFC als pseudo-asynchron bezeichnen.
Das bedeutet, dass das gerufen System immer verf ugbar sein muss. Jedoch ist
14.4 RFC-Arten 171
der Unterschied zum sRFC, dass der aRFC nicht auf die erfolgreiche Bearbeitung
der Funktionen im gerufenen System wartet. Der aRFC wird hochstens einmal
ausgef uhrt, gilt aber nach dem ersten Fehlversuch als gescheitert. So ein Fehl-
versuch konnte z. B. ein nicht verf ugbares aufgerufenes System sein. Verwendet
wird dieser RFC hauptsachlich, wenn man eine Echtzeit-Kommunikation mit ei-
nem entfernten System erreichen will, ohne aber auf die Ergebnisse warten zu
m ussen.
14.4.3 Transaktionaler RFC (tRFC)
Der tRFC entspricht der echten asynchronen Kommunikation. Das bedeutet, dass
das gerufene System nicht verf ugbar sein muss. Dadurch muss gewahrleistet sein,
dass die Aufrufe f ur das entfernte System gespeichert werden. Der tRFC speichert
daher alle RFC-Funktionen zusammen mit den dazugehorigen Daten in einer Da-
tenbank. Dies geschieht auch bei Kommunikationsproblemen. Auf jeden Fall wird
auf der Datenbank eine Statusfortschreibung ausgef uhrt. Das bedeutet, dass der
Sender uber den Verarbeitungsfortschritt beim Empfanger informiert ist. Es wird
auch sichergestellt, dass keine Doppel ubertragung und daraus resultierend eine
Doppelausf uhrung beim Empfanger stattndet.
Ein ABAP-Programm ruft verschiedene Funktionsbausteine auf. Der Aufruf der
Funktionsbausteine wird jedoch um einige Befehle erweitert. Mit den Befehlen
IN
BACKGROUND TASK wird jeder Aufruf eines Funktionsbausteins zur Bearbei-
tung vorgemerkt. Im aufrufenden Programm wird durch den Befehl
COMMIT
WORK die Ausf uhrung gestartet. Im Empfangssystem werden die Aufrufe, je
nachdem wie sie ankommen, abgearbeitet. Es ist nicht garantiert, dass diese Auf-
rufe in der gew unschten Reihenfolge bearbeitet werden. Wird ein Aufruf gesendet
und der Empfanger ist nicht verf ugbar, so wird der Aufruf in eine Warteschlan-
ge eingetragen. Das rufende Programm kann dadurch weiterlaufen ohne auf das
erfolgreiche oder nicht erfolgreiche Ablaufen der Funktionen zu warten. Wird
der RFC-Server nicht innerhalb eines bestimmten Zeitraums aktiviert, werden die
Aufrufe in einer Jobliste als Hintergrundauftrag eingetragen.
14.4.4 Queued RFC (qRFC)
Eine Erweiterung des tRFC stellt der qRFC dar. Beim qRFC ndet eine Seriali-
sierung des tRFC uber Queues statt. Diese Queues werden meist in Ausgangs-
und Eingangsqueue unterteilt. Damit wird ermoglicht, dass die ubertragenen Auf-
rufe im Zielsystem in der Reihenfolge bearbeitet werden, wie sie eintreen. Es
besteht weiterhin die Moglichkeit, eine Ausf uhrungseinheit (also mehrere Funk-
tionsbausteine innerhalb eines Prozesses) auf verschiedene Queues zu verteilen.
Diese Moglichkeit wird auch als Abhangigkeit bezeichnet.
Der qRFC kann verschiedene Einsatzszenarien haben. Unter dem Outbound-
Szenario versteht man die Aufzeichnung der Aufrufe in der Ausgangsqueue auf
der Datenbank des Senders. Dies f uhrt zu einer Entkopplung zwischen Sender
und Empfanger. Das Inbound-Szenario beschreibt die Aufzeichnung der Aufrufe
als Eingangsqueue auf der Datenbank des Empfangers. Der Empfanger ist aber
meist kein entferntes System sondern ein anderer Applikationsserver des senden-
den AS ABAP. Dieses Szenario wird benutzt um beispielsweise Anwendungen
zu parallelisieren. Das nachste Szenario ist das Out-In-Szenario. Dies stellt ei-
ne Kombination von Outbound- und Inboundszenario dar. Anscheinend werden
die Vorteile beider Szenarien ausgenutzt. Jedoch sollte dieses Einsatzszenario nur
verwendet werden, wenn es begr undete Umstande f ur die doppelte Bereitstellung
der Daten gibt. Das letzte Szenario ist das No-Send-Szenario. Dies stellt einen
degenerierten Spezialfall dar. Daten werden nur auf Anforderung an ein anderes
System ubergeben. So z. B. bei der Anbindung von mobilen Endgeraten. Das
Endgerat fordert Daten beispielsweise aus der CRM-Middleware an und bekommt
sie ubergeben.
14.4.5 Background RFC (bgRFC)
Der Einsatz des background RFC ermoglicht es, Daten aufzuzeichnen, die spater
von der aufgerufenen Anwendung empfangen werden konnen. Dabei stellt der
bgRFC sicher, dass die Daten entweder genau einmal in beliebiger Reihenfol-
ge (transaktional) oder genau einmal in der Reihenfolge der Erzeugung an den
Empfanger ubergeben werden. Die verschiedenen Aufrufe konnen uber Queues
organisiert werden. Dabei kann ein Aufruf auf verschiedene Queues aufgeteilt
werden. Dadurch entsteht eine Abhangigkeit zwischen den Queues. Man kann
diesen Umstand auch als Synchronisationspunkt der Queues betrachten. Alle
Queues konnen weiter abgearbeitet werden bis ein Eintrag einer Queue mit einer
Abhangigkeit an erster Stelle der Queue steht. Erst wenn in allen betreenden
Queues die Eintrage der Abhangigkeit an erster Stelle stehen, kann der komplette
Aufruf bearbeitet werden. Diese Funktion des bgRFC ist sehr machtig und muss
genau uberlegt verwendet werden, da es sonst zu einem kompletten Stillstand der
Queue-Verwaltung kommen kann. Eine Anwendungsmoglichkeit ist beispielsweise
die Belegverwaltung in der Logistik. Eine kombinierte Verwendung von bgRFC,
qRFC und tRFC sind innerhalb eines Ziels nicht gestattet. Beim bgRFC gibt
es einige Optimierungsmoglichkeiten zwischen dem Aufrufer und dem Gerufenen.
Ausschlaggebend daf ur ist die Asynchronitat. Innerhalb eines SAP-Systems f uhren
diese Optimierungen zu einer Parallelisierung und zu einer Lastverteilung uber die
verf ugbaren Applikationsserver des Systems. Dies wird auch als Inbound-Verfahren
bezeichnet. Zwischen entfernten SAP-Systemen konnen durch die Asynchronitat
die Unterschiede in den Leistungsmerkmalen der verschiedenen AS ausgeglichen
14.5 Programmierung 173
werden. Weiterhin f uhren diese Optimierungen zu einer Entkopplung, also einer
physischen Aufteilung, einer Anwendung bzw. eines Business-Szenarios. Man be-
zeichnet diese Optimierungen auch als Outbound-Verfahren. Beide Verfahren,
Inbound- und Outbound-Verfahren, konnen auch kombiniert werden. Dadurch
lassen sich alle Optimierungsmoglichkeiten ausnutzen. Jedoch erfolgt die Auf-
zeichnung der Daten doppelt.
Im Allgemeinen kann man sagen, dass der bgRFC eine bessere Skalierbarkeit bei
der Bearbeitung von RFC-Daten ermoglicht. Eine weitere Verbesserung der Per-
formance bei der Erstellung eines bgRFC-Programms bietet eine API, die von SAP
f ur die Entwickler zur Verf ugung gestellt wurde. Sie f uhrt zu einer Reduzierung
des Support- und Entwicklungsaufwandes. Diese API unterst utzt die Denition
der Eigenschaften der

Ubertragung, Datenaufzeichnung und die B undelung meh-
rerer Funktionsbausteine als eine Unit. Als Unit bezeichnet man die Einheit einer
Ubertragung. Die Unit kann zwei Zustande besitzen, vollstandig ubertragen oder
steht zur

Ubertragung an. Das transaktionale Verhalten der Queue-Funktion er-
zielt keine Einsparung bei der Verarbeitung einzelner Units. Dieser Umstand kann
durch leistungsfahigere Hardware ausgeglichen werden.
14.5 Programmierung
Die Programmierung von RFCs erfolgt meist in drei Schritten. Im Schritt 1 muss
im System, auf welchem programmiert werden soll und dem Empfangssystem, ei-
ne Destination festgelegt werden. Dabei werden Einstellungen getroen, wie z. B.
Zieladresse des Empfangssystems oder Anmeldeinformationen am System. Diese
Einstellungen sind notwendig, um uberhaupt eine Verbindung mit einem exter-
nen System aufbauen zu konnen. Schritt 2 ist die Suche bzw. das Erstellen eines
remote-fahigen Funktionsbausteins. SAP bietet schon eine Vielzahl vorgefertigter
Bausteine, jedoch konnen Spezialfalle auftreten, in denen man gezwungen ist, ei-
gene Losungen zu erstellen. Schritt 3 ist dann die Erstellung des RFC-Programms.
Im Anschluss daran erfolgen meist noch weitere Tatigkeiten, wie beispielsweise
das Testen des Programms in einem Testsystem sowie das Einpegen des Pro-
gramms in das Produktivsystem, die jedoch an dieser Stelle nicht angesprochen
werden sollen.
14.6 Fazit
Zum Schluss ist festzustellen, dass die RFC-Technik ein sehr machtiges Werkzeug
f ur die Gestaltung von systeminterner bzw. system ubergreifender Kommunikation
darstellt. Mit Hilfe von RFCs gibt es f ur fast jedes Kommunikationsproblem eine
Losung. Deshalb ist es nicht verwunderlich, dass alle Weiterentwicklungen im
Bereich Kommunikation im SAP-Umfeld, auf dem RFC-Konzept basieren.
[1] Keller, H.; Kr uger, S., ABAP Objects: ABAP-Programmierung mit SAP Net-
Weaver. 3. Auage, 2006, Galileo Press, Bonn.
[2] RFC Programmierung in ABAP, Stand: 07.12.2010, http://help.sap.com/
printdocu/core /Print 46c/de/data/pdf/BCFESDE2/BCFESDE2.pdf
[3] Programming RFC Clients in ABAP, Stand: 07.12.2010,
http://help.sap.com/saphelp 47x200/helpdata/en/26/64f61dfa8911d386e70
000e82011b8/content.htm
Teil IV
Web Services
15 Web-Services-
Architektur
Sebastian Leisen
Inhaltsverzeichnis
15.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 177
15.2 Denition . . . . . . . . . . . . . . . . . . . . . . . . . . 178
15.3 Serviceorientierte Architekturen . . . . . . . . . . . . . . 178
15.3.1 Rollen in einer SOA . . . . . . . . . . . . . . . . 180
15.3.2 Aktionen in einer SOA . . . . . . . . . . . . . . . 181
15.4 Web-Service-Architektur . . . . . . . . . . . . . . . . . . 182
15.4.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . 182
15.4.2 WSDL . . . . . . . . . . . . . . . . . . . . . . . 183
15.4.3 UDDI . . . . . . . . . . . . . . . . . . . . . . . . 184
15.4.4 Rollen und Aktionen . . . . . . . . . . . . . . . . 184
15.4.5 Beispiel - SOAP und WSDL . . . . . . . . . . . . 185
15.4.6 Vor- und Nachteile . . . . . . . . . . . . . . . . . 188
15.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
15.1 Einleitung
Die Entwicklung der Web-Service-Architekturen kann auf eine lange Geschichte
zur uck blicken. Als Grundlage aller Computerprogramme und Programmierspra-
chen wird haug die Assemblerprogrammierung genannt. Mit ihren maschinenna-
hen Befehlen war es moglich bereits einige Probleme mit Hilfe eines Computers zu
losen. An verteilte Problembewaltigung war hierbei allerdings noch nicht zu den-
ken. Mit der Entwicklung von Netzwerktechniken wurde die Grundlage f ur Web-
Services geschaen. Die Einf uhrung von Remote Procedure Calls ermoglichte
erste entfernte und damit verteilte Funktionsaufrufe. Immer komplexer werdende
Programme erforderten eine neue Art der Programmierung. Auf die Assembler
Programmierung folgte die prozedurale Programmierung. Als auch diese nicht
mehr ausreichte wurde die Idee der objektorientierten Programmiersprache um-
gesetzt. Immer komplexer werdende Szenarien der Programmierung erforderten
178 15 Web-Services-Architektur
eine neue Abstraktionsebene. So auch im Falle von Web-Service-Architekturen.
Das folgende Kapitel soll einen Einblick in Serviceorientierte Architekturen und
im speziellen uber Web-Service-Architekturen bieten.
15.2 Denition
Web service is a software system designed to support interoperable machine-to-
machine interaction over a network. It has an interface described in a machine-
processable format (specically WSDL). Other systems interact with the Web-
Service in a manner prescribed by its description using SOAP messages, typically
conveyed using HTTP with an XML serialization in conjunction with other Web-
related standards [1].
Als Web-Service wird ein Softwaresystem verstanden welches die Interaktion von
Machine zu Machine ermoglicht. Das Anwendungsprogramm kann dabei auf ver-
schiedenen Plattformen laufen. Dies gewahrleistet die Interoperatbilitat des Web-
Services. Ein Web-Service kann somit auch als eine Softwareanwendung verstan-
den werden. Der Web-Service ist uber einen eindeutigen Uniform Ressource Iden-
tier (URI) identizierbar. Die Schnittstelle des Dienstes ist uber XML deniert.
Uber diese kann der Dienst deniert, beschrieben sowie gefunden werden. In ei-
ner Maschine-zu-Maschine-Kommunikation kann ein Web-Service auch mit so
genannten Software-Agenten kommunizieren. Dabei erfolgt ein Austausch von
XML Dokumenten uber zumeist internetbasierte Protokolle [1].
15.3 Serviceorientierte Architekturen
Web-Services orientieren sich an der Serviceorientierten Architektur - SOA.
Serviceorientierte Architekturen stellen das abstrakte Konzept einer Software-
Architektur dar. Im Zentrum von SOA steht das Anbieten, Suchen und Nutzen
von Diensten uber ein Netztwerk. Diese Dienste wiederum werden dabei von an-
deren Anwendungen und Diensten genutzt. SOA bieten den groen Vorteil der
Interoperabilitat, es spielt dabei keine Rolle welche Hard- noch Software, Pro-
grammiersprache oder welches Betriebssystem zu Grunde liegt. Die Anwendungs-
details sind daher nahezu unabhangig von der jeweiligen Implementierung. Die
funktionale Zerlegung der Anwendung ermoglicht eine prozessorientierte Betrach-
tungsweise. Somit ist es moglich explizite Teilprozesse uber das Netzwerk (z.B.
Internet) anzusprechen. Zusammenfassend lasst sich sagen, dass es sich bei einer
SOA nicht um eine konkrete Technik handelt, sondern um eine Abstraktion der
Wirklichkeit. Mittels dieser Abstraktion ist es moglich wesentliche Aspekte hervor
zu heben und unwichtige Aspekte auszublenden. Die aussichtsreichste Abstraktion
15.3 Serviceorientierte Architekturen 179
der Wirklichkeit kann als Web-Services gesehen werden [2].
Serviceorientierte Architekturen vereinen die folgenden Eigenschaften:
Lose Kopplung
Dynamisches Binden
Verzeichnisdienst
Verwenden von Standards
Sicherheit
Einfachheit.
Die lose Kopplung stellt ein wichtiges Merkmal einer Serviceorientierten Architek-
tur dar. Mit Hilfe der losen Kopplung ist es moglich, dass Dienste von Anwendern
beziehungsweise anderen Diensten bei Bedarf dynamisch gesucht, gefunden und
eingebunden werden konnen. Die Bindung des Services erfolgt zur Laufzeit, dass
heit zur

Ubersetzung des Programmes ist es nicht bekannt wer auf den Dienst zu-
greift. Das dynamische Einbinden beschreibt die Moglichkeit Funktionalitaten bei
Bedarf einzubinden. Als Voraussetzung muss jedoch erf ullt sein, dass ein moglicher
Aufrufer in der Lage ist einen entsprechenden Dienst uberhaupt zu nden. Dies
ist vergleichbar mit der Suche nach einem Restaurant in einer unbekannten Stadt.
Eine mogliche Losung zu diesem Problem ware die Verwendung von einem Bran-
chenbuch, wie die Gelben Seiten. Dabei m ussen allerdings drei Voraussetzungen
erf ullt sein [2].
Zugri auf ein Branchenbuch wie die Gelben Seiten
Kategorie muss dem Suchenden bekannt sein unter welcher ein mogliches
Restaurant zu nden ist
Restaurant muss in den Gelben Seiten registriert sein
Der Verzeichnisdienst ist mit den Gelben Seiten vergleichbar. Er stellt eine Art
Repository bereit in dem die zur Verf ugung stehenden Dienste registriert sind. Er
gestattet die Suche nach Methoden und Diensten welche gerade benotigt werden.
Allen Eigenschaften gleich ist die Notwendigkeit der Verwendung von Standards.
Nur dadurch ist es dem Nutzer moglich den Dienst eines unbekannten Anbieters
zu nutzen. Sollten keine Standards vorliegen, kann es passieren das die Kommu-
nikation mit dem Dienst scheitert. Dies ermoglicht eine breite Akzeptanz beim
Nutzer und sichert somit den Erfolg eines Web-Service. Ein Folge der Verwendung
von Standards ist die daraus resultierende Einfachheit, welche ein Web-Service mit
sich bringen sollte. Die Beschreibung, der Aufruf und die Kommunikation sollte
Abbildung 15.1: Der SOA Tempel[2]
so einfach wie moglich gestaltet sein. Als letzte Eigenschaft vereint die SOA das
Thema Sicherheit [2].
Die folgende Abbildung veranschaulicht den allgemeinen und vereinfachten Auf-
bau einer Service-orientierten Architektur.
15.3.1 Rollen in einer SOA
Bei einer Serviceorientierten Architektur steht, wie bereits erwahnt, der Dienst
im Vordergrund. Dieser stellt dabei ein Programm bzw. eine Softwarekomponen-
te dar. Die Schnittstelle des Dienstes muss oentlich beschrieben sein. Die so
genannte Service Description muss in maschinenlesbarer Form vorliegen. Der Zu-
gri auf den Dienst ist dabei nur uber die beschriebene Schnittstelle moglich.
Damit wird das Prinzip des Information Hiding umgesetzt. Die Implementierung
des Dienstes an sich ist nicht sichtbar und wird uber die Dienstbeschreibung ge-
kapselt. Beteiligte einer SOA konnen drei verschiedene Rollen einnehmen:
Dienstanbieter
Dienstnutzer
Dienstverzeichnis / Dienstvermittler.
Der Dienstanbieter stellt eine Plattform zur Verf ugung, welche uber ein Netzwerk
(z.B. Internet) erreichbar ist [2].
15.3 Serviceorientierte Architekturen 181
Der angebotene Dienst muss vor der Nutzung jedoch beim Dienstverzeichnis re-
gistriert werden. Der Betreiber des Dienstes hat die Aufrechterhaltung, Sicher-
heit, Wartung sowie Authentizierung sicher zu stellen. Das Dienstverzeichnis,
auch Registry oder Repository genannt, spiegelt die bereits erwahnten Gelben
Seiten wieder. Beim Dienstverzeichnis besteht die Moglichkeit der Registrierung
und der damit verbundenen Kategorisierung. Eine eindeutige Kategorisierung ist
w unschenswert, in der Praxis jedoch kaum moglich. Das Dienstverzeichnis kann
ebenfalls als Dienstsuchmaschine bezeichnet werden. Der Dienstnutzer ist ver-
gleichbar mit einem Client in einer Client Server Architektur. Er greift nach er-
folgreicher Suche auf vorhandene Dienste zu. F ur ihn ist es wichtig, dass die
Dienste auf Standards beruhen. Nur so ist es gewahrleistet, dass ein unbekannter
Nutzer einen bis dato unbekannten Dienst problemlos nutzen kann. Dazu muss
die beschriebene Schnittstelle dem Nutzer jedoch vollstandig dargelegt sein [2].
15.3.2 Aktionen in einer SOA
Zu den Aktionen in einer SOA zahlen die folgenden Punkte:
Veroentlichen
Suchen
Verweis auf Dienst
Interaktion mit dem Dienst.
Beim Veroentlichen hinterlegt der Dienstanbieter den Dienst in einer oentlichen
Umgebung (Installation). Dieser Vorgang wird auch als Deployment bezeich-
net. Es erfolgt dabei eine Registrierung, Eintragung sowie Kategorisierung beim
Dienstverzeichnis. Ein potenzieller Nutzer fragt daraufhin beim Dienstverzeich-
nis an. Durch die vorgenommene Kategorisierung ist es dem Dienstverzeichnis
moglich eine konkrete Antwort auf die Anfrage des Dienstnutzers zu generieren.
Die Beschreibung des Dienstes erfolgt durch Taxonomien sowie Ontologien. Sollte
ein potentieller Dienst gefunden worden sein, verweist das Dienstverzeichnis auf
den Dienst. Nach der Abfrage der Dienstbeschreibung durch den Nutzer beim
Dienstanbieter erhalt der Nutzer die Schnittstellenbeschreibung. Nach erfolgrei-
cher Authentizierung kann der Dienst daraufhin durch den Nutzer gebunden
werden. Einer erfolgreichen Nutzung steht fortan nichts mehr im Wege [2]. Die
Abbildung 15.2 fasst die genannten Rollen und Aktionen in einer Grak zusam-
men.
Abbildung 15.2: SOA Rollen und Aktionen
15.4 Web-Service-Architektur
In den vergangenen Kapiteln wurden Serviceorientierte Architekturen beleuchtet.
Web-Service-Architekturen stellen eine konkrete Implementierung einer Service-
orientierten Architektur dar. Sie ubernehmen dazu die folgenden grundlegenden
Komponenten:
Kommunikation
Dienstbeschreibung
Verzeichnisdienst.
Diese werden bei einer Web-Service-Architektur (WSArch) durch die folgenden
Techniken und Protokolle reprasentiert [1].
15.4.1 SOAP
Die Kommunikation einer WSArch lauft uber das SOAP-Protokoll ab. Das SOAP-
Protokoll beschreibt ein Protokoll zum strukturierten Datenaustausch in WSArch.
Das Protokoll basiert auf XML, dies wird zum Nachrichtenaustausch / Re-
prasentation verwendet. Es greift f ur den Transport auf die Transport- und An-
wendungsschicht des TCP/IP Modells zur uck. Als haugste Kombination kommt
dabei HTTP sowie TCP zum Einsatz. SOAP wird vor allem dort eingesetzt wo
der direkte Zugang zu einem fremden System nicht gewahrleistet ist oder f ur
15.4 Web-Service-Architektur 183
nicht sinnvoll erachtet wird. Die Gr unde daf ur sind vor allem in vielen verschie-
denen Anwendungsarchitekturen aber auch in Sicherheitaspekten zu nden. Die
Kommunikation mittels SOAP ermoglicht die lose Kopplung von Systemen. Dazu
wird beim Sender ein XML Dokument zusammengesetzt, welches anschlieend
validiert werden muss. Die minimale SOAP-Nachricht besteht aus einem Enve-
lope genannten Element. Diesem Element muss ein lokaler Name zugewiesen
werden. Ein optionales Kind-Element des Envelopes ist das Header-Element. Im
Header konnen Metadaten wie Routing oder Verschl usselung untergebracht sein.
Im anschlieenden Body-Element sind die eigentlichen Nutzdaten untergebracht.
Innerhalb des Body-Elements konnen sowohl Informationen zum Datenaustausch
als auch Anweisungen zum entfernten Prozeduraufruf vorhanden sein. Die gelie-
ferten Informationen sind vom Empfanger entsprechend zu interpretieren [3].
15.4.2 WSDL
Die Web-Service Description Language (WSDL) stellt eine Metasprache zum
Austausch von Nachrichten auf Basis von XML dar. Ihr haugster Einsatzort
ist die Beschreibung und der Nachrichtenaustausch innerhalb von Web-Services.
Die Sprache ist dabei plattform-, programmiersprachen- und protokollunabhangig.
Mittels WSDL ist es moglich Funktionen, Daten, Datentypen und Austauschpara-
meter eines Web-Services zu beschreiben. Es werden dabei die oentlichen Ope-
rationen, Parameter und R uckgabewerte kommuniziert (Prinzip des Information
Hiding). Zur Beschreibung der Schnittstelle und des Zugangsprotokolls werden
folgende Beschreibungselemente verwendet:
types (Datentypen)
messages (Nachricht)
portType (Schnittstellentypen)
binding (Bindung)
port (Port)
service (Service).
In types werden die f ur messages verwendeten Datentypen deniert. Sie werden
zum Austausch innerhalb von messages verwendet[4].
Das Element message stellt eine abstrakte Denition der zu ubertragenden Da-
ten dar und kann aus mehreren logischen Teilen bestehen. Im Element portType
vorhandene Schnittstellentypen werden in neueren Versionen der WSDL auch als
Interface bezeichnet. Die WSDL beschreibt 4 Typen von Schnittstellennachrich-
ten:
One-way (Service erhalt Nachricht vom Client)
Request-response (Client Anfrage - Service Antwort)
Solicit-response (Service Nachricht - Antwort Client)
Notication (Service sendet Nachricht).
Das binding eines Services bestimmt das konkrete Protokoll und Datenformat f ur
die ausgetauschten Nachrichten. Der port wiederum speziziert die genaue Adres-
se f ur das binding. F ur den Aufruf des Web-Services wird auf einen einheitlichen
Bezeichner wie den Uniform Resource Identier (URI) zur uckgegrien. Das letz-
te Beschreibungselement service fasst die bisher genannten Elemente zusammen
und beschreibt damit den Service vollstandig [4].
15.4.3 UDDI
Universal Description, Discovery and Integration (UDDI) bezeichnet den standar-
disierten Verzeichnisdienst in einer WSArch. Der Verzeichnisdienst besitzt eine
SOAP-Schnittstelle welche die Informationen zum Unternehmen, den Daten und
dem Service bereitstellt. Der dreiteilige Aufbau wird wie folgt vorgenommen.
Die White Pages enthalten Basisinformationen, welche Auskunft uber die
Identitat eines Serviceanbieters geben. Zu den moglichen Informationen zahlen
der Ansprechpartner, das Geschaftsumfeld, Kontaktdaten sowie eine einein-
deutige ID zur Identizierung des Unternehmens.
Die Yellow Pages dienen der Servicekategorisierung. Mit Hilfe der in den White
Pages bereit gestellten Informationen wird eine Kategorisierung hinsichtlich
des Zweckes vorgenommen.
Im letzten Bereich, den so genannten Green Pages, wird die Schnittstellenbe-
schreibung gespeichert [5].
Das Zusammenspiel der Bereiche m undet im Datenmodell der UDDI. Hierauf soll
jedoch an dieser Stelle nicht weiter eingegangen werden.
15.4.4 Rollen und Aktionen
F ugt man dem bekannten Modell einer SOA, die in den vorherigen Kapiteln be-
schriebenen Informationen hinzu, so erhalt man folgendes Modell.
Abbildung 15.3: WSArch Rollen und Aktionen
15.4.5 Beispiel - SOAP und WSDL
<?xml version="1.0"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Body>
<m:StudentenInDatenbank xmlns:m="http://www.host.com/soap">
Leisen, Baumbach, Herrmann
</m:StudentenInDatenbank>
</s:Body>
</s:Envelope>
Listing 15.1: SOAP Anfrage
Das Beispiel 15.1 stellt eine exemplarische Suchanfrage an den angegebenen Host.
Hierzu steht die Methode StudentenInDatenbank bereit welche den Namen als
Eingabe verlangt. Das Element StudentenInDatenbank ist nicht Teil der SOAP
Denition und ist somit anwendungspezisch. Die SOAP Anfrage enthalt kein
Header-Element.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Header>
<m:RequestID
xmlns:m="http://www.host.com/soap">c34deca</m:RequestID>
</s:Header>
<s:Body>
<m:DbResponse xmlns:m="http://www.host.com/soap">
<m:matrikel value="Leisen, Baumbach, Herrmann">
<m:Choice value="1">143257</m:Choice>
</m:title>
</m:DbResponse>
</s:Body>
</s:Envelope>
Listing 15.2: SOAP Antwort
In der Antwort des Dienstes 15.2 ist ein Header-Element vorhanden. Dies lie-
fert die AnfrageID zur uck. Die abgefragten Informationen benden sich im Body
der SOAP-Nachricht und liefern die Matrikelnummer der abgefragten Studenten
zur uck.
<definitions name="Studenten"
targetNamespace="http://host.com/studenten.wsdl"
xmlns:tns="http://host.com/studenten.wsdl"
xmlns:xsd1="http://host.com/studenten.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
....
</definitions>
Listing 15.3: WSDL Service Denition
Das Listing 15.3 zeigt die WSDL service Denition f ur den zugehorigen Dienst.
<types>
<schema targetNamespace="http://host.com/studenten.xsd"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="MatrikelRequest">
<complexType>
<all>
<element name="name" type="string"/>
</all>
</complexType>
</element>
<element name="MatrikelResponse">
<complexType>
<all>
<element name="matrikel" type="integer"/>
</all>
</complexType>
</element>
</schema>
</types>
Listing 15.4: WSDL types Denition
Listing 15.4 zeigt die types Denitionen
<message name="GetNameInput">
<part name="body" element="xsd1:MatrikelRequest"/>
</message>
<message name="GetMatrikelOutput">
<part name="body" element="xsd1:MatrikelResponse"/>
</message>
Listing 15.5: WSDL message Denition
In Listing 15.5 sind die WSDL message Denitionen zu sehen.
<portType name="StudentenPortType">
<operation name="GetStudent">
<input message="tns:GetNameInput"/>
<output message="tns:GetMatrikelOutput"/>
</operation>
</portType>
Listing 15.6: WSDL portType Denition
Listing 15.6 zeigt die zugehorigen portType Denitionen.
<binding name="StudentSoapBinding" type="tns:StudentenPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetStudent">
<soap:operation soapAction="http://host.com/GetStudent"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
Listing 15.7: WSDL binding Denition
Die WSDL binding Denitionen sind in Listing 15.7 zu sehen.
<service name="StudentService">
<documentation>Meine erster Web-Service</documentation>
<port name="StudentPort" binding="tns:StudentSoapBinding">
<soap:address location="http://host.com/student"/>
</port>
</service>
Listing 15.8: WSDL service Denition
15.8 zeigt die zugehorigen WSDL service Dentionen
15.4.6 Vor- und Nachteile
Folgende Vorteile ergeben sich aus den vorangegangenen Kapiteln:
groer Kostenvorteil durch geringe Implementierungskosten
Verwendung oener Standards
oene und exible Architektur
Interoperabilitat
geringe Einstiegsbarrieren.
Folgende Nachteile ergeben sich aus der Verwendung von Web-Services-Architek-
turen:
Sicherheitsaspekte wie Authentizierung und Verschl usselung kaum umgesetzt
Performance oft mangelhaft aufgrund von Protokolloverhead und loser Kopp-
lung
Schnittstellen m ussen genau deniert sein.
15.5 Fazit
Die Einf uhrung in Serviceorientierte Architekturen hat den Grundstein f ur das
Verstandnis von Web-Service-Architekturen gelegt. SOA sind dabei nicht als
Web-Services anzusehen. Sie beschreiben losgelost von einer konkreten Im-
plementierung lediglich eine Architektur. Als Beispiel f ur eine SOA kann ein
Geschaftsprozess zu Rate gezogen werden. Bei diesem wird deutlich, das es sich
bei einer Serviceorientierten Architektur jeweils um eine individuelle Unterneh-
menslosung handelt.
Die vorgestellten Standards SOAP, WSDL und UDDI stellen die grundlegenden
Funktionen f ur WSArch bereit. Mittels Web-Services ist eine verteilte Zusammen-
arbeit zwischen verschiedenen Anwendungsprogrammen moglich. Dabei spielt es
keinerlei Rolle welche Plattformen, Programmiersprachen bzw. Frameworks ver-
wendet werden. Durch geringe Implementierungs- und Betriebskosten stellen Web-
Services eine kosteng unstige Art der Datenreprasentation dar. Die Verwendung
von oenen Standards ermoglicht eine grotmogliche Interoperabilitat.
[1] Web Service Architecture W3C 2004 - http://www.w3.org/TR/ws-arch/
[2] W.Dostal, M. Jeckle, I.Melzer, B.Zengler, Service-orientierte Architekturen
mit Web Services. Spektrum Akademischer Verlag 2005.
[3] SOAP Tutorial - http://www.w3schools.com/soap/default.asp
[4] Web Service Dention Language (WSDL) - http://www.w3.org/TR/wsdl
[5] Universal Description Discovery and Integration -
http://de.wikipedia.org/wiki/UDDI
16 Apache CXF
Martin Herrmann
Inhaltsverzeichnis
16.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 191
16.2 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . 192
16.3 Implementierte Protokolle . . . . . . . . . . . . . . . . . 192
16.3.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . 192
16.3.2 WSDL . . . . . . . . . . . . . . . . . . . . . . . 193
16.3.3 WS-*-Spezikationen . . . . . . . . . . . . . . . 193
16.3.4 Weitere Protokolle . . . . . . . . . . . . . . . . . 194
16.4 Unterst utzte Programmieransatze . . . . . . . . . . . . . 195
16.4.1 Spring . . . . . . . . . . . . . . . . . . . . . . . 195
16.4.2 JAX-WS . . . . . . . . . . . . . . . . . . . . . . 195
16.4.3 JAX-RS . . . . . . . . . . . . . . . . . . . . . . 195
16.4.4 Weitere Programmierverfahren . . . . . . . . . . 195
16.5 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
16.6 Anwenderfreundlichkeit . . . . . . . . . . . . . . . . . . . 199
16.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
16.1 Einleitung
Im Zeitalter des Web 2.0 werden eine Vielzahl von Anwendungen verteilt uber das
Internet realisiert. F ur die Interaktion zwischen Anwendungsprogrammen werden
vermehrt Web-Services eingesetzt, die eine Zusammenarbeit von Anwendungen
auf verschiedenen Plattformen erleichtern sollen. Apache CXF ist ein Framework
welches es Entwicklern erleichtern soll solche Web-Services zu implementieren.
Diese Ausarbeitung betrachtet Apache CXF naher, stellt dessen Funktionalitaten
dar und soll zeigen, ob es den Entwickler damit ermoglicht wird, auf einfachem
Wege Web-Services zu erstellen.
192 16 Apache CXF
16.2 Allgemeines
Bei Apache CXF handelt es sich um ein so genanntes Open-Source-Web-Service-
Framework welches auf Java basiert. Es stellt dem Entwickler einen Program-
mierrahmen bereit, der es ihm erlaubt verschiedenen Schnittstellen, Verfahren
und Anwendungen in Bezug auf Web-Services mit geringem Aufwand zu imple-
mentieren. Solche Web-Services sind XML-basierte Kommunikationsschnittstellen
f ur verteilte Systeme, die plattform ubergreifende Anwendungen realisieren sollen.
CXF unterst utzt zudem eine Vielzahl von Frontendprogrammiermodellen. Apache
CXF wird als Open Source Software von der Apache Software Foundation unter
der Apache License 2.0 veroentlicht[1].
Apache CXF entwickelte sich aus den Web-Service-Frameworks Codhouse XFire
und IONA Celtix, welche zu Apache CXF verschmolzen und so die Abk urzung CXF
f ur CeltiXFiredenierten. Die Entwickler von Celtix arbeiteten bis 2006, die von
XFire noch bis Mai 2007 eigenstandig an ihren Softwarelosungen und begannen
danach mit der Implementierung von Apache CXF. Beide Softwarelosungen brach-
ten eine groe Zahl von Protokollen und Programmierverfahren zur Erstellung von
verteilten Anwendungen in das neue Programm ein. Die Firma IONA, die vormals
Celtix entwickelte, vertreibt aktuell eine Enterprise-Version von CXF mit Support-
und Servicevertragen[2], [3].
16.3 Implementierte Protokolle
Obwohl Apache CXF im Vergleich zu anderen Frameworks wie etwa Apache
Axis recht schlank ist[4], verf ugt es dennoch uber eine vielfaltige Auswahl von
implementierten Protokollen und Verfahren zur Entwicklung von Web-Services.
Die Entwickler erweitern zudem mit dem Voranschreiten des Projekts dieses mit
zusatzlichen Ansatzen. So kann Apache CXF als ein kleines Sammelsurium von
vielen, aber dennoch ausgewahlten Web-Service-Implementierungsverfahren ver-
standen werden. Es obliegt allerdings oft der Aufgabe des Entwicklers sich f ur das
optimale Verfahren zu entscheiden. Einige Vorkenntnisse uber Web-Services sind
somit notwendig um die optimale Schnittstelle zu spezizieren, wenn diese nicht
vom verteilten System deniert sind. Im Folgenden werden einige der wichtigsten
enthaltenen Protokolle zur Realisierung von Web-Service vorgestellt.
16.3.1 SOAP
SOAP (urspr unglich f ur Simple Object Access Protocol) stellt ein Protokoll der
Anwendungsschicht dar. Primar in Kombination mit HTTP und TCP verwendet,
handelt es sich hierbei um eine Rahmenvorgabe von XML-basierten Nachrichten
16.3 Implementierte Protokolle 193
zur Kommunikation von Systemen. Es ermoglicht verteilten Systemen Informa-
tionen via HTTP auszutauschen und stellt somit eine wichtige Grundlage f ur
die Entwicklung von Web-Services dar[5]. SOAP war bereits in den Frameworks
Codehouse XFire und IONA Celtix enthalten auf denen CXF basiert.
16.3.2 WSDL
Bei WSDL (Web Services Description Language) handelt es sich um eine XML-
basierte Metasprache um Web-Service-Funktionen anzubieten und auszulesen. So
kann vom Client der Funktionsumfang der Serveranwendungen ermittelt werden
um verteilte Anwendungen zu strukturieren. WSDL wird in der Regel mit SOAP
verwendet um Web-Services zu realisieren. Die XML-Struktur von WSDL wird
dabei durch folgende 6 Elemente beschrieben[6]:
Datentypen f ur Daten die den Nachrichtenaustausch beschreiben.
Nachrichten entsprechen gesendeten und empfangenen Daten.
Schnittstellen beschreiben Dienstoperationen.
Protokoll beschreibt Protokolle und Datenformate einer Schnittstelle.
Port ist eine Adresse f ur ein Protokoll.
Service fasst mehrere Ports zusammen.
Zuk unftig ist die Implementierung von WSDL 2.0 geplant, welches einige Erwei-
terungen und Spezikationen f ur die dahinterstehende Metasprache liefern soll.
16.3.3 WS-*-Spezikationen
Eine Erweiterung des SOAP/WSDL-Ansatzes zum Erstellen von Web-Services
stellen die so genannten WS-*-Spezikationen des World Wide Web Consortium
(W3C) dar. Diese basieren auf SOAP und WSDL, spezizieren aber weitere, sehr
spezielle Verfahren zur Abstimmung und Kommunikation von verteilten Systemen
zur Implementierung bzw. Nutzung von Web-Services.
Eine Vielzahl der Protokolle wurde bereits in Apache CXF implementiert, so dass
diese vom Entwickler eines Web-Services ohne viel Aufwand implementiert werden
konnen. Dabei sind aktuell folgende Standards umgesetzt (Version 2.3.2, Stand
31.01.2011)[7]:
WS-Adressing f ur Verfahren zum Austausch von Adressinformationen.
WS Policy f ur Verfahren zum Austausch von Richtlinien, Qualitat, Version
des Systems.
194 16 Apache CXF
WS-Reliable Messaging f ur Verfahren, die unter Zuhilfenahme einer Middel-
ware sicherstellen, dass gesendete Nachrichten trotz Teilversagen des Systems
zugestellt werden.
WS-Security f ur Kommunikationsprotokolle um Sicherheitsaspekte gewahr-
leisten zu konnen.
WS-SecurityPolicy f ur Verfahren zur Zusicherungen an Sicherheitaspekten.
WS-SecureConversation f ur Verfahren zur Realisierung einer sicheren Kom-
munikation.
WS-Trust f ur Verfahren zum Domanen- ubergreifenden Austausch von Infor-
mationen.
Neben den bereits implementierten WS-*-Spezikationen sind folgende f ur
zuk unftige Versionen von Apache CXF geplant:
WS-Coordination f ur Verfahren um verteilte Anwendung miteinander zu ko-
ordinieren.
WS-Atomic Transactions erweitert WS-Coordination um Spezikationen f ur
kurz laufende Anwendungen.
WS-BusinessActivity erweitert WS-Coordination um Spezikationen f ur
langer laufende Anwendungen.
WS-MetaDataExchange f ur Verfahren zur Suche von Web-Service- Meta-
daten.
WS-Eventing f ur Verfahren um ein Event-Management f ur Web-Services zu
realisieren.
WS-Transfer f ur Verfahren um

Ubertragungsspezikationen f ur Web-Services
zu denieren.
16.3.4 Weitere Protokolle
Neben den bereits vorgestellten Protokollen zur Realisierung von Web-Services,
sind in Apache CXF noch viele weitere Ansatze implementiert. Dazu zahlen un-
ter andrem COBRA, Pure XML und REST. Eine aktuelle und vollstandige Liste
bendet sich auf der Homepage[7] des Projektes.
16.4 Unterst utzte Programmieransatze 195
16.4 Unterst utzte Programmieransatze
Neben den vorgestellten Web-Service-Protokollen verf ugt CXF uber eine Auswahl
von implementierten Programmierverfahren die uberwiegend auch zur Frontend-
programmierung bei der Entwicklung von Web-Services genutzt werden konnen.
Im Folgenden wird eine Auswahl der wichtigsten Verfahren vorgestellt.
16.4.1 Spring
Bei Spring handelt es sich um ein eigenstandiges Open-Source-Framework auf
Java-Basis. Spring vereinfacht die Programmierlogik und soll gute Programmier-
praktiken fordern. Mit Spring soll es vereinfacht werden die Applikationskom-
ponenten eines Programmes auszulagern. Die Besonderheit, die Spring als eine
wichtige Komponente von CXF auszeichnet, ist die Tatsache, dass viele verschie-
dene Plattformen und Systeme unterst utzt werden. Spring wurde in Apache CXF
integriert, da mittels dieses Frameworks eine gute Moglichkeit besteht Verteil-
te Anwendungen zu realisieren[8]. Ein Beispiel zur Implementierung von Spring
ndet sich im Kapitel 16.5 auf Seite 196.
16.4.2 JAX-WS
Beim Java API for XML - Web Services handelt es sich um eine Java-Pro-
grammschnittstelle zum Erstellen von Web-Services. Sie erleichtert den Program-
mierern die Konguration des Web-Services und der Kommunikation zwischen
verteilten Anwendungen. JAX-WS integriert die Protokolle SOAP, WSDL sowie
einige WS-*-Standards, weshalb es sich gut in Apache CXF integrieren lasst[9].
16.4.3 JAX-RS
Das Java API for RESTful Web Services ist eine Java-Programmierschnittstelle
zum Erstellen eines Web-Services unter Verwendung von Representational State
Transfer (kurz REST). Ebenso wie bei JAX-WS erleichtert JAX RS es den Pro-
grammierern Web-Services zu implementieren und verteilte Anwendungen zu rea-
lisieren. JAX-RS wurde im Rahmen des Java Community Process von einem Kon-
sortium um die Firma Sun Microsystems erarbeitet. Die Integrierung in CXF er-
laubt dem Entwickler abseits von SOAP/WSDL zu arbeiten[10].
16.4.4 Weitere Programmierverfahren
Neben den vorgestellten Programmieransatzen hat Apache CXF weitere Verfahren
integriert und wird mit Voranschreiten des Projektes um weitere Moglichkeiten
196 16 Apache CXF
zur Implementierung von Web-Services erweitert. Einige weitere Ansatze und Pro-
grammierschnittstellen sind Java Business Integration (JBI), Java EE Connector
Architecture (JCA) und Java Management Extensions (JMX). Eine vollstandige
Liste der aktuell implementierten und geplanten Programmieransatze ndet sich
auf der Homepage[7] des Projektes.
16.5 Beispiel
Im Folgenden soll an einem einfachen Beispiel gezeigt werden, wie ein Projekt mit
Hilfe von CXF erstellt werden kann. Es wird ein trivialer Service mithilfe von Spring
und Zuhilfenahme von WSDL erstellt. Der Code kann mit Hilfe jeder IDE erstellt
werden, die beste Unterst utzung von Seiten Apache CXF erhalt man allerdings
f ur Eclipse[11]. Andere IDEs wie Netbeans oder das Kompilieren mit Hilfe von
Apache Maven und Apache Ant ist aber ebenso moglich. Am stabilsten lauft CXF
auf dem JRE 1.5, allerdings wird auch die neuere Version 1.6 unterst utzt.
Vor der eigentlichen Implementierung muss ein neues Projekt angelegt werden
und einige Dateien eingebunden werden. Folgende JAR-Files sind Standard-
CXF-Bibliotheken die f ur die meisten Projekte benotigt werden und von der
Homepage[1] des Projectes bezogen werden konnen:
commons-logging-1.1.jar
geronimo-activation_1.1_spec-1.0-M1.jar
geronimo-annotation_1.0_spec-1.1.jar
geronimo-javamail_1.4_spec-1.0-M1.jar
geronimo-servlet_2.5_spec-1.1-M1.jar
geronimo-ws-metadata_2.0_spec-1.1.1.jar
jaxb-api-2.0.jar
jaxb-impl-2.0.5.jar
jaxws-api-2.0.jar
neethi-2.0.jar
saaj-api-1.3.jar
saaj-impl-1.3.jar
stax-api-1.0.1.jar
wsdl4j-1.6.1.jar
wstx-asl-3.2.1.jar
XmlSchema-1.2.jar
xml-resolver-1.2.jar
Listing 16.1: CXF-Projekt - allgemeine JAR-Dateien
Um Spring und CXF (Versionsangabe) verwenden zu konnen m ussen zusatzlich
folgende Dateien eingebunden werden:
16.5 Beispiel 197
aopalliance-1.0.jar
spring-core-2.0.8.jar
spring-beans-2.0.8.jar
spring-context-2.0.8.jar
spring-web-2.0.8.jar
cxf-2.1.jar
Listing 16.2: CXF-Projekt - Spring und CFX JAR-Dateien
Sind alle Dateien in das Projekt eingebunden, kann mit der Implementierung des
Services begonnen werden. F ur die Erstellung eines Web-Services m ussen eine
Interface- und eine Implementierung-Datei angelegt werden. Die Interface-Datei
sieht im aktuellen Beispiel wie folgt aus:
package demo.spring;
import javax.jws.WebService;
@WebService
public interface HelloWorld {
String sayHi(String text);}
Listing 16.3: CXF-Projekt - Interface-Datei
Die zugehorige Implementation enthalt folgenden Code:
package demo.spring;
import javax.jws.WebService;
@WebService(endpointInterface = "demo.spring.HelloWorld")
public class HelloWorldImpl implements HelloWorld {
public String sayHi(String text) {
System.out.println("sayHi called");
return "Hello " + text; }}
Listing 16.4: CXF-Projekt - Implementation-Datei
Der Service ist damit vollstandig um eine HalloWorld-Antwort zu produzieren.
Durch die Annotation @WebService kann CXF automatisch eine entsprechende
WSDL-Datei erstellen. Um den Web-Service mittels Spring nutzen zu konnen,
m ussen noch die Server Beans angepasst werden. Dazu m ussen im WEB-INF-
Ordner die Datei beans.xml folgendermaen anpassen:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jaxws="http://cxf.apache.org/jaxws"
xsi:schemaLocation="http://www.springframework.org/schema/beans
198 16 Apache CXF
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
<jaxws:endpoint id="helloWorld"
implementor="demo.spring.HelloWorldImpl"
address="/HelloWorld" />
</beans>
Listing 16.5: CXF-Projektt - beans.xml
Um den Spring-Service zu komplettieren, muss zuletzt die web.xml-Datei ange-
passt werden:
<web-app><context-param>
<param-name>contextConfigLocation</param-name>
<param-value>WEB-INF/beans.xml</param-value>
</context-param>
<listener><listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class></listener>
<servlet><servlet-name>CXFServlet</servlet-name>
<display-name>CXF Servlet</display-name>
<servlet-class>org.apache.cxf.transport.servlet.CXFServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping><servlet-name>CXFServlet</servlet-name>
<url-pattern>/ *</url-pattern>
</servlet-mapping>
</web-app>
Listing 16.6: CXF-Projekt - web.xml
Mit dem in der web.xml denierten ContextLoaderListener wird das Spring-
Framework gestartet und die beans.xml geladen. Damit ist der Spring-Web-Service
vollstandig implementiert und einsatzbereit. Um den Service testen zu konnen,
ist abschlieend die Implementierung eines Clients notwendig. Dies ist allerdings
relativ trivial und sieht im aktuellen Beispiel wie folgt aus:
package demo.spring.client;
import org.springframework.context.support.
ClassPathXmlApplicationContext;
import demo.spring.HelloWorld;
16.6 Anwenderfreundlichkeit 199
public final class Client { private Client() { }
public static void main(String args[]) throws Exception {
// START SNIPPET: client
ClassPathXmlApplicationContext context
= new ClassPathXmlApplicationContext(new String[]
{"demo/spring/client/client-beans.xml"});
HelloWorld client = (HelloWorld)context.getBean("client");
String response = client.sayHi("Joe");
System.out.println("Response: " + response);
System.exit(0); }} // END SNIPPET: client
Listing 16.7: CXF-Projekt - Client
Abschlieend muss noch die Bean-Datei des Servers angepasst werden. Im aktu-
ellen Beispiel einfach an den entsprechenden Localhost-Port.
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jaxws="http://cxf.apache.org/jaxws"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
<jaxws:endpoint id="helloWorld"
implementor="demo.spring.HelloWorldImpl"
address="/HelloWorld" />
</beans>
Listing 16.8: CXF-Projekt - Client beans.xml
Als Ergebnis erhalten wir einen Client und einen Server zur Realisierung eines
trivialen Web-Services, der problemlos erweitert werden kann[12].
16.6 Anwenderfreundlichkeit
Apache CXF ist im Vergleich zu vielen anderen Open-Source-Projekten recht
weit entwickelt. Es werden regelmaig Updates und Weiterentwicklungen ver-
oentlicht, sowie Fehler behoben. Trotz der schlanken Implementierung ist das
Projekt vielfaltig und hat viele Ansatze zur Entwicklung und Gestaltung von Web-
Services integriert. Dieser Punkt kann aber dahingehend als Nachteil betrachtet
werden, dass eine groe Vielfalt an Entwicklungsmoglichkeiten viele Vorkenntnisse
200 16 Apache CXF
beim Entwickler voraussetzt. Das Projekt liefert nur eine sparliche Dokumentation
seiner Funktionalitaten, was dazu f uhrt, dass auch professionelle Entwickler eine
gewisse Einarbeitungszeit in das Projekt investieren m ussen, um damit produk-
tiv arbeiten zu konnen. User die uber geringere Programmierkenntnisse verf ugen
und Apache CXF als Instrument verwenden wollen, um auf einfachen Wege Web-
Services zu implementieren, werden eine langere Einarbeitungszeit benotigen. Auf-
grund der vielfaltigen Implementierung und der entgegenstehenden schlechten Do-
kumentation ist es f ur User ohne groes Hintergrundwissen nahezu unmoglich die
Funktionalitaten von CXF voll auszunutzen und die Vorz uge gegen uber anderen
Entwicklungsmethoden wahrzunehmen.
16.7 Fazit
Apache CXF ist ein vielfaltiges, aber dennoch schlankes Web-Service-Framework,
welches dem Entwickler bei der Implementierung von Web-Service unterst utzen
soll. Das Projekt wird seit mehreren Jahren kontinuierlich weiterentwickelt und
hat deshalb sehr viele implementiere Schnittstellen, Protokolle und Verfahren.
CXF kann somit als kleines Sammelsurium an Methoden zum Erstellen von Web-
Services verstanden werden. Dennoch ist es in mancher Hinsicht beschrankter als
andere Frameworks wie etwa Apache Axis. Es liefert aber auch Funktionalitaten,
wie die Integration von Spring, welches es gegen uber von anderen Frameworks
abhebt. Zu kritisieren ist die l uckenhafte Dokumentation, welche es Entwicklern
mit geringeren Vorkenntnissen erschwert sich schnell in das Projekt einzuarbeiten
und die Funktionalitaten im vollen Umfang einzusetzen. F ur eine kommerzielle
Nutzung m usste eine bessere Dokumentation und Nutzerunterst utzung angeboten
werden. Dennoch ist Apache CXF ein gut entwickeltes Framework, welches nach
einer gewissen Einarbeitungszeit eektiv zur Erstellung von Web-Services genutzt
werden kann.
[1] Apache Software Foundation (Hrsg.), Apache CXF: An Open-Source Services
Framework, http://cxf.apache.org, 21.01.2011
[2] Codehouse (Hrsg.), Codehouse XFire, http://xre.codehaus.org, 03.01.2011
[3] IONA (Hrsg.), Celtix: The Open Source Java ESB, http://celtix.ow2.org,
03.01.2011
[4] Thomas Bayer, Apache Axis2, CXF und Sun JAX-WS RI im Vergleich,
http://www.predic8.de/axis2-cxf-jax-ws-vergleich.htm, 04.01.2011
[5] W3school (Hrsg.), SOAP Tutorial, http://www.w3schools.com/soap/
default.asp, 05.01.2011
[6] W3school (Hrsg.), WSDL Tutorial, http://www.w3schools.com/wsdl/
default.asp, 05.01.2011
[7] Apache Software Foundation (Hrsg.), Apache CXF - Projekt Status,
http:cxf.apache.org/project-status.html, 31.1.2011
[8] SpingSource (Hrsg.), The Standard for Enterprise Java Development,
http://www.springsource.com/developer/spring, 05.01.2011
[9] Oracle Corporation (Hrsg.), Getting Started with JAX-WS Web Services,
http://netbeans.org/kb/docs/websvc/jax-ws.html, 21.01.2011
[10] Oracle Corporation (Hrsg.), Jersey: RESTful Web services made easy,
http://wikis.sun.com/display/Jersey/Main, 21.01.2011
[11] Apache Software Foundation (Hrsg.), Apache CXF - Setting up Eclipse,
http://cxf.apache.org/setting-up-eclipse.html, 05.01.2011
[12] Apache Software Foundation (Hrsg.), Apache CXF - Writing a service
with Spring, http://cxf.apache.org/docs/writing-a-service-with-spring.html,
05.01.2011
202 16 Apache CXF
Teil V
Grid, Cluster und Monitoring
17 Globus Toolkit
Martin Baumbach
Inhaltsverzeichnis
17.1 Grid Computing . . . . . . . . . . . . . . . . . . . . . . . 205
17.1.1 Begriserklarung . . . . . . . . . . . . . . . . . . 205
17.1.2 Funktionsweise und Anwendungsgebiete . . . . . 206
17.2 Das Globus Toolkit . . . . . . . . . . . . . . . . . . . . . 207
17.2.1 Allgemeines . . . . . . . . . . . . . . . . . . . . 207
17.2.2 Vorteile . . . . . . . . . . . . . . . . . . . . . . . 208
17.2.3 Aufbau . . . . . . . . . . . . . . . . . . . . . . . 209
17.3 Bedienung und Eingabebefehle . . . . . . . . . . . . . . . 212
17.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Das Globus Toolkit ist ein Open Source Toolkit zur Erzeugung von Computing
Grids und wird von der Globus Alliance entwickelt und angeboten. Die Globus Al-
liance ist eine internationale Organisation, welche sich auf die Entwicklung grund-
legender Technologien f ur Grid-Infrastrukturen konzentriert. Das Toolkit kann auf
folgenden Betriebssystemen zum Einsatz kommen: Linux, FreeBSD, Solaris, Mac
OS X, HP-UX und AIX. Die derzeit aktuellste Version des Toolkits ist die 5.0.2,
welche am 19.07.2010 veroentlicht wurde.
17.1 Grid Computing
Um das Globus Toolkit besser zu verstehen, ist eine Einf uhrung in die Thematik
des Grid-Computing notwendig. Die folgenden Abschnitte erlautern verschiedene
Begriichkeiten und die Funktionsweise f ur ein besseres Verstandnis.
17.1.1 Begriserklarung
Grid-Computing ist eine Art des verteilten Rechnens. Es ist eine koordinierte, ge-
meinsame Nutzung von Ressourcen uber geographische Grenzen hinweg. Somit ist
es moglich uber Institutsgrenzen hinaus virtuelle Organisationsstrukturen zu bil-
den. Dadurch wird ein verteiltes System gebildet. Hierbei wird ein Supercomputer
aus einem Cluster lose gekoppelter Computer erzeugt.
206 17 Globus Toolkit
Diese Art des verteilten Rechnens dient zur Losung von rechenintensiven, ma-
thematischen und wissenschaftlichen Problemen. Der Unterschied zu typischen
Computerclustern liegt zum einen bei einer wesentlich loseren Kopplung der ein-
zelnen beteiligten Computer und zum anderen bei der geographischen Zerstreuung
der Computer. Nicht alle Computer benden sich zentral in einem Serverraum um
rechenintensive Aufgaben zu bewaltigen. Daher liegt ublicherweise auch eine He-
terogenitat vor. Ein Grid dient in den meisten Fallen zur Bewaltigung einer speziel-
len Aufgabe und wird im Normalfall nicht f ur unterschiedliche Zwecke eingesetzt,
im Gegensatz zu typischen Computerclustern. Auerdem werden standardisierte
Programmbibliotheken und Middlware genutzt. Der Vorteil eines Grids ist, dass
der Zugang zu verschiedenartigen Systemen moglich gemacht wird und somit
der Zugang zu den Daten der unterschiedlichen Systeme gewahrleistet ist. Durch
Grid-Computing werden verschiedene Probleme behoben. Beispielsweise bietet ei-
ne Grid eine einheitliche Schnittstelle f ur den Zugang zu Systemen und einen
transparenten Zugri auf die Daten. Dadurch ist eine sogenannte Interoperabi-
litat gegeben. Unter Interoperabilitat versteht man eine unabhangige, moglichst
nahtlose Zusammenarbeit heterogener Systeme um Informationen ezient und
gut verwertbar auszutauschen. Man kann Grid-Computings in verschiedene Klas-
sen unterteilen:
Computing Grids (Rechengrids): Zugri auf verteilte Rechenressourcen
Data Grids (Datengrids): Zugri auf verteilte Datenbanken
Knowledge Grids: Software-System zur Wissensgewinnung
Ressource Grids: Stellt Rechenzeit oder Speicherkapazitat zur Verf ugung
Service Grids: Stellt IT-Dienste bereit
17.1.2 Funktionsweise und Anwendungsgebiete
Beim Grid-Computing ist zunachst jeder Computer jedem anderen gleich gestellt.
Genau wie bei einer Peer-to-Peer-Connection. Daher ist eine strenge Hierarchie
notwendig, welche die Verteilung der Rechenleistung nach objektiven Kriterien
verwaltet. An Hardware wird nur ein Computer mit Netzwerkverbindung benotigt.
Auf den einzelnen Computern, welche im Grid zusammenarbeiten, ubernimmt eine
Software das Losen einer ihm zugeteilten Teilaufgabe. Diese wird im Normalfall
von einem zentralen Server zur Verf ugung gestellt. Der Server nutzt eine Software,
welche die groe, rechenintensive Aufgabe in mehrere Teilaufgaben aufsplittet und
an einzelne Knoten, Computer im Grid, verteilt und nach dem Losen die einzelnen
Teilergebnisse wieder zu einem Gesamtergebnis zusammentragt. Grid-Computing
kommt dann zum Einsatz, wenn einzelne Computer mit ihrer Rechenleistung an
ihre Grenzen gelangen.
17.2 Das Globus Toolkit 207
Daher sind typische Aufgaben beispielsweise die Auswertung, Integration und Dar-
stellung von sehr groen Datenmengen. Dies ist sehr hilfreich in der naturwis-
senschaftlichen oder medizinischen Forschung. Weitere Einsatzgebiete sind die
Meteorologie, mit der Auswertung von Wetterdaten, oder rechenintensive Indus-
triesimulationen. Ein Vorreiter in der Weiterentwicklung und Etablierung von Grid-
Computing ist die Teilchenphysik mit Groexperimenten wie Teilchenbeschleuni-
gern oder ahnlichem. Zur Erzeugung von verschiedenartigen Grids gibt es diverse
Grid-Middleware. Einige Beispiele hierf ur sind:
UNICORE
Xgrid
gLite
Gridbus
OurGrid
Sun Grid Engine
Globus Tookit
Im Rahmen der Ausarbeitung wird in den folgenden Abschnitten das Globus Tool-
kit vorgestellt und naher erlautert [1].
17.2 Das Globus Toolkit
Die Globus Alliance bietet zwei Losungen von Grid Software: Globus Online,
welches schon auf einer fertigen Grid-Architektur basiert und f ur Testzwecke und
Berechnungen jeglicher Art verwendet werden kann und das Globus Toolkit,
welches zur Erstellung eines eigenen Grids genutzt werden kann. Globus Online
steht unter dem Motto Use the Grid und das Globus Toolkit unter dem Motto
Build the Grid.
17.2.1 Allgemeines
Das Globus Toolkit ist eine grundlegende Technologie f ur Grids. Mit Hilfe die-
ser Open Source Software konnen Menschen Rechenleistung, Datenbanken und
andere Werkzeuge online und sicher uber Unternehmen, Institutionen und geo-
graphische Grenzen hinweg teilen.
Das Toolkit beinhaltet Softwareservices und Bibliotheken zur Ressourcen uber-
wachung, Verwaltung, Sichtung sowie Sicherheits- und Datenmanagement und
enthalt Software f ur die Sicherheits- und Informationsinfrastruktur, Ressourcen-
und Datenmanagement, Kommunikation, Fehlererkennung und Portabilitat. Es ist
so konstruiert, dass die einzelnen Softwarepakete und Komponenten zusammen
aber auch unabhangig voneinander verwendet werden konnen. Da jede Organisa-
tion uber eine einzigartige Struktur und Unternehmensphilosophie verf ugt, wird
die Zusammenarbeit erschwert. Gr unde hierf ur sind die Inkompatibilitat von Res-
sourcen, Computern und Netzwerken. Das Globus Toolkit wurde entwickelt um
genau diese Hindernisse, welche eine nahtlose Zusammenarbeit verhindern, aus
dem Weg zu raumen. Die zentralen Dienste, Schnittstellen und Protokolle des
Toolkits ermoglichen es dem Benutzer uber einen Remote-Zugri auf Ressourcen
zuzugreifen, so als w urde sich der Nutzer direkt vor Ort benden. Gleichzeitig
hat man mit dem Toolkit die Kontrolle dar uber, wer wann die einzelnen Res-
sourcen nutzt. Das Globus Toolkit wurde mit einer Open Source Strategie ent-
wickelt, welche dem des Linux Betriebssystems sehr ahnelt. An der Entwicklung
sind unzahlige Entwickler weltweit beteiligt. Dadurch wird eine schnellere und
groere Verbreitung gefordert und dies f uhrt zu mehr technischen Innovationen.
Die Open-Source-Community arbeitet standig an Produktverbesserungen und der
Weiterentwicklung und Fehlerbehebung der Software [2].
17.2.2 Vorteile
Das Globus Toolkit bietet eine einheitliche Schnittstelle, auch beim Einsetzen
unterschiedlicher Systeme. Des Weiteren bedient es sich dem Prinzip des Single-
Sign-On. Somit ist der Nutzer nach einmaliger Authentizierung am Arbeitsplatz
berechtigt auf alle Rechner und Dienste zuzugreifen. Dies gilt f ur alle Dienste f ur
die er autorisiert ist. Somit entfallt eine standige Neuanmeldung bei den einzel-
nen Diensten. Es bietet zudem die Moglichkeit der Interoperabilitat. Somit besteht
die Fahigkeit in unabhangigen, heterogenen, verschiedenen Systemen, Organisa-
tionen oder Techniken moglichst nahtlos zusammen zu arbeiten. Dadurch konnen
die Informationen ezient und gut verwertbar ausgetauscht werden ohne dabei
auf eine Absprache zwischen den beteiligten Systemen zur uckgreifen zu m ussen.
Hierbei ist jedoch zu beachten, dass verschiedene Standards in den Systemen
eingehalten werden m ussen. Durch die Interoperabilitat ist daher das Arbeiten
und Rechnen in anderen Grid-Projekten problemlos moglich. Gleichzeitig besteht
die Moglichkeit Daten auf andere Ressourcen, welche sich innerhalb des Grids
benden, zu transferieren.
Ein weiterer groer Vorteil ist die Aufgabenverteilung auf die einzelnen Syste-
me beziehungsweise die Erzeugung eines guten Workows. Beispielsweise kann
das Pre-Processing am Standort A stattnden, die eigentliche Berechnung der
Daten am Standort B und die nale Auswertung der Ergebnisse schlielich am
Standort C. Dadurch m ussen die einzelnen Personen sich nicht zentral an einem
Standort benden, was zur Arbeitserleichterung beitragt. Einzelne Clients nutzen
eigene interne Richtlinien (Policies), unterschiedliche Installationen, Batch Sys-
teme, Netzwerkprotokolle und Benutzerverwaltungen. Durch das Globus Toolkit
ndet eine Vereinheitlichung auf Basis von verschiedenen Standards statt. Das
Toolkit basiert auf Web-Services, auf welche noch eingegangen wird. Das 15.
Kapitel beschaftigt sich mit der Architektur von Web Services. Somit bietet das
Globus Toolkit einen Standardzugang und Standardschnittstellen.
17.2.3 Aufbau
Das Globus Toolkit ist eine Implementierung verschiedener Standards:
Open Grid Services Architecture (OGSA)
Open Grid Services Infrastrucure (OGSI)
Web Services Resource Framework
SOAP und WSDL
WS-Management und WS-BaseNotication
Job Submission Description Language
Distributed Resource Management Application API
Die OGSA ist eine Architektur f ur serviceorientierte Grid Computing Umgebungen
und wurde von der OGF, dem Open Grid Forum, entwickelt. Diese Architektur
basiert wiederum auch auf verschiedenen Techniken von Webservices wie WSDL
oder SOAP. Die OGSI bietet eine Infrastruktur f ur die Open Grid Service Ar-
chitektur. Das Toolkit nutzt Implementierungen der folgender Protokolle, welche
auch von der OGF deniert wurden, zur Sicherstellung folgender Services:
Security Services: Grid Security Infrastructure (GSI)
Resource Management: Grid Resource Allocation and Management Protocol
(GRAM)
Information Services: Monitoring and Discovery Services (MDS)
Data Movement and Management: Global Access to Secondary Storage
(GASS)
Die Abbildung 17.1 veranschaulicht den allgemeinen und vereinfachten Aufbau
des Toolkits durch die einzelnen Implementierungen der Protokolle. Hierbei gibt
es jedoch kleinere Unterschiede bei den einzelnen, verwendeten Protokollen in den
verschiedenen Versionen des Toolkits.
Security Services beziehungsweise die Grid Security Infrastructure (GSI) ba-
siert auf dem Prinzip der Private-Public-Key Verschl usselung. Der Public Key
Abbildung 17.1: vereinfachter Aufbau des Globus Toolkits
ermoglicht es jedem, Daten f ur den Inhaber des Private Key zu verschl usseln
oder dessen digitale Signaturen zu pr ufen. Der Private Key ermoglicht dem Besit-
zer, Daten welche mit dem Public Key verschl usselt wurden, zu entschl usseln,
sich zu authentizieren oder digitale Signaturen zu erzeugen. Es basiert auf
X.509-Zertikaten. Diese sind eine Art elektronische Umsetzung der Authenti-
zierung, Autorisierung und sind vergleichbar mit einem Personalausweis. Der
private Teile des Zertikats ist mit einem Passwort gesch utzt und mit dem Zerti-
kat kann man sich beim Ressourcen-Provider ausweisen. Durch den Einsatz von
Proxy-Zertikaten wird das bereits angesprochene Single-Sign-On und eine De-
legation von Aufgaben ermoglicht. Proxy-Zertikate haben in der Regel nur eine
G ultigkeitsdauer von 12 Stunden. Dadurch, dass hierbei keine Passworter uber
das Netz ubertragen werden, keine Passworter gespeichert werden m ussen und
die G ultigkeitsdauer nur begrenzt ist, bietet dieses Verfahren mehr Sicherheit. Der
Einsatz dieser Zertikate ist zudem einfach und bequem.
Resource Management, speziell der Grid Resource Allocation Manager (GRAM),
ist eine Software-Komponente des Globus Toolkits f ur das Lokalisieren,

Uber-
tragen,

Uberwachen und das Abbrechen von Jobs. Die Resource Specication
Language (RSL), ist eine XML basierte Job Beschreibungssprache und dient dazu
komplexe Jobs zu beschreiben. Zudem ist RSL notwendig um mehrere Jobs mit
einem Befehl auszuf uhren, parallele Jobs auszuf uhren und um das le staging zu
ermoglichen. Unter staging versteht man das Kopieren von Daten auf eine Res-
source. Es ist damit eine serielle sowie parallele Abarbeitung der Jobs moglich.
GRAM bietet Schnittstellen zu allen gangigen Batchsystemen. Man unterschei-
det hierbei zwei Arten von Jobs. Einmal den interaktiven Job. Hierbei ist man
durchgangig mit der Rechenressource verbunden und die Ausgabe erfolgt auf ei-
nem lokalen Bildschirm. Zum anderen gibt es den Batchjob. Hierbei wird das
Programm auf einer Rechenressource ausgef uhrt und die Ausgabe erfolgt in Form
einer Datei. Dabei ist keine Interaktion moglich.
Information Services beziehungsweise Monitoring and Discovery Services sind eine
Suite von Web-Services. Diese beinhalten Komponenten zur

Uberwachung und
Anzeige von Ressourcen in einer virtuellen Organisation. Das Globus Toolkit in
der Version 4 enthalt noch eine non-Web-Service-Version des Monitoring and
Discovery Services. Diese ist jedoch in der Version 5 nicht mehr enthalten. Die
folgende Grak zeigt das GUI eines solchen

Uberwachungstool. Fehlerhafte Jobs
sind markiert.
Abbildung 17.2: Monitoring and Discovery Services
Das Data Movement und Management bedient sich an verschiedenen Mechanis-
men. Das GridFTP, dem Reliable File Transfer (RLT), dem Replication Location
Service (RLS) und dem Data Replication Service (DRS).
GridFTP ist eine FTP-Erweiterung. Hierbei sind mehrere parallele TCP-Kanale
moglich die der Sender bestimmt und onet. Im Grid-Umfeld spielt NAT keine
groe Rolle. Durch Vereinfachung wird die Methode robust in Bezug auf Verlus-
te. Um eine Beschleunigung des Datentransfers zu ermoglichen, konnen Striped
GridFTP-Server eingesetzt werden. Hierbei transferieren mehrere Knoten aus dem
Rechnerverbund parallel Daten. GridFTP ist ein sicheres, zuverlassiges, perfor-
mantes Protokoll und speziell f ur groe Datenmengen optimiert.
17.3 Bedienung und Eingabebefehle
Die Eingabe beim Globus Toolkit erfolgt auf der Kommandozeile in einer
herkommlichen Konsole. Hierbei gibt es zahlreiche Eingabebefehle und im Fol-
genden sollen einige grundlegende Befehle vorgestellt werden.
Das Globus Toolkit greift auf ein Benutzerverzeichnis /.globus zur uck und dieses
muss als erstes erzeugt werden und die AFS-Rechte m ussen gesetzt werden:
/bin/bash
mkdir ~/.globus
fs sa ~/.globus whoami all -clear
chmod 700 ~/.globus
exit
Listing 17.1: Benutzerverzeichnis anlegen
Um das Toolkit nutzen zu konnen, m ussen das Zertikat und der private
Schl ussel exportiert werden. Die Datei wird beispielsweise als DFNcerticate.p12
in /.globus/ abgelegt. Danach m ussen der private Schl ussel und das Zertikat
getrennt werden: Um eine Verbindung zu einem Grid, hier am Beispiel eines kti-
ven Grids der FH-Schmalkalden gridway.dgrid.fh-sm.de aufzubauen, ist folgender
Befehl notwendig. Hierbei wird in Analogie zu ssh gsissh auf Port 2222 verwendet:
grid-proxy-init
gsissh -p 2222 gridway.dgrid.fh-sm.de
Listing 17.2: Auf Grid zugreifen
Um eine Datei zu kopieren, kann gsiscp verwendet werden. Um eine Portangabe
zu machen, wird das Flag -P verwendet:
gsiscp -P 2222 myfile gridway.dgrid.fh-sm.de
Listing 17.3: Datei kopieren
Nach dem Beenden der gsissh-Verbindung, muss der Proxy wieder geloscht wer-
den. Dies geschieht mit folgendem Befehl:
grid-proxy-destroy
Listing 17.4: Proxy loschen
Um beispielsweise einen Knoten mit 8 Prozessoren f ur eine maximale Rechenzeit
von einer Stunde zu reservieren ist folgender Befehl notwendig:
17.3 Bedienung und Eingabebefehle 213
qsub -I -l nodes=1:ppn=8:bwgrid,walltime=1:00:00
Listing 17.5: Knoten reservieren
Job wird in eine Warteschlange eingereiht und danach abgearbeitet:
qsub -l nodes=2:bwgrid:ppn=2+1:bwgrid:ppn=3 ./myscript
Listing 17.6: Job in Warteschlange stellen
Der Befehl globusrun-ws ist ein ozieller Job-Eingabe-Client f ur GRAM4 und
kann mit verschiedenen Befehlen kombiniert werden. Er dient dazu Jobs einzu-
geben und zu managen. Der Befehl um einen Job abzusenden oder zustellen zu
konnen, sieht am Beispiel von date wie folgt aus:
globusrun-ws -submit -c /bin/date
Listing 17.7: Job absenden oder zustellen
Mit der Erweiterung -F wird der Host speziziert:
globusrun-ws -submit -F mb.fh-schmalkalden.de -c grid1
Listing 17.8: Den Host spezizieren
Mit der Option -s wird der Streaming-Modus aktiviert und die Ausgabe erfolgt
auf dem lokalen Bildschirm:
globusrun-ws -submit -s -c /bin/date
Listing 17.9: Streaming Modus aktivieren
Mit der Erweiterung -b wird der Job im Batchmodus abgesetzt:
globusrun-ws -submit -b -c /bin/date
Listing 17.10: Job im Batchmodus
Das Toolkit ist sehr komplex und erfordert einges an Fachkenntnissen. Es wird
jedoch gut strukturierte Dokumentation, sowohl f ur Systemadministratoren als
auch f ur Endanwender, f ur den Umgang mit dem Toolkit angeboten [3].
17.4 Fazit
Beim Globus Toolkit erfolgt eine zertikatbasierte Authentizierung und Auto-
risierung, welche f ur mehr Sicherheit sorgt, so dass Angrie von auen weniger
haug erfolgreich sind. Durch den Einsatz von Zertikaten wird mehr Sicherheit
gewahrleistet und der Einsatz ist einfacher und bequemer. Das Toolkit bietet
Schnittstellen f ur alle gangigen Batchsysteme. Zudem ermoglicht es Single-Sign-
On. Das Toolkit bietet letztendlich einen sicheren, zuverlassigen und performan-
ten Datentransfer. Es stellt sehr leistungsfahige Hilfsmittel bereit. Zudem werden
f ur den Einsatz gute bis sehr gute Programmierkenntnisse und der sichere Um-
gang mit Linux vorausgesetzt, da das Windows-Betriebssystem nicht unterst utzt
wird. Gute Grundkenntnisse auf diesen Gebieten sind schon f ur das Einrichten
des Toolkits erforderlich. Das Toolkit dient zur Losung von rechenintensiven, ma-
thematischen und naturwissenschaftlichen Problemen in Gebieten der Teilchen-
physik, Meteorologie oder Industriesimulationen und der Einsatz f ur den privaten
Gebrauch ist daher eher ungeeignet.
[1] The gridbus project, Grid Computing. http://www.gridcomputing.com/,
2010.
[2] Globus Alliance, About the Globus Toolkit.
http://www.globus.org/toolkit/about.html, 2010.
[3] Globus Alliance, Commandline Tools. http://www.globus.org/toolkit/docs/
4.2/4.2.1/commands/, 2010.
[4] Globus Alliance, Globus Toolkit. http://www.globus.org/toolkit/, 2010.
18 Apache Hadoop
Thomas Hohn
Inhaltsverzeichnis
18.1 Das Apache Hadoop Framework . . . . . . . . . . . . . . 215
18.1.1 Was soll Hadoop ermoglichen? . . . . . . . . . . 216
18.2 Subprojekte des Hadoop-Frameworks . . . . . . . . . . . 216
18.2.1 Hadoop Common . . . . . . . . . . . . . . . . . 216
18.2.2 Hadoop MapReduce . . . . . . . . . . . . . . . . 216
18.2.3 Chukwa . . . . . . . . . . . . . . . . . . . . . . . 217
18.2.4 H-Base . . . . . . . . . . . . . . . . . . . . . . . 218
18.2.5 HDFS (Hadoop Distributed File System) . . . . . 218
18.2.6 AVRO . . . . . . . . . . . . . . . . . . . . . . . 219
18.2.7 ZooKeeper . . . . . . . . . . . . . . . . . . . . . 219
18.2.8 HIVE . . . . . . . . . . . . . . . . . . . . . . . . 219
18.2.9 Pig . . . . . . . . . . . . . . . . . . . . . . . . . 220
18.2.10 Mahout . . . . . . . . . . . . . . . . . . . . . . . 220
18.3 Einsatzgebiete des Apache Hadoop Frameworks . . . . . . 221
18.3.1 Facebook . . . . . . . . . . . . . . . . . . . . . . 222
18.3.2 Yahoo! . . . . . . . . . . . . . . . . . . . . . . . 223
18.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
18.1 Das Apache Hadoop Framework
Der Entwickler von Apache Lucene, Doug Cutting, startete im Jahr 2006 das Pro-
jekt Hadoop, dass zu diesem Zeitpunkt noch unter dem Namen Lucene-Subprojekt
bekannt war. Urspr unglich stammt Hadoop von Apache Nutch, einer Open Sour-
ce Web-Suchmaschine ab. Apache Nutch wird als ein Teil des Apache Lucene-
Projektes angesehen.
Im Jahre 2008 ernannte die Apache Software Foundation (ASF) das Hadoop-
Projekt zu einem Top-Level-Projekt. Kurz darauf wurde Hadoop schon von ver-
schiedenen Firmen, wie z.B. Yahoo!, Facebook und der New York Times, genutzt.
Im Juli 2009 gewann ein Cluster mit dem Hadoop-Framework zweimal den Tera-
byte Sort Benchmark, der in unterschiedlichen Kategorien die leistungsfahigsten
216 18 Apache Hadoop
Systeme zur Datensortierung bestimmte. Es war das erste Java-Open-Source-
Programm welches diesen Benchmark f ur sich entscheiden konnte.
18.1.1 Was soll Hadoop ermoglichen?
Das Apache Hadoop-Projekt entwickelt Open-Source-Software f ur sicheres, ska-
lierbares und verteiltes Arbeiten. Es dient als Plattform, die das Schreiben und
Ausf uhren von Anwendungen erleichtern soll. Dieses Framework soll in der Lage
sein, groe Datenmengen im Petabyte-Bereich verarbeiten zu konnen. Um dies
umsetzen zu konnen, wird Hadoop von einer Reihe Subprojekte, die z.B. Daten
speichern, analysieren oder verteilen konnen, unterst utzt. Im folgenden Abschnitt
werden alle Subprojekte des Apache Hadoop Frameworks naher betrachtet.
18.2 Subprojekte des Hadoop-Frameworks
Wie im Abschnitt 18.1 bereits angesprochen entwickelte Hadoop zehn Subprojek-
te, die zumeist mit einer Open-Source-Liznez genutzt werden konnen.
Die folgende

Ubersicht soll Aufschluss dar uber geben, f ur welchen Einsatzbereich
sich die einzelnen Subprojekte eignen und welche spezischen Eigenschaften sie
besitzen.
18.2.1 Hadoop Common
Common ist ein Hilfsmittel, das alle anderen Hadoop Subobjekte unterst utzt.
Es enthalt ein File-System, Serialization Libaries und RPC. Hadoop Common
verfolgt eine eigene Dokumentation, die n utzliche Informationen zur Handhabung,
Nutzung und Installation von Hadoop beinhaltet.
18.2.2 Hadoop MapReduce
Die Grundlage hierf ur wurde durch Google Inc. geschaen. Google f uhrte die-
sen Algorithmus ein, um nebenlauge Berechnungen von groen Datenmengen
auf Computerclustern durchzuf uhren. Hadoop MapReduce verfolgt genau diesen
Ansatz des verteilten Arbeitens. Es ist ein Programmiermodell und Software-
Framework zum Schreiben von Anwendungen, die es ermoglichen sollen eine
schnelle Verarbeitung groer Datenmengen parallel an groen Clustern von Rech-
nerknoten durchzuf uhren. Deren Implementierung kann durch C++, Erlang, Java,
Python und uber weitere Sprachen realisiert werden. Abbildung 18.1 soll verdeut-
lichen, wie Hadoop MapReduce in einem Unternehmen angewendet werden kann.
Der hier dargestellte Datenuss illustriert die MapReduce-Berechnung.
18.2 Subprojekte des Hadoop-Frameworks 217
Abbildung 18.1: Using Hadoop in the Enterprise (Quelle:[1])
Im Bereich 1
High Volume Data Flows benden sich die Eingabedaten, die

aus bestimmten Feldern zur Verf ugung gestellt werden. Dieses konnen bspw. Da-
ten aus der Industrie, Wissenschaft oder System-Daten sein. Die Eingabedaten
werden anschlieend im Bereich 2
MapReduce Processauf eine Reihe von Map-

Prozessen verteilt, welche jeweils die vom Nutzer bereitgestellte Map-Funktion be-
rechnen. Durch die parallele Ausf uhrung der Map-Prozesse ergibt sich der Vorteil
Zeit einzusparen. Jeder dieser Map-Instanzen ist in der Lage Zwischenergebnisse
abzulegen. Hierbei ieen von jeder Map-Instanz Daten in verschiedene Zwischen-
ergebnisspeicher. Sind alle Berechnungen abgeschlossen, ist die Durchf uhrung der
Map-Phase beendet und der

Ubergang zur Reduce-Phase wird ermoglicht. F ur je-
den Satz an Zwischenergebnissen berechnet nun jeweils genau ein Reduce-Prozess
die vom Nutzer bereitgestellte Reduce-Funktion und damit die Ausgabedaten.
Hierbei erfolgt die Durchf uhrung des Reduce-Prozesses parallel zu den anderen.
Anschlieend erfolgt ein Transfer der neu gewonnen Daten in den Bereich 3
Con-
sume Result. Diese Daten werden dann in einem Relationalen Datenbank Ma-
nagement System (RDBMS) abgespeichert. Von diesem Punkt aus konnen die
Daten f ur den Benutzer bereitgestellt werden. So konnen nun Analysen, Auswer-
tungen oder weitere Verwendung dieser Daten gewahrleistet werden.
18.2.3 Chukwa
Chukwa ist ein Sammelsystem f ur Dateien jeglicher Art. Um die bestmogliche
Nutzung der gesammelten Daten zu gewahrleisten, bietet Chukwa ein eigenes
Toolkit an, welches f ur Monitoring und genaue Analysen von Ergebnissen zur
Verf ugung steht. Seine Aufgabe besteht darin, verteilte Systeme zu uberwachen
und zu verwalten. Des Weiteren bildet es die Spitze von Hadoop Distributed File
System (HDFS) und MapReduce. In Hinblick auf die Skalierbarkeit und Robustheit
besitzt Chukwa die gleichen Eigenschaften wie Hadoop. Mit Chukwa ist es Hadoop
gelungen, ein gutes Open-Source Dateisammelsystem zu entwickeln.
18.2.4 H-Base
H-Base ist eine einfach skalierbare Datenbank die zur Verwaltung sehr groer
Datenmengen innerhalb eines Hadoop-Clusters dient. Hierbei bietet es sich als
kosteng unstiger Ansatz an, da es auch Open-Source ist. Die H-Base-Datenbank
basiert auf einer freien Implementierung der Google-Version BigTable. BigTable ist
ein proprietares Hochleistungs-Datenbanksystem das von Google zur Verf ugung
gestellt wird. Die Grundlage hierf ur wurde von Google File Systeme (GFS) und
Chubby Lock Service gelegt.
Die Datenstruktur von H-Base ist sehr gut f ur Daten geeignet, die selten
verandert, daf ur aber sehr haug erganzt werden. H-Base ist eine gute Losung,
um Milliarden von Zeilen verteilt und performant zu verwalten.
Es stellt geeignete Basisklassen f ur die Unterst utzung von Hadoop-MapReduce-
Jobs mit den so genannten H-Base-Tables bereit. Durch Optimierung von Real-
zeitabfragen konnen schnellere Prozesse erzeugt werden. Weiterhin enthalt es
RESTful Web Service Gateway der XML-, Protobuf- und binare Datenendkodie-
rung unterst utzt.
Die Random-Access-Performace ist hier auf der gleichen Ebene mit Open-Source
relationalen Datenbanken, wie MySQL, zu sehen. Ein weiterer wichtiger Punkt der
von H-Base verfolgt wird, ist der Export von Metriken uber die Hadoop Metrik
Subsysteme.
18.2.5 HDFS (Hadoop Distributed File System)
Als Vorbild f ur HDFS dient das Google File System (GFS). Aber was versteht man
eigentlich unter GFS? GFS ist ein auf Linux basiertes Dateisystem, das von Google
f ur seine Anwendungen genutzt wird. Das Haupteinsatzgebiet liegt im Bereich der
Internetsuch-Optimierung und soll einen hohen Datendurchsatz ermoglichen. Wie
folgt werden Daten in mehreren Gigabyte groen Dateien gespeichert, die gewisse
Bedingungen erf ullen m ussen. Bspw. d urfen diese Daten nur selten geandert oder
uberschrieben werden.
Nach diesem Vorbild arbeitet auch HDFS. Es wird von Hadoop als primares Spei-
chersystem eingesetzt. Hierbei erstellt es mehrere Kopien von Datenblocken und
verteilt diese auf Rechnerknoten in einem Custer was zuverlassig und extrem
schnelle Berechnungen zulasst.
18.2 Subprojekte des Hadoop-Frameworks 219
18.2.6 AVRO
AVRO ist ein Datei-Sterilisations-System welches auf bestimmte Schemata auf-
baut. Es bietet den Anwendern eine ubersichtliche Datenstruktur, wobei es auch
ein eigenes kompaktes, schnelles und binares Datenformat bereitstellt. Weiter-
hin konnen hier persistente Daten in einer Container-Datei gespeichert werden.
Im Umgang mit dynamischen Sprachen bietet sich AVRO an, da es eine leichte
Integration zulasst.
Im Vergleich zu anderen Systemen wird bei AVRO kein Code erzeugt, sondern uber
ein bestimmtes Schema konnen die Daten vollstandig verarbeitet werden. Wenn
ein Schema vorhanden ist, besteht die Moglichkeit, beim Lesen der Daten weniger
Typinformationen in den Daten zu codieren. Bei Anwendung eines Schemas sind
dennoch das alte und das neue Schema vorhanden. Dennoch bietet AVRO eine
Reihe gleicher Funktionen wie bei anderen Systemen, wie bspw. Sparsamkeit oder
Protokoll-Puer.
18.2.7 ZooKeeper
ZooKeeper ist ein High-Performance-Service, um verteilte Anwendungen koordi-
nieren zu konnen. Dieser Dienst ist zustandig f ur die Bereitstellung von Gruppen
Services, verteilter Synchronisierung und die Einhaltung von Kongurationsinfor-
mationen. Viele verteilte Anwendungen verwenden oder beinhalten diese Dienste
bereits. Dabei ist zu beachten, dass bei der Durchf uhrung solcher Dienste auch
gewisse Fehler auftreten konnen, die dann zu einem hoheren Verwaltungsauf-
wand f uhren. Die Losung dieser Fehler gestaltet sich schwierig. Auch bei richtiger
Anwendung dieser Dienste wird durch die verschiedenen Implementierungen eine
hohe Komplexitat erzeugt. Ziel von ZooKeeper ist es, eine einheitliche zentrale
Koordinationsstelle zu etablieren, in der alle Dienste vereint werden. Der Service
der einzelnen Dienste bleibt auch nach der Zentralisierung immer verteilt.
18.2.8 HIVE
HIVE bildet die Spitze des Hadoop-Frameworks in Form einer Data-Warehouse-
Infrastruktur. Es bietet eine Reihe unterst utzender Tools, die dazu genutzt werden
Analysen und Auswertungen von groen Datensets durchzuf uhren und in Hadoop-
Files zu speichern. Gleichzeitig soll es ermoglichen Daten komplexer Struktur
leichter zusammenzufassen. Um solche Prozesse durchf uhren und Daten struk-
turieren zu konnen, nutzt HIVE eine eigene Abfragesprache (HIVE QL), die auf
SQL basiert. HIVE QL bietet annahernd die gleichen Voraussetzungen wie SQL
und bietet so dem Nutzer ein leichteres Arbeiten, da die Einarbeitungszeit in diese
eigene Sprache gering ist.
Gleichzeitig ermoglicht HIVE QL MapReduce-Programmierern ihre selbst erzeug-
ten Mapper und Reducer zu besseren Analysen einzusetzen.
Weiterhin soll es eine gute Latenz f ur Test-Abfragen und interaktives Daten-
Browsing unterst utzen. Ein Nachteil der bei HIVE auftritt ist der Umgang mit
Echtzeit-Abfragen, da diese hier nicht unterst utzt werden.
Nat urlich uberwiegen dennoch die Vorteile dieser Software. Sie liegen im Bereich
der Skalierbarkeit, Fehlertoleranz und der Erweiterbarkeit.
HIVE wird derzeit schon von Facebook eingesetzt, um die Flut an Datenmengen,
die taglich neu erzeugt oder verwaltet werden m ussen, handhaben zu konnen.
Durch die solide Infrastruktur kann eine sichere Speicherung und das Abrufen von
Daten gewahrleistet werden.
18.2.9 Pig
Dieses Subprojekt verfolgt die Verwaltung und Analyse sehr groer Datenmengen.
Um dies realisieren zu konnen hat man in Pig eine eigene Programmiersprache
entwickelt, die es zulasst High-Level-Abfragen auf Daten durchzuf uhren. F ur die
Ausf uhrung ist ein Compiler von Noten, der von Pig bereitgestellt wird. Ein groer
Vorteil von Pig ist seine oene zugangliche Struktur und die Parallelisierung. Hier-
bei kann durch eine einfache Programmierung das parallele Ausf uhren komplexer
Analysen durchgef uhrt werden. Im Hinblick auf die Optimierung agiert Pig auto-
nom, da es komplexe Operationen selbst ausf uhren kann. Es ermoglicht so dem
Nutzer eine leichte Handhabung.
Ein weiterer Vorteil f ur den Nutzer besteht in der eigenen Programmiersprache
von Pig die es ermoglicht eigene Funktionen mit einem bestimmten Zweck f ur die
Verarbeitung von Daten zu generieren.
So erweist sich Pig als ein sehr individuell einsetzbares Tool, welches sich uber
einen groen Anwendungsbereich aufspannen lasst.
18.2.10 Mahout
Mahout ist eine kommerziell eingesetzte Software, welche das Ziel verfolgt, ska-
lierbare maschinelle Lern-Bibliotheken zu erzeugen. Es handelt sich hierbei wieder
um den Einsatz groer Datenmengen die skaliert werden m ussen.
Was wird aber unter dem Begri der Skalierbarkeit in Mahout verstanden? Be-
stimmte Kern-Algorithmen, die mit Hilfe von MapReduce Paradigmen umgesetzt
werden, werden f ur Klassikationen, Clustering und Batch-Based Collaborative
Filtering eingesetzt. Weiterhin gibt es noch die s.g. Kern-Bibliotheken, welche
sehr ausgereift und hoch optimiert sind. Diese bieten verteilten- als auch nicht
verteilten Algorithmen eine sehr gute und ausgewogene Leistung.
18.3 Einsatzgebiete des Apache Hadoop Frameworks 221
Ein weiterer wichtiger Punkt ist, dass Mahout zum aktuellen Zeitpunkt nur vier
Use Cases unterst utzt. Diese Use Cases teilen sich wie folgt auf:
1. Der Schwerpunkt leigt darauf, sich auf das Nutzerverhalten zu konzentrieren,
um bestimmte Begrie ausndig zu machen die der Nutzer bevorzugt.
2. Clustering versucht Dokumente nach bestimmten Themenbereichen zu ordnen
die jeweils eine eigene Gruppe bilden.
3. Klassizierung konzentriert sich auf die Zuordnung der vorhandenen, geord-
neten Dokumente zu speziellen Kategorien, wobei sie auch bei nicht gekenn-
zeichneten Dokumenten versuchen, eine richtige Kategorie zu nden.
4. Bei Gegenstanden die haug benutzt werden, wird versucht sie in einer geeig-
neten Gruppe von Gegenstanden zusammen zufassen. Hierf ur sind so genannte
Sessions oder
Warenkorbe in der Lage, Gegenstande die haug zusammen

verwendet werden, zu erkennen.
Bspw. setzt die Firma NAVTEQ Media Solution Hadoop Mahout bereits im Be-
reich Werbung im Bezug auf die Interaktion mit dem Benutzer ein.
NAVTEQ Media Solution ist nur eine von vielen Firmen die Apache Hadoop bzw.
die bereitgestellten Subprojekte nutzt. Der folgende Abschnitt soll Aufschluss uber
die Einsatzgebiete und die Verwendung von Apache Hadoop und seine Subpro-
jekten geben. Anhand zweier Beispiele, Facebook und Yahoo!, soll ein

Uberblick
gegeben werden wie Hadoop direkt im Unternehmen eingesetzt wird.
18.3 Einsatzgebiete des Apache Hadoop
Frameworks
Seit der Etablierung des Hadoop Frameworks haben viele Unternehmen und Sys-
teme die Vorteile von Hadoop erkannt und als Open-Source Framework f ur sich
gewonnen. Der aktuelle Stand zeigt, dass sich bis zum Jahre 2011 rund 110
Unternehmen und Systeme mit dem leistungsstarken Framework Hadoop ausein-
andergesetzt haben und auch im Alltag damit arbeiten. Bekannte Firmen wie
Amazon, Adobe, AOL, IBM, Joost, Twitter, Ebay, Facebook und Yahoo! setzen
Hadoop mit vollem Erfolg ein.
An den folgenden Beispielen Facebook und Yahoo! soll verdeutlicht werden wie
Hadoop und seine Subprojekte im Unternehmen eingesetzt und Projekte damit
umgesetzt werden konnen.
18.3.1 Facebook
Facebook ist eine der groten Social-Media-Communities die es momentan im
Internet gibt. Taglich werden hier mehrere Millionen von Daten neu erzeugt und
vorhandene verwaltet. Facebook hat in den vergangen Jahren einen enormen An-
stieg an Data-Warehouse-Cluster zu verzeichnen gehabt. Daher war Facebook
auf der Suche nach einem kosteng unstigen und schnellen Framework, das groe
Datenmengen zu verwalten wusste. Hadoop war wie geschaen f ur diese Anwen-
dungen. Nach aktuellem Stand, benden sich das Apache Hadoop Framework
in der Version 0.20 und die Subprojekte Apache Hive, Apache H-Base, Apache,
Thrif und eigenes Tool
Facebook Scribe bei Facebook im Einsatz.

Facebook setzt Hadoop in drei verschiedenen Systemen ein, um moglichst viel
von seinem Potential ausschopfen zu konnen. Die erste Variante ist die Funktion
Hadoop als Quelle f ur Webanalysen zu nutzen. Hierbei liegt der Schwerpunkt
auf dem Datendurchsatz und der Skalierbarkeit von Warehouse-Clustern. Dabei
verteilt Facebook seine Cluster auf verschiedene Rechenzentren. Die nachfolgende
Tabelle zeigt die Verteilung der Cluster in Facebook, wobei es insgesamt nur zwei
Cluster gibt.
Maschine-Cluster Cores PB-Rohspeicher
100 8800 12
300 2400 3
Jeder der hier eingesetzten Knoten besitzt 8 Kerne und maximal 12 TB Speicher-
kapazitat. Um die Datenmengen die durch diese Cluster stromen, umzusetzen zu
konnen, nutzt Facebook Hadoop und Hive. Dabei wird Hadoop eingesetzt um die
Speicherung von Kopien von internen Anmeldungen und von Datenquellen vorzu-
nehmen. Die neugewonnen Quellen bieten die Moglichkeit der Durchf uhrung von
Analysen und Berichtserstattung. Die zweite Variante ist der Einsatz als Speicher
einer verteilten Datenbank. Es handelt sich hierbei um eine Echtzeitanwendung,
wobei drauf abgezielt wird, die Warteizeiten moglichst klein zu halten und die
Antwortzeiten schneller zu realisieren. Dies kann durch den Einsatz der verteilten
Datenbank H-Base ermoglicht werden, da diese alle Dateien in Hadoop-Cluster
abspeichert. So kann ein schneller aber auch sicherer Zugri gewahrleistet wer-
den. Um Daten direkt in Hadoop-Cluster zu speichern, kommt zum Teil auch die
Software Scribe zum Einsatz.
Als dritte Variante nutzt Facebook eine eigene MySQL-Datenbank, um dort Back-
ups zu platzieren. Das ermoglicht es, schnelle Datensicherungen durchzuf uhren
und somit auch in das Hadoop Dateisystem abgespeicherte Daten schnell wieder-
herzustellen. Auch wenn Facebook Petabyte groe Datensatze archiviert, reduziert
es durch den Einsatz von Hadoop die Wartungs- und Entwicklungskosten enorm.
18.3 Einsatzgebiete des Apache Hadoop Frameworks 223
18.3.2 Yahoo!
Durch den massiven Anstieg an Datendurchsatz im Internet war auch Yahoo!
auf der Suche nach einem geeigneten Framework, um groe Datenmengen besser
verwalten und analysieren zu konnen.
Im Jahre 2008 etablierte Yahoo! das Open-Source-Framework Apache Hadoop in
seinem Unternehmen. Aktuell arbeiten sie mit der Version 0.20 die auch schon
von Facebook eingesetzt wird.
Einen groen Anwendungsbereich ndet hier Pig, HDFS und der MapReduce Al-
gorithmus. Ein schnelles, parallels und verteiltes Berechnen ermoglicht Yahoo!,
sehr prazise und zeitnahe Antworten zu liefern. Vorteilhaft ist dies f ur die Yahoo!
Suchmaschine. Wobei Yahoo! durch die Yahoo! Search Webmap eine weitere
Optimierung der Suchmaschine bietet. Diese Webmap ist eine Anwendung von
Hadoop, um Daten zu generieren, die dann von Suchanfragen verwendet werden
konnen. Um diese Daten zu erzeugen, muss das Internet nach bestehenden Web-
seiten und deren Inhalt untersucht werden, um so viel wie moglich Informationen
zu sammeln, die dann bereitgestellt werden konnen.
Bestimmte Hardware-Grundlagen mussten so neu geschaen werden. Aktuell ver-
wendet man bei Yahoo! 36.000 Computer in denen mehr als 100.000 CPUs
laufen, um Hadoop auszuf uhren. Das grote Cluster welches geschaen wurde,
besitzt 4000 Knoten. Diese Menge an Hardware bietet eine gute Grundlage um
Hadoop-Jobs auszuf uhren.
Nat urlich legt Yahoo! ein groes Augenmerk auf die Sicherheit seiner Systeme.
So kam es, dass Hadoop und Kerberos fusionierten, so dass dabei ein neuer und
besserer Open-Source-Authentizierungs-Standard entwickelt wurde.
Aktuell verfolgt Yahoo! eine Reihe neuer Produktentwicklungen, die in naher Zu-
kunft zum Einsatz kommen sollen. Es handelt sich dabei zum einen um
Hadoop
with Security und zum anderen um
Oozie.
Hadoop with Security soll zu-

sammen mit Kerberos die Abwicklung geschaftlicher Prozesse bei Yahoo noch
sicherer machen. In dem
Hadoop with Security-Sicherheitspaket ist Oozie, ei-

ne Workow-Technik, schon mit integriert. Durch Oozie sollen sich Jobs auf der
Hadoop-Installation besser verwalten lassen konnen.
Insgesamt wird dieses Paket
Hadoop with Security groe Teile des Hadoop

Frameworks beinhalten, wie bspw. MapReduce, HDFS, Pig und nat urlich Oozie.
Zuk unftig wird Hadoop ein fester Bestandteil von Yahoo bleiben und zu einer
schnellen und sicheren Datenverwaltung und Bearbeitung beitragen.
18.4 Fazit
Wie man aus dem Abschnitt 18.3 entnehmen konnte wird das Open-Source-
Framework
Apache Hadoop bereits in einem groen Umfang eingesetzt.

Zuk unftig wird es immer wichtiger werden, groe Datenmengen sicher verwalten
zu konnen. Daher bietet Hadoop in Verbindung mit seinen Subprojekten einen
guten Losungsansatz dies umzusetzen.
Nicht nur f ur groe Unternehmen sondern auch f ur kleine Projekte lohnt es sich
Hadoop zu nutzen. Dieses Framework, was derzeit schon gut etabliert ist, wird
in Zukunft noch mehr an Bedeutung gewinnen, da der rapide Zuwachs an Daten
nicht zu stoppen ist und immer mehr Daten analysiert und verwaltet werden
m ussen.
[1] http://www.ebizq.net/blogs/enterprise/images/mapreduce hadoop.png,
26.12.2010.
[2] Hadoop The Denitive Guide, Tom White, 2010.
[3] http://hadoop.apache.org, The Apache Software Foundation.
[4] http://hadoop.apache.org/common, The Apache Software Foundation.
[5] http://hadoop.apache.org/hdfs, The Apache Software Foundation.
[6] http://hadoop.apache.org/mapreduce, The Apache Software Foundation.
[7] http://avro.apache.org/docs/current, The Apache Software Foundation.
[8] http://incubator.apache.org/chukwa, The Apache Software Foundation.
[9] http://hbase.apache.org, The Apache Software Foundation.
[10] http://mahout.apache.org, The Apache Software Foundation.
[11] http://pig.apache.org, The Apache Software Foundation.
[12] http://wiki.apache.org/hadoop/ZooKeeper, The Apache Software Founda-
tion.
[13] http://wiki.apache.org/hadoop/PoweredBy, 14.12.2010.
[14] http://wiki.apache.org/hadoop/PoweredBy#F, 14.12.2010.
[15] http://wiki.apache.org/hadoop/PoweredBy#Y, 14.12.2010.
[16] http://www.heise.de/developer/artikel/Verarbeiten-grosser-verteilter-Da-
tenmengen-mit-Hadoop-964755.html, Oliver Fischer, 01.04.2010, 27.11.2010.
[17] http://www.facebook.com/note.php?note id=468211193919,
Dhruba Borthakur, 10.12.2010, 14.12.2010.
[18] http://www.heise.de/open/meldung/Apache-Hadoop-goes-Enterprise-
1031060.html, 30.06.20100, 14.12.2010.
[19] http://www.heise.de/open/meldung/Hadoop-Distribution-von-Yahoo-
180906.html, 12.06.09, 14.12.2010.
19 Monitoring Distributed
Real-Time Systems
Maik Heller
Inhaltsverzeichnis
19.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . 228
19.2 Begrisdenitionen und Grundlagen . . . . . . . . . . . . 228
19.2.1 Echtzeitsysteme . . . . . . . . . . . . . . . . . . 228
19.2.2 Verteilte Echtzeitsysteme . . . . . . . . . . . . . 229
19.2.3 Konzepte f ur fehlertolerante Systeme . . . . . . . 230
19.3 Monitore: Einf uhrung und Forschungsstand . . . . . . . . 231
19.3.1 Forschungsstand des Monitoring . . . . . . . . . 231
19.3.2 Monitoring and Checking (MaC) Framework . . . 232
19.4 Monitor-Architekturen f ur verteilte, harte Echtzeitsysteme 233
19.4.1 Monitore in einem verteilten Echtzeitsystem . . . 234
19.4.2 Hard- und Softwareunterscheidung . . . . . . . . 234
19.4.3 Anforderungen an Monitor-Architekturen . . . . . 235
19.4.4 Vorstellen potentieller Monitor-Architekturen . . . 235
19.5 Was ein Monitor uberwacht . . . . . . . . . . . . . . . . 238
19.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Laufzeit-Monitore (Runtime Monitors) sind ein aktuelles und vieldiskutiertes The-
ma in der Forschung. Sie werden als eine Moglichkeit gesehen, die Zuverlassigkeit
von sicherheitskritischen Systemen zu erhohen. Insbesondere das Unternehmen
Galois Inc. (USA) hat sich zum Ziel gesetzt hat, Ideen der Forschung in reale
Technologien umzusetzen. Als Grundlage der folgenden Ausarbeitung dient ein
Artikel der Galois Inc., welcher Ansatze und Losungsmoglichkeiten f ur sicher-
heitskritische Systeme der NASA Raum- und Luftfahrt diskutiert. Hierbei stehen
besonders Monitor-Konzepte f ur harte, verteilte Echtzeitsysteme im Fokus der
Untersuchung [1].
228 19 Monitoring Distributed Real-Time Systems
19.1 Problemstellung
Die Anforderungen an die Programmierung von Software f ur sicherheitskriti-
sche Systeme nehmen stetig zu. Sicherheitskritische Systeme (Abk.: SkS) nden
zunachst ihre Anwendung in einer Umgebung, in dem Fehlverhalten von Syste-
men das Leben von Menschen gefahrdet, wie z.B. in der Luftfahrt, atomaren
Energieerzeugung oder Medizin.
Wahrend in der Vergangenheit die Entwicklung von monolithischer, homogener
Software in Bezug auf Fehlerfreiheit und Komplexitat einfacher war, m ussen sich in
verteilten Systemen Teilkomponenten die Hardwareressourcen und Verbindungs-
kanale teilen. Hinzu kommt, dass die einzelnen Komponenten eines verteilten
Systems, wie z.B. die GPS-Sensoren eines Flugzeugs, Daten in Echtzeit bereitstel-
len m ussen, da sie f ur die fehlerfreie Funktion des gesamten Systems (Flugzeug)
relevant sind.
Wahrend der Entwicklung und Verikation von Software konnen Fehler niemals
hundertprozentig ausgeschlossen werden, dennoch muss eine hochstmogliche Feh-
lerfreiheit im spateren Betrieb garantiert werden. Einen Ansatz, die Zuverlassigkeit
von SkS zu erhohen, bietet die Laufzeit uberwachung von Software durch Kontroll-
systeme, welche als Monitore (runtime monitors) bezeichnet werden.
In diesem Kapitel sollen folgende Fragen diskutiert werden:
Konnen Monitore insbesondere verteilte harte Echtzeitsysteme zuverlassiger ma-
chen? Wie ist der bisherige Stand der Forschung? Wie sehen potentielle Archi-
tekturen f ur Monitore aus und welche Anforderungen m ussen diese erf ullen?
19.2 Begrisdenitionen und Grundlagen
Um die Funktionsweise und den Forschungsstand von Monitoren darzustellen,
bedarf es zunachst einer Begriserklarung der relevanten Systeme. Dazu sollen
nachfolgend Echtzeitsysteme und grundlegende Konzepte f ur fehlertolerante Sys-
teme vorgestellt werden.
19.2.1 Echtzeitsysteme
Ein Echtzeitsystem (Real-Time-System) ist ein beliebiges System, bei welchem
die Zeit, zu der ein Output als Reaktion auf einen Input erfolgt, von Bedeutung
ist. Die Realisierung eines Echtzeitsystems ist unterschiedlich.
Wahrend Echtzeit lediglich das Ein- und Ausgangsverhalten eines Systems be-
schreibt, kann die Umsetzung eines Systems durch z.B. ein einfaches EDV-System
mit Software geschehen. F ur Echtzeitsysteme kommen in der Regel aber spezielle
19.2 Begrisdenitionen und Grundlagen 229
Hardwarearchitekturen (Embedded Systems) mit angepassten Betriebssystemen
zum Einsatz, welche f ur ihren Verwendungszweck optimiert wurden, wie z.B. Rou-
ter aus der Netzwerktechnik.
Abbildung 19.1: Zeitabhangigkeit von Echtzeitsystemen[2]
In Echtzeitsystemen erfolgt auf Grund unterschiedlicher Anforderungen eine Un-
terscheidung bez uglich des einzuhaltenden Zeitintervalls (siehe Abbildung 17.1).
So gilt f ur harte- und weiche Echtzeitsysteme zwar die Pramisse, ein korrektes
Ergebnis zu liefern, dennoch ist auch der Zeitpunkt der Bereitstellung des Out-
puts von Bedeutung. Hierbei m ussen bei sogenannten
harten Echtzeitsystemen
vorgegebene Antwortzeiten penibel eingehalten werden, wahrend bei
weichen
Echtzeitsystemen Informationen auch spater verarbeitet werden konnen.
Weiche Echtzeitsysteme (Soft Real-Time Systems)
Die Ergebnisse von weichen Echtzeittasks sind nach der Deadline weiterhin von
Nutzen und f uhren nicht zum Scheitern des Systems. Als Beispiel ware ein Vi-
deostream zu nennen, welcher durch Performanceeinbr uche des Servers Bildfehler
liefert, aber dennoch nicht abbricht.
Harte Echtzeitsysteme (Hard Real-Time Systems)
Bei harten Echtzeitsystemen f uhrt eine

Uberschreitung der Antwortzeit zu kriti-
schem Fehlverhalten im System. Besonders in sicherheitskritischen Systemen wie
Reaktoren oder Shuttles konnen nicht ubermittelte Warnungen bei

Uberhitzungen
Leben gefahrden.
Besteht ein Echtzeitsystem aus mindestens einem harten Task, so ist es als ein
hartes Echtzeitsystem zu klassizieren, da andere Prozesse von dem rechtzeitigen
Ergebnis abhangig sind.
19.2.2 Verteilte Echtzeitsysteme
In einem verteilten Echtzeitsystem besteht das Berechnungs-Cluster aus meh-

reren Echtzeitsystemen (Knoten), die uber ein Echtzeit-Kommunikationssystem
verbunden sind [3].
Abbildung 19.2: Kommunikation uber verteilte Echtzeitsysteme[3]
Ein Beispiel f ur ein verteiltes Echtzeitsysteme (Distributed Real-Time System) ist
die Steuerungseinheit eines Flugzeuges. Dieses kommuniziert mit anderen Kompo-
nenten uber einen Bus in Echtzeit. Die Knoten sind Komponenten wie Sensoren,
welche Daten zur Steuereinheit senden. Dies erfordert auch Echtzeitverhalten des
Kommunikationssystems.
19.2.3 Konzepte f ur fehlertolerante Systeme
In einem verteilten Echtzeitsystem konnen Fehler in der Kommunikation auftreten,
z.B. durch den Verlust einer Nachricht oder eine fehlerhafte Nachricht. Dies kann
zum Ausfall des Knotens, oder, im Worst-Case, zu einem Ausfall des gesamten
Systems f uhren. Sicherheitskritische Systeme werden deshalb fehlertolerant kon-
zipiert, damit ein Hard- oder Softwarefehler nicht zum Totalausfall des Systems
f uhrt. Im Folgenden sollen drei Konzepte f ur fehlertolerante Systeme vorgestellt
werden, auf welchen die weiter unten erlauterten Monitoring-Ansatze aufbauen.
Fault-Containment Region (FCR): Das Prinzip von FCRs funktioniert auf
Hardwareebene.

Auert ein Knoten Fehlverhalten, soll sich dies nicht uber sei-
nen Eindammungsbereich auf das gesamte System ausbreiten. Die physikali-
sche Trennung der gesch utzten Bereiche ist jedoch praktisch nicht vollstandig
umsetzbar. So kommunizieren Knoten in einem verteilten System weiterhin
uber gemeinsame Kanale. Auch kann elektromagnetische Strahlung das Kon-
zept der FCR aushebeln.
Hybrid fault model (HFM): Das HFM ist ein Modell zur strukturierten
Sammlung von Informationen, Problemen und Konsequenzen eines Systems.
Hierbei sollen fehlerhafte Knoten anhand von versendeten Nachrichten von an-
deren Knoten eingestuft werden. Ein Knoten ist hierbei gutartig, wenn seine
Nachrichten fehlerfrei war. Dies kann z.B. durch einen CRC-Check festgestellt
werden. Weiterhin wird ein Knoten nach seinem Sendeverhalten eingestuft.
Ein Knoten ist symmetrisch, wenn er die gleiche, korrekte Nachricht zu jedem
19.3 Monitore: Einf uhrung und Forschungsstand 231
anderen Knoten sendet. Asymmetrische Knoten schicken dagegen fehlerhafte
Nachrichten zu unterschiedlichen Empfangern.
Maximal fault assumption (MFA): Das MFA ist ein statistisches Modell,
welches die maximale Art, Anzahl und Empfangsrate von Fehlern f ur jeden
FCR, unter denen das System funktionieren soll, verarbeitet. Hierbei werden
z.B. Faktoren wie die Zuverlassigkeit der Hardware oder der Umwelt erfasst.
Problematisch hierbei ist die korrekte und umfassende Bewertung aller Fak-
toren. F ur den Flugverkehr gilt z.B. die errechnete Vorgabe von 10
9
Fehlern
pro Betriebsstunde, welche f ur den korrekten Betrieb eingehalten muss.
19.3 Monitore: Einf uhrung und Forschungsstand
Fehlertolerante Konzepte in sicherheitskritischen Systemen konnen scheitern. Sei
es durch eine fehlerhafte Programmierung, auere Ein usse oder an Mangeln,
wie in den oben vorgestellten Konzepten. Greifen keine Sicherheitsmechanismen
in einem System, konnte dies durch Monitore korrigiert werden.
Ein Monitor beobachtet das Verhalten eines Systems und erkennt, wenn es im
Einklang mit einer bestimmten Spezikation ist [1].
Das uberwachte System (System Under Observation, SUO) kann ein Programm,
Hardware, Netzwerk oder jede Kombination untereinander sein. Verletzt beispiels-
weise das SUO eine Spezikation, gibt der Monitor eine Warnung aus, worauf das
System reagieren kann.
In der Vergangenheit lag der Fokus der Forschung bei Monitoren auf Oine
monitoring. Dabei erfolgt die Datensammlung und Analyse nicht dynamisch, d.h.
Daten konnen nicht im laufenden Betrieb des Systems verwendet werden. Fehler
werden dagegen protokolliert und dienen nach ihrer Analyse zur Fehlerdiagnose
und Verbesserung des Systems.
19.3.1 Forschungsstand des Monitoring
Online-Monitoring dagegen ist aktueller Forschungsgegenstand. Ein Programm
wird hierbei kontinuierlich auf die Einhaltung seiner Spezikationen gepr uft. Mo-
nitore tragen hierbei im laufenden Betrieb zur Stabilitat des Systems bei. Jedoch
erfordert Online-Monitoring hohe Ressourcen und kommt deshalb uberwiegend in
der Praxis nur beim Testen von Software zum Einsatz.
Die Implementierung von Online-Monitoring kann entweder inline oder outli-
ne erfolgen. Bei der inline-Umsetzung eines Monitors wird dieser ahnlich eines
Kommentars innerhalb des Programmcodes platziert. Bei dem Anna Consistency
Checking System (Anna CCS) werden z.B. aus Kommentaren mit Eigenschaften
Funktionen generiert, welche an dieser Stelle als Monitor arbeiten. Sogar ab Ja-
va 5 sind grundlegende Behauptungen im Code moglich. Eine andere Moglichkeit
einen Monitor zu implementieren ist auerhalb (outline) des Programmcodes. Der
Monitor wir hierbei als eigener Prozess gestartet. Auch eine Kombination von out-
und inline Implementierung moglich.
Online-Monitore teilen unabhangig von ihrer Implementierung Ressourcen mit
dem beobachteten System. So stellt sich als Forschungsherausforderung an
Online-Monitoring u.a. die Frage nach ihrer Ezienz. Die Aufgabe von Moni-
toren ist das Synthetisieren von Verhaltensspezizierungen hoherer Ebenen. Dies
kann ezient durch z.B. Linear Temporal Logic (LTL) (zeitabhangige Logik)
geschehen, welches das Generieren von Sicherheitseigenschaften aus Aussagen
ermoglicht. Eine zeitabhangige Aussage ware z.B. Es kann niemals was schlim-
mes passieren. Mit Hilfe von zeitlichen Modalitaten konnen Formeln uber die
Zukunft von Pfaden aufgestellt werden. Durch Operatoren wird hierbei zum Aus-
druck gebracht, ob ein Modell die Sicherheitseigenschaften erf ullt und wann nicht
mehr. Als Modell ware hier EAGLE zu nennen, welches beim NASA Mars Rover
zum Einsatz kommt.
Ein Groteil der Forschung des Monitoring basiert auf einheitlicher, monolithischer
Software. In der Monitoring-Forschung wurde verteilten Systemen bisher wenig
Beachtung gewidmet. Es gibt dennoch interessante Ansatze:
Der zentrale Monitoring-Ansatz f ur lokale Eigenschaften von Bauer erfordert
nur einen Verweis eines Programms auf einen lokalen Knoten. Jeder Knoten
uberpr uft sicherheitstechnische Eigenschaften und sendet einen Bericht an die
zentrale Diagnose-Engine. Der zentrale Monitor versucht den Ursprung des Pro-
blems zu diagnostizieren und in einen sicheren Zustand zu lenken. Der Ansatz
von Bhargavon zielt auf die

Uberwachung von verteilten Netzwerkprotokollen,
wie TCP, ab. Hierbei haben sogenannte Black-Box-Monitore keine Kenntnis des
internen Zustands. Sie zeigen den Trac, mimen Protokollaktivitaten als Reaktion
des uberwachten Inputs nach und vergleichen den Output im Netzwerk.
Die Network Event Recognition Language (NERL) wird hierbei verwendet, um
die Spezizierungen der zu uberwachenden Netzwerkereignisse zu denieren. Mit
einem spezialisierten Compiler wird dazu eine Zustandsmaschine generiert, welche
die Ereignisse uberwacht.
19.3.2 Monitoring and Checking (MaC) Framework
Im Folgenden soll das MaC-Framework vorgestellt werden, welches ein hochentwi-
ckeltes Monitoring-Framework ist. Das MaC-Framework adressiert weiche, nicht
verteilte Echtzeitanwendungen, welche in Java geschrieben wurden. Das Beson-
dere am Framework ist, dass die Integration und Monitor-Zustandigkeiten in ver-
schiedenen Tasks erfolgt. Die Implementierung kann out- oder inline erfolgen, bei
komplexen Projekten sollte der Monitor jedoch auerhalb des Programmcodes
platziert werden.
Die Sicherheitsspezizierungen werden in der Meta Event Denition Language
(MEDL) deniert, eine zeitliche Satzlogik von Ereignissen und Bedingungen. Die-
se wird uber einen Pfad von Beobachtungen interpretiert. Die Primitive Event
Denition Language (PEDL) deniert die Ereignisse und ist zustandig f ur das
Mapping von Spezikationen. Der PEDL-Compiler setzt den Input aus Java-
Implementierung und PEDL-Spezizierung um. Daraus entstehen zwei Produkte.
Der Filter wird als Code eingesetzt und beobachtet die Monitor-Objekte. Der
Event Recognizer verarbeitet die geschickten Ereignisse und uberpr uft, ob diese
uberwacht werden. Der MEDL-Compiler arbeitet auf der anderen Seite als Ve-
rier und uberpr uft ob der Event Recognizer die MEDL-Spezizierungen einhalt.
Durch die Aufgabentrennung ist eine hohe Sicherheit bei der Ausf uhrung gegeben.
Abbildung 19.3: Monitoring and Checking (MaC) Framework[1]
19.4 Monitor-Architekturen f ur verteilte, harte
Echtzeitsysteme
Mochte man Monitore f ur verteilte Echtzeitsysteme entwerfen, so ist hierbei kein
neuer Theorieansatz notwendig. Galois [1] argumentiert, dass das Subsumieren
von aktuellen, theoretischen Erkenntnissen hierbei ausreichend f ur den Entwurf
von

Uberwachungssystemen ist. Monitore sind nach dieser Argumentation Pro-
zesse, welche sich nicht von anderen in einem System unterscheiden.
19.4.1 Monitore in einem verteilten Echtzeitsystem
Uberwachende Prozesse sammeln in einem verteilten System demnach Informa-

tionen wie jeder andere Prozess, haben in der Regel aber mehr Privilegien. Diese
konnen z.B. eine genauere physikalische Uhr zur Synchronisation von Prozessen
oder direkte Kommunikationskanale zu jedem Knoten sein. Jedoch stellt dies kein
Alleinstellungsmerkmal eines Monitors dar, da diese Privilegien prinzipiell auch
andere Knoten bekommen konnen.
Folgt man der Argumentation, dass Monitore in einem verteilten System sich nicht
von anderen Prozessen unterscheiden, so gilt auch die theoretische Begrenztheit
eines Systems f ur Monitore. Verteilte Systeme haben insbesondere Grenzen bei
der Fehlertoleranz und Synchronisation. Monitore konnen diesen Grenzen unterlie-
gen. Eine Problematik ist hierbei, dass Monitore nicht selbst zu einer Fehlerquelle
werden. Wird z.B. ein guter Vorgang in einem uberwachten System als Fehler
eingestuft, sendet der Monitor kontinuierlich Fehlermeldungen und wird zu einem
babbling (plappernden) - Monitor. Aus diesem Aspekt ergibt sich die Notwen-
digkeit von Monitor-Architekturen, welche spater vorgestellt werden.
Die Synchronisation kann in verteilten System entweder nach Reihenfolge der
Ereignisse erfolgen (logical clock synchronisation) oder in kleinen Zeitfenstern,
mit Hilfe von physikalischen Uhren (wall-clock-time). Erfordern Echtzeitsysteme
synchronisierte Knoten mit realer Zeit, so kann es hierbei zum asymmetrischen
(byzantinischen) Fehler kommen. Der byzantinische Fehler ist ein Problem der
Ubereinkunft der verschiedenen Knoten in einem verteilten System mit physi-

kalischen Uhren. Konnte die Deadline zur Synchronisation der Uhrzeiten eines
Knotens nicht eingehalten werden, so kommuniziert dieser mit anderen Knoten
zwar protokollkonforme Nachrichten, aber liefert andere Ergebnisse. Dies f uhrt
zu einer erhohten Kommunikation der anderen Knoten untereinander, bis jeder
Knoten schlielich mehrere Ergebnisse je nach Knotenuhrzeit liefert. Unter der
Kommunikationslast und der fehlenden

Ubereinkunft von Knoten, kann das Sys-
tem zusammenbrechen.
19.4.2 Hard- und Softwareunterscheidung
In den vorhergehenden Abschnitten wurden Softwareansatze f ur Monitore vorge-
stellt und das Problem aufgezeigt, dass Monitore den gleichen Grenzen unterlie-
gen wie andere Prozesse im System. Eine Unterscheidung der Monitor-Ansatze
in Hard und Softwarelosungen ist f ur Echtzeitsysteme jedoch weniger n utzlich,
sowohl aus Echtzeit-, als auch fehlertoleranten Aspekten heraus. Grund daf ur ist,
dass Echtzeitsysteme auf das Zusammenspiel von Hard- und Software angewie-
sen sind. Eine isolierte Einzelfallbetrachtung eines Monitors nur auf die Software,
konnte z.B. einen Fehler in der Hardware f ur seinen Zustandigkeitsbereich falsch
interpretieren, da er ja nur f ur die Softwareumgebung zustandig ist. Das vorge-
stellte MFA-Konzept f ur fehlertolerante Systeme w urde z.B. nur mit einem ganz-
heitlichen Monitor funktionieren, da hier statistische Fehlerfaktoren aus Hardware
und Software ber ucksichtigt werden.
19.4.3 Anforderungen an Monitor-Architekturen
Eine Monitor-Architektur ist die Integration von einem oder mehreren Monitoren
in das zu uberwachende System (SUO - System Under Observation). Die Ar-
chitektur schliet dabei die ganze Hardware und ihre Verbindungen ein, welche
erforderlich sind, damit ein Monitor seine Funktion erf ullen kann.
Im Folgenden sollen Anforderungen vorgestellt werden, die Monitor-Architekturen
erf ullen m ussen:
1. Funktionalitat:
Der Monitor verandert die Funktionalitat eines SUO nicht, bis das SUO seine
Spezikationen verletzt.
2. Planbarkeit:
Die Monitor-Architektur veranlasst das SUO nicht, seine harten Echtzeitga-
rantien zu verletzen, es sei denn, dass das SUO seine Spezizierung verletzt.
3. Zuverlassigkeit:
Die Zuverlassigkeit des SUO im Rahmen der Monitor-Architektur ist groer
oder gleich der Zuverlassigkeit des SUO alleine.
4. Zertizierbarkeit:
Die Monitor-Architektur erfordert keine ubermaigen

Anderungen am Quell-
code oder Objektcode der SUO.
19.4.4 Vorstellen potentieller Monitor-Architekturen
Im folgenden Kapitel sollen drei abstrakte Monitor-Architekturen vorgestellt wer-
den, welche die im vorhergehenden Kapitel gestellten Anforderungen erf ullen. Die
Architekturen haben dabei konzeptionellen Charakter, d.h. sie wurden noch nicht
implementiert, konnen aber als Grundlage f ur k unftigen Studien verwendet wer-
den. In jeder Abbildung ist ein verteiltes SUO mit unterschiedlicher Monitor-
Architektur dargestellt, welches einem anderen Verwendungszweck entspricht. In
den Monitor-Architekturen werden die verteilten Prozesse mit x
1
, x
2
, . . . , x
n
in
Verbindung mit Leiterbahn und Monitoren dargestellt.
Bus-Monitor-Architektur
Die Bus-Monitor-Architektur ist die einfachste der Architekturen. Dem Monitor
wird hierbei ein dedizierter Kanal zugewiesen, welcher am Datenbus der anderen
Kanale lauscht und somit Nachrichten wie jeder andere Prozess auch empfangt.
Der Monitor kann als ein stiller Teilnehmer betrachtet werden, mit der Aufga-
be der zusatzlichen Pr ufung und Einhaltung der Kommunikationsprotokolle. Das
Uberwachungssystem greift nur bei katastrophalen Fehlern ein, indem es Nach-

richten durch den Datenbus zu den anderen Prozessen sendet. Eine Realisierung
der Architektur gestaltet sich einfach, z.B. durch Peripherie-Hardware. Das An-
wendungsgebiet der Bus-Monitors konnten sogenannte commercial-o-the-shelf-
Produkte (Regalware) sein, welche eine zusatzliche Sicherheitsfunktion besitzen
sollen.
Die Bus-Monitor-Architektur ist geeignet f ur einfache, elektronische Produkte,
hat aber einen Flaschenhals in der Anbindung des Monitors. Hierbei besteht die
Gefahr, dass der Monitor Fehlverhalten unterliegt und den Bus mit Nachrichten
utet.
Abbildung 19.4: Bus-Monitor Architektur[1]
Single-Process-Monitor-Architektur
In der Single-Process-Architektur ist ein separater Monitor-Bus enthalten, an dem
jeder Prozess zusatzlich mit dem Monitor verbunden ist. Im Betrieb sendet jeder
Prozess seine zu uberwachenden Nachrichten uber einen eigenen, dedizierten Ka-
nal an den Monitor-Bus. Dies hat den Vorteil, dass der Monitor nicht die Kom-
munikation des SUO gefahrdet und so Designfehler reduziert werden.
Abbildung 19.5: Single-Process Monitor Architektur[1]
Distributed-Process-Architektur
In der Distributed-Process-Architektur kommen mehrere verteilte Monitore zum
Einsatz, welche als M
0
, ..., M
n
bezeichnet werden und die zugewiesenen Prozesse
x
0
, ..., x
n
uberwachen. Die Realisierung des Monitors M
i
kann auf der gleichen
Hardware wie der Prozess x
i
erfolgen. Das hat g unstigere Hardwarekosten zum
Vorteil.
Abbildung 19.6: Distributed Process - Architektur[1]
Eine andere, aber teuere Moglichkeit ware den Monitor in einer isolierten Ein-
heit zu implementieren, um Fehlertoleranz gegen uber dem Prozess zu garantie-
ren. Der Monitor M
i
ist nach dieser Architektur als Vormund des Prozesses x
i
zu betrachten und die Monitor-Verbindung kann fehlertolerant sein, auch wenn
die SUO-Verbindung es nicht ist. Im Vergleich zur Single-Process-Architektur ist
die Kontrolle aber zuverlassiger, da nur die Monitore untereinander kommuni-
zieren m ussen, um Einigung zu erzielen, auch wenn Monitore ausfallen. Proble-
me konnen sich dennoch ergeben. Die Komplexitat dieser Architektur kann die
Zuverlassigkeit der Monitor Implementierung reduzieren, denn der Aufwand des
verteilten Monitor-Konzeptes ist so hoch, wie das SUO selbst.
19.5 Was ein Monitor uberwacht
Bis zu diesem Kapitel wurden fehlertolerante Ansatze, Monitore in verteilten Echt-
zeitsystemen und potentielle Monitor-Architekturen vorgestellt. Jedoch wurde bis-
her nicht die Frage beantwortet, was genau Monitore uberwachen sollen. Es wurde
bereits diskutiert, dass Monitore an dem Punkt ansetzen sollen, bei dem systema-
tische Fehler (Design-Fehler) zum Scheitern eines Systems f uhren. Ihre Aufgabe
ware hierbei die Kommunikation und die Knoten auf Einhaltung ihrer Spezizie-
rungen zu uberpr ufen. Doch was zahlt zu dem Kontext der Kommunikation, den
ein Monitor uberwachen soll? Betrachtet man noch einmal das Maximal Fault As-
sumption - Konzept f ur fehlertolerante Systeme, so werden Fehler bereits zur De-
signzeit begangen. In diesem statistischen Modell zur Bestimmung der maximalen
Fehlerannahme, sind Faktoren oftmals unterspeziziert, wodurch die tatsachliche
Zuverlassigkeit kleiner als die geschatzte ist. Auch wird ein solches System weit
uber seine geschatzte Betriebszeit oder gar f ur andere Aufgaben verwendet. Kann
uberhaupt bei einem systematischen Fehler ein Monitor eine Losung sein?
Fault-Model-Verletzungen
In Fault-Model-Verletzungen ist es demnach die Aufgabe des Monitors die
Ubereinstimmung oder den Konsens der Kommunikation zu uberpr ufen. Hier-

bei soll der Monitor den (fehlenden) Konsens zwischen verteilten Komponenten
feststellen. Ziel dieser

Uberpr ufung ist es, dass z.B. jeder Empfanger (Knoten) ei-
ner Broadcast-Nachricht den gleichen Wert erhalt. Die

Uberwachung des Konsens
wahrend der Laufzeit kann sich wie folgt gestalten: Die uberpr uften Werte sind
g ultig, wenn sie entweder exakt ubereinstimmen oder wenn sie innerhalb eines
geschatzten Deltas liegen. Besonders bei harten, verteilen Echtzeitsystemen mit
Uhrensynchronisation stehen wieder asymmetrische Fehler im Fokus der Fault-
Model-Verletzungen.
Monitore konnen hierbei, je nach Architektur des Systems, zur Sicherstellung der
Kommunikation beitragen. Die Bus-Monitor-Architektur eignet sich nicht daf ur,
da der Monitor hier am gleichen Bus wie jeder Knoten hangt und selbst zum plap-
pernden Prozess wird. In der Single-Process-Architektur ist dagegen jeder Knoten
direkt mit dem Monitor verbunden, weshalb das System bis zu einer bestimmten
Fehlerlast durch asymmetrische Kommunikation Stand halt. Am geeignetsten zur
Sicherstellung von harten Deadlines ist die Distributed-Process-Architektur, bei
welchem jeder Knoten einen eigenen Monitor mit dedizierter Anbindung hat. So
konnen die Monitore bei Konsensverletzungen der Knoten trotzdem ihrer Funktion
19.6 Fazit 239
beibehalten und Echtzeitverhalten sicherstellen.
Point-to-Point Error-Checking
CRC (Cyclic Redundant Checks) ist das Standardverfahren um Punkt-zu-Punkt
Kommunikationsfehler zwischen Knoten zu identizieren. Mit diesem Verfah-
ren weist der Empfanger nach, wenn eine Nachricht wahrend der

Ubertragung
beschadigt wurde, z.B. durch Burstfehler oder zufallige Bitfehler. CRC haben
zudem den Vorteil, dass sie einfach in die Hardware zu implementieren und be-
sonders f ur den Einsatz in Embedded-Systems geeignet sind. Jedoch arbeiten sie
nicht hoch-zuverlassig. Ein Hauptproblem ist, dass durch die Netzwerkkapselung
von hoheren Schichten CRC-Sequenzen gefalscht werden konnen. Dies resultiert
aus asymmetrischen Fehlern und f uhrt dazu, dass falsche Nachrichten als fehlerfrei
identiziert werden. Eine Losung ware Architekturen fehlertolerant zu (re) desi-
gnen, mit einem eigenen Bus f ur Monitore, welche zudem den CRC ubernehmen.
Der Vorteil von CRC ist, dass sie weniger Bandbreite beanspruchen als die eigent-
liche Nachricht. Sie konnten als zusatzliche Monitor-Nachrichten problemlos von
den Knoten zum Monitor kommuniziert werden und gefahrden keine Echtzeitga-
rantien.
Timing Violations
Harte Echtzeitsysteme liefern Echtzeitgarantien, wenn die Timing-Annahmen vom
System gehalten werden. Dazu m ussen Bedingungen (Constraints), wie z.B. Nach-
richtenverzogerungen und Resynchronisation, eingehalten werden. Diese Bedin-
gungen konnen jedoch nicht direkt uberwacht werden, denn ein Monitor hat
nicht mehr Moglichkeiten als das SUO selbst. Constraints verbinden im Wesentli-
chen die Werte von lokalen Hardwareuhren zueinander zur echten (wall-clock)
physischen Zeit des Systemes. Monitore konnen im Prinzip nur die Abwesenheit
von Fehlern aufzeigen. Die Fehlerursache, ob Hard- oder Software, kann nicht
bestimmt werden. Die Losung ware, Monitore selbst mit Wahrscheinlichkeitsmo-
dellen auszustatten. Dies erfordert aber korrekte Umweltvariablen.
19.6 Fazit
In dieser Kapitel wurde versucht, einen

Uberblick uber den aktuellen Forschungs-
stand zum Monitoring zu geben. Dabei wurden systematische Fehler bei fehler-
toleranten Systemen aufgezeigt, bei denen Monitor-Konzepte angewendet wer-
den konnen. Online-Monitore stellen mit den diskutierten Architekturen f ur
hochst-sicherheitskritische Systeme eine Moglichkeit dar, die Zuverlassigkeit zu
erhohen. Die

Uberwachung der drei Konsensklassen durch Monitore deckt hierbei
einen Groteil der auftretenden Fehler ab. In Zukunft kommen zwei potentielle
Hardware-Architekturen f ur Distributed-Realtime-Systems in Frage, welche ver-
teilt oder zentral sein konnen. Arbeiten Monitore verteilt, so m ussen diese unter-
einander kommunizieren und Konsensdaten austauschen. Ein zentraler Monitor
dagegen erhalt die zu uberpr ufenden Konsensdaten von den einzelnen Knoten.
Dar uber hinaus bietet sich eine Kombination der abstrakten Architekturen je nach
Verwendungszweck an.
Abschlieend lasst sich sagen, dass ein nachtragliches Hinzuf ugen eines Monitors
kein Wundermittel gegen grundsatzliche Fehler im System darstellt. Man beachte
hierbei immer, dass ein Monitor nur einen weiteren Prozess im System ist und
selbst Fehlverhalten unterliegen kann. Jedoch bietet ein

Uberwachungssystem,
wenn es bereits beim Design des Systems ber ucksichtigt wird, ein hohes Potential
Distributed-Realtime-Systems sicherer zu machen.
[1] Monitoring Distributed Real-Time Systems:A Survey and Future Directions,
Indiana University, https://www.cs.indiana.edu/ lepike/pubs/survey.pdf, Fe-
bruar 2010.
[2] Investopia.com, In Anlehnung an: Investopia Dictionary: Black Box,
http://i.investopedia.com/inv/dictionary/terms/blackbox.gif, aufgerufen am
30.11.2010.
[3] Kopetz, H., Real-Time Systems: Design Principles for Distributed Embedded
Applications, Kluwer Academic Publishers, 2001

Verteilte Systeme 2010

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Verteilte Systeme 2010

Hochgeladen von

Copyright:

Verfügbare Formate

Verteilte Systeme

Akka Advanced und

Akka Monitoring & Management an.

Writing correct concurrent, fault-tolerant and scalable applications is too

Let it Crash-Modell als Strategie f ur die Fehlertoleranz in Akka ent-

everything is an actor. Weiterhin sind

ordered message queue

transactional data set [1]. STM implementiert

rollback nun auch im Speicher. Somit

Einfach abgebrochen bedeutet in diesem Zu-

Let it crash-Modell. Die-

Let it crash-Modell sind in Akka bei

AllForOne in einer Hierarchie (restart all)

Container genannt und beinhaltet die Agenten. Die

Main-Container. Der erste in der Laufzeitumgebung ge-

Agent Management System

Directory Facilitator (DF). Das AMS bietet einen Namensdienst

Ein Agent ist ein Computersystem das sich in ei-

intelligente Systeme als Einheit ihr spezisches Wissen, ihre Ziele,

ASPECT Development Process umzusetzen. Dabei formuliert ASPECT einen

holonic multiagent systems. Das Janus-Projekt bem uht

holonic multiagent-systems zu bieten.

M2Eclipse geliefert, welches installiert werden muss. Zudem

Contracting Organisation (Vertragsnehmer) um die Bestellung abzuschlieen

Food-Pheromon: Dies gibt die Richtung der Nahrungsquelle an.

Colony-Pheromon: Dies gibt die Richtung der Ameisenkolonie an.

Colony Pheromon aus. Nachdem er eine Futterquelle gefunden hat, versucht

Food-Pheromons aus um die Nahrungsquelle

Food-Pheromones. Die Pheromone wurden

The promotion of technologies and interoperability specications that fa-

Anderungen bestehender Spezikationen.

Gelbe Seiten-Dienst an, wobei sich jeder Agent

t bezeichneten Spuren s und t werden gema ihrer Reihenfolge zu st

< a, c >=< a, b, a, c >

ist deniert durch:

t ist das Gleiche wie das Verhalten von (P/s) nach t.

t traces(P) vorausgesetzt s traces(P)

Anderung des Symbols kann durch parallele Kompositionen verteilt werden.

durch die Spur von Q ersetzt.

Uberblick uber die Entwicklungsgeschichte der Prozessalgebren wiedergegeben

A Calculus of Mobile Process Der -Kalk ul

Uber den switchKanal bekommt P einen neuen Kommunikationskanal zuge-

Q dann ist auch P Q (7.9)

Nachricht in Sendung asynchrone Kommunikation mit synchroner Kom-

Uberpr ufung der Richtigkeit von Kommunikationsprotokollen (z.B. in ad-hoc

BlockingQueue in Java und kann

Komma Ok Syntax beim Lesen

Komma Ok Syntax beim Schreiben

Komma, Ok Syntax ist es moglich das blockierende Verhalten zu umgehen.

Exporter und ein

Importer benotigt wird. Die Aufgabe des Exporters ist es

Ubertragungseinheit aufzunehmen. Dementsprechend blockiert B, wenn A noch

Component Object Model und bezeichnet eine Microsoft-

Dynamic Data Exchange, kurz DDE, an. 1992 wur-

ActiveX Steuerelement und

ActiveX Automation gepragt. OLE wurde

Remote COM-Server ist genau genommen Bestandteil von

eine Menge von lose

Ubergabe lasst sich wie folgt beschreiben:

out-of-the-box Produkt ist, sondern es ist auf den meisten Plattformen

The socket library that acts as a concurrency framework. Man

Concurrency-Model an und dann

Queue, die Nachrichten und Kommandos f ur ein Objekt

Kommandos hart unterschieden