Implementierung eines dezentralen Kalenders basierend auf Java · Kalenders basierend auf Java von...
Transcript of 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.
42 Entwurf eines Algorithmus
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
Entwurf eines Algorithmus 43
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).
44 Entwurf eines Algorithmus
Availability Partition tolerance
Consistency
DecentralizedCalendar
Abbildung 5.1.: Decentralized Calendar Synchronisations-Eigenschaften abgebildet auf das CAP Theo-rem
.
Entwurf eines Algorithmus 45
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 < u r l > h t t p s : / / www. htw−b e r l i n . de < / u r l >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/
8. Literaturverzeichnis 61
[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
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.
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]
8. Literaturverzeichnis 65
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 < p a r e n t >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 </ p a r e n t >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 < p r o p e r t i e s >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 </ p r o p e r t i e s >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 < b u i l d >85 < p l u g i n s >86 < p l u g i n >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 </ p l u g i n >90 </ p l u g i n s >91 </ b u i l d >92
93 </ p r o j e c t >
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