Implementierung eines dezentralen Kalenders basierend auf Java · Kalenders basierend auf Java von...

Bachelor Thesis

im Studiengang

Bachelor der angewandten Informatik

Implementierung eines dezentralenKalenders basierend auf Java

von

Mohamadbehzad Karimi AhmadabadiMatrikel-Nummer: 565477

Erstprüfer: Prof. Dr. Thomas Schwotzer

Zweitprüfer: Prof. Dr. Alexander Huhn

Eingereicht am: 16. September 2019

Zusammenfassung

Digitale Kalender bieten ihren Nutzern eine Möglichkeit, ihre Termine kompakt zu organisieren.

Um die Terminkoordination mit andern Nutzern zu erleichtern, wurden geteilte Kalender entwi-

ckelt. Diese Arbeit befasst sich mit der Entwicklung eines Kalendersystems, das ohne einen Ser-

ver auskommt. Die Daten sollen dezentral auf allen Geräten gespeichert werden und auch ohne

eine Verbindung zum Internet sichtbar sein. Mithilfe eines entwickelten Algorithmus, sollen die

verteilten Daten synchronisiert werden, um es mehreren Nutzern zu ermöglichen, Änderungen

durchzuführen.

Abstract

Digital calendars offer their users a way to organize their appointments in a compact manner. To

facilitate scheduling coordination with other users, shared calendars have been developed. This

thesis deals with the development of a calendar system without a server. The data should be

stored decentrally on all devices and be visible even without a connection to the Internet. Using

a developed algorithm, the distributed data should be synchronized to allow multiple users to

make changes.

Inhaltsverzeichnis

1. Einleitung 21.1. Hintergrund der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Problem- und Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Grundlagen zur Datensynchronisation für dezentrale Systeme 42.1. CAP-Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2. Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1. Aktualisierungsverwaltung Strategien . . . . . . . . . . . . . . . . . . 8

2.2.2. Replikations Protokollarten . . . . . . . . . . . . . . . . . . . . . . . 10

2.3. Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4. ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5. 2 Phase Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6. Voting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.7. Last-Write-Wins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.8. TCP/IP-Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.8.1. Nachrichtenversand . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.8.2. Transportschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3. Aktueller Stand 223.1. Rsync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2. Rumor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3. Roam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4. Bayou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5. Operational Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.6. SyncML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.7. BASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.8. IceCube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

III

4. Anforderungserhebung & -analyse 324.1. Infrastruktur & Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.1. Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.2. Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1. Beispielszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.2. Funktionale Anforderung . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.3. Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . 34

5. Konzeption & Entwurf 365.1. Kalenderformat: iCalendar (RFC 5545) . . . . . . . . . . . . . . . . . . . . . 36

5.1.1. Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.2. To-Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.3. Free/Busy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.4. Journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.5. Time Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.6. Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2. Entwurf eines Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.1. Operational Transformation nach Imine . . . . . . . . . . . . . . . . . 40

5.2.2. OT für den Decentralized Calendar . . . . . . . . . . . . . . . . . . . 42

6. Implementierung 466.1. Bibliotheken und Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.1.1. biweekly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.1.2. JUnit5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.1.3. AssertJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2. Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.3. Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.3.1. Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.3.2. Strategy Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.4. Implementierung der Datenversendung . . . . . . . . . . . . . . . . . . . . . . 56

7. Fazit 58

8. Literaturverzeichnis 60

9. Glossar 64

IV

A. Anhang 66A.1. Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

A.2. Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

A.3. Eidesstattliche Versicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Tabellenverzeichnis

2.1. Die vier Schichten des TCP/IP-Referenzmodell mit ihren Aufgaben und Proto-

kollen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1. Zusammenfassung der Funktionalen und Nichtfunktionalen Anforderungen . . 35

6.1. Junit5 genutzte Annotationen für Methoden im Decentralized Calendar . . . . 49

6.2. Maven Verzeichnisstruktur für den Entwurf des Decentralised Calendar) . . . . 53

Abbildungsverzeichnis

2.1. Das CAP-Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2. Aktualisierung eines Replikats auf mehreren Knoten . . . . . . . . . . . . . . 5

2.3. Das CAP-Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4. Eager Single Master Replication Protocol Actions. (1) Ein Write wird an der

Master Copy angewandt. (2) Der Write wird an alle Slaves propagiert. (3) Die

Aktualisierung ist durch den Commit nun dauerhaft gespeichert. (4) Reads kön-

nen lokal am Slave durchgeführt werden. [1, S. 469] . . . . . . . . . . . . . . . 11

2.5. Eager Primary Copy Replication Protocol Actions.(1) Writes oder Reads an je-

dem Objekt, werden an die Master Copy weitergeleitet. Der Write wird zuerst

bei der Master Copy durchgeführt. (2) Der Write wird dann an alle Slaves propa-

giert. (3) Durch den Commit sind nun alle Änderungen dauerhaft gespeichert. [1,

S. 473] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6. Eager Distributed Replication Protocols Action. (1) Zwei Writes werden an zwei

lokalen Replikationen desselben Datensatzes/Objekts durchgeführt. (2) Die bei-

den Writes werden unabhängig voneinander an alle anderen Replikationen pro-

pagiert. (3) Die Aktualisierung ist nun permanent gespeichert (nur für die Trans-

aktion 1 verdeutlicht). [1, S. 474] . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7. Lazy Single Master Replication Protocol Actions. (1) Die Aktualisierung wurde

am lokalen Replikat angemeldet. (2) Die Transaktion wird committed und somit

permanent gespeichert. (3) Eine Aktualisierungstransaktion wird an die Slaves

geschickt. (4) Transaktion 2 liest ein lokales Replikat [1, S. 475] . . . . . . . . 13

2.8. Lazy Distributed Replication Protocol Actions. (1) Zwei Aktualisierungen wer-

den an zwei lokalen Replikaten angewandt. (2) Die Transaktion wird commited

und damit die Änderung permanent gespeichert. (3) Die Aktualisierungen wer-

den unabhängig voneinander an alle anderen Replikate propagiert [1, S. 481] . 14

2.9. Klassifikation von Replikationsansätzen [2, S. 287] . . . . . . . . . . . . . . . 15

2.10. Architektur eines Systems welches das ACID Prinzip unterstützt [3]. . . . . . . 17

2.11. Das TCP/IP-Referenzmodell [4, S. 8] . . . . . . . . . . . . . . . . . . . . . . 20

Abbildungsverzeichnis IX

3.1. Datenmengenabdeckung bei einer selektiven Synchronisation. A, B, C und D

stellen die Datenteile dar. Verschiedene Replikationen bilden unterschiedliche

Datenmengen ab. Die Daten sind dennoch, in diesem Fall, an mindestens zwei

