Verteilte Systeme

Oliver BRAUN (Hrsg.)

Fakultt Informatik a Fachhochschule Schmalkalden Sommersemester 2012

Inhaltsverzeichnis
1 Akka 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Christoph Schmidt 2 Cloud Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Christian Linde 3 Go 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Robert Worgul 4 GridGain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Danny Rubner 5 Jini - Java Intelligent Network Interface . . . . . . . . . . . . . . Tim Achtert 6 ownCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fabian Markert 7 Orc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stephan Stenzel 8 Scala STM vs. Akka STM . . . . . . . . . . . . . . . . . . . . . . Marco Wilhelm 9 Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marie-Christin Reusche 1

15

25

37

53

63

77

85

95

10 Synchronisation in verteilten Systemen . . . . . . . . . . . . . . . 107 Ricardo Volkert

IV

Inhaltsverzeichnis

Akka 2.0
1.1 1.2 Einleitung . . . . . . . . . . . . . . . . . . . Grundlagen . . . . . . . . . . . . . . . . . . 1.2.1 Actor System . . . . . . . . . . . . . 1.2.2 Supervision und Monitoring . . . . . 1.2.3 Actors identizieren und lokalisieren Actors auf einen Blick . . . . . . . . . . . . 1.3.1 Denition eines Actors . . . . . . . . 1.3.2 Instanziieren eines Actors . . . . . . 1.3.3 Nachrichten versenden . . . . . . . . Remote Kommunikation . . . . . . . . . . . 1.4.1 Remote Konguration . . . . . . . . 1.4.2 Der Echo Service . . . . . . . . . . . 1.4.3 Der Echo Client . . . . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 3 4 5 5 6 7 9 9 11 12 13

Christoph Schmidt

Inhaltsverzeichnis

1.3

1.4

1.5

1.1

Einleitung

Akka ist nicht nur ein Bergmassiv in Lappland. Hinter den Buchstaben verbirgt sich ein Open-Source-Projekt das von Jonas Bon`r gegrndet wurde. Dabei e u handelt es sich um ein Framework, welches sich die Entwicklung von nebenlugen, a fehlertoleranten und skalierbaren Applikationen bzw. Verteilten Systemen auf die Fahnen geschrieben hat. Im Kern des Frameworks steht das Actor Model, ein mathematisches Konzept fr u die nebenluge Berechnung, welches 1973 von Carl Hewitt verentlicht wurde a o [1]. Diesem Konzept folgt beispielsweise auch die Programmiersprache Erlang 1 . Akka 1.0 nal wurde im Februar 2011 verentlicht [2]. Zu dieser Zeit stand o hinter Akka die schwedische Firma Scalable Solutions, welche neben professioneller
1

Weiterfhrende Informationen zu Erlang sind unter http://www.erlang.org (23.04.2012) zu u nden.

1 Akka 2.0

Beratung auch verschiedene kostenpichtige Module fr Akka bereitstellte. Bereits u im gleichen Jahr vernderte sich allerdings die Situation. Martin Odersky, welcher a als Vater der Sprache Scala gilt, grndete mit den fhrenden Scala-Kpfen die Firma u u o Typesafe, um die Sprache Scala im Markt zu etablieren. Auch Scalable Solutions verschmolz mit Typesafe [4]. Seit dieser Zeit ist Akka ein fester Bestandteil des Typesafe Stack. Akka hat sich kontinuierlich weiterentwickelt und mit der Version 2.0, welche am 6. Mai 2012 verentlicht wurde einiges an Neuerungen erfahren [3]. Derzeit ist o Akka in der Version 2.0.2 verfgbar. u Diese Ausarbeitung geht auf einige der wichtigsten Neuerungen ein und vergleicht diese an einigen Stellen mit der alten Version. Es wird dabei ein Grundverstndnis a fr Akka, dessen Actor Konzept und Scala vorausgesetzt, da sich die gezeigten u Beispiele im wesentlichen auf die Scala API beziehen.

1.2

Grundlagen

Mit der Verentlichung von Akka 2.0 sind einige Begrie in den Vordergrund o gerckt die bis dato zwar bereits im Sprachgebrauch rund um Akka eingesetzt u wurden, mit der neuen Version jedoch eine strkere Gewichtung erfahren. Aus a diesem Grund werden diese anschlieend nher erlutert. a a

1.2.1

Actor System

Actors sind Objekte mit eingekapseltem Zustand und Verhalten. Sie kommunizieren ausschlielich uber den Austausch von Nachrichten. Diese werden in der Mailbox des Empfngers gespeichert und nach einer gewissen Verweildauer abgearbeitet. Der a Begri des Actor Systems lsst sich mit einer Analogie beschreiben. Firmen weisen a hug hierarchische Strukturen auf. Dies lsst sich auch auf ein Actor System a a ubertragen. Die zu bewltigenden Aufgaben werden von einer ubergeordneten a Organisationseinheit, einem Actor, in Teilaufgaben zerlegt und an untergeordnete Organisationseinheiten weitergegeben. Daraus folgt, dass jede untergeordnete Einheit, also die einzelnen Actors, nur winzige Teilaufgaben erledigen mssen. u Hierarchische Strukturen Nun ergibt sich die Frage, wie die einzelnen Aufgaben koordiniert bzw. uberwacht werden. In Akka 2.0 etablierte sich der Begri des Actor System fest in die Syntax des Frameworks, wie in Kapitel 1.3 zu sehen. Es ist somit nicht mehr notwendig, eigene Supervisor zu denieren, da jetzt jeder Actor fr die Uberwachung seiner u Kinder verantwortlich ist. Die Einfhrung des Actor Systems hat auch zur Folge, u

1.2 Grundlagen

dass die in Akka 1.x eingesetzte ActorRegistry uberssig wird und daher u komplett entfernt wurde. Um leistungsstarke Actor Systeme entwickeln zu knnen, gibt die Dokumentation o einige Richtlinien vor, welche im Anschlu nher ausgefhrt werden: a u Wenn ein Actor einen oder mehrere Worker-Actors steuert, sollte dieser die Uberwachung der Worker (Kinder) ubernehmen, da die Fehlerbehandlung an ubergeordneter Stelle ezienter koordiniert und umgesetzt werden kann. Wenn ein Actor sensible Daten beinhaltet, sollte dieser alle kritischen Aufgaben an untergeordnete Worker auslagern. Hierbei ist es hug das Beste, fr jede a u Anfrage einen neuen Worker zu erzeugen. Wenn die Aufgabenerfllung eines Actors von einem anderen Actor abhngig ist, u a sollte dieser den Lebenszyklus des anderen uberwachen, um auf das Eingehen einer Terminierungsnachricht adquat reagieren zu knnen. a o

1.2.2

Supervision und Monitoring

Eine der wichtigsten Aufgabe in einem Actor System ist das Behandeln bzw. das Beheben von Fehlern. Akka unterscheidet zwischen Supervision und Monitoring. Die Unterschiede dieser Techniken werden im Anschluss ausgefhrt. u Supervision Supervision beschreibt die Mglichkeit, Fehlersituationen innerhalb eines Actor o Systems aufzulsen. Diese Aufgabe wird immer vom Eltern-Actor durchgefhrt. o u Dabei ergeben sich folgende Mglichkeiten: o Fortsetzen der untergeordneten Instanz mit aktuellem internen Zustand. Neustarten der untergeordneten Instanz durch Bereinigung des internen Zustandes. Dauerhaftes Beenden der untergeordneten Instanz. Fehler an ubergeordnete Instanz weiterreichen. Akka unterscheidet zwischen One-For-One und All-For-One-Strategie, um Supervision umzusetzen. One-For-One bedeutet, dass im Falle eines Fehlers nur der betroene Actor neu gestartet wird. Bei All-For-One-Strategie werden hingegen alle Kinder eines Supervisors neu gestartet. Standardmig arbeitet Akka mit a One-For-One-Strategie.

1 Akka 2.0

Monitoring Im Gegensatz zum Supervision-Konzept darf beim Monitoring jeder beliebige Actor einen anderen Actor uberwachen. Der Unterschied besteht allerdings darin, dass nur Zustandsnderungen von alive zu dead sichtbar werden. a Gerade im Bereich Supervision und Monitoring unterscheidet sich Akka 2.0 von dessen Vorgngerversionen. In Akka 1.3.1 mussten beispielsweise explizit a Supervisor mit Hilfe des Supervisor-Factory-Objekts angelegt werden [5]. Mit der Bestimmung, dass jeder Actor fr seine Nachkommen verantwortlich ist, wurde u dieses Konzept deutlich verschrft. a

1.2.3

Actors identizieren und lokalisieren

In diesem Abschnitt wird beschrieben wie Actors in einem verteilen Actor System identiziert und lokalisiert werden knnen. Abbildung 1.1 stellt dabei die wesento lichen Begrie in ihrer Beziehung zueinander dar. Die wichtigsten Bestandteile werden im Anschluss nher erlutert. a a
Abbildung 1.1: Actor System2

Abbildung in Anlehnung an [6].

1.3 Actors auf einen Blick

Actor Reference Eine Actor Reference ist eine Referenz auf einen konkreten Actor. Jeder Actor kann uber das Feld self auf seine lokale Referenz zugreifen. Uber das Feld sender hat er auerdem Zugri auf die Referenz des Senders der aktuell zu bearbeitenden Nachricht. Actor Path Da nun Actors strikt hierarchisch erzeugt werden, existiert eine baumartige Struktur von Actors. Durch diese Struktur kann hnlich wie in einem Datei-System der a Weg zu einem bestimmten Actor beschrieben werden. Jeder Actor Path besteht aus einem Anker, welcher das Actor System identiziert. Diesem schliet sich eine Verkettung von Elementen an, die von der Wurzel des Systems bis hin zum vorgesehenen Actor fhrt, wie in Listing 1.1 gezeigt. u
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 Aufruf context.ActorFor(<Actor Path>) ein entsprechender Actor angesprochen werden.

1.3

Actors auf einen Blick

Dieses Kapitel beantwortet die wichtigsten syntaktischen Fragen, um mittels Akka leistungsstarke Anwendungen realisieren zu knnen. Es geht auf Actors und o dessen Kommunikationskonzepte ein und beleuchtet anschaulich die wichtigsten Vorgehensweisen.

1.3.1

Denition eines Actors

Um eine Klasse mit der Funktionalitt eines Actors anzulegen, sind lediglich zwei a Schritte notwendig. Zu Beginn wird eine Klasse um den Actor-Trait erweitert. Anschlieen wird die receive-Methode implementiert. Bis zu diesem Punkt unterscheidet sich Akka 2.0 nicht von seinen Vorgngerversionen. a Listing 1.2 zeigt einen HelloActor und dessen receive-Methode. Darber hinaus u lsst sich erkennen, dass dieser lediglich auf Hello-Nachrichten mit der Ausgabe a

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 Frage oen, 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 notwendig ein ActorSystem4 zu erzeugen. Anschlieend wird mit dem Aufruf system.actorOf(...) ein Actor erzeugt. Diese Methode bekommt als zweites Argument den Name des Actors und als erstes Argument ein Objekt der Klasse Props ubergeben, welches mit einem Actor, in diesem Fall mit einem HelloActor parametrisiert wird. Natrlich ist es mit der Props-Klasse auch mglich Actors mit Nichtu o Standard-Konstruktor 5 zu erzeugen. Sie ist allerdings weitaus vielseitiger, da mit ihr beispielsweise auch Router realisiert werden knne, wie Listing 1.4 zeigt. In o
3 4

Siehe Listing 1.2. Der Begri des Actor Systems wurde bereits in Kapitel 1.1 eingefhrt. u 5 Statt Props[HelloActor] kann auch Props(new HelloActor()) genutzt werden.

1.3 Actors auf einen Blick

diesem wird ein Router mit fnf Instanzen des HelloActors erzeugt. Der Router u arbeitet 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 Stelle leicht variiert vorgegangen werden. Listing 1.5 soll dies illustrieren. Es wird nun context.actorOf(...) zum Erzeugen genutzt. Hinter dem context verbirgt sich die Sicht auf eine ActorCell welche Informationen wie die Actor Referenzen der 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 Vorgngerversionen grundstzlich a a zwei Arten, um Nachrichten an Actors zu senden. Dabei handelt es sich um Fire-forget und Send-And-Receive-Future. Bei der erstgenannten Variante wird einem Actor mit Hilfe der !-Methode eine Nachricht ubermittelt. Hierbei erwartet der Sender nicht wie bei Send-And-Receive-Future eine Rckantwort. Da bei u der Variante Fire-forget 6 keine Anderungen mit dem Versionssprung auf 2.0 vorgenommen wurden, wird dies hier nicht weiter ausgefhrt. u Send-And-Receive-Future Bei dieser Variante wird eine Nachricht asynchron versendet. Als Ergebnis erhlt a der Sender ein Future7 , was ein mgliches Ergebnis reprsentiert. An dieser o a Stelle unterscheidet sich Akka 2.0 syntaktisch von der Version 1.3.1, was mit den nachfolgenden Listings illustriert werden soll.
6 7

In Listing 1.12 ist ein Beispiel zu Fire-forget zusehen. Siehe hierzu [7].

8 Listing 1.6: Send-And-Receive ohne Future mit Akka 1.3.1

1 Akka 2.0

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, welcher von diesem unverndert zurckgesendet werden soll. Bei beiden Beispielen wird a u explizit auf das Ergebnis gewartet, weshalb ein Timeout von 10 Sekunden gesetzt wurde. 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 Ergebnis direkt bentigt wird. Hug ist ein solches Future aber nur Teil einer komplexen o a Berechnung, welche von mehreren Futures abhngig ist. Um an dieser Stelle nicht a zu blockieren bietet Akka 2.0 die Methode mapTo. Mit dieser ist es mglich die o Berechnung bereits auf Basis der Futures durchzufhren. Das Ergebnis kann dann u nach Vollendung aller beteiligter Futures zu einem spteren Zeitpunkt abgerufen a werden. 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

} yield a + b

1.4

Remote Kommunikation

Das vorangegangene Kapitel hat den Grundstein fr das Arbeiten mit Actors gelegt. u Auf diesem aufbauend soll nun gezeigt werden, wie Actors uber Rechnergrenzen hinweg kommunizieren knnen. o Um dies zu illustrieren wird schrittweise eine Client-Server-Anwendung 8 entwickelt. Die Idee der Anwendung besteht darin, dass ein Client eine Zeichenkette uber ein Netzwerk an einen Echo-Service sendet. Dieser empfngt die Nachricht, dreht a diese um und schickt sie an den Sender zurck. u

1.4.1

Remote Konguration

In Akka 2.0 gibt es keine gesonderte Syntax um remote Kommunikation zu realisieren. Alle Schritte laufen analog ab, als wrde ein lokales System umgesetzt werden. u Die Funktionalitt die ein Actor System bentigt um uber Rechnergrenzen hinweg a o zu kommunizieren wird lediglich durch eine entsprechende Konguration hinzugefgt. Um dies zu ermglichen wird im ersten Schritt das Module akka-remote u o in ein Projekt integriert.
Listing 1.9: SBT Konguration

l i br a r yD e p en d e nc i e s + = " com . typesafe . akka " % " akka - actor " % " 2.0.1 " l i br a r yD e p en d e nc i e s + = " com . typesafe . akka " % " akka - remote " % " 2.0.1 " l i br a r yD e p en d e nc i e s + = " 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 Starten eines Application Server ermglicht. o Remote Ressourcen freischalten Die eigentliche Remote-Funktionalitt wird in der Datei application.conf a hinzugefgt. Hier mssen mindestens drei Einstellungen vorgenommen werden: u u

Der Quellcode kann auf Github heruntergeladen werden[8].

10

1 Akka 2.0

Der Wert provider wird auf akka.remote.RemoteActorRefProvider gesetzt. Es wird ein Host-Name eingetragen unter welchem das Actor System erreicht werden kann. Auerdem ist ein entsprechender Port zu vergeben. Da die Beispielanwendung eine Konguration fr Client und Server bentigt, u o wurde die Konguration auf die Dateien common.conf und application.conf aufgeteilt.
Listing 1.10: Die Datei common.conf

akka { actor { provider = " akka . remote . R e m o t e A c t o r R e f P r o v i d e r " } remote { netty { hostname = " 127.0.0.1 " } } } Listing 1.10 zeigt die Basis-Konguration, die Client und Server gemeinsam haben. In Listing 1.11 ist dann die spezische Konguration der beiden Actor Systeme zu sehen.
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 Konguration wird nun vermittelt, wie ein remote basiertes Actor System implementiert werden kann. Dies geschieht wieder an Hand der genannten Anwendung. Im ersten Schritt wird ein EchoActor implementiert, der auf das Eintreen einer Zeichenkette reagiert, diese umdreht und an den Sender zurckschickt, wie in Listing 1.12 zu sehen. u
Listing 1.12: Der Echo Actor

class EchoActor extends Actor { def receive = { case msg : String = > println ( " > " + msg ) sender ! msg . reverse case _ = > } } Anschlieend folgt die Entwicklung des Actor Systems. Hierzu wird eine Klasse EchoApplication angelegt, welche um den Trait Bootable aus dem akka-kernel Modul erweitert wird. Nachdem die Rahmenbedingungen fr das u System geschaen wurden, erhlt dieses den Namen EchoApp und wird mit a der zuvor erstellen Konguration parametrisiert. Auerdem wird eine Instanz des EchoActors erzeugt um auf Nachrichten reagieren zu knne, was Listing 1.13 o zeigt.
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 " ) ... } Abschieend wird ein ausfhrbares Objekt mit dem Namen EchoApp angelegt, u um ein lauhiges Programm zu erzeugen. Hier wird lediglich ein Objekt der a Klasse EchoApplication erzeugt, welches die Funktionalitt des Actor Systems a widerspiegelt, wie in Listing 1.14 zu sehen.

12 Listing 1.14: Das EchoApp Object

1 Akka 2.0

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 fr die Realisierung des Client sind analog u zu denen des Servers zu sehen. Der Hauptunterschied besteht jedoch darin, dass der Client eine Information bentigt, wie er mit dem Server kommunizieren kann. o Dies geschieht wie in Akka 2.0 ublich dadurch, dass im Actor System des Client mit Hilfe der Methode actorFor unter Angabe des Actor Path eine Referenz auf den entfernten EchoActor angelegt wird. Dies ist In Listing 1.15 dargestellt. Uber die Methode sendMsg knnen dann Nachrichten an den Echo Service gesendet o werden.
Listing 1.15: Die Echo Client Application

class E c h o C l i e n t A p p l i c a t i o n extends Bootable { val system = ActorSystem ( " EchoClientApp " , ConfigFactory . load . getConfig ( " echoclient " ) ) val actor = system . actorOf ( Props [ EchoClientActor ] , " echo - client - actor " ) val remoteActor = system . actorFor ( " akka : // EchoApp @ 127.0.0.1 : 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 Vorgngerversion sehr gut fr die a u Entwicklung von nebenlugen Programmen bzw. Verteilten Systemen. Durch das a eingesetzte Actor-Konzept ist es auf elegante Weise mglich leistungsstarke Ano wendungen zu realisieren. Dies haben auch zahlreiche Entwickler fr sich entdeckt. u Es ist eine Community entstanden, die Neueinsteigern tatkrftige Untersttzung a u bietet. Darber hinaus ist es gelungen Akka kontinuierlich weiterzuentwickeln und u an neue Aufgaben anzupassen, was letztlich auf Jonas Bon`r zurckzufhren ist, e u u da dieser in regelmigen Abstnden entliche Diskussionen anregt, um das a a o Framework stetig zu verbessern. Daher wird Akka auch in Zukunft nichts an seiner Strke verlieren. a

Literaturverzeichnis
[1] Carl Hewitt and Peter Bishop and Richard Steiger, A Universal Modular Actor Formalism for Articial Intelligence. IJCAI, 1973. [2] Jonas Bonr, Akka 1.0 nal is relesead. http://groups.google.com/group/akkae user/browse thread/thread/c9a055d6f7d1b4d4, 23.04.2012. [3] Viktor Klang, Akka 2.0 Released. http://akka.io/news/2012/03/06/akka-20released.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 http://doc.akka.io/docs/akka/1.3.1/Akka.pdf, 30.04.2012. 1.3.1.

