Embed Size (px)
Citation preview
Verteilte Systeme
Oliver BRAUN(Hrsg.)
Fakultat InformatikFachhochschule Schmalkalden
Sommersemester 2012
Inhaltsverzeichnis
1 Akka 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Christoph Schmidt
2 Cloud Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Christian Linde
3 Go 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Robert Worgul
4 GridGain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Danny Rubner
5 Jini - Java Intelligent Network Interface . . . . . . . . . . . . . . 53
Tim Achtert
6 ownCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Fabian Markert
7 Orc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Stephan Stenzel
8 Scala STM vs. Akka STM . . . . . . . . . . . . . . . . . . . . . . 85
Marco Wilhelm
9 Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Marie-Christin Reusche
10 Synchronisation in verteilten Systemen . . . . . . . . . . . . . . . 107
Ricardo Volkert
IV Inhaltsverzeichnis
1 Akka 2.0Christoph Schmidt
Inhaltsverzeichnis
1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Actor System . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Supervision und Monitoring . . . . . . . . . . . . 3
1.2.3 Actors identifizieren und lokalisieren . . . . . . . 4
1.3 Actors auf einen Blick . . . . . . . . . . . . . . . . . . . 5
1.3.1 Definition eines Actors . . . . . . . . . . . . . . . 5
1.3.2 Instanziieren eines Actors . . . . . . . . . . . . . 6
1.3.3 Nachrichten versenden . . . . . . . . . . . . . . . 7
1.4 Remote Kommunikation . . . . . . . . . . . . . . . . . . 9
1.4.1 Remote Konfiguration . . . . . . . . . . . . . . . 9
1.4.2 Der Echo Service . . . . . . . . . . . . . . . . . . 11
1.4.3 Der Echo Client . . . . . . . . . . . . . . . . . . 12
1.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1 Einleitung
Akka ist nicht nur ein Bergmassiv in Lappland. Hinter den Buchstaben verbirgtsich ein Open-Source-Projekt das von Jonas Boner gegrundet wurde. Dabeihandelt es sich um ein Framework, welches sich die Entwicklung von nebenlaufigen,fehlertoleranten und skalierbaren Applikationen bzw. Verteilten Systemen auf dieFahnen geschrieben hat.Im Kern des Frameworks steht das Actor Model, ein mathematisches Konzept furdie nebenlaufige Berechnung, welches 1973 von Carl Hewitt veroffentlicht wurde[1]. Diesem Konzept folgt beispielsweise auch die Programmiersprache Erlang 1.Akka 1.0 final wurde im Februar 2011 veroffentlicht [2]. Zu dieser Zeit standhinter Akka die schwedische Firma Scalable Solutions, welche neben professioneller
1 Weiterfuhrende Informationen zu Erlang sind unter http://www.erlang.org (23.04.2012) zufinden.
2 1 Akka 2.0
Beratung auch verschiedene kostenpflichtige Module fur Akka bereitstellte. Bereitsim gleichen Jahr veranderte sich allerdings die Situation. Martin Odersky, welcherals Vater der Sprache Scala gilt, grundete mit den fuhrenden Scala-Kopfen die FirmaTypesafe, um die Sprache Scala im Markt zu etablieren. Auch Scalable Solutionsverschmolz mit Typesafe [4]. Seit dieser Zeit ist Akka ein fester Bestandteil desTypesafe Stack.Akka hat sich kontinuierlich weiterentwickelt und mit der Version 2.0, welche am6. Mai 2012 veroffentlicht wurde einiges an Neuerungen erfahren [3]. Derzeit istAkka in der Version 2.0.2 verfugbar.Diese Ausarbeitung geht auf einige der wichtigsten Neuerungen ein und vergleichtdiese an einigen Stellen mit der alten Version. Es wird dabei ein Grundverstandnisfur Akka, dessen Actor Konzept und Scala vorausgesetzt, da sich die gezeigtenBeispiele im wesentlichen auf die Scala API beziehen.
1.2 Grundlagen
Mit der Veroffentlichung von Akka 2.0 sind einige Begriffe in den Vordergrundgeruckt die bis dato zwar bereits im Sprachgebrauch rund um Akka eingesetztwurden, mit der neuen Version jedoch eine starkere Gewichtung erfahren. Ausdiesem Grund werden diese anschließend naher erlautert.
1.2.1 Actor System
Actors sind Objekte mit eingekapseltem Zustand und Verhalten. Sie kommunizierenausschließlich uber den Austausch von Nachrichten. Diese werden in der Mailboxdes Empfangers gespeichert und nach einer gewissen Verweildauer abgearbeitet. DerBegriff des Actor Systems lasst sich mit einer Analogie beschreiben. Firmen weisenhaufig hierarchische Strukturen auf. Dies lasst sich auch auf ein Actor Systemubertragen. Die zu bewaltigenden Aufgaben werden von einer ubergeordnetenOrganisationseinheit, einem Actor, in Teilaufgaben zerlegt und an untergeordneteOrganisationseinheiten weitergegeben. Daraus folgt, dass jede untergeordneteEinheit, also die einzelnen Actors, nur winzige Teilaufgaben erledigen mussen.
Hierarchische Strukturen
Nun ergibt sich die Frage, wie die einzelnen Aufgaben koordiniert bzw. uberwachtwerden. In Akka 2.0 etablierte sich der Begriff des Actor System fest in die Syntaxdes Frameworks, wie in Kapitel 1.3 zu sehen. Es ist somit nicht mehr notwendig,eigene Supervisor zu definieren, da jetzt jeder Actor fur die Uberwachung seinerKinder verantwortlich ist. Die Einfuhrung des Actor Systems hat auch zur Folge,
1.2 Grundlagen 3
dass die in Akka 1.x eingesetzte ActorRegistry uberflussig wird und daherkomplett entfernt wurde.Um leistungsstarke Actor Systeme entwickeln zu konnen, gibt die Dokumentationeinige Richtlinien vor, welche im Anschluß naher ausgefuhrt werden:
Wenn ein Actor einen oder mehrere Worker-Actors steuert, sollte dieser dieUberwachung der Worker (Kinder) ubernehmen, da die Fehlerbehandlung anubergeordneter Stelle effizienter koordiniert und umgesetzt werden kann.
Wenn ein Actor sensible Daten beinhaltet, sollte dieser alle kritischen Aufgabenan untergeordnete Worker auslagern. Hierbei ist es haufig das Beste, fur jedeAnfrage einen neuen Worker zu erzeugen.
Wenn die Aufgabenerfullung eines Actors von einem anderen Actor abhangig ist,sollte dieser den Lebenszyklus des anderen uberwachen, um auf das Eingeheneiner Terminierungsnachricht adaquat reagieren zu konnen.
1.2.2 Supervision und Monitoring
Eine der wichtigsten Aufgabe in einem Actor System ist das Behandeln bzw. dasBeheben von Fehlern. Akka unterscheidet zwischen Supervision und Monitoring.Die Unterschiede dieser Techniken werden im Anschluss ausgefuhrt.
Supervision
Supervision beschreibt die Moglichkeit, Fehlersituationen innerhalb eines ActorSystems aufzulosen. Diese Aufgabe wird immer vom Eltern-Actor durchgefuhrt.Dabei ergeben sich folgende Moglichkeiten:
Fortsetzen der untergeordneten Instanz mit aktuellem internen Zustand.
Neustarten der untergeordneten Instanz durch Bereinigung des internen Zu-standes.
Dauerhaftes Beenden der untergeordneten Instanz.
Fehler an ubergeordnete Instanz weiterreichen.
Akka unterscheidet zwischen One-For-One und All-For-One-Strategie, um Super-vision umzusetzen. One-For-One bedeutet, dass im Falle eines Fehlers nur derbetroffene Actor neu gestartet wird. Bei All-For-One-Strategie werden hingegenalle Kinder eines Supervisors neu gestartet. Standardmaßig arbeitet Akka mitOne-For-One-Strategie.
4 1 Akka 2.0
Monitoring
Im Gegensatz zum Supervision-Konzept darf beim Monitoring jeder beliebigeActor einen anderen Actor uberwachen. Der Unterschied besteht allerdings darin,dass nur Zustandsanderungen von “alive” zu “dead” sichtbar werden.
Gerade im Bereich Supervision und Monitoring unterscheidet sich Akka2.0 von dessen Vorgangerversionen. In Akka 1.3.1 mussten beispielsweise explizitSupervisor mit Hilfe des Supervisor-Factory-Objekts angelegt werden [5]. Mit derBestimmung, dass jeder Actor fur seine Nachkommen verantwortlich ist, wurdedieses Konzept deutlich verscharft.
1.2.3 Actors identifizieren und lokalisieren
In diesem Abschnitt wird beschrieben wie Actors in einem verteilen Actor Systemidentifiziert und lokalisiert werden konnen. Abbildung 1.1 stellt dabei die wesent-lichen Begriffe in ihrer Beziehung zueinander dar. Die wichtigsten Bestandteilewerden im Anschluss naher erlautert.
Abbildung 1.1: Actor System2
2 Abbildung in Anlehnung an [6].
1.3 Actors auf einen Blick 5
Actor Reference
Eine Actor Reference ist eine Referenz auf einen konkreten Actor. Jeder Actor kannuber das Feld self auf seine lokale Referenz zugreifen. Uber das Feld sender hater außerdem Zugriff auf die Referenz des Senders der aktuell zu bearbeitendenNachricht.
Actor Path
Da nun Actors strikt hierarchisch erzeugt werden, existiert eine baumartige Strukturvon Actors. Durch diese Struktur kann ahnlich wie in einem Datei-System der“Weg” zu einem bestimmten Actor beschrieben werden. Jeder Actor Path bestehtaus einem Anker, welcher das Actor System identifiziert. Diesem schließt sicheine Verkettung von Elementen an, die von der Wurzel des Systems bis hin zumvorgesehenen Actor fuhrt, wie in Listing 1.1 gezeigt.
Listing 1.1: Actor Path Aufbau
// local or remote
"akka://sys@host:2552/ user/parent/child"
// purely local
"akka://sys/user/parent/child"
Mit Hilfe des Actor Path kann dann aus einem Actor heraus mit dem Aufrufcontext.ActorFor(<Actor Path>) ein entsprechender Actor angesprochen wer-den.
1.3 Actors auf einen Blick
Dieses Kapitel beantwortet die wichtigsten syntaktischen Fragen, um mittelsAkka leistungsstarke Anwendungen realisieren zu konnen. Es geht auf Actors unddessen Kommunikationskonzepte ein und beleuchtet anschaulich die wichtigstenVorgehensweisen.
1.3.1 Definition eines Actors
Um eine Klasse mit der Funktionalitat eines Actors anzulegen, sind lediglich zweiSchritte notwendig. Zu Beginn wird eine Klasse um den Actor-Trait erweitert.Anschließen wird die receive-Methode implementiert. Bis zu diesem Punktunterscheidet sich Akka 2.0 nicht von seinen Vorgangerversionen.Listing 1.2 zeigt einen HelloActor und dessen receive-Methode. Daruber hinauslasst sich erkennen, dass dieser lediglich auf Hello-Nachrichten mit der Ausgabe
6 1 Akka 2.0
einer Zeichenkette reagiert.
Listing 1.2: Hello Actor
import akka.actor.Actor
case class Hello(name: String)
class HelloActor extends Actor {
def receive = {
case Hello(n) => println("Hello " + n)
case _ =>
}
}
1.3.2 Instanziieren eines Actors
Nachdem die Implementierung eines Actors dargestellt wurde, bleibt die Frageoffen, wie ein Objekt des HelloActors3 erzeugt werden kann.
Listing 1.3: Anlegen eines Actor Systems
...
object HelloApp extends App {
val system = ActorSystem("HelloSystem")
val helloActor = system.
actorOf(Props[HelloActor], name = "helloactor")
}
Diese Frage soll Listing 1.3 beantworten. Zu Anfang ist es notwen-dig ein ActorSystem4 zu erzeugen. Anschließend wird mit dem Aufrufsystem.actorOf(...) ein Actor erzeugt. Diese Methode bekommt als zweitesArgument den Name des Actors und als erstes Argument ein Objekt der KlasseProps ubergeben, welches mit einem Actor, in diesem Fall mit einem HelloActor
parametrisiert wird.
Naturlich ist es mit der Props-Klasse auch moglich Actors mit Nicht-Standard-Konstruktor 5 zu erzeugen. Sie ist allerdings weitaus vielseitiger, da mitihr beispielsweise auch Router realisiert werden konne, wie Listing 1.4 zeigt. In
3 Siehe Listing 1.2.4 Der Begriff des Actor Systems wurde bereits in Kapitel 1.1 eingefuhrt.5 Statt Props[HelloActor] kann auch Props(new HelloActor()) genutzt werden.
1.3 Actors auf einen Blick 7
diesem wird ein Router mit funf Instanzen des HelloActors erzeugt. Der Routerarbeitet dabei nach dem Round-Robin-Verfahren.
Listing 1.4: Beispiel Router
val router = system
.actorOf(Props[HelloActor ]. withRouter(
RoundRobinRouter(nrOfInstances = 5)))
Weiter wird betrachtet, wie Actors innerhalb eines anderen Actors erzeugt werden.Auf Grund der strengen Hierarchie eines Actor Systems muss an dieser Stelleleicht variiert vorgegangen werden. Listing 1.5 soll dies illustrieren. Es wird nuncontext.actorOf(...) zum Erzeugen genutzt. Hinter dem context verbirgtsich die Sicht auf eine ActorCell welche Informationen wie die Actor Referenzender untergeordneten Worker eines Actors beinhaltet.
Listing 1.5: Anlegen eines eingebetteten Actors
class MyActor extends Actor {
val helloActor =
context.actorOf(Props[HelloActor ])
...
}
1.3.3 Nachrichten versenden
Akka 2.0 unterscheidet wie auch schon in den Vorgangerversionen grundsatzlichzwei Arten, um Nachrichten an Actors zu senden. Dabei handelt es sich umFire-forget und Send-And-Receive-Future. Bei der erstgenannten Variante wirdeinem Actor mit Hilfe der !-Methode eine Nachricht ubermittelt. Hierbei erwartetder Sender nicht wie bei Send-And-Receive-Future eine Ruckantwort. Da beider Variante Fire-forget6 keine Anderungen mit dem Versionssprung auf 2.0vorgenommen wurden, wird dies hier nicht weiter ausgefuhrt.
Send-And-Receive-Future
Bei dieser Variante wird eine Nachricht asynchron versendet. Als Ergebnis erhaltder Sender ein Future7, was ein mogliches Ergebnis reprasentiert. An dieserStelle unterscheidet sich Akka 2.0 syntaktisch von der Version 1.3.1, was mit dennachfolgenden Listings illustriert werden soll.
6 In Listing 1.12 ist ein Beispiel zu Fire-forget zusehen.7 Siehe hierzu [7].
8 1 Akka 2.0
Listing 1.6: Send-And-Receive ohne Future mit Akka 1.3.1
import akka.util.duration._
...
val result =
(echoActor .?(msg)(timeout = 10 seconds))
.as[String] match {
case Some(str) => str
case None => "timeout"
}
...
In Listing 1.6 und 1.7 wird einem echoActor ein String ubermittelt, welchervon diesem unverandert zuruckgesendet werden soll. Bei beiden Beispielen wirdexplizit auf das Ergebnis gewartet, weshalb ein Timeout von 10 Sekunden gesetztwurde. In Listing 1.7 ist das Timeout allerdings implizit angegeben.
Listing 1.7: Send-And-Receive-Future mit Akka 2.0.1
import akka.dispatch.Await
import akka.pattern.ask
import akka.util.Timeout
import akka.util.duration._
...
implicit val timeout = Timeout (10 seconds)
val future = echoActor ? msg
val result = Await.result(future , timeout.duration)
.asInstanceOf[String]
...
In Akka 2.0 ist es ublich mittels Await auf das Ergebnis des Futures zu warten.Dieses Vorgehen kann durchaus als sinnvoll erachtet werden, wenn das Ergebnisdirekt benotigt wird. Haufig ist ein solches Future aber nur Teil einer komplexenBerechnung, welche von mehreren Futures abhangig ist. Um an dieser Stelle nichtzu blockieren bietet Akka 2.0 die Methode mapTo. Mit dieser ist es moglich dieBerechnung bereits auf Basis der Futures durchzufuhren. Das Ergebnis kann dannnach Vollendung aller beteiligter Futures zu einem spateren Zeitpunkt abgerufenwerden. Listing 1.8 zeigt die Verwendung dieser Methode.
Listing 1.8: Send-And-Receive-Future mit mapTo
val future = for {
a <- ask(actorA , msg).mapTo[String]
b <- ask(actorB , msg).mapTo[String]
1.4 Remote Kommunikation 9
} yield a + b
1.4 Remote Kommunikation
Das vorangegangene Kapitel hat den Grundstein fur das Arbeiten mit Actors gelegt.Auf diesem aufbauend soll nun gezeigt werden, wie Actors uber Rechnergrenzenhinweg kommunizieren konnen.Um dies zu illustrieren wird schrittweise eine Client-Server-Anwendung 8 entwickelt.Die Idee der Anwendung besteht darin, dass ein Client eine Zeichenkette uberein Netzwerk an einen Echo-Service sendet. Dieser empfangt die Nachricht, drehtdiese um und schickt sie an den Sender zuruck.
1.4.1 Remote Konfiguration
In Akka 2.0 gibt es keine gesonderte Syntax um remote Kommunikation zu realisie-ren. Alle Schritte laufen analog ab, als wurde ein lokales System umgesetzt werden.Die Funktionalitat die ein Actor System benotigt um uber Rechnergrenzen hinwegzu kommunizieren wird lediglich durch eine entsprechende Konfiguration hinzu-gefugt. Um dies zu ermoglichen wird im ersten Schritt das Module akka-remote
in ein Projekt integriert.
Listing 1.9: SBT Konfiguration
libraryDependencies +=
"com.typesafe.akka" % "akka -actor" % "2.0.1"
libraryDependencies +=
"com.typesafe.akka" % "akka -remote" % "2.0.1"
libraryDependencies +=
"com.typesafe.akka" % "akka -kernel" % "2.0.1"
Listing 1.9 zeigt einen Ausschnitt der build.sbt Datei. Neben dem akka-remote
Modul wurde noch das akka-kernel Modul eingebunden, welches das Starteneines Application Server ermoglicht.
Remote Ressourcen freischalten
Die eigentliche Remote-Funktionalitat wird in der Datei application.conf
hinzugefugt. Hier mussen mindestens drei Einstellungen vorgenommen werden:
8 Der Quellcode kann auf Github heruntergeladen werden[8].
10 1 Akka 2.0
Der Wert provider wird auf akka.remote.RemoteActorRefProvider ge-setzt.
Es wird ein Host-Name eingetragen unter welchem das Actor System erreichtwerden kann.
Außerdem ist ein entsprechender Port zu vergeben.
Da die Beispielanwendung eine Konfiguration fur Client und Server benotigt,wurde die Konfiguration auf die Dateien common.conf und application.conf
aufgeteilt.
Listing 1.10: Die Datei common.conf
akka {
actor {
provider = "akka.remote.RemoteActorRefProvider"
}
remote {
netty {
hostname = "127.0.0.1"
}
}
}
Listing 1.10 zeigt die Basis-Konfiguration, die Client und Server gemeinsam haben.In Listing 1.11 ist dann die spezifische Konfiguration der beiden Actor Systeme zusehen.
Listing 1.11: Die Datei application.conf
echoactor {
include "common"
akka {
remote.netty.port = 2552
}
}
echoclient {
include "common"
akka {
remote.netty.port = 2553
}
}
1.4 Remote Kommunikation 11
1.4.2 Der Echo Service
Nach dem Abschluss der Konfiguration wird nun vermittelt, wie ein remote basiertesActor System implementiert werden kann. Dies geschieht wieder an Hand dergenannten Anwendung. Im ersten Schritt wird ein EchoActor implementiert, derauf das Eintreffen einer Zeichenkette reagiert, diese umdreht und an den Senderzuruckschickt, wie in Listing 1.12 zu sehen.
Listing 1.12: Der Echo Actor
class EchoActor extends Actor {
def receive = {
case msg:String =>
println("> " + msg)
sender ! msg.reverse
case _ =>
}
}
Anschließend folgt die Entwicklung des Actor Systems. Hierzu wird eine Klas-se EchoApplication angelegt, welche um den Trait Bootable aus demakka-kernel Modul erweitert wird. Nachdem die Rahmenbedingungen fur dasSystem geschaffen wurden, erhalt dieses den Namen “EchoApp” und wird mitder zuvor erstellen Konfiguration parametrisiert. Außerdem wird eine Instanz desEchoActors erzeugt um auf Nachrichten reagieren zu konne, was Listing 1.13zeigt.
Listing 1.13: Die Echo Application
class EchoApplication extends Bootable {
val system =
ActorSystem("EchoApp",ConfigFactory.
load.getConfig("echoactor"))
val actor =
system.
actorOf(Props[EchoActor],"echo -actor")
...
}
Abschießend wird ein ausfuhrbares Objekt mit dem Namen EchoApp angelegt,um ein lauffahiges Programm zu erzeugen. Hier wird lediglich ein Objekt derKlasse EchoApplication erzeugt, welches die Funktionalitat des Actor Systems
widerspiegelt, wie in Listing 1.14 zu sehen.
12 1 Akka 2.0
Listing 1.14: Das EchoApp Object
object EchoApp {
def main(args: Array[String ]) {
new EchoApplication
println("Started Echo Application - waiting for
messages")
}
}
1.4.3 Der Echo Client
Die grundlegenden Entwicklungsschritte fur die Realisierung des Client sind analogzu denen des Servers zu sehen. Der Hauptunterschied besteht jedoch darin, dassder Client eine Information benotigt, wie er mit dem Server kommunizieren kann.Dies geschieht wie in Akka 2.0 ublich dadurch, dass im Actor System des Clientmit Hilfe der Methode actorFor unter Angabe des Actor Path eine Referenz aufden entfernten EchoActor angelegt wird. Dies ist In Listing 1.15 dargestellt. Uberdie Methode sendMsg konnen dann Nachrichten an den Echo Service gesendetwerden.
Listing 1.15: Die Echo Client Application
class EchoClientApplication extends Bootable {
val system = ActorSystem("EchoClientApp",
ConfigFactory.load.getConfig("echoclient"))
val actor = system
.actorOf(Props[EchoClientActor],
"echo -client -actor")
val remoteActor = system
.actorFor("akka:// [email protected]:2552/ user/
echo -actor")
def sendMsg(msg: String) = {
actor ! (remoteActor , msg)
}
...
}
1.5 Fazit 13
1.5 Fazit
Akka 2.0 eignet sich, wie auch schon seine Vorgangerversion sehr gut fur dieEntwicklung von nebenlaufigen Programmen bzw. Verteilten Systemen. Durch daseingesetzte Actor-Konzept ist es auf elegante Weise moglich leistungsstarke An-wendungen zu realisieren. Dies haben auch zahlreiche Entwickler fur sich entdeckt.Es ist eine Community entstanden, die Neueinsteigern tatkraftige Unterstutzungbietet. Daruber hinaus ist es gelungen Akka kontinuierlich weiterzuentwickeln undan neue Aufgaben anzupassen, was letztlich auf Jonas Boner zuruckzufuhren ist,da dieser in regelmaßigen Abstanden offentliche Diskussionen anregt, um dasFramework stetig zu verbessern. Daher wird Akka auch in Zukunft nichts an seinerStarke verlieren.
Literaturverzeichnis
[1] Carl Hewitt and Peter Bishop and Richard Steiger, A Universal Modular ActorFormalism for Artificial Intelligence. IJCAI, 1973.
[2] Jonas Boner, Akka 1.0 final is relesead. http://groups.google.com/group/akka-user/browse thread/thread/c9a055d6f7d1b4d4, 23.04.2012.
[3] Viktor Klang, Akka 2.0 Released. http://akka.io/news/2012/03/06/akka-20-released.html, 23.04.2012.
[4] Anonymous, Welcome to Scalable Solutions, now a part of Typesafe.http://scalablesolutions.se, 23.04.2012.
[5] Typesafe Inc, Akka Documentation Release 1.3.1.http://doc.akka.io/docs/akka/1.3.1/Akka.pdf, 30.04.2012.
[6] Typesafe Inc, Actor References, Paths and Addresses.http://doc.akka.io/docs/akka/2.0.1/general/addressing.html, 02.05.2012.
[7] Typesafe Inc, Futures. http://doc.akka.io/docs/akka/2.0.1/scala/futures.html,14.05.2012.
[8] Christoph Schmidt, Echo-Service. https://github.com/c-schmidt/Echo-Service,29.05.2012.
14 1 Akka 2.0
2 Cloud HaskellChristian Linde
Inhaltsverzeichnis
2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 Prozesskommunikation . . . . . . . . . . . . . . . 16
2.2.2 Serialisierbarkeit . . . . . . . . . . . . . . . . . . 17
2.2.3 Starten und Finden von Prozessen . . . . . . . . 17
2.2.4 Fehlertoleranz . . . . . . . . . . . . . . . . . . . 18
2.3 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Closures . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1 Statische Werte . . . . . . . . . . . . . . . . . . 20
2.4.2 Entserialisierung einer Closure . . . . . . . . . . . 21
2.5 Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1 Einleitung
Cloud Haskell ist ein Framework. Es befasst sich mit der Entwicklung von Verteil-ten Systemen in der Programmiersprache Haskell. Dieser Ausarbeitung liegt dieVeroffentlichung des Artikels “Towards Haskell in the Cloud“1 zu Grunde.
Ziel dieser Ausarbeitung soll es sein, dem Leser einen Einblick zu geben, ob Haskellzur Entwicklung Verteilter Systeme verwendbar ist und wie eine Umsetzungaussehen konnte.
In Verteilten Systemen sind einige wichtige Probleme zu bedenken. Es muss dafurgesorgt werden, dass Prozesse keine konkurrierenden Zugriffe aufeinander haben.Weiterhin muss eine Strategie entwickelt werden, wie mit fehlerhaften Prozessenumzugehen ist.
Die Forderung das Prozesse keinen konkurrierenden Zugriff haben durfen, istvor allem in Hochverfugbarkeitssystemen ein Muss. Das hat in diesem Kontext
1 [1]
16 2 Cloud Haskell
zur Folge, dass alle Daten die ausgetauscht werden sollen, explizit als Messageversendet werden mussen.
Mit dem Begriff “Cloud“ ist eine Große Menge an Prozessoren gemeint, die ihreneigenen Speicher besitzen und uber ein Netzwerk miteinander verbunden sind.
Bei Hochverfugbarkeitssystemen ist die Kostenfrage oft nicht außer Acht zu lassen.Den Großteil der Kosten beansprucht dabei das “Verschieben“ von Daten.
2.2 Prozesse
2.2.1 Prozesskommunikation
Wie in vielzahligen anderen Bereichen tritt Erlang auch hier als Vorbild auf. In CloudHaskell, wie in Erlang auch, wird die primare Kommunikation zwischen Prozessenuber “message-passing“, also das Versenden und Empfangen von Nachrichtenrealisiert.
Hingegen unterscheidet sich die Umsetzung von der in Erlang dahingehend, dassEinzel-Prozesse auch in geteiltem Speicher verwendet werde konnen.
In Haskell existieren Moglichkeiten umkonkurrierende Systeme zu entwickeln, sie-he MVar fur verteilte unveranderbare Va-riablen und forkIO fur “lightweight“ leicht-gewichtige Prozess-Faden (vol. Abbildung2.1).Die Entwickler haben sich Gedanken ge-macht, ob es sinnvoll ist MVar zu serialisie-ren. Dabei wurde die Frage aufgeworfen,ob es Sinn macht geteilten Speicher in ei-nem Verteilten System zu simulieren. Diesbeantworteten sie mit ja! Sie finden esallerdings nicht sinnvoll MVar zu seriali-sieren.Leider konnen diese Mechanismen zur Pro-blemlosung nicht genutzt werden, da sienicht serialisierbar sind und somit nichtgeeignet, um uber Netzwerk in einer Nach-richt versendet zu werden.
Abbildung 2.1: Prozess Kommunikation [1]
Alle Zustande einer Nachricht werden in der ProzessM monade vereinigt. Diesewird bei jeder Nachrichten-Aktion aktualisiert.
2.2 Prozesse 17
Das bedeutet, dass auch alle an der Kommunikation beteiligten Code-Elemente indie ProzessM monade integriert sind.
Cloud Haskell bietet zwei verschiedene Moglichkeiten um Nachrichten aus zutauschen. Untypisierte Nachrichten (untyped messages) verhalten sich genau wiein Erlang. Weiterhin gibt es noch den Typ-Kanal (typed channels), welcher an dasstrenge Typ-System in Haskell angelehnt ist. Es ermoglicht, statische Garantienfur den Inhalt einer Nachricht zu geben.
2.2.2 Serialisierbarkeit
Serialisierbarkeit bedeutet, dass jedes Element den “Serializable“ Typen imple-mentieren muss. Damit wird sichergestellt, dass die Elemente binar (Binary) undtypisierbar (Typeable) sind.
Listing 2.1: Serializable Beispiele
1 send::Serializable a=>ProcessId ->a->ProcessM ()2 match::Serializable a=>(a->ProcessM q)->MatchM q()3 --4 class (Binary a,Typeable a)=>Serializable a
Mit der binaren Eigenschaft wird die Funktionalitat zum de- und encodieren derDaten bereitgestellt. Somit ist eine binare Darstellungsform moglich.
Durch “Typeable“ wird erreicht, dass mittels der Funktion “typeOF“ eine TypReferenz produziert werden kann, wodurch der Typ ermittelt werden kann.
In Haskell sind alle primitiven Datentypen und die meisten Higher-level Daten-strukturen serialisierbar. Diese konnen also problemlos teil einer Nachricht sein.
Zu beachten ist, dass manche Datentypen ausdrucklich nicht serialisierbar sind,zum Beispiel: “MVar“ und “TVar“.
Weiterhin konnen Funktionen, welche keine freien Variablen haben einfachubertragen werden. Bei der Serialisierung statischer Werte findet als erstes ei-ne Auswertung statt Anschließend wird die Code-Adresse fur das Ergebnis derAuswertung serialisiert.
2.2.3 Starten und Finden von Prozessen
Damit in einem Verteilten System mit einem Prozess gearbeitet werden kann,muss dieser erst einmal gestartet werden. Das wirft die Frage auf: Wo soll ergestartet werden? Naheliegend ware es, eine Maschine im System auszuwahlen,welche Rechenkapazitat frei hat. Dafur wird zu erst ein Mechanismus benotigt,der in der Lage ist, in einem Verteilten System eine Maschine zu finden.
Cloud Haskell beantwortet dies mit dem Knoten (the node). Als Knoten beschreibt
18 2 Cloud Haskell
Haskell die Idee eines eigenen Adressbereiches, jeder der Knoten hat eine eigeneeindeutige Knoten ID (NodeID). In dieser ID ist die IP-Adresse enthalten, uberdie kommuniziert wird.
Zum Starten eines Prozesses werden zwei Elemente benotigt. Die NodeID und derCode der ausgefuhrt werden soll.
Um den Code einzubetten, muss er serialisiert werden. Dies wird erreicht, in demerstens eine Reprasentation des Codes vorhanden sein muss und zweitens dieReprasentation der Umwelt (environment).
2.2.4 Fehlertoleranz
Ein zentrales Problem stellt die Fragestellung dar, wie mit fehlerhaften Prozessenumgegangen wird.
Die Fehlerbehandlung oder -toleranz basiert in Haskell auf den Ideen von Erlang.
Der Erlang-style sieht vor, dass wenn irgendwas in einem Prozess schief lauft, dannist die beste Losung ihn zu beenden. Es wird davon ausgegangen, dass durch das“Versiegeln“ nie wieder die gleiche Sicherheit wie zuvor erreicht werden kann.
Das bedeutet also, dass der Prozess neu gestartet werden muss. Ein Neustartkann jedoch nur durchgefuhrt werden, wenn es einen Prozess gibt, der den zubeendenden Prozess uberwacht. Dieser uberwachende Prozess muss beim Beendenbenachrichtigt werden, damit er mogliche Schritte einleiten oder Entscheidungentreffen kann.
Hierbei muss eine Behandlung von Terminierungen erfolgen. Es gibt dieMoglichkeiten, das Haskell Exzeption handling zu bemuhen oder per Nachrichtenzu ubermitteln. Die Nachrichten werden dann wie jede andere Nachricht auchempfangen.
2.3 Messages 19
2.3 Messages
In Haskell werden die Daten nicht uber geteilten Speicher ausgetauscht, sondernuber Messages. Dies stellt sich als eine sehr gute Strategie fur Verteilte Systemedar.2
Probleme treten dann auf, wenn eine Nachricht verschiedene Typen haben kann.Siehe Erlang Listing 2.2
Listing 2.2: match in Erlang
1 math()->receive2 { add , Pid , Num1 , Num2} -> Pid ! Num1 +Num2;3 { divide , Pid , Num1 , Num2} when Num2 =0 -> Pid ! Num1 /Num2;4 { divide , Pid , _ , _ } Pid ! div by zero5 end ,6 math().
Dieses Beispiel beinhaltet zwei verschiedene Nachrichtentypen. Sie werden durch dieAtome “add“ und “divide“ reprasentiert. Die Auswahl wird mittels Patternmatchingrealisiert. Jedes der Pattern in Zeile zwei bis vier (siehe Listing 2.2), absolvierteine Nachrichtenbehandlung. In Zeile zwei wird durch das Atom add, die ProzessID sowie zwei Zahlenwerte eine Nachricht ausgelost, die an den Prozess mittelsProzess ID zwei addierte Zahlen sendet. In Zeile drei wird zusatzlich noch eineBedingung eingefuhrt. Diese pruft, ob es sich bei der zweiten Zahl um eine Nullhandelt. Die beiden ubergebenen Zahlen, in Zeile vier sind uninteressant, da esin dieser Reihung nur bedeuten kann, dass die Bedingung aus Zeile drei ergeben,dass die zweite Zahl Null ist. In diesem Fall soll ein “div by zero“ gesendet werden.
2.4 Closures
Mit Closures sind Funktionen gemeint, die Wissen aus ihrer Umgebung“mitnehmen“. Beispielsweise gibt es eine Mutter-Funktion, welche innerhalb ihresGultigkeitsbereich eine Variable “x“ setzt und eine lokale Kind-Funktion defi-niert. Beim Aufruf der Mutter-Funktion gibt diese die Kind-Funktion zuruck. Inder Aufrufer Umgebung gibt es keine Variable “x“ dagegen kann die gebundeneKind-Funktion auf die Variable aus ihrem Erstellungskontextes zugreifen.
In diesem Zusammenhang ist die Frage, wie eine Closure transportiert wird,grundlegender Bestandteil. Die Bedingung hierbei ist, dass die Funktion von jedembeteiligten Verteilten System adressierbar sein muss. Die Notwendigkeit fur solcheine Uberlegung ist verbreitet, zum Beispiel: “sendFunc“. Die Autoren des Artikels“Towards Haskell in the Cloud“ sagten Folgendes: “To see how pervasive this
2 vgl. [2]
20 2 Cloud Haskell
question is, consider sendFunc, [...]“[1]. Diese Funktion legt eine anonyme Funktionan und sendet sie an einen Channel.
Listing 2.3: sendFunc
1 -- wrong2 sendFunc::SendPort(Int ->Int)->Int ->ProcessM ()3 sendFunc p x = sendChan p (λ y -> x + y + 1)
Sie sendet die Closure (λ y → x + y + 1), in der die freien Variablen in xabgefangen werden. Die Serialisierung einer Closure-Funktion wird erreicht, indemihre freien Variablen serialisiert werden.
Immer dann wenn die Typen der freien Variablen nicht mit den Funtkionswertenverbunden sind, ist unklar wie sie serialisiert werden sollen. Wer sich an dieserStelle genauer fur das Problem interessiert, sollte den zugrunde liegenden Artikelund den dazugehorigen Quellcode lesen.
Es muss nun spezifiziert werden, dass eine Funktion serialisierbar ist. DieSerialisierbarkeit ist keine strukturelle Eigenschaft einer Funktion. Die Darstellungeiner Funktion in Haskell ist rein (purely). Das bedeutet alles, was in Haskell miteiner Funktion getan werden kann, ist sie anzuwenden.
Es besteht nun das Problem, dass die Funktionen serialisiert werden mussen, dazum Beispiel “spawn“ die Funktion spezifizieren muss, welche auf einem anderenSystem ausfuhren soll.
Die Serialisierung einer Closure-Funktion wird erreicht, indem die freien Variablenserialisiert werden.
2.4.1 Statische Werte
Funktionen, die keine freien Variablen haben, konnen einfach ubertragen werden.Die Implementierung der Serialisierung statischer Werte ist so realisiert, dass alserstes eine Auswertung stattfindet und dann die code Adresse fur das Ergebnisder Auswertung serialisiert wird.
Wie oben schon festgestellt, ist es problematisch eine Closure zu ubertragen,die freie Variablen beinhaltet. Eine Closure beinhaltet einen Code-Pointer undeine Umgebung (enviroment). Hierbei ist zu beachten, dass eine Closure nichtserialisiert werden kann, wenn ihre Umgebung es nicht ist. Durch diese statischenTerme ist es nun moglich eine Reprasentation in Haskell zu erstellen.
2.5 Beispiele 21
Listing 2.4: Representation einer Closure
1 data Closure a where -- Wrong2 MkClosure :: Static (env -> a) -> env -> Closure a
2.4.2 Entserialisierung einer Closure
Nun ist geklart wie eine Closure zu einem anderen “System“ ubertragen werdenkann. Das Problem, das an dieser Stelle nun besteht, ist dass der Empfanger nichtweiß, welchen Typ die Closure enthalt.
Es bestehen verschiedene Moglichkeiten um nun dem Empfanger diese Informatio-nen mitzuteilen.
Variante eins es wird eine Reprasentation des Umgebungstyps mitgesendet und amanderen Ende ein run-time type-class lookup gemacht. Also eine Typ Ermittlungzur Laufzeit.
Variante zwei ware eine Reprasentation des Deserialisierungstyps selbst mit zusenden.
Die Losung ist im Nachhinein eigentlich sehr nahe liegend. Die Serialisierung undDeserialisierung der Umgebung wird zur Closure Erstellungszeit und nicht zurClosure Serialisierungszeit durchgefuhrt. Da die Umgebung den Typ ByteStringhat.
2.5 Beispiele
CloudHaskell/examples/tests/Test-Closure.hs
Als erstes beginnt alles mit einer Main Funktion.
Listing 2.5: ein paar Zeilen code
1 main = remoteInit (Just "config") [Main.__remoteCallMetaData]initialProcess
2 --3 remoteInit4 :: Maybe FilePath5 -> [RemoteCallMetaData]6 -> (String -> ProcessM ())7 -> IO ()
Die Main Funktion ruft die initialProcess Funktion auf. In dieser Funktion stehendie im Nachgang stehenden Beispiele.
Bevor die Beispiele behandelt werden konnen, muss noch etwas vor Arbeit geleistetwerden. Die Funktion “remotable“ generiert automatisch closure Funktionen mitder Namenskonvention: n closure.
22 2 Cloud Haskell
Listing 2.6: remotable
1 remotable [’sayHi’, ’sayHiIO ’,’sayHiPure ’, ’sayHiPM ’, ’funnyHi ’, ’runAnother ’, ’simpleSum ’]
Dadurch ist es nun moglich, diese Funktionen mit spawn, remoteCall und invoke-Closure zu nutzen.
Listing 2.7: spawn
1 spawn :: NodeId -> Closure (ProcessM ()) -> ProcessM ProcessId
Nun konnen wir zum ersten Beispiel kommen.
Listing 2.8: sayHi
1 p <- spawn mynid (sayHi__closure "Zoltan")2 say $ "Got result " ++ show p3 --4 sayHi :: String -> ProcessM ()5 sayHi s = say $ "Greetings , " ++ s
In diesem Beispiel wird die Funktion sayHi mit dem Parameter “Zoltan“, von derspawn Funktion aufgerufen. Die spawn Funktion halt das Programm nicht an.
Listing 2.9: sayHiPure
1 q <- callRemotePure mynid (sayHiPure__closure "Spatula")2 say $ "Got result " ++ show q3 --4 sayHiPure :: String -> String5 sayHiPure s = "Hello , " ++ s
In diesem Beispiel (2.9) wird die sayHiPure Funktion mit dem Parameter “Spatula“,durch die callRemotePure Funktion aufgerufen.
Listing 2.10: sayHiPM
1 v <- callRemote mynid ( sayHiPM__closure "Jaroslav")2 say $ "Got result " ++ v3 --4 sayHiPM :: String -> ProcessM String5 sayHiPM s = say ("Hello , "++s) >>6 return (sort s)
In diesem Beispiel wird die callRemote Funktion verwendet, sie ruft die FunktionsayHiPM mit dem Parameter “Jaroslav“ auf. Im Gegensatz zu der spawn Funktionist sie synchron und wartet somit, bis das Ergebnis da ist.
2.5 Beispiele 23
Listing 2.11: sayHiIO
1 w <- callRemoteIO mynid ( $(mkClosure ’sayHiIO ’) "Noodle")2 say $ "Got result " ++ show w3 --4 sayHiIO :: String -> IO String5 sayHiIO s = putStrLn ("Hello , " ++ s) >>6 return (reverse s)
Nun wird mittels der callRemoteIO Funktion eine closure aufgerufen, die sich inder IO Monade befindet.
Listing 2.12: simpleSum
1 x <- callRemote mynid (runAnother__closure (simpleSum__closure 1 1))2 say $ "Got result " ++ x3 --4 simpleSum :: Int -> Int -> Int5 simpleSum a b = a + b + 1
In Beispiel (2.12) wird dargestellt, wie einer closures eine closure ubergebenwerden kann. Dies wird erreicht, in dem das Ergebnis der simpleSum closure andie runAnother closure Funktion ubergeben wird und dann mit callRemote aneinen Knoten geschickt wird.
24 2 Cloud Haskell
2.6 Fazit
Durch das Cloud Haskell Framework, ist es Haskell Entwicklern nun leichtergemacht wurden Verteilte Anwendungen zu entwickeln.
Die Installation des Frameworks verlauft bei vorhandener Cabal Umgebung pro-blemlos.
Den Einarbeitungsaufwand fand ich fur Haskell-Entwickler auch gering, da dieHandhabung nach verstehen des Konzeptes recht Intuitiv ist.
Das Framework ist nach meiner Einschatzung auch sehr gut Dokumentiert.
Im Vergleich zu anderen Frameworks die ahnliches leisten wie zum Beispiel akkain Verbindung mit Scala. War die Anwendung sehr vergleichbar. Auch wenn dieKonzepte dahinter etwas auseinander gehen.
Ich finde die Entwickler nehmen dem Programmierer dadurch viel Arbeit ab, die ihmnur unnotig Zeit gekostet hatte und erleichtern somit den Entwicklungsaufwandvon Verteilten Systemen.
Literaturverzeichnis
[1] Jeff Epstein, Andrew P. Black, Simon Peyton-Jones, Towards Haskell in theCloud. Remote Tokyo, Japan. 22 September 2011
[2] Jeff Epstein, Cloud Haskell. https://github.com/jepst/CloudHaskell, (Zugriffam 14.06.2012)
3 Go 1.0Robert Worgul
Inhaltsverzeichnis
3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Die Syntax von Go . . . . . . . . . . . . . . . . . 26
3.2.2 Der erweiterte Funktionsumfang . . . . . . . . . 28
3.2.3 Systemnahe Programmierung in Go . . . . . . . . 28
3.2.4 Reduktion auf das Wesentliche . . . . . . . . . . 29
3.3 Moglichkeiten verteilter Systeme in Go . . . . . . . . . . 30
3.3.1 Goroutines . . . . . . . . . . . . . . . . . . . . . 30
3.3.2 Channels . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Klassische Synchronisierungsmechanismen . . . . 33
3.3.4 Remote Procedure Calls . . . . . . . . . . . . . . 33
3.4 Zusammenfassung und Ausblick . . . . . . . . . . . . . . 34
3.1 Einleitung
Go ist eine junge Programmiersprache, deren Entwicklungsidee auf die heutigenUmstande der Systemprogrammierung zuruckzufuhren ist. Die Notwendigkeit derParallelisierung von Programmablaufen steigt mit der stetig wachsenden Anzahlan Prozessorkernen in modernen Prozessoren.
Die Programmiersprachen wie C, welche sich im Bereich der Systemprogram-mierung etabliert haben, bieten aufgrund ihres Alters und der damals geltendenHardwareverhaltnisse keine Unterstutzung fur die Parallelisierung. Die paralle-le Programmierung ist somit nur uber fremde Bibliotheken moglich, welche inAbhangigkeit von dem Betriebssystem, auf dem das Programm ausgefuhrt wird,implementiert sein mussen. Die Verwendung fremder Bibliotheken hat zur Fol-ge, dass sowohl die parallele Programmierung als auch die dadurch notwendigeSynchronisierung der parallelisierten Ablaufe uneinheitlich, komplex und dadurchunsicher werden [1].
Am 21. September 2007 skizzierten Robert Griesemer, Rob Pike und Ken Thomp-son die Hauptziele einer neuen Programmiersprache. Nach zwei Jahren interner
26 3 Go 1.0
Entwicklung wurde Go am 10. November 2009 als offentliches Open SourceProjekt herausgegeben. Das Hauptziel von Go ist es, eine neue, maschinennaheProgrammiersprache fur die Systemprogrammierung zu entwickeln, welche dieVorteile moderner Programmiersprachen mit der Sicherheit und Geschwindigkeiteiner kompilierten, statisch typisierten Programmiersprache kombiniert [1].
Im Gegensatz zu den gelaufigen Systemprogrammiersprachen bietet Go die folgen-den Vorteile [1]:
Das neue Paketsystem verringert aus Sicht der Abhangigkeitsanalyse unsaube-ren Overhead (bspw. von C-Include-Dateien), wodurch selbst das Kompilierengroßer Programme auf einem einzelnen Rechner wenige Sekunden dauert.
Die Unterstutzung von Garbage Collection gewahrleistet eine sichere Speicher-verwaltung.
Go wurde gestaltet, um Systemsoftware auf Rechnern mit mehreren Prozessorenzu entwickeln. Dafur wurden neue Parallelisierungs- und Synchronisierungs-ansatze eingebunden.
3.2 Grundlagen
In diesem Kapitel wird erlautert, was Go von anderen Systemprogrammiersprachenunterscheidet. Des Weiteren werden daraus folgende syntaktische Eigenheitenbegrundet.
3.2.1 Die Syntax von Go
Die Syntax von Go ahnelt der Programmiersprache C mit Einflussen von Pythonund diversen anderen. Besonderer Wert wurde auf die Einfachheit der Syntaxgelegt. Mit Hilfe des Listings 3.1 wird nun die Syntax von Go naher erlautert.
Listing 3.1: Syntaktische Eigenheiten in Go
package main
import "fmt"
func main() {
var b int = 42
if a := b; a < 10 {
fmt.Println("Hello World")
} else {
3.2 Grundlagen 27
fmt.Println("Nope, Chuck Testa!")
}
}
Das Paketsystem ist Teil des, im Vergleich zu C, machtigen Mechanismus, umAbhangigkeiten zu ermitteln. Jede Quelltextdatei gehort zu einem Package undkann multiple andere Packages importieren. Es konnen neben lokalen Paketenauch Pakete aus Web-Repositorys eingebunden werden, welche zur Kompilierzeitheruntergeladen und ubersetzt werden [2][5].
Die in C obligatorischen Semikolons sind in Go optional und mussen nur verwen-det werden, wenn mehrere Befehle in einer Zeile stehen sollen. Klammern sindweitestgehend nicht mehr notwendig. So wird beispielsweise bei den Bedingungenvon if-Anweisungen komplett auf Klammern verzichtet [2].
Die Deklarationssyntax wurde in eine sprechende Variante geandert, um komplexeDeklarationen von z. B. Funktionszeigern besser lesbar zu gestalten. Durch diesprechende Deklarationssyntax wurde das Schlusselwort var notwendig, um eineDeklaration vom restlichen Quelltext zu unterscheiden. Eine andere Moglichkeitder Deklaration ist der := Operator, welcher den Typ der neuen Variable auf derlinken Seite aus dem Typ der rechten Seite inferiert1 [3].
Weiterhin ist eine korrekte Formatierung des Go-Quelltextes notig. In Go gibt eskeine Warnungen, was einen falsch formatierten Quelltext zu einem Kompilierfehlerwerden lasst. Diese Maßnahme ist theoretisch fur den Parser nicht notwendig,wurde aber ergriffen, um die Lesbarkeit des Quelltextes zu steigern. Ein Beispielfur die strengen Formatierungsregeln sind die geschweiften Klammern. Diesemussen im Java-Einruckstil verwendet werden. Zur einheitlichen Aufbesserung vonz. B. Whitespace-Formatierungen kann das integrierte Werkzeug gofmt verwendetwerden. Allerdings basiert gofmt auf dem selben Parser wie der Kompiler undkann deshalb falsch gesetzte geschweifte Klammern nicht korrigieren [2].
Die Programmiersprache Go besitzt im Unterschied zu C nur die for-Schleife.Deren Syntax wurde angepasst, um die bekannten Schleifentypen nachbilden zukonnen (siehe Listing 3.2).
Listing 3.2: Schleifen in Go
for i := 0; i < 10; i++ { } //for loop
for i < 10 { } //while loop
myMap := map[string]int{"SM":123, "EF":456}
for key, value := range myMap { } //foreach loop
1 Diese Typfestlegung geschieht zur Kompilierzeit und durchlauft somit auch den Type-Checker.
28 3 Go 1.0
3.2.2 Der erweiterte Funktionsumfang
Die im Abschnitt 3.2.1 erlauterten Eigenschaften der Syntax haben die Intention,die Programmiersprache Go leicht lesbar und einfach erlernbar bzw. verwendbar zugestalten. In diesem Abschnitt wird darauf eingegangen, welche zusatzlichen Funk-tionen (im Vergleich zur Programmiersprache C) vom Go-Basispaket unterstutztwerden.
Ein geringer Funktionsumfang ist vorteilhaft fur eine Systemprogrammierspra-che, da dieser den Kompilerbau erleichtert. Somit kann bei neuen Systemenschnell auf eine hohere Programmiersprache gewechselt werden. Aber das Fehlenvon einheitlich integrierten Losungen fur aktuell alltagliche Problemstellungen,wie z. B. Threads und Synchronisierung, fuhrt zur Verwendung unterschiedlicherFremdbibliotheken und somit zu Kompatibilitatsschwierigkeiten auf unterschiedli-chen Systemen. Die Moglichkeiten zur Parallelisierung und Synchronisation in Gowerden im Abschnitt 3.3 besprochen.
Go bietet eine volle Unicode Unterstutzung, sowohl in Variablennamen als auchin Strings. Die Anweisung ∆t = t1 - t2 und das String-Literal "∆t ∈ R" warenalso Beispiele fur gultigen Go-Quelltext [2].
Im weiteren Funktionsumfang der Programmiersprache Go werden [2]:
Mehrfach-Ruckgabewerte unterstutzt,
eine Referenzdatentyp map zur Verfugung gestellt, welcher einem Assoziativarrayoder Dictionary anderer Programmiersprachen entspricht und
ein defer-Schlusselwort eingefuhrt, durch das bei jeder Funktion finally-ahnlicheAnweisungen, unabhangig vom Return-Point, ausgefuhrt werden konnen.
Funktionale Ansatze
Die Moglichkeit, funktionale Ansatze in Go umzusetzen, ist durch die Unterstutzungvon Funktionszeigern prinzipiell gegeben. Funktionszeiger ermoglichen die Imple-mentierung von Higher Order Functions wie
”fold“. Des Weiteren das aus der
funktionalen Programmierung stammende Konzept der Closures, also Funktionen,welche ihren inneren Zustand beibehalten, unterstutzt [6].
3.2.3 Systemnahe Programmierung in Go
Entwickelt als systemnahe Programmiersprache, kann Go diverse Sprachkonstrukte(z. B. Zeiger und Arrays) nicht durch Abstraktion vereinfachen.
Zeiger werden in Go unterstutzt, wodurch der Entwickler die Freiheit hat, selbst
3.2 Grundlagen 29
ressourcenschonend und performant zu programmieren. Auf eine Unterstutzungder Zeigerarithmetik wurde verzichtet [7].
Ein Array in Go entspricht einem Array in C, also einem sequenziell reserviertenStuck Speichers fester Große. Um die Bildung von Teilmengen und die Erweiterungvon Arrays zu vereinfachen, werden in Go Slices anstelle von Arrays verwendet [4].
Ein Slice ist ein Referenztyp, welcher auf einem Array operiert. Dadurch bleibt derGeschwindigkeitsvorteil der hardwarenahen Array-Implementierung erhalten. EinSlice wird durch einen Zeiger auf sein Startelement im referenzierten Array, seineLange und seine Kapazitat reprasentiert. Somit kann ein Slice ohne große Kostenzur Laufzeit verandert und erweitert werden, sofern der referenzierte Array großgenug ist. Sollte im Verlauf des Programms mehr Kapazitat notig sein, als derArray des Slices zur Verfugung stellen kann, muss der Array auf die konventionelleWeise2 erweitert werden. Dafur bietet Go seit der Version 1.0 die Funktion append
[4].
3.2.4 Reduktion auf das Wesentliche
Als Systemprogrammiersprache sollte Go auf das Wesentliche reduziert werden.Zwar wurde der Funktionsumfang im Vergleich zu
”schlanken“ Programmierspra-
chen wie C erweitert (siehe 3.2.2), aber auf andere Mittel moderner Program-miersprachen wurde bewusst verzichtet. In Go ist es beispielsweise nicht moglich,dynamisch zu linken3. Jeglicher Go-Quelltext soll zur Kompilierzeit zur Verfugungstehen. Diese Maßnahme soll zur Vermeidung von Fehlern beitragen [8].
Keine objektorientierte Programmierung
In Go werden weder Klassen noch Vererbung unterstutzt. Ein Grund fur denVerzicht auf das objektorientierte Programmiermodell ist die geringere Performanzdurch den Overhead der intern notwendigen Reprasentation von bspw. Vererbungs-wegen im Vergleich zu prozeduralen Funktionsaufrufen [8].
Es ist jedoch moglich, Methoden auf Strukturen oder Typen zu definieren. Einesolche Methode ist nach ihrer Definition in jeder Instanz einer solchen Struktur(oder Typs) vorhanden.
Weiterhin konnen Interfaces definiert werden. Ein Interface in Go bestimmt,welche Methoden auf einer Struktur oder einem Typ definiert sein mussen. EineStruktur oder ein Typ implementieren ein Interface automatisch, sobald alle durchdas Interface bestimmten Methoden auf ihnen definiert wurden. Dadurch ist
2 Einen neuen, großeren Array reservieren; die Werte des alten Arrays in den neuen kopieren; dieReferenz auf den neuen Array setzen und den Speicher des alten Arrays freigeben.3 Aus Grunden der Kompatibilitat mit diversen vorhandenen APIs (z. B. OpenGL oder WinAPI)ist dynamisches Linken mit C-Bibliotheken jedoch moglich.
30 3 Go 1.0
eine einfache Handhabung von Interfaces und eine vollkommene Unabhangigkeitzwischen Interface- und Implementierungs-Package moglich [2].
Fehlerbehandlung
Das ebenfalls weit verbreitete Konzept der Exceptions wird in Go nicht unterstutzt.Die Behandlung von Fehlern soll so nah wie moglich am Fehlerursprung geschehen.
Die Fehlermeldungen konnen uber die Mehrfach-Ruckgabewerte der Funktionenan den Aufrufer weitergeleitet werden. Mit Go 1.0 wurde der Fehlertyp error
eingefuhrt, welcher als allgemeiner Container fur Fehlermeldungen jeder Art dient[1].
Die Behandlung von schweren Fehlern zur Laufzeit erfolgt mittels panic undrecover. Das Verhalten der panic-Funktion ist dem einer Exception sehr ahnlich.Der Aufruf-Stack wird durchlaufen und das Laufzeitsystem fangt die panic inletzter Instanz und beendet das Programm mit einer Fehlermeldung. Es bestehtjedoch die Moglichkeit, eine panic mit dem Befehl recover aufzufangen, zubehandeln und den Programmablauf fortzusetzen. Dies ist moglich, da der mitdem Schlusselwort defer definierte Code, selbst bei einer panic, beim Verlassender Funktion ausgefuhrt wird [2].
3.3 Moglichkeiten verteilter Systeme in Go
Die Moglichkeiten von Go zur Parallelisierung und Synchronisierung von Pro-grammablaufen sind unkompliziert und geradlinig. Basierend auf Tony HoaresProzessalgebra
”Communicating Sequential Processes (CSP)4“ kann die Paralleli-
sierung durch Goroutines und die Synchronisierung durch Channels implementiertwerden.
3.3.1 Goroutines
Die Goroutines sind eine threadahnliche Moglichkeit, Funktionsaufrufe asynchronund somit parallelisierbar zu gestalten. Eine Goroutine ist eine Funktion, welchekonkurrierend mit anderen Goroutines im selben Adressraum ausgefuhrt wird. DieUmwandlung eines konventionellen Funktionsaufrufs in einen asynchronen erfolgtdurch Hinzufugen des Schlusselwortes go. Im Listing 3.3 wird die Ausgabefunktionfmt.Println() einmal asynchron durch das Schlusselwort go und einmal konven-tionell (blockierend) aufgerufen. Dies hat zur Folge, dass die Ausgabe
”Hello Go!“
4 Weitere Informationen zu CSP konnen unter www.usingcsp.com (7.7.2012) abgerufen werden.
3.3 Moglichkeiten verteilter Systeme in Go 31
entweder vor oder nach der Ausgabe”Hello World!“ erscheinen kann (je nach
Systemzustand).
Listing 3.3: Starten einer Goroutine
go fmt.Println("Hello Go!") //non-blocking call
fmt.Println("Hello World!") //blocking call
Das Erstellen einer Goroutine benotigt nur geringfugig mehr Ressourcen als ein kon-ventioneller Funktionsaufruf. Ein weiterer Vorteil ist die automatische Verteilungder Goroutines auf mehrere Kernel Level Threads durch die Laufzeitumgebung, wo-durch die Blockierung einzelner Goroutines (z. B. durch IO) nicht zur Blockierungaller Goroutines fuhrt [2].
3.3.2 Channels
Durch die Channels bietet Go ein Konzept, welches Kommunikation, Werteaus-tausch und Synchronisierung zwischen Goroutines kombiniert. Ein Channel ist einReferenzdatentyp und kann als
”Pipe“ mit der Standardkapazitat von 1 betrachtet
werden. Wird beispielsweise ein Channel auf einem int erstellt:
ch := make(chan int)
so kann jede Goroutine mit Zugriff auf die Variable ch in den Channel schreibenoder daraus lesen. Die Lese- und Schreiboperationen auf einen Channel erfolgenmit dem Operator <-. Steht der Channel auf der rechten Seite, wird der Wert,der durch den Channel referenzierten Variable, in die Variable der linken Seitegelesen. Dabei blockiert dieser Aufruf, bis etwas aus dem Channel gelesen werdenkann. Steht der Channel auf der linken Seite, wird der Wert des Ausdrucks aufder rechten Seite in den Channel geschrieben. Der Schreibzugriff blockiert, fallsder Channel bereits bis an seine Kapazitatsgrenze gefullt ist [2][7].
Listing 3.4: Schreiben und Lesen in Channels
package main
import "fmt"
func sum(a []int, c chan int) {
sum := 0
for _, v := range a {
sum += v
}
c <- sum // send sum to c
}
32 3 Go 1.0
func main() {
a := []int{7, 2, 8, -9, 4, 0}
c := make(chan int)
go sum(a[:len(a)/2], c)
go sum(a[len(a)/2:], c)
x, y := <-c, <-c // receive from c
fmt.Println(x, y, x + y)
}
Die grundlegende Verwendung von Goroutines und Channels wird nun anhanddes Beispielprogramms von Listing 3.4 erlautert. Die definierte Funktion sum
errechnet die Summe der Elemente des ihr ubergebenen int-Slices und schreibtdas Ergebnis in den ebenfalls ubergebenen Channel. In der main-Funktion wird einzu berechnendes int-Slice deklariert und ein Channel erstellt. Nachfolgend wirddie Funktion sum zweimal asynchron, mit je einer Halfte des int-Slices, aufgerufen.Das Programm ist nun in drei Handlungsstrange unterteilt. Durch das zweimaligeLesen aus dem Channel mittels <-c wird die Goroutine der main-Funktion blockiert,bis die Ergebnisse der beiden nebenlaufigen Aktivitaten verfugbar sind.
Die select-Anweisung auf Channels
Die select-Anweisung bietet die Moglichkeit, auf den Lesevorgang mehrererChannels zu warten. Es werden dabei, wie bei der switch-Anweisung, mittels case
die einzelnen Lesevorgange aufgelistet (siehe Listing 3.5).
Listing 3.5: Die select-Anweisung
func fibonacci(c, quit chan int) {
x, y := 1, 1
for {
select {
case c <- x:
x, y = y, x + y
case <-quit:
fmt.Println("quit")
return
}
}
}
Die select-Anweisung blockiert nur noch, wenn alle angegebenen Falle blockieren.Sollte mehr als ein Fall zur selben Zeit verfugbar sein, wird per Zufall ausgewahlt.
3.3 Moglichkeiten verteilter Systeme in Go 33
Um jegliches Blockieren der select-Anweisung zu verhindern, kann ein default
Fall angegeben werden, welcher betreten wird, wenn alle anderen Falle blockieren[2][7].
3.3.3 Klassische Synchronisierungsmechanismen
Durch das enthaltene Package”sync“ ist es neben Channels ebenfalls moglich,
klassische Synchronisierungsmechanismen wie”mutual exclusion locks“ zu verwen-
den. Im Listing 3.6 wird die Verwendung des Mutex-Locks dargestellt. Weiterhinbietet das Package bspw. den Once-Datentyp. Dieser fuhrt eine ihm ubergebeneFunktion aus und stellt sicher, dass dieser Funktionsaufruf nur einmal geschieht.Weitere Anfragen an Once, diese Funktion auszufuhren, werden ignoriert [9].
Listing 3.6: Verwendung des Mutex-Locks
import "sync"
var m sync.Mutex = sync.Mutex{}
func myFunc() {
m.Lock()
//critical section
m.Unlock()
}
Sollte die Notwendigkeit bestehen, eigene Synchronisierungsmechanismen zu im-plementieren, stellt das sync/atomic-Package die atomaren GrundoperationenAdd, CompareAndSwap, Load und Store auf Basisdatentypen int32, int64, uint32,uint64, uintprt und unsafe.Pointer zur Verfugung [10].
3.3.4 Remote Procedure Calls
Mit Remote Procedure Calls (RPC) ist es moglich, eine Funktion eines RPC-Serversaufzurufen und deren Ergebnis durch diesen zu beziehen. Go unterstutzt diesesVerfahren durch das Package
”net/rpc“.
Das rpc-Package bietet Zugriff auf exportierte Methoden5 eines Objektes uber einNetzwerk oder sonstige I/O Verbindungen. Die Methoden des Objektes mussenfolgende Bedingungen erfullen, um am Client verfugbar zu sein [11]:
die Methode muss exportiert sein,
die Parameter der Methode mussen exportierte oder Basisdatentypen sein,
5 Exporte werden in Go uber Groß- und Kleinschreibung des ersten Buchstaben ihres Namensgesteuert. Ein großer Anfangsbuchstabe bedeutet public, ein kleiner private.
34 3 Go 1.0
der zweite Parameter muss ein Zeiger sein und
die Methode muss den Ruckgabetyp error haben.
Durch diesen Funktionsaufbau konnen alle Funktionen reprasentiert werden. Derschematische Aufbau einer gultigen RPC-Methode ware wie folgt [11]:
func (t *T)MethodName(argType T1, replyType *T2)error
Der erste Parameter enthalt alle benotigten Funktionsparameter (z. B. in einerStruktur) und der zweite Parameter stellt den Ruckgabewert der Funktion dar.Zur Fehlerauswertung kann der allgemeine Typ error (Funktionsruckgabewert)verwendet werden.
3.4 Zusammenfassung und Ausblick
Go ist ein gelungener Ansatz, eine performante Systemprogrammiersprache zuentwickeln. Besonders die Goroutines, welche die Komplexitat der Parallelisie-rung stark abstrahieren, ermoglichen in Kombination mit der Synchronisierunguber Channels ein einheitliches und intuitiven Konzept zur Programmierung aufRechnern mit mehreren logischen Prozessoren.
Da es nicht moglich ist, Go-Code dynamisch zu linken, ist die Realisierung einesPlugin-Systems schwer moglich. Hierbei musste bspw. darauf zuruckgegriffenwerden, einen Interpreter fur eine Skriptsprache wie Lua einzubauen und diePlugins zur Laufzeit zu interpretieren. Diese Losung wirkt sich allerdings in derPerformanz der Plugins aus.
Weiterhin konnte die Parallelisierung noch einfacher werden, denn die Goroutineslaufen standardmaßig alle auf einem logischen Prozessor und werden nicht verteilt.Um zu erreichen, dass alle vorhandenen logischen Prozessoren verwendet werden,muss der folgende Befehl ausgefuhrt werden [2]:
runtime.GOMAXPROCS(runtime.NumCPU())
Go konnte sich in der Entwicklung performanter, plattformubergreifender An-wendungen etablieren und dabei anderen plattformunabhangigen Sprachen wieJava in Sachen Performanz Konkurrenz machen. Eine denkbare Moglichkeit dafurware ein neues Datenbank Management System. Die integrierten Methoden zurParallelisierung und Synchronisation in Kombination mit der Performanz durchdie Systemnahe und der vollen Unicode-Unterstutzung scheinen wie geschaffendafur zu sein.
Literaturverzeichnis 35
Literaturverzeichnis
[1] Google Inc., FAQ – The Go Programming Language.http://golang.org/doc/go faq.html, 08.07.2012.
[2] Google Inc., Effective Go – The Go Programming Language.http://golang.org/doc/effective go.html, 08.07.2012.
[3] Google Inc., Go’s Declaration Syntax – The Go Programming Language.http://golang.org/doc/articles/gos declaration syntax.html, 08.07.2012.
[4] Google Inc., Slices: usage and internals – The Go Programming Language.http://golang.org/doc/articles/slices usage and internals.html, 08.07.2012.
[5] Google Inc., How to Write Go Code – The Go Programming Language.http://golang.org/doc/code.html, 08.07.2012.
[6] Google Inc., First-Class Functions in Go – The Go Programming Language.http://golang.org/doc/codewalk/functions/, 08.07.2012.
[7] Google Inc., A Tour of Go. http://tour.golang.org/, 08.07.2012.
[8] Davis, Ian, 5 Weeks of Go. http://blog.iandavis.com/tag/golang/, 08.07.2012.
[9] Google Inc., Package sync – The Go Programming Language.http://golang.org/pkg/sync/, 08.07.2012.
[10] Google Inc., Package atomic – The Go Programming Language.http://golang.org/pkg/sync/atomic/, 08.07.2012.
[11] Google Inc., Package rpc – The Go Programming Language.http://golang.org/pkg/net/rpc/, 08.07.2012.
36 3 Go 1.0
4 GridGainDanny Rubner
Inhaltsverzeichnis
4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Was ist GridGain? . . . . . . . . . . . . . . . . . . . . . 38
4.3 Warum GridGain? . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Compute und In-Memory-Technologie . . . . . . . . . . . 40
4.4.1 In-Memory Data Grid . . . . . . . . . . . . . . . 40
4.4.2 Compute Grid . . . . . . . . . . . . . . . . . . . 42
4.5 High Performance und Cloud Computing . . . . . . . . . 43
4.5.1 Cloud Computing . . . . . . . . . . . . . . . . . 43
4.5.2 High Performance . . . . . . . . . . . . . . . . . 43
4.5.3 GridGain als High Performance Cloud Application 43
4.6 IaaS, PaaS und SaaS . . . . . . . . . . . . . . . . . . . . 44
4.6.1 IaaS . . . . . . . . . . . . . . . . . . . . . . . . 44
4.6.2 PaaS . . . . . . . . . . . . . . . . . . . . . . . . 44
4.6.3 SaaS . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6.4 Einordnung von GridGain . . . . . . . . . . . . . 45
4.7 Ein Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.7.1 Schritt 1: Knoten starten . . . . . . . . . . . . . 46
4.7.2 Schritt 2: Ausfuhren des Codes . . . . . . . . . . 46
4.7.3 Schritt 3: Endergebnis . . . . . . . . . . . . . . . 47
4.8 Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.8.1 Verfugbarkeit . . . . . . . . . . . . . . . . . . . . 48
4.8.2 Lizenz . . . . . . . . . . . . . . . . . . . . . . . 48
4.8.3 Support . . . . . . . . . . . . . . . . . . . . . . . 49
4.9 Schlusswort . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.10 Quellen . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
38 4 GridGain
4.1 Einleitung
Das Sammeln, Bearbeiten und Verarbeiten von Daten spielt in der heutigenGesellschaft eine wesentliche Rolle. So werden regelmaßig verschiedene Formenvon Nutzerdaten in Firmen angelegt, Bestellungen verarbeitet und Datengesichert. Doch stellt sich die Frage, wie mit der unglaublichen Menge anDaten in namenhaften Firmen, wie Sony, Amazon oder TomTom umgegan-gen werden kann? Je großer eine Firma ist, desto mehr Nutzer nehmennaturlich Gebrauch von verschiedenen angebotenen Diensten, die von diesenFirmen zur Verfugung gestellt werden. Doch geht es gerade in der Informatikdarum, diese Daten, welche durch Dienste erzeugt und von diesen verwen-det werden effizient zu speichern und vor allem mit diesen wirkungsvoll umzugehen.
GridGain ist eine Technologie, die eine effiziente Datenverarbeitung ermoglicht. Inden folgenden Abschnitten wird deshalb genauer auf diese Technolgie eingegangen,um zu verdeutlichen, was GridGain eigentlich ist, welche Vorteile bei der Nutzungvon GridGain bestehen und wie GridGain, anhand eines Beispiels, funktioniert.
4.2 Was ist GridGain?
GridGain ist eine Java basierte Open Source Middleware-Software aus dem Hause“GridGain Systems”. Die Aufgabe der Software ist die Echtzeit-Verarbeitung undAnalyse von umfangreichen Datensatzen sowie das Parallelisieren von Prozessen.Diese Plattform ermoglicht das Entwickeln von verteilten Anwendungen furverteilte Systeme, welche große Performance Anforderungen besitzen. Die Softwareverfugt uber den Vorteil sowohl fur einzelne Systeme, als auch fur umfassendeDaten-Clouds Anwendung zu finden. Der Kern von GridGain verfolgt zweierleiAnsatze. Zum einen soll GridGain ein machtiges Werkzeug in Verbindung mitData Warehousing sein, zum anderen elegant einfach im Umgang.
Die Funktionalitat von GridGain ist auf zwei Bereiche fokussiert. Der Gebrauchvon Daten Grids ist einer dieser Bereiche, welcher das Be- und Verarbeiten vonDatensatzen ermoglicht. Des Weiteren ist die Moglichkeit gegeben, Datensatzemit Hilfe von In-Memory-Technologie zu verarbeiten, um moglichst schnell undeffizient Ergebnisse erzielen zu konnen.
GridGain ist fur Business Anwendungen und Data Warehouse, wie SQL oder ERPgeeignet.1 Die Positionierung von GridGain lasst sich demnach zentral auffinden.
1 Siehe Abb. 4.1, Seite 39
4.2 Was ist GridGain? 39
Das heisst, zwischen Anwendungen oder “Business Intelligence”-Software undder eigentlichen Daten-Cloud, dem Long-Term-Storage oder Data Warehousing.Eine große Starke von GridGain ist die Verarbeitung von “Live Data”. Somitkonnen gerade einkommende Daten direkt verarbeitet und fur Anwendungenoder Datenbanken zur Verfugung gestellt werden. Der Vorteil der Anwendungliegt vor allem in der Unterstutzung von In-Memory-Technologie die eine hohePerformance gewahrleistet und mit geringen Verarbeitungslatenzen von Datenbesticht, da ein Großteil der Daten von GridGain im Speicher behalten wird,um mit diesen zu operieren. Fur die Effizienz der gespeicherten Daten ist die“Intelligence Caching Technology” verantwortlich. Diese speichert nur oft genutzteoder wichtige Daten im Speicher. Die weniger wichtigen Daten verbleiben derweilin Langzeitspeicherung oder im Data Warehouse.
Abbildung 4.1: Ubersicht; Positionierung von GridGain zwischen Business Anwendungund Data Warehousing. [GGFE]
Mit der GridGain Architektur besteht die Moglichkeit Business Daten in zweiverschiedene Richtungen zu leiten. Entweder von der Business Anwendung undexternen Quellen durch GridGain in ein Data Warehouse oder Bulk-Loaded vomData Warehouse in In-Memory Daten Grids fur geringe Latenzen und Echtzeitver-arbeitung. Ersteres, auch genannt “Up-Stream”, ist gut geeignet fur Streaming-und Transaktionsdaten, die nicht direkt in einem Data Warehouse gespeichertwerden konnen, da diese effektiv in Echtzeit verarbeitet werden mussen. Die zweiteMethode, “Down-Stream”, ist ideal fur die Verarbeitung von schon gesammelten,historischen Daten. In vielen Fallen werden beide Moglichkeiten durch Anwendun-gen genutzt. GridGain ermoglicht sowohl “Up-”, als auch “Down-Stream”.
40 4 GridGain
4.3 Warum GridGain?
Durch das Unterstutzen der beschriebenen vorangegangenen Bereiche in Ab-schnitt 4.1 ergeben sich fur Anwendungen, die GridGain -Methoden implementierenfolgende Vorteile:
* arbeiten in einem “Zero-Deployment” Modus2
* auf- und ab-skalieren je nach Bedarf
* cachen verteilter Daten in Datengrids
* schnelleres losen von Aufgaben durch MapReduce
* speichern und abfragen von JSON Objekten
* und viele weitere3 Vorteile
4.4 Compute und In-Memory-Technologie
Das Berechnen von Grids und Nutzen von In-Memory-Technologien in GridGaindient dem Losen des Problems mit verteilten Daten und deren verteilten Berech-nungen zuarbeiten. Das heißt, dass diese beiden Technologien fundamental furverteilte Systeme sind und diese sowohl die Parallelisierung von Berechnungen alsauch die Parallelisierung von Datenspeicherung und -zugriff ermoglichen. GridGainist die erste Software Middleware, die “In-Memory Data Grids” und “In-MemoryCompute Grids” in einem Produkt unterstutzt, um Parallelisierung zu ermoglichen.Beide Technologien sind essentiell fur moderne verteilte Datenverarbeitung, diewiederum wesentliche Vorteile fur den Anwender bereit halten. Unter diese Vorteilefallt das Arbeiten mit einheitlichen APIs fur Datenzugriff und -Verarbeitung, ein-malige einheitliche Konfiguration, die drastisch gesenkte Lernkurve und weitere4
Vorteile.
4.4.1 In-Memory Data Grid
“In-Memory Data Grids” bilden die Kerntechnologie von GridGain. Durch dieseGrids wird die Moglichkeit gegeben, umfassende Datensatze mit geringer Latenz imEchtzeitkontext zu verarbeiten. Somit konnen Daten von einem einzigen Computerbis hin zu mehreren Terabytes Daten skaliert werden. Die “In-Memory Data Grid”-Technologie unterstutzt den Fall der Parallelisierung der Datenspeicherung durch
2 “Zero-Deployment Mode” ist die Vermeidung von weniger relevanten IT-Aufgaben3 Siehe [WIGG]4 Siehe [GGFE]; Abschnitt “Integrated In-Memory Data Grid and Compute Grid”
4.4 Compute und In-Memory-Technologie 41
Speicherung partitionierter Daten durch “In-Process Memory”. Dass heißt, dassDaten durch das “In-Memory Compute Grid” so nahe wie moglich und so schnellwie moglich an der Anwendung sein sollen.
Abbildung 4.2: Einsatz von “Data Grids”; Gegenuberstellung von Berechnungsprozesseneinzelner Knoten, die auf “Data Grids” sowohl zuruckgreifen (Grafik; unten), als auchnicht zuruckgreifen (Grafik; oben).[GGDG]
Der Vergleich5 von Verarbeitungen mit “In-Memory Data Grids” und ohne Gridszeigt, dass die Verarbeitung einer Anfrage mit verschiedenen Schlusseln (K1, K2
und K3) in einem Prozess ohne Daten Grids zunachst Ergebnisse (V1, V2 und V3)liefert, wenn diese Anfrage mit den Schlusseln an eine Datenbank geleitet werden.Allerdings mussen die Daten fur die weitere Verarbeitung, falls diese nochmalsbenotigt werden, erneut angefragt werden. Somit wiederholt sich der Prozess.6
Beim Einsatz von “In-Memory Data Grids” werden die einzelnen Anfragen (K1, K2
und K3) auf verschiedene Knoten ((K1; V1), (K3; V3) und (K3; V3)) verteilt undan das System weitergeleitet, welches die Ergebniswerte (V1, V2 und V3) liefert.7
Dass System gibt die einzelnen Ergebnisse an die Knoten zuruck und diese reichendie Ergebnisse an den Absender der Anfrage weiter. “In-Memory Data Grids”erlauben es, dass Grids und Clouds als eine einfache virtuelle Speicherbank oder als“virtuelles Gedachtnis” angesehen werden konnen. Diese beinhalten partitionierteDaten und unterstutzen verschiedene Caching-Strategien. Das Ziel ist es, eineextrem hohe Verfugbarkeit von Daten zu ermoglichen, so dass diese Daten direktim Speicher in verteilter Form hinterlegt sind.
5 Siehe Abb. 4.2, Seite 416 siehe Abb. 4.2, Seite 41; oben7 siehe Abb. 4.2, Seite 41; unten
42 4 GridGain
4.4.2 Compute Grid
Bei “Compute Grids” handelt es sich ebenfalls um eine Kerntechnologie vonGridGain. Diese Technologie ermoglicht die Parallelisierung von Berechnungen aneinem oder mehreren Knoten.
Abbildung 4.3: Einsatz von “Compute Grids”; Gegenuberstellung von Berechnungspro-zessen, die auf “Compute Grids” sowohl zuruckgreifen (Grafik; unten), als auch nichtzuruckgreifen (Grafik; oben).[GGCG]
Wie in der Grafik8 zu sehen, wird eine Berechnung (C) an einem Computerdurchgefuhrt. Diese Berechnung benotigt eine gewisse Zeit (T) um ein Resultat(R) zu liefern. Bei der Anwendung von “Compute Grids9” wird die Berechnung (C)in mehrere Berechnungen oder Teile (C1, C2 und C3) zerlegt und an verschiedeneKnoten weitergereicht, die diese einzelnen Berechnungen durchfuhren. Die Knotenliefern anschließend die einzelnen Ergebnisse (R1, R2 und R3) zuruck, welcheszu einem Endergebnis (R) zusammengesetzt wird. Die zu verarbeitende Zeit(T) resultiert aus der Maschine, die am langsten fur die Berechnung benotigtund dem liefern sowie zusammensetzen der Ergebnisse. In der Regel ist diesesverteilte Arbeiten wesentlich Zeit-extensiver als die Verarbeitung durch eine einzelneMaschine. Das Ziel, der Anwendung von “Compute Grids” ist das berechnen undlosen von umfassenden Berechnungen durch mehrere Knoten.
8 Siehe Abb. 4.3, Seite 42; oben9 Siehe Abb. 4.3, Seite 42; unten
4.5 High Performance und Cloud Computing 43
4.5 High Performance und Cloud Computing
GridGain wird als “High Performance Cloud Computing” Anwendungen be-schrieben. “High Performance” und “Cloud Computing” sind die fundamentalenGrundsatze, die in der GridGain-Philosophy verankert sind.
4.5.1 Cloud Computing
“Cloud Computing” ist, laut den Entwicklern, ein Synonym fur die traditionelleverteilte Programmierung.10 Unter “Cloud Computing” wird aus heutiger Sichtdie Bereitstellung von Infrastrukturen, Plattformen und Software verstanden.Mit Infrastrukturen kann beispielsweise die Bereitstellung von Rechnenleistungund Speicherplatz gemeint sein. Dabei wird der Zugriff fur den Nutzer uber einNetzwerk, zum Beispiel das Internet oder firmeneigene Intranets ermoglicht. Durch“Cloud Computing” wird die Parallelisierung von Verfugbarkeit und Verarbeitungvon Datengrids in GridGain ermoglicht. Beide Aspekte sind absolut entscheidendfur skalierbare, verteilte Systeme.
4.5.2 High Performance
“High Performance” ist ebenfalls eine Anforderung von GridGain an Cloud-Anwendungen. Die meisten heutigen Cloud-Anwendungen erfullen die Anforde-rung an hohe Leistung nicht. Dabei sollen “High Performance”-AnwendungenCloud-Distributionen nutzen, um die Skalierbarkeit und Leistung zu erreichen, dietheoretisch fur eine einzige Verarbeitungseinheit unerreichbar ist. Nicht-“HighPerformance”-Anwendungen nutzen Cloud-Distributionen nur als okonomischeoder bequeme Bereitstellungsoptionen.
4.5.3 GridGain als High Performance Cloud Application
Mit Beiden zuvor genannten Aspekte zusammengenommen, kann GridGain als“High Performance Cloud Application” angesehen werden, denn GridGain ist furdie einfache Entwicklung von verteilten Software-Systemen entwickelt worden. DesWeiteren unterstutzt GridGain Skalierbarkeit und Leistung fur Software-Systeme,die zum verteilten Kontext gehoren.
10Ebd. [GGCC]
44 4 GridGain
4.6 IaaS, PaaS und SaaS
Die Begriffe “IaaS”, “SaaS” und “PaaS” werden heute, ohne jegliche weitereAusfuhrungen oder genaue Definitionen, gelaufig im Sprachgebrauch verwendet.Jedoch sind nur die ersten beiden Begriffe wirklich aus definiert. Der Begriff “PaaS”hingegen weniger. In diesem Abschnitt wird auf die einzelnen Begriffe eingegangenund uber die Lokalisierung von GridGain in diesem Zusammenhang gesprochen.
4.6.1 IaaS
“IaaS” ist eine der drei Servicearten und steht fur “Infrastructure As a Service”.Dieser Begriff wird oft als “Cloud Computing” beschrieben, gemeint ist jedoch dieUnterstutzung von virtuellen Berechnungsressourcen als Service. Als Beispiel kannhier “Amazon EC2” angefuhrt werden. Es handelt sich um das eigne Amazon Da-tencenter, welches gegen Bezahlung nicht genutzte Rechnerkapazitat zur Verfugungstellt. Durch das Einsetzen von virtualisierter Hardware, wie “Virtual Machines”von VMWare oder Vitrix, auf den hauseigenen Servern kann ein Management uberden Web Browser realisiert werden, um die einzelnen “Virtual Machine”-Instanzenzu verwalten. “IaaS” kann sowohl offentlich (“public”), als auch privat (“private”)sein. Mischungen (“hybrid”) sind ebenfalls moglich. Offentliche Infrastrukturensind offentlich zuganglich. Beispielsweise die Zugriffsvergabe fur jeden an ein Da-tencenter. Private Strukturen sind meist fur die eigene Nutzung von Organisationenund Firmen erstellte individualisierte Infrastrukturen. Die Unterstutzung beiderVerhaltensweisen ist Aufgabe von hybriden Strukturen. Private und offentlicheInfrastrukturen (Clouds) sind fur gewohnlich von physikalischer Struktur. HybrideClouds jedoch eher als virtuelle Cloud anzusehen, denn diese sitzen am “Kopf”einer physischen offentlichen oder privaten Cloud und unterstutzen nahtlos dieEndbenutzer in Bezug auf Cloud- oder “IaaS”-Transparenz.
4.6.2 PaaS
“PaaS” definiert eine Plattform als einen Dienst und steht fur “Platform As aService”. Fur “PaaS” gibt es keine einheitliche Definition, vielmehr nur Beschrei-bungen, was man unter dieser Abkurzung gemeint ist: Die Plattform unterstutztden “IaaS”-Anbieten oder -Provider und fugt weitere Dienstleistungen hinzu. Dieseerweiterten Dienste bestehen aus Bereitstellungs- und Beschaffungsservices, mitdem Ziel, der “Support Application Multi-Tenancy”. Also Eigenschaften zumVerwalten mehrerer Anwendungen auf einer oder mehreren virtuellen Maschinen.
4.6 IaaS, PaaS und SaaS 45
4.6.3 SaaS
Der letzte Begriff “SaaS”, also “Software As a Service”, definiert die Software alseinen Dienst und hat relativ wenig mit “IaaS” oder “PaaS” zu tun. Dieser Dienstist vorstellbar mit dem Aufrufen einer Anwendung im Browser. Diese Anwendungist somit eine “SaaS”-Abwendung.
4.6.4 Einordnung von GridGain
Mit GridGain besteht die Moglichkeit mit “IaaS”-, wie etwa Amazons AWS,oder “PaaS”-Diensten zu arbeiten.11 Jedoch ist GridGain vollkommen unabhangigvon beiden genannten Servicearten. GridGain kann komplett ohne spezifischeCloud-, Grid- oder Cluster-Infrastruktur auskommen. Diese Eigenschaft ist eine derSchlusselvorteile von GridGain. Somit ist die Unterstutzung fur Entwickler gegeben,welche die gleichen Services auf verschiedenen Geraten, wie Android-Systeme,Laptops, mehrere Server, Grids oder Clouds zur Verfugung stellen mochten.
Abbildung 4.4: IaaS, PaaS und SaaS [IPS]
11Siehe Abb. 4.4, Seite 45
46 4 GridGain
4.7 Ein Beispiel
Das Trivial-Beispiel besteht aus drei Schritten:
1. Starten der einzelnen Konten
2. Ausfuhren des Codes
3. Ergebnis erhalten
4.7.1 Schritt 1: Knoten starten
Im ersten Schritt werden die einzelnen Knoten gestartet.12 Dies geschieht durchdas Ausfuhren des Befehls “ggstart” in der Konsole. Anschließend wird einAusdruck gezeigt, der besagt, um welche GridGain Version es sich handelt.Außerdem werden weitere Informationen ausgegeben, wie etwa der genutzteModus oder um welchen Nutzer es sich handelt.
Abbildung 4.5: Auszug aus der Konsole, nach dem Starten eines Knotens.
4.7.2 Schritt 2: Ausfuhren des Codes
Nachdem starten des Knotens wird der eigentliche Code ausgefuhrt.13 In diesemCode wird uber die Main-Methode, nach dem Importieren der Klassen, eineFunktion “MapReduceCount” aufgerufen mit einem String, “Java GridGainMapReduce”, als Parameter. Das Ziel dieser Funktion ist es, die Zeichen dereinzelnen Worter, die durch ein Leerzeichen getrennt worden sind, zu zahlen.Das Ergebnis wird an die Main-Methode zuruckgegeben und mit “Count is:”auf dem Bildschirm ausgegeben. Innerhalb der Main-Methode wird, neben zwei
12Siehe Abb. 4.5, Seite 4613Siehe Abb. 4.6, Seite 47
4.7 Ein Beispiel 47
anderen Knoten die in dem Beispiel uber die Konsole gestartet wurden, einweiterer Knoten gestartet, mit “G.start()”, und nach dem Zahlvorgang mit“G.stop(true)” wieder gestoppt. In der “mapReduceCount”-Funktion wird dieeigentliche “Reduce”-Methode aufgerufen, die fur das Zahlen verantwortlich ist.Der erste Parameter “SPREAD” der Methode beschreibt, wie die Aufgabe, alsoder zweite Parameter, an die einzelnen Knoten verteilt werden soll. Der letzteParameter “F.sumIntReducer()” setzt die Teilergebnisse der Knoten zu einemGesamtergebnis zusammen, welches uber “return” an die Main-Funktion furdie Ausgabe zuruckgegeben wird. Innerhalb des zweiten Parameters, wird dereigentlich String anstelle der Leerzeichen geteilt und an die einzelnen Knotenubergeben, die mit “Calculating for: ” den Namen des Strings, von dem dieZeichen gezahlt werden sollen, ausgeben. Anschließend wird die Lange des Stringsan den Hauptknoten zuruckgegeben.
Abbildung 4.6: Auszug des auszufuhrenden Codes.
4.7.3 Schritt 3: Endergebnis
Im letzten Schritt wird jeweils das Gesamtergebnis dargestellt.14 In den erstenbeiden Auszugen werden die einzelnen Strings gezeigt, fur dem der Knoten verant-wortlich ist, namlich “MapReduce” und “GridGain”. In der letzten Grafik wird der
14Siehe Abb. 4.7, Seite 48
48 4 GridGain
String “Java” gezeigt, wie auch das Endergebnis, “Count is: 21”, des Zahlvorgangs.
Abbildung 4.7: Auszug der einzelnen Ausgaben der Knoten sowie des Endergebnisses.
Weitere Beispiele existieren auf der Homepage oder im Youtube-Channel vonGridGain.15
4.8 Anhang
Die aktuelle Version von GridGain kann nach erfolgreicher Registrierung unterhttp://www.gridgain.com/download/ heruntergeladen werden. Diese beinhaltetdie Bibliotheken und Beispiele fur die jeweilige gewunschte ProgrammierspracheJava, Scala oder Groovy.
4.8.1 Verfugbarkeit
GridGain ist in drei verschiedenen Versionen verfugbar:
* “Compute Grid”-Edition
* “Data Grid”-Edition
* “Big Data”-Edition
Alle Editionen sind als Open Source verfugbar. Weiterfuhrend existiert noch eineCommunity-Edition. Die beinhaltenden Features der einzelnen Pakete16 konnenauf der GridGain-Homepage betrachtet werden.
4.8.2 Lizenz
Fur GridGain stehen zwei gultige Lizenzen zur Verfugung:
15Fur weiterfuhrende Informationen siehe Quellen - Internetreferenzen16Siehe [GGPU]
4.9 Schlusswort 49
* GridGain Community Edition: Diese Lizenz ist freie Open-Source-Software undlizenziert unter GPL17 Version 3
* GridGain Enterprise Edition: Diese Lizenz ist Closed-Source, kommerziell lizen-ziert18 und somit nicht frei zuganglich
Die aktuelle EULA (“End-Used License Agreement”) fur die Enterprise Edition istim GridGain Installationshauptverzeichniss, nach der Installation von GridGrainverfugbar oder auf der GridGain Internetseite19.
4.8.3 Support
Es gibt einen freien GridGain Support, durch die aktive Community im Forum,ebenfalls zu finden auf der GridGain-Homepage20 unter dem Reiter “Forums”.Außerdem steht ein kommerzieller Service zur Verfugung, durch das GridGain-Unternehmen.
4.9 Schlusswort
GridGain ist eine leistungsfahige und effiziente Middleware-Software, die durchverschiedene In-Memory-Technologien umfangreiche Datensatze verarbeiten undkomplexe Berechnungen durchfuhren kann. Sie ist durch die Moglichkeit desEinsatzes von Knoten durchaus fur verteiltes Arbeiten geeignet und durch dieVerfugbarkeit verschiedener Pakete, die zum Download bereitstehen, an diverseAusgangssituationen anpassbar. Dadurch, dass GridGain außerdem fur Java-, Scala-und Groovy-Entwickler verfugbar ist, wird auch ein breites Spektrum an Entwicklernangesprochen. Die einfache Integration in eine Anwendung erleichtert stark dieEinbettung von GridGain in eigene Anwendungen. Alles in allem ist GridGain eineSoftware, die stark zur Erleichterung im Kontext des verteilten Arbeitens beitragtund durch standige Weiterentwicklungen zukunftig an Interesse gewinnen wird.
17Stand 05. Juni 2012; Siehe [GGLI]18Stand 05. Juni 2012; Ebd.19Siehe [GGHP]20Ebd.
50 4 GridGain
4.10 Quellen
Internetreferenzen:
* Offizielle GridGain Website;URL: http://www.gridgain.com
* Blog des GridGain-Systems CEO Nikita Ivanov;URL: http://gridgaintech.wordpress.com/
* Dokumentation;URL: http://wiki.gridgain.org
* GridGain Youtube Channel;URL: http://www.youtube.com/user/gridgain
Bucher:
* [GG10] “Real time Big Data Processing With GridGain” (2010) Ivanov,N.; Setrakyan, D.Letzter Aufruf am 11. Mai 2012URL: http://www.gridgain.com/book/book.html
Literaturverzeichnis
[GGHP] “GridGain”-Homepage;Letzter Aufruf am 05. Juni 2012URL: http://www.gridgain.com
[WIGG] Siehe [GG10]; Abschnitt: “What is GridGain?”
[GGCC] Siehe [GG10]; Abschntt: “Cloud Computing”
[IPS] Siehe [GG10]; Abschnit: “IaaS, PaaS and SaaS”
[GGFE] Abschnitt: “GridGain = Real time Big Data”;Letzter Aufruf am 20. Mai 2012URL: http://www.gridgain.com/features/
[GGDG] Abschnitt: “In-Memory Data Grid”;Letzter Aufruf am 22. Mai 2012URL: http://www.gridgain.com/features/in-memory-data-grid/
[GGCG] Abschnitt: “Compute Grid”;Letzter Aufruf am 22. Mai 2012URL: http://www.gridgain.com/features/compute-grid/
Literaturverzeichnis 51
[GGPU] Abschnitt: “Product Matrix”;Letzter Aufruf am 02. Juli 2012URL: http://www.gridgain.com/purchase/product matrix/
[GGLI] Abschnitt: “License”;Letzter Aufruf am 05. Juni 2012URL: http://www.gridgainsystems.com/wiki/display/GG15UG/License#License-GridGain3.0CommunityEditionGeneralPublicLicense%28GPLv3%29
52 4 GridGain
5 Jini - Java Intelligent Net-work Interface
Tim Achtert
Inhaltsverzeichnis
5.1 Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2 Entwicklung JINI . . . . . . . . . . . . . . . . . . . . . . 54
5.2.1 Was ist Jini? . . . . . . . . . . . . . . . . . . . . 54
5.2.2 Werdegang . . . . . . . . . . . . . . . . . . . . . 54
5.2.3 Ziele von Jini . . . . . . . . . . . . . . . . . . . . 56
5.3 Dienstkonzept . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.1 Komponenten einer Jini - Architektur . . . . . . . 57
5.3.2 Ablauf der Dienstvermittlung . . . . . . . . . . . 58
5.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.5 Abbildungen . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.6 Quellenverzeichnis . . . . . . . . . . . . . . . . . . . . . 62
5.1 Hintergrund
Im Jahr 1994 wurde der erste, vollstandig auf Java basierende Webbrowser mitder Fahigkeit des Herunterladens ausfuhrbarer Codeskripte, sogenannten Applets,von Sun Microsystems entwickelt.
Im Zuge dieser Entwicklung wurde die Moglichkeit des Austauschens von Codezwischen zusammenarbeiteten Netzwerken und Endgeraten, von den Sun Microsys-tems Entwicklern unter dem Namen Jini, in einem experimentellen Projekt weitervoran getrieben. Die Verbreitung sollte sich dabei nicht nur auf Computersystemebeschranken. Im Gegenteil, diese Technik sollte in Geraten aller Art, besonders imHaushalts- und Unterhaltungselektronikbereich, Verwendung finden.
Das diese Gerate, speziell Kleingerate, Prozessor und Speicher besitzen konnen,um eine Java Virtual Machine1, zur Berechnung und Ausfuhrung von Java - Code,
1 Abk.:JVM
54 5 Jini - Java Intelligent Network Interface
ausfuhren zu konnen, war zu dieser Zeit noch Wunschdenken. Die heutige Entwick-lung zeigt jedoch, dass dies in den kleinsten Geraten moglich ist. Endgeraten, wiebeispielweise Toastern oder Mikrowellen, konnten so die Moglichkeit gegeben wer-den an Netzwerkgemeinschaften teilzunehmen. Diese Zukunftsvorstellung spiegeltsich auch in der Werbeaussage aus dieser Zeit, �the network is the computer�2,von Sun Microsystems wieder.
5.2 Entwicklung JINI
In diesem Kapitel werden Grundgedanke des Frameworks Jini, die Ziele und derWerdegang, von der ersten offiziellen Vorstellung bis heute, naher erlautert.
5.2.1 Was ist Jini?
Jini ist, einfach ausgedruckt, eine auf der Programmiersprache Java basierendeArchitektur, mit deren Hilfe sich Dienste im Netzwerk finden, miteinander kom-munizieren und sich gegenseitig nutzen konnen. Das Konzept bemuht sich dabeiAd - Hoc Vernetzung, das sogenannte spontaneous networking3, zu realisieren.Der entscheidende Vorteil dabei ist, dass keine Treiberinstallation mehr notig ist,sondern die Gerate sofort nutzbar sind, da das System bzw. das Jini - Konzeptdiesen Vorgang automatisiert.
Der Begriff Jini steht dabei offiziell fur Java Intelligent Network Interface. Inder Jini - Community wurde die Abkurzung teilweise als Jini Is Not Initialsaufgeschlusselt.
Das Jini Logo zeigt eine Wunderlampe, was die Vermutung zu lasst, dass es sichbei dem Namen Jini um ein Wortspiel aus Java und dem englischen Wort Genie,dem Flaschengeist aus der Wunderlampe aus den Sagen aus 1000 und 1 Nacht,handelt konnte.
5.2.2 Werdegang
Die Entwicklung von Jini startete 1997 als internes, experimentelles Projekt. ImJahre 1999 wurde Jini erstmals der Offentlichkeit vorgestellt und erste Beta -Versionen veroffentlicht. Jini war dabei eines der ersten großeren Projekte welchesvom Sun Marketing als Open Source herausgegeben wurde, um die Verbreitungder Technologie zu sichern.4 Eine Jini - Community wurde ebenso ins Leben
2 �das Netzwerk ist der Computer�3 spontanes vernetzen4 Vgl. Sommer P.: Jini - Konzepte von Betriebssystem-Komponenten, Universitat Erlangen, S.1-7
5.2 Entwicklung JINI 55
Abbildung 5.1: Logo Jini (Wunderlampe) Quelle: http://goo.gl/WiEwo
gerufen. Der Zugriff auf den Quelltext fur jeden wurde mit der Sun CommunitySource License [Sun00-2]5 festgelegt. Fur den Einsatz der Jini - Technologie inkommerziellen Projekten, verlangte Sun jedoch weitere kostenpflichtige Lizenzen.
Fast zehn Jahre spater, im Jahr 2007, erfolgte die Ubernahme der Jini - Technikdurch die Apache Software Foundation unter dem Namen Apache River. SunMicrosystem bezeichnete die Entwicklung Jini‘s, sowie auch die der Community, alseingeschlafen und stellte die finanziellen Mittel ein. Aus Jini wurde somit ApacheRiver.
Momentan befindet sich Apache River noch immer in der Incubator Phase. DiesePhase mussen alle neuen Projekte, bei der Apache Software Foundation, durchlau-fen um vollwertige Projekte zu werden. Im Jahre 2010 fand eine Verschmelzungvon Sun Microsystems und der Oracle Corporation statt. Sun Microsystems heißtnun Sun Oracle.
5 Vgl.: Sun Microsystems, Richard P. Gabriel, William N. Joy: Sun Community Source LicensePrinciples, 2000
56 5 Jini - Java Intelligent Network Interface
Abbildung 5.2: Logo Apache River (Apache Software Foundation) Quelle:http://goo.gl/MYQ7i
5.2.3 Ziele von Jini
Einfachheit (Jini nutzt Java und fugt selbst nur wenige Funktionen hinzu)
Zuverlassigkeit (stabiles Hinzufugen oder Entfernen von Dienste in einemNetzwerk spontane Vernetzung)
Skalierbarkeit (Jini-Dienste konnen sich zu einer Gemeinschaft (Djinn) zu-sammenschließen, jeder Dienst kennt den anderen und kann ihn nutzen)
Selbstheilung (Jini kann tote Dienste mit Hilfe des sogenannten Leasingausschließen)
5.3 Dienstkonzept 57
5.3 Dienstkonzept
Im folgenden Abschnitt wird das Konzept, mit den dazugehorigen Diensten, einerJini - Architektur vorgestellt.
5.3.1 Komponenten einer Jini - Architektur
Die drei Hauptkomponenten einer Jini - Architektur sind der Client (Dienstnutzer),der Lookup - Service (Dienstverwalter) und der Service (Dienst) selber, welchergenutzt werden soll. Mehrere Dienste werden als Djinn bezeichnet. Die wichtigsteKomponente ist der Lookup - Service, welcher die Aufgabe hat, zwischen Clientund Service zu vermitteln. Grundvoraussetzungen sind, wie bereits erwahnt, dassdie benutzten Gerate eine JVM besitzen und auf Basis vom TCP/IP Protokoll imNetzwerk kommunizieren6.
Abbildung 5.3: Abbildung Hauptkomponenten einer Jini - Architektur Quelle: eigeneDarstellung
Der Code wird nun, durch serialisierte Objekte, zwischen diesen drei Komponen-ten ausgetauscht und muss bei spaterer Verwendung dieser Objekte zunachstdeserialisiert werden. Bei Zugriff auf Methoden eines Objekts einer entferntenJVM, kommt RMI zum Einsatz. RMI ist schon langer Bestandteil von Java undwurde zur Objektkommunikation uber Maschinen - und Netzwerkgrenzen hinweggeschaffen. RMI steht fur Remote Method Invocation und ermoglicht eben genaudiesen Zugriff auf entfernte Methoden und das Transferieren von Klassen wie auch
6 Vgl. Langel J.: Jini und JavaSpaces, Universitat Freiburg (Schweiz), S. 7-12
58 5 Jini - Java Intelligent Network Interface
von Objekten. Auf die Spezifikationen von RMI soll an dieser Stelle nicht nahereingegangen werden.
5.3.2 Ablauf der Dienstvermittlung
In diesem Abschnitt werden die einzelnen Vorgange und dabei genutzten Diensteim Detail betrachtet und erklart.
Discovery und Join
Zu Beginn muss explizit ein Lookup - Service vom Administrator gestartet werden,falls noch kein solcher Service im Netzwerk lauft. Danach erfolgt die Dienstsuche,das sogenannte Discovery, damit sich Dienste beim Lookup - Service registrierenkonnen. Es gibt verschiedene Discovery - Verfahren fur Dienstanbieter:
Unicast Request Protocol Der Rechner (contact point) auf dem der Lookup- Service lauft ist dem Dienst bereits bekannt durch z.B. Multicast Discoveryoder durch vorkonfigurierte Informationen von Host und Port.
Multicast Request Protocol Dieses Verfahren wird verwendet wenn keinLookup - Service bekannt ist. Der Jini - Service versendet dabei UDP (UserDatagram Protocol) Pakete mit seinem eigenem TCP Port, den Namen derDjinns, die ihn interessieren und eine Liste der ihm schon bekannten Lookup- Services. Dadurch konnen benachbarte Lookup - Dienste werden gefunden.Der Multicast Request wird periodisch (alle 5 Sekunden) wiederholt.
Der Lookup - Service kann ebenso nach Diensten suchen, mit folgendem Verfahren:
Multicast Announcement Protocol Jeder Service (Dienst) im Netzwerkerhalt dabei regelmaßig Informationen per UDP mit der IP - Adresse undPort des Lookup - Service, der Lookup - Service ID und den Namen derDjinns, denen er angehort. Der Lookup - Service kundigt damit sein eigenesVorhandensein im Netzwerk, z.B. bei Start oder nach einem Ausfall und demdamit verbunden Neustart des Lookup - Service, an. Grund fur einen Neustartist z.B. ein Serverabsturz.
Nach der erfolgreichen Suche des Service und dem Finden des Lookup - Service,wird ein Registrar - Objekt an den Service zuruckgegeben. Das Registrar - Objektbeinhaltet Host und Port des Lookup - Service. Daraufhin kann sich der Servicebeim Lookup - Service registrieren und kann daraufhin von Clients (Dienstnutzern)gefunden werden.
5.3 Dienstkonzept 59
Alle Dienste bzw. Services, wie beispielweise ein jini - fahiger Drucker, beinhaltendabei ein Serviceobjekt, welches die Informationen zur Nutzung des Dienstesbeinhaltet. Bei Registrierung, dem Joining, beim Lookup - Service wird nun eineKopie dieses Objekts an den Lookup - Service ubergeben. Somit dient der Lookup -Service dem spateren Client (Dienstnutzer) als Proxy zum Dienstanbieter (Service).
Client Lookup (Request)
Die Registrierung des Clients beim Lookup - Service erfolgt aquivalent zur Registrie-rung des Dienstanbieters beim Lookup - Service. Daraufhin sendet nun ein Clienteine Dienstanfrage (Request), mit den jeweiligen geforderten Parametern, an denLookup - Service. Hat der Lookup - Service, bei Vorhandensein von registriertenDiensten, einen passenden Dienst gefunden, kann der Client das Serviceobjekt,vom dem Dienst welchen er nutzen mochte, in seine JVM herunterladen. Zudiesem Zeitpunkt hat der Dienstanbieter sein Service - Objekt und der Lookup- Service sowie der Client eine Kopie dieses Objekts in der jeweiligen JVM. DerClient kann nun direkt mit dem Service uber das Service - Objekt kommunizieren.
Proxies
Das Service - Objekt dient dem Client also als Proxy zum Service, dabei bestehen4 verschiedene Varianten der Nutzung7:
1. lokal Bei dieser Variante agiert der Proxy lokal, d.h. das Proxy - Objekt istselbst der Service und fuhrt sich in der JVM des Clients aus.
2. remote Der Proxy stellt eine Verbindung zum Dienstanbieter her, welcherden Service beherbergt. Die Dienstleistung wird vollstandig in der JVM desAnbieters ausgefuhrt
3. remote (andere JVM) Der Proxy kontaktiert andere, besonders geeigneteMaschine zum ausfuhren des Codes. Diese befinden sich meist zwischen Clientund remote Serviceanbieter.
4. Smart Proxy (lokal/remote) Ein Teil der Dienstleistung wird lokal in der JVMdes Clients, der verbleibende Teil auf einer entfernten Maschine, ausgefuhrt.
Leasing
Ein Nachteil von verteilten Systemen ist, dass einzelne Dienste ausfallen konnenund die Kommunikation zwischen den Komponenten unterbrochen ist. Erfahrt nunder Lookup - Service nicht vom Ausfall einer Komponente und stellt den Clients
7 Vgl. Muller H.: Integration nicht-Java-fahiger Dienstleister in eine Jini-Infrastruktur, UniversitatHamburg, S. 31-36
60 5 Jini - Java Intelligent Network Interface
weiterhin das Service - Objekt des Dienstes bereit. Erfolgt nun der Versuch desClients, den nicht vorhandenen Dienst zu nutzen, kommt zu einem Fehler.
Um dies zu verhindern, erhalt jeder Dienst bei Registrierung beim Lookup - Serviceein Lease. Ein Lease ist eine Registrierung eines Dienstes fur ein bestimmtesZeitfenster. Dieser muss fortlaufend erneuert werden, da der Lookup - Servicesonst annimmt, dass der jeweilige Dienst nicht mehr existiert. Ist dies der Fallerfolgt das Loschen des Service - Objekts aus der Dienstliste des Lookup - Service.Jini ist somit ein selbstheilendes System, da es keine toten Dienste toleriert. DiesesKonzept wird auch Soft State Computing genannt.
5.4 Fazit
Jini ist eine elegante Architektur fur spontane Netzwerke und bietet einige Vorteile.Es mussen keine Treiber installiert werden, zudem ist Jini ein selbstheilendesSystem, da nicht verfugbare Dienste geloscht werden. Weiterhin basiert Jini aufJava und ist somit plattformunabhangig.
Jini ist jedoch nicht die einzige Architektur, die Vernetzung von Komponentenim Netzwerk verbessern bzw. vereinfachen soll. Konkurrenzprodukte zu SUN’sJini sind vorhanden. Ein Gegenstuck zu Jini ist z.B. das Universal Plug and PlayKonzept von Microsoft. Es hat das gleiche Ziel wie Jini, ist aber plattformabhangig.
Jini ist also nicht die Losung fur solch ein Szenario aber es ist eine denkbareVariante, eine Java - basierte Variante.
5.5 Abbildungen 61
5.5 Abbildungen
Abbildungen
5.1 Logo Jini (Wunderlampe) . . . . . . . . . . . . . . . . . 55
5.2 Logo Apache River (Apache Software Foundation) . . . . 56
5.3 Abbildung Hauptkomponenten einer Jini - Architektur . . 57
62 5 Jini - Java Intelligent Network Interface
5.6 Quellenverzeichnis
Vgl. Langel J.: Jini und JavaSpaces, Universitat Freiburg (Schweiz), S. 7-12
Vgl. Sommer P.: Jini - Konzepte von Betriebssystem-Komponenten, UniversitatErlangen, S. 1-7
Vgl. Keith Edwards W.: Core Jini, Prentice Hall Verlag, Jahr 2000
Vgl. Muller H.: Integration nicht-Java-fahiger Dienstleister in eine Jini-Infrastruktur, Universitat Hamburg, S. 31-36
Vgl. Flanagan D.: Java In A Nutshell, O’Reilly & Associates, Jahr 1996
Vgl. Jini in Java, Fach Hochschule Wedel, Jahr 1999, http://www.fh-wedel.de/ si/seminare/ws99/Ausarbeitung/jini/Jini/Jini3.html
Vgl. What is Jini? River Wiki - JiniOrgWiki,http://wiki.apache.org/river/JiniOrgWiki
6 ownCloudFabian Markert
Inhaltsverzeichnis
6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3 WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.4 Vorstellung der Dienste fur PC . . . . . . . . . . . . . . . 67
6.4.1 Dateien . . . . . . . . . . . . . . . . . . . . . . . 67
6.4.2 Musik . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.3 Bilder . . . . . . . . . . . . . . . . . . . . . . . . 70
6.4.4 Kontakte . . . . . . . . . . . . . . . . . . . . . . 71
6.4.5 Kalender & Aufgaben . . . . . . . . . . . . . . . 71
6.4.6 Einstellungen . . . . . . . . . . . . . . . . . . . . 72
6.5 ownCloud & Android . . . . . . . . . . . . . . . . . . . . 72
6.5.1 Dateien . . . . . . . . . . . . . . . . . . . . . . . 72
6.5.2 Musik . . . . . . . . . . . . . . . . . . . . . . . . 72
6.5.3 Kontakte . . . . . . . . . . . . . . . . . . . . . . 73
6.5.4 Kalender . . . . . . . . . . . . . . . . . . . . . . 73
6.6 Erweiterung von ownCloud . . . . . . . . . . . . . . . . . 73
6.7 Integration in die Systemlandschaft der FH-Schmalkalden 74
6.8 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.1 Einleitung
Das Projekt ownCloud wurde im Januar 2010 vom KDE-Entwickler Frank Karlit-schek gestartet. Ziel des Projektes ist es eine freie Alternative zu kommerziellenCloud-Anbietern zu schaffen. Es benutzt PHP in Verbindung mit einer SQLite,MySQL oder einer PostgreSQL - Datenbank, daher kann es auf jeder Plattformeingesetzt werden, die diese Voraussetzungen erfullen. Die Anwendung steht unterder Affero GPL 3.0.
Es existieren zwar bereits einige kostenlose Cloud-Dienste wie beispielsweise Drop-box oder Google-Kalender, bei diesen besteht allerdings der Nachteil, dass der
64 6 ownCloud
Nutzer seine Daten einem Drittanbieter anvertrauen muss. Daraus ergibt sichdie Ungewissheit, dass jemand Missbrauch mit diesen Daten betreiben kann. BeiownCloud darf jeder seine eigene Wolke mit eigenen Servern bauen, somit entfallendiese Bedenken.
Diese Ausarbeitung stellt ownCloud anhand einer eigenen Konfiguration mitausgewahlten Features vor und testet deren Alltagsbetrieb. Im Einzelnen geht esum folgende Funktionalitaten:
Dateizugriff
Musikstreaming,
Kontaktmanagement
Integration in Android
Erweiterung der Cloud
LDAP - Anbindung fur eine mogliche Integration in die Systemlandschaft derFH - Schmalkalden
In dieser Ausarbeitung wird zur Veranschaulichung eine eigene ownCloud–Instanzauf einem Linux Server verwendet. Der Zugriff auf diese erfolgt uber Windows7, Linux (Kernel 3.4) sowie Android 2.3.7. Als Browser werden Internet Explo-rer 9, Firefox 13 und Chromium 20 verwendet. Auf den Betriebssystemen wirdausschließlich kostenfreie Software betrachtet.
6.2 Installation
Installationsvoraussetzung fur ownCloud ist ein Webserver wie beispielsweiseapache2, PHP5 sowie eine SQL-Datenbank erforderlich[1]. Auf Debian-ArtigenSystemen werden mit den folgenden Befehlen samtliche Abhangigkeiten automa-tisch installiert:
Listing 6.1: Installation aller notwendigen Pakete auf Debian Systemen [1]
apt−get i n s t a l l apache2 php5 php5−json php−xml \php−mbstring php5−zip php5−gd
apt−get i n s t a l l php5−s q l i t e cur l \l i b c u r l 3 l ibcur l3−dev php5−cur l php−pdo
Die ownCloud-Installation erfolgt uber ein Archiv, welches von der Adressehttp://owncloud.org/install/ heruntergeladen werden kann. Danach wird es inden Webordner entpackt (beispielsweise /var/www/owncloud). Dieser muss demapache-user durch chown −R www−data:www−data /pfad/zu/owncloud/ zuganglich gemacht
6.3 WebDAV 65
werden. Als letzter Schritt muss der Webserver nun uber den Browser angesprochenwerden, ein Screenshot ist in Abbildung 6.1 zu sehen. Dort findet der Nutzer einensehr einfachen Einrichtungsassistenten. Es muss lediglich die Datenbankanbindung,der Pfad zum Speichern der Einstellungen und ein Administrator eingerichtetwerden.
Abbildung 6.1: Einrichtungsassistent von ownCloud bei der Installation.
Fur diese Ausarbeitung wird ein Sabayon Linux 8 1 verwendet, ein Gentoo-basiertesSystem, da ownCloud direkt uber dessen Paketverwaltung Portage installiertwerden kann. Als USE flag kann hierbei auch die benotigte Datenbank angegebenwerden; in der aktuellen Betrachtung ist es SQLite3. Anschließend geht es andie Konfiguration des Servers. In der Datei /etc/conf.d/apache2 mussen beiAPACHE2 OPTS die Parameter -D DAV -D PHP5 erganzt werden.
Die Bereitstellung auf dem Server erfolgt uber das Kommando webapp−config −I −
h localhost owncloud 4.0.0. Der Parameter -I steht fur die Aktion Install, -h gibt denhost an, auf dem eine Webanwendung installiert werden soll. Die letzten beidenParameter spezifizieren, welche webapp in welcher Version installiert werden soll[2].
6.3 WebDAV
Die einzelnen Dienste, die von einer ownCloud - Instanz angeboten werden,basieren auf WebDAV. WebDAV steht fur Web-based Distributed Authoringand Versioning. Es ist ein offener Standard, an dessen Arbeit im Jahr 1996begonnen wurde. Das Protokoll stellt eine Erweiterung des HTTP - Protokolls darund ist speziell fur den Datenaustausch uber das WorldWideWeb entwickelt worden
1 http://sabayon.org/
66 6 ownCloud
[3]. Mittlerweile existieren fur die verbreiteten Betriebssysteme (einschließlich furmobile Endgerate) Implementierungen, welche den Zugriff auf WebDAV - Freigabenmit Hilfe eines Dateiexplorers ermoglichen.
Da HTTP die Basis fur diesen Standard ist, wird keine zusatzliche Portfreigabe furFirewalls benotigt. Ein WebDAV - Server kann mit einem normalen HTTP -Serverbetrieben werden. Dadurch ist es fur Portscanner auch nicht so offensichtlich wieeine Windows- oder Samba-Freigabe, was einen Vorteil fur die Sicherheit und denAdministrationsaufwand darstellt.
WebDAV erweitert das HTTP Protokoll um folgende Kommandos:
HTTP-Methode
Beschreibung
PROPFINDerfragt die Eigenschaften einer Datei im XML - Format, kann ebenfallsAuskunft uber die Verzeichnisstruktur des entfernten Systems geben
PROPPATCH dient dem Bearbeiten von Eigenschaften einer Ressource
MKCOL erstellt eine Collection (Verzeichnis)
COPY kopiert eine Ressource
MOVE verschiebt eine Ressource
DELETE loscht eine Ressource
LOCKder Webserver wird angewiesen, eine Ressource zu sperren, dieRessource kann in diesem Zustand nur vom aktuell genutzten Clientbearbeitet werden
UNLOCK Entfernt eine Sperre wieder
Tabelle 6.1: Kommandos von WebDAV [4, 5, 6, 7, 8, 9, 10, 11, 12]
Seit RFC-5689 ist eine Versionsverwaltung ebenfalls fester Bestandteil des Stan-dards, wodurch sich altere Dateien wiederherstellen lassen [13].
6.4 Vorstellung der Dienste fur PC 67
6.4 Vorstellung der Dienste fur PC
Direkt nach der Einrichtung prasentiert ownCloud dem Nutzer sein Webinterface.Die Plugins fur Dateizugriff, Musik, Kontakte, Kalender und Galerie sind stan-dardmaßig aktiviert – zu sehen in Abbildung 6.2. Im linken unteren Bereich sinddie Einstellungen zu finden. An dieser Stelle finden sich ebenfalls Links, um auf dieeinzelnen Dienste mit externen Programmen zugreifen zu konnen. Im nachfolgen-den Abschnitt wird auf die einzelnen Funktionen und Einstellungsmoglichkeitennaher eingegangen.
Abbildung 6.2: Webinterface direkt nach der Einrichtung.
6.4.1 Dateien
Dateizugriffe konnen auf mehrere Arten bewerkstelligt werden. Die erste Varianteist die uber den Browser. Mit dem Webinterface konnen Textdokumente und Ordnerdirekt angelegt werden. Per Drag & Drop konnen Daten direkt hochgeladen werden.Es ist ebenfalls moglich PDF, Open Document Format sowie diverse Bildformatedort zu betrachten. Des weiteren kann der Nutzer Dateien herunterladen.
Das Interface gestattet die Freigabe von Dateien und Ordnern. Diese kann entwederfur einzelne Benutzer oder fur Nutzergruppen geschehen. Daruber hinaus kanneingestellt werden, ob andere Nutzer diese bearbeiten durfen oder nicht. Es fehltallerdings eine Anzeige, welche dem Anwender signalisiert, dass es sich um eineFreigabe handelt und welche Zugriffsrechte er besitzt.
Eine weitere Moglichkeit auf Dateien zuzugreifen ist mittels des eigenen Sync-Clients Mirall. Dieser kann von der Projektseite heruntergeladen werden und ist
68 6 ownCloud
ebenfalls Open Source und fur Windows, Mac sowie Linux verfugbar.2 Nach derInstallation erwartet der Client die Adresse und die Zugangsdaten des Servers. Esist nicht moglich mehrere Server mit einem Client abzurufen. Der Nutzer kannselbst entscheiden, welche Ordner vom Server mit welchen lokalen Verzeichnis-sen synchronisiert werden sollen. Zum Synchronisieren wird csync verwendet. 3
Das Verhalten der Anwendung erinnert an Dropbox oder ahnliche Dienste undfunktioniert auf allen getesteten Desktop-Betriebssystemen gleichermaßen gut.Im Tray-Bereich erscheint ein Symbol des Clients, welches den Nutzer uber Syn-chronisationsvorgange informiert. Es fiel auf, dass der Server die Synchronisationblockierte, wenn die Systemzeiten der beteiligten Rechner zu stark voneinanderabweichen.
Als letzte Moglichkeit bietet ownCloud WebDAV zum Dateizugriff an. Der Standardist auf allen Betriebssystemen bereits implementiert. Im Falle von Linux ist esmoglich die Freigabe per mount-Befehl zu erreichen. 4 Wesentlich komfortablergestaltet sich der Zugriff uber die Desktopumgebungen. So bieten KDE und GnomeAssistenten an, welche das Einbinden erlauben ohne auf root-Rechte zuruckgreifenzu mussen – zu sehen in Abbildung 6.3.
Abbildung 6.3: Eingabemaske zum Verbinden mit WebDAV durch Nautilus (Gnome)
Unter Windows gestaltet sich die Verbindung uber WebDAV als problematisch.Trotz korrekter Verbindungsdaten meldet das System eine fehlerhafte Eingabe.Dieser Fehler betrifft lediglich Windows 7, auf XP und Vista funktioniert dieEinbindung laut Projektseite ohne Probleme. Dort befindet sich ebenfalls eineAnleitung, um besagten Fehler zu beseitigen. Im personlichen Test konnte dieseAnleitung nicht nachvollzogen werden. Eine Alternative stellt die Software NetDrivedar. Dabei handelt es sich um eine Freeware-Anwendung, welche dazu dient FTP-
2 http://owncloud.org/sync-clients/3 http://www.csync.org/4 http://owncloud.org/support/webdav/
6.4 Vorstellung der Dienste fur PC 69
und WebDAV-Freigaben als Netzwerklaufwerke einzubinden. 5 Die Bedienung istdabei ahnlich komfortabel wie der Assistent von Nautilus.
Uber WebDAV eingebundene Verzeichnisse befinden sich direkt auf dem Server.Daten werden daher direkt bearbeitet. Anders als beim Sync-Client bemerkt derNutzer Anderungen an enthaltenen Inhalten nicht unmittelbar, sondern erst beierneutem Erfragen des Inhaltes. Die meisten Anwendungen haben keine Problememit dieser Art des Dateizugriffs und verhalten sich so, als waren es lokale Dateien.In einigen Fallen sturzen diese jedoch ab oder reagieren nicht mehr. Dies istbeispielsweise bei Shotwell, einem Bildbetrachter fur Linux, der Fall.
6.4.2 Musik
Das Webinterface beinhaltet einen Extra-Menupunkt fur Musik. Sofern sich Audio-dateien im Verzeichnis des Nutzers befinden, konnen diese mit dem Button RescanCollection erfasst werden. Abbildung 6.4 zeigt diese Ansicht. Darin zu sehen ist eineUbersicht uber vorhandene Musikstucke. Eventuell vorhandene Titelinformationenwerden ebenfalls eingeblendet. Es ist moglich dort eine Playlist zusammenzustellenund diese direkt wiederzugeben. Die Wiedergabe wird fortgesetzt, wenn der Nutzereinen anderen Menupunkt betritt. Allerdings unterbricht die Wiedergabe fur dieZeit des Neuladens der Seite. Daruber hinaus fuhrt dies bei Chromium zu Absturzen.Der verwendete Tab gibt keine Ruckmeldung mehr. Dieser Effekt tritt bei keinemanderen Browser auf.
Abbildung 6.4: Webinterface fur Musikwiedergabe
Die ownCloud bietet eine weitere Moglichkeit Musikdaten zu erreichen. Hierfur
5 http://www.netdrive.net/
70 6 ownCloud
wird der MP3-Streaming-Server Ampache verwendet. 6 Dieser kann uber einexternes Programm angesprochen werden. Die Projektseite empfielt den PlayerTomahawk 7, welcher fur Windows, Linux und Mac verfugbar ist. Die Einrichtungist sehr einfach, da das Webinterface im Dialog fur personliche Einstellungen dieURL prasentiert, welche in die Eingabemaske des Players eingegeben werden muss.Die serverseitigen Werke werden allerdings nicht in einer Ubersicht prasentiert.Der Nutzer muss daher genau wissen, welche Musik sich auf dem Server befindetund im Zweifelsfalle uber das Webinterface nachsehen. Sie konnen ausschließlichuber die Suchfunktion des Players gefunden und abgespielt werden.
Fur das Wiedergabeprogramm Banshee existiert ebenfalls ein Ampache-Plugin.Die Software ist fur Windows, Linux und Mac verfugbar. Die Einrichtung verlauftahnlich wie bei Tomahawk. Banshee liefert einen extra Menupunkt, uber deneine Ubersicht der Ampache Medien prasentiert wird. Das Plugin ist jedoch nichtstabil. Gelegentlich sturzt die Anwendung beim Anklicken des Menupunktes oderwahrend der Wiedergabe ab.
6.4.3 Bilder
In der Weboberflache existiert ein Menupunkt, welcher speziell zur Darstellung vonBildern gedacht ist. An dieser Stelle werden alle Verzeichnisse mit Bildern ange-ordnet. Fur die enthaltenen Bilder werden Thumbnails generiert – eine Darstellungist in Abbildung 6.5 zu sehen.
Abbildung 6.5: Ubersicht aller Bilder eines Benutzers.
Beim Anklicken eines Ordners wechselt die Ansicht und alle enthaltenen Bilder
6 http://ampache.org/7 http://www.tomahawk-player.org/
6.4 Vorstellung der Dienste fur PC 71
werden angezeigt. Beim Anklicken eines Bildes erscheint eine Lightbox in dervollen Große. Mit Pfeiltasten oder Mausradsteuerung kann zwischen den einzelnenLightboxen gewechselt werden.
6.4.4 Kontakte
Uber den Menupunkt Kontakte konnen Adressbucher verwaltet werden. Der Im-port von vCard-Dateien ist moglich. Uber das Webinterface konnen Kontakteangelegt und bearbeitet werden. Fur externe Programme bietet ownCloud eineCardDAV Schnittstelle an; einer Erweiterung des WebDAV-Standards. [14] Dadurchist es beispielsweise moglich Adressdaten mit dem E-Mail-Client Thunderbird8
zu synchronisieren. Dafur mussen zwei Erweiterungen installiert werden. Dabeihandelt es sich um SOGo Connector 9 und MoreFunctionsForAddressBook 10.SOGo Connector ermoglicht die Anmeldung uber Webinterfaces. MoreFunctions-ForAddressBook erweitert die Funktionen des Adressbuches unter anderem umdie Moglichkeit ein Remote Adressbuch anzulegen. Dazu muss in Thunderbirddas Adressbuch geoffnet und im Menupunkt Datei/Neu der Unterpunkt Remote-Adressbuch ausgewahlt werden. Die einzutragende Adresse erfragt der Nutzer inder Oberflache von ownCloud – zu sehen in Abbildung 6.6.
Abbildung 6.6: Im linken Berreich ist die Anzeige von ownCloud zu sehen, welche denFreigabelink des Adressbuches anzeigt. Im rechten Berreich ist die Eingabemaske vonThunderbird zu sehen. Hier wird der Freigabelink eingetragen.
6.4.5 Kalender & Aufgaben
Zu den Standardfunktionen von ownCloud gehort eine Kalender- und Aufgabenfunk-tionalitat. Diese konnen uber den Browser bedient werden. Die Kalenderoberflachefunktioniert ahnlich wie Google-Calendar. Es konnen mehrere Kalender angelegtwerden. Fur externe Programme wird eine CalDAV-Schnittstelle angeboten. [15]
Damit ist es moglich mit Programmen, wie Thunderbird (mit Lightning) oderMozilla Sunbird auf den eigenen Kalender zuzugreifen. Hierzu muss fur denKalender der Freigabelink erzeugt werden und im Client Programm eingetragen
8 http://www.mozilla.org/de/thunderbird/9 http://www.sogo.nu/english/downloads/frontends.html10http://nic-nac-project.de/ kaosmos/morecols-en.html
72 6 ownCloud
werden. Fur Programme, die kein CalDAV beherrschen, wird zusatzlich noch eineiCalendar-Schnittstelle angeboten. [16] Uber das gleiche Protokoll werden auchAufgaben eingetragen.
6.4.6 Einstellungen
Im unteren Bereich der Weboberflache befindet sich ein Zahnradsymbol, wel-ches Zugang zu samtlichen Einstellungsdialogen bietet. Hierbei ist es von denBerechtigungen des aktuellen Nutzers abhangig, welche Einstellungsmoglichkeitenangezeigt werden. An dieser Stelle sind Links, um die einzelnen Diensten anspre-chen zu konnen, auffindbar. Administratoren haben die Moglichkeit neue Nutzerund Gruppen anzulegen. Fur neue Erweiterungen gibt es einen eigenen App-Store.Dort werden alle Erweiterungen prasentiert und konnen mit einem Klick installiertwerden. Negativ fallt hierbei auf, dass Apps aufgefuhrt sind, die mit der installiertenownCloud-Version nicht kompatibel sind. Die daraus resultierende Fehlermeldunglasst keine Ruckschlusse auf den Grund der Installationsverweigerung zu.
6.5 ownCloud & Android
Es existiert bereits eine Android-App fur ownCloud. Diese kann momentan aus-schließlich uber die Projektseite bezogen werden, da sie sich noch in einem fruhenEntwicklungsstadium befindet. Die aktuelle Version 1.0 beschrankt sich auf denDateiup- und -download. Um auf die anderen Dienste zugreifen zu konnen, werdenApps benotigt, die den jeweiligen Standard unterstutzen. Einige davon werden indiesem Abschnitt vorgestellt.
6.5.1 Dateien
Mit der App WebDAV Nav lite 11 kann die Dateifreigabe von ownCloud ange-sprochen werden. Die Einrichtung ist selbsterklarend und verlauft problemlos. Eskonnen einzelne Dateien hoch- und runtergeladen werden.
6.5.2 Musik
Mit Hilfe der App Just Player 12 in Verbindung mit Ampache Provider 13 ist esmoglich den Ampache dienst von ownCloud Anzusprechen. Beide Apps mussendazu installiert werden. In Ampache Provider muss der Anwender die Serverurl
11http://alturl.com/uoeom12http://goo.gl/wr9CT13http://goo.gl/xWtNK
6.6 Erweiterung von ownCloud 73
und die Zugangsdaten fur Ampache eingegeben. Anschließend ist es notwendig,den Sync Button im unteren Bereich zu betatigen.
Danach muss in Just Player der Menubutton betatigt werden. Anschließenderscheint eine reihe von Buttons. Der Mittlere offenbart verfugbare Datenquellen.An dieser Stelle ist Ampache auszuwahlen. Daraufhin sind remote Inhalte verfugbar.Im personlichen Test gab es keine Probleme, die Wiedergabe funktionierte fehlerfreiund flussig.
6.5.3 Kontakte
Durch die App CardDAV-Sync free beta 14 konnen Kontakte und Adressen syn-chronisiert werden. Nach der Installation ist es moglich im Einstellungsmenu vonAndroid ein neues Synchronisierungskonto hinzuzufugen. Nach dessen Einrichtungstartet die Synchronisation. Mit dieser Anwendung ist es moglich Kontakte ohneGoogle-Konto zu verwalten.
6.5.4 Kalender
Zum Zeitpunkt der Fertigstellung dieser Arbeit ist es nicht moglich gewesen eineFunktionierende kostenfreie App zu testen, welche CalDAV unterstutzt. Daherkann uber diese Funktionalitat keine aussage getroffen werden.
6.6 Erweiterung von ownCloud
Fur den Begriff Cloud Computing gibt es noch keine einheitliche Definition. In denmeisten ist von einer Rechnerinfrastruktur die rede, welche fur den Nutzer nachaußen undurchsichtig ist, ahnlich einer Wolke. Daher stellt sich die Frage inwiefernownCloud diesen Definitionen gerecht wird. In der derzeit aktuellen Version 4.0.4gibt es keinen Grafischen Assistenten um mehrere Instanzen zu verbinden. Dies isterst fur die Version 5 geplant, deren Veroffentlichung fur August 2012 vorgesehenist. 15 Auf der Projektseite existieren bereits Anleitungen um Dateifreigaben allerArt per mountscript einzubinden. Dem Nutzer erscheinen diese Freigaben alsnormale Verzeichnisse. 16
14http://goo.gl/qbRLO15http://owncloud.org/dev/roadmap/16http://owncloud.org/support/custom-mount-configuration/
74 6 ownCloud
6.7 Integration in die Systemlandschaft derFH-Schmalkalden
Da zum Zeitpunkt der Fertigstellung dieser Ausarbeitung auf dem zur Verfugunggestellten Testsystem der FH-Schmalkalden kein funktionsfahiger PHP-Servervorlag, wird an dieser stelle nur ein Theoretisches Konzept genannt. Die Anmeldungauf Diensten der FH-Schmalkalden funktioniert mit einem LDAP-Server. FurownCloud existiert ein entsprechendes LDAP Plugin. Nach dessen Installation undKonfiguration ist es einem Nutzer moglich, sich mit seiner FHS-ID anzumelden.Mit Hilfe eines Mount Scripts kann das Home-, das PUB- sowie das Free-Laufwerkmittels Samba uber ownCloud erreicht werden. Da die Passworter von den einzelnenDiensten unterschiedlich verschlusselt ubertragen werden ist es nicht moglich dieseeinfach an Samba durchzureichen. Eine Losung hierfur bieten fur jeden Nutzerindividuelle SSH-Keys welche Serverinternen fur die Authentifizierung anstelle vonPasswortern eingesetzt werden. Danach ist die Konfiguration abgeschlossen.
6.8 Fazit
Die ownCloud bietet Privatanwendern die Moglichkeit, unabhangig von Kommerzi-ellen anbiedern die selben Dienste zu Nutzen ohne ihre Daten an diese weitergebenzu mussen. Die Einrichtung ist mit geringen Arbeitsaufwand bewerkstelligt unddie Bedienung ist Intuitiv. Durch den App-Store ist es daruber hinaus sehr leicht,die eigene Instanz um neue Funktionen zu erweitern. Man merkt dem Projekt aneinigen stellen allerdings an, dass es noch nicht ganz ausgereift ist. Insgesamtbefindet sich ownCloud jedoch auf einem guten Weg.
Die Nutzung der verschiedenen Diensten mit Desktop-Betriebssystemen ist ohnegroßeren aufwand moglich. Fur mobile Endgerate mangelt es noch an Apps umalle Dienste nutzen zu konnen.
Alles in allem ist ownCloud eine gute alternative zu aktuellen Cloud Anbietern. Furinteressierte bietet ownCloud auf der Projektseite eine Demoinstanz zum Testenan.
Literaturverzeichnis 75
Literaturverzeichnis
[1] ownCloud Support Centre, “Installation,” Website, 05 2012. [Online].Available: http://owncloud.org/support/install/
[2] S. Herbert, R. Lumpau, and G. Wrobel, Linux Manpages. Gentoo Linux,2005, ch. WEBAPP-CONFIG(8).
[3] J. Whitehead, “Proposed agenda for san mateo meeting,” Website, Jun1996. [Online]. Available: http://lists.w3.org/Archives/Public/w3c-dist-auth/1996AprJun/0002.html
[4] J. Slein, F. Vitali, E. Whitehead, and D. Durand, “Requirements for aDistributed Authoring and Versioning Protocol for the World Wide Web,”RFC 2291 (Informational), Internet Engineering Task Force, Feb. 1998.[Online]. Available: http://www.ietf.org/rfc/rfc2291.txt
[5] Y. Goland, E. Whitehead, A. Faizi, S. Carter, and D. Jensen, “HTTPExtensions for Distributed Authoring – WEBDAV,” RFC 2518 (ProposedStandard), Internet Engineering Task Force, Feb. 1999, obsoleted by RFC4918. [Online]. Available: http://www.ietf.org/rfc/rfc2518.txt
[6] G. Clemm, J. Amsden, T. Ellison, C. Kaler, and J. Whitehead, “VersioningExtensions to WebDAV (Web Distributed Authoring and Versioning),” RFC3253 (Proposed Standard), Internet Engineering Task Force, Mar. 2002.[Online]. Available: http://www.ietf.org/rfc/rfc3253.txt
[7] J. Whitehead and J. Reschke, “Web Distributed Authoring andVersioning (WebDAV) Ordered Collections Protocol,” RFC 3648 (ProposedStandard), Internet Engineering Task Force, Dec. 2003. [Online]. Available:http://www.ietf.org/rfc/rfc3648.txt
[8] G. Clemm, J. Reschke, E. Sedlar, and J. Whitehead, “Web DistributedAuthoring and Versioning (WebDAV) Access Control Protocol,” RFC 3744(Proposed Standard), Internet Engineering Task Force, May 2004. [Online].Available: http://www.ietf.org/rfc/rfc3744.txt
[9] J. Reschke, “Datatypes for Web Distributed Authoring and Versioning(WebDAV) Properties,” RFC 4316 (Experimental), Internet Engineering TaskForce, Dec. 2005. [Online]. Available: http://www.ietf.org/rfc/rfc4316.txt
[10] B. Korver and L. Dusseault, “Quota and Size Properties for DistributedAuthoring and Versioning (DAV) Collections,” RFC 4331 (ProposedStandard), Internet Engineering Task Force, Feb. 2006. [Online]. Available:http://www.ietf.org/rfc/rfc4331.txt
76 6 ownCloud
[11] J. Whitehead, G. Clemm, and J. Reschke, “Web Distributed Authoringand Versioning (WebDAV) Redirect Reference Resources,” RFC 4437(Experimental), Internet Engineering Task Force, Mar. 2006. [Online].Available: http://www.ietf.org/rfc/rfc4437.txt
[12] L. Dusseault, “HTTP Extensions for Web Distributed Authoringand Versioning (WebDAV),” RFC 4918 (Proposed Standard), InternetEngineering Task Force, Jun. 2007, updated by RFC 5689. [Online]. Available:http://www.ietf.org/rfc/rfc4918.txt
[13] C. Daboo, “Extended MKCOL for Web Distributed Authoring and Versioning(WebDAV),” RFC 5689 (Proposed Standard), Internet Engineering TaskForce, Sep. 2009. [Online]. Available: http://www.ietf.org/rfc/rfc5689.txt
[14] ——, “CardDAV: vCard Extensions to Web Distributed Authoring andVersioning (WebDAV),” RFC 6352 (Proposed Standard), Internet EngineeringTask Force, Aug. 2011. [Online]. Available: http://www.ietf.org/rfc/rfc6352.txt
[15] C. Daboo, B. Desruisseaux, and L. Dusseault, “Calendaring Extensions toWebDAV (CalDAV),” RFC 4791 (Proposed Standard), Internet EngineeringTask Force, Mar. 2007, updated by RFC 5689. [Online]. Available:http://www.ietf.org/rfc/rfc4791.txt
[16] B. Desruisseaux, “Internet Calendaring and Scheduling Core ObjectSpecification (iCalendar),” RFC 5545 (Proposed Standard), InternetEngineering Task Force, Sep. 2009, updated by RFC 5546. [Online].Available: http://www.ietf.org/rfc/rfc5545.txt
7 OrcStephan Stenzel
Inhaltsverzeichnis
7.1 Orc Definition . . . . . . . . . . . . . . . . . . . . . . . . 77
7.2 Anwendungsbereiche . . . . . . . . . . . . . . . . . . . . 78
7.3 Orc-Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.3.1 Seitenaufrufe . . . . . . . . . . . . . . . . . . . . 78
7.3.2 Kombinatoren . . . . . . . . . . . . . . . . . . . 79
7.3.3 Definitionen . . . . . . . . . . . . . . . . . . . . 80
7.3.4 Time/Timer . . . . . . . . . . . . . . . . . . . . 80
7.4 Cor-Snytax . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.4.1 Konstanten . . . . . . . . . . . . . . . . . . . . . 81
7.4.2 Bedingungen . . . . . . . . . . . . . . . . . . . . 81
7.4.3 Variablen . . . . . . . . . . . . . . . . . . . . . . 81
7.4.4 Datenstrukturen . . . . . . . . . . . . . . . . . . 81
7.4.5 Muster . . . . . . . . . . . . . . . . . . . . . . . 82
7.4.6 Funktionen . . . . . . . . . . . . . . . . . . . . . 82
7.5 Kombination von Orc und Cor . . . . . . . . . . . . . . . 82
7.1 Orc Definition
Orc ist eine neuartige Sprache fur die verteilte und simultane/nebenlaufigen(gleichzeitige) Programmierung, welche einen einheitlichen Zugriff auf rechnerischeDienste, inklusive der verteilten Kommunikation und Datenmanipulation, uberSeiten bereitstellt. Mit nur vier simplen simultanen Primitiven, instrumentiert derProgrammierer den Aufruf vonseiten um ein Ziel zu erzielen, wahrend er Timeouts,Prioritaten und Fehler regelt. Orc selbst besteht insgesamt zwei Teilen. Demsimplen Orc-Kalkul und der Cor-Sprache. Zusammen bilden sie die vollstandigeOrc-Programmiersprache.
78 7 Orc
7.2 Anwendungsbereiche
Orc sich vor allem fur den Einsatz als sogenannte General Purpose Language (GPL)an. Eine GPL zeichnet sich dadurch aus das Sie fur so gut wie alle Anwendungsfalleund Problemstellungen einsetzbar ist. Dies bietet dem Programmierer ein hohesMaß an Freiheit wie Probleme gelost werden konnen. Außerdem kann bereitsbekanntes Wissen erneut eingesetzt werden. Allerdings gibt es beim Einsatz vonOrc als GPL einige Nachteile. Zum einen mussen alle Problemstellungen zunachstin Orc-Syntax ubersetzt werden. Dies kann zu Problemen fuhren sollten sichmehrere Fachgebiete uberschneiden.
Desweiteren kann Orc als Webskriptsprache eingesetzt werden, da sie die einfacheund schnelle Erstellung von Webseiten beziehungsweise Webnetzen ermoglicht.
Eine weitere Anwendungsmoglichkeit ist es Orc als ausfuhrbare Spezifikationsspra-che, beispielweise fur sequenzielle Arbeitsablaufe, einzusetzen.
7.3 Orc-Syntax
7.3.1 Seitenaufrufe
Seitenaufruf ist die simpelste Art eines Orc-Ausdrucks. Ein Seitenaufruf im Orc-Syntax ist eigentlich der Aufruf einer Funktion, welche mit einem Services verknupftist. Der Allgemeine Aufbau eines Seitenaufrufs ist M(p). M steht hierbei fur denSeitennamen und p fur die Liste von Parametern, die der Seite ubergeben werdensollen. Bei einer Ausfuhrung von M(p) wird der entsprechende Service M aufgerufenund diesem die Parameter p geschickt. Der Service hat nach dem Aufruf Zeit zuantworten. Die zuruckgegebene Antwort wird anschließend ausgegeben.
Beispiele fur Seitenaufrufe:
add(2,4) –¿ Antwort: 8
CNN(d) –¿ Antwort: Alle Nachrichten von CNN vom Datum d
Ein Seitenaufruf hat die Eigenschaft nur maximal eine Antwort auf einen Aufrufzugeben. Eine Antwort kann das Ergebnis des Aufrufs beinhalten oder die Infor-mation enthalten des der Seitenaufruf nie eine Antwort zuruckliefern wird. Sollteein solcher Ausdruck empfangen werden, gilt der entsprechende Seitenaufruf alsunterbrochen. Der hier beschriebene Orc-Syntax hat selbst keine vordefiniertenSeiten. Allerdings wurde von den Entwicklern wichtige Seiten eingefugt, die zumErstellen von funktionalen Programmen notwendig sind. Zum einen wurde eineIdentitatsseite (let) eingefugt welche bei Aufruf mit einem einzelnen Parameterdiesen zuruckliefert. Aber bei Aufruf mit mehreren Parametern diese als ein Tupel
7.3 Orc-Syntax 79
zuruckgibt. Zum anderen eine Bedingungsseite (if), die bei Aufruf mit einemSignal (ein Wert der keine Informationen enthalt) antwortet wenn das ubergebeneArgument wahr (true) ist. Ansonsten wird mit falsch (false) geantwortet.
7.3.2 Kombinatoren
Der Orc-Syntax bietet vier unterschiedliche Kombinatoren (Combinators) zumKombinieren von Orc-Ausdrucken. Die Kombinatoren selbst besitzen unterschied-liche Prioritaten in ihrer Ausfuhrung. Nachfolgend werden alle Kombinatorenbeschrieben in der Reihenfolge ihrer Prioritaten beginnend mit der Hochsten. DerAufbau eines Kombinatorausdrucks wird durch zwei Ausdrucke ( F & G ) und denentsprechenden Kombinator dargestellt.
¿x¿, —, ¡x¡, ;
Paralleler Kombinator
Der parallele Kombinator wird in Orc mit dem Zeichen “—” dargestellt. Er wirddazu verwendet zwei Orc-Ausdrucke miteinander zu kombinieren und gleichzeitigauszufuhren. Ein Beispiel ware die Kombination der Seitenaufrufe add(2,3) —add(4,5). Die beiden Seitenaufrufe mit dem Namen add addieren ihre Parametermiteinander und geben unabhangig voneinander ihre Ergebnisse aus. Der ersteSeitenaufruf liefert den Wert 5, der Zweite den Wert 9 zuruck. Beide Ausdrucke wer-den gleichzeitig (parallel) aufgerufen. Eine direkte Interaktion oder Kommunikationzwischen den Seitenaufrufen findet jedoch nicht statt.
Sequenzieller Kombinator
Der sequenzielle Kombinator wird durch die Zeichenkombination ¿x¿ dargestellt.Das x steht hierbei fur eine Variable. Der Variablenname muss nicht x lauten,sondern kann frei gewahlt werden. Der sequenzielle Kombinator wird benutztum Orc Ausdrucke voneinander abhangig zu machen. Das heißt der Ausdruckder rechts vom Kombinator steht wird solange an der Ausfuhrung gehindert bisder Variable x, durch den links neben dem Kombinator stehenden Ausdruck, einWert zugewiesen wurde. Der Wert, der x zugewiesen wird, entspricht hierbeidem Ausgabewert des linken Ausdrucks. Ein Beispiel dafur ist die Kombinationdes Ausdrucks ( CNN(d) — BBC(d) ) mit dem Ausdruck email(a,x) zu demgesamten Orc Ausdruck ( CNN(d) — BBC(d) ) ¿x¿ email(a,x). Die SeitenaufrufeCNN und BBC sind durch einen parallelen Kombinator miteinander verknupftund geben die neusten Nachrichten des Datums d zuruck. Sollte ein Wert dzuruckgeliefert werden, wird dieser an die Variable x gebunden und damit der
80 7 Orc
Seitenaufruf email(a,x) gestartet. Dabei wird die ubergebene Variable x an eineEmailadresse a geschickt.
Reduktionskombinator
Der Reduktionskombinator wird mittels der Zeichenkombination ¡x¡ ausgefuhrt.Ahnlich wie bei einem parallelen Kombinator werden beide Ausdrucke rechts undlinks neben dem Kombinator gleichzeitig ausgefuhrt. Allerdings werden Teile deslinken Ausdrucks die die Variable x als Parameter verwenden solange vor derAusfuhrung gestoppt bis durch den rechten Ausdruck x ein Wert zugewiesen wurde.Sollte durch den Rechten Ausdruck ein Wert zuruckgegeben werden, wird dieser anx gebunden und alle unausgefuhrten Teile des linken Ausdrucks werden ausgefuhrt.Beispiel: email(a,x) ¡x¡ ( CNN(d) — BBC(d) )
Sonst Kombinator
Dargestellt wird der Sonstkombinator durch das Semikolon (;). Werden zweiAusdrucke mit dem Sonstkombinator kombiniert ( F ; G ) wird F als erstesausgefuhrt und G muss warten. Sollte F keine Werte ausgeben oder gestopptworden sein so wird G ausgefuhrt. Der Ausdruck F gilt dann als angehalten wennalle Seitenaufrufe von F geantwortet haben, F nie wieder andere Seitenaufrufedurchfuhrt oder F keine Werte mehr ausgibt. Beispiel: ( CNN(d) ; BBC(d) ) ¿x¿email(a,x)
7.3.3 Definitionen
Einem Orc-Ausdruck kann eine Sequenz von Definitionen vorangestellt sein. DerBeginn einer Definition wird durch das Wort “def” gekennzeichnet. Der AllgemeineAufbau einer Orc-Definiton sieht folgender maßen aus: def E(x) F. Das E stehtfur den Funktionsnamen, das x beschreibt die formalen Parameter und F denFunktionskorper. Bei einem Aufruf von E(p) werden die formalen Parameter xim Funktionskorper F durch die wirklichen Parameter p ersetzt. Im Gegensatz zueinem Seitenaufruf kann ein Funktionsaufruf mehr als nur einen Wert ausgebenund zusatzlich rekursiv sein.
7.3.4 Time/Timer
Da Orc hauptsachlich mit externen Services kommuniziert muss eine Funktion be-reitgestellt werden, um auf Timeouts durch nicht antwortende Dienste zu reagieren.Mit der Funktion Rtimer(t) wird nach dem Aufruf genau t Millisekunden spatermit einem Signal geantwortet. Mogliche Anwendungen waren wie bereits genanntdas warten auf Timeouts von Diensten oder die Erstellung eines Metronoms. def
7.4 Cor-Snytax 81
metronome(t) = signal — Rtimer(t) ¿¿ metronome(t) email(a,x) ¡x¡ ( BBC(d) —Rtimer(5000) ¿¿ “BBC timed out”)
7.4 Cor-Snytax
7.4.1 Konstanten
Der Cor-Syntax stellt insgesamt nur drei Konstanten zur Verfugung. Als ErstesNummern, sowohl Ganze-, Fließkomma- und negative Zahlen. Als Zweites Zeichen-ketten sogenannte Strings wie “orc” oder “Verteilte Systeme”. Und als DrittesWahrheitswerte (boolische Werte) die entweder wahr (true) oder falsch (false)sein konnen.
7.4.2 Bedingungen
Die einzige Bedingung die der Cor-Syntax bereitstellt ist die IF-Bedingung. Allge-mein kann man die IF-Bedingung mit folgendem Aufbau beschreiben.
IF E then F else G
Diese Bedingung reagiert mit der Ausfuhrung der Funktion F, wenn der AusdruckE wahr sein sollte. Sollte E jedoch falsch als Antwort zuruck liefern, wird statt “F”die Funktion “G” ausgefuhrt.
7.4.3 Variablen
Variablen werden im Cor-Syntax der Ausdruck val vorangestellt, um sie als Variablenzu kennzeichnen. In Cor sollten Variablen nur einmal einen Wert zugewiesenbekommen. Sollte zur Laufzeit der Wert einer Variable geandert werden, kanndies zu Fehlern bei der Ausfuhrung kommen. Bei einem neu zugewiesenen Wertverwenden alle Referenzen die vor der Wertzuweisung auf die Variable verwiesenhaben den alten Variablenwert. Alle neuen Referenzen verwenden den neuen Wert.Deswegen sollten Variablen nach einer Wertzuweisung unverandert bleiben.
7.4.4 Datenstrukturen
Der Cor Syntax bietet zwei simple Datenstrukturen, die Tupel ( (“3,7”),(“tag”,“monat”,“jahr”) ) und endliche Listen ( [4,4,1] , [“Beispiel”] ) an. Wichtigist es zu nennen, dass alle Datenstrukturen die Ausdrucke enthalten selbst auchAusdrucke sind. Das bedeutet, das alle beinhalteten Ausdrucke ausgefuhrt werdenund das Ergebnis entsprechend als Tupel oder endliche Liste zuruckgegeben wird.Ein Beispiel ware eine endliche Liste [1, 2+3]. Diese beinhaltet den Ausdruck
82 7 Orc
2+3. Nach der Ausfuhrung aller Ausdrucke wird eine endliche Ergebnisliste [1,5]ausgegeben. Mit dem Operator “:” konnen endlichen Listen Werte vorangestelltwerden. So konnte man der Liste [1,5] so den Wert (1+6) voranstellen.
(1+6) : [1,5] –¿ Ergebnis: [7,1,5]
7.4.5 Muster
Muster dienen im Cor-Syntax dazu Teile von Datenstrukturen an Variablen zubinden. Beispiel: Val(x,y) = (2+3, 2*3) –¿ x=5 & y=6
7.4.6 Funktionen
Funktionen werden im Cor-Syntax, genau wie im Orc-Syntax, durch dasSchlusselwort “def” definiert. Beispiel: def add(x,y) = x+y
7.5 Kombination von Orc und Cor
Die Orc-Programmiersprache ist die Kombination aus dem nichtsequenziellenKalkul und der funktionalen Kernsprache. Außerdem stellt das Orc-Paket zusatzlichnoch große Bibliotheken aus vordefinierten Seiten und Funktionen bereit, die dieArbeit des Programmierers erleichtern sollen. Da die funktionale KernspracheCor auf dem nichtsequenziellen Kalkul Orc aufbaut kann entsprechend jeder Cor-Ausdruck in einen Orc-Ausdruck ubersetzt werden. Bei einer solchen Ubersetzungist allerdings zu beachten das arithmetische, logische und vergleichende Operatorendirekt in Seitenaufrufe ubersetzt werden und Orc nur einzelne Werte oder Variablenals Argumente der Seitenaufrufe besitzen darf. Das bedeutet, dass verschachtelteCor-Ausdrucke in logische Kombinationen von Orc-Ausdrucken ubersetzt werdenmussen.
Literaturverzeichnis
[1] David Kitchin, Adrian Quark, William Cook, Jayadev Misra: TheOrc Programming Language. The University of Texas at Austin.http://orc.csres.utexas.edu/papers/forte09.pdf 12.6.2012
[2] John A. Thywissen: Secure Information Flow in the Orc Concur-rent Programming Language. The University of Texas at Austin.http://orc.csres.utexas.edu/papers/Secure-Information-Flow-Orc.pdf11.6.2012
Literaturverzeichnis 83
[3] OrcWiki. http://orc.csres.utexas.edu/wiki/Wiki.jsp?page=RecentChanges15.6.2012
[4] Orc Language Project.http://orc.csres.utexas.edu/research.shtml 10.6.2012
84 7 Orc
8 Scala STM vs. Akka STMMarco Wilhelm
Inhaltsverzeichnis
8.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2.1 Software Trans–Was? . . . . . . . . . . . . . . . 86
8.2.2 Arbeitsweise von STMs . . . . . . . . . . . . . . 86
8.3 Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.3.1 Aufbau einer Transaktion . . . . . . . . . . . . . 87
8.3.2 Erstellen einer Reference . . . . . . . . . . . . . . 88
8.3.3 Zugriff auf den Wert einer Reference . . . . . . . 88
8.3.4 Zugriff auf den Wert einer Reference uber Funktionen 89
8.3.5 Single-Operation-Transaktionen . . . . . . . . . . 89
8.3.6 Blocken von Transaktionen . . . . . . . . . . . . 90
8.3.7 Alternative Blocke . . . . . . . . . . . . . . . . . 91
8.3.8 Transaction Lifecycle Listeners . . . . . . . . . . 92
8.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.1 Einleitung
Ein Software Transactional Memory ist kurz gesagt eine Moglichkeit schnellund unkompliziert verteilte Systeme zu entwickeln. Mittlerweile gibt es einigeverschiedene STMs in vielen verschiedenen Programmiersprachen. Obwohl Scalaund Akka zwei Programmiersprachen mit den selben Wurzeln sind, entwickeln beideihr jeweils eigenes STM. In den folgenden Kapiteln wird kurz auf TransactionalMemories im Allgemeinen eingegangen. Nach den Grundlagen folgt ein Vergleichder beiden STMs von Scala und Akka.
8.2 Grundlagen
In den Grundlagen wird erklart, was ein Transactional Memory ist. Es wird kurz aufdie unterschiedlichen Moglichkeiten ein Transactional Memory umzusetzen einge-
86 8 Scala STM vs. Akka STM
gangen und schlussendlich wird die Arbeitsweise speziell der Software TransactionalMemories erlautert.
8.2.1 Software Trans–Was?
Um kurz auf die Grundlagen des Themas einzugehen, wird zuerst auf das TM ausSTM eingegangen. TM steht fur Transactional Memory zu deutsch transaktionalerSpeicher. Die Idee des transaktionalen Speichers ist relativ neu. TransaktionalerSpeicher ist ein Speicherkonzept fur parallele Berechnungseinheiten. Berechnungs-einheiten konnen Threads in einem Prozess, Prozesse auf einer CPU, Prozessorkernein einem Rechner oder auch verschiedene Rechner in einem Netzwerk sein.Transaktionaler Speicher kann in 3 Varianten umgesetzt werden.
Software Transactional Memory ist eine rein durch Software umgesetzte Vari-ante. Es gibt mittlerweile eine große Palette an verschiedenen STMs. ClojureSTM, Scala STM und Akka STM sind nur 3 bekannte Vertreter. Im Großenund Ganzen ahneln sie sich alle, aber jedes einzelne verfolgt hier und da seineeigenen Ansatze.
Hardware Transactional Memory basieren auf Hardware wie z. B. CPUs odereigens entwickelten Speicherbauteilen. HTMs sind i. d. R. schneller als STMs.Da sie aber bei weitem nicht so komplexe Rechenvorgange abarbeiten konnen,sind sie noch keine Konkurrenz zu STMs.
Hybrid Transactional Memory stellen eine Mischung aus STM und HTM dar.Simple Berechnungen werden durch HTM gelost, wahrend komplexere Pro-bleme weiterhin durch STM verarbeitet werden. IBMs Blue Gene/Q arbeitetbereits mit HybridTM. Intels Haswell Chips, die voraussichtlich im 2. Quartal2013 auf den Markt kommen, werden auch auf HybridTM-Technologie setzen.
8.2.2 Arbeitsweise von STMs
Software Transactional Memories nutzen den Arbeitsspeicher um eine Art Daten-bank zu erstellen. Genauer: sie wandeln den Heap in eine transaktionale Daten-struktur mit begin/commit/rollback-Semantik um. Sie implementieren die ersten3 Buchstaben des ACID-Paradigmas[1]:
Atomaritat bedeutet, dass entweder alle in ihr beinhalteten Schritte durchgefuhrtwerden, oder es wird kein einzelner durchgefuhrt.
Konsistenz zu wahren ist eine wichtige Aufgabe. Egal wo die Daten liegen odervon wo auf sie zugegriffen wird. Sie mussen nach einer Transaktion in einemkonsistenten Zustand sein.
8.3 Vergleich 87
Isoliertheit garantiert die absolute Trennung der einzelnen Transaktionen von-einander. Benotigt eine Transaktion Zugriff auf eine Ressource, so ist sie dieeinzige die darauf zugreifen darf. Hier muss naturlich zwischen Lese– undSchreibzugriffen unterschieden werden.
Die Dauerhaftigkeit macht bei einem fluchtigen Speicher wie dem RAM naturlichkeinen Sinn.Ein STM stellt also eine programmiertechnische Moglichkeit, Transaktionen zuerstellen, sie atomar und isoliert durchzufuhren, wobei ein konsistenter Zustand derDaten garantiert wird. Der Programmierer muss sich weder um commits noch umrollbacks kummern. Mutexe und Semaphoren generiert der STM automatisch. DerProgrammcode kann durch hohe Lesbarkeit besser verstanden und gewartet werden.Deadlocks werden automatisch verhindert. Der Programmierer kann effizienterarbeiten.
8.3 Vergleich
Im Folgenden wird ein direkter Vergleich der beiden STMs von Scala und Akkaangestellt. Hierzu wird Code in Akka und danach Code in Scala mit der selbenbzw. vergleichbaren Funktionalitat gezeigt. Nach den Codebeispielen werden dieseerlautert und es wird auf Unterschiede und Gemeinsamkeiten eingegangen.
8.3.1 Aufbau einer Transaktion
Listing 8.1: Aufbau einer Transaktion in Akka
1 import akka.stm._2
3 // implicit val txn = TransactionFactory(4 // readonly = true)5
6 atomic{7 // code8 }
Listing 8.2: Aufbau einer Transaktion in Scala
1 import scala.concurent.stm._2
3 atomic{ implicit txn =>4 // code5 }
Wie in Listing 8.1 und Listing 8.2 zu sehen ist, ahnelt sich der Aufbau beiderTransaktionen sehr stark.Mit atomic wird eine Transaktion eingeleitet. In den
88 8 Scala STM vs. Akka STM
geschweiften Klammern wird der atomar auszufuhrende Code geschrieben.In Scala wird zudem unbedingt eine implizite transaction factory benotigt. Ohnedie Codezeile implicit txn => erkennt der Compiler den atomic-Block nicht alssolchen und es kann nicht auf Referenzen (siehe 8.3.2) zugegriffen werden. Dader Zugriff auf Referenzen der Sinn und Zweck von atomic-Blocken ist, wird manim Fall des Vergessens der transaction factory zwangslaufig mit Compilerfehlernuberhauft werden.
8.3.2 Erstellen einer Reference
Listing 8.3: Erstellen einer Reference in Akka
1 // giving an initial value2 val ref1 = Ref(0)3
4 // specifying a type but no initial value (null)5 val ref2 = Ref[Int]
Listing 8.4: Erstellen einer Reference in Scala
1 // giving an initial value2 val ref1 = Ref(0)3
4 // specifying a type with default value5 val ref2 = Ref.make[String]()
Eine Reference stellt eine Speicherzelle innerhalb des STM dar. Sie wird in Akkaund in Scala uber eine Instanz von Ref() deklariert. In die Klammern von Ref()
kommt der Wert, den die Reference beinhalten soll. Das kann alles mogliche sein:Standardtypen wie long, double, char aber auch Maps, Sets usw. Wahrend manin Akka z. B. mit val ref = Ref[Int] eine Reference, in diesem Fall vom Typint, ohne Wert definieren kann, ist das in Scala so nicht moglich. In Scala besitzteine Reference immer einen Wert. Auch wenn es nur ein z. B. mit val ref =
Ref.make[int]() generierter Defaultwert ist.
8.3.3 Zugriff auf den Wert einer Reference
Listing 8.5: Zugriff auf den Wert einer Reference in Akka
1 atomic{2 val i = ref1.get3 }4
5 atomic{6 ref1.set(5)7 }
8.3 Vergleich 89
Listing 8.6: Zugriff auf den Wert einer Reference in Scala
1 atomic{ implicit txn =>2 val i = ref1.get //oder3 val j = ref1()4 }5
6 atomic{ implicit txn =>7 ref1.set(5)//oder8 ref1() = 59 }
In beiden STMs ist es moglich uber die Member-Funktion get() an den Werteiner Reference zu kommen. Genauso kann man mittels set() den Wert einerReference andern. Scalas STM bieten zusatzlich eine weitere Moglichkeit. Hierkann man get und set() durch ein Klammerpaar ersetzen und somit eine bessereLesbarkeit des Quellcodes erreichen.
8.3.4 Zugriff auf den Wert einer Reference uber Funktionen
Listing 8.7: Zugriff auf den Wert einer Reference uber Funktionen in Akka
1 atomic{2 val k = ref1 alter(_ + 5)3 }
Listing 8.8: Zugriff auf den Wert einer Reference uber Funktionen in Scala
1 atomic{ implicit txn =>2 val k = ref1.transform{_ + 5}3 val pre = ref1.getAndTransform{_ + 100}4 val post = ref1.transformAndGet{_ + 100}5 }
In den STMs von Akka und Scala ist es neben get() und set() moglich, denWert einer Reference mit Hilfe einer Funktion zu andern. In Akka funktioniert dasuber alter(). In den Klammern wird die Funktion, die auf den Wert der Referenceausgefuhrt werden soll, ubergeben. Scala bietet hierfur die Funktion transform an.Des weiteren gibt es die Funktionen getAndTransform sowie transformAndGet.Wie die Namen vermuten lassen, wird bei Ersterem der Wert der Reference alsRuckgabewert zuruckgegeben, der vor der Anwendung des Funktionsrumpfes inihr gespeichert war. Bei transformAndGet wird zuerst der Funktionsrumpf aufden Wert der Reference angewendet. Als Ruckgabewert dient der neu berechneteWert.
8.3.5 Single-Operation-Transaktionen
Listing 8.9: Single-Operation-Transaktionen in Akka
90 8 Scala STM vs. Akka STM
1 def isZero = atomic{2 ref1.get == 03 }
Listing 8.10: Single-Operation-Transaktionen in Scala
1 // def isZero = atomic{ implicit txn =>2 // ref1() == 03 // }4
5 def isZero = ref1.single() == 0
Wahrend man in Akka nur innerhalb eines atomic–Blocks auf References zugreifenkann, bietet Scala eine weitere Moglichkeit. Durch den Aufruf ref.single()
bekommt man ein View-Objekt auf die Reference zuruckgegeben. Das View-Objektverhalt sich nicht anders als eine Reference, außer dass man es auch außerhalb einesatomic–Blocks nutzen kann. Das simple zuruckgeben des Wertes einer Referenceist genauso moglich wie das andern des Wertes uber ref.single().set() undref.single().transform. Neben der besseren Lesbarkeit hat das Verwendeneines einzelnen View-Objektes auch Performancevorteile gegenuber einem atomic–Block mit nur einem einzigen Zugriff auf eine Reference.
8.3.6 Blocken von Transaktionen
Listing 8.11: Blocken von Transaktionen in Akka
1 atomic{2 if(ref1.get == 0)3 retry4 ref1.set(ref1.get - 1)5 }
Listing 8.12: Blocken von Transaktionen in Scala
1 atomic{ implicit txn =>2 if (ref1() == 0)3 retry4 ref1() -= 15 }
Das Blocken von Transaktionen ist ein hilfreiches Feature. Durch das Blockenvon Transaktionen kann eine Behandlung von unnotigen Exceptions umgangenwerden, indem man diese unnotigen Exceptions gar nicht erst auftreten lasst.Mit dem Befehl retry kann man eine Transaktion manuell zuruckrollen lassen.Gekoppelt mit einer oder mehreren vorherigen if–Anweisungen kann man komplexeFehlerabfangstrukturen erstellen. Kommt die fertige Applikation an einem retry
an, wird der komplette atomic–Block zuruckgerollt. Das STM speichert die
8.3 Vergleich 91
Abhangigkeiten bzw. die References die fur den retry verantwortlich waren ab.Sobald sich der Wert einer der References andert, wird versucht die Transaktionerneut durchzufuhren.
8.3.7 Alternative Blocke
Listing 8.13: Alternative Blocke in Akka
1 either{2 if(ref1.get == 0)3 retry4 ref1.set(ref1.get - 1)5 }6 orElse{7 if(ref2.get == 0)8 retry9 ref2.set(ref2.get - 1)
10 }
Listing 8.14: Alternative Blocke in Scala
1 atomic{ implicit txn =>2 if (ref1() == 0)3 retry4 ref1() -= 15 }6 orAtomic{ implicit txn =>7 if (ref2() == 0)8 retry9 ref2 -= 1
10 }
Alternative Blocke konnen als Erweiterung des Blockens von Transaktionen 8.3.6gesehen werden. Als alternative Blocke werden mehrere Transaktionen bezeich-net, die stellvertretend fureinander durchgefuhrt werden konnen. In Akkas STMwird hierzu der eigentliche atomic–Block zu einem either–Block. Er stellt dieTransaktion dar, die als erstes ausgefuhrt werden soll. Sie ist sozusagen der Nor-malfall. Sollte die Applikation in diesem Block auf ein retry stoßen, wird siezuruckgerollt. Anstatt nun wie beim normalen Blocken von Transaktionen daraufgewartet wird, dass sich Werte von Referencen andern, springt die Applikationin eine alternative Transaktion. Diese wird in Akka mit orElse gekennzeichnet.Sollte diese Transaktion, ohne auf ein weiteres retry zu stoßen, durchlaufen, giltdie Transaktion als abgeschlossen. Es konnen in diesem Verfahren beliebig vieleweitere orElse–Blocke angefugt werden. In dem Fall, dass keiner der alternativenBlocke fehlerfrei durchlaufen werden konnte, rollt der STM alles zuruck, springtwieder zur Normalfall-Transaktion zuruck und wartet auf Anderungen an denWerten der beteiligten References. Der einzige Unterschied von Scala STM zuAkka STM ist in diesem Fall die Bezeichnung der Transaktionsblocke. Scalas
92 8 Scala STM vs. Akka STM
Normalfall-Transaktion bleibt dem Namen atomic treu, wahrend die alternativenBlocke den Bezeichner orAtomic tragen.
8.3.8 Transaction Lifecycle Listeners
Listing 8.15: Transaction Lifecycle Listeners in Akka
1 atomic{2 deferred(new Runnable() {3 public void run(){4 // runs after commit5 }6 });7 compensating(new Runnable(){8 public void run(){9 //runs after rollback
10 }11 });12 // transaction code here13 }
Listing 8.16: Transaction Lifecycle Listeners in Scala
1 atomic{implicit txn =>2 txn.afterCommit{3 // runs after commit4 }5 txn.afterRollback{6 // runs after rollback7 }8 txn.afterCompletion{9 // runs after commit and rollback
10 }11 // transaction code here12 }
Wie bei vielen anderen Funktionen und Programmen muss man auch nach Trans-aktionen eventuell etwas aufraumen. Fur diesen Fall stellen Scala und Akkaverschiedene Funktionen bereit. In Akka sind das deferred und compensating.Die Funktionen werden einfach in den atomic–Block geschrieben. Der Codeinnerhalb von deferred wird ausgefuhrt, sobald die Transaktion erfolgreich durch-gefuhrt, also commited wurde. Dagegen wird der Code in compensating beieinem Rollback der Transaktion ausgefuhrt. In Scala sind die Funktionen Mem-ber der transaction factory. Code, der nach einem commit ausgefuhrt werdensoll, muss in txn.afterCommit geschrieben werden. In txn.afterRollback
kommt der Code fur den Fall eines Rollbacks. Zusatzlich bietet Scalas STM mittxn.afterCompletion einen Codeblock an, der immer am Ende der Transaktionausgefuhrt wird. Ganz egal ob diese erfolgreich durchgefuhrt werden konnte, oderob ein Rollback notig war.
8.4 Fazit 93
8.4 Fazit
Die beiden STMs von Scala und Akka ahneln sich sehr in ihrer Syntax undArbeitsweise. Dennoch ist die Scala STM-Syntax z. B. durch die kurze Schreibweisevon ref() anstatt von set() und get() besser lesbar. Vom Funktionsumfangsind beide nahezu gleich auf. Zum Zeitpunkt der Erstellung dieses Textes kamdas STM von Scala jedoch noch nicht ganz an das Akka STM heran. Das wirdsich jedoch in Kurze andern. Schliesslich sitzt einer der großen Kopfe des AkkaProjektes — Jonas Boner — auch im Entwicklerteam des Scala STM. In der ScalaSTM Expert Group sitzen außerdem viele weitere Experten zum Thema STM.Nicht zuletzt deshalb, haben sie es sich zum Ziel gesetzt, dass das Scala STM indie Scala Standard Library aufgenommen wird. Dieses Ziel ist bald erreicht. Somitwird das STM von Akka uberflussig, da Akka per Definition nur eine Erweiterungzu Scala darstellen soll. In weiser Voraussicht hat Typesafe — die Entwickler vonAkka — die Weiterentwicklung ihres STMs gestoppt. Seit Akka 2.0 wird somitnur noch das Scala STM unterstutzt.
Literaturverzeichnis
[1] Typesafe Inc, Akka Documentation Release 1.3.1http://doc.akka.io/docs/akka/1.3.1/Akka.pdf, 19.06.2012.
[2] Nathan Bronson, Scala STM — Library–Based Software Transactional Memoryhttp://nbronson.github.com/scala-stm/index.html, 19.06.2012.
94 8 Scala STM vs. Akka STM
9 SwarmMarie-Christin Reusche
Inhaltsverzeichnis
9.1 SWARM - allgemein . . . . . . . . . . . . . . . . . . . . 95
9.2 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . 96
9.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . 96
9.2.2 Platform-as-a-Service (PaaS) . . . . . . . . . . . 98
9.3 SWARM - im Detail . . . . . . . . . . . . . . . . . . . . 98
9.4 SWARM - Demos . . . . . . . . . . . . . . . . . . . . . . 103
9.4.1 Demo 1 - ForceRemoteRef.scala . . . . . . . . . 103
9.4.2 Demo 2 - ExplicitMoveTo1.scala . . . . . . . . . 104
9.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.1 SWARM - allgemein
SWARM ist ein Open-Source-Framework fur Berechnungen in der Cloud und gehtdem Grundgedanken
“move the computation, not the data”[4]
nach. Das bedeutet, dass sich die auf einem Computer anstehenden Berechnungenbewegen sollen und nicht die dafur benotigten Daten.
Mit diesem Hintergrund entwickelte ein aus Irland stammender Informati-ker und Entwickler – Ian Clarke – dieses Framework. Es wurde von ihm imSeptember 2009 in den USA bei der
”IEEE Ninth International Conference on
Peer-to-Peer Computing in Seattle“ vorgestellt.1 SWARM befand sich bei dieserVorstellung - wie auch heute immer noch - in der “Proof of Concept-Phase”. Dasbedeutet, dass das Framework ein entwickelter Prototyp ist, der alle benotigtenKernfunktionalitaten beinhaltet. Das Framework wurde in der Scala-Version 2.8implementiert.
1 Vgl. [5]
96 9 Swarm
Auf der Homepage von SWARM wird das Framework der Kategorie Platform-as-a-Service des Cloud Computings zugeordnet. Was dies bedeutet, wird im Kapitel9.2 naher erlautert.
9.2 Cloud Computing
In diesem Kapitel soll aufgezeigt werden, was unter dem Begriff Cloud Computingsowie Platform-as-a-Service zu verstehen ist.
9.2.1 Definition
Dieser Begriff setzt sich aus zwei Wortern zusammen, die im Folgenden einzelnbetrachtet und am Ende im Zusammenhang dargestellt werden.
Cloud ist ein englischer Begriff und bedeutet im Deutschen “die Wolke”.Diese Wolke soll fur das Internet stehen, in der alle ausgelagerten Dienstedargestellt werden konnen.
Computing stammt ebenfalls aus dem englischsprachigen Raum und wird imDeutschen als die Aktivitat der Nutzung und Verbesserung von Hard- undSoftware gesehen.
Abbildung 9.1: Die Rechnerwolke2
9.2 Cloud Computing 97
Das Cloud Computing kann daher mit dem Begriff “Rechnerwolke” inVerbindung gebracht werden, welcher in Abbildung 9.1 dargestellt ist. Somitwerden IT-Leistungen uber das Internet oder innerhalb eines Netzwerkes einerFirma in Echtzeit bereitgestellt und nach deren Nutzung abgerechnet. Beispielefur IT-Leistungen konnen sein: Software, Plattformen fur Entwicklungen sowieSpeicherplatz als eine Basis-Infrastruktur.3
Die zu betrachtenden Nutzergruppen spielen eine entscheidende Rolle,damit Cloud Computing richtig eingesetzt werden kann. Daraus ergibt sich,welche Art von Cloud Computing eingesetzt und welche technische Realisierungumgesetzt werden soll. Auf die Arten von Cloud Computing wird in diesemArtikel nicht weiter eingegangen, da sie fur SWARM eher unbedeutend sind.Die technischen Realisierungen werden heute auch als Kategorien des CloudComputings bezeichnet.4 Die folgenden drei Kategorien werden in Abbildung 9.2aufgegriffen und voneinander abgegrenzt.
Software-as-a-Service (SaaS)
Platform-as-a-Service (PaaS)
Infrastructure-as-a-Service (IaaS)
Abbildung 9.2: Kategorien des Cloud Computings5
Im Hinblick auf SWARM wird im weiteren Verlauf nur die Kategorie Platform-as-a-Service naher beleuchtet.
2 Quelle: [8].3 Vgl. [6]4 Vgl. [2]5 Quelle: [2].
98 9 Swarm
9.2.2 Platform-as-a-Service (PaaS)
Da SWARM ein Framework fur Berechnungen in der Cloud ist, muss es sichum die Kategorie PaaS des Cloud Computings handeln. Dies wird auch auf derHomepage von SWARM dargestellt.6
Beim Ansatz des Platform-as-a-Service wird eine proprietare Laufzeitum-gebung von dem Anbieter in der Cloud zur Verfugung gestellt. Der Nutzerkann so auf einfache Weise seine Software in die Cloud einbringen. Eine auf dieLaufzeitumgebung abgestimmte Software kann dadurch bspw. bei der Ausfuhrungfrei skaliert werden.7
9.3 SWARM - im Detail
In diesem Kapitel wird das Framework naher vorgestellt. Hier wird zum Beispiel dar-auf eingegangen, warum SWARM in Scala geschrieben wurde, wie das Frameworkfunktioniert und was es derzeit noch fur Probleme gibt.
Warum Scala?
Scala kann zu Java-Bytecode kompiliert werden und ist somit auf der Java VirtualMachine (JVM) ausfuhrbar. Dies bringt einen großen Vorteil mit sich, da die JVMschnell und weit verbreitet ist.
Ein weiterer und vor allem der wichtigste Grund, warum sich Ian Clarkefur Scala entschieden hat, sind die sogenannten “portable continuations”. Sie sindseit der Scala Version 2.8 verfugbar. Zum Zeitpunkt der Entwicklung von SWARMwar Scala die einzige Programmiersprache, die diese Funktionalitat unterstutzte.So bot zum Beispiel Haskell zu dieser Zeit nur die Moglichkeit der “einfachen”continuations.
portable continuations
Die portable continuations kommen aus der funktionalen Programmierung. Umsich vorstellen zu konnen, was darunter zu verstehen ist, soll im Folgenden einBeispiel erklaren.
Wenn von einer Person ein Computerspiel gespielt wird, mochte diese si-cherlich das Spiel speichern und zu einem spateren Zeitpunkt an der gespeicherten
6 Vgl. [1]7 Vgl. [2]
9.3 SWARM - im Detail 99
Stelle weiter spielen. Somit kann dann das Computerspiel von jedem beliebigenOrt - also PC - weiter gespielt werden. Im Bezug auf die portable continuationsbedeutet es, dass aus dem Programm heraus das Programm eingefroren wird. DasProgramm kann dann zum Beispiel an einen anderen PC geschickt, auf eine CDgespeichert oder uber ein Netzwerk versendet werden. Wenn dies geschehen ist,kann das Programm am eingefrorenen Zustand fortgesetzt werden.
Im Allgemeinen sind die portable continuations sehr komplex, weshalbSWARM diese fur den Programmierer auf ein einfaches und verstandliches Niveauabstrahiert. Weiterhin musste sich der Programmierer Gedanken machen uber:
Wie gelangen die Daten von A nach B?
Welche Daten werden uberhaupt benotigt?
Die Losung: SWARM
SWARM beschaftigt sich mit folgender zentralen Leitfrage:
“What if we could distribute data and computation across multiple compu-ters such that the programmer need not think about it?”[7]
Hier wird der Ansatz der portable continuations aufgegriffen, dass sich derProgrammierer uber bestimmte Dinge Gedanken machen muss. Das Konzeptvon SWARM will namlich genau das Gegenteil erreichen, so dass sich derProgrammierer keine Gedanken mehr machen muss. Er muss nicht mehr wissen,wie alles funktioniert, wenn Daten und Berechnungen auf mehrere Rechner verteiltwerden. Aber wie soll das gehen?
Das Framework SWARM geht zwei Leitgedanken nach:
1. Leitgedanke - “Move the computation, not the data.”Dieser Leitgedanke entspricht dem gleichen Prinzip des MapReduce von Google.Hier soll ein Problem auf mehrere Teilprobleme zerlegt und danach verteiltwerden. Doch bei MapReduce muss der Programmierer selbst herausfinden, wiedas Problem am Besten zerlegt werden kann. Er muss sich daruber Gedankenmachen, welche Losung die sinnvollste ist. Diese Aufgabe soll das FrameworkSWARM selbst ubernehmen und alleine die Teilprobleme herausfinden, ohne dasder Programmierer seine Finger mit im Spiel hat. Dadurch wird das Vorgehenfur den Programmierer allgemeiner und transparenter.
100 9 Swarm
2. LeitgedankeLeider gibt es fur diesen Leitgedanken keinen kurzen pragnanten Satz, wiees der 1. Leitgedanke her gibt. Bei dem 2. Leitgedanken handelt es sichum eine Erweiterung des 1. im Bezug auf die Zerlegung der Teilprobleme.Denn das Konzept von SWARM beinhaltet die Idee, dass die Daten so gutaufbereitet bzw. klug strukturiert sein sollen, dass die Berechnungen nichthaufig verschoben werden mussen. Da dieser Vorgang ressourcenintensiv istund somit ein Performance-Problem entstehen konnte.
Wie SWARM funktioniert
Die gewunschte Funktionalitat von SWARM soll in diesem Abschnitt anhand einesBeispiels erlautert werden. Dieses Beispiel lasst sich im Vorstellungsvideo auf derHomepage wiederfinden.
Zuerst ein paar allgemeine Erklarungen des Beispiels, die fur alle dreiAbbildungen wichtig sind:
Rechtecke - damit werden verschiedene Rechner dargestellt.
Punkte - sind die einzelnen Daten auf den Rechnern.
Pfeile - stellen die Berechnungen dar, die auf die Daten zugreifen.
a/b/c - werden als Beispieldaten genutzt.
Das auf der rechten Seite befindliche Rechteck entspricht einem sehr einfachenProgramm. Die Abbildung 9.3 zeigt, was passiert, wenn print a aufgerufen wird.Das Programm greift auf die Daten a zu und gibt das entsprechende Ergebnis aus.
Abbildung 9.3: Wie SWARM funktioniert - 18
8 Screenshot von [7].
9.3 SWARM - im Detail 101
Im weiteren Verlauf wird print b ausgefuhrt. Hier ergeben sich keine Probleme,da sich die Daten b auf dem gleichen Rechner wie die Daten a befinden. Daherkonnen die Daten b einfach ausgegeben werden (siehe Abbildung 9.4).
Abbildung 9.4: Wie SWARM funktioniert - 29
Wie in der Abbildung 9.5 ersichtlich ist, befinden sich die Daten c auf einemanderen Rechner als die Daten a und b. Wenn es zum Aufruf von print c kommt,konnen die Daten von c ausgegeben werden, aber das Framework SWARM mussintern einige Schritte mehr tun. Das Programm befindet sich zunachst auf demersten Rechner, wo die Daten a und b ausgegeben wurden sind. Dann wird dieserZustand des Programms eingefroren und an den Rechner geschickt, auf welchemsich die Daten c befinden. Hier wird das Programm wieder ausgepacktund an derStelle weiter ausgefuhrt, an welcher es auf dem ersten Rechner eingefroren wurde.
Abbildung 9.5: Wie SWARM funktioniert - 310
9 Screenshot von [7].10Screenshot von [7].
102 9 Swarm
Das Verschieben der Berechnung ist daher sehr zeitintensiv. Hier setzt der 2.Leitgedanke von SWARM an: Die Daten sollen so aufbereitet sein, dass so wenigwie moglich Verschiebungen zwischen unterschiedlichen Rechnern stattfindenmussen.Doch wie diese Anforderung umgesetzt werden kann, ist noch bis heute mit einemgroßen Fragezeichen bei SWARM versehen.
aktuelle Probleme
Hinter SWARM steckt ein sehr guter Gedanke, doch wie schon bisher aufgezeigtwurde, sind in der Umsetzung noch immer Probleme vorhanden. Die folgendeUbersicht soll Probleme aufzeigen und diese ein wenig erklaren.
Aufbereitung der DatenHier ergibt sich die folgende Frage: “Wie sollen die Daten arrangiert werden,dass alles effizient bleibt?”. Das Team hinter SWARM hat sich das Ziel gesetzt,die benotigten Daten so zu strukturieren, dass die Zahl der Berechnungsver-schiebungen minimiert wird. Diese Aufbereitung der Daten soll automatischund kontinuierlich vom Framework durchgefuhrt werden. Zur Losung dieserThematik sind verschiedene Ideen vorhanden, leider gibt es aber noch keinenfunktionierenden und implementierten Ansatz.
Sicherstellung von ReplikationenEs muss eine gewisse Redundanz der Daten vorhanden sein, um irgendwelchenAusfallen entgegenwirken zu konnen. Gerade auch im Bezug auf Cloud Computingist dies ein wichtiger Punkt, der zu beachten ist.
NebenlaufigkeitAuch bei SWARM spielt die Parallelisierung von Prozessen zur Performancesteige-rung eine wichtige Rolle. Da es sich hierbei aber um ein verteiltes System handelt,steigt die Komplexitat an. Um sicherstellen zu konnen, dass alle Prozesse inmanchen Bereichen synchron arbeiten, spielen die Entwickler mit dem Gedanken,SWARM um das Konzept des Software Transactional Memory zu erweitern. Sokonnten auch Synchronisationsprobleme in der Cloud gelost werden.
Garbage CollectionDie Uberlegungen gehen auch in die Richtung SWARM um eine Java-ahnlicheGarbage Collection zu erweitern und so die nicht mehr benotigten Daten nacheiner gewissen Zeit vom System zu loschen. Aber wie soll das System selbststandigerkennen und entscheiden, welche Daten nicht mehr benotigt und geloscht werdenkonnen, wenn mehrere Rechner im Verbund arbeiten und darauf zugreifen.
9.4 SWARM - Demos 103
einheitliche CodebasisEin weiteres Problem stellt eine einheitliche Codebasis dar. Diese wird dringendgebraucht, damit alle zu verwendenden Klassen auf jedem Rechner verfugbar sind.Bei SWARM gibt es auch eine Idee fur die Umsetzung, der JVM classloader. Indem Fall konnen dann die laufenden SWARM-Instanzen die benotigten Klassenvon einer globalen Anlaufstelle ziehen und verwenden.
SWARM-spezifische Collection-KlassenFur SWARM werden Framework-spezifische Collection-Klassen wie Map, List,Set gebraucht. In Scala sind diese Klassen zwar vorhanden, aber leider nichtfur ein verteiltes System ausgelegt. Denn bei SWARM soll ein Programm aufmehreren Rechnern laufen.
9.4 SWARM - Demos
Mit zwei kleinen und leicht verstandlichen Demos soll im Folgenden veranschaulichtwerden, was in SWARM bisher schon umgesetzt und was damit schon moglichist. Bei github11 liegen diese sowie weitere Demos und konnen somit leicht vonjedermann getestet werden. Die folgenden Listings wurden zur besseren Lesbarkeitund zum besseren Verstandnis auf den notigsten Quellcode zusammengekurzt.
9.4.1 Demo 1 - ForceRemoteRef.scala
Wie schon bereits erwahnt, soll SWARM den Zugriff auf die verteilten Datenermoglichen. Dies wird in dem zweiten Leitgedanken aufgenommen. Derzeit kanndies uber die Funktion Ref geschehen. Ein Beispiel dazu ist in dem Listing 9.1 zusehen.
Listing 9.1: Demo 1
1 println("1")
2 val vLoc = Ref(local, "test local string")
3 println("2")
4 val vRem = Ref(remote, "test remote string")
5 println("3")
6 println(vLoc())
7 println("4")
8 println(vRem())
9 println("5")
11Vgl. [3]
104 9 Swarm
Es wird fur die zwei angelegten Variablen vLoc und vRem jeweils eine Referenzauf zwei verschiedene “virtuelle” Rechner erzeugt. Am Anfang wird die Zahl 1ausgegeben. Da im Anschluss die Variable vLoc definiert wird, bleibt das Programmim ersten Ausgabefenster stehen und gibt dann die Zahl 2 aus. Es wird ja explizitgesagt, dass sich die Variable auf dem lokalen System befindet. Bei dem Anlegender zweiten Variablen springt das Programm in das zweite Ausgabefenster undgibt dann die Zahl 3 aus. Wie die einzelnen Ausgabefenster aussehen, zeigen dieListings 9.2 und 9.3.
Listing 9.2: Ausgabe der ersten Konsole
1 1
2 2
3 test local string
4 4
Listing 9.3: Ausgabe der zweiten Konsole
1 3
2 test remote string
3 5
9.4.2 Demo 2 - ExplicitMoveTo1.scala
Dieses kleine Beispiel (siehe Listing 9.4) zeigt die Umsetzung des ersten Leitge-dankens von SWARM. Hier wird vom Programmierer noch explizit angegeben, aufwelchen Host die Berechnung verschoben werden soll. Dies wird mit der FunktionmoveTo umgesetzt.
Listing 9.4: Demo 2
1 val name = scala.Console.readLine("What is your name? :
");
2 Swarm.moveTo(new InetLocation(java.net.InetAddress.
getLocalHost, 9997))
3 val age = Integer.parseInt(readLine("Hello " + name + "
, what age are you? : "))
4 Swarm.moveTo(new InetLocation(java.net.InetAddress.
getLocalHost, 9998))
5 println("Wow " + name + ", you’re half way to " + (age
* 2) + " years old")
9.5 Fazit 105
Es werden zwei Variablen angelegt (name und age), die jeweils die Eingaben desNutzers als String fassen sollen. Beim Aufruf des Programms wird der Nutzer nachseinem Namen gefragt. Nach der Eingabe wird das Programm eingefroren und aneine andere Location (einen anderen Host) gesendet. Dort wird das Programmweiter ausgefuhrt und der Nutzer wird mit seinem Namen angesprochen undnach seinem Alter gefragt. Nun wird das Programm wieder an den ersten Hostzuruckgesendet, welcher dann den abschließenden Text des Programms ausgibt.Um sehen zu konnen, welche Ausgaben auf welchem Host gemacht werden, sinddie Listings 9.5 und 9.6 dargestellt.
Listing 9.5: Ausgabe des Host 9998
1 What is your name? : (Marie)
2 Wow Marie, you’re half way to 50 years old
Listing 9.6: Ausgabe des Host 9997
1 Hello Marie, what age are you? : (25)
9.5 Fazit
Zusammenfassend kann gesagt werden, dass die Idee, die hinter dem FrameworkSWARM steckt, sehr gut ist. Doch leider gibt es nach fast drei Jahren seit derVorstellung des Frameworks keine vollstandigen Losungen fur die Ansatze. Wie imKapitel 9.3 dargestellt, ist noch einiges an Denkleistung zu erbringen, um diegenannten Probleme und Fragen aus dem Weg zu raumen.
Im Folgenden werden noch einmal die Leitgedanken aufgenommen undabschließend betrachtet.
1. Leitgedanke - “Move the computation, not the data.”Fur die Autorin ist dieser Leitgedanke sehr gut nachvollziehbar und derzeitauch im Prototyp umgesetzt. Hier wird nur eine Sache vom Framework nichtautomatisch durchgefuhrt; und zwar muss der Programmierer noch explizitangeben, wohin die Berechnungen verschoben werden sollen. Dies kann mitder FUNKTION moveTo vom Programmierer geschehen. Doch irgendwannsoll ja das Framework diese Funktionalitat selbst ubernehmen.
2. LeitgedankeAn sich ist dieses Vorgehen ein guter Gedanke, doch fur die Autorin sehr schwervorstellbar. Denn wie soll das Framework selbst erkennen, welche Daten immer
106 9 Swarm
wieder gebraucht und genutzt werden? Und hierfur hat SWARM noch keineLosung und sucht selbst danach, wie die “perfekte” Aufbereitung der Datenaussehen soll bzw. umgesetzt werden kann. In dem Prototypen ist der Zugriffauf die verteilten Daten mit der Funktion Ref moglich.
Das Thema Cloud Computing war in dem Jahre 2009 ein sehr aktuelles Themaund es wurde in den vergangenen drei Jahren immer beliebter. Trotz hoherBeliebtheit und rasch wachsendem Interesse in diesem Bereich konnten bishernoch keine Losungen gefunden oder gravierende Fortschritte im Bezug auf diegenannten Probleme von SWARM gemacht werden.
SWARM ist ein einfacher Prototyp, dessen bisherige Umsetzungen schoneinige Ideen teilweise implementiert, aber von einer fertigen Anwendung noch weitentfernt ist. Die bereits zur Verfugung stehenden Funktionalitaten sind interessantund lassen einen auf ein zugiges Vorankommen der Entwickler hoffen.
Literaturverzeichnis
[1] Ian Clarke, swarm-dpl. http://code.google.com/p/swarm-dpl/, 31.05.2012.
[2] Holger Bleich, Sturm in die Wolke, Der Cloud-Boom und was Sie davon haben.c’t 10/12, S. 102.
[3] Ian Clarke, SWARM Github. https://github.com/sanity/Swarm/tree/master/swarm-demos/src/main/scala/swarm/demos, 31.05.2012.
[4] Ian Clarke, Swarm: A true distributed programming language.http://blog.locut.us/2008/10/07/swarm-a-true-distributed-programming-language/, 31.05.2012.
[5] bagwell, Swarm - Concurrency with Scala Continuations. http://www.scala-lang.org/node/3485, 30.05.2012.
[6] BITKOM, Cloud Computing. http://www.bitkom.org/de/themen/61490.aspx,10.07.2012.
[7] Ian Clarke, Swarm: Distributed Computation in the Cloud.http://vimeo.com/6614042, 30.05.2012.
[8] o. V., Cloud computing. http://en.wikipedia.org/wiki/Cloud computing,10.06.2012.
10 Synchronisation in ver-teilten Systemen
Ricardo Volkert
Inhaltsverzeichnis
10.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10.2 Uhrensynchronisation . . . . . . . . . . . . . . . . . . . . 108
10.2.1 Physikalische Uhren . . . . . . . . . . . . . . . . 109
10.2.2 Algorithmen zur Uhrzeitsynchronisation . . . . . . 110
10.2.3 Logische Uhren . . . . . . . . . . . . . . . . . . . 111
10.3 Gegenseitiger Ausschluss . . . . . . . . . . . . . . . . . . 113
10.3.1 Ein zentralisierter Algorithmus . . . . . . . . . . 113
10.3.2 Ein verteilter Algorithmus . . . . . . . . . . . . . 114
10.3.3 Ein Token-Ring-Algorithmus . . . . . . . . . . . . 115
10.4 Wahlalgorithmen . . . . . . . . . . . . . . . . . . . . . . 116
10.4.1 Der Bully-Algorithmus . . . . . . . . . . . . . . . 116
10.4.2 Ein Ringalgorithmus . . . . . . . . . . . . . . . . 118
10.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Vorwort: Die Inhalte der nachfolgenden Arbeit beziehen sich ausschließlich, sofernnicht anderweitig explizit genannt, auf Aussagen, Grafiken und Darstellungen derSeiten 261 bis 300 aus dem Werk “Verteilte Systeme Prinzipien und Paradigmen”in der 2. Auflage von Andrew S. Tanenbaum und Maarten van Steen, verlegtdurch die Pearson Education Deutschland GmbH.
10.1 Einleitung
Die rasante Entwicklung im Informations- und Telekommunikationsbereich unddes Internets als verteiltes System, haben es in den letzten Jahren notwendiggemacht, dass immer mehr Prozesse, Anwendungen und Systeme ihre Ressourcenbundeln und gemeinsam nutzen. Dieses Verhalten wirft jedoch eine Vielzahlvon Fragen und Verhaltensweisen auf, wie sich verteilte Systeme miteinanderverstandigen sollen ohne sich gegenseitig in ihrer Funktion zu beeintrachtigen.
108 10 Synchronisation in verteilten Systemen
Dabei umfasst die Thematik der verteilten Systeme eine große Bandbrei-te von Technologien und Vorschlagen, wie eine Kommunikation dabei umgesetztwerden kann. Im folgendem wird speziell auf die Synchronisation von verteiltenSystemen eingegangen. Dabei soll dem Leser ein Uberblick verschafft werden,warum beispielsweise das einfache Synchronisieren von Uhrzeiten enorm wichtigund keinesfalls trivial ist. Ferner werden Mechanismen vorgestellt, wie ein gegen-seitiger Ausschluss erreicht werden kann und welche Aufgaben Wahlalgorithmenhaben.
10.2 Uhrensynchronisation
Die Uhrzeit in einem Rechner bildet die Grundlage in welcher Reihenfolge Prozesseaufgerufen und ausgefuhrt werden. Nachdem ein Prozess angestoßen oder einProgramm ausgefuhrt wird, bekommt es einen Zeitstempel der die entsprechendeUhrzeit tragt. Werden verschiedene Prozesse in nur einem Rechner ausgefuhrt,spielt die tatsachliche Uhrzeit eine untergeordnete Rolle. Die Uhr kann mehrereSekunden, Minuten oder Stunden vor- beziehungsweise nachgehen, ohne dass diesAuswirkungen hat. Sobald Prozesse jedoch auf unterschiedlichen Rechnern laufenund gemeinsame Ressourcen nutzen, kann die richtige Uhrzeit eine entscheidendeRolle spielen.
Um zu verdeutlichen welche Auswirkungen ein solches Verhalten mit sichbringt, wird das verhalten am Beispiel des UNIX-Programm make verdeutlicht.Dieses Programm ermoglicht es große Dateisysteme nach Anderungen in einzelnenQuelldateien zu durchsuchen und diese zu identifizieren um sie anschließenddurch den Compiler neu kompilieren zu lassen. Auf diese Weise werden nur dieQuelldateien neu kompiliert, welche auch bearbeitet worden sind. In der Praxis wirdanhand eines Vergleiches zwischen der Quelldatei und der Objektdatei erkannt,ob neu kompiliert werden muss oder nicht. Hat die Quelldatei einen hoherenZeitstempel als die Objektdatei wird die Datei an den Compiler weitergegeben. Istdies nicht der Fall und die Objektdatei besitzt einen hoheren Zeitstempel als dieQuelldatei wird nichts unternommen.
In verteilten Systemen ist es daher enorm wichtig, dass alle Zeitstempelnach einer globalen Uhrzeit definiert sind. Angenommen dies ist nicht derFall, kann es zu Problemen kommen die nicht nachvollziehbar sind. So kanndie Erstellung einer Quelldatei im zeitlichen Ablauf nach der Erstellung derObjektdatei geschehen, durch unterschiedliche Uhrzeiten in den verteiltenSystemen aber einen niedrigeren Zeitstempel besitzen. Daraus resultiert, dass es
10.2 Uhrensynchronisation 109
zu keiner Kompilierung kommt und die Quelldatei nicht mehr zur entsprechendenObjektdatei passt. Solche Fehler lassen sich nur sehr schwer herausfinden undsind oft nicht nachvollziehbar.
Ziel dieses Kapitels ist es, einen kurzen Einblick in Algorithmen zur Uh-rensynchronisation zu geben und physikalische von logischen Uhren abzugrenzen.
10.2.1 Physikalische Uhren
Um zu verstehen, wie eine Uhrensynchronisation in verteilten Systemen ablauft,ist es notwendig, einen kurzen Einblick in die Funktion von physikalischenUhren oder auch Zeitgebern in Rechnern zu geben. Zeitgeber in Rechner sindherkommlicher Weise prazise hergestellte Quarzkristalle die unter Spannunganfangen zu oszillieren. Durch die Schwingung des Kristalls konnen mittelszweier Register, dem Zahler und dem Halteregister, Interrupts erzeugt werden.Dies geschieht dadurch, dass mit jeder Schwingung des Kristalls der Zahler, dervorher beispielsweise bei 60 Schwingungen pro Minute festgelegt wurde, umeins verringert wird und schließlich beim Erreichen der Null landet. Nach demausgelosten Interrupt ladt das Halteregister den Zeiger neu auf. Der Zeitgeberlasst sich auf diese Art und Weise mit einer gewunschten Frequenz programmieren.
Auch wenn die eingesetzten Quarzkristalle eine sehr stabile Frequenz beiden Schwingungen einhalten, kann nicht davon ausgegangen werden, dass diese inverschiedenen Rechnern nicht voneinander abweichen. Besteht ein System ausbeliebig vielen Rechnern muss also angenommen werden, dass alle Kristalle leichtasynchron schwingen und die Uhrenzeiten somit voneinander abweichen. DerEffekt verschiedener Zeitwerte wird auch als Uhrendrift bezeichnet. Als moglicheFolge konnten sich Fehler ergeben wie am Beispiel make bereits erlautert.
Um reale Uhrzeiten mit denen von Rechnern abgleichen zu konnen, wur-den im Laufe der Zeit mehrere Entwicklungen bis hin zur Atomuhr vollzogen.Aktuelle Rechner und Systeme nutzen die modernen staatlichen Zeiterfas-sungsverfahren wie UTC (Universal Coordinate Time). Diese basiert auf derAtomzeit und ist heute wesentlicher Standard in der Zeitgebung. Zu Beginn jederUTC-Sekunde wird von verschiedenen Sendern ein kurzes Signal gesendet, umsomit eine Synchronisation zu ermoglichen. In den USA wird fur diesen Zweck einKurzwellensender mit der Bezeichnung WWV genutzt.
110 10 Synchronisation in verteilten Systemen
10.2.2 Algorithmen zur Uhrzeitsynchronisation
Die Synchronisation verschiedener Uhren lasst sich am einfachsten durchzufuhren,wenn einer der beteiligten Rechner einen WWV-Empfanger besitzt. In diesem Fallsynchronisieren alle anderen Rechner ihre Uhrzeit gegen diesen einen Rechner.Algorithmen, die auf diesen Ansatz aufbauen, werden auch als passiv bezeichnet,da der Zeitgeber nur auf die Anfragen der anderen Rechner reagiert und ihnendie aktuelle Uhrzeit mitteilt. Ein Beispiel fur einen solchen Algorithmus ist NTP(Network Time Protocol).
Das Network Time Protocol (NTP)
Gemaß dem NTP verbindet sich ein Rechner mit dem Zeitserver, um die aktuelleUhrzeit abzufragen. Der Zeitserver ubermittelt die diese unter Berucksichtigungder Ubertragungsverzogerung. Das heißt, dass aufgrund der Ubertragungsdauereine gute Schatzung vorgenommen werden muss, um die richtige Uhrzeit zuubermitteln. Anhand der ubermittelten Zeitstempel beim Absenden und derZeitstempel beim jeweiligen Eingang einer Nachricht lasst sich eine Berechnungdurchfuhren und die richtige Uhrzeit ubermitteln. Eine Besonderheit ergibt sich,wenn die aktuelle Uhrzeit zu schnell lauft und somit zuruck gestellt werden muss.Da die Uhrzeit nicht ruckwarts laufen darf, weil dies zu Konflikten in Dateienmit verschiedenen Zeitstempeln fuhren kann, muss eine andere Losung gefundenwerden. Diese wird durch das Einfuhren von zusatzlichen Interrupts geschafft.
Angenommen ein Zeitgeber ist so eingestellt, dass er pro Sekunde 100 In-terrupts erzeugt und nach jedem Interrupt der Zeit 10 ms hinzufugt, so konnenbeispielsweise bei Verlangsamen stattdessen nur 9 ms oder beim Beschleunigen 11ms hinzugefugt werden. Auf diese Weise lasst sich die Zeit allmahlich anpassen.Eine weitere Besonderheit bei NTP ist das sogenannte Strata. Das Stratagibt Aufschluss daruber, ob ein Rechner an eine Referenzuhr (bspw. Atomuhr)angeschlossen ist. Ein solcher Rechner wird auch als Stratum-1-Server bezeichnet.Rechner die an keine Referenzuhr angeschlossen sind, werden als Stratum-k-Serverbezeichnet. Eine Anpassung der Uhrzeit wird dementsprechend immer nurgegenuber einem Rechner vollzogen, der ein kleineres Stratum besitzt.
Es gibt jedoch auch verteilte Systeme in denen kein Rechner uber einenWWV-Empfanger oder eine Atomuhr verfugt und der Zeitserver sich im gesamtenSystem nach der aktuellen Uhrzeit erkundigt, um die Uhrzeit zu bestimmen. EinVertreter dieser aktiven Algorithmen ist der Berkley-Algorithmus.
10.2 Uhrensynchronisation 111
Der Berkley-Algorithmus
Beim Berkley-Algorithmus ubernimmt ein Rechner die Aufgabe des Zeit-Deamons.Dieser teilt alle im Netzwerk befindlichen Rechner seine Uhrzeit mit und fragt sienach ihrer eigenen Zeit. Aus den Antworten wird die durchschnittliche Uhrzeitberechnet. Dabei reicht dem Deamon als Antwort die Differenz zur eigenen Uhrzeit.Anschließend teilt er allen Rechner mit, ob diese ihre Uhren vor- oder zuruckstellenmussen. Die Zeit des Zeit-Daemons wird in der Regel durch einen Administratorin regelmaßigen Abstanden neu eingestellt. Es ist bei diesem Verfahren nichtnotwendig, dass die Uhrzeit im Netzwerk mit der realen Uhrzeit ubereinstimmt.Es fuhrt auch zu keinerlei Problemen wenn der Zeit-Daemon lange nicht manuellnachgestellt wird, solange kein anderer im Netzwerk befindlicher Rechner mitaußen kommuniziert. Ein anschauliches Beispiel wird nachfolgend gegeben.
Abbildung 10.1: Berkley-Algorithmus
In Abbildung 10.1(a) sendet der Zeit-Daemon allen im Netzwerk befindlichenRechnern seine aktuelle Uhrzeit und erkundigt sich nach deren. Als Antwort wirddem Zeit-Daemon in Abbildung 10.1(b) die jeweilige Differenz zur mitgeteiltenUhrzeit ubermittelt. Aus der Differenz aller Zeiten wird ein Mittelwert gebildetund allen Rechnern in Abbildung 10.1(c) mitgeteilt, wie sie ihre Uhr anpassenmussen.
10.2.3 Logische Uhren
Eine Uhrzeitsynchronisation hangt jedoch nicht zwangslaufig mit der realenUhrzeit zusammen. Wenn ein Netzwerk sich nur untereinander verstandigt, reichtes aus, dass die Uhrzeit nur unter den Teilnehmern synchronisiert wird. Es reichtjedoch auch schon aus, wenn sich zwei Prozesse daruber einigen, wenn eine
112 10 Synchronisation in verteilten Systemen
Version einer Datei alter ist als die andere. Werden Algorithmen benutzt diediese Entscheidungen unterstutzen, wird von logischen Uhren gesprochen. Imnachfolgenden wird diese Thematik am Beispiel der logischen Uhren von Lamportdargelegt.
Lamport definierte die Bezeichnung happens-before, um logische Uhrenzu synchronisieren. Mittels des folgenden Ausdrucks kann somit angegebenwerden, in welcher Reihenfolge Ereignisse eingetreten sind: a → b besagt, dass dasEreignis a zeitlich gesehen vor b stattgefunden hat. Da die Relation transitiv ist,kann aus dem Ausdruck a → b und b → c entnommen werden, das a → c folgt.Wenn jedoch verschiedene Ereignisse in unterschiedlichen Prozessen eintreffenund nicht miteinander kommunizieren, kann keine Aussage daruber getroffenwerden, welche Ereignis zuerst stattgefunden hat. Die folgende Abbildung sollverdeutlichen, wie die logischen Uhren von Lamport arbeiten und was passiert,wenn eine Nachricht mit einem Zeitstempel ankommt, der großer ist als dereigene.
Abbildung 10.2: Die logischen Uhren von Lamport
In Abbildung 10.2(a) sendet der Prozess P1 eine Nachricht m1 an P2 und diesereine Nachricht m2 an P3. Auffallig dabei ist, dass die Zeitgeber der jeweiligenProzesse unterschiedlich schnell laufen. Da bei den ersten beiden Nachrichten dieZeit aber jeweils weiter fortgeschritten ist als beim Absenden, tritt kein Fehler auf.Beim Senden der Nachricht m3 von P3 an P2 und dem senden der Nachricht m4von P2 an P1 in Abbildung 10.2(b) kann nun jedoch geschlussfolgert werden, dass
10.3 Gegenseitiger Ausschluss 113
die Uhrzeit nicht richtig ist. Als Folge daraus werden die Uhren jeweils auf eineEinheit weiter vorgestellt, als der Zeitstempel beim Absenden aufweist. Auf dieseWeise justieren sich die Zeitgeber einer logischen Uhr.
10.3 Gegenseitiger Ausschluss
Wie bereits erwahnt, arbeiten in verteilten Systemen mehrere Prozesse mit dengleichen Ressourcen. Dies fuhrt dazu, dass ausgehandelt werden muss, welcherProzess wann auf die entsprechende Ressource zugreifen darf. Geschieht dies nicht,so kann es zu Inkonsistenzen fuhren oder im schlimmsten Fall zur Beschadigung derRessource. Um dies zu verhindern, wird zeitgleich immer nur einem Prozess das ex-klusive Zugriffsrecht zugesprochen. Im Folgenden werden verschieden Algorithmenvorgestellt und dargestellt, wie diese umgesetzt werden konnen.
10.3.1 Ein zentralisierter Algorithmus
Eine einfache Moglichkeit einen gegenseitigen Ausschluss zu erreichen, ist dassimulieren eines Einprozessorsystems. Mit Hilfe eines Prozesses, der zum Koordi-nator bestimmt wird, lasst sich dies Umsetzen. Will ein Prozess den Zugriff aufeine Ressource, so muss er dies beim Koordinator beantragen. Sollte kein andererProzess auf die Ressource zugreifen, so wird der Zugriff erlaubt. In dem, dass einanderer Prozess bereits auf die Ressource zugreift, wird dem anfordernden Prozess,je nach Implementierung, eine Besetztnachricht ubermittelt. Anschließend nimmtder Koordinator die Anfrage in seine Warteschlange auf. Sobald die Ressourcefreigegeben wird, arbeitet der Koordinator die Warteschlange ab und der Prozesserhalt den Zugriff. In der Nachfolgenden Abbildung wird veranschaulicht, wie derZugriff erfolgt.
Abbildung 10.3: Ein zentralisierter Algorithmus
In Abbildung 10.3(a) fordert der Prozess 1 vom Koordinator den Zugriff auf eine
114 10 Synchronisation in verteilten Systemen
Ressource an. Da kein anderer Prozess auf die Ressource zugreift, wird die Anfragegenehmigt und ein OK gesendet. In Abbildung 10.3(b) fordert nun Prozess 2den Zugriff auf die gleiche Ressource an. Jedoch ist Prozess 1 noch nicht mitder Bearbeitung fertig. Der Koordinator signalisiert, dass die Ressource belegtist, und nimmt die Anfrage in die Warteschlange auf. Nun wird in Abbildung10.3(c) die Bearbeitung durch 1 abgeschlossen und die Ressource freigegeben. DerKoordinator registriert die und arbeitet die Warteschlange ab. Somit bekommtnun Prozess 2 das OK zur Bearbeitung.
10.3.2 Ein verteilter Algorithmus
Ein verteilter Algorithmus kann verschieden aufgebaut sein. Er unterscheidet sichim Gegensatz zu einem zentralisierten Algorithmus allerdings dahin gehend, dasses keinen einzelnen Koordinator mehr gibt. Dafur ist es jedoch notwendig, dassalle Teilnehmer an diesem Verfahren eine gemeinsame logische Zeit besitzen. DerAnsatz den Lamport vorschlagt, lasst sich hierbei einbringen und die Nutzungvon Zeitstempel bildet die Grundlage fur den gegenseitigen Ausschluss. An dieserStelle soll kurz auf die Funktionsweise des Algorithmus eingegangen werden. Willein Prozess auf eine Ressource zugreifen, so sendet er seine Prozessnummer, denNamen der Ressource und die logische Zeit an alle Prozesse innerhalb des verteiltenSystems. Ein Prozess, der eine solche Nachricht erhalt, kann unterschiedlichreagieren.
Greift der Empfanger der Nachricht nicht auf die gewunschte Ressource zuund hat dies auch nicht vor, so sendet er eine OK-Nachricht an den Absenderzuruck.
Wenn der Empfanger jedoch bereits auf die Ressource zugreift, so antworteter einfach nicht, oder sendete, je nach Implementierung, eine Besetztnachrichtzuruck und nimmt die Anfrage in seine Warteschlange auf. Nach Beendigungdes Zugriffs arbeitet er diese ab und sendet die OK-Nachricht an den Absender.
Mochte der Empfanger jedoch auch auf die Ressource zugreifen, hat diesaber noch nicht getan, vergleicht er seinen gesendeten Zeitstempel mit demEingegangenen. Dabei gewinnt der Prozess, der den niedrigeren Zeitstempelbesitzt. Sollte dies der Absender sein, so sendet der Empfanger die OK-Nachricht. Besitzt der Empfanger den niedrigeren Zeitstempel, so greift er aufdie Ressource zu und stellt die Anfrage in die Warteschlange ein.
Die Abbildung 10.4 soll an einem Beispiel verdeutlichen, wie der Algorithmusarbeitet. In (a) wollen sowohl Prozess 0 als auch Prozess 2 auf die gleiche Res-source zugreifen. Dabei besitzt Prozess 0 den Zeitstempel 8 und Prozess 2 den
10.3 Gegenseitiger Ausschluss 115
Abbildung 10.4: Ein verteilter Algorithmus
Zeitstempel 12. Nachdem beide Prozesse die jeweiligen Zeitstempel mit ihreneigenen verglichen haben, sendet Prozess 2 die OK-Nachricht an Prozess 0, wie in(b) abgebildet. Nachdem in (c) Prozess 0 mit der Bearbeitung fertig ist, arbeiteter seine Warteschlange ab und sendet die OK-Nachricht an Prozess 2.
10.3.3 Ein Token-Ring-Algorithmus
Einen vollkommen anderen Ansatz um den gegenseitigen Ausschluss in verteiltenSystemen zu erreichen ist der Token-Ring-Algorithmus. Um den Token im Ringkreisen zu lassen, ist als erster Schritt die Ordnung der Prozesse notwendig. Dafurreicht es aus, den jeweiligen Prozessen eine Position zuzuordnen, die beispielsweiseanhand der Netzwerkadresse und weiteren Kriterien ermittelt werden kann. Hatjeder Prozess eine entsprechende Nummer erhalten, kann der Ring initialisiertwerden und Prozess 0 erhalt den Token. Fur die jeweiligen Prozesse ist es nichtnotwendig die gesamte Ordnung zu kennen. Allerdings mussen sie ihren Nachfolgerkennen um den Token weiterzugeben.
Erhalt ein Prozess den Token, so uberpruft er, ob er Zugriff auf die Res-source haben will. Ist dies nicht der Fall, gibt er den Token an den nachstenProzess weiter. Um einen verlorenen Token entgegenzuwirken, empfiehlt es sich,dass jeder Prozess der den Token erhalt eine Empfangsbestatigung ubermittelt.Sollte ein Prozess absturzen, so ist er aus dem Ring zu entfernen und der Tokenwird an den nachsten Prozess weitergegeben. Da kein Prozess doppelt auf dieRessource zugreifen kann, ohne das alle anderen Prozesse die Gelegenheit dazubekommen haben, bleibt die Fairness gewahrt. Der Aufbau eines moglichen Ringesist in Abbildung 10.5 dargestellt.
In Fall (a) wird eine Reihe von Prozessen ohne Ordnung innerhalb eines Netzwer-kes dargestellt. Nachdem jeden Prozess eine entsprechende Nummer zugeordnet
116 10 Synchronisation in verteilten Systemen
Abbildung 10.5: Ein Token-Ring-Algorithmus
wurde, kann in (b) der logische Ring mittels einer Software initialisiert werden.Anschließend erhalt Prozess 0 den Token und pruft ob er Zugriff benotigt. Solltedies geschehen verweilt der Token solange bei ihm, bis er die Ressource freigibtund den Token an seinen Nachfolger sendet.
10.4 Wahlalgorithmen
Damit der Großteil der bisher vorgestellten Algorithmen funktioniert, ist es not-wendig, dass ein Prozess eine Sonderaufgabe ubernimmt. Dieser fungiert dadurchals Initiator, Koordinator oder in einer sonstigen Sonderrolle. Es spielt in der Regelkeine Rolle welcher Prozess diese Aufgabe ubernimmt, jedoch muss es ein Prozesstun. Um die Prozesse dennoch voneinander unterscheiden zu konnen, ist es not-wendig, dass alle Prozesse eine eindeutige Nummer zugeordnet bekommen. Einemogliche Vorgehensweise anhand der Netzwerknummer wurde bereits beschrieben.Im weiteren Verlauf dieses Kapitels wird auf zwei verschiedene Wahlalgorithmeneingegangen, wie ein Prozess zum Koordinator, Initiator oder als Inhaber einersonstige Sonderrolle bestimmt werden kann.
10.4.1 Der Bully-Algorithmus
Eine Moglichkeit wie eine Wahl abgehalten werden kann, verdeutlicht der vonGarcia-Molina entwickelte Bully-Algorithmus. Wenn ein Prozess festgestellt hat,dass der Koordinator nicht mehr auf Anfragen antwortet, kann der Algorithmusfolgender Maßen beschrieben werden:
Der Prozess der den Absturz des Koordinators bemerkt, sendet an alle Prozessemit einer hoheren Nummer eine WAHL-Nachricht.
10.4 Wahlalgorithmen 117
Antwortet keiner dieser Prozesse, ubernimmt der Absender der Nachricht dieAufgaben des Koordinators und teilt dies allen anderen Prozessen mit.
Sollte ein Prozess mit einer hoheren Nummer antworten, ist die Aufgabe furden initiierenden Prozess beendet. Der hohere Prozess wickelt die weitere Wahlab.
Grundsatzlich kann jeder Prozess immer eine WAHL-Nachricht von einem niedrige-ren Prozess erhalten. Umgekehrt ist dies jedoch nicht moglich. Um zu signalisieren,dass ein Prozess die entsprechende Nachricht erhalten hat, sendet er eine OK-Nachricht an den Absender zuruck. Anschließend wird, wie bereits beschrieben,eine neue Wahl abgehalten. Dieses Verhalten setzt sich solange fort, bis nur nochein Prozess ubrig bleibt und somit zum neuen Koordinator wird. Eine entsprechendeNachricht daruber wird an alle Prozesse versendet. Kehrt ein abgesturzter Prozesswieder zuruck, halt dieser eine neue Wahl ab. Hat er die hochste Prozessnummer,so wird er gewinnen und alle andern Prozess wieder unterwerfen. In Abbildung10.6 wird der Bully-Algorithmus an einem Beispiel veranschaulicht.
Abbildung 10.6: Der Bully-Algorithmus
Es ist davon auszugehen, dass in Abbildung 10.6(a) der ehemalige Koordinatormit der Prozessnummer 7 abgesturzt ist und Prozess 4 dies als erster bemerkt. Erbeginnt eine Wahl abzuhalten und sendet die WAHL-Nachricht an die Prozesse 5,6 und 7. Die Prozesse 5 und 6 senden jeweils eine OK-Nachricht als Bestatigung,wie in (b) zu sehen ist. Abbildung 10.6(c) veranschaulicht wie die Prozesse separateine neue Wahl einleiten und an die hoheren Prozesse herantreten. Da jedoch nur
118 10 Synchronisation in verteilten Systemen
Prozess eine OK-Nachricht senden kann, ist die Wahl somit in (d) beendet undProzess 6 wird zum Koordinator. Anschließend teilt er dies an alle existierendenProzesse mit, was aus Abbildung 10.6(e) zu entnehmen ist.
10.4.2 Ein Ringalgorithmus
Eine weitere Moglichkeit einen Wahlalgorithmus zu implementieren ist der Ringal-gorithmus. Dieser arbeitet im Gegensatz zu anderen Ringalgorithmen jedochohne einen Token. Damit ein Ringalgorithmus funktioniert, mussen alle Prozessephysisch oder logisch in einem Ring angeordnet werden und ihren Nachfolgerkennen. Sollte ein Prozess feststellen, dass der Koordinator abgesturzt ist, erstellter eine WAHL-Nachricht. Diese Nachricht enthalt seine eigene Prozessnummerund wird an den Nachfolger gesendet. Trifft die WAHL-Nachricht ein, erganztder aktuelle Prozess seine Nummer und sendet die Nachricht anschließend anseinen Nachfolger. Wenn zwischendurch ein Prozess nicht mehr existent ist, sowird er einfach ubersprungen. Der Vorgang wird so lange wiederholt, bis dieWAHL-Nachricht wieder beim ursprunglichen Absender ankommt. Dies wird ander eigenen Prozessnummer erkannt, die bereits in der Nachricht enthalten ist.Der Prozess mit der hochsten Nummer innerhalb der WAHL-Nachricht wird nunzum neuen Koordinator ernannt. Der Initiator der Wahl teilt dies allen Prozessenmittels einer KOORDINATOR-Nachricht mit. Ist diese Nachricht einmal im Ringumhergegangen, wird sie schließlich entfernt und der Vorgang ist abgeschlossen.Am nachfolgenden Beispiel wird der Algorithmus veranschaulicht.
Abbildung 10.7: Ein Ringalgorithmus
In Abbildung 10.7 stellen die Prozesse 2 und 5 gleichzeitig fest, dass der Koordinatormit der Prozessnummer 7 abgesturzt ist. Unabhangig voneinander initialisieren
10.5 Fazit 119
beide Prozesse eine Wahl und geben die WAHL-Nachricht in den Ring. Sobalddie Nachricht wieder bei den jeweiligen Absendern angelangt ist, stellen dieseunabhangig voneinander fest, dass Prozess 6 der neue Koordinator wird. Mit derabschließenden KOORDINATOR-Nachricht wird dies allen Prozessen mitgeteilt.Dass zwei WAHL- bzw. KOORDINATOR-Nachrichten kreisen, wird dabei nichtals Fehler angesehen. Im schlimmsten Fall kostet dies nur etwas mehr Ressourcen.
10.5 Fazit
Die Synchronisation ist ein wichtiger Baustein beim Erstellen und Nutzen vonverteilten Systemen. Dabei kommen verschiedenste Algorithmen zum Einsatz, umgegenseitigen Ausschluss zu erreichen und die Konsistenz von Netzwerken zuerhalten. Die erwahnten Algorithmen stellen dabei jedoch nur eine eingeschrankteAuswahl dar, um den Leser in die Thematik der Synchronisation in verteilteSysteme einzufuhren und zu sensibilisieren. Durch das Thema Cloud-Computingund der sich daraus ergebenden Moglichkeit Anwendungen in immer großereverteilte Systeme zu unterteilen, wird die Notwendigkeit von Synchronisationenauch aktuell verdeutlicht.