Stellen repliziert. [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2. Operational Transformation mithilfe des Wortes „Effekt“ veranschaulicht. . . . 26

3.3. SyncML Synchronisierung zwischen einem Server und einem Client. . . . . . 28

3.4. Architektur eines Systems welches dem BASE Modell folgt [6] . . . . . . . . . 29

5.1. Decentralized Calendar Synchronisations-Eigenschaften abgebildet auf das CAP

Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2. Aktivitätsdiagramm des Decentralized Calendar. . . . . . . . . . . . . . . . . . 45

6.1. Klassendiagramm zur Veranschaulischung des Strategy Patterns. . . . . . . . . 55

Listings

5.1. Beispiel eines Events mit einer Dauer von einer Stunde . . . . . . . . . . . . . 37

5.2. Beispiel eines To-Dos mit mehreren Teilnehmern . . . . . . . . . . . . . . . . 37

5.3. Beispiel einer veröffentlichten Liste über nicht erreichbare Zeiten . . . . . . . 38

5.4. Beispiel eines Journal Eintrags . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.5. Dieses Beispiel beschreibt die Zeitzonen Information über Berlin . . . . . . . . 39

5.6. Beispiel einer Erinnerung mit Beschreibung . . . . . . . . . . . . . . . . . . . 39

6.1. Lesen eines iCalendar Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.2. Schreiben einer iCalendar Klasse in eine .ics Datei . . . . . . . . . . . . . . . 47

6.3. Validierung eines ICalendar Objekts . . . . . . . . . . . . . . . . . . . . . . . 48

6.4. Gegenüberstellung von JUnit und AssertJ an der Ergebniskontrolle. Getestet

wird ob zwei Listen, unabhängig der Reihenfolge ihrer Einträge, gleich sind. . . 49

6.5. Koordinaten aus der POM vom Cecentralized Calendar Projekt . . . . . . . . . 51

6.6. Kleiner Ausschnitt der Depencencies aus der POM vom Decentralized Calendar

Projekt. Die erste Dependency ist das Framework biweekly und das zweite JUnit5 52

6.7. Informationen über die Organisation in der POM des Decentralized Calendar

Projekts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.8. Informationen über den Entwickler in der POM des Decentralized Calendar Pro-

jekts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.9. RequestLog.java. Nutzung des Singleton Patterns. . . . . . . . . . . . . . . . . 54

6.10. ConnectionHandler.java aus dem Decentralized Calendar. Er ist verantwortlich

für den Empfang und Versand des Logs. . . . . . . . . . . . . . . . . . . . . . 57

A.1. Vollständige POM aus dem Decentralized Calendar Projekts . . . . . . . . . . 66

1. Einleitung

Kalender unterstützen Menschen in ihrem Alltag. Man unterscheidet hierbei in privaten und ge-

teilten Kalendern. Letzteres erleichtert es mehreren Nutzern sich untereinander zu organisieren.

Ohne diesen müssten sie sich ihre Informationen anderweitig austauschen, wie z.B. durch ein

Telefonat oder einer Email. Um einen Single Point of Failure im System zu vermeiden, sollte

dieser nicht auf eine zentrale Lösung setzen. Ist bei diesem nämlich ein zentraler Knoten nicht

erreichbar, so können die Nutzer nicht auf ihren Kalender zugreifen und Aktionen betätigen.

Dieses Problem umgehen verteilte Systeme, diese bieten nämlich eine höhere Fehlertoleranz

an, als eine zentrale (Server) basierte Lösung. Auch vor Angreifern ist ein dezentrales System

besser geschützt, da hier ein Angreifer mehrere Knoten angreifen muss. Ein weiterer Nachteil

einer zentralen Lösung ist, dass Nutzer mit dem Server verbunden sein müssen, um das System

nutzen zu können, Beispiel Google Calendar [7]. Besteht keine Internetverbindung, so kann der

Nutzer sein Kalender nicht nutzen und wenn dieser seine Daten nicht Offline gespeichert hat,

auch keine Termine einsehen. In dieser Arbeit soll genau solch eine dezentrale Lösung entwi-

ckelt werden, damit Nutzer ohne eine Verbindung mit dem Internet ihr Kalender nutzen können.

Dieser soll dennoch ein geteilter sein, sodass weitere Nutzer Zugang zum Kalender haben und

ebenfalls Änderungen durchführen können.

1.1. Hintergrund der Arbeit

Bei der Datenkommunikation herrscht eine Regeleinhaltung, werden diese nicht eingehalten

kommt es zu Datenverlusten. Die Regeln beginnen schon bei der Auswahl der Technologien

wie Daten zwischen zwei Computern ausgetauscht werden. Hinzu kommt eine Regelung die

bestimmt was es für Daten sind und wie genau diese auszusehen haben. Dafür verlangt es an

Kenntnissen über Netzwerkprotokolle sowie der Datenreplikation in einem verteilten System.

1.2. Problem- und Zielstellung

Heutzutage nutzt jeder für seine Daten einen Cloud Anbieter (z.B. Microsoft, Apple, IBM, Ama-

zon Web Services). Das heißt, dass die eigenen Daten nicht nur privat, sondern auch bei einem

Aufbau der Arbeit 3

Dienstleister gespeichert sind. Fallen diese Dienstleister ausfallen, durch zum Beispiel einem

Systemfehler in der Cloud, so gibt es keinen Zugang mehr zu den eigenen Daten (single point

of failure). Ebenfalls können die Dienstleister keine 100-prozentige Sicherheit für die Daten ga-

rantieren, wie man seit der NSA-Affäre 2013 weiß [8]. Der große Vorteil einer Cloud basierten

Lösung ist aber, dass es lokal zu keiner hohen Speicherlast kommt und die Daten (theoretisch)

immer abrufbar sind, solange der Computer mit dem Internet verbunden ist.

Bei dieser Arbeit geht es nun darum trotz eines dezentralen Speichers, die Vorteile eines

Cloud basierten Systems anzueignen und gleichzeitig deren Nachteile auszugleichen. Ein Nach-

teil den dezentrale Server mit sich bringen, ist die Datensynchronisation. Aufgrund der Tatsache,

dass die Daten auf verschiedenen Computern verteilt sind kann es dazu kommen, dass auf zwei

verschiedenen Computern der gleiche Datensatz unterschiedlich bearbeitet wird, was bei einer

Synchronisation zu einem Konflikt der beiden Daten führt. In dieser Arbeit wird versucht eine

Möglichkeit zu finden folgende Frage zu beantworten: „Wie ist es möglich Kalenderdaten in

einem dezentralen System zu synchronisieren? “

1.3. Aufbau der Arbeit

Es werden zuerst die nötigen Kenntnisse vermittelt um diese Arbeit zu durchzuführen. Begin-

nend mit den Grundlagen zur Datensynchronisation und anschließend die Netzwerktopologie.

Im darauffolgenden Kapitel werden aktuelle Technologien zur Datensynchronisation vorgestellt

und diskutiert. Anschließend wird eine Anforderungsanalyse erhoben, um die für diese Arbeit

relevanten Funktionalitäten festzusetzen. Auf diese Funktionalitäten bauen die beiden weiteren

Kapitel auf und erstellen ein Entwurf und die Implementation des Systems. Im letzten Kapitel

wird die Arbeit rückwirkend Reflektiert, Probleme während der Umsetzung beschrieben und ein

Ausblick für weitere Arbeiten erstellt.

2. Grundlagen zur Datensynchronisationfür dezentrale Systeme

In diesem Kapitel werden grundlegende Theorien und Begriffe zum Thema Datensynchronisa-

tion für dezentrale Systeme vorgestellt und erläutert.

2.1. CAP-Theorem

Das CAP-Theorem wurde im Jahr 2000 von Brewer vorgestellt. Es beschreibt Zielkonflikte, die

bei verteilten Systeme entstehen. Es besagt, dass in einem verteilten Datenbanksystem nur zwei

von den folgenden drei Eigenschaften (Abbildung 2.1) garantiert werden können:

Consistency (dt. Konsistenz). Die Daten sehen für alle Teilnehmer gleich aus, selbst bei

einer Aktualisierung eines Datensatzes.

Availability (dt. Verfügbarkeit). Es ist jederzeit möglich Zugriff auf die Daten zu haben,

auch bei Ausfällen von Knoten.

Tolerance for Networt Partitions (dt. Partitionierungstoleranz). Bei Partitionierung des

Netzwerks, werden alle Systemeigenschaften gewährleistet. Partitionierung bedeutet hier,

das es mindestens zwei miteinander unverbundene Teilnetze gibt.

C Konsistenz

A Verfügbarkeit

P Partitionierungstoleranz

Abbildung 2.1.: Das CAP-Theorem.

CAP-Theorem 5

Um zu verstehen warum nicht alle drei Eigenschaften garantiert werden können, folgendes

Fallbeispiel (Abbildung 2.2): Zwei Knoten A und B, haben Replikate eines Datenobjekts ge-

speichert. A verändert sein Replikat. Damit ein konsistenter Zustand gesichert ist, muss A B

eine Nachricht M mit Informationen der Änderung schicken, welcher diese dann verarbeitet.

Anschließend haben beide Knoten wieder einen konsistenten Zustand. Gibt es nun eine Netz-

werkpartitionierung, sodass die beiden Knoten nicht mehr miteinander verbunden sind, kann die

Nachricht M nicht mehr zugestellt werden. Wenn die Konsistenz aber sichergestellt werden soll,

dann darf die Änderung am Replikat von A nicht erfolgen, sondern erst wieder wenn eine Ver-

bindung zwischen den beiden Knoten besteht. Das geht nur auf Kosten der Verfügbarkeit. Eine

andere Möglichkeit wäre, dass B das Replikat erst lesen darf, wenn es die Nachricht M erhalten

hat. Dies wiederum schränkt ebenfalls die Verfügbarkeit oder Partitionierungstoleranz ein.

DB

Knoten A

update

Nachricht M

1

2

DB

Knoten B

read3

Abbildung 2.2.: Aktualisierung eines Replikats auf mehreren Knoten.

Aufgrund der Einschränkung die eingegangen werden muss, ergeben sich drei Systemklassen

(Abbildung 2.3). [2, S. 353-361]

AP-Systeme - Verzicht auf Konsistenz Abbildung 2.3a stellt die erste Variante dar. Sie

wird oft für Cloud-Datenbanken verwendet. Damit die Daten immer Verfügbar sind, wird

die Konsistenz der Daten eingeschränkt, indem es zugelassen wird das Aktualisierungen

auf Replikate zugelassen werden, auch bei einer nicht bestehenden Verbindung zwischen

den Knoten. Um die entstehenden Konflikte zu lösen, werden meistens optimistische Stra-

tegien verwendet.

6 Replikation

CP-Systeme - Verzicht auf Verfügbarkeit Es gibt Systeme, wie z.B. Banking Anwendun-

gen, bei denen die Verfügbarkeit eine geringere Rolle spielt als die Konsistenz (Abbildung

2.3b). Falls zum Beispiel ein Geldautomat keine Verbindung mehr zum System aufbau-

en kann, wird dieser gesperrt bis er wieder eine Verbindung hat. Das geschieht durch

pessimistische Protokolle. Zu diesem Systemen gehören auch die klassischen verteilten

Datenbanken mit Primary Copy Replikation (Abschnitt 2.2).

AC-Systeme - Verzicht auf Partitionierungstoleranz Die Garantie auf Konsistenz und Ver-

fügbarkeit bedeutet in diesem System den Verzicht auf Partitionierungstoleranz (Abbil-

dung 2.3c). Das heißt, dass verschiedene Knoten K immer auf die Daten D zugreifen kön-

nen und D dabei gleich bleibt. Bei einem Netzausfall, kann die Garantie der Konsistenz

theoretisch nicht mehr gegeben sein, falls ein Knoten seine Daten ändern möchte. Hier

kommen Protokolle wie das 2PC (Abschnitt 2.5) zum Einsatz. Dieser fordert, dass bei

einer Aktualisierung alle relevanten Knoten erreichbar sind und sie diese auch durchfüh-

ren können. Ein Beispiel solcher Systeme ist eine einzelne Datenbank in einem verteilten

System. Auch Cluster-Datenbanken sind eng miteinander gekoppelt und benötigen eine

vollständige Verbindung.

a

C A

P

b

C A

P

c

C A

P

Abbildung 2.3.: Das CAP-Theorem.

2.2. Replikation

Eine Replikation ist "die kontrollierte, mehrfache Speicherung von Teilen des Datenbestan-

des" [2, S. 285]. Es gibt verschiedene Gründe weshalb in einem verteilten System Datenbanken

repliziert werden:

System availability (dt. System Verfügbarkeit). Es reduziert die Wahrscheinlichkeit ei-

nes Single Points of Failure, da die Daten bei einem Ausfall eines Knotens noch erreichbar

sind.

Replikation 7

Performance (dt. Leistung). Bei einem verteilten System kann es schnell zu einer Verzöge-

rung der Antwort kommen. Hier gilt die Kommunikation als beitragender Faktor. Wären

die Daten nicht lokal als Replikation vorhanden, so müsste ein Knoten diese erst von

einem anderen Knoten anfordern, was zusätzliche Kommunikation erfordert und einen

Overhead produziert.

Scalability (dt. Skalierbarkeit). Ein geographisch wachsendes System profitiert durch Re-

plikationen mit geringeren Antwortzeiten der Knoten.

Application requirements (dt. Anwendungsanforderung). Anwendungen können Repli-

kate fordern, damit diese überhaupt ihre Anforderungen durchführen können.

Die Nachteile einer replizierten Datenbank variieren je nach Architektur des Systems. Un-

umstritten ist, dass replizierte Datenbanken einen erhöhten Speicherbedarf erfordern und dass

die Replikate auf dem gleichen Stand gehalten werden müssen. Dieser Aktualisierungsaufwand

hängt von den folgenden Entscheidungen ab:

Datenbankendesign. Bei einer verteilten Datenbank gibt es die Möglichkeit die Daten voll-

ständig oder partiell zu replizieren. Bei einer partiellen Replikation kann es dazu kommen,

dass es Daten gibt, die kein Replikat besitzen. Diese Daten haben den Vorteil, dass die

Transaktionen lokal verlaufen (Local Transactions). Bei den replizierten Daten muss die

Transaktion hingegen an mehreren Knoten durchgeführt werden (Global Transactions).

Datenbankkonsistenz. Bei einer global transaction kann es dazu kommen, dass die Replikate

zu einem Zeitpunkt t unterschiedlich sind. Diesen Zustand nennt man Mutually Consis-

tent. Hier gibt es zwei unterschiedliche Kriterien, Strong Consistency (dt. starke Konsis-

tenz) und Weak Consistency (dt. schwache Konsistenz). Bei der starken Konsistenz wird

sichergestellt, dass es eine wechselseitige Konsistenz gibt, bei einer schwachen Konsis-

tenz kann es dazu kommen, dass Daten nicht konsistent sind.

Wo werden Aktualisierungen durchgeführt. Es muss entschieden werden, wo die Aktuali-

sierung zuerst durchgeführt wird. Hier gibt es verschiedene Methoden: Bei der Centralized

(dt. zentralen) Methode wird eine sogenannte Master Copy zuerst aktualisiert. Des Weite-

ren gibt es die Distributed (dt. verteilte) Methode, die eine Aktualisierung überall erlaubt.

Bei der zentralen Methode kann noch unterschieden werden zwischen Single Master und

Primary Copy. Beim Single Master existiert eine einzige Master Datenbank im System,

welche zuerst aktualisiert wird und diese Änderung dann anschließend an die anderen Re-

plikate (Slaves) verteilt. Bei der Primary Copy kann es jedoch sein, dass die Master Copies

auf unterschiedlichen Datenbanken sind.

8 Replikation

Aktualisierungsverteilung. Nachdem ein Datensatz aktualisiert wurde, muss diese Aktuali-

sierung an die anderen Replikate verteilt werden. Es gibt die Möglichkeit die Änderung

am Datensatz den anderen Replikaten sofort mitzuteilen (Eager) oder die Änderung wird

zu einem späteren Zeitpunkt mitgeteilt (Lazy).

Grad der Replikationstransparenz. Zuletzt muss noch entschieden werden wie stark die Trans-

parenz sein soll. Protokolle, die von der Anwendung verlangen zu wissen wo der Master-

Knoten ist, in welchem die Transaktionen durchgeführt werden, nennt man Limited Repli-

cation Transparency (dt. beschränkte Replikations-Transparenz). Die anderen Protokolle

stellen einen Transaktionsmanager (TM) bereit. Jeder Knoten besitzt einen TM, welcher

von der Anwendung die Transaktionen zugestellt bekommt. Diese Protokollart gehört zu

den Fully Replication Transparency Protokollen.

Damit nachvollzogen werden kann, warum eine bestimmte Entscheidung getroffen wurde,

werden in den folgenden Kapiteln die vorhin genannten Begriffe erläutert. Anschließend werden

die Protokolle vorgestellt. [1, S. 459-495] [2, S. 285-300]

2.2.1. Aktualisierungsverwaltung Strategien

Wie anfangs erwähnt, können Aktualisierungen zeitlich gesehen unterteilt werden in Lazy und

Eager. Zusätzlich gibt es noch die Unterscheidung, wo die Aktualisierungen durchgeführt wer-

den - zentral oder verteilt. Diese Einteilungen gehören zu den Update Management Strategien.

In diesem Abschnitt wird nun auf diese Entscheidungen eingegangen und die Funktionsweise

erklärt.

2.2.1.1. Sofortige Aktualisierungsverteilung: Eager

Wenn Änderungen an Daten sofort synchronisiert werden sollen, dann spricht man von einer

Eager Propagation. Das bedeutet, dass sobald eine Transaktion vollständig durchgeführt wurde

(Commit), der Datensatz auf allen Replikaten aktuell ist. Meistens wird hierfür das 2 Phase

Commit Protokoll (Abschnitt 2.5) verwendet, das später noch vorgestellt wird. Aufgrund der

Tatsache, dass eine Anwendung davon ausgehen kann, dass ihre Daten stets aktuell sind, kann

diese bei einem Read Zugriff auf ihre lokale Replikation zugreifen. Bei einem Write Zugriff

muss die Anwendung dafür auf alle Replikate zugreifen können. Protokolle dieser Art gehören

zu den Read-One/Write-All (ROWA) Protokollen.

Die Vorteile von Eager sind der geringere Kommunikationsaufwand bei einem Lesezugriff

und die stets aktuellen Daten. Damit die Daten immer aktuell sind, muss jedes Replikat aktua-

lisiert werden. Dies erfordert einen großen Kommunikationsaufwand. Bei einem Ausfall oder

Replikation 9

einer Absage eines Knotens kann auch keine Aktualisierung erfolgen. [1, S. 465]

2.2.1.2. Verzögerte Aktualisierungsverteilung: Lazy

Im Gegensatz zur Eager Propagation steht Lazy. Bei einer Aktualisierung am Datensatz wird

hier nicht auf die Zustimmung der anderen Replikate gewartet. Der Commit wird sofort durch-

geführt nachdem das Replikat aktualisiert wurde und die Verteilung der Aktualisierung geschieht

dann asynchron. Der Domain Name Service (DNS) ist ein Beispielprotokoll, welches das Lazy

Verfahren anwendet. Aufgrund der geographisch großen Abstände von Knoten, wird auf eine

konsequente Konsistenz der Daten verzichtet und wodurch schnelle Reaktionszeiten des Sys-

tems ermöglicht werden.

Genau hier liegen die Vorteile des Lazy Verfahrens: bei der schnellen Reaktionszeit des Sys-

tems. Aufgrund des zügigen Commits und der erst danach von Statten gehenden Verteilung der

Aktualisierungen, kann das System schneller reagieren. Hier entsteht aber auch der Nachteil des

Lazy Verfahrens. Aufgrund der verzögerten Verteilung der Aktualisierungen sind die Daten im

Netzwerk nicht immer aktuell. Dieser Umstand kann später zu Konflikten führen. [1, S. 466]

2.2.1.3. Zentrale Aktualisierungsverteilung

Bei der zentralen Aktualisierungspropagation wird zuerst eine Master Copy aktualisiert und

anschließend die anderen Replikate (Slaves). Die Master Copy liegt auf dem Master Site und

der Knoten, auf dem ein Slave gespeichert ist, ist der Slave Site. Wie am Anfang des Kapitels

bereits erläutert, wird hier nochmals unterteilt in Single Master und Primary Copy. Beim Single

Master existiert genau eine Datenbank für alle Master Copies. Im Gegensatz dazu kann es bei der

Primary Copy dazu kommen, dass die Master Copy auf unterschiedlichen Datenbanken liegen.

Aufgrund der zentralen Anlaufstelle zur Aktualisierung von Daten, ist es nicht nötig die Daten

zu synchronisieren. Das heißt, dass ein Replikat lediglich die Aktualisierung der neuen Version

erhalten muss, womit die Anwendung einfacher gehalten wird. Als Nachteil sind hier die Client/-

Server Nachteile aufzuzählen. Der Master Site kann überladen werden und es entstehen dadurch

längere Wartezeiten. Im schlimmsten Fall fällt der Master Site aus und die Aktualisierung eines

Datensatzes findet nicht statt. [1, S. 466-477]

2.2.1.4. Verteilte Aktualisierungsverteilung

Durch eine verteilte Aktualisierungsverteilung kann jeder Knoten seine Replikate lokal aktua-

lisieren. Von hier aus wird die Aktualisierung an alle Knoten verteilt. Das bedeutet, dass un-

terschiedliche Transaktionen auf Replikate desselben Datensatzes durchgeführt werden können.

10 Replikation

Diese Lastenverteilung führt zu einem insgesamt schnelleren System mit einer bessern Verfüg-

barkeit. Dies geht zu Lasten der Komplexität für die Anwendung. Weil Replikate eines gleichen

Datensatzes unterschiedliche Transaktionen erhalten, kommt es bei der Synchronisation zu Kon-

flikten. Diese Konflikte erfordern dann eine Auflösung, die der Anwender im schlimmsten Fall

per Hand durchführen muss. In Kombination mit dem Lazy Verfahren, kann es dann auch noch

zu einer Vertauschung der Reihenfolge von Transaktionen kommen, was wiederum mehr Auf-

wand bei der Konfliktauflösung verursacht. [1, S. 467]

2.2.2. Replikations Protokollarten

Im letzten Abschnitt wurden Strategien zur Verwaltung von Aktualisierung vorgestellt. In die-

sem Kapitel werden nun die Replikationsansätze klassifiziert, indem die vorgestellten Strategien

miteinander kombiniert werden. Die geschieht nach den zeitlichen und örtlichen Eigenschaften

der Strategien. Dadurch entstehen insgesamt vier Klassifizierungen, die nun vorgestellt werden

(Abbildung 2.9 fasst die vier Klassifikationen kurz zusammen).

2.2.2.1. Zentral-Synchron

Bei dieser Klassifikation gibt es eine unverzügliche Aktualisierung der Primary Copy. Diese

wiederum wird dann durch den Master Site an die Slave Sites verteilt. Der Master Site muss

also alle Anfragen verwalten, bearbeiten und gleichzeitig die Reihenfolge der Aktualisierungen

einhalten. Das kann unter anderem durch einen Lock (Abschnitt 2.3) realisiert werden, verur-

sacht jedoch längere Antwortzeiten. Die ganze Verteilung der Aktualisierung erfolgt mithilfe

des ACID Konzepts, da die Konsistenz gewahrt werden muss. Das ACID Konzept wird später

im Abschnitt 2.4 vorgestellt. Um Nachteile der Zentralisierung auszugleichen, kann bei einem

Ausfall des Master Sites ein Ersatzknoten dessen Rolle übernehmen. Im Englischen wird diese

Klassifikation Eager Primary Copy genannt.

Die Abbildungen 2.4 und 2.5 veranschaulichen den Unterschied zwischen der zentralen Syn-

chronisation durch einen Master Site und einer Primary Copy. Wie schon erklärt, gilt bei der

Centralized Methode (Abbildung 2.4), dass es eine einzige Datenbank gibt die alle Master Co-

pies beinhaltet. Hier werden alle Transaktionen mit Schreib-Operationen weitergeleitet (genauer,

an den TM des Master Sites) und durchgeführt. Anschließend werden die Aktualisierungen an

alle Slaves propagiert. Die Methode der Primary Copy (Abbildung 2.5) erfordert etwas mehr

Achtsamkeit. Hier muss zwischen einer vollständigen oder einer partiellen Replikation unter-

schieden werden. Im Unterschied zum Centralized Verfahren wird die Transaktion nicht an den

TM der Primary Copy weitergeleitet, sondern der TM, der die Transaktion in Auftrag gibt, leitet

diese selber an den Knoten der Primary Copy weiter.

Replikation 11

Abbildung 2.4.: Eager Single Master Replication Protocol Actions. (1) Ein Write wird an der Master Copyangewandt. (2) Der Write wird an alle Slaves propagiert. (3) Die Aktualisierung ist durchden Commit nun dauerhaft gespeichert. (4) Reads können lokal am Slave durchgeführtwerden. [1, S. 469]

.

Erklärung zur Abbildung 2.5: Knoten A, besitzt die Master Copy für das Objekt x und die

Knoten B und C haben die Slaves gespeichert. Ähnlich ist es mit dem Objekt y, wo der Knoten

C die Master Copy gespeichert hat und die Knoten B und D die Slaves. [1, S. 459-495] [2, S.

285-300]

Abbildung 2.5.: Eager Primary Copy Replication Protocol Actions.(1) Writes oder Reads an jedem Ob-jekt, werden an die Master Copy weitergeleitet. Der Write wird zuerst bei der MasterCopy durchgeführt. (2) Der Write wird dann an alle Slaves propagiert. (3) Durch denCommit sind nun alle Änderungen dauerhaft gespeichert. [1, S. 473]

.

12 Replikation

2.2.2.2. Verteilt-Synchron

Bei einem verteilt-synchronen Protokoll wird eine Aktualisierung lokal durchgeführt und an-

schließend an alle Replikate propagiert. Es kann der Fall auftreten, dass der Knoten das Replikat

gar nicht besitzt, hier wird die Transaktion an einen Knoten weitergeleitet, der das Replikat

besitzt. Nach einem erfolgreichen Commit wird der Nutzer anschließend benachrichtigt. Diese

Klassifikation nennt man auch Eager Update Anywhere. Die Konsistenz der Daten wird durch

das ACID Konzept bewerkstelligt.

Zwar gibt es bei dieser Klassifikation keinen Flaschenhals mehr, der alle Transaktionen alleine

durchführt, dafür kommt es jedoch zu Wartezeiten. Diese können länger werden, falls Knoten

ausfallen. Im schlimmsten Fall können Deadlocks entstehen, welche aufwendig zu lösen bzw.

zu erkennen sind.

Die Abbildung 2.6 veranschaulicht die Operationen, die bei den Klassifikationen durchgeführt

werden. Es existiert für ein Objekt x Replikationen auf den Knoten A, B, C und D und zwei

Transaktionen zu diesen Replikaten. Jeweils am Knoten A und D. Es fällt hier auf, dass die

Schwierigkeit darin besteht, sicherzustellen, dass die Schreib-Operationen die unterschiedlich

sind und gleichzeitig initialisiert werden, in der richtigen Reihenfolge abgearbeitet werden. [1, S.

459-495] [2, S. 285-300]

Abbildung 2.6.: Eager Distributed Replication Protocols Action. (1) Zwei Writes werden an zwei loka-len Replikationen desselben Datensatzes/Objekts durchgeführt. (2) Die beiden Writeswerden unabhängig voneinander an alle anderen Replikationen propagiert. (3) Die Ak-tualisierung ist nun permanent gespeichert (nur für die Transaktion 1 verdeutlicht). [1, S.474]

.

Replikation 13

2.2.2.3. Zentral-Verzögert

Die verzögerte Aktualisierung mithilfe einer Primary Copy ähnelt der Klassifikation Zentral-

Synchron. Bei beiden geschieht eine Aktualisierung des Datensatzes am Master Site. Der Un-

terschied liegt am zeitlichen Faktor. Hier wird die Propagation nicht innerhalb der Transaktion

durchgeführt, sondern erst danach. Das heißt, dass am Master Site die aktualisierte Master Copy

committed wird und diese Information erst mithilfe einer Aktualisierungstransaktion verzögert

an alle Slaves Propagiert wird (Abbildung 2.8). Daraus folgt, dass falls ein Lesezugriff an einem

der Slaves erfolgt, es passieren kann, dass veraltete Daten gelesen werden. Bei der Erstellung der

Aktualisierungstransaktion muss dringend auf die Reihenfolge der Operationen geachtet wer-

den, da es sonst zu Konflikten kommen kann. Dies kann zum Beispiel mithilfe von Zeitstempeln

oder mit fortlaufenden Transaktionsnummern geschehen.

Wie schon genannt, ist die nicht gegebene, konsequente Konsistenz ein Nachteil dieser Klas-

sifikation. Diese abgeschwächte Konsistenz wird auch als Eventually Consistency genannt, was

später nochmal genauer erläutert wird. Genau aus diesem Problem folgt ein weiteres Problem.

Fällt nämlich ein Master Site aus, so muss ein Slave Site dessen Rolle übernehmen. Jedoch weiß

der Slave Site, der nun ersatzweise den Master Site spielt, nicht wie weit die Transaktion an

einer Primary Copy von statten ging und das System somit einen Commit verpassen kann. [1, S.

459-495] [2, S. 285-300]

Abbildung 2.7.: Lazy Single Master Replication Protocol Actions. (1) Die Aktualisierung wurde am lo-kalen Replikat angemeldet. (2) Die Transaktion wird committed und somit permanentgespeichert. (3) Eine Aktualisierungstransaktion wird an die Slaves geschickt. (4) Trans-aktion 2 liest ein lokales Replikat [1, S. 475]

.

14 Locks

2.2.2.4. Verteilt-Verzögert

Lazy Update Anywhere, die verzögerte Aktualisierung von Replikaten, die von jedem Knoten aus

starten kann, ist die komplexeste der vier Klassifikationen. Die Prozessfolge ist relativ simpel:

Lese- und Schreib-Operationen werden am lokalen Replikat durchgeführt, gleiches gilt für eine

Transaktion und dem Commit. Anschließend wird eine Aktualisierungstransaktion verzögert an

alle Replikate propagiert (Abbildung 2.8).

Aufgrund der Tatsache, dass jeder Knoten seinen Commit unabhängig von anderen Knoten

durchführen kann und diese auch noch verzögert den anderen Knoten mitteilt, kann es zu Kon-

flikten kommen. Diese Konflikte gilt es zu lösen und stellen sich hier als ein größeres Problem

dar. Im schlimmsten Fall führen Konflikte zu Datenverlusten. Um diese Konflikte aufzulösen

erfordert es an Schlichtungstechniken. [1, S. 459-495] [2, S. 285-300]

Abbildung 2.8.: Lazy Distributed Replication Protocol Actions. (1) Zwei Aktualisierungen werden anzwei lokalen Replikaten angewandt. (2) Die Transaktion wird commited und damit dieÄnderung permanent gespeichert. (3) Die Aktualisierungen werden unabhängig vonein-ander an alle anderen Replikate propagiert [1, S. 481]

.

2.3. Locks

Mit Locks sperrt man das Bearbeiten eines Datensatzes durch einen Prozess. Mit einem Lock

versehen werden können hierbei Tabellen, Datenreihen, gecachte Daten, Verbindungen oder das

gesamte System. Auf die Datensätze hat ein anderer Prozess dann weder lesende noch schreiben-

de Rechte, diese Art von Lock nennt sich Read-Write-Lock. Dann gibt es noch den Write-Lock,

der einem Prozess nur den lesenden Zugriff erlaubt.

ACID 15

+ starke Konsistenz- potentiell lange AntwortzeitEager

(synchron)

Lazy(verzögert)

Primärkopie Verteilt

+ einfache Synchronisation

- unflexibel

+ flexibel

- komplexe Synchronisation

+ einfache Synchronisation+ meistens schnell

- veraltete Daten- unflexibel

+ flexibel+ immer schnell

- Inkonsistenzen- Konfliktauflösung notwendig

A B

C D

Abbildung 2.9.: Klassifikation von Replikationsansätzen [2, S. 287].

Der Vorteil eines Locks liegt ist die gezielte Vermeidung von Konflikten. Durch die Zugriffs-

berechtigung muss immer erst geprüft werden ob ein Prozess ein Recht auf Zugriff hat oder

nicht. Dadurch können Wartezeiten entstehen, da ein Prozess auf die Genehmigung des Zu-

griffs wartet. Bei großen zusammenhängenden Programmabläufen könnte die Leistung eines

Systems stärker auswirken. Ein nicht zu vernachlässigender Nachteil wäre ein Deadlock. Bei

einem Deadlock hat kein beteiligter Prozess mehr Zugriffsrechte auf einen Datensatz und die-

se müssen auf die Freigabe des Datensatzes durch einen anderen Prozess warten. Dieser Fall

trifft meistens nur ein, wenn bei der Entwicklung des Programms logische Fehler unterlaufen

sind. [5], [9]

2.4. ACID

ACID wurde abgeleitet von den Worten Atomicity, Consistency, Isolation und Durability. Die

Bedeutung der Begriffe wird nun folgend erläutert:

Atomicity (Atomarität). Wird auch das Alles oder Nichts Prinzip genannt. Es bedeutet im

16 2 Phase Commit

Grunde genommen, dass wenn während einer Transaktion in einem Prozessfluss ein Feh-

lerauftritt, alle bisher getätigten Transaktionen zurückgesetzt werden. Die Zurücksetzung

von Transaktionen ist nur dadurch möglich, dass alle Informationen geloggt werden und

bei einem Fehler abrufbar sind.

Consistency (Konsistenz). Ist die Widerspruchsfreiheit eines Datensatzes, welche vor und

nach einer Transaktion gelten muss.

Isolation. Ein Datensatz wird gegen mehrere gleichzeitige Operationen geschützt und damit

isoliert. Dies wird durch Synchronisationsmaßnahmen erreicht.

Durability (Dauerhaftigkeit, Persistenz). Gilt für alle erfolgreich durchgeführten Transak-

tionen. Das bedeutet, dass die Daten gespeichert werden und Fehler, wie beispielsweise

Systemabstürze, überleben können.

Anhand von Abbildung 2.10 wird ein System welches das ACID Prinzip nutzt graphisch veran-

schaulicht. Mithilfe eines Transaction Manager beginnt (1) und endet (3) eine Anwendung eine

Transaktion. Diese sind in mehreren Operationen unterteilt (2), welche zusammen die Transak-

tion beschreiben und auf unterschiedlichen Datenbanken ablaufen können. Damit diese Daten-

banken auch die angeforderten Operationen durchführen können, haben diese einen Resource

Manager, der beim Transaction Manager registriert ist. Sie müssen zudem eine gemeinsame

Schnittstelle aufweisen, damit die Transaktionen vollständig vonstattengehen können (4), z.B.

das X/Open XA Interface 9 [3]. Bei einem verteilten System wird das ACID Prinzip durch ein

Verfahren wie das Zwei-Phasen-Commit (2PC) unterstützt, das im nächsten Abschnitt vorge-

stellt wird. [10], [11]

2.5. 2 Phase Commit

Das 2 Phase Protocol (Zwei-Phasen-Commit, 2PC) wird eingesetzt um die Konsistenz der ver-

schiedenen Datenbanksysteme zu sichern. Das geschieht durch die zwei Phasen, Vorbereitungs-

und Commitphase. Im Folgenden werden die Akteure Koordinator und Agenten genannt. In der

Vorbereitungsphase sendet der Koordinator dem Agenten eine Nachricht mit dem Transaktions-

wunsch. Die Agenten lehnen diesen entweder ab oder stimmen diesem zu. Bei Zustimmung aller

Agenten folgt dann die Commitphase. Hier teilt der Koordinator den Agenten das Ergebnis der

Transaktion mit. Bei nur einer negativen Antwort der Agenten in der Vorbereitungsphase, wird

die Transaktionsphase nicht durchgeführt.

Nachteil des Verfahrens ist die längere Blockade des Transaktionsprozesses. Durch Kommu-

nikationsfehler, Timeouts, oder nicht erreichbare Agenten bzw. nicht erreichbaren Koordinator

Voting 17

the following three:

1. A blockchain is a peer-to-peer protocol for trust-less execution and recording of transactions se-cured by asymmetric cryptography in a consistentand immutable chain of blocks – the blockchaindevelopers and technology view.

2. A blockchain is a shared append-only distributeddatabase with full replication and a cryptographictransaction permissioning model – the IT architectand data management view.

3. A blockchain is a shared decentralized ledger, en-abling business disintermediation and trustless in-teractions, thereby lowering transaction costs –the business executive and applications view.

With each of these three definitions, a differentemphasis is set, focusing either on the protocol aspect,the data management aspect, or the decentralizationaspect of blockchains. Yet, all three definitions makeuse of the term transaction. In the following, we thustake a closer look at what a transaction is and howsuch transactions traditionally have been supported bytransaction processing systems.

3 TRADITIONALTRANSACTIONS AND TPSYSTEMS

A (business) transaction, in its most generic sense andas used in commerce, is an instance of buying or sell-ing something. In computer science, a transaction isa logical unit of work performed within a transactionprocessing system (TP system). A TP system, in turn,refers to an information processing system that di-vides all processing work into transactions, in a waythat each transaction can be guaranteed a set of prop-erties by the system.

3.1 Understanding ACID

In the 1980s, relational database management sys-tems (RDBMS) based on Codd’s relational modelwere first introduced. With the addition of TP tech-nologies to RDBMS a few years later, originally pro-posed by Jim Gray, the acronym “ACID transaction”was born (Gray and Reuter, 1992). ACID refers to aset of guarantees for each transaction to be processedby the TP system: Atomicity, Consistency, Isolation,and Durability.

ACID has since been understood as a very conve-nient model:

• A transaction consisting of multiple operations isexecuted as a whole or not at all (“all or nothing”).

• Each transaction transforms the database fromone consistent, valid state to another, adheringto all validation rules and database integrity con-straints.

• Concurrent transactions are executed by maintain-ing isolation, that is, by executing them as if theywere sequential.

• Once a transaction has been committed, the re-sults become permanent.The responsibilities to achieve the ACID proper-

ties are spread across different components of a TPsystem (Bernstein and Newcomer, 2009). A transac-tion manager component typically is required to drivecoordination protocols among the resource managers,for example, the 2PC completion protocol. Consis-tency is a responsibility of components that performvalidation checks, for example, by using the rulesof the database itself. Isolation requires some con-currency control, which typically relies upon lockingprotocols such as the 2PL. And durability typically isa responsibility of the database itself.

Figure 1 illustrates a TP system in support ofACID transactions. An application interacts withthe transaction manager to begin (1) and end (3) atransaction as a logical unit-of-work. Each transac-tion groups a set of operations (2) on one or moredatabases (resources). For each resource involvedin a transaction, a resource manager component ex-ists. The resource managers must be registered withthe transaction manager and must understand proto-cols and provide interfaces in support of transactionprocessing, e.g., the X/Open XA interface, so thatthe transaction manager can run completion protocolswhen committing the transaction (4).

Resource Manager

Resource Manager

Transaction Manager

Application

Resource Resource

1 3

Tx interface

4

XA interface

XA interface

RM2 interface

RM1 interface

2

Figure 1: Architecture of a TP system supporting ACIDtransactions.

Guaranteeing the ACID properties implies that

Abbildung 2.10.: Architektur eines Systems welches das ACID Prinzip unterstützt [3].

wird die Wartezeit verlängert. [10], [11]

2.6. Voting

Um beim Voting Zugriff auf ein Datensatz zu erhalten, muss vorerst eine ausreichende Anzahl

an Stimmen (Votes) gesammelt werden. Dafür gibt es zwei Varianten, Majority und Read One

Write All.

Majority Um ein Schreibrecht zu erhalten, muss es eine Mehrheit an Stimmen dafür geben.

Dadurch ist sichergestellt, dass es keine zweite Instanz gibt, die Lese- bzw. Schreibrechte

holt. Für das Erlangen von Leserechten bedarf es ebenfalls einer Mehrheit. Es wird dann

auf ein aktuellen Datensatz referenziert. Der Vorteil hierbei ist die Erreichbarkeit der Da-

ten. Datensätze sind noch referenzierbar, solange es eine Mehrheit der Kopien (Replikate)

gibt. Ein erheblicher Nachteil dieses Verfahrens ist der hohe Kommunikationsaufwand für

Lese- und Schreibzugriffe.

Read One Write All (ROWA) Es ist keine Erlaubnis erfoderlich, um eine lokale Read Ope-

ration durchzuführen, wohingegen bei einer Write Operation alle Knoten involviert wer-

18 Last-Write-Wins

den müssen.

Durch die Mehrheit an Stimmen werden bei diesem Verfahren Konflikte umgangen. Allerdings

verursacht dieses Verfahren einen hohen Kommunikationsaufwand. Für den Akteur muss auch

die Anzahl der nicht erreichbaren Konten, die dennoch am System teilnehmen, bekannt sein.

Bei einem dynamischen System führt dies zu erneuten Problemen, da die genaue Anzahl der

Knoten aktuell gehalten werden muss. Des weiteren ist es nicht möglich, eine Mehrheit zu er-

langen, wenn mindestens die Hälfte der Knoten ausgefallen ist, das heißt, wenn Datensätze nicht

beschrieben oder gelesen werden können. [12] [5]

2.7. Last-Write-Wins

Aus dem Englischen übersetzt bedeutet Last-Write-Wins: "Zuletzt geschriebenes gewinnt". Bei

dieser Methode wird bei der Synchronisierung der Datensätze kontrolliert, welche Version die

neuste ist und diese für alle Teilnehmer übernommen. Als Voraussetzung gilt, dass alle Uhren

synchron laufen müssen. Vorteil ist die einfache Implementierung des Verfahrens. Durch die

Ignoranz aller älteren Einträge, kann es jedoch zu ungewollten Datenverlusten kommen.

Alle theoretischen Ansätze haben Vor- und Nachteile. Sie versuchen das Problem der man-

gelnden Konsistenz zu lösen, jedoch grenzen sie die Konsistenz lediglich ein. Im übernächsten

Abschnitt werden einige praktische Lösungen vorgestellt, durch die die Konsistenz der Daten

erhalten werden kann. Zunächst aber wird das TCP/IP Referenzmodell vorgestellt.

2.8. TCP/IP-Referenzmodell

In diesem Abschnitt wird erläutert welche Möglichkeiten Computer haben sich zu kommunizie-

ren und wie diese von statten geht. Damit Computer sich gegenseitig verstehen können müssen

diese Regeln einhalten, die in Protokollen festgesetzt werden. Diese Protokolle sind sehr kom-

plex und werden daher in Referenzmodellen überschaubar dargestellt. Zu den meist verbreiteten

Referenzmodellen gehören das ISO/OSI-Referenzmodell (Open Systems Interconnection) und

das TCP/IP-Referenzmodell (Transmission Control Protocol/Internet Protocol). Als Praxistaug-

licher hat sich letzteres erwiesen und wird daher deutlich mehr genutzt [13, S. 1].

Das TCP/IP-Referenzmodell ist heute "Defacto-Standard in der Rechnerkommunikation im

Internet" [14, S. 1]. Folgend (Die vier Schichten des TCP/IP-Referenzmodell mit ihren Aufga-

ben und Protokollen.) sind die vier Schichten mit einer kurzen Erläuterung zur ihrer Aufgabe