[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

Cloud Haskell
2.1 2.2 Einleitung . . . . . . . . . . . . . . . . . . Prozesse . . . . . . . . . . . . . . . . . . . 2.2.1 Prozesskommunikation . . . . . . . 2.2.2 Serialisierbarkeit . . . . . . . . . . 2.2.3 Starten und Finden von Prozessen 2.2.4 Fehlertoleranz . . . . . . . . . . . Messages . . . . . . . . . . . . . . . . . . Closures . . . . . . . . . . . . . . . . . . . 2.4.1 Statische Werte . . . . . . . . . . 2.4.2 Entserialisierung einer Closure . . . Beispiele . . . . . . . . . . . . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 16 16 17 17 18 19 19 20 21 21 24

Christian Linde

Inhaltsverzeichnis

2.3 2.4

2.5 2.6

2.1

Einleitung

Cloud Haskell ist ein Framework. Es befasst sich mit der Entwicklung von Verteilten Systemen in der Programmiersprache Haskell. Dieser Ausarbeitung liegt die Verentlichung des Artikels Towards Haskell in the Cloud 1 zu Grunde. o Ziel dieser Ausarbeitung soll es sein, dem Leser einen Einblick zu geben, ob Haskell zur Entwicklung Verteilter Systeme verwendbar ist und wie eine Umsetzung aussehen knnte. o In Verteilten Systemen sind einige wichtige Probleme zu bedenken. Es muss dafr u gesorgt werden, dass Prozesse keine konkurrierenden Zugrie aufeinander haben. Weiterhin muss eine Strategie entwickelt werden, wie mit fehlerhaften Prozessen umzugehen ist. Die Forderung das Prozesse keinen konkurrierenden Zugri haben drfen, ist u vor allem in Hochverfgbarkeitssystemen ein Muss. Das hat in diesem Kontext u
1

[1]

16

2 Cloud Haskell

zur Folge, dass alle Daten die ausgetauscht werden sollen, explizit als Message versendet werden mssen. u Mit dem Begri Cloud ist eine Groe Menge an Prozessoren gemeint, die ihren eigenen Speicher besitzen und uber ein Netzwerk miteinander verbunden sind. Bei Hochverfgbarkeitssystemen ist die Kostenfrage oft nicht auer Acht zu lassen. u Den Groteil der Kosten beansprucht dabei das Verschieben von Daten.

2.2
2.2.1

Prozesse
Prozesskommunikation

Wie in vielzahligen anderen Bereichen tritt Erlang auch hier als Vorbild auf. In Cloud Haskell, wie in Erlang auch, wird die primre Kommunikation zwischen Prozessen a uber message-passing, also das Versenden und Empfangen von Nachrichten realisiert. Hingegen unterscheidet sich die Umsetzung von der in Erlang dahingehend, dass Einzel-Prozesse auch in geteiltem Speicher verwendet werde knnen. o In Haskell existieren Mglichkeiten um o konkurrierende Systeme zu entwickeln, siehe MVar fr verteilte unvernderbare Vau a riablen und forkIO fr lightweight leichtu gewichtige Prozess-Fden (vol. Abbildung a 2.1). Die Entwickler haben sich Gedanken gemacht, ob es sinnvoll ist MVar zu serialisieren. Dabei wurde die Frage aufgeworfen, ob es Sinn macht geteilten Speicher in einem Verteilten System zu simulieren. Dies beantworteten sie mit ja! Sie nden es allerdings nicht sinnvoll MVar zu serialisieren. Leider knnen diese Mechanismen zur Proo blemlsung nicht genutzt werden, da sie o nicht serialisierbar sind und somit nicht geeignet, um uber Netzwerk in einer Nach Abbildung 2.1: Prozess Kommunikation [1] richt versendet zu werden. Alle Zustnde einer Nachricht werden in der ProzessM monade vereinigt. Diese a wird bei jeder Nachrichten-Aktion aktualisiert.

2.2 Prozesse

17

Das bedeutet, dass auch alle an der Kommunikation beteiligten Code-Elemente in die ProzessM monade integriert sind. Cloud Haskell bietet zwei verschiedene Mglichkeiten um Nachrichten aus zu o tauschen. Untypisierte Nachrichten (untyped messages) verhalten sich genau wie in Erlang. Weiterhin gibt es noch den Typ-Kanal (typed channels), welcher an das strenge Typ-System in Haskell angelehnt ist. Es ermglicht, statische Garantien o fr den Inhalt einer Nachricht zu geben. u

2.2.2

Serialisierbarkeit

Serialisierbarkeit bedeutet, dass jedes Element den Serializable Typen implementieren muss. Damit wird sichergestellt, dass die Elemente binr (Binary) und a typisierbar (Typeable) sind.
Listing 2.1: Serializable Beispiele
1 2 3 4

send : : Serializable a = > ProcessId - >a - > ProcessM () match : : Serializable a = >(a - > ProcessM q ) -> MatchM q () -class ( Binary a , Typeable a ) = > Serializable a

Mit der binren Eigenschaft wird die Funktionalitt zum de- und encodieren der a a Daten bereitgestellt. Somit ist eine binre Darstellungsform mglich. a o Durch Typeable wird erreicht, dass mittels der Funktion typeOF eine Typ Referenz produziert werden kann, wodurch der Typ ermittelt werden kann. In Haskell sind alle primitiven Datentypen und die meisten Higher-level Datenstrukturen serialisierbar. Diese knnen also problemlos teil einer Nachricht sein. o Zu beachten ist, dass manche Datentypen ausdrcklich nicht serialisierbar sind, u zum Beispiel: MVar und TVar. Weiterhin knnen Funktionen, welche keine freien Variablen haben einfach o ubertragen werden. Bei der Serialisierung statischer Werte ndet als erstes ei ne Auswertung statt Anschlieend wird die Code-Adresse fr das Ergebnis der u Auswertung 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 er gestartet werden? Naheliegend wre es, eine Maschine im System auszuwhlen, a a welche Rechenkapazitt frei hat. Dafr wird zu erst ein Mechanismus bentigt, a u o der in der Lage ist, in einem Verteilten System eine Maschine zu nden. 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 eigene eindeutige Knoten ID (NodeID). In dieser ID ist die IP-Adresse enthalten, uber die kommuniziert wird. Zum Starten eines Prozesses werden zwei Elemente bentigt. Die NodeID und der o Code der ausgefhrt werden soll. u Um den Code einzubetten, muss er serialisiert werden. Dies wird erreicht, in dem erstens eine Reprsentation des Codes vorhanden sein muss und zweitens die a Reprsentation der Umwelt (environment). a

2.2.4

Fehlertoleranz

Ein zentrales Problem stellt die Fragestellung dar, wie mit fehlerhaften Prozessen umgegangen 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 luft, dann a ist die beste Lsung ihn zu beenden. Es wird davon ausgegangen, dass durch das o Versiegeln nie wieder die gleiche Sicherheit wie zuvor erreicht werden kann. Das bedeutet also, dass der Prozess neu gestartet werden muss. Ein Neustart kann jedoch nur durchgefhrt werden, wenn es einen Prozess gibt, der den zu u beendenden Prozess uberwacht. Dieser uberwachende Prozess muss beim Beenden benachrichtigt werden, damit er mgliche Schritte einleiten oder Entscheidungen o treen kann. Hierbei muss eine Behandlung von Terminierungen erfolgen. Es gibt die Mglichkeiten, das Haskell Exzeption handling zu bemhen oder per Nachrichten o u zu ubermitteln. Die Nachrichten werden dann wie jede andere Nachricht auch empfangen.

2.3 Messages

19

2.3

Messages

In Haskell werden die Daten nicht uber geteilten Speicher ausgetauscht, sondern uber Messages. Dies stellt sich als eine sehr gute Strategie fr Verteilte Systeme u dar.2 Probleme treten dann auf, wenn eine Nachricht verschiedene Typen haben kann. Siehe Erlang Listing 2.2
Listing 2.2: match in Erlang
1 2 3 4 5 6

math () -> receive { add , Pid , Num1 , Num2 } -> Pid ! Num1 + Num2 ; { divide , Pid , Num1 , Num2 } when Num2 = 0 -> Pid ! Num1 / Num2 ; { divide , Pid , _ , _ } Pid ! div by zero end , math () .

Dieses Beispiel beinhaltet zwei verschiedene Nachrichtentypen. Sie werden durch die Atome add und divide reprsentiert. Die Auswahl wird mittels Patternmatching a realisiert. Jedes der Pattern in Zeile zwei bis vier (siehe Listing 2.2), absolviert eine Nachrichtenbehandlung. In Zeile zwei wird durch das Atom add, die Prozess ID sowie zwei Zahlenwerte eine Nachricht ausgelst, die an den Prozess mittels o Prozess ID zwei addierte Zahlen sendet. In Zeile drei wird zustzlich noch eine a Bedingung eingefhrt. Diese prft, ob es sich bei der zweiten Zahl um eine Null u u handelt. Die beiden ubergebenen Zahlen, in Zeile vier sind uninteressant, da es in 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 ihres Gltigkeitsbereich eine Variable x setzt und eine lokale Kind-Funktion deu niert. Beim Aufruf der Mutter-Funktion gibt diese die Kind-Funktion zurck. In u der Aufrufer Umgebung gibt es keine Variable x dagegen kann die gebundene Kind-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 jedem beteiligten Verteilten System adressierbar sein muss. Die Notwendigkeit fr solch u eine 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 Funktion an und sendet sie an einen Channel.
Listing 2.3: sendFunc
1 2 3

-- wrong sendFunc : : SendPort ( Int - > Int ) -> Int - > ProcessM () sendFunc p x = sendChan p ( y -> x + y + 1)

Sie sendet die Closure ( y x + y + 1), in der die freien Variablen in x abgefangen werden. Die Serialisierung einer Closure-Funktion wird erreicht, indem ihre freien Variablen serialisiert werden. Immer dann wenn die Typen der freien Variablen nicht mit den Funtkionswerten verbunden sind, ist unklar wie sie serialisiert werden sollen. Wer sich an dieser Stelle genauer fr das Problem interessiert, sollte den zugrunde liegenden Artikel u und den dazugehrigen Quellcode lesen. o Es muss nun speziziert werden, dass eine Funktion serialisierbar ist. Die Serialisierbarkeit ist keine strukturelle Eigenschaft einer Funktion. Die Darstellung einer Funktion in Haskell ist rein (purely). Das bedeutet alles, was in Haskell mit einer Funktion getan werden kann, ist sie anzuwenden. Es besteht nun das Problem, dass die Funktionen serialisiert werden mssen, da u zum Beispiel spawn die Funktion spezizieren muss, welche auf einem anderen System ausfhren soll. u Die Serialisierung einer Closure-Funktion wird erreicht, indem die freien Variablen serialisiert werden.

2.4.1

Statische Werte

Funktionen, die keine freien Variablen haben, knnen einfach ubertragen werden. o Die Implementierung der Serialisierung statischer Werte ist so realisiert, dass als erstes eine Auswertung stattndet und dann die code Adresse fr das Ergebnis u der Auswertung serialisiert wird. Wie oben schon festgestellt, ist es problematisch eine Closure zu ubertragen, die freie Variablen beinhaltet. Eine Closure beinhaltet einen Code-Pointer und eine Umgebung (enviroment). Hierbei ist zu beachten, dass eine Closure nicht serialisiert werden kann, wenn ihre Umgebung es nicht ist. Durch diese statischen Terme ist es nun mglich eine Reprsentation in Haskell zu erstellen. o a

2.5 Beispiele Listing 2.4: Representation einer Closure

1 2

21

data Closure a where -- Wrong MkClosure : : Static ( env -> a ) -> env -> Closure a

2.4.2

Entserialisierung einer Closure

Nun ist geklrt wie eine Closure zu einem anderen System ubertragen werden a kann. Das Problem, das an dieser Stelle nun besteht, ist dass der Empfnger nicht a wei, welchen Typ die Closure enthlt. a Es bestehen verschiedene Mglichkeiten um nun dem Empfnger diese Informatioo a nen mitzuteilen. Variante eins es wird eine Reprsentation des Umgebungstyps mitgesendet und am a anderen Ende ein run-time type-class lookup gemacht. Also eine Typ Ermittlung zur Laufzeit. Variante zwei wre eine Reprsentation des Deserialisierungstyps selbst mit zu a a senden. Die Lsung ist im Nachhinein eigentlich sehr nahe liegend. Die Serialisierung und o Deserialisierung der Umgebung wird zur Closure Erstellungszeit und nicht zur Closure Serialisierungszeit durchgefhrt. Da die Umgebung den Typ ByteString u hat.

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 2 3 4 5 6 7

main = remoteInit ( Just " config " ) [ Main . _ _ r e m o t e C a l l M e t a D a t a ] initialProce ss -remoteInit : : Maybe FilePath -> [ Re m o t e C a l l M e t a D a t a ] -> ( String -> ProcessM () ) -> IO ()

Die Main Funktion ruft die initialProcess Funktion auf. In dieser Funktion stehen die im Nachgang stehenden Beispiele. Bevor die Beispiele behandelt werden knnen, muss noch etwas vor Arbeit geleistet o werden. Die Funktion remotable generiert automatisch closure Funktionen mit der Namenskonvention: n closure.

22 Listing 2.6: remotable

1

2 Cloud Haskell

remotable [ sayHi , sayHiIO , sayHiPure , sayHiPM , funnyHi , runAnother , simpleSum ]

Dadurch ist es nun mglich, diese Funktionen mit spawn, remoteCall und invokeo Closure zu nutzen.
Listing 2.7: spawn
1

spawn : : NodeId -> Closure ( ProcessM () ) -> ProcessM ProcessId

Nun knnen wir zum ersten Beispiel kommen. o

Listing 2.8: sayHi
1 2 3 4 5

p <- spawn mynid ( sayHi _ _ closure " Zoltan " ) say $ " Got result " ++ show p -sayHi : : String -> ProcessM () sayHi s = say $ " Greetings , " ++ s

In diesem Beispiel wird die Funktion sayHi mit dem Parameter Zoltan, von der spawn Funktion aufgerufen. Die spawn Funktion hlt das Programm nicht an. a
Listing 2.9: sayHiPure
1 2 3 4 5

q <- callRemotePure mynid ( sayHiPure _ _ closure " Spatula " ) say $ " Got result " ++ show q -sayHiPure : : String -> String 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 2 3 4 5 6

v <- callRemote mynid ( sayHiPM _ _ closure " Jaroslav " ) say $ " Got result " ++ v -sayHiPM : : String -> ProcessM String sayHiPM s = say ( " Hello , " ++ s ) >> return ( sort s )

In diesem Beispiel wird die callRemote Funktion verwendet, sie ruft die Funktion sayHiPM mit dem Parameter Jaroslav auf. Im Gegensatz zu der spawn Funktion ist sie synchron und wartet somit, bis das Ergebnis da ist.

2.5 Beispiele Listing 2.11: sayHiIO

1 2 3 4 5 6

23

w <- callRemoteIO mynid ( $ ( mkClosure sayHiIO ) " Noodle " ) say $ " Got result " ++ show w -sayHiIO : : String -> IO String sayHiIO s = putStrLn ( " Hello , " ++ s ) >> return ( reverse s )

Nun wird mittels der callRemoteIO Funktion eine closure aufgerufen, die sich in der IO Monade bendet.
Listing 2.12: simpleSum
1 2 3 4 5

x <- callRemote mynid ( runAnother _ _ closure ( simpleSum _ _ closure 1 1) ) say $ " Got result " ++ x -simpleSum : : Int -> Int -> Int simpleSum a b = a + b + 1

In Beispiel (2.12) wird dargestellt, wie einer closures eine closure ubergeben werden kann. Dies wird erreicht, in dem das Ergebnis der simpleSum closure an die runAnother closure Funktion ubergeben wird und dann mit callRemote an einen Knoten geschickt wird.

24

2 Cloud Haskell

2.6

Fazit

Durch das Cloud Haskell Framework, ist es Haskell Entwicklern nun leichter gemacht wurden Verteilte Anwendungen zu entwickeln. Die Installation des Frameworks verluft bei vorhandener Cabal Umgebung proa blemlos. Den Einarbeitungsaufwand fand ich fr Haskell-Entwickler auch gering, da die u Handhabung nach verstehen des Konzeptes recht Intuitiv ist. Das Framework ist nach meiner Einschtzung auch sehr gut Dokumentiert. a Im Vergleich zu anderen Frameworks die hnliches leisten wie zum Beispiel akka a in Verbindung mit Scala. War die Anwendung sehr vergleichbar. Auch wenn die Konzepte dahinter etwas auseinander gehen. Ich nde die Entwickler nehmen dem Programmierer dadurch viel Arbeit ab, die ihm nur unntig Zeit gekostet htte und erleichtern somit den Entwicklungsaufwand o a von Verteilten Systemen.

Literaturverzeichnis
[1] Je Epstein, Andrew P. Black, Simon Peyton-Jones, Towards Haskell in the Cloud. Remote Tokyo, Japan. 22 September 2011 [2] Je Epstein, Cloud Haskell. https://github.com/jepst/CloudHaskell, (Zugri am 14.06.2012)

Go 1.0
3.1 3.2 Einleitung . . . . . . . . . . . . . . . . . . . . . . Grundlagen . . . . . . . . . . . . . . . . . . . . . 3.2.1 Die Syntax von Go . . . . . . . . . . . . . 3.2.2 Der erweiterte Funktionsumfang . . . . . 3.2.3 Systemnahe Programmierung in Go . . . . 3.2.4 Reduktion auf das Wesentliche . . . . . . Mglichkeiten verteilter Systeme in Go . . . . . . o 3.3.1 Goroutines . . . . . . . . . . . . . . . . . 3.3.2 Channels . . . . . . . . . . . . . . . . . . 3.3.3 Klassische Synchronisierungsmechanismen 3.3.4 Remote Procedure Calls . . . . . . . . . . Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 26 26 28 28 29 30 30 31 33 33 34

Robert Worgul

Inhaltsverzeichnis

3.3

3.4

3.1

Einleitung

Go ist eine junge Programmiersprache, deren Entwicklungsidee auf die heutigen Umstnde der Systemprogrammierung zurckzufhren ist. Die Notwendigkeit der a u u Parallelisierung von Programmablufen steigt mit der stetig wachsenden Anzahl a an Prozessorkernen in modernen Prozessoren. Die Programmiersprachen wie C, welche sich im Bereich der Systemprogrammierung etabliert haben, bieten aufgrund ihres Alters und der damals geltenden Hardwareverhltnisse keine Untersttzung fr die Parallelisierung. Die parallea u u le Programmierung ist somit nur uber fremde Bibliotheken mglich, welche in o Abhngigkeit von dem Betriebssystem, auf dem das Programm ausgefhrt wird, a u implementiert sein mssen. Die Verwendung fremder Bibliotheken hat zur Folu ge, dass sowohl die parallele Programmierung als auch die dadurch notwendige Synchronisierung der parallelisierten Ablufe uneinheitlich, komplex und dadurch a unsicher werden [1]. Am 21. September 2007 skizzierten Robert Griesemer, Rob Pike und Ken Thompson die Hauptziele einer neuen Programmiersprache. Nach zwei Jahren interner

26

3 Go 1.0

Entwicklung wurde Go am 10. November 2009 als oentliches Open Source Projekt herausgegeben. Das Hauptziel von Go ist es, eine neue, maschinennahe Programmiersprache fr die Systemprogrammierung zu entwickeln, welche die u Vorteile moderner Programmiersprachen mit der Sicherheit und Geschwindigkeit einer kompilierten, statisch typisierten Programmiersprache kombiniert [1]. Im Gegensatz zu den gelugen Systemprogrammiersprachen bietet Go die folgena den Vorteile [1]: Das neue Paketsystem verringert aus Sicht der Abhngigkeitsanalyse unsaubea ren Overhead (bspw. von C-Include-Dateien), wodurch selbst das Kompilieren groer Programme auf einem einzelnen Rechner wenige Sekunden dauert. Die Untersttzung von Garbage Collection gewhrleistet eine sichere Speicheru a verwaltung. Go wurde gestaltet, um Systemsoftware auf Rechnern mit mehreren Prozessoren zu entwickeln. Dafr wurden neue Parallelisierungs- und Synchronisierungsu anstze eingebunden. a

3.2

Grundlagen

In diesem Kapitel wird erlutert, was Go von anderen Systemprogrammiersprachen a unterscheidet. Des Weiteren werden daraus folgende syntaktische Eigenheiten begrndet. u

3.2.1

Die Syntax von Go

Die Syntax von Go hnelt der Programmiersprache C mit Einssen von Python a u und diversen anderen. Besonderer Wert wurde auf die Einfachheit der Syntax gelegt. Mit Hilfe des Listings 3.1 wird nun die Syntax von Go nher erlutert. a a
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 fmt.Println("Nope, Chuck Testa!") } }

27

Das Paketsystem ist Teil des, im Vergleich zu C, mchtigen Mechanismus, um a Abhngigkeiten zu ermitteln. Jede Quelltextdatei gehrt zu einem Package und a o kann multiple andere Packages importieren. Es knnen neben lokalen Paketen o auch Pakete aus Web-Repositorys eingebunden werden, welche zur Kompilierzeit heruntergeladen und ubersetzt werden [2][5]. Die in C obligatorischen Semikolons sind in Go optional und mssen nur verwenu det werden, wenn mehrere Befehle in einer Zeile stehen sollen. Klammern sind weitestgehend nicht mehr notwendig. So wird beispielsweise bei den Bedingungen von if-Anweisungen komplett auf Klammern verzichtet [2]. Die Deklarationssyntax wurde in eine sprechende Variante gendert, um komplexe a Deklarationen von z. B. Funktionszeigern besser lesbar zu gestalten. Durch die sprechende Deklarationssyntax wurde das Schlsselwort var notwendig, um eine u Deklaration vom restlichen Quelltext zu unterscheiden. Eine andere Mglichkeit o der Deklaration ist der := Operator, welcher den Typ der neuen Variable auf der linken Seite aus dem Typ der rechten Seite inferiert1 [3]. Weiterhin ist eine korrekte Formatierung des Go-Quelltextes ntig. In Go gibt es o keine Warnungen, was einen falsch formatierten Quelltext zu einem Kompilierfehler werden lsst. Diese Manahme ist theoretisch fr den Parser nicht notwendig, a u wurde aber ergrien, um die Lesbarkeit des Quelltextes zu steigern. Ein Beispiel fr die strengen Formatierungsregeln sind die geschweiften Klammern. Diese u mssen im Java-Einrckstil verwendet werden. Zur einheitlichen Aufbesserung von u u z. B. Whitespace-Formatierungen kann das integrierte Werkzeug gofmt verwendet werden. Allerdings basiert gofmt auf dem selben Parser wie der Kompiler und kann 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 zu knnen (siehe Listing 3.2). o
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 durchluft somit auch den Type-Checker. a

28

3 Go 1.0

3.2.2

Der erweiterte Funktionsumfang

Die im Abschnitt 3.2.1 erluterten Eigenschaften der Syntax haben die Intention, a die Programmiersprache Go leicht lesbar und einfach erlernbar bzw. verwendbar zu gestalten. In diesem Abschnitt wird darauf eingegangen, welche zustzlichen Funka tionen (im Vergleich zur Programmiersprache C) vom Go-Basispaket untersttzt u werden. Ein geringer Funktionsumfang ist vorteilhaft fr eine Systemprogrammiersprau che, da dieser den Kompilerbau erleichtert. Somit kann bei neuen Systemen schnell auf eine hhere Programmiersprache gewechselt werden. Aber das Fehlen o von einheitlich integrierten Lsungen fr aktuell alltgliche Problemstellungen, o u a wie z. B. Threads und Synchronisierung, fhrt zur Verwendung unterschiedlicher u Fremdbibliotheken und somit zu Kompatibilittsschwierigkeiten auf unterschiedlia chen Systemen. Die Mglichkeiten zur Parallelisierung und Synchronisation in Go o werden im Abschnitt 3.3 besprochen. Go bietet eine volle Unicode Untersttzung, sowohl in Variablennamen als auch u in Strings. Die Anweisung t = t1 - t2 und das String-Literal "t R" wren a also Beispiele fr gltigen Go-Quelltext [2]. u u Im weiteren Funktionsumfang der Programmiersprache Go werden [2]: Mehrfach-Rckgabewerte untersttzt, u u eine Referenzdatentyp map zur Verfgung gestellt, welcher einem Assoziativarray u oder Dictionary anderer Programmiersprachen entspricht und ein defer-Schlsselwort eingefhrt, durch das bei jeder Funktion nally-hnliche u u a Anweisungen, unabhngig vom Return-Point, ausgefhrt werden knnen. a u o Funktionale Anstze a Die Mglichkeit, funktionale Anstze in Go umzusetzen, ist durch die Untersttzung o a u von Funktionszeigern prinzipiell gegeben. Funktionszeiger ermglichen die Impleo 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, untersttzt [6]. u

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 untersttzt, wodurch der Entwickler die Freiheit hat, selbst u

3.2 Grundlagen

29