aufgelistet: [4, S. 7], [14, S. 2].

TCP/IP-Referenzmodell 19

Schicht Aufgabe Protokolle

Anwendung Datenübertragung verläuft anhand von strukturierten Da-ten.

FTP, HTTP etc.

Transport Die Paketübertragung erhält eine feste Verbindung zwi-schen zwei Anwendungen, die Adressen der Anwendun-gen werden als Port gespeichert.

TCP, UDP

Internet Datenübertragung über Datenpakete anhand von IP-Adressen. Gegebenenfalls muss das Paket in ein anderesNetzwerk geroutet werden.

IPv4, IPv6

Netzwerk Datenübertragung innerhalb eines Netzwerksegments.Dabei wird ein Datenpaket zwischen zwei MAC-Adressenverschickt. Es wird auch geregelt welcher Teilnehmerwann senden darf und ob dabei Übertragungsfehler entste-hen. Es wird auch die physikalische Eigenschaft der Über-tragung beschrieben.

Ethernet, WLAN

Tabelle 2.1.: Die vier Schichten des TCP/IP-Referenzmodell mit ihren Aufgaben und Protokollen.

Nachdem der Aufbau des Referenzmodells erklärt wurde, kann im nächsten Abschnitt nun

der Vorgang des Nachrichtenversandes beschrieben werden.

2.8.1. Nachrichtenversand

Der Nachrichtenversand über dem TCP/IP-Referenzmodell verläuft, wie im vorigen Kapitel be-

schrieben, über vier Schichten. In jeder Schicht wird ein Header erzeugt, der der Nutzdatennach-

richt beigefügt wird. Somit entstehen vier Header für den Nachrichtenversand. Diese beinhalten

jeweils Kontroll- und Steuerinformationen, welche der jeweiligen Empfängerschicht bereitste-

hen. Darauf wird in dieser Arbeit aber nicht genauer eingegangen. Für die eigentliche Nachricht

bedeutet es, dass diese beim Sender alle vier Schichten durchquert und bei jeder einen Hea-

der hinzu bekommt. Dadurch entsteht ein Protokollstack. Die letzte Schicht, die Netzwerkzu-

gangsschicht schickt die Nachricht an den nächsten Knoten weiter, welcher den Protokollstack

von oben nach unten interpretiert, bis die eigentlich zu sendende Nachricht gelesen wird. In

Abb. 2.11 wird das dies nochmal verdeutlicht.

Bei einem, wie in dieser Arbeit entwickelten, dezentralen Kalender stellt sich nun die Frage,

welches Protokoll in der Transportschicht genutzt werden sollte. Für die Internetschicht und die

Netzwerkschicht, wird dies automatisch vom System bestimmt und erfordert keiner manuellen

Konfiguration. Für die Anwendungsschicht muss keine spezielle Protokollart genutzt werden,

20 TCP/IP-Referenzmodell

da es in dieser Arbeit für die Datenübertragung eine eigene Implementierung geben wird.8 1 Einführung

Header Anwendung

Daten

Header Transport

Header Anwendung

Daten

Header Transport

Header Anwendung

Daten

Header Netzwerk

Header Transport

Header Anwendung

Daten

Header Netzwerk

Header Netzzugang

Header Anwendung

Daten

Header Transport

Header Anwendung

Daten

Header Transport

Header Anwendung

Daten

Header Netzwerk

Header Transport

Header Anwendung

Daten

Header Netzwerk

Header Netzzugang

Anwendungsschicht(Anwendungs- + Darstellungs-

+ Sitzungsschicht)

Transportschicht

Netzwerkschicht(Vermittlungsschicht)

Netzzugangsschicht(Sicherungsschicht +

Eigentlicher Kommunikationsweg

Beispiel: TCP/IP

Beispiel: HTTP

Beispiel: IP

Beispiel: Ethernet

Abb. 1.1 Das TCP/IP-Schichtmodell

fach Bytes oder Bytestreams übertragen, ohne sich um derenBedeutung zu kümmern, kann diese Schicht strukturierte Daten,wie beispielsweise den Namen und die dazugehörige Telefon-nummer übertragen.

Netzwerkanwendungen implementieren meist eine eigene An-wendungsschicht und setzen damit auf der Transportschicht auf.Damit sind sie unabhängig von den tieferen Schichten, so dassbeispielsweise in der Netzzugangsschicht die unterschiedlichstenphysikalischen Netze eingesetzt werden können, ohne in die An-wendungen eingreifen zu müssen: 100Mbit-Kabel, WLAN, Glas-faserleitungen, PPP usw.

1.4.2 Java

Die Standard-Java-Bibliotheken können auch als Schichtmodellbetrachtet werden.

Abbildung 2.11.: Das TCP/IP-Referenzmodell [4, S. 8]

2.8.2. Transportschicht

In dieser Schicht gibt es Hauptsächlich zwei Protokolle, TCP und UDP. Alle anderen Protokolle

sind im Eigentlichen Abwandlungen von den beiden genannten Protokollen. Folgend nun beide

Protokolle vorgestellt: [4] [15]

TCP (Transmission Control Protocol) - Zuverlässiges, verbindungsorientiertes, paketver-

mittelndes Protokoll:

Beim TCP Protokoll wird immer eine Verbindung zwischen zwei Knoten aufgebaut. An-

hand dieser Verbindung wird ein unendlich langer Datenstrom in einzelne Pakete aufge-

teilt, welcher für jede Verbindungsrichtung jeweils einmal zur Verfügung gestellt wird. Es

wird sichergestellt, dass die versendeten Pakete zum Zielknoten vollständig und in richti-

TCP/IP-Referenzmodell 21

ger Reihenfolge ankommen. Jedes Paket bekommt einen eigenen Header (min. 20 Byte)

der Steuerungs-, Kommunikations-, Verwaltungsinformationen und die Nutzdaten enthält.

UDP (User Datagram Protocol) - Ungesichertes, verbindungsloses Protokoll:

Beim UDP Protokoll wird kein Verbindungsaufbau benötigt, einer der Knoten kann mit

dem senden der Pakete beginnen. Die zu sendenden Pakete werden auch Datagramme

genannt und erhalten ebenfalls einen Header (8 Byte) mit allen relevanten Informationen.

Das Protokoll bietet hierbei keine Kontrolle zur sicheren Ankunft der Datagramme. Das

bedeutet, dass der Sender nie weiß, ob das gesendete Datagramm am Ziel angekommen

ist. Die Datagramme haben auch keine feste Reihenfolge, es kann also passieren, dass sich

Pakete gegenseitig überholen.

Verglichen zu TCP, ist UDP bei der Datenübertragung schneller. Daher nutzen zum Beispiel

Streaminganbieter dieses Protokoll um Medien zu versenden. TCP hat dafür gegenüber von UDP

den Vorteil, dass die Daten garantiert vollständig ankommen. Vergleicht man beide Protokolle

miteinander, kommt man zum Schluss, dass TCP aufwändiger und somit langsamer ist als UDP.

Dafür bietet es Sicherheit und einen zuverlässigen Versand von Daten.

3. Aktueller Stand

In diesem Kapitel werden praktische Umsetzungen zur Datensynchronisation vorgestellt. An-

hand dieser Informationen wir ein Überblick zum aktuellen Forschungsstand gegeben.

3.1. Rsync

Der Rsync Algorithmus wurde 1996 vorgestellt und gehört somit zu den ältesten Verfahren der

Datensynchronisation. Das Grundkonzept besteht aus dem Vergleich zweier zu synchronisie-

render Datensätze. Dies geschieht durch die Erstellung sogenannter Checksums. Einer der Teil-

nehmer (A) teilt seinen Datensatz in nicht überlappende, gleichgroße Byte-Blöcke, für die er

ein Checksumpaar erstellt, mit jeweils einer starken und einer schwachen Checksumme. Die-

se sendet er dann dem anderen Teilnehmer (B). Teilnehmer B durchsucht seinen Datensatz nach

diesen Checksumpaaren ab. Bei nicht äquivalenten Datensätzen wird mindestens ein Checksum-

paar nicht gefunden und weist dem Teilnehmer B auf den Unterschied hin. Dieser sendet statt

des gesamten Datensatzes, nur den Block an Daten der sich unterscheidet und eine Anleitung

wie der geänderte Datensatz nun auszusehen hat. [16]

Der Algorithmus umgeht das Problem, dass bei einer Datensynchronisation zweier Datensät-

ze diese vollständig auf einem Knoten vorhanden sein müssen. Dadurch, dass nur Checksums

gesendet werden, ist dieser Algorithmus sehr effizient und erfordert wenig Kommunikation. Als

weiterer Vorteil gilt seine 1:1 Beziehung der Datensätze, womit Konflikte komplett vermieden

werden.

3.2. Rumor

Der Rumor Algorithmus dient zur Datensynchronisation in Peer-to-Peer Systemen. Bei der Syn-

chronisation einer Replikation, werden alle involvierten Knoten einbezogen. Bei nicht Erreich-

barkeit eines Knoten, wird dieser vorerst ausgelassen. Sobald dieser wieder erreichbar ist, er-

folgt auch hier die Datensynchronisation der Replikationen. Als Rumor 1999 vorgestellt wurde,

versuchte man mit Hilfe des selektiven Synchronisierens dem Problem der geringen Internet-

geschwindigkeit zuvorzukommen. Durch diese Art der Synchronisierung, ist es nicht nötig den

Roam 23

gesamten Datensatz einer Replikation zu speichern. Für einen korrekten Fluss der Synchronisa-

tion reicht es aus, dass nur ein Teil des Datensatzes synchron gehalten wird (Abbildung 3.1). Bei

diesem Prozess sind Konflikte nicht ausgeschlossen, können aber oft durch einen Algorithmus

automatisch gelöst werden. Kommt es durch den Algorithmus nicht zu einer Lösung, muss der

Benutzer das Problem per Hand lösen.

14 Verwandte Arbeiten

die gleiche Dateimenge abdecken mussen, sondern dass auch Teile der Dateimenge

synchron gehalten werden konnen (Abbildung 5). [GRR+99]

Replka 4

Replka 3

Replka 1 A

C

Replka 2

B

D

Abbildung 5: Datenmengenabdeckung bei einer selektiven Synchronisation.. A, B,C und D stellen die Datenteile dar. Verschiedene Replikas bilden un-terschiedliche Datenmengen ab. Die Daten sind dennoch, in diesemFall, an mindestens zwei Stellen repliziert.

2.2.3 Roam

Roam wurde extra fur mobile Gerate entwickelt. Das System wendet das Ward-

Vorgehen an, das dem Ultrapeer-System beim Gnutella-Netzwerk2 ahnelt. So haben

geografisch verteilte Replikas innerhalb einer geografischen Zone (auch Wards ge-

nannt, das fur”wide area replication domains“ steht) einen Vertreter (genannt Ward

2Gnutella ist ein Peer-to-Peer-basiertes Overlaynetzwerk, bei dem es moglich ist, Dateien auszut-auschen. Weitere Informationen uber das Flooding mit Hilfe der Ultrapeers konnen in [LHSH05]gefunden werden.

Abbildung 3.1.: Datenmengenabdeckung bei einer selektiven Synchronisation. A, B, C und D stellen dieDatenteile dar. Verschiedene Replikationen bilden unterschiedliche Datenmengen ab. DieDaten sind dennoch, in diesem Fall, an mindestens zwei Stellen repliziert. [5]

3.3. Roam

Roam ist der Nachfolger des Rumor Algorithmus. Er wurde speziell für mobile Geräte entwi-

ckelt, welche das Ward Prinzip (Wide Area Replication Domains) nutzen. Bei diesem Verfahren

existieren verschiedene Wards (geografische Zone). Jedes dieser Wards besitzt einen Vertreter,

der mit den anderen Vertretern des gesamten Systems kommuniziert. Innerhalb dieser Wards

werden die Replikationen durch einen Kommunikationsring, selbständig synchronisiert [5].

Durch diesen Unterschied zum Rumor Algorithmus, ist das Roam Verfahren besser skalierbar.

Zudem ist bei einem auftretendem Konflikt nicht direkt das gesamte System betroffen, sondern

24 Bayou

lediglich ein Ward [5].

3.4. Bayou

Bayou ist ein auf Peer-to-Peer basierendes Model und bietet Hilfe zur Konfliktlösung. Es wurde

konzipiert um verteilten Anwendungen eine Zusammenarbeit beim Lesen und Schreiben von

geteilten Datensätzen zu ermöglichen. Zu diesem Verfahren gibt es vier wichtige Fähigkeiten

die gegeben sind:

Skalierbarkeit. Um eine hohe Skalierbarkeit zu erreichen, werden bei Bayou die Kosten einer

Transaktion an einer Replikation und der Speicherverbrauch einer Replikation so gering

wie möglich gehalten, unabhängig von der Anzahl der existierenden Replikationen. Alle

Transaktionen werden bei diesem Verfahren nie mehr als zwei Knoten involvieren.

Verfügbarkeit. In diesem System kann jeder Knoten ein Server sein. Als Server gilt jeder

Knoten, der mindestens eine oder mehrere Kopien von Datenbanken besitzt. Das Verfah-

ren gibt dem System nicht vor, ob es sich hier um eine relationale oder Datei basierte

Datenbank handelt. Zugang zum Server hat jeder Client, der mit diesem eine Verbindung

aufbauen kann. Dort hat der Client sowohl Lese- als auch Schreibrechte. Durch diese Frei-

heit an Rechten, entsteht eine schwache Konsistenz. Die entstehenden Konflikte werden

dann durch eine Funktion namens Mergeproc automatisch gefunden und gelöst [17].

Erweiterbarkeit. Mithilfe von Abhängigkeitschecks und des Mergingprozesses, der genutzt

wird um Konflikte automatisch aufzulösen, wird die Erweiterbarkeit ermöglicht. Die bei-

den genannten Prozesse werden bei jedem Schreibzugriff ausgeführt und verändern sich

dabei von Aktion zu Aktion.

Anpassungsfähigkeit. Damit Änderungen am Datensatz persistent bleiben, müssen diese durch

einen sogenannten Primary Server commited werden. Ist ein Server ein Primary Server, so

ist das nicht von Dauer, da dieser sich adaptiv ändern kann. Jeder Server kann ein Primary

Server werden, sobald er den Primary Server aktualisiert hat. Bevor Daten vom Prima-

ry Server comitted werden, gelten sie als Tentative (dt. vorläufig). Wenn Knoten diese

Tentative-Daten nutzen, müssen sie in Kauf nehmen, dass diese einen Konflikt auslösen

können und als ungültig gekennzeichnet werden [5].

Die vier genannten Fähigkeiten haben eine schwachen Konsistenz zur Folge. Man stelle sich

folgendes Szenario vor:

Operational Transformation 25

• Client A aktualisiert auf Server B eine Replikation. Später benötigt A wieder das Replikat

und holt sich dieses diesmal vom Server C. Es kann aber sein, dass die aktuellen Daten

von Server B noch nicht auf dem Server C sind. Somit würde der Client A Daten einer

älteren Version lesen, obwohl dieser das Replikat selbst aktualisiert hat.

Damit solch ein Szenario nicht entsteht, werden mithilfe von „Session Guarantees“ im Bayou

System folgende vier Eigenschaften sichergestellt: [18, 19]

Read Your Writes: Lesezugriffe reflektieren vorherige Schreibzugriffe.

Monotonic Reads: Aufeinanderfolgende Lesezugriffe reflektieren eine nicht kleiner werden-

de Anzahl von Schreibzugriffen. Bei aufeinanderfolgenden Lesezugriffen ist die Version

des Datensatzes nicht sinkend.

Write Follows Reads: Schreiboperationen werden nur nach Lesezugriffen durchgeführt, da

diese davon abhängig sind.

Monotonic Writes: Datenaktualisierungen erfolgen immer auf eine ältere Version.

3.5. Operational Transformation

Operational Transformation (OT) ist ein optimistisches Verfahren, welches Knoten erlaubt, die

Replikate parallel zu bearbeiten und zu synchronisieren. Es wird Hauptsächlich an reinen Text-

dokumenten angewendet. Die Synchronisierung der unterschiedlichen Versionen einer Replika-

tion verfolgt das Ziel, das gleiche Ergebnis bei allen Knoten zu haben. Alle lokal durchgeführten

Änderungen, werden in einem Log gespeichert. Dabei gibt es die primitiven Operationsarten

Einfügen und Löschen: Ins(p,e,s) fügt ein Element e an der Position p ein; Del(p,s) löscht das

Elements an der Position p. Der Wert s ist beschreibt die Identität vom Ersteller der Operati-

on, anhand eines Ranges. Um die gleichzeitige Bearbeitung von Dokumenten zu ermöglichen,

wurde der Algorithmus Inclusive Transformation (IT) entwickelt. Dieser fasst die Operationen

unabhängig von ihrer Reihenfolge zusammen. Seien o1 und o2 zwei Operationen die gleich-

zeitig erstellt worden sind. Damit die Effekte der Operation o2 nicht unbeachtet bleiben, passt

IT (o1,o2) die Operation o1 an. Der Algorithmus 1 zeigt den Fall IT (Ins,Del) für IT und Ab-

bildung 3.2 verdeutlicht diesen mithilfe eines konkreten Beispiels. Dieses Verfahren hat jedoch

folgende Nachteile: [20]

1. Skalierbarkeit: OT nutzt die Vektoruhr um Zeitstempel zu generieren. Für ein dynami-

sches System, in das neue Knoten eingefügt werden oder austreten können, skaliert diese

26 Operational Transformation

Methode nicht gut, da beim Vektor die Dimension der Anzahl an Knoten im System ent-

spricht.

2. Puzzle Dilemma: Das sogenannte „Killer“ Szenario führt zu einem divergierenden Da-

tensatz. Es besteht immer aus zwei Einfüge- und einer Lösch-Operation unter drei teil-

nehmenden Knoten.

3. Partielle Nebenläufigkeit: Eine Partielle Nebenläufigkeit entsteht, wenn zwei Operatio-

nen o1 und o2 aus einem Unterschiedlichen Zustand heraus generiert werden. Der IT

Algorithmus führt dann bei diesen Operationen zur Divergenz statt zur Konvergenz der

Daten.

Algorithmus 1 Inclusive Transformation Algorithmus für den Fall IT (Ins,Del)

1: function IT(Ins(p1,e1,s1),Del(p2,s2))2: if p1 > p2 then3: Ins(p1−1,e1,s1)4: else5: Ins(p1,e1,s1)6: end if7: end function

Knoten A„Efeckt“

„Effeckt“

„Effekt“

Knoten B„Efeckt“

„Efekt“

„Effekt“

𝑜" = 𝐼𝑛𝑠(2, 𝑓) 𝑜, = 𝐷𝑒𝑙(4)

I𝑇 𝑜,, 𝑜" = 𝐷𝑒𝑙(5) I𝑇 𝑜", 𝑜, = 𝐼𝑛𝑠(2, 𝑓)

Abbildung 3.2.: Operational Transformation mithilfe des Wortes „Effekt“ veranschaulicht.

SyncML 27

3.6. SyncML

SyncML wurde 2000 aufgrund der steigenden Popularität an mobilen Geräten entwickelt 1. Das

Protokoll wurde für mobile Geräte entwickelt, die nur zeitweise mit einem Netzwerk und einem

Server, der dauerhaft über ein Netzwerk erreichbar ist, verbunden sind. Das Protokoll kann aber

auch für Peer-to-Peer Netze genutzt werden. Zum Informationsaustausch werden XML Doku-

mente verwendet, die die genauen Änderungen an den Daten sowie die Daten selbst beschreiben.

Dabei setzt das Protokoll auf einen Client/Server Aufbau und tauscht seine Informationen mit-

tels Paketen aus. Abbildung 3.3 veranschaulicht den Ablauf einer Synchronisierung mit den drei

verschiedenen Package Arten. Diese beinhalten unter anderem folgende Informationen: [21]

Initialisierungspaket:

• Client Fähigkeiten

• Angeforderte Datenbank

• Art der Synchronisierung

• Authentifizierungsinformationen

Modifikationspaket:

• Kommando: add, replace, delete, . . .

• IDs der Daten und ggf. die Daten selbst

Mapping Paket:

• Mapping Informationen, welches aus einem Paar von IDs besteht. Der LUID (local unique

identifier) und der GUID (global unique identifier).

Bei entstehenden Konflikten setzt das Protokoll auf folgende drei Methoden [5]:

Client wins: Client Daten gelten als Referenz.

Server wins: Server Daten gelten als Referenz.

Last-Write-Wins: Letzte Änderung am Datensatz wird übernommen.

12002 wurde das Protokoll zu OMA DS (Open Mobile Alliance Data Synchronization), umbenannt. Da es dennochin meisten Publikationen noch als SyncML referenziert wird, wird dies bei dieser Arbeit auch beibehalten.

28 BASE

Client Server

Pkg #1: Client Initialisierung

Pkg #3: Client Daten Modifizierungen

Pkg #5: Mapping der Daten IDs

Pkg #2: Server Initialisierung

Pkg #4: Server Daten Modifizierungen

Pkg #6: Mapping Status

Datenupdate auf der Client Datenbank

Datenaktualisierung auf der Server

Datenbank

Abbildung 3.3.: SyncML Synchronisierung zwischen einem Server und einem Client.

3.7. BASE

BASE sieht sich als alternative zum ACID Prinzip. Es leitet sich aus den folgenden Wörtern

ab: „basically available“, „soft state“ und „eventually consistent“. Zu Deutsch: grundsätzlich

verfügbar, lockerer Zustand, eventuell konsistent. Während also ACID pessimistisch ist und die

Konsistenz der Daten nach jeder Operation fordert, ist BASE optimistisch und strebt eine Kon-

sistenz der Daten an. Die Konsistenz nur erreicht, wenn es keine weiteren Änderungen an den

Daten gibt. Das Base Modell setzt auf das Peer-to-Peer Prinzip. Jeder Knoten besitzt eine Teil-

menge der gesamten Datenbank, sodass alle Knoten zusammen die gesamte Datenbank reprä-

sentieren. Diese Vorgehensweise wird auch Sharding genannt. Abbildung 3.4 veranschaulicht

ein System, welches auf das BASE Modell aufbaut. Wenn eine Anwendung auf Daten zugreifen

möchte, interagiert die Anwendung entweder direkt mit dem Resource Manager (1b) oder greift

mithilfe eines Load Balancers auf die Daten zu (1a). Der Load Balancer dient zur Verteilung der

Anfragen auf die verschiedenen Knoten, welche der Anwendung auf direktem Weg antworten.

IceCube 29

whenever things do go wrong, the TP system willdetect the failure and rollback any intermediate stepstaken, if necessary.

3.2 Understanding BASE

With the emergence of unprecedented scalabilityneeds of modern Web applications, an alternative tothe rather expensive and consistency-focused ACIDmodel was introduced: BASE – Basically Avail-able, Soft state, Eventually consistent. The term wascoined around the year 2000, deliberately constructedto describe a model that is diametrically opposed toACID (Brewer, 2000).

Today, BASE is a model commonly favored bycloud systems and NoSQL stores. BASE captures thefollowing properties (Pritchett, 2008):

• A system is basically available when supportingpartial failures without total system failure.

• The state of the system is ‘soft’ in that it canchange over time even if no further updates aremade.

• The system will eventually become consistent, ifno new updates are made to the system.

Generally, BASE systems follow a peer-to-peerarchitecture, where each peer is equally responsiblefor a subset of the overall data, a so-called shard. Anincoming client request is forwarded to a responsiblenode based on a sharding function, e.g., a distributedhashtable. No notion of a transaction manager existswith BASE systems; all nodes can instead process in-coming requests, which dramatically increases scala-bility and throughput. Shards themselves are usuallyreplicated for increased fault tolerance. Hence, notonly the data itself, but also the control over it is dis-tributed.

BASE systems typically use optimistic replicationtechniques and thereby trade some consistency foravailability. Instead of requiring availability of allcomponents that are participating in a logical transac-tion (and thereby coupling all components when pro-cessing the transaction), a BASE design encouragesinteraction only with select nodes and components,thereby tolerating partial failures (of other nodes andcomponents) and accepting that the overall consis-tency will be in a state of flux. Read and write oper-ations by different clients can be performed by differ-ent nodes in the system, thereby ensuring high avail-ability. Updates written to a node typically are prop-agated asynchronously to other required nodes afterreturning to the client – the system therefore is in softstate and, if no new updates are made to a given data

item, will only eventually converge to a consistentstate.

Figure 2 illustrates a system that follows theBASE model. An application interacts either directlywith a resource managing component (1.b), or, moretypically, through some load balancer (1.a) that dis-tributes incoming requests to peers of nodes withsymmetrical responsibilities and capabilities. Re-quests are served by one or more resource managersdirectly, and changes are propagated (2) to other re-quired nodes subsequently. The number of resourcemanagers required depends on the sharding modeland the system configuration chosen, ranging from asingle node (single replica) to a quorum of nodes to,theoretically, all replicas of a given data record.

Resource Manager

Resource Manager

Load BalancerApplication

Resource Resource

RM interface

sync

RM2 interface

RM1 interface

1a

sync

1b

2

Figure 2: Architecture of a System following the BASEmodel.

Notice that BASE refers to properties of the TPsystem more so than of an individual transaction, andthat BASE hardly describes any guarantee: being ba-sically available, soft-state and eventually consistentare very weak guarantees, if any. In comparison toACID, BASE does not address atomicity and does notsupport isolation. BASE compromises consistencyto eventual consistency. Durability (persistence) ofchanges to the system is the only property common toboth models.

In the context of BASE systems, the term trans-action (and transaction processing, correspondingly)is misleading. A “BASE transaction” – if at all –probably is best understood as the unit of work com-prising an initial client request to one system nodeand all subsequent steps to propagate the effects ofthat request to all other required nodes. However, weprefer referring to “ACID transactions” (rather than“ACID systems”) and to “BASE systems” (rather than“BASE transactions”) instead, reflecting the focus ofeach of the acronyms.

Abbildung 3.4.: Architektur eines Systems welches dem BASE Modell folgt [6].

Anschließend werden die Änderungen, die an den Daten durchgeführt wurden, an alle relevanten

Knoten weitergegeben. [6]

Beim BASE System ist eine Transaktion keine direkte Änderung an den Daten, sondern ei-

ne Änderung in sogenannten Transaktionslog Tabellen. Aus diesen Tabellen werden die Logs

herausgenommen und in eine Message Queue eingereiht, welche wiederum abgearbeitet wird.

Wie oben schon genannt, gibt es beim BASE System die Eigenschaft Eventually Consistent.

Die Message Queue ist für diese Eigenschaft verantwortlich. Ist diese nicht leer, so gibt es Än-

derungen an den Daten. Erst wenn die Message Queue leer ist, herrscht eine Konsistenz in der

Datenbank. [6]

3.8. IceCube

Wie auch BASE basiert das IceCube Verfahren auf Logs. Das heißt, dass alle Transaktionen (hier

Actions genannt), die auf einen Datensatz erfolgen sollen, zuerst in Logs gespeichert werden.

30 IceCube

Anhand dieser Logs ermittelt IceCube dann eine Konfliktfreie Lösung. Actions bilden dabei die

Basis eines Logs und werden als Objekt betrachtet, welches vier Eigenschaften besitzt:

Target. Beschreibt die Objekte, die die Action adressiert.

Precondition. Ist eine Methode, die nur einen Boolean Wert zurück gibt. Bei True wird die Ac-

tion durchgeführt und bei False nicht. Die Methode prüft, ob das Objekt und seine gebun-

dene Umgebung kompatibel zum simulierten Endergebnis der Action sind. Die Methode

verändert nichts am Objekt oder seiner Umgebung, da die Endergebnisse nur simuliert

werden. Die Vorbedingung ist dynamisch.

Operation. Ist eine Methode, die eventuell das Objekt und seine Umgebung verändert. Als

Rückgabewert gib sie einen Boolean zurück, welcher beschreibt, ob die Nachbedingung

erfüllt ist oder nicht. Die Nachbedingung ist dynamisch.

Tag. Sind alle Daten, die zur Action gehören. Z.B. die Operationsart und seine Parameter.

Um Konfliktfrei zu bleiben, setzt IceCube auf eine nicht feste Reihenfolge der Logs. Zuerst

werden die Logs der Replikationen zusammengeführt und die Actions darin anschließend in der

erstellten Reihenfolge ausgeführt. Falls es dabei zu Konflikten kommt, wird die Reihenfolge

unter Beachtung der Precondition geändert. Nichtsdestotrotz kann es dabei zu Konflikten kom-

men, welche dann manuell gelöst werden müssen. Folgend wird ein Offline Kalender Szenario

erstellt, um das IceCube Verfahren zu verdeutlichen.

• Es gibt drei User, A, B und C.

• Zustand am Freitag:

– A hat am Montag frei.

– B hat am Montag 2 Slots frei 9:00-10:00 und 10:00-11:00 Uhr.

– C hat am Montag keine freie Zeit.

• Am Wochenende erstellen die User offline Einträge.

– A erstellt ein einstündiges Meeting mit B so nah wie und falls möglich 9:00 Uhr

(appAB).

– B erstellt ein einstündiges Meeting mit C so nah wie und falls möglich 9:00 Uhr

(appBC).

– C sagt sein Meeting um 9:00 Uhr ab ( f reeC).

• Alle drei User synchronisieren um 8:55 Uhr ihren Kalender.

IceCube 31

Damit alle Einträge erfolgreich erstellt werden, gibt es nur eine Reihenfolge um die Daten zu

erstellen: f reeC, appBC, appAB. Es ist zu erkennen, dass zwischen f reeC und appBC eine Ab-

hängigkeit vorliegt. appBC gibt einen Fehler aus, falls vorher nicht f reeC ausgeführt wird, da

User C sonst zu diesem Zeitpunkt nicht frei hat. Wenn appAB vor appBC ausgeführt wird, dann

gibt appBC einen Fehler aus.

IceCube versucht bei solchen Konflikten eine Reihenfolge zu finden, mit der möglichst keine

Fehler zurückgegeben werden müssen. In der Praxis stellt die hohe Anzahl von Actions ein

Problem dar. Je mehr Actions es gibt, desto weniger Spielraum hat das Verfahren eine perfekte

Lösung zu finden. [22]

4. Anforderungserhebung & -analyse

In diesem Kapitel wird auf die Anforderungen, die an die Anwendung gestellt werden einge-

gangen. Zuerst wird das Systemmodell, ein Anwendungsszenario und die daraus resultierenden

Anforderungen an das System vorgestellt.

Es gibt eine technische Umgebung, die Umgebung der Knoten. Diese besteht aus Computern

oder Smartphones, folgend als Knoten bezeichnet, welche geographisch verteilt sind und sich

über LAN bzw. Wireless LAN mit dem Internet verbinden können. Sie besitzen einen lokalen

Speicher.

4.1. Infrastruktur & Komponenten

Das Systemmodel benötigt die zuvor genannte Umgebung, welche aus den folgenden Kompo-

nenten besteht: Knoten und Netzwerk. Diese Komponenten werden in den nächsten Abschnitten

erklärt und ihre Rolle im System erläutert. Ebenfalls werden Annahmen über diese Komponen-

ten getroffen, die für die spätere Anforderung benötigt werden.

4.1.1. Knoten

Wie zu Beginn des Kapitels schon erwähnt, besitzt ein Knoten einen lokalen Cache und einen

lokalen Speicher. Die Funktionen des Knotens können wie folgt beschrieben werden:

Persistierung der Daten. Der Cache nutzt den lokalen Speicher zur Persistierung der Daten.

Aktualität. Der Speicher gewährleistet die Verfügbarkeit der Daten.

Synchronisierung. Der Knoten muss Daten sowohl senden, als auch empfangen können. Mit

den erhaltenen Daten muss eine Synchronisierung mit den vorhandenen Daten erfolgen

können.

Jeder Knoten kann sich, mithilfe seiner ausgewählten Technologie, mit dem Internet verbinden.

Dabei muss es keine dauerhafte Verbindung geben, diese kann auch nur zum Synchronisieren

aktiviert werden. Aus diesem Grund ist die Verfügbarkeit eines Knoten variabel. Neue Knoten

Anforderungen 33

können jederzeit in das System eingebunden werden oder austreten. Der lokale Speicher wird

als zuverlässig angesehen und die Daten somit auch nach einem Neustart des Systems noch

vorhanden.

4.1.2. Netzwerk

Das Netzwerk verbindet alle Knoten miteinander und stellt diesen einen Kanal zur Kommuni-

kation bereit. Die dafür vorhergesehenen Kommunikationsprotokolle wurden in Abschnitt 2.8.2

vorgestellt.

4.2. Anforderungen

Um die Anforderungen der Anwendung zu spezifizieren, wird ein Beispielszenario untersucht.

Anschließend lassen sich die Anforderungen identifizieren und beschreiben. Dabei wird zwi-

schen funktionalen und nichtfunktionalen Anforderungen unterschieden. Zuletzt werden diese

tabellarisch zusammengefasst (Tabelle 4.1).

4.2.1. Beispielszenario

Mit diesem Szenario werden die Herausforderungen, die an das System gestellt werden, heraus-

gearbeitet. Dabei wird das Szenario realitätsnah erstellt.

Durch den stetigen Arbeitsdruck auf die Menschen, ist ein geplanter Ablauf von Arbeit immer

wichtiger geworden. Alle Daten sollen immer mobil und sofort abrufbereit sein. Seit einigen

Jahren ist das Bewusstsein der Menschen, bezüglich ihrer persönlichen Daten, gestiegen.

Der Benutzer soll so wenig Daten wie möglich von sich preisgeben, daher reicht es zur Identi-

fikation nur die Email anzugeben. Diese Daten werden lokal auf dem eigenen Gerät gespeichert.

Das kann hier jede Art von Computer sein, dazu zählen der Personal Computer (PC), Smartpho-

ne, Tablet, etc.. Somit hat keine dritte Anwendung Zugriff auf die Daten.

Der Benutzer möchte nun für seinen Kalender einige Einträge erstellen. Das können Erinne-

rungen, Termine oder Notizen sein. Um diese zu Erstellen braucht er keine Internetverbindung,

diese wird nur benötigt sobald eine Synchronisation gefordert wird.

Die Synchronisation der Einträge erfolgt auf allen teilnehmenden Geräten im Netz. Als Identi-

fikation wird die Emailadresse genutzt, mit dieser ist es gleichzeitig auch möglich den Einträgen

andere Teilnehmer hinzuzufügen. Dadurch wird der Zugriff auf die Einträge durch andere Be-

nutzer des Systems ermöglicht.

34 Anforderungen

4.2.2. Funktionale Anforderung

Das System soll die Funktionalitäten eines verteilten Datenspeichers realisieren. Die Speiche-

rung der Daten erfolgt auf allen Knoten und nicht an einer zentralen Stelle. Damit soll die Offli-

nenutzung des Systems gewährleistet werden. Beim Starten bzw. Beenden der Anwendung wird

der Speicher auf die Datenintegrität geprüft. Gespeichert werden die Einträge als Flatfiles. Die

grundlegenden Operationen create, read, update und delete (CRUD) sollen unterstützt werden.

Mithilfe dieser können die Daten persistent lokal gespeichert werden. Die auftretenden Konflik-

te sollen automatisch aufgelöst werden. Bei nicht erfolgreicher Auflösung eines Konflikts muss

der Benutzer eingreifen. Damit jeder Knoten Einträge jederzeit und überall durchführen kann,

wird das Konzept Eventually Consistency angewendet.

4.2.3. Nichtfunktionale Anforderungen

Die Anwendung soll während einer nicht bestehenden Internetverbindung weiterhin verfügbar

sein. Bei einer bestehenden Internetverbindung sollen sich die Knoten laufend synchronisieren.

Im Falle einer Netzwerkpartitionierung muss es den Knoten dennoch möglich sein, sich zu syn-

chronisieren. Bei einer Aufhebung der Partitionierung soll das System seine Daten selbständig

synchronisieren. Bei der Bearbeitung von Einträgen braucht es keine Erlaubnis des Erstellers. Es

ist jedem Nutzer im System erlaubt Einträge zu bearbeiten. Gleiches gilt auch für die Erstellung

von Einträgen für andere Nutzer. Es soll zur Speicherung der Einträge ein offener Standard ge-

nutzt werden, der eine Portabilität sichert. Die Konfliktwahrscheinlichkeit soll verringert werden

und diese grundsätzlich nur maschinell aufgelöst. Das Eingreifen eines Nutzers soll so gering

wie möglich gehalten werden.

Folgend kommt nun die Zusammenfassung des gesamten Kapitels, worin kurz für das Bei-

spielszenario und der funktionalen bzw. nichtfunktionalen Anforderungen ein Überblick ver-

schafft wird.

Anforderungen 35

Funktionale Anforderung Nichtfunktionale Anforderung

Bereitstellung eines verteilten Speichers Offline verfügbar und editierbar

Lokaler Datenspeicher Synchronisierung der Daten bei bestehenderVerbindung

Flache Datenstruktur Toleranz gegenüber Knotenausfällen

CRUD-Operationen werden unterstützt Portabilität der Lösung

Automatische und Manuelle Konfliktauflö-sung

Reduktion der Wahrscheinlichkeit für Kon-flikte

Integritätsprüfung der Daten Editierbarkeit aller Einträge

Eventually Consistency

Tabelle 4.1.: Zusammenfassung der Funktionalen und Nichtfunktionalen Anforderungen

5. Konzeption & Entwurf

In diesem Kapitel wird das Konzept und der Entwurf der Anwendung „Decentralized Calendar“

dokumentiert. Es werden dabei die angewendeten Technologien vorgestellt. Im anschließenden

Kapitel wird dann die dazugehörige Implementation vorgestellt.

5.1. Kalenderformat: iCalendar (RFC 5545)

Damit diese Arbeit auch in Zukunft erweitert und verbessert werden kann, ist es wichtig ein

Kalenderformat zu wählen, welches ein offener Standard ist. Dafür gibt es einen sehr bekann-

ten Standard, den iCalendar RFC 5545. Er wird von fast allen Kalenderanbietern unterstützt

und ist auch für diese Arbeit geeignet. Mit diesem Standard ist es möglich Kalendereinträge zu

repräsentieren und auszutauschen.

Den RFC Standard iCalendar gibt es seit September 2009 und wurde seitdem fünf mal erwei-

tert (RFC: 5546, 6868, 7953, 7986). Er ist eine Sammlung von Kalender- und Zeitplanungsin-

formationen und besteht üblicherweise aus einem oder mehreren iCalendar Objekten, welche in

einer .ics Datei gespeichert werden. Innerhalb eines iCalender Objekts gibt es Attribute und

eine oder (in Ausnahmefällen) mehrere Komponenten. Folgend sind die sechs verschiedenen

Komponenten aufgelistet:

• Event

• To-Do

• Journal

• Free/Busy

• Time Zone

• Alarm

Der Beginn eines iCalendar Objekts wird anhand von BEGIN:VCALENDAR deklariert und das

Ende mit END:VCALENDAR. Damit ein iCalendar Objekt überhaupt gültig ist, muss es die bei-

den Werte PRODID und VERSION beinhalten. Die PROID gibt an wer das Objekt erstellt hat. Wie

Kalenderformat: iCalendar (RFC 5545) 37

schon erwähnt gibt es verschiedene Versionen des Standards. Damit ein Objekt einer Version

genau zugeordnet werden kann, gibt es das Attribut VERSION. Folgend werden nun noch die

Komponenten erklärt, weitere Attribute werden nicht mehr erklärt, da diese entweder selbster-

klärend oder für diese Arbeit irrelevant sind.

5.1.1. Event

Die Komponente VEVENT ist eine Sammlung von Attributen, welche eine geplante Zeit im Ka-

lender beschreibt. Sie kann zusätzlich die Komponente VALARM beinhalten. Sie darf nicht mit

anderen Komponenten ineinander verschachtelt werden, kann aber eine Beziehung zu den Kom-

ponenten Event, To-Do oder Journal haben.

1 BEGIN :VEVENT2 UID : b42ba6ec−dacb−4121−af8b−27ef208bba213 DTSTAMP:20190724 T170806Z4 SUMMARY;LANGUAGE=en−us : Meet ing wi th Team A5 DTSTART:20190723 T220000Z6 DURATION: PT1H7 END:VEVENT

Listing 5.1: Beispiel eines Events mit einer Dauer von einer Stunde

5.1.2. To-Do

Die Komponente VTODO beschreibt eine Aufgabe mithilfe von Attributen. Sie kann zusätzlich

die Komponente VALARM beinhalten. Sie darf nicht mit anderen Komponenten ineinander ver-

schachtelt werden, kann aber eine Beziehung zu den Komponenten To-Do, Event oder Journal

haben.

1 BEGIN :VTODO2 UID : 9 0 fc11d f−dcd0−4588−998e−2ee92c3860de3 DTSTAMP:20190816 T142835Z4 DUE:20190815 T220000Z5 LOCATION : B e r l i n6 ORGANIZER: m a i l t o : mus te rmai l@mai l . com7 PRIORITY : 18 RELATED−TO: b91092bc−bb8b−11e9−9cb5−2a2ae2dbcce49 ATTENDEE: m a i l t o : mus te rmai l@mai l . com

10 ATTENDEE: m a i l t o : t e i l nehmer1@mai l . com11 ATTENDEE: m a i l t o : t e i l nehmer2@mai l . com12 END:VTODO

Listing 5.2: Beispiel eines To-Dos mit mehreren Teilnehmern

38 Kalenderformat: iCalendar (RFC 5545)

5.1.3. Free/Busy

Die Komponente VFREEBUSY ist entweder eine Anfrage oder Antwort nach Informationen über

freie bzw. beschäftigte Zeit oder eine veröffentlichte Liste beschäftigter Zeit. Bei einer Anfrage

beschreibt das Attribut ATTENDEE den Kalender der angefragten Person und ORGANIZER die an-

fragende Person. Bei einer Antwort beschreibt das Attribut ATTENDEE die Antwortende Person,

die zuvor nach beschäftigter Zeit angefragt wurde und ORGANIZER die Person, die diese Anfrage

erstellt hat. Bei einer veröffentlichten Liste der beschäftigten Zeit ist der Kalenderbesitzer der

ORGANIZER. Die Komponente darf nicht mit anderen Komponenten verschachtelt werden und

auch keine Beziehungen zu anderen Komponenten haben.

1 BEGIN :VFREEBUSY2 UID : df3fd51b −7733−49ee−be24−57 a f b e 9 d f 2 a 23 DTSTAMP:20190816 T151132Z4 ORGANIZER: m a i l t o : mus te rmai l@mai l . com5 ATTENDEE;CN= u s e r ; EMAIL=user@mail . com : u r i6 FREEBUSY ; FBTYPE=FREE:20190309 T230000Z / PT2H40M7 FREEBUSY ; FBTYPE=BUSY:20190815 T220000Z / PT1H8 END:VFREEBUSY

Listing 5.3: Beispiel einer veröffentlichten Liste über nicht erreichbare Zeiten

5.1.4. Journal

Die Komponente VJOURNAL repräsentiert eine oder mehrere Notizen zu einem bestimmten Da-

tum. Das Datum zu dem das Journal gehört, spielt bei keine Rolle bei der Suche nach freier

bzw. beschäftigter Zeit. Ein Journal kann nicht ineinander verschachtelt werden, dieses kann nur

Relationen zu einem Journal, Event oder To-Do haben.

1 BEGIN :VJOURNAL2 UID : f1752e09−d745−40ce−bc56−d 0 a c 4 a f 1 b e a b3 DTSTAMP:20190817 T085410Z4 DESCRIPTION : Lorem ipsum d o l o r s i t amet , c o n s e t e t u r \ n5 s a d i p s c i n g e l i t r , sed diam nonumy ei rmod tempor \ n6 i n v i d u n t u t l a b o r e e t d o l o r e magna a l iquyam e r a t .7 ATTACH;FMTTYPE= B e i s p i e l s e i t e ;ENCODING=BASE64 ; \ n8 VALUE=BINARY : cGF . . . Qp99 ATTENDEE: m a i l t o : mus te rmai l@mai l . com

10 RELATED−TO: b91092bc−bb8b−11e9−9cb5−2a2ae2dbcce411 CONTACT: Max12 DTSTART:20190816 T220000Z13 END:VJOURNAL

Listing 5.4: Beispiel eines Journal Eintrags

Kalenderformat: iCalendar (RFC 5545) 39

Die vier Komponenten die bis hierhin vorgestellt wurden Event, To-Do, Free/Busy und Journal

besitzen zur eindeutigen Identifikation immer eine UID.

5.1.5. Time Zone

Die Komponente VTIMEZONE beschreibt anhand von Regeln die Zeitzone für einen geografi-

schen Ort. Mit der Subkomponente STANDARDwird die Winterzeit beschrieben und mit DAYLIGHT

die Sommerzeit.

1 BEGIN :VTIMEZONE2 TZID : Europe / B e r l i n3 BEGIN :STANDARD4 DTSTART:20192710 T0300005 TZOFFSETFROM:+02006 TZOFFSETTO:+01007 TZNAME:MEZ8 END:STANDARD9 BEGIN :DAYLIGHT

10 DTSTART:20190331 T02000011 TZOFFSETFROM:+010012 TZOFFSETTO:+020013 TZNAME:MESZ14 END:VTIMEZONE

Listing 5.5: Dieses Beispiel beschreibt die Zeitzonen Information über Berlin

5.1.6. Alarm

Die Komponente VALARM ist Alarm bzw. eine sogenannte Erinnerung, welche für ein Event oder

To-Do genutzt werden kann.

1 BEGIN :VALARM2 ACTION :AUDIO3 TRIGGER ;VALUE=DATE−TIME:20190816 T220000Z4 REPEAT: 45 DURATION: PT10M6 DESCRIPTION : T r e f f e n mi t d e r A b t e i l u n g s l e i t u n g \ n7 um 11 Uhr .8 END:VALARM

Listing 5.6: Beispiel einer Erinnerung mit Beschreibung

Der bisher vorgestellte Teil des Standards ist ein geringer Teil des gesamten [23]. Dennoch reicht

das bis hierhin vermittelte Wissen für diese Arbeit aus.

40 Entwurf eines Algorithmus

5.2. Entwurf eines Algorithmus

In Kapitel 3 wurden neun verschiedene Methoden vorgestellt. Vier von Ihnen weisen die Ge-

meinsamkeit auf, für ihre Synchronisierung der Replikate Logs zu verwenden, das sind: Ope-

rational Transformation (OT), SyncML, BASE und IceCube. Diese Logs werden genutzt um

Konflikte zu lösen bevor sie entstehen. Dabei nutzt jede Methode ihre eigenen Verfahren an.

OT lässt dabei am meisten Spielraum eine eigene Konfliktlösung anzubieten. Folgend wird nun

etwas mehr auf das Verfahren eingegangen.

Das Operational Transformation Verfahren ist eine Strategie, die für eine parallele Bearbei-

tung von Textdokumenten entwickelt wurde. Sie bietet jedoch eine geeignete Methode, um

Kalenderdaten zu synchronisieren. In diesem Abschnitt wird versucht, das Verfahren für den

Decentralized Calendar zu adaptieren. Zunächst werden die Grunddefinitionen nach Imine be-

schrieben. Im Anschluss werden die Lösungen, mithilfe derer Iminie die Nachteile des OT aus-

gleichen will, erklärt. Zuletzt wird die Adaption für den Decentralized Calendar gezeigt.

5.2.1. Operational Transformation nach Imine

Die OT bietet für den Decentralized Calendar eine gute Grundlage für die Datensynchronisa-

tion. Die zuvor in Abschnitt 3.5 aufgeführten Nachteile der OT sind, bei einem dynamischen

System, jedoch ein Problem. Imine hat ein Koordinationsmodell erstellt, welches auf OT basiert

und dabei die Nachteile eines OT Systems ausgleicht. In seinem Modell gibt es nun statt zwei,

drei Operationsarten: Einfügen Ins(p,e,w), Aktualisieren Up(p,e,e′) und Löschen Del(p) mit

p die Position des Elements, e das Element und w eine Liste aus allen Positionen die e belegt.

Mit q,q′,q1,q2, ... werden Anfragen vereinfacht beschrieben und mit i, d und u Einfügen, Lö-

schen und Aktualisieren. Die beiden Funktionen old(u) und new(u) geben für die Operation

Aktualisieren den alten Wert e bzw. den neuen Wert e′ zurück.

Imine definiert zudem noch eine Anfrage q als Quadrupel (c,r,a,o). Mit c als Identität (ID)

des anfragenden Knotens und r ∈ N als eine aufsteigende Nummerierung der Anfrage. Die Ver-

kettung aus beidem ergibt zusammen die ID der Anfrage q. Die Variable a ist die ID der Anfrage

von der q abhängig ist. Ist diese null so gibt es keine Abhängigkeiten. Zuletzt o mit der Opera-

tion selbst. Jeder Knoten hat genau einen Log, der darin jede erstellte Anfrage speichert.

Das Problem der schlechten Skalierbarkeit wird mithilfe von Relationen gelöst. Dafür wird

eine Causal Dependency Relation definiert.

Definition 1 (Causal Dependency Relation). Sei L ein Log mit L[i] = qi, L[i] = qi und j = i+1.

Die transitive Relation s−→ in L wird wir folgt definiert. Es gilt qis−→ q j für alle Anfragen die

Entwurf eines Algorithmus 41

folgenden Bedingungen erfüllen:

qi.o = Ins(p,e,w),q j.o = Ins(p,e′,w′) und qi.c≤ q j.c (df1)

qi.o = Ins(p,e,w),q j.o = Ins(p+1,e′,w′) und q j.c≤ qi.c (df2)

qi.o = Ins(p,e,w) und q j.o = Del(p) (df3)

qi.o = Ins(p,e,w) und q j.o =U p(p,e,e′) (df4)

qi.o =U p(p,e,e′),q j.o =U p(p,e′,e′′) and q j.c≤ qi.c (df5)

Für alle anderen gilt qi 6 s−→ q j, damit sind qi und q j unabhängig voneinander.

Zwei eingefügte Elemente sind abhängig voneinander, falls diese benachbart sind und die

Bedingung zur ID der Knoten erfüllt sind (df1 und df2). Das Löschen eines Elements hängt

vom Einfügen des gleichen Elements ab (df3). Selbiges gilt für das Aktualisieren eines Elements

(df4). Gibt es zwei Aktualisieren an der selben Position und ist die Bedingung zur ID der Knoten

erfüllt, so sind diese auch abhängig voneinander (df5). Für alle anderen Anfragen qi und q j gilt,

dass diese auch in umgekehrter Reihenfolge ausgeführt werden können.

Um das Puzzle Dilemma auszugleichen wurde folgendes definiert:

Definition 2 (Canonical Log). Ein Log L ist ein Canonical Log, falls L die Verkettung der

beiden Teilmengen Lins und Ldel ist. Für Lins gilt, es existiert keine Lösch-Operation. Für Ldel

gilt, es existiert keine Einfüge-Operation.

Aus der Definition 2 folgt, das in den beiden Logs Li und L j Aktualisierungsoperationen

existieren dürfen. Mithilfe des Canonical Log geben wir den Operationen nun eine Regel für die

Reihenfolge der Ausführung. Das Einfügen eines Elements muss immer vor dem Löschen eines

Elements von statten gehen. Leere Logs oder Logs ohne eine Aktualisierungs-Operation sind

ebenfalls Canonical Logs. Siehe folgendes Beispiel: [i1,u1, i2,d1] und [u1, i1,u2,d1] erfüllen die

Bedingung. [i1,u1,d2, i1] hingegen jedoch nicht.

Um den dritten Nachteil des OT Verfahrens auszugleichen definiert Imine ein Conistency

Model.

Definition 3 (Conistency Model). Folgende Eigenschaften müssen erfüllt sein, damit die Daten

Konsistent sind:

1. Abhängigkeits Einhaltung: Wenn qis−→ q j, so muss auf allen Knoten qi vor q j ausgeführt

werden.

2. Konvergenz: Sobald alle Knoten dieselbe Menge an Anfragen ausgeführt haben, sind die

Replikate identisch.


Um diese drei Definitionen umzusetzen gibt Iminie einen Ablauf von Algorithmen vor, wel-

cher nun beschrieben wird.

Erstellung einer Anfrage. Der Algorithmus ComputeBF (Algorithmus 2). wird aufgerufen,

sobald eine Anfrage erstellt wurde. Diese erhält als Parameter die erstellte Anfrage q und

den Log L des Knotens. Der Algorithmus sucht für die erstelle Anfrage eine abhängige

Anfrage im Log. Falls es eine gibt, so wird dies in der Anfrage im Wert a hinterlegt und

falls nicht wird auf die Anfrage der Algorithmus Exclusive Transformation (Algorithmus

6) angewendet. Die Funktion gibt zum Schluss die bearbeitete Anfrage zurück. Nach der

Integration der neuen Anfrage, muss der Log nun bearbeitet werden, damit die Bedingung

eines Canonical Logs erfüllt wird. Dafür wird der Algorithmus Canonize (Algorithmus 3)

ausgeführt. Dieser fügt zu Beginn die erstellte Anfrage in den Log ein. Anschließend geht

der Algorithmus durch den Log und kontrolliert alle eingetragenen Anfragen auf Abhän-

gigkeit zur erstellen Anfrage. Die neue Anfrage wird solange nach vorne geschoben, bis

diese eine Abhängigkeit findet.

Empfangen von Anfragen. Der Algorithmus ComputeFF (Algorithmus 4). verarbeitet die

empfangene Anfrage so, dass diese zum aktuellen Zustand des Datensatzes passt. Dies

geschieht mithilfe des Inclusive Transformation (Algorithmus 5). Anschließend wird die

Anfrage durchgeführt und mithilfe vom Algorithmus Canonize in den Log integriert.

Es wurde nun anhand von Iminies Modell beschrieben, wie ein Datensatz über mehrere Knoten

hinaus konsistent bleiben kann. Im nächsten Abschnitt werden die erforderlichen Änderungen

beschrieben, sodass das Modell für den Decentralized Calendar verwendet werden kann.

5.2.2. OT für den Decentralized Calendar

Iminies Modell ist für eine parallele Bearbeitung eines Textdokuments gedacht. Bei dieser Ar-

beit wird jedoch mit mehreren .ics Dateien gearbeitet. Diese beinhalten zwar auch Textelemente,

jedoch werden diese nicht Zeichen für Zeichen geändert, sondern pro Attribut. Jedes Attribut

belegt dabei eine Zeile, was bedeutet dass Änderungen Zeilenweise geschehen müssen. Somit

gilt für den Decentralized Calendar das p die Zeilennummer und nicht die Position eines Zei-

chens beschreibt. Um nun mehrere Dateien synchronisieren zu können, wird dem Request der

Dateiname f beigefügt. Aus dem Quadrupel wird nun ein Quintupel mit (c,r, f ,a,o). Um je-

der Datei einen einzigartigen Namen zu geben, wird dieser anhand seiner ID generiert. Um das

Erstellen und Löschen von Dateien zu ermöglichen, erfordert es neue Operationen. Folgend wer-

den beide neue Operationsarten definiert: Erstellen einer Datei Cr(e) und Löschen einer Datei


Rm(e), mit e als Inhalt der gesamten Datei. Das Modell von Iminie erlaubt es zudem nicht, Lö-

schungen wieder Rückgängig zu machen, da die Operation des Löschvorgangs nur die Position

des zu löschenden Elements beinhaltet. Um dieses Problem zu vermeiden, wird den Operationen

Del und Rm noch das Element e beigefügt, welches das zu Löschende Element beschreibt. Ei-

ne Löschung ist zwar persistent, jedoch kann mithilfe der neu definierten Operationen Del und

Rm, die jeweilig gegenteilige Operation Ins bzw. Cr ausgeführt werden. Die Löschinformatio-

nen können dem Nutzer gezeigt werden, welcher dann entscheiden kann, diese Rückgängig zu

machen. Somit ergibt sich folgende Erweiterung der Abhängigkeiten nach der Definition 1 von

Imine:

qi.o =Cr( f ,e),q j.o = Ins(p,e,w) und qi. f = q j. f (df6)

qi.o =Cr( f ,e),q j.o =U p(p,e,e′) und qi. f = q j. f (df7)

qi.o =Cr( f ,e),q j.o = Del(p,e) und qi. f = q j. f (df8)

qi.o =Cr( f ,e),q j.o = Rm(e) und qi. f = q j. f (df9)

Diese beschreiben, dass alle durchgeführten Operationen immer abhängig von ihrer Erstellung

sind.

Der Decentralized Calendar bietet dem Nutzer auch eine Offlinenutzung an. Es kann also der

Fall eintreten, dass der Nutzer mehrere Änderungen durchführt und diese noch nicht an alle

Replikate verteilt wurden. Imines Modell setzt aber auf eine dauerhafte Verbindung und sendet

somit jede Anfrage nach ihrer Integrierung in das Log ab. Um die Offlinenutzung zu unterstüt-

zen, werden also alle erstellten Anfragen in eine separate Queue gespeichert. Sobald nun eine

Verbindung zu einem Knoten aufgebaut wird, wird die gesamte Queue abgeschickt. Der emp-

fangende Knoten geht die erhaltenen Anfragen dann Stück für Stück durch. Das Aktivitätsdia-

gramm auf Abbildung 5.2 verdeutlicht diesen Ablauf. Mit diesen Eigenschaften gehört das Mo-

dell der Anwendung zu der Klassifikation der Verteilt-Verzögerten Systeme (Abbildung 2.9D).

Die Konsistenz der Daten wird angestrebt, ist aber durch die verzögerte Verteilung des Logs nur

zu gewissen Zeitpunkten gegeben (Abbildung 5.1).


Availability Partition tolerance

Consistency

DecentralizedCalendar

Abbildung 5.1.: Decentralized Calendar Synchronisations-Eigenschaften abgebildet auf das CAP Theo-rem

.


Abbildung 5.2.: Aktivitätsdiagramm des Decentralized Calendar.

6. Implementierung

In diesem Kapitel wird die Implementierung des Decentralized Calendars dokumentiert. Es wer-

den dabei genutzte Technologien erklärt und anhand von Beispielen aus der Implementierung

veranschaulicht.

6.1. Bibliotheken und Frameworks

In diesem Abschnitt werden die genutzten Bibliotheken und Frameworks, die für die Implemen-

tierung des Decentralized Calendar genutzt werden, beschrieben.

6.1.1. biweekly

Biweekly wurde 2013 von Michael Angstadt veröffentlicht und ist eine Java Bibliothek, die es

ermöglicht iCalendar Objekte bzw. Dateien zu erstellen und zu lesen. Hier die drei wichtigsten

Funktionen und ihre Methoden [24]:

6.1.1.1. Lesen von iCalendar Daten

Mithilfe der Methode Biweekly.parse() ist es möglich iCalendar Daten zu lesen. Als Argu-

mente können ein String, File, InputStream oder Reader übergeben werden. In Abschnitt

5.1 wurde bereits erklärt, dass .ics Dateien mehrere iCalender Objekte enthalten können. Mit

den Methoden first() bzw. all() wird das erste Objekt bzw. alle Objekte gelesen. Als Rück-

gabewert wird ein iCalender Objekt oder eine Liste aus iCalendar Objekten zurückgegeben.

Listing 6.1 zeigt beispielhaft, wie aus einem iCalendar String, ein iCalendar Objekt erstellt wird

und daraus anschließend die Zusammenfassung aus dem Event liest.

6.1.1.2. Schreiben eines iCalendar Objekts

Um ein iCalendar zu schreiben benötigt es zuerst ein iCalendar Objekt der iCalendar Klasse.

Dieses Objekt übergibt man der Methode Biweekly.write() als Argument. Anschließend ruft

man die Methode go() auf, welcher eins folgende Objekte liest File, OutputStream oder

Writer und das iCalender Objekt darin speichert. Gibt man kein Argument ein, gibt die Methode

Bibliotheken und Frameworks 47

1 S t r i n g s t r i n g =2 "BEGIN :VCALENDAR" +3 "VERSION : 2 . 0 " +4 "PRODID: − / / Michae l A n g s t a d t / / b i w e e k l y 0 . 6 . 3 / / EN" +5 "UID : b91098f2−bb8b−11e9−9cb5−2a2ae2dbcce4 " +6 "NAME: same " +7 "LAST−MODIFIED:20190810 T152454Z " +8 "BEGIN :VEVENT" +9 "DTSTAMP:20190810 T152454Z " +

10 "SUMMARY;LANGUAGE=en−us : Meet ing wi th O f f i c e Team" +11 "DTSTART:20190809 T220000Z " +12 "DURATION: PT1H" +13 "END:VEVENT" +14 "END:VCALENDAR" ;15

16 I C a l e n d a r i c a l = Biweekly . p a r s e ( s t r i n g ) . f i r s t ( ) ;17 VEvent e v e n t = i c a l . g e t E v e n t s ( ) . g e t ( 0 ) ;18 S t r i n g summary = e v e n t . getSummary ( ) . g e t V a l u e ( ) ;

Listing 6.1: Lesen eines iCalendar Strings

einen String zurück, welcher das iCalendar Objekt repräsentiert. Es gilt zu beachten, dass falls

das ICalendar Objekt nicht der iCalendar Spezifikation entspricht, es dennoch zur Speicherung

kommt (Ein Beispiel eines Fehlers auf Listing 6.3). Listing 6.2 zeigt wie eine ICalendar Klasse

erstellt wird und diese dann in einer .ics Datei gespeichert wird.

1 f i n a l I C a l e n d a r i C a l e n d a r = new I C a l e n d a r ( ) ;2 f i n a l VEvent e v e n t = new VEvent ( ) ;3 f i n a l Summary summary = e v e n t . setSummary ( " Meet ing wi th O f f i c e Team" ) ;4 summary . s e t L a n g u a g e ( " en−us " ) ;5

6 f i n a l Loca lDa te l o c a l D a t e = Loca lDa te . now ( ) ;7 f i n a l Date s t a r t = c o n v e r t T o D a t e V i a I n s t a n t ( l o c a l D a t e ) ;8 e v e n t . s e t D a t e S t a r t ( s t a r t ) ;9

10 f i n a l D u r a t i o n d u r a t i o n = new D u r a t i o n . B u i l d e r ( ) . h o u r s ( 1 ) . b u i l d ( ) ;11 e v e n t . s e t D u r a t i o n ( d u r a t i o n ) ;12

13 i C a l e n d a r . addEvent ( e v e n t ) ;14

15 F i l e f i l e = new F i l e ( " mee t ing . i c s " ) ;16 Biweekly . w r i t e ( i c a l ) . go ( f i l e ) ;

Listing 6.2: Schreiben einer iCalendar Klasse in eine .ics Datei

48 Bibliotheken und Frameworks

6.1.1.3. Validierung eines ICalendar Objekts

Damit auch kontrolliert werden kann, ob ein ICalendar Objekt der iCalender Spezifikation ent-

spricht, gibt es die Methode validate(). Sie benötigt keine Parameter, sondern wird über das

ICalendar Objekt selbst aufgerufen und gibt eine Liste von Warnungen zurück, die die iCalendar

Spezifikation verletzen. Die Liste der Warnungen kann wie auf Listing 6.3 aussehen.

1 DateFormat d f = new SimpleDateFormat ( " yyyy−MM−dd HH:mm" ) ;2 I C a l e n d a r i c a l = new I C a l e n d a r ( ) ;3

4 VEvent e v e n t = new VEvent ( ) ;5 e v e n t . s e t D a t e S t a r t ( d f . p a r s e ( " 2019−07−15 18 :00 " ) ) ;6 e v e n t . s e t D a t e E n d ( d f . p a r s e ( " 2013−07−15 12 :00 " ) ) ;7 i c a l . addEvent ( e v e n t ) ;8

9 V a l i d a t i o n W a r n i n g s w a r n i n g s = i c a l . v a l i d a t e ( I C a l V e r s i o n . V2_0 ) ;10 System . o u t . p r i n t l n ( w a r n i n g s . t o S t r i n g ( ) ) ;11

12 / / Ausgabe d e r Konsole :13 / / [ I C a l e n d a r > VEvent ] : ( 1 6 ) The s t a r t d a t e must come b e f o r e t h e end d a t e .

Listing 6.3: Validierung eines ICalendar Objekts

6.1.2. JUnit5

Das Framework JUnit ist ein Werkzeug zum Testen von Java-Programmen. Es ist darauf ausge-

legt worden einzelne Units des Programms zu Testen, wie z.B. Methoden oder Klassen. Die ak-

tuellste und auch bei dieser Arbeit genutzte Version ist JUnit5, welche es seit 2017 gibt. Es bietet

dem Entwickler eine große Palette an Tools, um sein Programm zu testen. All diese vorzustellen,

würde den Rahmen dieser Arbeit sprengen. Daher werden in Tabelle 6.1 alle Annotationen für

Methoden erklärt, die in dieser Arbeit genutzt werden.

Ein Test kann entweder nur fehlschlagen oder gelingen. Die Ursache eines misslungenen Tests

kann eine Exception, den das Programm wirft sein, oder das Ergebnis des Tests entspricht nicht

dem erwartenden Ergebnis. Um das Ergebnis der Tests zu kontrollieren, wird das Framework

AssertJ (Abschnitt 6.1.3) genutzt, da dieser einige Vorteile gegenüber der Methodik von JUnit

aufweist. JUnit kontrolliert seine Ergebnisse mithilfe von Assertions, die wie folgt aussehen kön-

nen assertEquals(value1, value2);. Dadurch ist einem lesenden Entwickler nicht sofort

ersichtlich, welcher dieser Werte der Erwartete und welcher das Ergebnis ist. [25]

Bibliotheken und Frameworks 49

Annotation Beschreibung

@Test Kennzeichnet die Methode als Testmethode.

@BeforeEach Die Methode wird vor jeder Testmethode ausgeführt.

@AfterEach Die Methode wird nach jeder Testmethode ausgeführt.

@BeforeAll Die Methode wird vor allen Testmethoden ausgeführt.

@AfterAll Die Methode wird nach allen Testmethoden ausgeführt.

Tabelle 6.1.: Junit5 genutzte Annotationen für Methoden im Decentralized Calendar

6.1.3. AssertJ

AssertJ ist kein eigenständiges Test Framework, sondern bietet eine Erweiterung für Test Fram-

works mit einem Angebot an diversen Assertions. Einer der Vorteile gegenüber den JUnit As-

sertions wurde schon im vorigen Abschnitt aufgezeigt. Durch AssertJ verbessert sich die Les-

barkeit eines Tests und ermöglicht dem Leser die Absicht des Tests schneller zu verstehen.

Folgendes Beispiel soll die bessere Lesbarkeit verdeutlichen. Seien cache und storage zwei

Listen, bei denen geprüft werden muss, ob ihre Einträge gleich sind. Diese Prüfung soll je-

doch unabhängig der Reihenfolge der Einträge sein. Mit JUnit würden beide Listen zuerst in

HashSets umgewandelt und anschließend auf Gleichheit geprüft werden, da es bei HashSets

keine Reihenfolge der Einträge gibt. AssertJ bietet für solch einen Vergleich seine eigene Me-

thode an. Listing 6.4 stellt die beiden Varianten gegenüber. Zwar muss unter AssertJ der Ver-

gleich mit einem Array gemacht werden, liest sich aber dennoch einfacher, da die Methode

containsExactlyInAnyOrder() selbsterklärend ihre Funktion als Namen trägt. Diese Me-

thode ist beispielhaft für AssertJ. Das Framework versucht, mithilfe ihrer Erweiterung, dem

Lesenden direkt zu verdeutlichen, was genau beim Test beabsichtigt wird. [26]

1 / / J U n i t Methode2 HashSet < S t r i n g > e x p e c t e d S e t = new HashSet < S t r i n g >( e x p e c t e d L i s t ) ;3 HashSet < S t r i n g > a c t u a l S e t = new HashSet < S t r i n g >( a c t u a l L i s t ) ;4 a s s e r t T h a t ( a c t u a l S e t ) . i s E q u a l T o ( e x p e c t e d S e t ) ;5

6

7 / / A s s e r t J Methode8 S t r i n g [ ] e x p e c t e d A r r a y = new S t r i n g [ e x p e c t e d L i s t . s i z e ( ) ]9 e x p e c t e d L i s t . t o A r r a y ( e x p e c t e d A r r a y ) ;

10 a s s e r t T h a t ( a c t u a l L i s t ) . c o n t a i n s E x a c t l y I n A n y O r d e r ( e x p e c t e d A r r a y ) ;

Listing 6.4: Gegenüberstellung von JUnit und AssertJ an der Ergebniskontrolle. Getestet wird ob zweiListen, unabhängig der Reihenfolge ihrer Einträge, gleich sind.

50 Maven

6.2. Maven

Maven ist ein Software Management Tool, welches dabei hilft, standardisierte Java-Programme

zu erstellen und zu verwalten. Maven automatisiert viele Arbeitsschritte der Software Entwick-

lung, indem durch gegebene Konventionen weniger konfiguriert werden muss (Convetion over

Configuration), wie z.B. das Kompilieren, Testen, Packen und Deployen der Anwendung.

Die Arbeitsschritte, die eine Anwendung durchläuft, werden in Maven als Lifecycle beschrie-

ben. Hier stellt Maven eine standartisierte Vorgabe bereit, die in ihrer Reihenfolge nicht verän-

derbar ist, dafür besteht die Möglichkeit, nur Teile dieses Lifecycles durchzugehen.

clean - Löschen des target Verzeichnisses.

validate - Kontrolle des Projekts anhand von Vollständigkeit aller Daten und Informationen.

compile - Kompilierung des Codes.

test - Ausführung der Unit Tests mithilfe des angewendeten Frameworks.

package - Verpackt den kompilierten Code in ein vorgegebenes Format, z.B. JAR oder WAR,

als Paket.

verify - Ausführung von Integration Tests.

install - Kopiert das Paket in das lokale Maven-Repository.

deploy - Kopiert das Paket in das Remote Repository, somit steht es weiteren Personen zur

Verfügung.

Durch Plugins besteht die Möglichkeit den Lifecycle zu erweitern.

Mithilfe eines zentralen Orts, der POM („project object model“), werden alle Informationen

über das Projekt gespeichert (üblicherweise als XML Datei, pom.xml). Beispielweise die Versio-

nierung, Dokumentation oder die genutzten Bibiliotheken. Die POM ist der elemtare Bestandteil

eines Maven Projekts und somit zwingend erforderlich. Sie enthält somit jegliche Meta-Daten

zum Projekt, die in vier Bereiche eingeteilt werden kann.

Koordinaten. Die Koordinaten, bestehend aus drei Elementen, beantworten das "Wer"des Ma-

ven Projekts.

• groupid ist eine eindeutige Bezeichnung für das Projekt. Nach der Namenskonventi-

on beginnt die groupid mit dem umgekehrte Domainname des Besitzers. Zusätzlich

kann die groupid, um Projekt- oder Abteilungsnamen erweitert werden.

• artefactID wird der Name des gepackten Projekts sein.

Maven 51

• version ist die Versionsnummer des Projekts.

Listing 6.5 zeigt Beispielhaft die Koordinaten für das Decentralized Kalendar Projekt.

1 . . .2 < groupId >de . htw . a i < / g roupId >3 < a r t i f a c t I d > d e c e n t r a l i s e d _ c a l e n d a r < / a r t i f a c t I d >4 < v e r s i o n > 0 . 0 . 1 < / v e r s i o n >5 . . .

Listing 6.5: Koordinaten aus der POM vom Cecentralized Calendar Projekt

Projektbeziehungen. Hier werden die Beziehungen zu anderen Projekten deklariert. Bei Ma-

ven unterscheidet man zwischen drei unterschiedlichen Arten von Beziehungen.

• Dependency: Hier werden die verschiedenen Projekte deklariert, von denen das ei-

gentliche Projekt abhängig ist. Das können Projekte sein, die öffentlich sind, Frame-

works oder auch Bibliotheken, solange sie im öffentlichen Maven-Repository exis-

tieren. Das heißt im Umkehrschluss, dass Projekte, die nicht öffentlich verfügbar

sind, nicht verwendet werden können. Damit wird sichergestellt, das nur Projekte

eingebunden werden, mit denen Maven auch umgehen kann. Listing 6.6 zeigt zwei

Dependencies der POM aus dem Projekt dieser Arbeit. Der erste Eintrag ist das Fra-

mework biweekly, welches in Abschnitt 6.1.1 vorgestellt wird und das zweite ist

JUnit5, welches in Abschnitt 6.1.2 erläutert wird.

• Vererbung: Maven Projekte können von einem anderen Projekt erben. Dies ge-

schieht durch eine <parent> deklaration.

• Aggregation bzw. Multimodul: Große Projekte sollten immer komponentenbasiert

entwickelt werden, damit die einzelnen Kompenenten wiederverwendet werden kön-

nen. Maven bietet dieses Prinzip ebenfalls an. Wenn ein Projekt in Unterprojekte

eingeteilt ist, werden diese in Maven unter dem Punkt <modules> deklariert. Bei

großen Projekten würde ansonsten eine POM mit Informationen überfüllt und damit

auch fehleranfälliger werden.

Weitere Projekt Informationen. In der POM können noch weitere optionale organisatori-

sche Informationen hinterlegt werden. Dazu gehören:

• Software Lizenz

• Organisation (Listing 6.7)

• Entwickler (Listing 6.8)

52 Maven

1 . . .2 < d e p e n d e n c i e s >3 <!−− i C a l e n d a r Framework−−>4 <dependency >5 < groupId > n e t . s f . b iweekly < / groupId >6 < a r t i f a c t I d > biweekly < / a r t i f a c t I d >7 < v e r s i o n > 0 . 6 . 3 < / v e r s i o n >8 </ dependency >9

10 <!−−TESTING−−>11 <dependency >12 < groupId > org . j u n i t . j u p i t e r < / groupId >13 < a r t i f a c t I d > j u n i t − j u p i t e r −ap i < / a r t i f a c t I d >14 < v e r s i o n > 5 . 3 . 2 < / v e r s i o n >15 <scope > t e s t < / scope >16 </ dependency >17 . . .18 </ d e p e n d e n c i e s >19 . . .

Listing 6.6: Kleiner Ausschnitt der Depencencies aus der POM vom Decentralized Calendar Projekt. Dieerste Dependency ist das Framework biweekly und das zweite JUnit5

1 . . .2 < o r g a n i z a t i o n >3 <name> Hoschschu l e f u e r Technik und W i r t s c h a f t < / name>4 h t t p s : / / www. htw−b e r l i n . de 5 </ o r g a n i z a t i o n >6 . . .

Listing 6.7: Informationen über die Organisation in der POM des Decentralized Calendar Projekts

• Mitwirkende

Sonstige Einstellungen. Die POM bietet noch einige weitere Möglichkeiten, Informationen

über das Projekt zu speichern. In dieser Arbeit werden diese zusätzlichen Informationen

aber nicht genutzt und daher auch nicht weiter diskutiert1.

Maven gibt eine eigene Verzeichnisstruktur vor, die genauso eingehalten werden muss. Es ist

jedoch erlaubt ungenutzte Ordner nicht anzulegen. Tabelle 6.2 zeigt die Verzeichnisstruktur des

Decentralized Calendar Projekts.

Die gesamte POM Datei ist auf Listing A.1 abgebildet. [27]

1Die komplette Dokumentation der POM kann unter folgender Adresse nachgeschlagen werden: htt-ps://maven.apache.org/pom.html

Design Pattern 53

1 . . .2 < d e v e l o p e r s >3 < d e v e l o p e r >4 <id >bki < / id >5 <name>Behzad Karimi < / name>6 <emai l > ka r imi1993@l ive . de < / emai l >7 < o r g a n i z a t i o n >HTW</ o r g a n i z a t i o n >8 < o r g a n i z a t i o n U r l > h t t p s : / / www. htw−b e r l i n . de / < / o r g a n i z a t i o n U r l >9 < r o l e s >

10 < r o l e > a r c h i t e c t < / r o l e >11 < r o l e > d e v e l o p e r < / r o l e >12 </ r o l e s >13 <t imezone >Germany / B e r l i n < / t imezone >14 </ d e v e l o p e r >15 </ d e v e l o p e r s >16 . . .

Listing 6.8: Informationen über den Entwickler in der POM des Decentralized Calendar Projekts

Verzeichnis Beschreibung

src alle Dateien die für die Anwendung genutzt werden

src/main alle Dateien die für die Erstellung des Produkts benötigt werden

src/main/java Java-Quelltext

src/test alle Dateien die für die Erstellung von automatisierten Tests benötigt werden

src/test/java Java Unit-Tests

target erzeugte bzw. kompilierte Dateien

Tabelle 6.2.: Maven Verzeichnisstruktur für den Entwurf des Decentralised Calendar)

6.3. Design Pattern

In diesem Abschnitt werden die Design Pattern, die bei der Umsetzung der Implemenierung

genutzt werden vorgestellt.

6.3.1. Singleton

Das Singleton Pattern wird verwendet, um sicherzustellen, dass ein Objekt global nur einmal

existiert. Der Konstruktor des Objekts ist von außen nicht erreichbar (private). Um das Objekt

aufzurufen, wird eine Methode Namens getInstance() aufgerufen. Diese gibt das Objekt zu-

rück. Dabei kontrolliert die Methode, ob schon eine erstelle Instanz des Objektes existiert. Falls

nicht wird diese erstellt. Listing 6.9 zeigt die Klasse RequestLog welche das Singleton Pattern

54 Design Pattern

anwendet. [28]

1 * /2 p u b l i c c l a s s Reques tLog implemen t s S e r i a l i z a b l e {3

4 p r i v a t e s t a t i c RequestLog r e q u e s t L o g I n s t a n c e ;5 p r i v a t e L i n k e d L i s t < Reques t > r e q u e s t L i s t ;6

7

8 p r i v a t e RequestLog ( ) {9 t h i s . r e q u e s t L i s t = new L i n k e d L i s t < >() ;

10 }11

12

13 p u b l i c s t a t i c s y n c h r o n i z e d RequestLog g e t I n s t a n c e ( ) {14 i f ( r e q u e s t L o g I n s t a n c e == n u l l ) {15 r e q u e s t L o g I n s t a n c e = new RequestLog ( ) ;16 }17 r e t u r n r e q u e s t L o g I n s t a n c e ;18 }19

20

21 p u b l i c L i n k e d L i s t < Reques t > g e t R e q u e s t L i s t ( ) {22 r e t u r n t h i s . r e q u e s t L i s t ;23 }24

25

26 p u b l i c vo id addReques t ( f i n a l Reques t . . . r e q u e s t s ) {27 f o r ( f i n a l Reques t r e q u e s t : r e q u e s t s ) {28 t h i s . r e q u e s t L i s t . add ( r e q u e s t ) ;29 }30 }31

32

33 p u b l i c vo id s e t R e q u e s t L i s t ( f i n a l L i n k e d L i s t < Reques t > r e q u e s t L i s t ) {34 t h i s . r e q u e s t L i s t = r e q u e s t L i s t ;35 }36 }

Listing 6.9: RequestLog.java. Nutzung des Singleton Patterns.

6.3.2. Strategy Pattern

Das Strategy Pattern entstand aus dem Prinzip "Favour Composition Over Inheritance" (FCOI,

dt. Ziehe Objektkomposition der Klassenvererbung vor), welches sich als Konkurrent zur Ver-

erbung sieht. Wenn Vererbung genutzt wird, gestaltet es sich schwieriger, das Programm zu

kapseln, da die zu erbende Klasse abhängig ist von der Basisklasse. Der Abghängigkeitsgrad

liegt an der Menge an nicht überschriebenen Methoden bzw. Elementen in der erbenden Klasse

Design Pattern 55

(White-Box-Verhalten). Beim FCOI wird versucht, die Abhähngigkeit so gering wie möglich zu

halten, indem der Inhalt beteiligter Objekte nicht sichtbar ist (Black-Box-Verhalten). Dadurch

gibt es nur noch die Abhängigkeit zur Abstraktion.

Das Strategy Pattern nutzt das FCOI Prinzip, um die Auswahl von Algorithmen während der

Laufzeit zu vollziehen. Abbildung 6.1 zeigt wie die Klasse Request die Abstraktion IOpera-

tion vorgibt. Die Anwendung, die den RequestManager nutzt, die den RequestManager nutzt,

setzt dabei die konkrete Strategie zur Laufzeit fest. Dadurch ist die Unabhängigkeit der Klasse

RequestManager von der jeweilig ausgewählten Operation gegeben.

Abbildung 6.1.: Klassendiagramm zur Veranschaulischung des Strategy Patterns.

Folgend werden die Vorteile des Strategy Patterns erklärt:

Abhängigkeit wird verringert. Bei der Verwendung des Strategy Patterns wird ein Interface

verwendet, welches eine Abstraktion der existieren Strategien ist. Diese Strategien sind

zu Ihrer Abstraktion, also dem Interface, schwach abhängig.

Klassenhierarchien werden vermieden. Durch die Verwendung des Strategy Patterns gibt

es flache Hierarchien. Somit werden komplexe Klassenhierarchien vermieden.

Merfachvererbung ist möglich. In Java ist es nicht möglich, dass eine Klasse aus mehreren

Klassen erbt. Durch die Verwendung von Interfaces kann dieses aber simuliert werden.

56 Implementierung der Datenversendung

Testen ist einfacher. Tests mit Mock-Objekten sind leichter anzuwenden.

Dependency Injection. Im Gegensatz zur Vererbung wird bei diesem Pattern das Objekt (hier

die Klassen CreateFile, DeleteFile, Insert, Update und Delete) erst zur Laufzeit festgelegt.

Dadurch kann mithilfe von Dependency Injection das Objekt an den Nutzer des Interfaces

übergeben werden.

Nachteilig ist, dass es keine Wiederverwendung von Code gibt. [29, S. 132-137]

6.4. Implementierung der Datenversendung

Für die Abwicklung des Datenversandes ist die Klasse ConnectionHandler zuständig. Die-

ser wird mit einem InputStream, Outputstream und RequestManager initialisiert. Die bei-

den Streams sind aus der aufgebauten TCP Verbindung und sind für den Datenversand zustän-

dig. Der RequestManager ist verantwortlich für den Log und bearbeitet diesen. Die Methode

handleConnection() ist die einzige Funktion des ConnectionHandlers. Er erhält aus dem Re-

questManager den aktuellen Log und sendet diesen mithilfe eines ObjectOutputStream. Für

den Versand von Objekten über einen ObjectOutputStream muss das zu versendende Objekt

das Interface Serializable implementieren. Nach dem Versand des Logs, nimmt der Connec-

tionHandler den Log des Gegenüber an, welchen er dann dem RequestManager übergibt (Lis-

ting 6.10).

Implementierung der Datenversendung 57

1 p u b l i c c l a s s C o n n e c t i o n H a n d l e r {2

3 p r i v a t e f i n a l I n p u t S t r e a m i s ;4 p r i v a t e f i n a l Ou tpu tS t r eam os ;5 p r i v a t e f i n a l Reques tManager r e q u e s t M a n a g e r ;6

7

8 p u b l i c C o n n e c t i o n H a n d l e r ( f i n a l I n p u t S t r e a m i s , f i n a l Ou tpu tS t r eam os ,f i n a l Reques tManager r e q u e s t M a n a g e r ) {

9 t h i s . i s = i s ;10 t h i s . os = os ;11 t h i s . r e q u e s t M a n a g e r = r e q u e s t M a n a g e r ;12 }13

14

15 p u b l i c vo id h a n d l e C o n n e c t i o n ( ) {16 / / s e n d i n g l o g17 f i n a l RequestLog r e q u e s t L o g = t h i s . r e q u e s t M a n a g e r . ge tLog ( ) ;18 f i n a l L i n k e d L i s t < Reques t > l o g = r e q u e s t L o g . g e t R e q u e s t L i s t ( ) ;19 t r y {20 f i n a l O b j e c t O u t p u t S t r e a m oos = new O b j e c t O u t p u t S t r e a m ( t h i s . os ) ;21 oos . w r i t e O b j e c t ( l o g ) ;22 } c a t c h ( f i n a l IOExcep t ion e ) {23 e . p r i n t S t a c k T r a c e ( ) ;24 }25

26 / / r e c e i v i n g l o g27 f i n a l L i n k e d L i s t < Reques t > r e c e i v e d L o g ;28 t r y {29 f i n a l O b j e c t I n p u t S t r e a m o i s = new O b j e c t I n p u t S t r e a m ( t h i s . i s ) ;30 r e c e i v e d L o g = ( L i n k e d L i s t < Reques t >) o i s . r e a d O b j e c t ( ) ;31 t h i s . r e q u e s t M a n a g e r . addToQueue ( r e c e i v e d L o g ) ;32 } c a t c h ( f i n a l IOExcep t ion | C l a s s N o t F o u n d E x c e p t i o n e ) {33 e . p r i n t S t a c k T r a c e ( ) ;34 r e t u r n ;35 }36 }37 }

Listing 6.10: ConnectionHandler.java aus dem Decentralized Calendar. Er ist verantwortlich für denEmpfang und Versand des Logs.

7. Fazit

Der entwickelte Algorithmus kann Kalenderdaten des Standards iCalendar in einem dezentralen

System unter mehreren Nutzern synchronisieren. Durch die Dezentralität des Systems und der

Offlinenutzung ist aber keine vollständige Konsistenz der Daten gewährleistet. Sie ist nur vor-

handen, wenn alle Knoten dauerhaft mit dem Internet und somit dem Netz Verbunden sind. Die

anfangs gestellte Fragestellung: „Wie ist es möglich Kalenderdaten in einem dezentralen System

zu synchronisieren?“ wird im Folgenden beantwortet:

Als Grundlage diente Imines Algorithmus [20], der weiterentwickelt und auf die Anforde-

rungen dieser Arbeit angepasst wurde. Für die Datensynchronisation werden Änderungen am

Datensatz in einem Log gesammelt, um bei einer bestehenden Verbindung zum Netzwerk, an

andere Knoten verteilt zu werden. Die Änderungen werden Anfragen genannt und sind eindeu-

tig identifizierbar. Eine Anfrage beschreibt die Änderung des Objektes mithilfe einer Operation,

für die es fünf verschiedene Typen gibt: Erstellen und Löschen eines Objektes sowie das Ein-

fügen, Aktualisieren und Löschen von Daten innerhalb des Objektes. Knoten, die einen Log

eines anderen Knotens erhalten, senden diesem Knoten ihren eigenen Log. Beide Teilnehmer

entnehmen einzeln die Anfragen und formatieren die darin enthaltene Operation um. Durch die

Umformatierung wird sichergestellt, dass beide Replikate nach der Durchführung der Anfragen,

identisch sind.

Der zeitliche Rahmen dieser Arbeit erlaubte es nicht, eine vollständige Implementation ei-

nes komplexen dezentralen Systems zu erstellen. Die Implementierung zeigt nur, wie zwischen

einer aufgebauten Verbindung zweier Knoten, Daten ausgetauscht und synchronisiert werden.

Um ein eigenständiges Framework zu entwickeln erfordert es mehr Zeit. Auf eine vollständige

Dokumentation zur Nutzung der Implementierung ist ebenfalls verzichtet worden.

Diese Arbeit kann dazu verwendet werden ein Framework zu entwickeln, die in ein bestehen-

des dezentrales System eingebunden wird. Das Framework würde sich um die Daten kümmern

und bei einer bestehenden Verbindung zum Netzwerk, die Synchronisierung seiner Daten star-

ten.

8. Literaturverzeichnis

[1] M. T. Özsu and P. Valduriez, Principles of distributed database systems, 3rd ed. Springer

Science+Business Media, 2011.

[2] E. Rahm, G. Saake, and K.-U. Sattler, Verteiltes und paralleles Datenmanagement: von

verteilten Datenbanken zu Big Data und Cloud, ser. eXamen.press. Springer Vieweg,

2015.

[3] S. Tai, J. Eberhardt, and M. Klems, Not ACID, not BASE, but SALT: A Transaction Pro-

cessing Perspective on Blockchains. Technische Universität Berlin, 2017.

[4] Plenk, Angewandte Netzwerktechnik kompakt. Springer Vieweg, 2019.

[5] P. Hummel, “Konzepte und algorithmen zur datensynchronisation mit cloud-datenzentren,”

2012, zugriff: 18.8.2019. [Online]. Available: http://elib.uni-stuttgart.de/handle/11682/

3020

[6] D. Pritchett, “BASE: An acid alternative,” vol. 6, no. 3, pp. 48–55, 2008, zugriff:

23.8.2019. [Online]. Available: http://doi.acm.org/10.1145/1394127.1394128

[7] Google kalender – holen sie sich die neue app für android und iPhone. Zugriff: 2.9.2019.

[Online]. Available: https://www.google.com/intl/de/calendar/about/

[8] P. Beuth, “Snowden-enthüllungen: Alles wichtige zum NSA-skandal,” Die Zeit, 2016,

zugriff: 1.9.2019. [Online]. Available: https://www.zeit.de/digital/datenschutz/2013-10/

hintergrund-nsa-skandal

[9] J. Callison, “Methods & tools,” Methods & Tools, vol. 17, pp. 49–64, 2019.

[10] T. Härder and E. Rahm, Datenbanksysteme: Konzepte und Techniken der Implementierung,

2nd ed. Springer, 2001.

[11] S. Luber and N. Litzel. Was ist ein zwei-phasen-commit

(2pc)? Zugriff: 18.8.2019. [Online]. Available: https://www.bigdata-insider.de/

was-ist-ein-zwei-phasen-commit-2pc-a-826808/

http://elib.uni-stuttgart.de/handle/11682/3020

http://elib.uni-stuttgart.de/handle/11682/3020

http://doi.acm.org/10.1145/1394127.1394128

https://www.google.com/intl/de/calendar/about/

https://www.zeit.de/digital/datenschutz/2013-10/hintergrund-nsa-skandal

https://www.zeit.de/digital/datenschutz/2013-10/hintergrund-nsa-skandal

https://www.bigdata-insider.de/was-ist-ein-zwei-phasen-commit-2pc-a-826808/

https://www.bigdata-insider.de/was-ist-ein-zwei-phasen-commit-2pc-a-826808/


[12] E. Rahm, Mehrrechner-Datenbanksysteme - Grundlagen der verteilten und parallelen Da-

tenbankverarbeitung. Oldenbourg-Verlag, 1994.

[13] P. Mandl, TCP und UDP Internals: Protokolle und Programmierung, ser. Lehrbuch.

Springer Vieweg, 2018.

[14] ——, Internet Internals: Vermittlungsschicht, Aufbau und Protokolle, ser. Lehrbuch.

Springer Fachmedien Wiesbaden GmbH, 2019.

[15] Abts, Masterkurs Client/Server-Programmierung mit Java. Springer Vieweg, 2019.

[16] A. Tridgell and P. Mackerras, “The rsync algorithm,” 1996.

[17] A. Demers, K. Petersen, M. Spreitzer, D. Terry, M. Theimer, and B. Welch, “The bay-

ou architecture: Support for data sharing among mobile users,” Xerox Palo Alto Research

Center, 1997.

[18] D. Terry, A. Demers, K. Petersen, M. Spreitzer, M. Theimer, and B. Welch, Session gua-

rantees for weakly consistent replicated data. Xerox Palo Alto Research Center, 1994.

[19] K. Petersen, M. Spreitzer, D. Terry, and M. Theimer, “Bayou: Replicated database services

for world-wide applications,” Xerox Palo Alto Research Center, 1996.

[20] A. Imine, “Coordination model for real-time collaborative editors,” in Coordination Mo-

dels and Languages, J. Field and V. T. Vasconcelos, Eds. Springer Berlin Heidelberg,

2009, pp. 225–246.

[21] “A primer to SyncML/OMA DS,” zugriff: 22.8.2019. [Online]. Availa-

ble: http://www.openmobilealliance.org/release/SyncML_Primer/V1_0-20071002-C/

OMA-WP-SyncML_Primer-20071002-C.pdf

[22] A.-M. Kermarrec, A. Rowstron, M. Shapiro, and P. Druschel, “The IceCube approach

to the reconciliation of divergent replicas,” in Proceedings of the twentieth annual ACM

symposium on Principles of distributed computing - PODC ’01. ACM Press, 2001, pp.

210–218. [Online]. Available: http://portal.acm.org/citation.cfm?doid=383962.384020

[23] B. Desruisseaux [email protected]. Internet calendaring and scheduling

core object specification (iCalendar). Zugriff: 14.8.2019. [Online]. Available: https:

//tools.ietf.org/html/rfc5545

http://www.openmobilealliance.org/release/SyncML_Primer/V1_0-20071002-C/OMA-WP-SyncML_Primer-20071002-C.pdf

http://www.openmobilealliance.org/release/SyncML_Primer/V1_0-20071002-C/OMA-WP-SyncML_Primer-20071002-C.pdf

http://portal.acm.org/citation.cfm?doid=383962.384020

https://tools.ietf.org/html/rfc5545

https://tools.ietf.org/html/rfc5545

62 8. Literaturverzeichnis

[24] M. Angstadt, “biweekly is an iCalendar library written in java. contribute to

mangstadt/biweekly development by creating an account on GitHub,” original-date:

2015-11-22T14:57:45Z. [Online]. Available: https://github.com/mangstadt/biweekly

[25] JUnit 5. Zugriff: 4.9.2019. [Online]. Available: https://junit.org/junit5/

[26] AssertJ / fluent assertions for java. Zugriff: 4.9.2019. [Online]. Available: https:

//joel-costigliola.github.io/assertj/

[27] Maven – welcome to apache maven. Zugriff: 3.9.2019. [Online]. Available: https:

//maven.apache.org/

[28] K. Eilebrecht and G. Starke, Patterns kompakt: Entwurfsmuster für effektive Softwareent-

wicklung, 5th ed., ser. IT kompakt. Springer Berlin, 2019.

[29] Goll, Entwurfsprinzipien und Konstruktionskonzepte der Softwaretechnik. Springer View-

eg, 2019.

[30] X/Open Company, Distributed transaction processing: the XA specification. X/Open,

1991.

https://github.com/mangstadt/biweekly

https://junit.org/junit5/

https://joel-costigliola.github.io/assertj/

https://joel-costigliola.github.io/assertj/

https://maven.apache.org/

https://maven.apache.org/

9. Glossar

Asynchron. Gegenteil von Synchron. Nicht gleichzeitig.

Checksums. Anhand eines Checksums wird die Integrität eines Datensatzes geprüft. Er wird

aus anhand des Datensatzes berechnet und bietet die Möglichkeit Bitfehler zu entdecken.

Convetion over Configuration . Ziel dieses Paradigmas ist die Reduzierung der Komplexität

von Konfiguration. Durch die Einhaltung von Konventionen muss weniger Konfiguriert

werden. Das erspart viel Arbeit und somit auch Zeit.

Flatfile. Ein strukturloser Datensatz. Meistens sind dies reine Textdateien. Aber auch CSV

Dateien sind Flatfiles.

Log. In einem Log werden ausgeführte Prozesse gespeichert.

Optimistische Verfahren. Gehen davon aus, dass bei der Datensynchronisation Konflikte sel-

ten bis gar nicht auftreten.

Overhead. Das sind alle Daten, abseits der Nutzdaten, die mitgeschickt werden.

Pessimistische Verfahren. Gehen davon aus, dass bei der Datensynchronisation Konflikte

häufiger auftreten.

Propagation. Ist die Verteilung von Daten.

Read & Write. Sind die beiden Zugriffsarten Lesen und Schreiben.

Single Point of Failure. Darunter versteht man Systeme die Komponenten besitzen, die bei

einem Fehler bzw. Ausfall das gesamte System lahmlegen.

Transparenz. In der Informatik bedeutet Transparenz, dass der Benutzer einer Anwendung,

den Teil des Systems der Transparent ist, nicht wahrnimmt.

Transaktion. Ist eine Folge von Datenbank-Operationen. Mit einer Rollback-Anweisung ist es

möglich die Transaktion abzubrechen. Eine Transaktion ist nicht auf einen Knoten limi-

tiert, es können also auch mehrere Knoten involviert sein. [2, S. 228]


X/Open XA. Ein Standard zur Abarbeitung von Transaktionen über mehrere Knoten [30].

A. Anhang

A.1. Listings

1 <?xml v e r s i o n = " 1 . 0 " e n c o d i n g ="UTF−8"?>2 < p r o j e c t xmlns : x s i =" h t t p : / / www. w3 . org / 2 0 0 1 / XMLSchema−i n s t a n c e " xmlns =" h t t p : / /

maven . apache . o rg /POM/ 4 . 0 . 0 "3 x s i : s chemaLoca t ion =" h t t p : / / maven . apache . o rg /POM/ 4 . 0 . 0 h t t p : / / maven .

apache . o rg / xsd / maven −4 . 0 . 0 . xsd ">4 <modelVers ion > 4 . 0 . 0 < / modelVers ion >5 6 < groupId > org . s p r i n g f r a m e w o r k . boot < / groupId >7 < a r t i f a c t I d > s p r i n g−boot−s t a r t e r −p a r e n t < / a r t i f a c t I d >8 < v e r s i o n > 2 . 1 . 5 . RELEASE</ v e r s i o n >9 < r e l a t i v e P a t h / > <!−− l ookup p a r e n t from r e p o s i t o r y −−>

10 11 < groupId >de . htw . a i < / g roupId >12 < a r t i f a c t I d > d e c e n t r a l i s e d _ c a l e n d a r < / a r t i f a c t I d >13 < v e r s i o n >0.0.1−SNAPSHOT</ v e r s i o n >14 < packag ing >war < / packag ing >15 <name> d e c e n t r a l i s e d _ c a l e n d a r < / name>16 < d e s c r i p t i o n > B a c h e l o r T h e s i s P r o j e c t < / d e s c r i p t i o n >17

18 19 < j a v a . v e r s i o n >11 </ j a v a . v e r s i o n >20 21

22 < d e p e n d e n c i e s >23 <dependency >24 < groupId > org . p o s t g r e s q l < / groupId >25 < a r t i f a c t I d > p o s t g r e s q l < / a r t i f a c t I d >26 <scope > run t ime </ scope >27 </ dependency >28 <dependency >29 < groupId > org . p r o j e c t l o m b o k </ groupId >30 < a r t i f a c t I d >lombok </ a r t i f a c t I d >31 < o p t i o n a l > t r u e < / o p t i o n a l >

Listings 67

32 </ dependency >33

34 <!−− i C a l e n d a r Framework−−>35 <dependency >36 < groupId > n e t . s f . b iweekly < / groupId >37 < a r t i f a c t I d > biweekly < / a r t i f a c t I d >38 < v e r s i o n > 0 . 6 . 3 < / v e r s i o n >39 </ dependency >40

41 <!−−TESTING−−>42 <dependency >43 < groupId > org . j u n i t . j u p i t e r < / groupId >44 < a r t i f a c t I d > j u n i t − j u p i t e r −ap i < / a r t i f a c t I d >45 < v e r s i o n > 5 . 3 . 2 < / v e r s i o n >46 <scope > t e s t < / scope >47 </ dependency >48 <dependency >49 < groupId >commons−io < / groupId >50 < a r t i f a c t I d >commons−io < / a r t i f a c t I d >51 < v e r s i o n >2 .6 < / v e r s i o n >52 <scope > t e s t < / scope >53 </ dependency >54 <!−− h t t p s : / / m v n r e p o s i t o r y . com / a r t i f a c t / o rg . apache . commons / commons−

l a n g 3 −−>55 <dependency >56 < groupId > org . apache . commons < / groupId >57 < a r t i f a c t I d >commons−l ang3 </ a r t i f a c t I d >58 < v e r s i o n >3 .9 < / v e r s i o n >59 </ dependency >60 <!−− h t t p s : / / m v n r e p o s i t o r y . com / a r t i f a c t / o rg . apache . commons / commons−

c o l l e c t i o n s 4 −−>61 <dependency >62 < groupId > org . apache . commons < / groupId >63 < a r t i f a c t I d >commons−c o l l e c t i o n s 4 < / a r t i f a c t I d >64 < v e r s i o n >4 .0 < / v e r s i o n >65 </ dependency >66

67

68

69 <!−− I n p u t s t r e a m t o S t r i n g −−>70 <dependency >71 < groupId >com . g oo g l e . guava < / groupId >72 < a r t i f a c t I d >guava < / a r t i f a c t I d >73 < v e r s i o n >28.0− j r e < / v e r s i o n >

68 Algorithmen

74 </ dependency >75 <dependency >76 < groupId > org . a s s e r t j < / g roupId >77 < a r t i f a c t I d > a s s e r t j −core < / a r t i f a c t I d >78 < v e r s i o n > 3 . 1 1 . 1 < / v e r s i o n >79 </ dependency >80

81

82 </ d e p e n d e n c i e s >83

84 85 86 87 < groupId > org . s p r i n g f r a m e w o r k . boot < / groupId >88 < a r t i f a c t I d > s p r i n g−boot−maven−p l u g i n < / a r t i f a c t I d >89 90 91 92

93 

Listing A.1: Vollständige POM aus dem Decentralized Calendar Projekts

A.2. Algorithmen

Algorithmus 2 ComputeBF

1: function COMPUTEBF(q,L)2: q′← q3: for (i = |L|−1; i≥ 0; i−−) do4: if q′ is not dependent of L[i] then5: q′← ET (q′,L[i]) return q′

6: else7: q.a′ = (L[i].p,L[k].k,df j)8: . d f j with j = 1,2,3,4 or 5 according to the dependecy form9: end if

10: end for11: return q′

12: end function

Algorithmen 69

Algorithmus 3 Canonize1: function CANONIZE(q,L)2: L′← L[L;q]3: i← |L|−14: while L′ is not canonical do5: < L′[i−1],L′[i]>← PERM(L′[i],L′[i−1])6: end while7: return L′

8: end function

Algorithmus 4 ComputeFF

1: function COMPUTEFF(q,L)2: q′← q3: j←−14: if q′.a! = null then5: Let L[ j] be the request whose q′ depends on ( j ∈ {0, ..., |L|−1})6: Modify q′.o with respect to L[ j].o and the dependency form7: end if8: for (i = j+1; i≤ |L|−1; i++) do9: if q′ is not dependent of L[i] then

10: q′← IT (sq′,L[i])11: end if12: end for13: return q′

14: end function

70 Algorithmen

Algorithmus 5 Inclusive Transformation1: function IT(q1,q2)2: q′1← q13: switch q1,q2 do4: case q1 = i1 and q2 = i25: if (p2 < p1 or (p2 = p1 and p2.c < p1.c)) then6: q′1.o← Ins(p1 +1,e1,w1)7: end if8: case q1 = i1 and q2 = d29: if (p2 < p1) then

10: q′1.c← Ins(p1−1,e1, p1w1)11: else if (p2 = p1) then12: q′1.o← Ins(p1,e1, p1w1)13: end if14: case q1 = d1 and q2 = i215: if (p2 ≤ p1) then16: q′1.o← Del(p1 +1)17: end if18: case q1 = d1 and q2 = d219: if (p2 < p1) then20: q′1.c← Del(p1−1)21: else if (p2 = p1) then22: q′1.o← NoOp()23: end if24: case q1 = u1 and q2 = i225: if (p2 ≤ p1) then26: q′1.c←U p(p1 +1,old(u1),new(u1))27: end if28: case q1 = u1 and q2 = u229: if (p2 = p1 and q2 < q1.c) then30: q′1.c←U p(p1,new(u2),new(u1))31: else if (p2 = p1 and q2 > q1.c) then32: q′1.o← NoOp()33: end if34: case q1 = u1 and q2 = d235: if (p2 < p1 then36: q′1.c←U p(p1−1,old(u1),new(u1))37: else if (p2 = p1) then38: q′1.o← NoOp()39: end if

return q′140: end function

Algorithmen 71

Algorithmus 6 Exclusive Transformation1: function IT(q1,q2)2: q′1← q13: switch q1,q2 do4: case q1 = i1 and q2 = i25: if ((p2 = p1 and p2.c≤ p1.c)or(p2 = p1 +1 and p2.c≥ p1.c)) then6: q′1.o← NoOp()7: else8: q′1.o← Ins(p1−1,e1,w1)9: end if

10: case q1 = i1 and q2 = d211: if (p2 = p1) then12: q′1.o← Ins(p1,e1, pop(w1))13: . Funktion pop() entfernt das oberste Element und gibt den Stack wieder zurück14: else if (p2 < p1) then15: q′1.o← Ins(p1 +1,e1, pop(w1))16: end if17: case q1 = d1 and q2 = i218: if (p2 +1≤ p1) then19: q′1.o← Del(p1−1)20: else if (p2 = p1) then21: q′1.o← NoOp()22: end if23: case q1 = d1 and q2 = d224: if (p2/leqp1) then25: q′1.o← Del(p1 +1)26: end if27: case q1 = u1 and q2 = i228: if (p2 < p1) then29: q′1.o←U p(p1−1,old(u1),new(u1))30: else if (p2 = p1 then31: q′1.o← NoOp()32: end if33: case q1 = u1 and q2 = u234: if (p2 < p1 and q2 < q1.c) then35: q′1.o←U p(p1 +1,old(u1),new(u1))36: end if37: case q1 = u1 and q2 = d238: if (p2 = p1 and p2.c < p1.c) then39: q′1.o←U p(p1,old(u2),new(u1))40: else if (p2 = p1) then41: q′1.o← NoOp()42: end if

return q′143: end function

72 Eidesstattliche Versicherung

A.3. Eidesstattliche Versicherung

Hiermit versichere ich, Mohamadbehzad Karimi Ahmadabadi, an Eides statt durch meine Un-

terschrift, dass ich die vorstehende Arbeit selbstständig und ohne fremde Hilfe angefertigt und

alle Stellen, die ich wörtlich oder annähernd wörtlich aus Veröffentlichungen entnommen habe,

als solche kenntlich gemacht habe, mich auch keiner anderen als der angegebenen Literatur oder

sonstiger Hilfsmittel bedient habe. Die Arbeit hat in dieser oder ähnlicher Form noch keiner an-

deren Prüfungsbehörde vorgelegen.

——————————————————-

Datum, Ort, Unterschrift

Implementierung eines dezentralen Kalenders basierend auf Java · Kalenders basierend auf Java von...

Documents

Transcript of Implementierung eines dezentralen Kalenders basierend auf Java · Kalenders basierend auf Java von...