ressourcenschonend und performant zu programmieren. Auf eine Untersttzung u der Zeigerarithmetik wurde verzichtet [7]. Ein Array in Go entspricht einem Array in C, also einem sequenziell reservierten Stck Speichers fester Gre. Um die Bildung von Teilmengen und die Erweiterung u o von Arrays zu vereinfachen, werden in Go Slices anstelle von Arrays verwendet [4]. Ein Slice ist ein Referenztyp, welcher auf einem Array operiert. Dadurch bleibt der Geschwindigkeitsvorteil der hardwarenahen Array-Implementierung erhalten. Ein Slice wird durch einen Zeiger auf sein Startelement im referenzierten Array, seine Lnge und seine Kapazitt reprsentiert. Somit kann ein Slice ohne groe Kosten a a a zur Laufzeit verndert und erweitert werden, sofern der referenzierte Array gro a genug ist. Sollte im Verlauf des Programms mehr Kapazitt ntig sein, als der a o Array des Slices zur Verfgung stellen kann, muss der Array auf die konventionelle u Weise2 erweitert werden. Dafr bietet Go seit der Version 1.0 die Funktion append u [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 Programmiersprachen wurde bewusst verzichtet. In Go ist es beispielsweise nicht mglich, o dynamisch zu linken3 . Jeglicher Go-Quelltext soll zur Kompilierzeit zur Verfgung u stehen. Diese Manahme soll zur Vermeidung von Fehlern beitragen [8]. Keine objektorientierte Programmierung In Go werden weder Klassen noch Vererbung untersttzt. Ein Grund fr den u u Verzicht auf das objektorientierte Programmiermodell ist die geringere Performanz durch den Overhead der intern notwendigen Reprsentation von bspw. Vererbungsa wegen im Vergleich zu prozeduralen Funktionsaufrufen [8]. Es ist jedoch mglich, Methoden auf Strukturen oder Typen zu denieren. Eine o solche Methode ist nach ihrer Denition in jeder Instanz einer solchen Struktur (oder Typs) vorhanden. Weiterhin knnen Interfaces deniert werden. Ein Interface in Go bestimmt, o welche Methoden auf einer Struktur oder einem Typ deniert sein mssen. Eine u Struktur oder ein Typ implementieren ein Interface automatisch, sobald alle durch das Interface bestimmten Methoden auf ihnen deniert wurden. Dadurch ist
2

Einen neuen, greren Array reservieren; die Werte des alten Arrays in den neuen kopieren; die o Referenz auf den neuen Array setzen und den Speicher des alten Arrays freigeben. 3 Aus Grnden der Kompatibilitt mit diversen vorhandenen APIs (z. B. OpenGL oder WinAPI) u a ist dynamisches Linken mit C-Bibliotheken jedoch mglich. o

30

3 Go 1.0

eine einfache Handhabung von Interfaces und eine vollkommene Unabhngigkeit a zwischen Interface- und Implementierungs-Package mglich [2]. o Fehlerbehandlung Das ebenfalls weit verbreitete Konzept der Exceptions wird in Go nicht untersttzt. u Die Behandlung von Fehlern soll so nah wie mglich am Fehlerursprung geschehen. o Die Fehlermeldungen knnen uber die Mehrfach-Rckgabewerte der Funktionen o u an den Aufrufer weitergeleitet werden. Mit Go 1.0 wurde der Fehlertyp error eingefhrt, welcher als allgemeiner Container fr Fehlermeldungen jeder Art dient u u [1]. Die Behandlung von schweren Fehlern zur Laufzeit erfolgt mittels panic und recover. Das Verhalten der panic-Funktion ist dem einer Exception sehr hnlich. a Der Aufruf-Stack wird durchlaufen und das Laufzeitsystem fngt die panic in a letzter Instanz und beendet das Programm mit einer Fehlermeldung. Es besteht jedoch die Mglichkeit, eine panic mit dem Befehl recover aufzufangen, zu o behandeln und den Programmablauf fortzusetzen. Dies ist mglich, da der mit o dem Schlsselwort defer denierte Code, selbst bei einer panic, beim Verlassen u der Funktion ausgefhrt wird [2]. u

3.3

Mglichkeiten verteilter Systeme in Go o

Die Mglichkeiten von Go zur Parallelisierung und Synchronisierung von Proo grammablufen sind unkompliziert und geradlinig. Basierend auf Tony Hoares a Prozessalgebra Communicating Sequential Processes (CSP)4 kann die Paralleli sierung durch Goroutines und die Synchronisierung durch Channels implementiert werden.

3.3.1

Goroutines

Die Goroutines sind eine threadhnliche Mglichkeit, Funktionsaufrufe asynchron a o und somit parallelisierbar zu gestalten. Eine Goroutine ist eine Funktion, welche konkurrierend mit anderen Goroutines im selben Adressraum ausgefhrt wird. Die u Umwandlung eines konventionellen Funktionsaufrufs in einen asynchronen erfolgt durch Hinzufgen des Schlsselwortes go. Im Listing 3.3 wird die Ausgabefunktion u u fmt.Println() einmal asynchron durch das Schlsselwort go und einmal konvenu tionell (blockierend) aufgerufen. Dies hat zur Folge, dass die Ausgabe Hello Go!
4

Weitere Informationen zu CSP knnen unter www.usingcsp.com (7.7.2012) abgerufen werden. o

3.3 Mglichkeiten verteilter Systeme in Go o

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 bentigt nur geringfgig mehr Ressourcen als ein kono u ventioneller Funktionsaufruf. Ein weiterer Vorteil ist die automatische Verteilung der Goroutines auf mehrere Kernel Level Threads durch die Laufzeitumgebung, wodurch die Blockierung einzelner Goroutines (z. B. durch IO) nicht zur Blockierung aller Goroutines fhrt [2]. u

3.3.2

Channels

Durch die Channels bietet Go ein Konzept, welches Kommunikation, Werteaustausch und Synchronisierung zwischen Goroutines kombiniert. Ein Channel ist ein Referenzdatentyp und kann als Pipe mit der Standardkapazitt von 1 betrachtet a werden. Wird beispielsweise ein Channel auf einem int erstellt:
ch := make(chan int)

so kann jede Goroutine mit Zugri auf die Variable ch in den Channel schreiben oder daraus lesen. Die Lese- und Schreiboperationen auf einen Channel erfolgen mit dem Operator <-. Steht der Channel auf der rechten Seite, wird der Wert, der durch den Channel referenzierten Variable, in die Variable der linken Seite gelesen. Dabei blockiert dieser Aufruf, bis etwas aus dem Channel gelesen werden kann. Steht der Channel auf der linken Seite, wird der Wert des Ausdrucks auf der rechten Seite in den Channel geschrieben. Der Schreibzugri blockiert, falls der Channel bereits bis an seine Kapazittsgrenze gefllt ist [2][7]. a u
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 anhand des Beispielprogramms von Listing 3.4 erlutert. Die denierte Funktion sum a errechnet die Summe der Elemente des ihr ubergebenen int-Slices und schreibt das Ergebnis in den ebenfalls ubergebenen Channel. In der main-Funktion wird ein zu berechnendes int-Slice deklariert und ein Channel erstellt. Nachfolgend wird die Funktion sum zweimal asynchron, mit je einer Hlfte des int-Slices, aufgerufen. a Das Programm ist nun in drei Handlungsstrnge unterteilt. Durch das zweimalige a Lesen aus dem Channel mittels <-c wird die Goroutine der main-Funktion blockiert, bis die Ergebnisse der beiden nebenlugen Aktivitten verfgbar sind. a a u Die select-Anweisung auf Channels Die select-Anweisung bietet die Mglichkeit, auf den Lesevorgang mehrerer o Channels zu warten. Es werden dabei, wie bei der switch-Anweisung, mittels case die einzelnen Lesevorgnge aufgelistet (siehe Listing 3.5). a
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 Flle blockieren. a Sollte mehr als ein Fall zur selben Zeit verfgbar sein, wird per Zufall ausgewhlt. u a

3.3 Mglichkeiten verteilter Systeme in Go o

33

Um jegliches Blockieren der select-Anweisung zu verhindern, kann ein default Fall angegeben werden, welcher betreten wird, wenn alle anderen Flle blockieren a [2][7].

3.3.3

Klassische Synchronisierungsmechanismen

Durch das enthaltene Package sync ist es neben Channels ebenfalls mglich, o klassische Synchronisierungsmechanismen wie mutual exclusion locks zu verwen den. Im Listing 3.6 wird die Verwendung des Mutex-Locks dargestellt. Weiterhin bietet das Package bspw. den Once-Datentyp. Dieser fhrt eine ihm ubergebene u Funktion aus und stellt sicher, dass dieser Funktionsaufruf nur einmal geschieht. Weitere Anfragen an Once, diese Funktion auszufhren, werden ignoriert [9]. u
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 implementieren, stellt das sync/atomic-Package die atomaren Grundoperationen Add, CompareAndSwap, Load und Store auf Basisdatentypen int32, int64, uint32, uint64, uintprt und unsafe.Pointer zur Verfgung [10]. u

3.3.4

Remote Procedure Calls

Mit Remote Procedure Calls (RPC) ist es mglich, eine Funktion eines RPC-Servers o aufzurufen und deren Ergebnis durch diesen zu beziehen. Go untersttzt dieses u Verfahren durch das Package net/rpc. Das rpc-Package bietet Zugri auf exportierte Methoden5 eines Objektes uber ein Netzwerk oder sonstige I/O Verbindungen. Die Methoden des Objektes mssen u folgende Bedingungen erfllen, um am Client verfgbar zu sein [11]: u u die Methode muss exportiert sein, die Parameter der Methode mssen exportierte oder Basisdatentypen sein, u
5

Exporte werden in Go uber Gro- und Kleinschreibung des ersten Buchstaben ihres Namens gesteuert. Ein groer Anfangsbuchstabe bedeutet public, ein kleiner private.

34

3 Go 1.0

der zweite Parameter muss ein Zeiger sein und die Methode muss den Rckgabetyp error haben. u Durch diesen Funktionsaufbau knnen alle Funktionen reprsentiert werden. Der o a schematische Aufbau einer gltigen RPC-Methode wre wie folgt [11]: u a
func (t *T)MethodName(argType T1, replyType *T2)error

Der erste Parameter enthlt alle bentigten Funktionsparameter (z. B. in einer a o Struktur) und der zweite Parameter stellt den Rckgabewert der Funktion dar. u Zur Fehlerauswertung kann der allgemeine Typ error (Funktionsrckgabewert) u verwendet werden.

3.4

Zusammenfassung und Ausblick

Go ist ein gelungener Ansatz, eine performante Systemprogrammiersprache zu entwickeln. Besonders die Goroutines, welche die Komplexitt der Parallelisiea rung stark abstrahieren, ermglichen in Kombination mit der Synchronisierung o uber Channels ein einheitliches und intuitiven Konzept zur Programmierung auf Rechnern mit mehreren logischen Prozessoren. Da es nicht mglich ist, Go-Code dynamisch zu linken, ist die Realisierung eines o Plugin-Systems schwer mglich. Hierbei msste bspw. darauf zurckgegrien o u u werden, einen Interpreter fr eine Skriptsprache wie Lua einzubauen und die u Plugins zur Laufzeit zu interpretieren. Diese Lsung wirkt sich allerdings in der o Performanz der Plugins aus. Weiterhin knnte die Parallelisierung noch einfacher werden, denn die Goroutines o laufen standardmig alle auf einem logischen Prozessor und werden nicht verteilt. a Um zu erreichen, dass alle vorhandenen logischen Prozessoren verwendet werden, muss der folgende Befehl ausgefhrt werden [2]: u
runtime.GOMAXPROCS(runtime.NumCPU())

Go knnte sich in der Entwicklung performanter, plattformbergreifender Ano u wendungen etablieren und dabei anderen plattformunabhngigen Sprachen wie a Java in Sachen Performanz Konkurrenz machen. Eine denkbare Mglichkeit dafr o u wre ein neues Datenbank Management System. Die integrierten Methoden zur a Parallelisierung und Synchronisation in Kombination mit der Performanz durch die Systemnhe und der vollen Unicode-Untersttzung scheinen wie geschaen a u dafr zu sein. u

Literaturverzeichnis

35

Literaturverzeichnis
[1] Google Inc., FAQ The Go Programming http://golang.org/doc/go faq.html, 08.07.2012. [2] Google Inc., Eective Go The Go Programming http://golang.org/doc/eective go.html, 08.07.2012. Language. Language.

[3] Google Inc., Gos 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 http://golang.org/pkg/sync/, 08.07.2012. Go Programming Language.

[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 http://golang.org/pkg/net/rpc/, 08.07.2012. Programming Language.

36

3 Go 1.0

GridGain
4.1 4.2 4.3 4.4 Einleitung . . . . . . . . . . . . . . . . . . . Was ist GridGain? . . . . . . . . . . . . . . Warum GridGain? . . . . . . . . . . . . . . . Compute und In-Memory-Technologie . . . . 4.4.1 In-Memory Data Grid . . . . . . . . 4.4.2 Compute Grid . . . . . . . . . . . . 4.5 High Performance und Cloud Computing . . 4.5.1 Cloud Computing . . . . . . . . . . 4.5.2 High Performance . . . . . . . . . . 4.5.3 GridGain als High Performance Cloud 4.6 IaaS, PaaS und SaaS . . . . . . . . . . . . . 4.6.1 IaaS . . . . . . . . . . . . . . . . . 4.6.2 PaaS . . . . . . . . . . . . . . . . . 4.6.3 SaaS . . . . . . . . . . . . . . . . . 4.6.4 Einordnung von GridGain . . . . . . 4.7 Ein Beispiel . . . . . . . . . . . . . . . . . . 4.7.1 Schritt 1: Knoten starten . . . . . . 4.7.2 Schritt 2: Ausfhren des Codes . . . u 4.7.3 Schritt 3: Endergebnis . . . . . . . . 4.8 Anhang . . . . . . . . . . . . . . . . . . . . 4.8.1 Verfgbarkeit . . . . . . . . . . . . . u 4.8.2 Lizenz . . . . . . . . . . . . . . . . 4.8.3 Support . . . . . . . . . . . . . . . . 4.9 Schlusswort . . . . . . . . . . . . . . . . . . 4.10 Quellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 38 40 40 40 42 43 43 43 43 44 44 44 45 45 46 46 46 47 48 48 48 49 49 50

Danny Rubner

Inhaltsverzeichnis

38

4 GridGain

4.1

Einleitung

Das Sammeln, Bearbeiten und Verarbeiten von Daten spielt in der heutigen Gesellschaft eine wesentliche Rolle. So werden regelmig verschiedene Formen a von Nutzerdaten in Firmen angelegt, Bestellungen verarbeitet und Daten gesichert. Doch stellt sich die Frage, wie mit der unglaublichen Menge an Daten in namenhaften Firmen, wie Sony, Amazon oder TomTom umgegangen werden kann? Je grer eine Firma ist, desto mehr Nutzer nehmen o natrlich Gebrauch von verschiedenen angebotenen Diensten, die von diesen u Firmen zur Verfgung gestellt werden. Doch geht es gerade in der Informatik u darum, diese Daten, welche durch Dienste erzeugt und von diesen verwendet werden ezient zu speichern und vor allem mit diesen wirkungsvoll umzugehen. GridGain ist eine Technologie, die eine eziente Datenverarbeitung ermglicht. In o den folgenden Abschnitten wird deshalb genauer auf diese Technolgie eingegangen, um zu verdeutlichen, was GridGain eigentlich ist, welche Vorteile bei der Nutzung von 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 und Analyse von umfangreichen Datenstzen sowie das Parallelisieren von Prozessen. a Diese Plattform ermglicht das Entwickeln von verteilten Anwendungen fr o u verteilte Systeme, welche groe Performance Anforderungen besitzen. Die Software verfgt uber den Vorteil sowohl fr einzelne Systeme, als auch fr umfassende u u u Daten-Clouds Anwendung zu nden. Der Kern von GridGain verfolgt zweierlei Anstze. Zum einen soll GridGain ein mchtiges Werkzeug in Verbindung mit a a Data Warehousing sein, zum anderen elegant einfach im Umgang. Die Funktionalitt von GridGain ist auf zwei Bereiche fokussiert. Der Gebrauch a von Daten Grids ist einer dieser Bereiche, welcher das Be- und Verarbeiten von Datenstzen ermglicht. Des Weiteren ist die Mglichkeit gegeben, Datenstze a o o a mit Hilfe von In-Memory-Technologie zu verarbeiten, um mglichst schnell und o ezient Ergebnisse erzielen zu knnen. o GridGain ist fr Business Anwendungen und Data Warehouse, wie SQL oder ERP u geeignet.1 Die Positionierung von GridGain lsst sich demnach zentral aunden. a
1

Siehe Abb. 4.1, Seite 39

4.2 Was ist GridGain?

39

Das heisst, zwischen Anwendungen oder Business Intelligence-Software und der eigentlichen Daten-Cloud, dem Long-Term-Storage oder Data Warehousing. Eine groe Strke von GridGain ist die Verarbeitung von Live Data. Somit a knnen gerade einkommende Daten direkt verarbeitet und fr Anwendungen o u oder Datenbanken zur Verfgung gestellt werden. Der Vorteil der Anwendung u liegt vor allem in der Untersttzung von In-Memory-Technologie die eine hohe u Performance gewhrleistet und mit geringen Verarbeitungslatenzen von Daten a besticht, da ein Groteil der Daten von GridGain im Speicher behalten wird, um mit diesen zu operieren. Fr die Ezienz der gespeicherten Daten ist die u Intelligence Caching Technology verantwortlich. Diese speichert nur oft genutzte oder wichtige Daten im Speicher. Die weniger wichtigen Daten verbleiben derweil in Langzeitspeicherung oder im Data Warehouse.

Abbildung 4.1: Ubersicht; Positionierung von GridGain zwischen Business Anwendung und Data Warehousing. [GGFE]

Mit der GridGain Architektur besteht die Mglichkeit Business Daten in zwei o verschiedene Richtungen zu leiten. Entweder von der Business Anwendung und externen Quellen durch GridGain in ein Data Warehouse oder Bulk-Loaded vom Data Warehouse in In-Memory Daten Grids fr geringe Latenzen und Echtzeitveru arbeitung. Ersteres, auch genannt Up-Stream, ist gut geeignet fr Streamingu und Transaktionsdaten, die nicht direkt in einem Data Warehouse gespeichert werden knnen, da diese eektiv in Echtzeit verarbeitet werden mssen. Die zweite o u Methode, Down-Stream, ist ideal fr die Verarbeitung von schon gesammelten, u historischen Daten. In vielen Fllen werden beide Mglichkeiten durch Anwenduna o gen genutzt. GridGain ermglicht sowohl Up-, als auch Down-Stream. o

40

4 GridGain

4.3

Warum GridGain?

Durch das Untersttzen der beschriebenen vorangegangenen Bereiche in Abu schnitt 4.1 ergeben sich fr Anwendungen, die GridGain -Methoden implementieren u folgende Vorteile: * arbeiten in einem Zero-Deployment Modus2 * auf- und ab-skalieren je nach Bedarf * cachen verteilter Daten in Datengrids * schnelleres lsen von Aufgaben durch MapReduce o * 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 GridGain dient dem Lsen des Problems mit verteilten Daten und deren verteilten Berecho nungen zuarbeiten. Das heit, dass diese beiden Technologien fundamental fr u verteilte Systeme sind und diese sowohl die Parallelisierung von Berechnungen als auch die Parallelisierung von Datenspeicherung und -zugri ermglichen. GridGain o ist die erste Software Middleware, die In-Memory Data Grids und In-Memory Compute Grids in einem Produkt untersttzt, um Parallelisierung zu ermglichen. u o Beide Technologien sind essentiell fr moderne verteilte Datenverarbeitung, die u wiederum wesentliche Vorteile fr den Anwender bereit halten. Unter diese Vorteile u fllt das Arbeiten mit einheitlichen APIs fr Datenzugri und -Verarbeitung, eina u malige einheitliche Konguration, die drastisch gesenkte Lernkurve und weitere4 Vorteile.

4.4.1

In-Memory Data Grid

In-Memory Data Grids bilden die Kerntechnologie von GridGain. Durch diese Grids wird die Mglichkeit gegeben, umfassende Datenstze mit geringer Latenz im o a Echtzeitkontext zu verarbeiten. Somit knnen Daten von einem einzigen Computer o bis hin zu mehreren Terabytes Daten skaliert werden. Die In-Memory Data GridTechnologie untersttzt den Fall der Parallelisierung der Datenspeicherung durch u
Zero-Deployment Mode ist die Vermeidung von weniger relevanten IT-Aufgaben Siehe [WIGG] 4 Siehe [GGFE]; Abschnitt Integrated In-Memory Data Grid and Compute Grid
3 2

4.4 Compute und In-Memory-Technologie

41

Speicherung partitionierter Daten durch In-Process Memory. Dass heit, dass Daten durch das In-Memory Compute Grid so nahe wie mglich und so schnell o wie mglich an der Anwendung sein sollen. o

Abbildung 4.2: Einsatz von Data Grids; Gegenberstellung von Berechnungsprozessen u einzelner Knoten, die auf Data Grids sowohl zurckgreifen (Grak; unten), als auch u nicht zurckgreifen (Grak; oben).[GGDG] u

Der Vergleich5 von Verarbeitungen mit In-Memory Data Grids und ohne Grids zeigt, dass die Verarbeitung einer Anfrage mit verschiedenen Schlsseln (K1 , K2 u und K3 ) in einem Prozess ohne Daten Grids zunchst Ergebnisse (V1 , V2 und V3 ) a liefert, wenn diese Anfrage mit den Schlsseln an eine Datenbank geleitet werden. u Allerdings mssen die Daten fr die weitere Verarbeitung, falls diese nochmals u u bentigt werden, erneut angefragt werden. Somit wiederholt sich der Prozess.6 o 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 und an das System weitergeleitet, welches die Ergebniswerte (V1 , V2 und V3 ) liefert.7 Dass System gibt die einzelnen Ergebnisse an die Knoten zurck und diese reichen u die 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 Gedchtnis angesehen werden knnen. Diese beinhalten partitionierte a o Daten und untersttzen verschiedene Caching-Strategien. Das Ziel ist es, eine u extrem hohe Verfgbarkeit von Daten zu ermglichen, so dass diese Daten direkt u o im Speicher in verteilter Form hinterlegt sind.

Siehe Abb. 4.2, Seite 41 siehe Abb. 4.2, Seite 41; oben 7 siehe Abb. 4.2, Seite 41; unten
6

42

4 GridGain

4.4.2

Compute Grid

Bei Compute Grids handelt es sich ebenfalls um eine Kerntechnologie von GridGain. Diese Technologie ermglicht die Parallelisierung von Berechnungen an o einem oder mehreren Knoten.

Abbildung 4.3: Einsatz von Compute Grids; Gegenberstellung von Berechnungsprou zessen, die auf Compute Grids sowohl zurckgreifen (Grak; unten), als auch nicht u zurckgreifen (Grak; oben).[GGCG] u

Wie in der Grak8 zu sehen, wird eine Berechnung (C) an einem Computer durchgefhrt. Diese Berechnung bentigt eine gewisse Zeit (T) um ein Resultat u o (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 verschiedene Knoten weitergereicht, die diese einzelnen Berechnungen durchfhren. Die Knoten u liefern anschlieend die einzelnen Ergebnisse (R1 , R2 und R3 ) zurck, welches u zu einem Endergebnis (R) zusammengesetzt wird. Die zu verarbeitende Zeit (T) resultiert aus der Maschine, die am lngsten fr die Berechnung bentigt a u o und dem liefern sowie zusammensetzen der Ergebnisse. In der Regel ist dieses verteilte Arbeiten wesentlich Zeit-extensiver als die Verarbeitung durch eine einzelne Maschine. Das Ziel, der Anwendung von Compute Grids ist das berechnen und lsen von umfassenden Berechnungen durch mehrere Knoten. o

8 9

Siehe Abb. 4.3, Seite 42; oben 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 beschrieben. High Performance und Cloud Computing sind die fundamentalen Grundstze, die in der GridGain-Philosophy verankert sind. a

4.5.1

Cloud Computing

Cloud Computing ist, laut den Entwicklern, ein Synonym fr die traditionelle u verteilte Programmierung.10 Unter Cloud Computing wird aus heutiger Sicht die Bereitstellung von Infrastrukturen, Plattformen und Software verstanden. Mit Infrastrukturen kann beispielsweise die Bereitstellung von Rechnenleistung und Speicherplatz gemeint sein. Dabei wird der Zugri fr den Nutzer uber ein u Netzwerk, zum Beispiel das Internet oder rmeneigene Intranets ermglicht. Durch o Cloud Computing wird die Parallelisierung von Verfgbarkeit und Verarbeitung u von Datengrids in GridGain ermglicht. Beide Aspekte sind absolut entscheidend o fr skalierbare, verteilte Systeme. u

4.5.2

High Performance

High Performance ist ebenfalls eine Anforderung von GridGain an CloudAnwendungen. Die meisten heutigen Cloud-Anwendungen erfllen die Anfordeu rung an hohe Leistung nicht. Dabei sollen High Performance-Anwendungen Cloud-Distributionen nutzen, um die Skalierbarkeit und Leistung zu erreichen, die theoretisch fr eine einzige Verarbeitungseinheit unerreichbar ist. Nicht-High u Performance-Anwendungen nutzen Cloud-Distributionen nur als okonomische oder 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 fr u die einfache Entwicklung von verteilten Software-Systemen entwickelt worden. Des Weiteren untersttzt GridGain Skalierbarkeit und Leistung fr Software-Systeme, u u die zum verteilten Kontext gehren. o

10 Ebd.

[GGCC]

44

4 GridGain

4.6

IaaS, PaaS und SaaS

Die Begrie IaaS, SaaS und PaaS werden heute, ohne jegliche weitere Ausfhrungen oder genaue Denitionen, gelug im Sprachgebrauch verwendet. u a Jedoch sind nur die ersten beiden Begrie wirklich aus deniert. Der Begri PaaS hingegen weniger. In diesem Abschnitt wird auf die einzelnen Begrie eingegangen und uber die Lokalisierung von GridGain in diesem Zusammenhang gesprochen.

4.6.1

IaaS

IaaS ist eine der drei Servicearten und steht fr Infrastructure As a Service. u Dieser Begri wird oft als Cloud Computing beschrieben, gemeint ist jedoch die Untersttzung von virtuellen Berechnungsressourcen als Service. Als Beispiel kann u hier Amazon EC2 angefhrt werden. Es handelt sich um das eigne Amazon Dau tencenter, welches gegen Bezahlung nicht genutzte Rechnerkapazitt zur Verfgung a u stellt. Durch das Einsetzen von virtualisierter Hardware, wie Virtual Machines von VMWare oder Vitrix, auf den hauseigenen Servern kann ein Management uber den Web Browser realisiert werden, um die einzelnen Virtual Machine-Instanzen zu verwalten. IaaS kann sowohl entlich (public), als auch privat (private) o sein. Mischungen (hybrid) sind ebenfalls mglich. Oentliche Infrastrukturen o sind entlich zugnglich. Beispielsweise die Zugrisvergabe fr jeden an ein Dao a u tencenter. Private Strukturen sind meist fr die eigene Nutzung von Organisationen u und Firmen erstellte individualisierte Infrastrukturen. Die Untersttzung beider u Verhaltensweisen ist Aufgabe von hybriden Strukturen. Private und entliche o Infrastrukturen (Clouds) sind fr gewhnlich von physikalischer Struktur. Hybride u o Clouds jedoch eher als virtuelle Cloud anzusehen, denn diese sitzen am Kopf einer physischen entlichen oder privaten Cloud und untersttzen nahtlos die o u Endbenutzer in Bezug auf Cloud- oder IaaS-Transparenz.

4.6.2

PaaS

PaaS deniert eine Plattform als einen Dienst und steht fr Platform As a u Service. Fr PaaS gibt es keine einheitliche Denition, vielmehr nur Beschreiu bungen, was man unter dieser Abkrzung gemeint ist: Die Plattform untersttzt u u den IaaS-Anbieten oder -Provider und fgt weitere Dienstleistungen hinzu. Diese u erweiterten Dienste bestehen aus Bereitstellungs- und Beschaungsservices, mit dem Ziel, der Support Application Multi-Tenancy. Also Eigenschaften zum Verwalten mehrerer Anwendungen auf einer oder mehreren virtuellen Maschinen.

4.6 IaaS, PaaS und SaaS

45

4.6.3

SaaS

Der letzte Begri SaaS, also Software As a Service, deniert die Software als einen Dienst und hat relativ wenig mit IaaS oder PaaS zu tun. Dieser Dienst ist vorstellbar mit dem Aufrufen einer Anwendung im Browser. Diese Anwendung ist somit eine SaaS-Abwendung.

4.6.4

Einordnung von GridGain

Mit GridGain besteht die Mglichkeit mit IaaS-, wie etwa Amazons AWS, o oder PaaS-Diensten zu arbeiten.11 Jedoch ist GridGain vollkommen unabhngig a von beiden genannten Servicearten. GridGain kann komplett ohne spezische Cloud-, Grid- oder Cluster-Infrastruktur auskommen. Diese Eigenschaft ist eine der Schlsselvorteile von GridGain. Somit ist die Untersttzung fr Entwickler gegeben, u u u welche die gleichen Services auf verschiedenen Gerten, wie Android-Systeme, a Laptops, mehrere Server, Grids oder Clouds zur Verfgung stellen mchten. u o

Abbildung 4.4: IaaS, PaaS und SaaS [IPS]

11 Siehe

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. Ausfhren des Codes u 3. Ergebnis erhalten

4.7.1

Schritt 1: Knoten starten

Im ersten Schritt werden die einzelnen Knoten gestartet.12 Dies geschieht durch das Ausfhren des Befehls ggstart in der Konsole. Anschlieend wird ein u Ausdruck gezeigt, der besagt, um welche GridGain Version es sich handelt. Auerdem werden weitere Informationen ausgegeben, wie etwa der genutzte Modus oder um welchen Nutzer es sich handelt.

Abbildung 4.5: Auszug aus der Konsole, nach dem Starten eines Knotens.

4.7.2

Schritt 2: Ausfhren des Codes u

Nachdem starten des Knotens wird der eigentliche Code ausgefhrt.13 In diesem u Code wird uber die Main-Methode, nach dem Importieren der Klassen, eine Funktion MapReduceCount aufgerufen mit einem String, Java GridGain MapReduce, als Parameter. Das Ziel dieser Funktion ist es, die Zeichen der einzelnen Wrter, die durch ein Leerzeichen getrennt worden sind, zu zhlen. o a Das Ergebnis wird an die Main-Methode zurckgegeben und mit Count is: u auf dem Bildschirm ausgegeben. Innerhalb der Main-Methode wird, neben zwei
12 Siehe 13 Siehe

Abb. 4.5, Seite 46 Abb. 4.6, Seite 47

4.7 Ein Beispiel

47

anderen Knoten die in dem Beispiel uber die Konsole gestartet wurden, ein weiterer Knoten gestartet, mit G.start(), und nach dem Zhlvorgang mit a G.stop(true) wieder gestoppt. In der mapReduceCount-Funktion wird die eigentliche Reduce-Methode aufgerufen, die fr das Zhlen verantwortlich ist. u a Der erste Parameter SPREAD der Methode beschreibt, wie die Aufgabe, also der zweite Parameter, an die einzelnen Knoten verteilt werden soll. Der letzte Parameter F.sumIntReducer() setzt die Teilergebnisse der Knoten zu einem Gesamtergebnis zusammen, welches uber return an die Main-Funktion fr u die Ausgabe zurckgegeben wird. Innerhalb des zweiten Parameters, wird der u eigentlich String anstelle der Leerzeichen geteilt und an die einzelnen Knoten ubergeben, die mit Calculating for: den Namen des Strings, von dem die Zeichen gezhlt werden sollen, ausgeben. Anschlieend wird die Lnge des Strings a a an den Hauptknoten zurckgegeben. u

Abbildung 4.6: Auszug des auszufhrenden Codes. u

4.7.3

Schritt 3: Endergebnis

Im letzten Schritt wird jeweils das Gesamtergebnis dargestellt.14 In den ersten beiden Auszgen werden die einzelnen Strings gezeigt, fr dem der Knoten verantu u wortlich ist, nmlich MapReduce und GridGain. In der letzten Grak wird der a
14 Siehe

Abb. 4.7, Seite 48

48

4 GridGain

String Java gezeigt, wie auch das Endergebnis, Count is: 21, des Zhlvorgangs. a

Abbildung 4.7: Auszug der einzelnen Ausgaben der Knoten sowie des Endergebnisses.

Weitere Beispiele existieren auf der Homepage oder im Youtube-Channel von GridGain.15

4.8

Anhang

Die aktuelle Version von GridGain kann nach erfolgreicher Registrierung unter http://www.gridgain.com/download/ heruntergeladen werden. Diese beinhaltet die Bibliotheken und Beispiele fr die jeweilige gewnschte Programmiersprache u u Java, Scala oder Groovy.

4.8.1

Verfgbarkeit u

GridGain ist in drei verschiedenen Versionen verfgbar: u * Compute Grid-Edition * Data Grid-Edition * Big Data-Edition Alle Editionen sind als Open Source verfgbar. Weiterfhrend existiert noch eine u u Community-Edition. Die beinhaltenden Features der einzelnen Pakete16 knnen o auf der GridGain-Homepage betrachtet werden.

4.8.2
15 ur F

Lizenz

Fr GridGain stehen zwei gltige Lizenzen zur Verfgung: u u u

16 Siehe

weiterfhrende Informationen siehe Quellen - Internetreferenzen u [GGPU]

4.9 Schlusswort

49

* GridGain Community Edition: Diese Lizenz ist freie Open-Source-Software und lizenziert unter GPL17 Version 3 * GridGain Enterprise Edition: Diese Lizenz ist Closed-Source, kommerziell lizenziert18 und somit nicht frei zugnglich a Die aktuelle EULA (End-Used License Agreement) fr die Enterprise Edition ist u im GridGain Installationshauptverzeichniss, nach der Installation von GridGrain verfgbar oder auf der GridGain Internetseite19 . u

4.8.3

Support

Es gibt einen freien GridGain Support, durch die aktive Community im Forum, ebenfalls zu nden auf der GridGain-Homepage20 unter dem Reiter Forums. Auerdem steht ein kommerzieller Service zur Verfgung, durch das GridGainu Unternehmen.

4.9

Schlusswort

GridGain ist eine leistungsfhige und eziente Middleware-Software, die durch a verschiedene In-Memory-Technologien umfangreiche Datenstze verarbeiten und a komplexe Berechnungen durchfhren kann. Sie ist durch die Mglichkeit des u o Einsatzes von Knoten durchaus fr verteiltes Arbeiten geeignet und durch die u Verfgbarkeit verschiedener Pakete, die zum Download bereitstehen, an diverse u Ausgangssituationen anpassbar. Dadurch, dass GridGain auerdem fr Java-, Scalau und Groovy-Entwickler verfgbar ist, wird auch ein breites Spektrum an Entwicklern u angesprochen. Die einfache Integration in eine Anwendung erleichtert stark die Einbettung von GridGain in eigene Anwendungen. Alles in allem ist GridGain eine Software, die stark zur Erleichterung im Kontext des verteilten Arbeitens beitrgt a und durch stndige Weiterentwicklungen zuknftig an Interesse gewinnen wird. a u

17 Stand 18 Stand

05. Juni 2012; Siehe [GGLI] 05. Juni 2012; Ebd. 19 Siehe [GGHP] 20 Ebd.

50

4 GridGain

4.10

Quellen

Internetreferenzen: * Ozielle 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 Bcher: u * [GG10] Real time Big Data Processing With GridGain (2010) Ivanov, N.; Setrakyan, D. Letzter Aufruf am 11. Mai 2012 URL: http://www.gridgain.com/book/book.html

Literaturverzeichnis
[GGHP] GridGain-Homepage; Letzter Aufruf am 05. Juni 2012 URL: 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 2012 URL: http://www.gridgain.com/features/ [GGDG] Abschnitt: In-Memory Data Grid; Letzter Aufruf am 22. Mai 2012 URL: http://www.gridgain.com/features/in-memory-data-grid/ [GGCG] Abschnitt: Compute Grid; Letzter Aufruf am 22. Mai 2012 URL: http://www.gridgain.com/features/compute-grid/

Literaturverzeichnis

51

[GGPU] Abschnitt: Product Matrix; Letzter Aufruf am 02. Juli 2012 URL: http://www.gridgain.com/purchase/product matrix/ [GGLI] Abschnitt: License; Letzter Aufruf am 05. Juni 2012 URL: http://www.gridgainsystems.com/wiki/display/GG15UG/Lice nse#License-GridGain3.0CommunityEditionGeneralPublicLicense% 28GPLv3%29

52

4 GridGain

Jini - Java Intelligent Network Interface

5.1 5.2 Hintergrund . . . . . . . . . . . . . . . . . . Entwicklung JINI . . . . . . . . . . . . . . . 5.2.1 Was ist Jini? . . . . . . . . . . . . . 5.2.2 Werdegang . . . . . . . . . . . . . . 5.2.3 Ziele von Jini . . . . . . . . . . . . . Dienstkonzept . . . . . . . . . . . . . . . . . 5.3.1 Komponenten einer Jini - Architektur 5.3.2 Ablauf der Dienstvermittlung . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . Abbildungen . . . . . . . . . . . . . . . . . . Quellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 54 54 54 56 57 57 58 60 61 62

Tim Achtert

Inhaltsverzeichnis

5.3

5.4 5.5 5.6

5.1

Hintergrund

Im Jahr 1994 wurde der erste, vollstndig auf Java basierende Webbrowser mit a der Fhigkeit des Herunterladens ausfhrbarer Codeskripte, sogenannten Applets, a u von Sun Microsystems entwickelt. Im Zuge dieser Entwicklung wurde die Mglichkeit des Austauschens von Code o zwischen zusammenarbeiteten Netzwerken und Endgerten, von den Sun Microsysa tems Entwicklern unter dem Namen Jini, in einem experimentellen Projekt weiter voran getrieben. Die Verbreitung sollte sich dabei nicht nur auf Computersysteme beschrnken. Im Gegenteil, diese Technik sollte in Gerten aller Art, besonders im a a Haushalts- und Unterhaltungselektronikbereich, Verwendung nden. Das diese Gerte, speziell Kleingerte, Prozessor und Speicher besitzen knnen, a a o um eine Java Virtual Machine1 , zur Berechnung und Ausfhrung von Java - Code, u
1

Abk.:JVM

54

5 Jini - Java Intelligent Network Interface

ausfhren zu knnen, war zu dieser Zeit noch Wunschdenken. Die heutige Entwicku o lung zeigt jedoch, dass dies in den kleinsten Gerten mglich ist. Endgerten, wie a o a beispielweise Toastern oder Mikrowellen, knnten so die Mglichkeit gegeben wero o den an Netzwerkgemeinschaften teilzunehmen. Diese Zukunftsvorstellung spiegelt sich 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 der Werdegang, von der ersten oziellen Vorstellung bis heute, nher erlutert. a a

5.2.1

Was ist Jini?

Jini ist, einfach ausgedrckt, eine auf der Programmiersprache Java basierende u Architektur, mit deren Hilfe sich Dienste im Netzwerk nden, miteinander kommunizieren und sich gegenseitig nutzen knnen. Das Konzept bemht sich dabei o u Ad - Hoc Vernetzung, das sogenannte spontaneous networking3 , zu realisieren. Der entscheidende Vorteil dabei ist, dass keine Treiberinstallation mehr ntig ist, o sondern die Gerte sofort nutzbar sind, da das System bzw. das Jini - Konzept a diesen Vorgang automatisiert. Der Begri Jini steht dabei oziell fr Java Intelligent Network Interface. In u der Jini - Community wurde die Abkrzung teilweise als Jini Is Not Initials u aufgeschlsselt. u Das Jini Logo zeigt eine Wunderlampe, was die Vermutung zu lsst, dass es sich a bei 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 knnte. o

5.2.2

Werdegang

Die Entwicklung von Jini startete 1997 als internes, experimentelles Projekt. Im Jahre 1999 wurde Jini erstmals der Oentlichkeit vorgestellt und erste Beta Versionen verentlicht. Jini war dabei eines der ersten greren Projekte welches o o vom Sun Marketing als Open Source herausgegeben wurde, um die Verbreitung der Technologie zu sichern.4 Eine Jini - Community wurde ebenso ins Leben
das Netzwerk ist der Computer spontanes vernetzen 4 Vgl. Sommer P.: Jini - Konzepte von Betriebssystem-Komponenten, Universitt Erlangen, S. a 1-7
3 2

5.2 Entwicklung JINI

55

Abbildung 5.1: Logo Jini (Wunderlampe) Quelle: http://goo.gl/WiEwo

gerufen. Der Zugri auf den Quelltext fr jeden wurde mit der Sun Community u Source License [Sun00-2]5 festgelegt. Fr den Einsatz der Jini - Technologie in u kommerziellen Projekten, verlangte Sun jedoch weitere kostenpichtige Lizenzen. Fast zehn Jahre spter, im Jahr 2007, erfolgte die Ubernahme der Jini - Technik a durch die Apache Software Foundation unter dem Namen Apache River. Sun Microsystem bezeichnete die Entwicklung Jinis, sowie auch die der Community, als eingeschlafen und stellte die nanziellen Mittel ein. Aus Jini wurde somit Apache River. Momentan bendet sich Apache River noch immer in der Incubator Phase. Diese Phase mssen alle neuen Projekte, bei der Apache Software Foundation, durchlauu fen um vollwertige Projekte zu werden. Im Jahre 2010 fand eine Verschmelzung von Sun Microsystems und der Oracle Corporation statt. Sun Microsystems heit nun Sun Oracle.

Vgl.: Sun Microsystems, Richard P. Gabriel, William N. Joy: Sun Community Source License Principles, 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 fgt selbst nur wenige Funktionen hinzu) u Zuverlssigkeit (stabiles Hinzufgen oder Entfernen von Dienste in einem a u Netzwerk spontane Vernetzung) Skalierbarkeit (Jini-Dienste knnen sich zu einer Gemeinschaft (Djinn) zuo sammenschlieen, jeder Dienst kennt den anderen und kann ihn nutzen) Selbstheilung (Jini kann tote Dienste mit Hilfe des sogenannten Leasing ausschlieen)

5.3 Dienstkonzept

57

5.3

Dienstkonzept

Im folgenden Abschnitt wird das Konzept, mit den dazugehrigen Diensten, einer o Jini - 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, welcher genutzt werden soll. Mehrere Dienste werden als Djinn bezeichnet. Die wichtigste Komponente ist der Lookup - Service, welcher die Aufgabe hat, zwischen Client und Service zu vermitteln. Grundvoraussetzungen sind, wie bereits erwhnt, dass a die benutzten Gerte eine JVM besitzen und auf Basis vom TCP/IP Protokoll im a Netzwerk kommunizieren6 .

Abbildung 5.3: Abbildung Hauptkomponenten einer Jini - Architektur Quelle: eigene Darstellung

Der Code wird nun, durch serialisierte Objekte, zwischen diesen drei Komponenten ausgetauscht und muss bei spterer Verwendung dieser Objekte zunchst a a deserialisiert werden. Bei Zugri auf Methoden eines Objekts einer entfernten JVM, kommt RMI zum Einsatz. RMI ist schon lnger Bestandteil von Java und a wurde zur Objektkommunikation uber Maschinen - und Netzwerkgrenzen hinweg geschaen. RMI steht fr Remote Method Invocation und ermglicht eben genau u o diesen Zugri auf entfernte Methoden und das Transferieren von Klassen wie auch
6

Vgl. Langel J.: Jini und JavaSpaces, Universitt Freiburg (Schweiz), S. 7-12 a

58

5 Jini - Java Intelligent Network Interface

von Objekten. Auf die Spezikationen von RMI soll an dieser Stelle nicht nher a eingegangen werden.

5.3.2

Ablauf der Dienstvermittlung

In diesem Abschnitt werden die einzelnen Vorgnge und dabei genutzten Dienste a im Detail betrachtet und erklrt. a Discovery und Join Zu Beginn muss explizit ein Lookup - Service vom Administrator gestartet werden, falls noch kein solcher Service im Netzwerk luft. Danach erfolgt die Dienstsuche, a das sogenannte Discovery, damit sich Dienste beim Lookup - Service registrieren knnen. Es gibt verschiedene Discovery - Verfahren fr Dienstanbieter: o u Unicast Request Protocol Der Rechner (contact point) auf dem der Lookup - Service luft ist dem Dienst bereits bekannt durch z.B. Multicast Discovery a oder durch vorkongurierte Informationen von Host und Port. Multicast Request Protocol Dieses Verfahren wird verwendet wenn kein Lookup - Service bekannt ist. Der Jini - Service versendet dabei UDP (User Datagram Protocol) Pakete mit seinem eigenem TCP Port, den Namen der Djinns, die ihn interessieren und eine Liste der ihm schon bekannten Lookup - Services. Dadurch knnen benachbarte Lookup - Dienste werden gefunden. o 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 Netzwerk erhlt dabei regelmig Informationen per UDP mit der IP - Adresse und a a Port des Lookup - Service, der Lookup - Service ID und den Namen der Djinns, denen er angehrt. Der Lookup - Service kndigt damit sein eigenes o u Vorhandensein im Netzwerk, z.B. bei Start oder nach einem Ausfall und dem damit verbunden Neustart des Lookup - Service, an. Grund fr einen Neustart u ist z.B. ein Serverabsturz. Nach der erfolgreichen Suche des Service und dem Finden des Lookup - Service, wird ein Registrar - Objekt an den Service zurckgegeben. Das Registrar - Objekt u beinhaltet Host und Port des Lookup - Service. Daraufhin kann sich der Service beim Lookup - Service registrieren und kann daraufhin von Clients (Dienstnutzern) gefunden werden.

5.3 Dienstkonzept

59

Alle Dienste bzw. Services, wie beispielweise ein jini - fhiger Drucker, beinhalten a dabei ein Serviceobjekt, welches die Informationen zur Nutzung des Dienstes beinhaltet. Bei Registrierung, dem Joining, beim Lookup - Service wird nun eine Kopie dieses Objekts an den Lookup - Service ubergeben. Somit dient der Lookup Service dem spteren Client (Dienstnutzer) als Proxy zum Dienstanbieter (Service). a Client Lookup (Request) Die Registrierung des Clients beim Lookup - Service erfolgt quivalent zur Registriea rung des Dienstanbieters beim Lookup - Service. Daraufhin sendet nun ein Client eine Dienstanfrage (Request), mit den jeweiligen geforderten Parametern, an den Lookup - Service. Hat der Lookup - Service, bei Vorhandensein von registrierten Diensten, einen passenden Dienst gefunden, kann der Client das Serviceobjekt, vom dem Dienst welchen er nutzen mchte, in seine JVM herunterladen. Zu o diesem Zeitpunkt hat der Dienstanbieter sein Service - Objekt und der Lookup - Service sowie der Client eine Kopie dieses Objekts in der jeweiligen JVM. Der Client kann nun direkt mit dem Service uber das Service - Objekt kommunizieren. Proxies Das Service - Objekt dient dem Client also als Proxy zum Service, dabei bestehen 4 verschiedene Varianten der Nutzung7 : 1. lokal Bei dieser Variante agiert der Proxy lokal, d.h. das Proxy - Objekt ist selbst der Service und fhrt sich in der JVM des Clients aus. u 2. remote Der Proxy stellt eine Verbindung zum Dienstanbieter her, welcher den Service beherbergt. Die Dienstleistung wird vollstndig in der JVM des a Anbieters ausgefhrt u 3. remote (andere JVM) Der Proxy kontaktiert andere, besonders geeignete Maschine zum ausfhren des Codes. Diese benden sich meist zwischen Client u und remote Serviceanbieter. 4. Smart Proxy (lokal/remote) Ein Teil der Dienstleistung wird lokal in der JVM des Clients, der verbleibende Teil auf einer entfernten Maschine, ausgefhrt. u Leasing Ein Nachteil von verteilten Systemen ist, dass einzelne Dienste ausfallen knnen o und die Kommunikation zwischen den Komponenten unterbrochen ist. Erfhrt nun a der Lookup - Service nicht vom Ausfall einer Komponente und stellt den Clients
7

Vgl. Mller H.: Integration nicht-Java-fhiger Dienstleister in eine Jini-Infrastruktur, Universitt u a a Hamburg, S. 31-36

60

5 Jini - Java Intelligent Network Interface

weiterhin das Service - Objekt des Dienstes bereit. Erfolgt nun der Versuch des Clients, den nicht vorhandenen Dienst zu nutzen, kommt zu einem Fehler. Um dies zu verhindern, erhlt jeder Dienst bei Registrierung beim Lookup - Service a ein Lease. Ein Lease ist eine Registrierung eines Dienstes fr ein bestimmtes u Zeitfenster. Dieser muss fortlaufend erneuert werden, da der Lookup - Service sonst annimmt, dass der jeweilige Dienst nicht mehr existiert. Ist dies der Fall erfolgt das Lschen des Service - Objekts aus der Dienstliste des Lookup - Service. o Jini ist somit ein selbstheilendes System, da es keine toten Dienste toleriert. Dieses Konzept wird auch Soft State Computing genannt.

5.4

Fazit

Jini ist eine elegante Architektur fr spontane Netzwerke und bietet einige Vorteile. u Es mssen keine Treiber installiert werden, zudem ist Jini ein selbstheilendes u System, da nicht verfgbare Dienste gelscht werden. Weiterhin basiert Jini auf u o Java und ist somit plattformunabhngig. a Jini ist jedoch nicht die einzige Architektur, die Vernetzung von Komponenten im Netzwerk verbessern bzw. vereinfachen soll. Konkurrenzprodukte zu SUNs Jini sind vorhanden. Ein Gegenstck zu Jini ist z.B. das Universal Plug and Play u Konzept von Microsoft. Es hat das gleiche Ziel wie Jini, ist aber plattformabhngig. a Jini ist also nicht die Lsung fr solch ein Szenario aber es ist eine denkbare o u Variante, eine Java - basierte Variante.

5.5 Abbildungen

61

5.5

Abbildungen

Abbildungen
5.1 5.2 5.3 Logo Jini (Wunderlampe) . . . . . . . . . . . . . . . . . Logo Apache River (Apache Software Foundation) . . . . Abbildung Hauptkomponenten einer Jini - Architektur . . 55 56 57

62

5 Jini - Java Intelligent Network Interface

5.6

Quellenverzeichnis

Vgl. Langel J.: Jini und JavaSpaces, Universitt Freiburg (Schweiz), S. 7-12 a Vgl. Sommer P.: Jini - Konzepte von Betriebssystem-Komponenten, Universitt a Erlangen, S. 1-7 Vgl. Keith Edwards W.: Core Jini, Prentice Hall Verlag, Jahr 2000 Vgl. Mller H.: Integration nicht-Java-fhiger Dienstleister in eine Jiniu a Infrastruktur, Universitt Hamburg, S. 31-36 a Vgl. Flanagan D.: Java In A Nutshell, OReilly & Associates, Jahr 1996 Vgl. Jini in Java, Fach Hochschule Wedel, Jahr 1999, http://www.fhwedel.de/ si/seminare/ws99/Ausarbeitung/jini/Jini/Jini3.html Vgl. What is Jini? River http://wiki.apache.org/river/JiniOrgWiki Wiki JiniOrgWiki,

ownCloud
6.1 6.2 6.3 6.4 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . Installation . . . . . . . . . . . . . . . . . . . . . . . . . WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . Vorstellung der Dienste fr PC . . . . . . . . . . . . . . . u 6.4.1 Dateien . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Musik . . . . . . . . . . . . . . . . . . . . . . . . 6.4.3 Bilder . . . . . . . . . . . . . . . . . . . . . . . . 6.4.4 Kontakte . . . . . . . . . . . . . . . . . . . . . . 6.4.5 Kalender & Aufgaben . . . . . . . . . . . . . . . 6.4.6 Einstellungen . . . . . . . . . . . . . . . . . . . . ownCloud & Android . . . . . . . . . . . . . . . . . . . . 6.5.1 Dateien . . . . . . . . . . . . . . . . . . . . . . . 6.5.2 Musik . . . . . . . . . . . . . . . . . . . . . . . . 6.5.3 Kontakte . . . . . . . . . . . . . . . . . . . . . . 6.5.4 Kalender . . . . . . . . . . . . . . . . . . . . . . Erweiterung von ownCloud . . . . . . . . . . . . . . . . . Integration in die Systemlandschaft der FH-Schmalkalden Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 64 65 67 67 69 70 71 71 72 72 72 72 73 73 73 74 74

Fabian Markert

Inhaltsverzeichnis

6.5

6.6 6.7 6.8

6.1

Einleitung

Das Projekt ownCloud wurde im Januar 2010 vom KDE-Entwickler Frank Karlitschek gestartet. Ziel des Projektes ist es eine freie Alternative zu kommerziellen Cloud-Anbietern zu schaen. Es benutzt PHP in Verbindung mit einer SQLite, MySQL oder einer PostgreSQL - Datenbank, daher kann es auf jeder Plattform eingesetzt werden, die diese Voraussetzungen erfllen. Die Anwendung steht unter u der Aero GPL 3.0. Es existieren zwar bereits einige kostenlose Cloud-Dienste wie beispielsweise Dropbox oder Google-Kalender, bei diesen besteht allerdings der Nachteil, dass der

64

6 ownCloud

Nutzer seine Daten einem Drittanbieter anvertrauen muss. Daraus ergibt sich die Ungewissheit, dass jemand Missbrauch mit diesen Daten betreiben kann. Bei ownCloud darf jeder seine eigene Wolke mit eigenen Servern bauen, somit entfallen diese Bedenken. Diese Ausarbeitung stellt ownCloud anhand einer eigenen Konguration mit ausgewhlten Features vor und testet deren Alltagsbetrieb. Im Einzelnen geht es a um folgende Funktionalitten: a Dateizugri Musikstreaming, Kontaktmanagement Integration in Android Erweiterung der Cloud LDAP - Anbindung fr eine mgliche Integration in die Systemlandschaft der u o FH - Schmalkalden In dieser Ausarbeitung wird zur Veranschaulichung eine eigene ownCloudInstanz auf einem Linux Server verwendet. Der Zugri auf diese erfolgt uber Windows 7, Linux (Kernel 3.4) sowie Android 2.3.7. Als Browser werden Internet Explorer 9, Firefox 13 und Chromium 20 verwendet. Auf den Betriebssystemen wird ausschlielich kostenfreie Software betrachtet.

6.2

Installation

Installationsvoraussetzung fr ownCloud ist ein Webserver wie beispielsweise u apache2, PHP5 sowie eine SQL-Datenbank erforderlich[1]. Auf Debian-Artigen Systemen werden mit den folgenden Befehlen smtliche Abhngigkeiten automaa a tisch installiert:
Listing 6.1: Installation aller notwendigen Pakete auf Debian Systemen [1]
aptget i n s t a l l apache2 php5 php5json phpxml \ phpmbstring php5zip php5gd aptget i n s t a l l php5s q l i t e c u r l \ l i b c u r l 3 l i b c u r l 3dev php5c u r l phppdo

Die ownCloud-Installation erfolgt uber ein Archiv, welches von der Adresse http://owncloud.org/install/ heruntergeladen werden kann. Danach wird es in den Webordner entpackt (beispielsweise /var/www/owncloud). Dieser muss dem apache-user durch chown R wwwdata:wwwdata /pfad/zu/owncloud/ zugnglich gemacht a

6.3 WebDAV

65

werden. Als letzter Schritt muss der Webserver nun uber den Browser angesprochen werden, ein Screenshot ist in Abbildung 6.1 zu sehen. Dort ndet der Nutzer einen sehr einfachen Einrichtungsassistenten. Es muss lediglich die Datenbankanbindung, der Pfad zum Speichern der Einstellungen und ein Administrator eingerichtet werden.

Abbildung 6.1: Einrichtungsassistent von ownCloud bei der Installation.

Fr diese Ausarbeitung wird ein Sabayon Linux 8 1 verwendet, ein Gentoo-basiertes u System, da ownCloud direkt uber dessen Paketverwaltung Portage installiert werden kann. Als USE ag kann hierbei auch die bentigte Datenbank angegeben o werden; in der aktuellen Betrachtung ist es SQLite3. Anschlieend geht es an die Konguration des Servers. In der Datei /etc/conf.d/apache2 mssen bei u APACHE2 OPTS die Parameter -D DAV -D PHP5 ergnzt werden. a
h localhost owncloud 4.0.0.

Die Bereitstellung auf dem Server erfolgt uber das Kommando webappcong I Der Parameter -I steht fr die Aktion Install, -h gibt den u host an, auf dem eine Webanwendung installiert werden soll. Die letzten beiden Parameter spezizieren, 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 fr Web-based Distributed Authoring u and Versioning. Es ist ein oener Standard, an dessen Arbeit im Jahr 1996 begonnen wurde. Das Protokoll stellt eine Erweiterung des HTTP - Protokolls dar und ist speziell fr den Datenaustausch uber das WorldWideWeb entwickelt worden u
1

http://sabayon.org/

66

6 ownCloud

[3]. Mittlerweile existieren fr die verbreiteten Betriebssysteme (einschlielich fr u u mobile Endgerte) Implementierungen, welche den Zugri auf WebDAV - Freigaben a mit Hilfe eines Dateiexplorers ermglichen. o Da HTTP die Basis fr diesen Standard ist, wird keine zustzliche Portfreigabe fr u a u Firewalls bentigt. Ein WebDAV - Server kann mit einem normalen HTTP -Server o betrieben werden. Dadurch ist es fr Portscanner auch nicht so oensichtlich wie u eine Windows- oder Samba-Freigabe, was einen Vorteil fr die Sicherheit und den u Administrationsaufwand darstellt. WebDAV erweitert das HTTP Protokoll um folgende Kommandos:
HTTPMethode PROPFIND PROPPATCH MKCOL COPY MOVE DELETE Beschreibung erfragt die Eigenschaften einer Datei im XML - Format, kann ebenfalls Auskunft uber die Verzeichnisstruktur des entfernten Systems geben dient dem Bearbeiten von Eigenschaften einer Ressource erstellt eine Collection (Verzeichnis) kopiert eine Ressource verschiebt eine Ressource lscht eine Ressource o der Webserver wird angewiesen, eine Ressource zu sperren, die Ressource kann in diesem Zustand nur vom aktuell genutzten Client bearbeitet werden Entfernt eine Sperre wieder

LOCK

UNLOCK

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 Standards, wodurch sich ltere Dateien wiederherstellen lassen [13]. a

6.4 Vorstellung der Dienste fr PC u

67

6.4

Vorstellung der Dienste fr PC u

Direkt nach der Einrichtung prsentiert ownCloud dem Nutzer sein Webinterface. a Die Plugins fr Dateizugri, Musik, Kontakte, Kalender und Galerie sind stanu dardmig aktiviert zu sehen in Abbildung 6.2. Im linken unteren Bereich sind a die Einstellungen zu nden. An dieser Stelle nden sich ebenfalls Links, um auf die einzelnen Dienste mit externen Programmen zugreifen zu knnen. Im nachfolgeno den Abschnitt wird auf die einzelnen Funktionen und Einstellungsmglichkeiten o nher eingegangen. a

Abbildung 6.2: Webinterface direkt nach der Einrichtung.

6.4.1

Dateien

Dateizugrie knnen auf mehrere Arten bewerkstelligt werden. Die erste Variante o ist die uber den Browser. Mit dem Webinterface knnen Textdokumente und Ordner o direkt angelegt werden. Per Drag & Drop knnen Daten direkt hochgeladen werden. o Es ist ebenfalls mglich PDF, Open Document Format sowie diverse Bildformate o dort zu betrachten. Des weiteren kann der Nutzer Dateien herunterladen. Das Interface gestattet die Freigabe von Dateien und Ordnern. Diese kann entweder fr einzelne Benutzer oder fr Nutzergruppen geschehen. Darber hinaus kann u u u eingestellt werden, ob andere Nutzer diese bearbeiten drfen oder nicht. Es fehlt u allerdings eine Anzeige, welche dem Anwender signalisiert, dass es sich um eine Freigabe handelt und welche Zugrisrechte er besitzt. Eine weitere Mglichkeit auf Dateien zuzugreifen ist mittels des eigenen Synco Clients Mirall. Dieser kann von der Projektseite heruntergeladen werden und ist

68

6 ownCloud

ebenfalls Open Source und fr Windows, Mac sowie Linux verfgbar.2 Nach der u u Installation erwartet der Client die Adresse und die Zugangsdaten des Servers. Es ist nicht mglich mehrere Server mit einem Client abzurufen. Der Nutzer kann o selbst entscheiden, welche Ordner vom Server mit welchen lokalen Verzeichnissen synchronisiert werden sollen. Zum Synchronisieren wird csync verwendet. 3 Das Verhalten der Anwendung erinnert an Dropbox oder hnliche Dienste und a funktioniert auf allen getesteten Desktop-Betriebssystemen gleichermaen gut. Im Tray-Bereich erscheint ein Symbol des Clients, welches den Nutzer uber Syn chronisationsvorgnge informiert. Es el auf, dass der Server die Synchronisation a blockierte, wenn die Systemzeiten der beteiligten Rechner zu stark voneinander abweichen. Als letzte Mglichkeit bietet ownCloud WebDAV zum Dateizugri an. Der Standard o ist auf allen Betriebssystemen bereits implementiert. Im Falle von Linux ist es mglich die Freigabe per mount-Befehl zu erreichen. 4 Wesentlich komfortabler o gestaltet sich der Zugri uber die Desktopumgebungen. So bieten KDE und Gnome Assistenten an, welche das Einbinden erlauben ohne auf root-Rechte zurckgreifen u zu mssen zu sehen in Abbildung 6.3. u

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 betrit lediglich Windows 7, auf XP und Vista funktioniert die Einbindung laut Projektseite ohne Probleme. Dort bendet sich ebenfalls eine Anleitung, um besagten Fehler zu beseitigen. Im persnlichen Test konnte diese o Anleitung nicht nachvollzogen werden. Eine Alternative stellt die Software NetDrive dar. Dabei handelt es sich um eine Freeware-Anwendung, welche dazu dient FTP-

http://owncloud.org/sync-clients/ http://www.csync.org/ 4 http://owncloud.org/support/webdav/

3

6.4 Vorstellung der Dienste fr PC u

69

und WebDAV-Freigaben als Netzwerklaufwerke einzubinden. 5 Die Bedienung ist dabei hnlich komfortabel wie der Assistent von Nautilus. a Uber WebDAV eingebundene Verzeichnisse benden sich direkt auf dem Server. Daten werden daher direkt bearbeitet. Anders als beim Sync-Client bemerkt der Nutzer Anderungen an enthaltenen Inhalten nicht unmittelbar, sondern erst bei erneutem Erfragen des Inhaltes. Die meisten Anwendungen haben keine Probleme mit dieser Art des Dateizugris und verhalten sich so, als wren es lokale Dateien. a In einigen Fllen strzen diese jedoch ab oder reagieren nicht mehr. Dies ist a u beispielsweise bei Shotwell, einem Bildbetrachter fr Linux, der Fall. u

6.4.2

Musik

Das Webinterface beinhaltet einen Extra-Menpunkt fr Musik. Sofern sich Audiou u dateien im Verzeichnis des Nutzers benden, knnen diese mit dem Button Rescan o Collection erfasst werden. Abbildung 6.4 zeigt diese Ansicht. Darin zu sehen ist eine Ubersicht uber vorhandene Musikstcke. Eventuell vorhandene Titelinformationen u werden ebenfalls eingeblendet. Es ist mglich dort eine Playlist zusammenzustellen o und diese direkt wiederzugeben. Die Wiedergabe wird fortgesetzt, wenn der Nutzer einen anderen Menpunkt betritt. Allerdings unterbricht die Wiedergabe fr die u u Zeit des Neuladens der Seite. Darber hinaus fhrt dies bei Chromium zu Abstrzen. u u u Der verwendete Tab gibt keine Rckmeldung mehr. Dieser Eekt tritt bei keinem u anderen Browser auf.

Abbildung 6.4: Webinterface fr Musikwiedergabe u

Die ownCloud bietet eine weitere Mglichkeit Musikdaten zu erreichen. Hierfr o u

5

http://www.netdrive.net/

70

6 ownCloud

wird der MP3-Streaming-Server Ampache verwendet. 6 Dieser kann uber ein externes Programm angesprochen werden. Die Projektseite empelt den Player Tomahawk 7 , welcher fr Windows, Linux und Mac verfgbar ist. Die Einrichtung u u ist sehr einfach, da das Webinterface im Dialog fr persnliche Einstellungen die u o URL prsentiert, welche in die Eingabemaske des Players eingegeben werden muss. a Die serverseitigen Werke werden allerdings nicht in einer Ubersicht prsentiert. a Der Nutzer muss daher genau wissen, welche Musik sich auf dem Server bendet und im Zweifelsfalle uber das Webinterface nachsehen. Sie knnen ausschlielich o uber die Suchfunktion des Players gefunden und abgespielt werden. Fr das Wiedergabeprogramm Banshee existiert ebenfalls ein Ampache-Plugin. u Die Software ist fr Windows, Linux und Mac verfgbar. Die Einrichtung verluft u u a a u hnlich wie bei Tomahawk. Banshee liefert einen extra Menpunkt, uber den eine Ubersicht der Ampache Medien prsentiert wird. Das Plugin ist jedoch nicht a stabil. Gelegentlich strzt die Anwendung beim Anklicken des Menpunktes oder u u whrend der Wiedergabe ab. a

6.4.3

Bilder

In der Weboberche existiert ein Menpunkt, welcher speziell zur Darstellung von a u Bildern gedacht ist. An dieser Stelle werden alle Verzeichnisse mit Bildern angeordnet. Fr die enthaltenen Bilder werden Thumbnails generiert eine Darstellung u ist 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 7

http://ampache.org/ http://www.tomahawk-player.org/

6.4 Vorstellung der Dienste fr PC u

71

werden angezeigt. Beim Anklicken eines Bildes erscheint eine Lightbox in der vollen Gre. Mit Pfeiltasten oder Mausradsteuerung kann zwischen den einzelnen o Lightboxen gewechselt werden.

6.4.4

Kontakte

Uber den Menpunkt Kontakte knnen Adressbcher verwaltet werden. Der Imu o u port von vCard-Dateien ist mglich. Uber das Webinterface knnen Kontakte o o angelegt und bearbeitet werden. Fr externe Programme bietet ownCloud eine u CardDAV Schnittstelle an; einer Erweiterung des WebDAV-Standards. [14] Dadurch ist es beispielsweise mglich Adressdaten mit dem E-Mail-Client Thunderbird8 o zu synchronisieren. Dafr mssen zwei Erweiterungen installiert werden. Dabei u u handelt es sich um SOGo Connector 9 und MoreFunctionsForAddressBook 10 . SOGo Connector ermglicht die Anmeldung uber Webinterfaces. MoreFunctionso ForAddressBook erweitert die Funktionen des Adressbuches unter anderem um die Mglichkeit ein Remote Adressbuch anzulegen. Dazu muss in Thunderbird o das Adressbuch genet und im Menpunkt Datei/Neu der Unterpunkt Remoteo u Adressbuch ausgewhlt werden. Die einzutragende Adresse erfragt der Nutzer in a der Oberche von ownCloud zu sehen in Abbildung 6.6. a

Abbildung 6.6: Im linken Berreich ist die Anzeige von ownCloud zu sehen, welche den Freigabelink des Adressbuches anzeigt. Im rechten Berreich ist die Eingabemaske von Thunderbird zu sehen. Hier wird der Freigabelink eingetragen.

6.4.5

Kalender & Aufgaben

Zu den Standardfunktionen von ownCloud gehrt eine Kalender- und Aufgabenfunko tionalitt. Diese knnen uber den Browser bedient werden. Die Kalenderoberche a o a funktioniert hnlich wie Google-Calendar. Es knnen mehrere Kalender angelegt a o werden. Fr externe Programme wird eine CalDAV-Schnittstelle angeboten. [15] u Damit ist es mglich mit Programmen, wie Thunderbird (mit Lightning) oder o Mozilla Sunbird auf den eigenen Kalender zuzugreifen. Hierzu muss fr den u Kalender der Freigabelink erzeugt werden und im Client Programm eingetragen
http://www.mozilla.org/de/thunderbird/ http://www.sogo.nu/english/downloads/frontends.html 10 http://nic-nac-project.de/ kaosmos/morecols-en.html
9 8

72

6 ownCloud

werden. Fr Programme, die kein CalDAV beherrschen, wird zustzlich noch eine u a iCalendar-Schnittstelle angeboten. [16] Uber das gleiche Protokoll werden auch Aufgaben eingetragen.

6.4.6

Einstellungen

Im unteren Bereich der Weboberche bendet sich ein Zahnradsymbol, wela ches Zugang zu smtlichen Einstellungsdialogen bietet. Hierbei ist es von den a Berechtigungen des aktuellen Nutzers abhngig, welche Einstellungsmglichkeiten a o angezeigt werden. An dieser Stelle sind Links, um die einzelnen Diensten ansprechen zu knnen, aundbar. Administratoren haben die Mglichkeit neue Nutzer o o und Gruppen anzulegen. Fr neue Erweiterungen gibt es einen eigenen App-Store. u Dort werden alle Erweiterungen prsentiert und knnen mit einem Klick installiert a o werden. Negativ fllt hierbei auf, dass Apps aufgefhrt sind, die mit der installierten a u ownCloud-Version nicht kompatibel sind. Die daraus resultierende Fehlermeldung lsst keine Rckschlsse auf den Grund der Installationsverweigerung zu. a u u

6.5

ownCloud & Android

Es existiert bereits eine Android-App fr ownCloud. Diese kann momentan ausu schlielich uber die Projektseite bezogen werden, da sie sich noch in einem frhen u Entwicklungsstadium bendet. Die aktuelle Version 1.0 beschrnkt sich auf den a Dateiup- und -download. Um auf die anderen Dienste zugreifen zu knnen, werden o Apps bentigt, die den jeweiligen Standard untersttzen. Einige davon werden in o u diesem Abschnitt vorgestellt.

6.5.1

Dateien

Mit der App WebDAV Nav lite 11 kann die Dateifreigabe von ownCloud angesprochen werden. Die Einrichtung ist selbsterklrend und verluft problemlos. Es a a knnen einzelne Dateien hoch- und runtergeladen werden. o

6.5.2

Musik

Mit Hilfe der App Just Player 12 in Verbindung mit Ampache Provider 13 ist es mglich den Ampache dienst von ownCloud Anzusprechen. Beide Apps mssen o u dazu installiert werden. In Ampache Provider muss der Anwender die Serverurl
11 http://alturl.com/uoeom 12 http://goo.gl/wr9CT 13 http://goo.gl/xWtNK

6.6 Erweiterung von ownCloud

73

und die Zugangsdaten fr Ampache eingegeben. Anschlieend ist es notwendig, u den Sync Button im unteren Bereich zu bettigen. a Danach muss in Just Player der Menbutton bettigt werden. Anschlieend u a erscheint eine reihe von Buttons. Der Mittlere oenbart verfgbare Datenquellen. u An dieser Stelle ist Ampache auszuwhlen. Daraufhin sind remote Inhalte verfgbar. a u Im persnlichen Test gab es keine Probleme, die Wiedergabe funktionierte fehlerfrei o und ssig. u

6.5.3

Kontakte

Durch die App CardDAV-Sync free beta 14 knnen Kontakte und Adressen syno chronisiert werden. Nach der Installation ist es mglich im Einstellungsmen von o u Android ein neues Synchronisierungskonto hinzuzufgen. Nach dessen Einrichtung u startet die Synchronisation. Mit dieser Anwendung ist es mglich Kontakte ohne o Google-Konto zu verwalten.

6.5.4

Kalender

Zum Zeitpunkt der Fertigstellung dieser Arbeit ist es nicht mglich gewesen eine o Funktionierende kostenfreie App zu testen, welche CalDAV untersttzt. Daher u kann uber diese Funktionalitt keine aussage getroen werden. a

6.6

Erweiterung von ownCloud

Fr den Begri Cloud Computing gibt es noch keine einheitliche Denition. In den u meisten ist von einer Rechnerinfrastruktur die rede, welche fr den Nutzer nach u auen undurchsichtig ist, hnlich einer Wolke. Daher stellt sich die Frage inwiefern a ownCloud diesen Denitionen gerecht wird. In der derzeit aktuellen Version 4.0.4 gibt es keinen Graschen Assistenten um mehrere Instanzen zu verbinden. Dies ist erst fr die Version 5 geplant, deren Verentlichung fr August 2012 vorgesehen u o u ist. 15 Auf der Projektseite existieren bereits Anleitungen um Dateifreigaben aller Art per mountscript einzubinden. Dem Nutzer erscheinen diese Freigaben als normale Verzeichnisse. 16

14 http://goo.gl/qbRLO 15 http://owncloud.org/dev/roadmap/ 16 http://owncloud.org/support/custom-mount-conguration/

74

6 ownCloud

6.7

Integration in die Systemlandschaft der FH-Schmalkalden

Da zum Zeitpunkt der Fertigstellung dieser Ausarbeitung auf dem zur Verfgung u gestellten Testsystem der FH-Schmalkalden kein funktionsfhiger PHP-Server a vorlag, wird an dieser stelle nur ein Theoretisches Konzept genannt. Die Anmeldung auf Diensten der FH-Schmalkalden funktioniert mit einem LDAP-Server. Fr u ownCloud existiert ein entsprechendes LDAP Plugin. Nach dessen Installation und Konguration ist es einem Nutzer mglich, sich mit seiner FHS-ID anzumelden. o Mit Hilfe eines Mount Scripts kann das Home-, das PUB- sowie das Free-Laufwerk mittels Samba uber ownCloud erreicht werden. Da die Passwrter von den einzelnen o Diensten unterschiedlich verschlsselt ubertragen werden ist es nicht mglich diese u o einfach an Samba durchzureichen. Eine Lsung hierfr bieten fr jeden Nutzer o u u individuelle SSH-Keys welche Serverinternen fr die Authentizierung anstelle von u Passwrtern eingesetzt werden. Danach ist die Konguration abgeschlossen. o

6.8

Fazit

Die ownCloud bietet Privatanwendern die Mglichkeit, unabhngig von Kommerzio a ellen anbiedern die selben Dienste zu Nutzen ohne ihre Daten an diese weitergeben zu mssen. Die Einrichtung ist mit geringen Arbeitsaufwand bewerkstelligt und u die Bedienung ist Intuitiv. Durch den App-Store ist es darber hinaus sehr leicht, u die eigene Instanz um neue Funktionen zu erweitern. Man merkt dem Projekt an einigen stellen allerdings an, dass es noch nicht ganz ausgereift ist. Insgesamt bendet sich ownCloud jedoch auf einem guten Weg. Die Nutzung der verschiedenen Diensten mit Desktop-Betriebssystemen ist ohne greren aufwand mglich. Fr mobile Endgerte mangelt es noch an Apps um o o u a alle Dienste nutzen zu knnen. o Alles in allem ist ownCloud eine gute alternative zu aktuellen Cloud Anbietern. Fr u interessierte bietet ownCloud auf der Projektseite eine Demoinstanz zum Testen an.

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. 2005, ch. WEBAPP-CONFIG(8). Gentoo Linux,

[3] J. Whitehead, Proposed agenda for san mateo meeting, Website, Jun 1996. [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 a Distributed 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, HTTP Extensions for Distributed Authoring WEBDAV, RFC 2518 (Proposed Standard), Internet Engineering Task Force, Feb. 1999, obsoleted by RFC 4918. [Online]. Available: http://www.ietf.org/rfc/rfc2518.txt [6] G. Clemm, J. Amsden, T. Ellison, C. Kaler, and J. Whitehead, Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning), RFC 3253 (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 and Versioning (WebDAV) Ordered Collections Protocol, RFC 3648 (Proposed Standard), 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 Distributed Authoring 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 Task Force, Dec. 2005. [Online]. Available: http://www.ietf.org/rfc/rfc4316.txt [10] B. Korver and L. Dusseault, Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections, RFC 4331 (Proposed Standard), 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 Authoring and 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 Authoring and Versioning (WebDAV), RFC 4918 (Proposed Standard), Internet Engineering 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 Task Force, Sep. 2009. [Online]. Available: http://www.ietf.org/rfc/rfc5689.txt [14] , CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV), RFC 6352 (Proposed Standard), Internet Engineering Task Force, Aug. 2011. [Online]. Available: http://www.ietf.org/rfc/rfc6352. txt [15] C. Daboo, B. Desruisseaux, and L. Dusseault, Calendaring Extensions to WebDAV (CalDAV), RFC 4791 (Proposed Standard), Internet Engineering Task Force, Mar. 2007, updated by RFC 5689. [Online]. Available: http://www.ietf.org/rfc/rfc4791.txt [16] B. Desruisseaux, Internet Calendaring and Scheduling Core Object Specication (iCalendar), RFC 5545 (Proposed Standard), Internet Engineering Task Force, Sep. 2009, updated by RFC 5546. [Online]. Available: http://www.ietf.org/rfc/rfc5545.txt

Orc
7.1 7.2 7.3 Orc Denition . . . . . . . . . Anwendungsbereiche . . . . . Orc-Syntax . . . . . . . . . . 7.3.1 Seitenaufrufe . . . . . 7.3.2 Kombinatoren . . . . 7.3.3 Denitionen . . . . . 7.3.4 Time/Timer . . . . . Cor-Snytax . . . . . . . . . . 7.4.1 Konstanten . . . . . . 7.4.2 Bedingungen . . . . . 7.4.3 Variablen . . . . . . . 7.4.4 Datenstrukturen . . . 7.4.5 Muster . . . . . . . . 7.4.6 Funktionen . . . . . . Kombination von Orc und Cor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 78 78 78 79 80 80 81 81 81 81 81 82 82 82

Stephan Stenzel

Inhaltsverzeichnis

7.4

7.5

7.1

Orc Denition

Orc ist eine neuartige Sprache fr die verteilte und simultane/nebenlugen u a (gleichzeitige) Programmierung, welche einen einheitlichen Zugri auf rechnerische Dienste, inklusive der verteilten Kommunikation und Datenmanipulation, uber Seiten bereitstellt. Mit nur vier simplen simultanen Primitiven, instrumentiert der Programmierer den Aufruf vonseiten um ein Ziel zu erzielen, whrend er Timeouts, a Prioritten und Fehler regelt. Orc selbst besteht insgesamt zwei Teilen. Dem a simplen Orc-Kalkl und der Cor-Sprache. Zusammen bilden sie die vollstndige u a Orc-Programmiersprache.

78

7 Orc

7.2

Anwendungsbereiche

Orc sich vor allem fr den Einsatz als sogenannte General Purpose Language (GPL) u an. Eine GPL zeichnet sich dadurch aus das Sie fr so gut wie alle Anwendungsflle u a und Problemstellungen einsetzbar ist. Dies bietet dem Programmierer ein hohes Ma an Freiheit wie Probleme gelst werden knnen. Auerdem kann bereits o o bekanntes Wissen erneut eingesetzt werden. Allerdings gibt es beim Einsatz von Orc als GPL einige Nachteile. Zum einen mssen alle Problemstellungen zunchst u a in Orc-Syntax ubersetzt werden. Dies kann zu Problemen fhren sollten sich u mehrere Fachgebiete uberschneiden. Desweiteren kann Orc als Webskriptsprache eingesetzt werden, da sie die einfache und schnelle Erstellung von Webseiten beziehungsweise Webnetzen ermglicht. o Eine weitere Anwendungsmglichkeit ist es Orc als ausfhrbare Spezikationssprao u che, beispielweise fr sequenzielle Arbeitsablufe, einzusetzen. u a

7.3
7.3.1

Orc-Syntax
Seitenaufrufe

Seitenaufruf ist die simpelste Art eines Orc-Ausdrucks. Ein Seitenaufruf im OrcSyntax ist eigentlich der Aufruf einer Funktion, welche mit einem Services verknpft u ist. Der Allgemeine Aufbau eines Seitenaufrufs ist M(p). M steht hierbei fr den u Seitennamen und p fr die Liste von Parametern, die der Seite ubergeben werden u sollen. Bei einer Ausfhrung von M(p) wird der entsprechende Service M aufgerufen u und diesem die Parameter p geschickt. Der Service hat nach dem Aufruf Zeit zu antworten. Die zurckgegebene Antwort wird anschlieend ausgegeben. u Beispiele fr Seitenaufrufe: u 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 Aufruf zugeben. Eine Antwort kann das Ergebnis des Aufrufs beinhalten oder die Information enthalten des der Seitenaufruf nie eine Antwort zurckliefern wird. Sollte u ein solcher Ausdruck empfangen werden, gilt der entsprechende Seitenaufruf als unterbrochen. Der hier beschriebene Orc-Syntax hat selbst keine vordenierten Seiten. Allerdings wurde von den Entwicklern wichtige Seiten eingefgt, die zum u Erstellen von funktionalen Programmen notwendig sind. Zum einen wurde eine Identittsseite (let) eingefgt welche bei Aufruf mit einem einzelnen Parameter a u diesen zurckliefert. Aber bei Aufruf mit mehreren Parametern diese als ein Tupel u

7.3 Orc-Syntax

79

zurckgibt. Zum anderen eine Bedingungsseite (if), die bei Aufruf mit einem u Signal (ein Wert der keine Informationen enthlt) antwortet wenn das ubergebene a Argument wahr (true) ist. Ansonsten wird mit falsch (false) geantwortet.

7.3.2

Kombinatoren

Der Orc-Syntax bietet vier unterschiedliche Kombinatoren (Combinators) zum Kombinieren von Orc-Ausdrcken. Die Kombinatoren selbst besitzen unterschiedu liche Prioritten in ihrer Ausfhrung. Nachfolgend werden alle Kombinatoren a u beschrieben in der Reihenfolge ihrer Prioritten beginnend mit der Hchsten. Der a o Aufbau eines Kombinatorausdrucks wird durch zwei Ausdrcke ( F & G ) und den u entsprechenden Kombinator dargestellt. x, , x, ; Paralleler Kombinator Der parallele Kombinator wird in Orc mit dem Zeichen dargestellt. Er wird dazu verwendet zwei Orc-Ausdrcke miteinander zu kombinieren und gleichzeitig u auszufhren. Ein Beispiel wre die Kombination der Seitenaufrufe add(2,3) u a add(4,5). Die beiden Seitenaufrufe mit dem Namen add addieren ihre Parameter miteinander und geben unabhngig voneinander ihre Ergebnisse aus. Der erste a Seitenaufruf liefert den Wert 5, der Zweite den Wert 9 zurck. Beide Ausdrcke weru u den gleichzeitig (parallel) aufgerufen. Eine direkte Interaktion oder Kommunikation zwischen den Seitenaufrufen ndet jedoch nicht statt. Sequenzieller Kombinator Der sequenzielle Kombinator wird durch die Zeichenkombination x dargestellt. Das x steht hierbei fr eine Variable. Der Variablenname muss nicht x lauten, u sondern kann frei gewhlt werden. Der sequenzielle Kombinator wird benutzt a um Orc Ausdrcke voneinander abhngig zu machen. Das heit der Ausdruck u a der rechts vom Kombinator steht wird solange an der Ausfhrung gehindert bis u der Variable x, durch den links neben dem Kombinator stehenden Ausdruck, ein Wert zugewiesen wurde. Der Wert, der x zugewiesen wird, entspricht hierbei dem Ausgabewert des linken Ausdrucks. Ein Beispiel dafr ist die Kombination u des Ausdrucks ( CNN(d) BBC(d) ) mit dem Ausdruck email(a,x) zu dem gesamten Orc Ausdruck ( CNN(d) BBC(d) ) x email(a,x). Die Seitenaufrufe CNN und BBC sind durch einen parallelen Kombinator miteinander verknpft u und geben die neusten Nachrichten des Datums d zurck. Sollte ein Wert d u zurckgeliefert werden, wird dieser an die Variable x gebunden und damit der u

80

7 Orc

Seitenaufruf email(a,x) gestartet. Dabei wird die ubergebene Variable x an eine Emailadresse a geschickt. Reduktionskombinator Der Reduktionskombinator wird mittels der Zeichenkombination x ausgefhrt. u Ahnlich wie bei einem parallelen Kombinator werden beide Ausdrcke rechts und u links neben dem Kombinator gleichzeitig ausgefhrt. Allerdings werden Teile des u linken Ausdrucks die die Variable x als Parameter verwenden solange vor der Ausfhrung gestoppt bis durch den rechten Ausdruck x ein Wert zugewiesen wurde. u Sollte durch den Rechten Ausdruck ein Wert zurckgegeben werden, wird dieser an u x gebunden und alle unausgefhrten Teile des linken Ausdrucks werden ausgefhrt. u u Beispiel: email(a,x) x ( CNN(d) BBC(d) ) Sonst Kombinator Dargestellt wird der Sonstkombinator durch das Semikolon (;). Werden zwei Ausdrcke mit dem Sonstkombinator kombiniert ( F ; G ) wird F als erstes u ausgefhrt und G muss warten. Sollte F keine Werte ausgeben oder gestoppt u worden sein so wird G ausgefhrt. Der Ausdruck F gilt dann als angehalten wenn u alle Seitenaufrufe von F geantwortet haben, F nie wieder andere Seitenaufrufe durchfhrt oder F keine Werte mehr ausgibt. Beispiel: ( CNN(d) ; BBC(d) ) x u email(a,x)

7.3.3

Denitionen

Einem Orc-Ausdruck kann eine Sequenz von Denitionen vorangestellt sein. Der Beginn einer Denition wird durch das Wort def gekennzeichnet. Der Allgemeine Aufbau einer Orc-Deniton sieht folgender maen aus: def E(x) F. Das E steht fr den Funktionsnamen, das x beschreibt die formalen Parameter und F den u Funktionskrper. Bei einem Aufruf von E(p) werden die formalen Parameter x o im Funktionskrper F durch die wirklichen Parameter p ersetzt. Im Gegensatz zu o einem Seitenaufruf kann ein Funktionsaufruf mehr als nur einen Wert ausgeben und zustzlich rekursiv sein. a

7.3.4

Time/Timer

Da Orc hauptschlich mit externen Services kommuniziert muss eine Funktion bea reitgestellt werden, um auf Timeouts durch nicht antwortende Dienste zu reagieren. Mit der Funktion Rtimer(t) wird nach dem Aufruf genau t Millisekunden spter a mit einem Signal geantwortet. Mgliche Anwendungen wren wie bereits genannt o a das 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
7.4.1

Cor-Snytax
Konstanten

Der Cor-Syntax stellt insgesamt nur drei Konstanten zur Verfgung. Als Erstes u Nummern, sowohl Ganze-, Fliekomma- und negative Zahlen. Als Zweites Zeichenketten sogenannte Strings wie orc oder Verteilte Systeme. Und als Drittes Wahrheitswerte (boolische Werte) die entweder wahr (true) oder falsch (false) sein knnen. o

7.4.2

Bedingungen

Die einzige Bedingung die der Cor-Syntax bereitstellt ist die IF-Bedingung. Allgemein kann man die IF-Bedingung mit folgendem Aufbau beschreiben. IF E then F else G Diese Bedingung reagiert mit der Ausfhrung der Funktion F, wenn der Ausdruck u E wahr sein sollte. Sollte E jedoch falsch als Antwort zurck liefern, wird statt F u die Funktion G ausgefhrt. u

7.4.3

Variablen

Variablen werden im Cor-Syntax der Ausdruck val vorangestellt, um sie als Variablen zu kennzeichnen. In Cor sollten Variablen nur einmal einen Wert zugewiesen bekommen. Sollte zur Laufzeit der Wert einer Variable gendert werden, kann a dies zu Fehlern bei der Ausfhrung kommen. Bei einem neu zugewiesenen Wert u verwenden alle Referenzen die vor der Wertzuweisung auf die Variable verwiesen haben den alten Variablenwert. Alle neuen Referenzen verwenden den neuen Wert. Deswegen sollten Variablen nach einer Wertzuweisung unverndert bleiben. a

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. Wichtig ist es zu nennen, dass alle Datenstrukturen die Ausdrcke enthalten selbst auch u Ausdrcke sind. Das bedeutet, das alle beinhalteten Ausdrcke ausgefhrt werden u u u und das Ergebnis entsprechend als Tupel oder endliche Liste zurckgegeben wird. u Ein Beispiel wre eine endliche Liste [1, 2+3]. Diese beinhaltet den Ausdruck a

82

7 Orc

2+3. Nach der Ausfhrung aller Ausdrcke wird eine endliche Ergebnisliste [1,5] u u ausgegeben. Mit dem Operator : knnen endlichen Listen Werte vorangestellt o werden. So knnte man der Liste [1,5] so den Wert (1+6) voranstellen. o (1+6) : [1,5] Ergebnis: [7,1,5]

7.4.5

Muster

Muster dienen im Cor-Syntax dazu Teile von Datenstrukturen an Variablen zu binden. 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 das Schlsselwort def deniert. Beispiel: def add(x,y) = x+y u

7.5

Kombination von Orc und Cor

Die Orc-Programmiersprache ist die Kombination aus dem nichtsequenziellen Kalkl und der funktionalen Kernsprache. Auerdem stellt das Orc-Paket zustzlich u a noch groe Bibliotheken aus vordenierten Seiten und Funktionen bereit, die die Arbeit des Programmierers erleichtern sollen. Da die funktionale Kernsprache Cor auf dem nichtsequenziellen Kalkl Orc aufbaut kann entsprechend jeder Coru Ausdruck in einen Orc-Ausdruck ubersetzt werden. Bei einer solchen Ubersetzung ist allerdings zu beachten das arithmetische, logische und vergleichende Operatoren direkt in Seitenaufrufe ubersetzt werden und Orc nur einzelne Werte oder Variablen als Argumente der Seitenaufrufe besitzen darf. Das bedeutet, dass verschachtelte Cor-Ausdrcke in logische Kombinationen von Orc-Ausdrcken ubersetzt werden u u mssen. u

Literaturverzeichnis
[1] David Kitchin, Adrian Quark, William Cook, Jayadev Misra: The Orc 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 Concurrent Programming Language. The University of Texas at Austin. http://orc.csres.utexas.edu/papers/Secure-Information-Flow-Orc.pdf 11.6.2012

Literaturverzeichnis

83

[3] OrcWiki. http://orc.csres.utexas.edu/wiki/Wiki.jsp?page=RecentChanges 15.6.2012 [4] Orc Language Project.http://orc.csres.utexas.edu/research.shtml 10.6.2012

84

7 Orc

Scala STM vs. Akka STM

8.1 8.2 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Software TransWas? . . . . . . . . . . . . . . . 8.2.2 Arbeitsweise von STMs . . . . . . . . . . . . . . Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Aufbau einer Transaktion . . . . . . . . . . . . . 8.3.2 Erstellen einer Reference . . . . . . . . . . . . . . 8.3.3 Zugri auf den Wert einer Reference . . . . . . . 8.3.4 Zugri auf den Wert einer Reference uber Funktionen 8.3.5 Single-Operation-Transaktionen . . . . . . . . . . 8.3.6 Blocken von Transaktionen . . . . . . . . . . . . 8.3.7 Alternative Blcke . . . . . . . . . . . . . . . . . o 8.3.8 Transaction Lifecycle Listeners . . . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 85 86 86 87 87 88 88 89 89 90 91 92 93

Marco Wilhelm

Inhaltsverzeichnis

8.3

8.4

8.1

Einleitung

Ein Software Transactional Memory ist kurz gesagt eine Mglichkeit schnell o und unkompliziert verteilte Systeme zu entwickeln. Mittlerweile gibt es einige verschiedene STMs in vielen verschiedenen Programmiersprachen. Obwohl Scala und Akka zwei Programmiersprachen mit den selben Wurzeln sind, entwickeln beide ihr jeweils eigenes STM. In den folgenden Kapiteln wird kurz auf Transactional Memories im Allgemeinen eingegangen. Nach den Grundlagen folgt ein Vergleich der beiden STMs von Scala und Akka.

8.2

Grundlagen

In den Grundlagen wird erklrt, was ein Transactional Memory ist. Es wird kurz auf a die unterschiedlichen Mglichkeiten ein Transactional Memory umzusetzen eingeo

86

8 Scala STM vs. Akka STM

gangen und schlussendlich wird die Arbeitsweise speziell der Software Transactional Memories erlutert. a

8.2.1

Software TransWas?

Um kurz auf die Grundlagen des Themas einzugehen, wird zuerst auf das TM aus STM eingegangen. TM steht fr Transactional Memory zu deutsch transaktionaler u Speicher. Die Idee des transaktionalen Speichers ist relativ neu. Transaktionaler Speicher ist ein Speicherkonzept fr parallele Berechnungseinheiten. Berechnungsu einheiten knnen Threads in einem Prozess, Prozesse auf einer CPU, Prozessorkerne o in 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 Variante. Es gibt mittlerweile eine groe Palette an verschiedenen STMs. Clojure STM, Scala STM und Akka STM sind nur 3 bekannte Vertreter. Im Groen und Ganzen hneln sie sich alle, aber jedes einzelne verfolgt hier und da seine a eigenen Anstze. a Hardware Transactional Memory basieren auf Hardware wie z. B. CPUs oder eigens entwickelten Speicherbauteilen. HTMs sind i. d. R. schneller als STMs. Da sie aber bei weitem nicht so komplexe Rechenvorgnge abarbeiten knnen, a o sind sie noch keine Konkurrenz zu STMs. Hybrid Transactional Memory stellen eine Mischung aus STM und HTM dar. Simple Berechnungen werden durch HTM gelst, whrend komplexere Proo a bleme weiterhin durch STM verarbeitet werden. IBMs Blue Gene/Q arbeitet bereits mit HybridTM. Intels Haswell Chips, die voraussichtlich im 2. Quartal 2013 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 Datenbank zu erstellen. Genauer: sie wandeln den Heap in eine transaktionale Datenstruktur mit begin/commit/rollback-Semantik um. Sie implementieren die ersten 3 Buchstaben des ACID-Paradigmas[1]: Atomaritt bedeutet, dass entweder alle in ihr beinhalteten Schritte durchgefhrt a u werden, oder es wird kein einzelner durchgefhrt. u Konsistenz zu wahren ist eine wichtige Aufgabe. Egal wo die Daten liegen oder von wo auf sie zugegrien wird. Sie mssen nach einer Transaktion in einem u konsistenten Zustand sein.

8.3 Vergleich

87

Isoliertheit garantiert die absolute Trennung der einzelnen Transaktionen voneinander. Bentigt eine Transaktion Zugri auf eine Ressource, so ist sie die o einzige die darauf zugreifen darf. Hier muss natrlich zwischen Lese und u Schreibzugrien unterschieden werden. Die Dauerhaftigkeit macht bei einem chtigen Speicher wie dem RAM natrlich u u keinen Sinn. Ein STM stellt also eine programmiertechnische Mglichkeit, Transaktionen zu o erstellen, sie atomar und isoliert durchzufhren, wobei ein konsistenter Zustand der u Daten garantiert wird. Der Programmierer muss sich weder um commits noch um rollbacks kmmern. Mutexe und Semaphoren generiert der STM automatisch. Der u Programmcode kann durch hohe Lesbarkeit besser verstanden und gewartet werden. Deadlocks werden automatisch verhindert. Der Programmierer kann ezienter arbeiten.

8.3

Vergleich

Im Folgenden wird ein direkter Vergleich der beiden STMs von Scala und Akka angestellt. Hierzu wird Code in Akka und danach Code in Scala mit der selben bzw. vergleichbaren Funktionalitt gezeigt. Nach den Codebeispielen werden diese a erlutert und es wird auf Unterschiede und Gemeinsamkeiten eingegangen. a

8.3.1

Aufbau einer Transaktion

Listing 8.1: Aufbau einer Transaktion in Akka

1 2 3 4 5 6 7 8

import akka.stm._ // implicit val txn = TransactionFactory( // readonly = true) atomic{ // code }

Listing 8.2: Aufbau einer Transaktion in Scala

1 2 3 4 5

import scala.concurent.stm._ atomic{ implicit txn => // code }

Wie in Listing 8.1 und Listing 8.2 zu sehen ist, hnelt sich der Aufbau beider a Transaktionen sehr stark.Mit atomic wird eine Transaktion eingeleitet. In den

88

8 Scala STM vs. Akka STM

geschweiften Klammern wird der atomar auszufhrende Code geschrieben. u In Scala wird zudem unbedingt eine implizite transaction factory bentigt. Ohne o die Codezeile implicit txn => erkennt der Compiler den atomic-Block nicht als solchen und es kann nicht auf Referenzen (siehe 8.3.2) zugegrien werden. Da der Zugri auf Referenzen der Sinn und Zweck von atomic-Blcken ist, wird man o im Fall des Vergessens der transaction factory zwangslug mit Compilerfehlern a uberhuft werden. a

8.3.2

Erstellen einer Reference

Listing 8.3: Erstellen einer Reference in Akka

1 2 3 4 5

// giving an initial value val ref1 = Ref(0) // specifying a type but no initial value (null) val ref2 = Ref[Int]

Listing 8.4: Erstellen einer Reference in Scala

1 2 3 4 5

// giving an initial value val ref1 = Ref(0) // specifying a type with default value val ref2 = Ref.make[String]()

Eine Reference stellt eine Speicherzelle innerhalb des STM dar. Sie wird in Akka und in Scala uber eine Instanz von Ref() deklariert. In die Klammern von Ref() kommt der Wert, den die Reference beinhalten soll. Das kann alles mgliche sein: o Standardtypen wie long, double, char aber auch Maps, Sets usw. Whrend man a in Akka z. B. mit val ref = Ref[Int] eine Reference, in diesem Fall vom Typ int, ohne Wert denieren kann, ist das in Scala so nicht mglich. In Scala besitzt o eine Reference immer einen Wert. Auch wenn es nur ein z. B. mit val ref = Ref.make[int]() generierter Defaultwert ist.

8.3.3

Zugri auf den Wert einer Reference

Listing 8.5: Zugri auf den Wert einer Reference in Akka

1 2 3 4 5 6 7

atomic{ val i = ref1.get } atomic{ ref1.set(5) }

8.3 Vergleich Listing 8.6: Zugri auf den Wert einer Reference in Scala
1 2 3 4 5 6 7 8 9

89

atomic{ implicit txn => val i = ref1.get //oder val j = ref1() } atomic{ implicit txn => ref1.set(5)//oder ref1() = 5 }

In beiden STMs ist es mglich uber die Member-Funktion get() an den Wert o einer Reference zu kommen. Genauso kann man mittels set() den Wert einer Reference ndern. Scalas STM bieten zustzlich eine weitere Mglichkeit. Hier a a o kann man get und set() durch ein Klammerpaar ersetzen und somit eine bessere Lesbarkeit des Quellcodes erreichen.

8.3.4

Zugri auf den Wert einer Reference uber Funktionen

Listing 8.7: Zugri auf den Wert einer Reference uber Funktionen in Akka
1 2 3

atomic{ val k = ref1 alter(_ + 5) }

Listing 8.8: Zugri auf den Wert einer Reference uber Funktionen in Scala
1 2 3 4 5

atomic{ implicit txn => val k = ref1.transform{_ + 5} val pre = ref1.getAndTransform{_ + 100} val post = ref1.transformAndGet{_ + 100} }

In den STMs von Akka und Scala ist es neben get() und set() mglich, den o Wert einer Reference mit Hilfe einer Funktion zu ndern. In Akka funktioniert das a uber alter(). In den Klammern wird die Funktion, die auf den Wert der Reference ausgefhrt werden soll, ubergeben. Scala bietet hierfr die Funktion transform an. u u Des weiteren gibt es die Funktionen getAndTransform sowie transformAndGet. Wie die Namen vermuten lassen, wird bei Ersterem der Wert der Reference als Rckgabewert zurckgegeben, der vor der Anwendung des Funktionsrumpfes in u u ihr gespeichert war. Bei transformAndGet wird zuerst der Funktionsrumpf auf den Wert der Reference angewendet. Als Rckgabewert dient der neu berechnete u Wert.

8.3.5

Single-Operation-Transaktionen
Listing 8.9: Single-Operation-Transaktionen in Akka

90
1 2 3

8 Scala STM vs. Akka STM

def isZero = atomic{ ref1.get == 0 }

Listing 8.10: Single-Operation-Transaktionen in Scala

1 2 3 4 5

// def isZero = atomic{ implicit txn => // ref1() == 0 // } def isZero = ref1.single() == 0

Whrend man in Akka nur innerhalb eines atomicBlocks auf References zugreifen a kann, bietet Scala eine weitere Mglichkeit. Durch den Aufruf ref.single() o bekommt man ein View-Objekt auf die Reference zurckgegeben. Das View-Objekt u verhlt sich nicht anders als eine Reference, auer dass man es auch auerhalb eines a atomicBlocks nutzen kann. Das simple zurckgeben des Wertes einer Reference u ist genauso mglich wie das ndern des Wertes uber ref.single().set() und o a ref.single().transform. Neben der besseren Lesbarkeit hat das Verwenden eines einzelnen View-Objektes auch Performancevorteile gegenber einem atomic u Block mit nur einem einzigen Zugri auf eine Reference.

8.3.6

Blocken von Transaktionen

Listing 8.11: Blocken von Transaktionen in Akka

1 2 3 4 5

atomic{ if(ref1.get == 0) retry ref1.set(ref1.get - 1) }

Listing 8.12: Blocken von Transaktionen in Scala

1 2 3 4 5

atomic{ implicit txn => if (ref1() == 0) retry ref1() -= 1 }

Das Blocken von Transaktionen ist ein hilfreiches Feature. Durch das Blocken von Transaktionen kann eine Behandlung von unntigen Exceptions umgangen o werden, indem man diese unntigen Exceptions gar nicht erst auftreten lsst. o a Mit dem Befehl retry kann man eine Transaktion manuell zurckrollen lassen. u Gekoppelt mit einer oder mehreren vorherigen ifAnweisungen kann man komplexe Fehlerabfangstrukturen erstellen. Kommt die fertige Applikation an einem retry an, wird der komplette atomicBlock zurckgerollt. Das STM speichert die u

8.3 Vergleich

91

Abhngigkeiten bzw. die References die fr den retry verantwortlich waren ab. a u Sobald sich der Wert einer der References ndert, wird versucht die Transaktion a erneut durchzufhren. u

8.3.7

Alternative Blcke o
Listing 8.13: Alternative Blcke in Akka o

1 2 3 4 5 6 7 8 9 10

either{ if(ref1.get == 0) retry ref1.set(ref1.get - 1) } orElse{ if(ref2.get == 0) retry ref2.set(ref2.get - 1) }

Listing 8.14: Alternative Blcke in Scala o

1 2 3 4 5 6 7 8 9 10

atomic{ implicit txn => if (ref1() == 0) retry ref1() -= 1 } orAtomic{ implicit txn => if (ref2() == 0) retry ref2 -= 1 }

Alternative Blcke knnen als Erweiterung des Blockens von Transaktionen 8.3.6 o o gesehen werden. Als alternative Blcke werden mehrere Transaktionen bezeicho net, die stellvertretend freinander durchgefhrt werden knnen. In Akkas STM u u o wird hierzu der eigentliche atomicBlock zu einem eitherBlock. Er stellt die Transaktion dar, die als erstes ausgefhrt werden soll. Sie ist sozusagen der Noru malfall. Sollte die Applikation in diesem Block auf ein retry stoen, wird sie zurckgerollt. Anstatt nun wie beim normalen Blocken von Transaktionen darauf u gewartet wird, dass sich Werte von Referencen ndern, springt die Applikation a in eine alternative Transaktion. Diese wird in Akka mit orElse gekennzeichnet. Sollte diese Transaktion, ohne auf ein weiteres retry zu stoen, durchlaufen, gilt die Transaktion als abgeschlossen. Es knnen in diesem Verfahren beliebig viele o weitere orElseBlcke angefgt werden. In dem Fall, dass keiner der alternativen o u Blcke fehlerfrei durchlaufen werden konnte, rollt der STM alles zurck, springt o u wieder zur Normalfall-Transaktion zurck und wartet auf Anderungen an den u Werten der beteiligten References. Der einzige Unterschied von Scala STM zu Akka STM ist in diesem Fall die Bezeichnung der Transaktionsblcke. Scalas o

92

8 Scala STM vs. Akka STM

Normalfall-Transaktion bleibt dem Namen atomic treu, whrend die alternativen a Blcke den Bezeichner orAtomic tragen. o

8.3.8

Transaction Lifecycle Listeners

Listing 8.15: Transaction Lifecycle Listeners in Akka

1 2 3 4 5 6 7 8 9 10 11 12 13

atomic{ deferred(new Runnable() { public void run(){ // runs after commit } }); compensating(new Runnable(){ public void run(){ //runs after rollback } }); // transaction code here }

Listing 8.16: Transaction Lifecycle Listeners in Scala

1 2 3 4 5 6 7 8 9 10 11 12

atomic{implicit txn => txn.afterCommit{ // runs after commit } txn.afterRollback{ // runs after rollback } txn.afterCompletion{ // runs after commit and rollback } // transaction code here }

Wie bei vielen anderen Funktionen und Programmen muss man auch nach Transaktionen eventuell etwas aufrumen. Fr diesen Fall stellen Scala und Akka a u verschiedene Funktionen bereit. In Akka sind das deferred und compensating. Die Funktionen werden einfach in den atomicBlock geschrieben. Der Code innerhalb von deferred wird ausgefhrt, sobald die Transaktion erfolgreich durchu gefhrt, also commited wurde. Dagegen wird der Code in compensating bei u einem Rollback der Transaktion ausgefhrt. In Scala sind die Funktionen Memu ber der transaction factory. Code, der nach einem commit ausgefhrt werden u soll, muss in txn.afterCommit geschrieben werden. In txn.afterRollback kommt der Code fr den Fall eines Rollbacks. Zustzlich bietet Scalas STM mit u a txn.afterCompletion einen Codeblock an, der immer am Ende der Transaktion ausgefhrt wird. Ganz egal ob diese erfolgreich durchgefhrt werden konnte, oder u u ob ein Rollback ntig war. o

8.4 Fazit

93

8.4

Fazit

Die beiden STMs von Scala und Akka hneln sich sehr in ihrer Syntax und a Arbeitsweise. Dennoch ist die Scala STM-Syntax z. B. durch die kurze Schreibweise von ref() anstatt von set() und get() besser lesbar. Vom Funktionsumfang sind beide nahezu gleich auf. Zum Zeitpunkt der Erstellung dieses Textes kam das STM von Scala jedoch noch nicht ganz an das Akka STM heran. Das wird sich jedoch in Krze ndern. Schliesslich sitzt einer der groen Kpfe des Akka u a o Projektes Jonas Bonr auch im Entwicklerteam des Scala STM. In der Scala e STM Expert Group sitzen auerdem viele weitere Experten zum Thema STM. Nicht zuletzt deshalb, haben sie es sich zum Ziel gesetzt, dass das Scala STM in die Scala Standard Library aufgenommen wird. Dieses Ziel ist bald erreicht. Somit wird das STM von Akka uberssig, da Akka per Denition nur eine Erweiterung u zu Scala darstellen soll. In weiser Voraussicht hat Typesafe die Entwickler von Akka die Weiterentwicklung ihres STMs gestoppt. Seit Akka 2.0 wird somit nur noch das Scala STM untersttzt. u

Literaturverzeichnis
[1] Typesafe Inc, Akka Documentation Release http://doc.akka.io/docs/akka/1.3.1/Akka.pdf, 19.06.2012. 1.3.1

[2] Nathan Bronson, Scala STM LibraryBased Software Transactional Memory http://nbronson.github.com/scala-stm/index.html, 19.06.2012.

94

8 Scala STM vs. Akka STM

Swarm
9.1 9.2 SWARM - allgemein . . . . . . . . . . . Cloud Computing . . . . . . . . . . . . . 9.2.1 Denition . . . . . . . . . . . . . 9.2.2 Platform-as-a-Service (PaaS) . . SWARM - im Detail . . . . . . . . . . . SWARM - Demos . . . . . . . . . . . . . 9.4.1 Demo 1 - ForceRemoteRef.scala 9.4.2 Demo 2 - ExplicitMoveTo1.scala Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 . 96 . 96 . 98 . 98 . 103 . 103 . 104 . 105

Marie-Christin Reusche

Inhaltsverzeichnis

9.3 9.4

9.5

9.1

SWARM - allgemein

SWARM ist ein Open-Source-Framework fr Berechnungen in der Cloud und geht u dem Grundgedanken move the computation, not the data[4] nach. Das bedeutet, dass sich die auf einem Computer anstehenden Berechnungen bewegen sollen und nicht die dafr bentigten Daten. u o Mit diesem Hintergrund entwickelte ein aus Irland stammender Informatiker und Entwickler Ian Clarke dieses Framework. Es wurde von ihm im September 2009 in den USA bei der IEEE Ninth International Conference on Peer-to-Peer Computing in Seattle vorgestellt.1 SWARM befand sich bei dieser Vorstellung - wie auch heute immer noch - in der Proof of Concept-Phase. Das bedeutet, dass das Framework ein entwickelter Prototyp ist, der alle bentigten o Kernfunktionalitten beinhaltet. Das Framework wurde in der Scala-Version 2.8 a implementiert.
1

Vgl. [5]

96

9 Swarm

Auf der Homepage von SWARM wird das Framework der Kategorie Platform-as-aService des Cloud Computings zugeordnet. Was dies bedeutet, wird im Kapitel 9.2 nher erlutert. a a

9.2

Cloud Computing

In diesem Kapitel soll aufgezeigt werden, was unter dem Begri Cloud Computing sowie Platform-as-a-Service zu verstehen ist.

9.2.1

Denition

Dieser Begri setzt sich aus zwei Wrtern zusammen, die im Folgenden einzeln o betrachtet und am Ende im Zusammenhang dargestellt werden. Cloud ist ein englischer Begri und bedeutet im Deutschen die Wolke. Diese Wolke soll fr das Internet stehen, in der alle ausgelagerten Dienste u dargestellt werden knnen. o Computing stammt ebenfalls aus dem englischsprachigen Raum und wird im Deutschen als die Aktivitt der Nutzung und Verbesserung von Hard- und a Software gesehen.
Abbildung 9.1: Die Rechnerwolke2

9.2 Cloud Computing

97

Das Cloud Computing kann daher mit dem Begri Rechnerwolke in Verbindung gebracht werden, welcher in Abbildung 9.1 dargestellt ist. Somit werden IT-Leistungen uber das Internet oder innerhalb eines Netzwerkes einer Firma in Echtzeit bereitgestellt und nach deren Nutzung abgerechnet. Beispiele fr IT-Leistungen knnen sein: Software, Plattformen fr Entwicklungen sowie u o u Speicherplatz 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 Realisierung umgesetzt werden soll. Auf die Arten von Cloud Computing wird in diesem Artikel nicht weiter eingegangen, da sie fr SWARM eher unbedeutend sind. u Die technischen Realisierungen werden heute auch als Kategorien des Cloud Computings bezeichnet.4 Die folgenden drei Kategorien werden in Abbildung 9.2 aufgegrien 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-asa-Service nher beleuchtet. a
Quelle: [8]. Vgl. [6] 4 Vgl. [2] 5 Quelle: [2].
3 2

98

9 Swarm

9.2.2

Platform-as-a-Service (PaaS)

Da SWARM ein Framework fr Berechnungen in der Cloud ist, muss es sich u um die Kategorie PaaS des Cloud Computings handeln. Dies wird auch auf der Homepage von SWARM dargestellt.6 Beim Ansatz des Platform-as-a-Service wird eine proprietre Laufzeituma gebung von dem Anbieter in der Cloud zur Verfgung gestellt. Der Nutzer u kann so auf einfache Weise seine Software in die Cloud einbringen. Eine auf die Laufzeitumgebung abgestimmte Software kann dadurch bspw. bei der Ausfhrung u frei skaliert werden.7

9.3

SWARM - im Detail

In diesem Kapitel wird das Framework nher vorgestellt. Hier wird zum Beispiel dara auf eingegangen, warum SWARM in Scala geschrieben wurde, wie das Framework funktioniert und was es derzeit noch fr Probleme gibt. u Warum Scala? Scala kann zu Java-Bytecode kompiliert werden und ist somit auf der Java Virtual Machine (JVM) ausfhrbar. Dies bringt einen groen Vorteil mit sich, da die JVM u schnell und weit verbreitet ist. Ein weiterer und vor allem der wichtigste Grund, warum sich Ian Clarke fr Scala entschieden hat, sind die sogenannten portable continuations. Sie sind u seit der Scala Version 2.8 verfgbar. Zum Zeitpunkt der Entwicklung von SWARM u war Scala die einzige Programmiersprache, die diese Funktionalitt untersttzte. a u So bot zum Beispiel Haskell zu dieser Zeit nur die Mglichkeit der einfachen o continuations. portable continuations Die portable continuations kommen aus der funktionalen Programmierung. Um sich vorstellen zu knnen, was darunter zu verstehen ist, soll im Folgenden ein o Beispiel erklren. a Wenn von einer Person ein Computerspiel gespielt wird, mchte diese sio cherlich das Spiel speichern und zu einem spteren Zeitpunkt an der gespeicherten a
6 7

Vgl. [1] Vgl. [2]

9.3 SWARM - im Detail

99

Stelle weiter spielen. Somit kann dann das Computerspiel von jedem beliebigen Ort - also PC - weiter gespielt werden. Im Bezug auf die portable continuations bedeutet es, dass aus dem Programm heraus das Programm eingefroren wird. Das Programm kann dann zum Beispiel an einen anderen PC geschickt, auf eine CD gespeichert 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, weshalb SWARM diese fr den Programmierer auf ein einfaches und verstndliches Niveau u a abstrahiert. Weiterhin msste sich der Programmierer Gedanken machen uber: u Wie gelangen die Daten von A nach B? Welche Daten werden uberhaupt bentigt? o Die Lsung: SWARM o SWARM beschftigt sich mit folgender zentralen Leitfrage: a What if we could distribute data and computation across multiple computers such that the programmer need not think about it?[7] Hier wird der Ansatz der portable continuations aufgegrien, dass sich der Programmierer uber bestimmte Dinge Gedanken machen muss. Das Konzept von SWARM will nmlich genau das Gegenteil erreichen, so dass sich der a Programmierer keine Gedanken mehr machen muss. Er muss nicht mehr wissen, wie alles funktioniert, wenn Daten und Berechnungen auf mehrere Rechner verteilt werden. 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 verteilt werden. Doch bei MapReduce muss der Programmierer selbst herausnden, wie das Problem am Besten zerlegt werden kann. Er muss sich darber Gedanken u machen, welche Lsung die sinnvollste ist. Diese Aufgabe soll das Framework o SWARM selbst ubernehmen und alleine die Teilprobleme herausnden, ohne das der Programmierer seine Finger mit im Spiel hat. Dadurch wird das Vorgehen fr den Programmierer allgemeiner und transparenter. u

100

9 Swarm

2. Leitgedanke Leider gibt es fr diesen Leitgedanken keinen kurzen prgnanten Satz, wie u a es der 1. Leitgedanke her gibt. Bei dem 2. Leitgedanken handelt es sich um eine Erweiterung des 1. im Bezug auf die Zerlegung der Teilprobleme. Denn das Konzept von SWARM beinhaltet die Idee, dass die Daten so gut aufbereitet bzw. klug strukturiert sein sollen, dass die Berechnungen nicht hug verschoben werden mssen. Da dieser Vorgang ressourcenintensiv ist a u und somit ein Performance-Problem entstehen knnte. o Wie SWARM funktioniert Die gewnschte Funktionalitt von SWARM soll in diesem Abschnitt anhand eines u a Beispiels erlutert werden. Dieses Beispiel lsst sich im Vorstellungsvideo auf der a a Homepage wiedernden. Zuerst ein paar allgemeine Erklrungen des Beispiels, die fr alle drei a u Abbildungen 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 bendliche Rechteck entspricht einem sehr einfachen Programm. 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

Screenshot von [7].

9.3 SWARM - im Detail

101

Im weiteren Verlauf wird print b ausgefhrt. Hier ergeben sich keine Probleme, u da sich die Daten b auf dem gleichen Rechner wie die Daten a benden. Daher knnen die Daten b einfach ausgegeben werden (siehe Abbildung 9.4). o
Abbildung 9.4: Wie SWARM funktioniert - 29

Wie in der Abbildung 9.5 ersichtlich ist, benden sich die Daten c auf einem anderen Rechner als die Daten a und b. Wenn es zum Aufruf von print c kommt, knnen die Daten von c ausgegeben werden, aber das Framework SWARM muss o intern einige Schritte mehr tun. Das Programm bendet sich zunchst auf dem a ersten Rechner, wo die Daten a und b ausgegeben wurden sind. Dann wird dieser Zustand des Programms eingefroren und an den Rechner geschickt, auf welchem sich die Daten c benden. Hier wird das Programm wieder usgepacktnd an der a u Stelle weiter ausgefhrt, an welcher es auf dem ersten Rechner eingefroren wurde. u
Abbildung 9.5: Wie SWARM funktioniert - 310

10 Screenshot

Screenshot von [7]. 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 wenig wie mglich Verschiebungen zwischen unterschiedlichen Rechnern stattnden o mssen. u Doch wie diese Anforderung umgesetzt werden kann, ist noch bis heute mit einem groen Fragezeichen bei SWARM versehen. aktuelle Probleme Hinter SWARM steckt ein sehr guter Gedanke, doch wie schon bisher aufgezeigt wurde, sind in der Umsetzung noch immer Probleme vorhanden. Die folgende Ubersicht soll Probleme aufzeigen und diese ein wenig erklren. a Aufbereitung der Daten Hier ergibt sich die folgende Frage: Wie sollen die Daten arrangiert werden, dass alles ezient bleibt?. Das Team hinter SWARM hat sich das Ziel gesetzt, die bentigten Daten so zu strukturieren, dass die Zahl der Berechnungsvero schiebungen minimiert wird. Diese Aufbereitung der Daten soll automatisch und kontinuierlich vom Framework durchgefhrt werden. Zur Lsung dieser u o Thematik sind verschiedene Ideen vorhanden, leider gibt es aber noch keinen funktionierenden und implementierten Ansatz. Sicherstellung von Replikationen Es muss eine gewisse Redundanz der Daten vorhanden sein, um irgendwelchen Ausfllen entgegenwirken zu knnen. Gerade auch im Bezug auf Cloud Computing a o ist dies ein wichtiger Punkt, der zu beachten ist. Nebenlugkeit a Auch bei SWARM spielt die Parallelisierung von Prozessen zur Performancesteigerung eine wichtige Rolle. Da es sich hierbei aber um ein verteiltes System handelt, steigt die Komplexitt an. Um sicherstellen zu knnen, dass alle Prozesse in a o manchen Bereichen synchron arbeiten, spielen die Entwickler mit dem Gedanken, SWARM um das Konzept des Software Transactional Memory zu erweitern. So knnten auch Synchronisationsprobleme in der Cloud gelst werden. o o Garbage Collection Die Uberlegungen gehen auch in die Richtung SWARM um eine Java-hnliche a Garbage Collection zu erweitern und so die nicht mehr bentigten Daten nach o einer gewissen Zeit vom System zu lschen. Aber wie soll das System selbststndig o a erkennen und entscheiden, welche Daten nicht mehr bentigt und gelscht werden o o knnen, wenn mehrere Rechner im Verbund arbeiten und darauf zugreifen. o

9.4 SWARM - Demos

103

einheitliche Codebasis Ein weiteres Problem stellt eine einheitliche Codebasis dar. Diese wird dringend gebraucht, damit alle zu verwendenden Klassen auf jedem Rechner verfgbar sind. u Bei SWARM gibt es auch eine Idee fr die Umsetzung, der JVM classloader. In u dem Fall knnen dann die laufenden SWARM-Instanzen die bentigten Klassen o o von einer globalen Anlaufstelle ziehen und verwenden. SWARM-spezische Collection-Klassen Fr SWARM werden Framework-spezische Collection-Klassen wie Map, List, u Set gebraucht. In Scala sind diese Klassen zwar vorhanden, aber leider nicht fr ein verteiltes System ausgelegt. Denn bei SWARM soll ein Programm auf u mehreren Rechnern laufen.

9.4

SWARM - Demos

Mit zwei kleinen und leicht verstndlichen Demos soll im Folgenden veranschaulicht a werden, was in SWARM bisher schon umgesetzt und was damit schon mglich o ist. Bei github11 liegen diese sowie weitere Demos und knnen somit leicht von o jedermann getestet werden. Die folgenden Listings wurden zur besseren Lesbarkeit und zum besseren Verstndnis auf den ntigsten Quellcode zusammengekrzt. a o u

9.4.1

Demo 1 - ForceRemoteRef.scala

Wie schon bereits erwhnt, soll SWARM den Zugri auf die verteilten Daten a ermglichen. Dies wird in dem zweiten Leitgedanken aufgenommen. Derzeit kann o dies uber die Funktion Ref geschehen. Ein Beispiel dazu ist in dem Listing 9.1 zu sehen.
Listing 9.1: Demo 1
1 2 3 4 5 6 7 8 9

println("1") val vLoc = Ref(local, "test local string") println("2") val vRem = Ref(remote, "test remote string") println("3") println(vLoc()) println("4") println(vRem()) println("5")
11 Vgl.

[3]

104

9 Swarm

Es wird fr die zwei angelegten Variablen vLoc und vRem jeweils eine Referenz u auf zwei verschiedene virtuelle Rechner erzeugt. Am Anfang wird die Zahl 1 ausgegeben. Da im Anschluss die Variable vLoc deniert wird, bleibt das Programm im ersten Ausgabefenster stehen und gibt dann die Zahl 2 aus. Es wird ja explizit gesagt, dass sich die Variable auf dem lokalen System bendet. Bei dem Anlegen der zweiten Variablen springt das Programm in das zweite Ausgabefenster und gibt dann die Zahl 3 aus. Wie die einzelnen Ausgabefenster aussehen, zeigen die Listings 9.2 und 9.3.
Listing 9.2: Ausgabe der ersten Konsole
1 2 3 4

1 2 test local string 4

Listing 9.3: Ausgabe der zweiten Konsole

1 2 3

3 test remote string 5

9.4.2

Demo 2 - ExplicitMoveTo1.scala

Dieses kleine Beispiel (siehe Listing 9.4) zeigt die Umsetzung des ersten Leitgedankens von SWARM. Hier wird vom Programmierer noch explizit angegeben, auf welchen Host die Berechnung verschoben werden soll. Dies wird mit der Funktion moveTo umgesetzt.
Listing 9.4: Demo 2
1

val name = scala.Console.readLine("What is your name? : "); Swarm.moveTo(new InetLocation(java.net.InetAddress. getLocalHost, 9997)) val age = Integer.parseInt(readLine("Hello " + name + " , what age are you? : ")) Swarm.moveTo(new InetLocation(java.net.InetAddress. getLocalHost, 9998)) println("Wow " + name + ", youre half way to " + (age * 2) + " years old")

9.5 Fazit

105

Es werden zwei Variablen angelegt (name und age), die jeweils die Eingaben des Nutzers als String fassen sollen. Beim Aufruf des Programms wird der Nutzer nach seinem Namen gefragt. Nach der Eingabe wird das Programm eingefroren und an eine andere Location (einen anderen Host) gesendet. Dort wird das Programm weiter ausgefhrt und der Nutzer wird mit seinem Namen angesprochen und u nach seinem Alter gefragt. Nun wird das Programm wieder an den ersten Host zurckgesendet, welcher dann den abschlieenden Text des Programms ausgibt. u Um sehen zu knnen, welche Ausgaben auf welchem Host gemacht werden, sind o die Listings 9.5 und 9.6 dargestellt.
Listing 9.5: Ausgabe des Host 9998
1 2

What is your name? : (Marie) Wow Marie, youre half way to 50 years old
Listing 9.6: Ausgabe des Host 9997

Hello Marie, what age are you? : (25)

9.5

Fazit

Zusammenfassend kann gesagt werden, dass die Idee, die hinter dem Framework SWARM steckt, sehr gut ist. Doch leider gibt es nach fast drei Jahren seit der Vorstellung des Frameworks keine vollstndigen Lsungen fr die Anstze. Wie im a o u a Kapitel 9.3 dargestellt, ist noch einiges an Denkleistung zu erbringen, um die genannten Probleme und Fragen aus dem Weg zu rumen. a Im Folgenden werden noch einmal die Leitgedanken aufgenommen und abschlieend betrachtet. 1. Leitgedanke - Move the computation, not the data. Fr die Autorin ist dieser Leitgedanke sehr gut nachvollziehbar und derzeit u auch im Prototyp umgesetzt. Hier wird nur eine Sache vom Framework nicht automatisch durchgefhrt; und zwar muss der Programmierer noch explizit u angeben, wohin die Berechnungen verschoben werden sollen. Dies kann mit der FUNKTION moveTo vom Programmierer geschehen. Doch irgendwann soll ja das Framework diese Funktionalitt selbst ubernehmen. a 2. Leitgedanke An sich ist dieses Vorgehen ein guter Gedanke, doch fr die Autorin sehr schwer u vorstellbar. Denn wie soll das Framework selbst erkennen, welche Daten immer

106

9 Swarm

wieder gebraucht und genutzt werden? Und hierfr hat SWARM noch keine u Lsung und sucht selbst danach, wie die perfekte Aufbereitung der Daten o aussehen soll bzw. umgesetzt werden kann. In dem Prototypen ist der Zugri auf die verteilten Daten mit der Funktion Ref mglich. o Das Thema Cloud Computing war in dem Jahre 2009 ein sehr aktuelles Thema und es wurde in den vergangenen drei Jahren immer beliebter. Trotz hoher Beliebtheit und rasch wachsendem Interesse in diesem Bereich konnten bisher noch keine Lsungen gefunden oder gravierende Fortschritte im Bezug auf die o genannten Probleme von SWARM gemacht werden. SWARM ist ein einfacher Prototyp, dessen bisherige Umsetzungen schon einige Ideen teilweise implementiert, aber von einer fertigen Anwendung noch weit entfernt ist. Die bereits zur Verfgung stehenden Funktionalitten sind interessant u a und lassen einen auf ein zgiges Vorankommen der Entwickler hoen. u

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. ct 10/12, S. 102. [3] Ian Clarke, SWARM Github. https://github.com/sanity/Swarm/tree/master/swarmdemos/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-programminglanguage/, 31.05.2012. [5] bagwell, Swarm - Concurrency with Scala Continuations. http://www.scalalang.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 http://vimeo.com/6614042, 30.05.2012. in the Cloud.

[8] o. V., Cloud computing. http://en.wikipedia.org/wiki/Cloud computing, 10.06.2012.

10

Synchronisation in verteilten Systemen

10.1 Einleitung . . . . . . . . . . . . . . . . . . . . 10.2 Uhrensynchronisation . . . . . . . . . . . . . . 10.2.1 Physikalische Uhren . . . . . . . . . . 10.2.2 Algorithmen zur Uhrzeitsynchronisation 10.2.3 Logische Uhren . . . . . . . . . . . . . 10.3 Gegenseitiger Ausschluss . . . . . . . . . . . . 10.3.1 Ein zentralisierter Algorithmus . . . . 10.3.2 Ein verteilter Algorithmus . . . . . . . 10.3.3 Ein Token-Ring-Algorithmus . . . . . . 10.4 Wahlalgorithmen . . . . . . . . . . . . . . . . 10.4.1 Der Bully-Algorithmus . . . . . . . . . 10.4.2 Ein Ringalgorithmus . . . . . . . . . . 10.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 108 109 110 111 113 113 114 115 116 116 118 119

Ricardo Volkert

Inhaltsverzeichnis

Vorwort: Die Inhalte der nachfolgenden Arbeit beziehen sich ausschlielich, sofern nicht anderweitig explizit genannt, auf Aussagen, Graken und Darstellungen der Seiten 261 bis 300 aus dem Werk Verteilte Systeme Prinzipien und Paradigmen in der 2. Auage von Andrew S. Tanenbaum und Maarten van Steen, verlegt durch die Pearson Education Deutschland GmbH.

10.1

Einleitung

Die rasante Entwicklung im Informations- und Telekommunikationsbereich und des Internets als verteiltes System, haben es in den letzten Jahren notwendig gemacht, dass immer mehr Prozesse, Anwendungen und Systeme ihre Ressourcen bndeln und gemeinsam nutzen. Dieses Verhalten wirft jedoch eine Vielzahl u von Fragen und Verhaltensweisen auf, wie sich verteilte Systeme miteinander verstndigen sollen ohne sich gegenseitig in ihrer Funktion zu beeintrchtigen. a a

108

10 Synchronisation in verteilten Systemen

Dabei umfasst die Thematik der verteilten Systeme eine groe Bandbreite von Technologien und Vorschlgen, wie eine Kommunikation dabei umgesetzt a werden kann. Im folgendem wird speziell auf die Synchronisation von verteilten Systemen eingegangen. Dabei soll dem Leser ein Uberblick verschat werden, warum beispielsweise das einfache Synchronisieren von Uhrzeiten enorm wichtig und keinesfalls trivial ist. Ferner werden Mechanismen vorgestellt, wie ein gegenseitiger Ausschluss erreicht werden kann und welche Aufgaben Wahlalgorithmen haben.

10.2

Uhrensynchronisation

Die Uhrzeit in einem Rechner bildet die Grundlage in welcher Reihenfolge Prozesse aufgerufen und ausgefhrt werden. Nachdem ein Prozess angestoen oder ein u Programm ausgefhrt wird, bekommt es einen Zeitstempel der die entsprechende u Uhrzeit trgt. Werden verschiedene Prozesse in nur einem Rechner ausgefhrt, a u spielt die tatschliche Uhrzeit eine untergeordnete Rolle. Die Uhr kann mehrere a Sekunden, Minuten oder Stunden vor- beziehungsweise nachgehen, ohne dass dies Auswirkungen hat. Sobald Prozesse jedoch auf unterschiedlichen Rechnern laufen und gemeinsame Ressourcen nutzen, kann die richtige Uhrzeit eine entscheidende Rolle spielen. Um zu verdeutlichen welche Auswirkungen ein solches Verhalten mit sich bringt, wird das verhalten am Beispiel des UNIX-Programm make verdeutlicht. Dieses Programm ermglicht es groe Dateisysteme nach Anderungen in einzelnen o Quelldateien zu durchsuchen und diese zu identizieren um sie anschlieend durch den Compiler neu kompilieren zu lassen. Auf diese Weise werden nur die Quelldateien neu kompiliert, welche auch bearbeitet worden sind. In der Praxis wird anhand eines Vergleiches zwischen der Quelldatei und der Objektdatei erkannt, ob neu kompiliert werden muss oder nicht. Hat die Quelldatei einen hheren o Zeitstempel als die Objektdatei wird die Datei an den Compiler weitergegeben. Ist dies nicht der Fall und die Objektdatei besitzt einen hheren Zeitstempel als die o Quelldatei wird nichts unternommen. In verteilten Systemen ist es daher enorm wichtig, dass alle Zeitstempel nach einer globalen Uhrzeit deniert sind. Angenommen dies ist nicht der Fall, kann es zu Problemen kommen die nicht nachvollziehbar sind. So kann die Erstellung einer Quelldatei im zeitlichen Ablauf nach der Erstellung der Objektdatei geschehen, durch unterschiedliche Uhrzeiten in den verteilten Systemen aber einen niedrigeren Zeitstempel besitzen. Daraus resultiert, dass es

10.2 Uhrensynchronisation

109

zu keiner Kompilierung kommt und die Quelldatei nicht mehr zur entsprechenden Objektdatei passt. Solche Fehler lassen sich nur sehr schwer herausnden und sind oft nicht nachvollziehbar. Ziel dieses Kapitels ist es, einen kurzen Einblick in Algorithmen zur Uhrensynchronisation zu geben und physikalische von logischen Uhren abzugrenzen.

10.2.1

Physikalische Uhren

Um zu verstehen, wie eine Uhrensynchronisation in verteilten Systemen abluft, a ist es notwendig, einen kurzen Einblick in die Funktion von physikalischen Uhren oder auch Zeitgebern in Rechnern zu geben. Zeitgeber in Rechner sind herkmmlicher Weise przise hergestellte Quarzkristalle die unter Spannung o a anfangen zu oszillieren. Durch die Schwingung des Kristalls knnen mittels o zweier Register, dem Zhler und dem Halteregister, Interrupts erzeugt werden. a Dies geschieht dadurch, dass mit jeder Schwingung des Kristalls der Zhler, der a vorher beispielsweise bei 60 Schwingungen pro Minute festgelegt wurde, um eins verringert wird und schlielich beim Erreichen der Null landet. Nach dem ausgelsten Interrupt ldt das Halteregister den Zeiger neu auf. Der Zeitgeber o a lsst sich auf diese Art und Weise mit einer gewnschten Frequenz programmieren. a u Auch wenn die eingesetzten Quarzkristalle eine sehr stabile Frequenz bei den Schwingungen einhalten, kann nicht davon ausgegangen werden, dass diese in verschiedenen Rechnern nicht voneinander abweichen. Besteht ein System aus beliebig vielen Rechnern muss also angenommen werden, dass alle Kristalle leicht asynchron schwingen und die Uhrenzeiten somit voneinander abweichen. Der Eekt verschiedener Zeitwerte wird auch als Uhrendrift bezeichnet. Als mgliche o Folge knnten sich Fehler ergeben wie am Beispiel make bereits erlutert. o a Um reale Uhrzeiten mit denen von Rechnern abgleichen zu knnen, wuro den im Laufe der Zeit mehrere Entwicklungen bis hin zur Atomuhr vollzogen. Aktuelle Rechner und Systeme nutzen die modernen staatlichen Zeiterfassungsverfahren wie UTC (Universal Coordinate Time). Diese basiert auf der Atomzeit und ist heute wesentlicher Standard in der Zeitgebung. Zu Beginn jeder UTC-Sekunde wird von verschiedenen Sendern ein kurzes Signal gesendet, um somit eine Synchronisation zu ermglichen. In den USA wird fr diesen Zweck ein o u Kurzwellensender mit der Bezeichnung WWV genutzt.

110

10 Synchronisation in verteilten Systemen

10.2.2

Algorithmen zur Uhrzeitsynchronisation

Die Synchronisation verschiedener Uhren lsst sich am einfachsten durchzufhren, a u wenn einer der beteiligten Rechner einen WWV-Empfnger besitzt. In diesem Fall a synchronisieren 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 ihnen die aktuelle Uhrzeit mitteilt. Ein Beispiel fr einen solchen Algorithmus ist NTP u (Network Time Protocol). Das Network Time Protocol (NTP) Gem dem NTP verbindet sich ein Rechner mit dem Zeitserver, um die aktuelle a Uhrzeit abzufragen. Der Zeitserver ubermittelt die diese unter Bercksichtigung u der Ubertragungsverzgerung. Das heit, dass aufgrund der Ubertragungsdauer o eine gute Schtzung vorgenommen werden muss, um die richtige Uhrzeit zu a ubermitteln. Anhand der ubermittelten Zeitstempel beim Absenden und der Zeitstempel beim jeweiligen Eingang einer Nachricht lsst sich eine Berechnung a durchfhren und die richtige Uhrzeit ubermitteln. Eine Besonderheit ergibt sich, u wenn die aktuelle Uhrzeit zu schnell luft und somit zurck gestellt werden muss. a u Da die Uhrzeit nicht rckwrts laufen darf, weil dies zu Konikten in Dateien u a mit verschiedenen Zeitstempeln fhren kann, muss eine andere Lsung gefunden u o werden. Diese wird durch das Einfhren von zustzlichen Interrupts geschat. u a Angenommen ein Zeitgeber ist so eingestellt, dass er pro Sekunde 100 Interrupts erzeugt und nach jedem Interrupt der Zeit 10 ms hinzufgt, so knnen u o beispielsweise bei Verlangsamen stattdessen nur 9 ms oder beim Beschleunigen 11 ms hinzugefgt werden. Auf diese Weise lsst sich die Zeit allmhlich anpassen. u a a Eine weitere Besonderheit bei NTP ist das sogenannte Strata. Das Strata gibt Aufschluss darber, ob ein Rechner an eine Referenzuhr (bspw. Atomuhr) u angeschlossen ist. Ein solcher Rechner wird auch als Stratum-1-Server bezeichnet. Rechner die an keine Referenzuhr angeschlossen sind, werden als Stratum-k-Server bezeichnet. Eine Anpassung der Uhrzeit wird dementsprechend immer nur gegenber einem Rechner vollzogen, der ein kleineres Stratum besitzt. u Es gibt jedoch auch verteilte Systeme in denen kein Rechner uber einen WWV-Empfnger oder eine Atomuhr verfgt und der Zeitserver sich im gesamten a u System nach der aktuellen Uhrzeit erkundigt, um die Uhrzeit zu bestimmen. Ein Vertreter 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 bendlichen Rechner seine Uhrzeit mit und fragt sie nach ihrer eigenen Zeit. Aus den Antworten wird die durchschnittliche Uhrzeit berechnet. Dabei reicht dem Deamon als Antwort die Dierenz zur eigenen Uhrzeit. Anschlieend teilt er allen Rechner mit, ob diese ihre Uhren vor- oder zurckstellen u mssen. Die Zeit des Zeit-Daemons wird in der Regel durch einen Administrator u in regelmigen Abstnden neu eingestellt. Es ist bei diesem Verfahren nicht a a notwendig, dass die Uhrzeit im Netzwerk mit der realen Uhrzeit ubereinstimmt. Es fhrt auch zu keinerlei Problemen wenn der Zeit-Daemon lange nicht manuell u nachgestellt wird, solange kein anderer im Netzwerk bendlicher Rechner mit auen kommuniziert. Ein anschauliches Beispiel wird nachfolgend gegeben.
Abbildung 10.1: Berkley-Algorithmus

In Abbildung 10.1(a) sendet der Zeit-Daemon allen im Netzwerk bendlichen Rechnern seine aktuelle Uhrzeit und erkundigt sich nach deren. Als Antwort wird dem Zeit-Daemon in Abbildung 10.1(b) die jeweilige Dierenz zur mitgeteilten Uhrzeit ubermittelt. Aus der Dierenz aller Zeiten wird ein Mittelwert gebildet und allen Rechnern in Abbildung 10.1(c) mitgeteilt, wie sie ihre Uhr anpassen mssen. u

10.2.3

Logische Uhren

Eine Uhrzeitsynchronisation hngt jedoch nicht zwangslug mit der realen a a Uhrzeit zusammen. Wenn ein Netzwerk sich nur untereinander verstndigt, reicht a es aus, dass die Uhrzeit nur unter den Teilnehmern synchronisiert wird. Es reicht jedoch auch schon aus, wenn sich zwei Prozesse darber einigen, wenn eine u

112

10 Synchronisation in verteilten Systemen

Version einer Datei lter ist als die andere. Werden Algorithmen benutzt die a diese Entscheidungen untersttzen, wird von logischen Uhren gesprochen. Im u nachfolgenden wird diese Thematik am Beispiel der logischen Uhren von Lamport dargelegt. Lamport denierte die Bezeichnung happens-before, um logische Uhren zu synchronisieren. Mittels des folgenden Ausdrucks kann somit angegeben werden, in welcher Reihenfolge Ereignisse eingetreten sind: a b besagt, dass das Ereignis 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 eintreen und nicht miteinander kommunizieren, kann keine Aussage darber getroen u werden, welche Ereignis zuerst stattgefunden hat. Die folgende Abbildung soll verdeutlichen, wie die logischen Uhren von Lamport arbeiten und was passiert, wenn eine Nachricht mit einem Zeitstempel ankommt, der grer ist als der o eigene.
Abbildung 10.2: Die logischen Uhren von Lamport

In Abbildung 10.2(a) sendet der Prozess P1 eine Nachricht m1 an P2 und dieser eine Nachricht m2 an P3. Aullig dabei ist, dass die Zeitgeber der jeweiligen a Prozesse unterschiedlich schnell laufen. Da bei den ersten beiden Nachrichten die Zeit 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 m4 von 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 eine Einheit weiter vorgestellt, als der Zeitstempel beim Absenden aufweist. Auf diese Weise justieren sich die Zeitgeber einer logischen Uhr.

10.3

Gegenseitiger Ausschluss

Wie bereits erwhnt, arbeiten in verteilten Systemen mehrere Prozesse mit den a gleichen Ressourcen. Dies fhrt dazu, dass ausgehandelt werden muss, welcher u Prozess wann auf die entsprechende Ressource zugreifen darf. Geschieht dies nicht, so kann es zu Inkonsistenzen fhren oder im schlimmsten Fall zur Beschdigung der u a Ressource. Um dies zu verhindern, wird zeitgleich immer nur einem Prozess das exklusive Zugrisrecht zugesprochen. Im Folgenden werden verschieden Algorithmen vorgestellt und dargestellt, wie diese umgesetzt werden knnen. o

10.3.1

Ein zentralisierter Algorithmus

Eine einfache Mglichkeit einen gegenseitigen Ausschluss zu erreichen, ist das o simulieren eines Einprozessorsystems. Mit Hilfe eines Prozesses, der zum Koordinator bestimmt wird, lsst sich dies Umsetzen. Will ein Prozess den Zugri auf a eine Ressource, so muss er dies beim Koordinator beantragen. Sollte kein anderer Prozess auf die Ressource zugreifen, so wird der Zugri erlaubt. In dem, dass ein anderer Prozess bereits auf die Ressource zugreift, wird dem anfordernden Prozess, je nach Implementierung, eine Besetztnachricht ubermittelt. Anschlieend nimmt der Koordinator die Anfrage in seine Warteschlange auf. Sobald die Ressource freigegeben wird, arbeitet der Koordinator die Warteschlange ab und der Prozess erhlt den Zugri. In der Nachfolgenden Abbildung wird veranschaulicht, wie der a Zugri erfolgt.
Abbildung 10.3: Ein zentralisierter Algorithmus

In Abbildung 10.3(a) fordert der Prozess 1 vom Koordinator den Zugri auf eine

114

10 Synchronisation in verteilten Systemen

Ressource an. Da kein anderer Prozess auf die Ressource zugreift, wird die Anfrage genehmigt und ein OK gesendet. In Abbildung 10.3(b) fordert nun Prozess 2 den Zugri auf die gleiche Ressource an. Jedoch ist Prozess 1 noch nicht mit der Bearbeitung fertig. Der Koordinator signalisiert, dass die Ressource belegt ist, und nimmt die Anfrage in die Warteschlange auf. Nun wird in Abbildung 10.3(c) die Bearbeitung durch 1 abgeschlossen und die Ressource freigegeben. Der Koordinator registriert die und arbeitet die Warteschlange ab. Somit bekommt nun Prozess 2 das OK zur Bearbeitung.

10.3.2

Ein verteilter Algorithmus

Ein verteilter Algorithmus kann verschieden aufgebaut sein. Er unterscheidet sich im Gegensatz zu einem zentralisierten Algorithmus allerdings dahin gehend, dass es keinen einzelnen Koordinator mehr gibt. Dafr ist es jedoch notwendig, dass u alle Teilnehmer an diesem Verfahren eine gemeinsame logische Zeit besitzen. Der Ansatz den Lamport vorschlgt, lsst sich hierbei einbringen und die Nutzung a a von Zeitstempel bildet die Grundlage fr den gegenseitigen Ausschluss. An dieser u Stelle soll kurz auf die Funktionsweise des Algorithmus eingegangen werden. Will ein Prozess auf eine Ressource zugreifen, so sendet er seine Prozessnummer, den Namen der Ressource und die logische Zeit an alle Prozesse innerhalb des verteilten Systems. Ein Prozess, der eine solche Nachricht erhlt, kann unterschiedlich a reagieren. Greift der Empfnger der Nachricht nicht auf die gewnschte Ressource zu a u und hat dies auch nicht vor, so sendet er eine OK-Nachricht an den Absender zurck. u Wenn der Empfnger jedoch bereits auf die Ressource zugreift, so antwortet a er einfach nicht, oder sendete, je nach Implementierung, eine Besetztnachricht zurck und nimmt die Anfrage in seine Warteschlange auf. Nach Beendigung u des Zugris arbeitet er diese ab und sendet die OK-Nachricht an den Absender. Mchte der Empfnger jedoch auch auf die Ressource zugreifen, hat dies o a aber noch nicht getan, vergleicht er seinen gesendeten Zeitstempel mit dem Eingegangenen. Dabei gewinnt der Prozess, der den niedrigeren Zeitstempel besitzt. Sollte dies der Absender sein, so sendet der Empfnger die OKa Nachricht. Besitzt der Empfnger den niedrigeren Zeitstempel, so greift er auf a die Ressource zu und stellt die Anfrage in die Warteschlange ein. Die Abbildung 10.4 soll an einem Beispiel verdeutlichen, wie der Algorithmus arbeitet. In (a) wollen sowohl Prozess 0 als auch Prozess 2 auf die gleiche Ressource zugreifen. Dabei besitzt Prozess 0 den Zeitstempel 8 und Prozess 2 den

10.3 Gegenseitiger Ausschluss Abbildung 10.4: Ein verteilter Algorithmus

115

Zeitstempel 12. Nachdem beide Prozesse die jeweiligen Zeitstempel mit ihren eigenen 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, arbeitet er 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 verteilten Systemen zu erreichen ist der Token-Ring-Algorithmus. Um den Token im Ring kreisen zu lassen, ist als erster Schritt die Ordnung der Prozesse notwendig. Dafr u reicht es aus, den jeweiligen Prozessen eine Position zuzuordnen, die beispielsweise anhand der Netzwerkadresse und weiteren Kriterien ermittelt werden kann. Hat jeder Prozess eine entsprechende Nummer erhalten, kann der Ring initialisiert werden und Prozess 0 erhlt den Token. Fr die jeweiligen Prozesse ist es nicht a u notwendig die gesamte Ordnung zu kennen. Allerdings mssen sie ihren Nachfolger u kennen um den Token weiterzugeben. Erhlt ein Prozess den Token, so uberprft er, ob er Zugri auf die Resa u source haben will. Ist dies nicht der Fall, gibt er den Token an den nchsten a Prozess weiter. Um einen verlorenen Token entgegenzuwirken, empehlt es sich, dass jeder Prozess der den Token erhlt eine Empfangsbesttigung ubermittelt. a a Sollte ein Prozess abstrzen, so ist er aus dem Ring zu entfernen und der Token u wird an den nchsten Prozess weitergegeben. Da kein Prozess doppelt auf die a Ressource zugreifen kann, ohne das alle anderen Prozesse die Gelegenheit dazu bekommen haben, bleibt die Fairness gewahrt. Der Aufbau eines mglichen Ringes o ist in Abbildung 10.5 dargestellt. In Fall (a) wird eine Reihe von Prozessen ohne Ordnung innerhalb eines Netzwerkes 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. Anschlieend erhlt Prozess 0 den Token und prft ob er Zugri bentigt. Sollte a u o dies geschehen verweilt der Token solange bei ihm, bis er die Ressource freigibt und den Token an seinen Nachfolger sendet.

10.4

Wahlalgorithmen

Damit der Groteil der bisher vorgestellten Algorithmen funktioniert, ist es notwendig, dass ein Prozess eine Sonderaufgabe ubernimmt. Dieser fungiert dadurch als Initiator, Koordinator oder in einer sonstigen Sonderrolle. Es spielt in der Regel keine Rolle welcher Prozess diese Aufgabe ubernimmt, jedoch muss es ein Prozess tun. Um die Prozesse dennoch voneinander unterscheiden zu knnen, ist es noto wendig, dass alle Prozesse eine eindeutige Nummer zugeordnet bekommen. Eine mgliche Vorgehensweise anhand der Netzwerknummer wurde bereits beschrieben. o Im weiteren Verlauf dieses Kapitels wird auf zwei verschiedene Wahlalgorithmen eingegangen, wie ein Prozess zum Koordinator, Initiator oder als Inhaber einer sonstige Sonderrolle bestimmt werden kann.

10.4.1

Der Bully-Algorithmus

Eine Mglichkeit wie eine Wahl abgehalten werden kann, verdeutlicht der von o Garcia-Molina entwickelte Bully-Algorithmus. Wenn ein Prozess festgestellt hat, dass der Koordinator nicht mehr auf Anfragen antwortet, kann der Algorithmus folgender Maen beschrieben werden: Der Prozess der den Absturz des Koordinators bemerkt, sendet an alle Prozesse mit einer hheren Nummer eine WAHL-Nachricht. o

10.4 Wahlalgorithmen

117

Antwortet keiner dieser Prozesse, ubernimmt der Absender der Nachricht die Aufgaben des Koordinators und teilt dies allen anderen Prozessen mit. Sollte ein Prozess mit einer hheren Nummer antworten, ist die Aufgabe fr o u den initiierenden Prozess beendet. Der hhere Prozess wickelt die weitere Wahl o ab. Grundstzlich kann jeder Prozess immer eine WAHL-Nachricht von einem niedrigea ren Prozess erhalten. Umgekehrt ist dies jedoch nicht mglich. Um zu signalisieren, o dass ein Prozess die entsprechende Nachricht erhalten hat, sendet er eine OKNachricht an den Absender zurck. Anschlieend wird, wie bereits beschrieben, u eine neue Wahl abgehalten. Dieses Verhalten setzt sich solange fort, bis nur noch ein Prozess ubrig bleibt und somit zum neuen Koordinator wird. Eine entsprechende Nachricht darber wird an alle Prozesse versendet. Kehrt ein abgestrzter Prozess u u wieder zurck, hlt dieser eine neue Wahl ab. Hat er die hchste Prozessnummer, u a o so wird er gewinnen und alle andern Prozess wieder unterwerfen. In Abbildung 10.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 Koordinator mit der Prozessnummer 7 abgestrzt ist und Prozess 4 dies als erster bemerkt. Er u beginnt 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 Besttigung, a wie in (b) zu sehen ist. Abbildung 10.6(c) veranschaulicht wie die Prozesse separat eine neue Wahl einleiten und an die hheren Prozesse herantreten. Da jedoch nur o

118

10 Synchronisation in verteilten Systemen

Prozess eine OK-Nachricht senden kann, ist die Wahl somit in (d) beendet und Prozess 6 wird zum Koordinator. Anschlieend teilt er dies an alle existierenden Prozesse mit, was aus Abbildung 10.6(e) zu entnehmen ist.

10.4.2

Ein Ringalgorithmus

Eine weitere Mglichkeit einen Wahlalgorithmus zu implementieren ist der Ringalo gorithmus. Dieser arbeitet im Gegensatz zu anderen Ringalgorithmen jedoch ohne einen Token. Damit ein Ringalgorithmus funktioniert, mssen alle Prozesse u physisch oder logisch in einem Ring angeordnet werden und ihren Nachfolger kennen. Sollte ein Prozess feststellen, dass der Koordinator abgestrzt ist, erstellt u er eine WAHL-Nachricht. Diese Nachricht enthlt seine eigene Prozessnummer a und wird an den Nachfolger gesendet. Trit die WAHL-Nachricht ein, ergnzt a der aktuelle Prozess seine Nummer und sendet die Nachricht anschlieend an seinen Nachfolger. Wenn zwischendurch ein Prozess nicht mehr existent ist, so wird er einfach ubersprungen. Der Vorgang wird so lange wiederholt, bis die WAHL-Nachricht wieder beim ursprnglichen Absender ankommt. Dies wird an u der eigenen Prozessnummer erkannt, die bereits in der Nachricht enthalten ist. Der Prozess mit der hchsten Nummer innerhalb der WAHL-Nachricht wird nun o zum neuen Koordinator ernannt. Der Initiator der Wahl teilt dies allen Prozessen mittels einer KOORDINATOR-Nachricht mit. Ist diese Nachricht einmal im Ring umhergegangen, wird sie schlielich 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 Koordinator mit der Prozessnummer 7 abgestrzt ist. Unabhngig voneinander initialisieren u a

10.5 Fazit

119

beide Prozesse eine Wahl und geben die WAHL-Nachricht in den Ring. Sobald die Nachricht wieder bei den jeweiligen Absendern angelangt ist, stellen diese unabhngig voneinander fest, dass Prozess 6 der neue Koordinator wird. Mit der a abschlieenden KOORDINATOR-Nachricht wird dies allen Prozessen mitgeteilt. Dass zwei WAHL- bzw. KOORDINATOR-Nachrichten kreisen, wird dabei nicht als Fehler angesehen. Im schlimmsten Fall kostet dies nur etwas mehr Ressourcen.

10.5

Fazit

Die Synchronisation ist ein wichtiger Baustein beim Erstellen und Nutzen von verteilten Systemen. Dabei kommen verschiedenste Algorithmen zum Einsatz, um gegenseitigen Ausschluss zu erreichen und die Konsistenz von Netzwerken zu erhalten. Die erwhnten Algorithmen stellen dabei jedoch nur eine eingeschrnkte a a Auswahl dar, um den Leser in die Thematik der Synchronisation in verteilte Systeme einzufhren und zu sensibilisieren. Durch das Thema Cloud-Computing u und der sich daraus ergebenden Mglichkeit Anwendungen in immer grere o o verteilte Systeme zu unterteilen, wird die Notwendigkeit von Synchronisationen auch aktuell verdeutlicht.