4. Replikation und Synchronisation

Präsentation zum Thema: "4. Replikation und Synchronisation"—  Präsentation transkript:

1 4. Replikation und Synchronisation

2 4. Replikation und Synchronisation Gliederung
4.1 Motivation 4.2 Replikation 4.3 Synchronisation 4.4 Klassische Verfahren 4.5 Neue mobile Verfahren 4.6 SyncML (Synchronization Markup Language) 4.7 Zusammenfassung

3 4.1 Motivation Was ist Replikation? Projektion Selektion
Ziel: Daten sollen in Offline-Phasen unabhängig auf einem Client bearbeitet werden können Replikation bezeichnet das Anlegen einer Kopie und damit die Einführung von Datenredundanz Daten werden dadurch auf mobilen Clients verfügbar oft auch nur Teile (Selektion, Projektion) der urspüngl. Relation (-> Nachforderungen, schwieriger Wiederabgleich) Projektion Relation Selektion

4 Motivation Was ist Synchronisation?
Auf den Clients geänderte Daten sollen wieder auf den Server rückübertragen werden Probleme entstehen, wenn auch dort die Daten zwischenzeitlich geändert wurden Ziel: Datenkonsistenz innerhalb einer Replikationsumgebung, da Inkonsistenzen zu schwerwiegenden Fehlern führen können Bei der Synchronisation werden die geänderten Daten nach bestimmten Verfahren (meistens konventionell, zeitstempelbasiert oder semantisch) abgeglichen  Replikation und Synchronisation sind wichtige Grundlagen für Offline-Szenarien

5 4.2 Replikation 4.2.1 Ursprung Ursprung der Replikation:
Ursprung in den verteilten Systemen und in den verteilten Datenbanksystemen Verteilte, nichtreplizierende (DB-)Systeme sind wesentlich anfälliger für Ausfälle im Gegensatz zu zentralistisch ausgelegten Systemen Um Ausfall von einem Knoten zu kompensieren, werden wichtige Daten redundant auf mehreren Knoten abgespeichert Auch Daten mit hohen Zugriffsraten werden auf mehrere Knoten verteilt Alle Knoten die replizierte Daten enthalten bilden zusammen die Replikationsumgebung

6 4.2.2 Vorteile von Replikation
Höhere Verfügbarkeit durch Verteilung der Daten auf mehrere Knoten Niedrigere Kommunikationskosten Bessere Performanz durch lokalen Zugriff Ermöglicht Lastverteilung (Zugriff auf Knoten mit geringster Last) Vorbeugung gegenüber Datenverlust Replikation ist Grundlage für das Arbeiten mit Clients, die sich im Disconnected Mode befinden  Suche nach intelligenten Verfahren zur Auswahl der zu replizierenden Daten

7 4.2.3 Was ist ein Replikat? Definition
Ein Replikat ist eine Kopie, also eine redundante Speicherung eines bereits existierenden Datenelements Datenelement kann ein Tupel, eine Relation, Teile einer Relation oder eine ganze Datenpartition sein Per se gibt es kein Originalelement, dieses kann aber bei Bedarf festgelegt werden Es können beliebig viele Kopien existieren

8 4.2.4 Zentrale Strategien beim Einsatz der Replikation
Übersicht: Kopie-Update-Strategien Fehlerbehandlungs-Strategien Synchronisations-Strategien konkurrierender Zugriffe Konsistenz-Strategien bei Lesetransaktionen

9 Zentrale Strategien beim Einsatz der Replikation
Kopie-Update-Strategien: Datenoperationen werden auf einem einzelnen Replikat ausgeführt Die daraus resultierenden Änderungen werden auf 2 verschiedene Arten an die anderen Kopien weitergegeben Wenn alle Replikate gleichzeitig aktualisiert werden, spricht man von Eager Replication Wenn die Änderung asynchron an die anderen Replikate weitergegeben wird, spricht man von Lazy Replication Die Erlaubnis zur Änderung ist oft an spezifische Bedingungen geknüpft und hängt oft von den anderen Kopien des Replikats ab (z.B. Quorum-Verfahren)

10 Zentrale Strategien beim Einsatz der Replikation
Fehlerbehandlungsstrategien: Enthält Methoden, mit denen auf Fehlersituationen während der Replikation reagiert wird Repräsentiert den Ausnahmefall gegenüber den durch die Kopie-Update-Strategien abgedeckten Normalfall Häufigste Fehlersituation sind typische Netzpartitionierungen, wenn also Clients dauerhaft vom Gesamtsystem getrennt werden In mobilen Umgebungen aber Netzpartitionierungen Normalfall, deshalb hat die „Fehlerbehandlung“ eine wichtige Rolle (Begriff „Fehlerbehandlung“ in diesem Zusammenhang fraglich)

11 Zentrale Strategien beim Einsatz der Replikation
Synchronisation konkurrierender Zugriffe Wichtig sind Methoden zur Konsistenzsicherung innerhalb einer Replikationsumgebung Aufgabe: Eine geeignete Serialisierbarkeitsreihenfolge (Schedule) finden, damit bei allen Replikaten während allen Transaktionen keine Konsistenzkonflikte entstehen 3 Synchronisationsverfahren: konventionell (mit Einsatz von Sperren), optimistisch (zeitstempelbasiert, read-set, write-set) semantisch (Einbeziehung von speziellem Anwendungswissen)

12 Zentrale Strategien beim Einsatz der Replikation
Konsistenzstrategien: 3 verschiedene Konsistenzgrade bei Lese-TAs: Replikate sind aktuell und konsistent negativ für Gesamtdurchsatz, kein disconnected Mode Konsistent, aber dürfen etwas veraltet sein. Durch Versionskonzept können Lese- und Änderungstransaktionen parallel ablaufen innerhalb bestimmter Toleranzgrenzen inkonsistent. Die Toleranzgrenze bestimmt die maximal erlaubte Abweichung vom aktuellen, konsistenten Datenbankzustand

13 4.2.5 Replikationsdefinition
Wichtigste Aufgabe der Replikation ist die Replikationsdefinition. Sie wird in 2 Subaufgaben gegliedert: Replikationsschemadefinition: Definiert den Ausschnitt des Datenbankschemas auf der Replikationsquelle, der für die Datenreplikation genutzt wird, und die Operationen, die auf den replizierten Daten ausgeführt werden dürfen, sowie zusätzliche Integritätsbedingungen Replikatdefinition: Wählt die zu replizierenden Daten aus (Selektionsbedingungen) Ausgewählt werden können alle Daten, die dem Replikationsschema genügen Neben Daten werden auch Integritätsbedingungen auf die Senke übertragen

14 4.2.6 Forderungen Weitere Forderungen in der Replikationsumgebung:
Replikationstransparenz: Der Benutzer merkt von unter schiedlichen Kopien nichts 1-Kopie-Serialisierbarkeit: Es gibt mind. einen Schedule, welcher mit seriellen Transaktionen auf einer Datenbank ohne Replikate den gleichen Endzustand erzeugt Replikationskorrektheit: Änderungen auf einer Kopie sind auf allen anderen Kopien nachziehbar: alle redundanten Kopien sind konsistent. Entweder streng korrekt (Identität) oder innerhalb bestimmter Grenzen ( Konsistenzgrade)

15 4.2.7 Zielkonflikt der Replikation
3 verschiedene Forderungen an die Replikation 1. Erhöhung der Verfügbarkeit 2. Konsistenz aller Kopien 3. Niedrige Kosten der Replikation Konflikt: Replikation wird oft eingesetzt um die Verfügbarkeit zu erhöhen Je mehr Senken, desto mehr Daten müssen konsistent gehalten werden Dadurch steigen mit der Zahl der Senken die Kosten Konsequenz: Alle 3 Forderung sind nie zu erreichen Je näher man 2 Forderungen kommt, desto mehr entfernt man sich von der 3. Verfügbarkeit Zielkonflikt der Replikation Konsistenz Kosten

16 4.3 Synchronisation Ziel: konsistenter Zustand aller Kopien innerhalb einer Replikationsumgebung Bei Synchronisation müssen Änderungen von der Replikationssenke auf die Quelle und umgekehrt übertragen werden Reintegration: Abgleich der geänderten Daten von Senke auf Quelle Rückübertragung: Quelle überträgt aktuellen + konsistenten Datenzustand auf die Senke Beide Phasen: Bidirektionale Synchronisation Eine Phase: unidirektionale Synchronisation

17 4.4 Klassische Replikations- und Synchronisationsverfahren
Die wichtigsten Replikations- und Synchronisationsverfahren: Konsistenzerhaltende Verfahren Pessimistische Verfahren (ROWA, Primary-Copy-Verfahren, Quorum, ...) Optimistische Verfahren (Log-Transformation, Data-Patch-Verfahren) Verfügbarkeitserhaltende Verfahren Epsilon-Serialisierbarkeit Quasi-Copy-Verfahren Data Caching (Replikation innerhalb der Speicherhierarchie) Data Hoarding (gezieltes Nachladen vom Server)

18 4.4.1 Konsistenzerhaltende Verfahren
Eigenschaften der konsistenzerhaltenden Verfahren Hauptziel: Strikte Durchsetzung der Konsistenz (oft auf Kosten der Verfügbarkeit) Unterteilt in pessimistische und optimistische Verfahren Pessimistische Verfahren: verwenden Sperren um von vorneherein alle möglichen Inkonsistenzen zu verhindern Änderungen können gleichzeitig (2-Phasen-Commit-Protokoll) (eager Repl.) oder asynchron (lazy Repl.) mit gesonderten Update-Aktionen durchgeführt werden Vorteil bei asynchronen Updates: keine systemübergreifende Sperren Optimistische Verfahren: Gehen von seltenen Inkonsistenzen aus und verwenden deshalb keine Sperren Nach jeder Transaktion findet Validierung statt, ob ein inkonsistenter Zustand vorliegt

19 Pessimistische Verfahren - ROWA -
ROWA (Read One Write All): Innerhalb einer Änderungstransaktion alle Kopien updaten (verwendet 2-Phasen-Commit-Protokoll) Alle Kopien eines Replikats sind deshalb stets konsistent Lesetransaktionen bekommen so auch keine veralteten Daten Erreichbarkeit aller Kopien muss gegeben sein deshalb in mobiler Umgebung so nicht einsetzbar, da viele mobile Clients sich im Disconnected Mode befinden Es exisiteren Varianten des ROWA-Verfahrens, die aber keine sinnvolle Lösungen für den Einsatz in mobilen Umgebungen sind, z.b. Write-All-Available oder Missing-Update

20 Pessimistische Verfahren - Primary-Copy Verfahren -
Änderungstransaktion wird erst auf einer Masterkopie durchgeführt Für die asynchrone Aktualisierung ist nun nicht mehr die Änderungstransaktion selbst, sondern die Masterkopie zuständig Stark zentralistisches Verfahren (Gleichheit aller Knoten wird aufgegeben) Vorteil: In mobiler Umgebung möglich, dann darf sich aber die Masterkopie nicht auf einem Client befinden, sondern auf stationärem Knoten Nachteil: Bei Änderungstransaktionen muss eine Netzwerkverbindung bestehen Bei Transaktionen mit vielen Updates kann der Knoten der Masterkopie zu einem Hot-Spot werden Die Wahrscheinlichkeit, dass keine Netzwerkverbindung für eine Änderungstransaktion besteht, steigt mit jedem Knoten  Abhilfe: Virtual-Primary-Copy-Verfahren (siehe später)

21 Pessimistische Verfahren - Quorum Verfahren -
Abstimmung entscheiden ob Aktualisierung durchgeführt wird Jede Kopie besitzt eine Anzahl von Stimmen (meistens 1) Um Aktualisierung durchzuführen muss die Transaktion die Mehrheit der Stimmen gewinnen (Majority Consensus) Transaktion gewinnt eine Stimme wenn eine Kopie durch diese Transaktion gesperrt werden kann Konkurrierendes Schreiben wird verhindert wenn Schreibquorum > n/2 (Anzahl der Stimmen) Konkurrierendes Lesen und Schreiben wird verhindert, wenn Lese- + Schreibquorum > n Randfall: Schreibquorum=n und Lesequ=1 dann ROWA-Verfahren

22 Pessimistische Verfahren - Quorum Verfahren -
Quorum-Verfahren Teil II: Variante: Einführung von Stimmgewichten Variante: Einführung von Zeugen (Stellvertreter-Knoten) Wenn Mehrheiten fest vergeben, dann spricht man von statischem Quorum-Verfahren Wenn zur Laufzeit vergeben, spricht man von dynamischen Quorum-Verfahren (z.B. zum Zeitpunkt verfügbarer Stimmen) (nur bedingt) in der mobilen Umgebung einsetzbar: Für Änderungstransaktion muss Verbindung zur Basisstation verfügbar sein. Diese muss dann das Quorum der anderen Kopien einholen Nur mindestens |Qw| Knoten müssen während Abstimmung online sein. Für Commit eigentlich alle, Nachziehen auf offline Knoten? Sperren halten? (Unwahrscheinlich, dass kein Client im Disconnected Mode)

23 Optimistische Verfahren
Eigenschaften: Keine Sperren, dafür wird am Ende jeder Transaktion validiert, ob konsistenter Zustand vorliegt (mittels Zeitstempel) Propagation durchgeführter Änderungen erfolgt dann asynchron Späteres Wiedereinbringen von Daten kann zu Konflikte führen (z.B. Änderungen auf einen bereits alten Datensatz) Häufig werden diese Konflikte durch semantisches Wissen aufgelöst (z.B. summierende Verfahren, „neueste Info zählt“…) Die 2 wichtigsten Verfahren sind Log-Transformation und das Data-Patch-Verfahren

24 Optimistische Verfahren - Log-Transformation -
Änderungen einer (mobilen) Kopie werden zuerst auf der zentralen Datenbank nachgezogen, dann an die anderen Kopien asynchron weitergegeben Alle Transaktionen werden in Logbuch-Einträgen protokolliert Bei Konflikten wird die konfliktauslösende Transaktion zurückgesetzt Einfaches Auflösen von Konflikten, aber umfangreiches oder kaskadierendes Zurücksetzten kompletter Transaktionen möglich

25 Optimistische Verfahren - Data Patch -
Data-Patch Verfahren Es gibt kein Zurücksetzen von TAs denn bereits beim Datenbankentwurf werden anwendungsbezogene Regeln festgelegt Diese Regeln legen fest, wie aus 2 verschiedenen Versionen ein neuer konsistenter Zustand wird (z.B. neueste Info zählt, Aufaddieren, Chef hat immer recht, ...) Data-Patch-Verfahren kann gut in mobilen Umgebungen eingesetzt werden Dieses Verfahren kann sowohl den konsistenz- als auch den verfügbarkeitserhaltenden Verfahren zugeordnet werden

26 4.4.2 Verfügbarkeitserhaltende Verfahren
Eigenschaften verfügbarkeitserhaltender Verfahren Im Gegensatz zu den konsistenzerhaltenden Verfahren steht hier die höhere (Lese-) Verfügbarkeit von Daten im Mittelpunkt Dies wird dadurch erreicht, dass in bestimmten Situationen inkonsistente Daten geduldet werden Konflikte werden oft durch semantisches Wissen aufgelöst (z.B. summierende Verfahren, Prioritätsverfahren oder „neueste-Info-zählt“-Verfahren) Werden keine Abweichungen toleriert, kann wieder von konsistenzerhaltenden Verfahren gesprochen werden

27 Verfügbarkeitserhaltende Verfahren
Beispiele für verfügbarkeitserhaltende Verfahren: Epsilon-Serialisierbarkeit: globaler Faktor Epsilon bestimmt tolerierbare Abweichung gegenüber bestimmten Konsistenzzustand Jedes Replikat hält selbst sein aktuelles Epsilon fest Lesezugriff auch auf epsilon-inkonsistente Replikate möglich  höhere Verfügbarkeit Quasi-Copy-Verfahren: Ähnlich zur Epsilon-Serialisierbarkeit aber jetzt Anzahl Änderungen auf lokaler Kopie oder Zeitspanne ausschlaggebend, nicht eine bestimmte Abweichung

28 Was bisher war Definition der Begriffe Replikation und Synchronisation
Ursprung und die Vorteile der Replikation 4 Zentralen Strategien beim Einsatz der Replikation Zielkonflikt der Replikation Beispiele für konstistenzerhaltende Verfahren 3 pessimistische Verfahren 2 optimistische Verfahren 2 Beispiele für verfügbarkeitserhaltende Verfahren

29 Was kommt Data Caching und Data Hoarding Verfahren
Verzicht auf Replikation Beispiele für neue mobile Verfahren Synchronization Markup Language (SyncML)

30 4.4.3 Data Caching Data Caching: (Replikation innerhalb der Speicherhierarchie) Zugriff auf Daten wird stark beschleunigt, wenn die Daten schon im Cache sind. Deshalb bevorzugte Speicherung im Cache Intelligente und vorrausschauende Verfahren gesucht, damit Daten mit hohen Zugriffsraten im Cache sind oder/und bleiben Da bei mobilen Clients der Cache bisher recht klein ist, sind solche intelligenten Verfahren sehr wichtig Eine Variante ist das semantische Cachen. Es werden zusätzlich Beschreibungen der Daten gespeichert, damit intelligente Einlagerungsstrategien implementiert werden können (Nachteil: Speicherplatzbedarf steigt)

31 Data Caching Cachen heißt zusätzliche Redundanzebene:
Bei Synchronisation: Cache-Kohärenz sicherstellen! Damit nicht mit alten Cache-Werten weitergearbeitet wird. Mobile Endgeräte: Vorab-Cache-Einlagerungen (Prefetching) Nicht nur zugriffs- und zeitabhängig auch ortsabhängig (bei Standortwechsel des Nutzers)

32 4.4.4 Data Hoarding Data Hoarding: (gezieltes, vorausschauendes Nachladen vom Server) Besondere Variante des Prefetchings bei Caches, speziell für die mobile Umgebung Datenaustausch zwischen Server und Client nur an speziellen Infostationen Die Infostationen sind mit WLANs ausgestattete Terminals, die untereinander mit Hochgeschwindigkeitsnetzwerk verbunden sind Gerade dort eingesetzt, wo Benutzer keine eigenen Clients, sondern nur anwendungsspezifische Clients haben (z.B. Museum)

33 Data Hoarding Spezieller Proxy-Server koordiniert sämtliche Hoarding-Prozesse: Schritt 1: Drahtloser Download der wahrscheinlich benötigten Informationen Schritt 2: Trennung der Verbindung zur Infostation Schritt 3: Gelegentliche Übertragung des protokollierten Nutzerverhaltens an erreichbare Infostationen bei Bedarf: Nachladen

34 4.4.5 Verzicht auf Replikation
Nur möglich, wenn eine zuverlässige und hochverfügbare Infrastruktur drahtloser Netzwerktechnologien vorhanden ist (z.B. firmeninternes WLAN) Zentrale Datenhaltung und eine Schnittstelle für drahtlosen Online-Zugriff anzubieten kann einfacher sein als Offline-Szenarien mit komplizierter Replikation und Synchronisation

35 4.5 Neue mobile Verfahren Eigenschaften:
Pessimistische Verfahren sind schlecht einsetzbar, da sie auf dem Einsatz von Sperren basieren. Sperren können aber sehr kritisch sein, falls ein Client eine Sperre setzt und in den Disconnected Mode wechselt und dort lange bleibt Grundlage sind die optimistischen Verfahren Trotzdem wurden auch pessimistische Verfahren entwickelt, Beispiel dafür ist das Virtual-Primary-Copy-Verfahren

36 Neue mobile Verfahren 1. Virtual-Primary-Copy
Virtual-Primary-Copy ist eine Variante des Primary-Copy Verfahren Basiert auf den konsistenzerhaltenden, pessimistischen Verfahren Masterkopie jetzt immer auf dem mobilen Client (!), zusätzlich noch eine virtuelle Masterkopie (Position frei wählbar, meist im Festnetz) Falls nun Masterkopie für andere Clients nicht erreichbar ist, können die anderen Clients ihre Änderungstransaktion auf der virtuellen Masterkopie durchführen Sobald wieder online muss ein Abgleich beider Kopien erfolgen, damit ein konsistenter Zustand vorliegt

37 Neue mobile Verfahren 2. Snapshot-Verfahren
Sehr gut einsetzbar in mobilen Umgebungen Snapshots sind materialisierte Sichten nichtlokaler Datenbestände Snapshots basiert auf einer Originaltabelle, auch Mastertabelle genannt Snapshots können einzelnen Tupel bis hin zu kompletten Relationen sein Replikationsserver werden als Master-Sites, mobile Clients als Snapshot-Sites bezeichnet Kommunikation kann synchron (verbindungsorientiert) oder asynchron (dateibasiert) erfolgen Synchronisation kann als Abgleich von Snapshots aufgefasst werden

38 Neue mobile Verfahren - Snapshot-Verfahren -
Publish & Subscribe-Modell: Der Server bietet Publikationen an, der Client subscribiert sie Publikationen = { Publikationsartikel* } Publikationsartikel = Snapshot beliebiger Granularität, z.b. durch SQL-Anweisung definiert Zuordnung von Publikationen (Snapshots) zu mobilen Clients erfolgt anhand von Subskriptionen (auch parametrisierbar)  Subskription = Zuordnung Replikationsquelle zu Senke

39 Neue mobile Verfahren - Snapshot-Verfahren -
Einfache vs. Komplexe Snapshots (vgl. View-Update Problem) Einfache Snapshots basieren auf einer einzelnen Tabelle. Zwischen Originaltabelle und Snapshot muss eine bijektive Abbildung existieren Komplexe Snapshots beziehen sich auf mehrere Tabellen oder enthalten GROUP BY oder Aggregatfkt oder weitere Snapshots Bei komplexen Snapshots ist keine Reintegration möglich, deshalb nur lesender Zugriff auf den mobilen Clients Zusammenfassung Snapshots unterstützen den Disconnected Mode mobiler Clients In Offline-Phasen können beliebig viele Update-Operationen ausgeführt werden Abgleich der Daten danach durch Synchronisation und gegebenenfalls durch Konfliktauflösungsroutinen

40 Neue mobile Verfahren 3. Replikationsserver-Verfahren
Motivation: Beobachtung: Replikation und Synchronisation erzeugt erhebl. Last auf stationärem DBS, besonders bei sehr vielen mobilen Clients Idee: Um den Datenbankserver von der Koordination der Replikation und Synchronisation zu entlasten, kann man die klassische Client/Server-Architektur erweitern um einen Replikationsserver (Replication Proxy Server) Dann auch anwendungsgesteuerte, dynamische Auswahl der Replikate SQL-ähnliche Schnittstelle, um eine solche dynamische Auswahl treffen zu können

41 Neue mobile Verfahren - Replikationsserver-Verfahren -
3-stufige Architektur: Replikationsanforderungen des mobilen Clients werden dann über den Replikationsserver an den Datenbankserver übertragen Replikationsserver hat eine Kopie der Daten vom Datenbankserver Aufgabe des Replikationsserver: Pflege von Daten- und Schemaelementen Bestimmung der zu replizierenden Daten unter der Berücksichtigung der bereits replizierten Daten Der Datenaustausch zwischen mobilen Client und Datenbankserver ist nur noch indirekt möglich Replikationsserver auf eigenem Rechner, z.B. auf Basisstation

42 Neue mobile Verfahren - Replikationsserver-Verfahren -
Architektur: Vorteil: Skalierbarkeit bei sehr vielen mobilen Clients (sync erzeugt erhebl. Last auf stationärem DBS) Ebenso können Lastspitzen vom Datenbankserver weg verteilt werden

43 Neue mobile Verfahren - Replikationsserver-Verfahren -
Anforderungen und Ablauf nutzerdefinierter Replikation: Heute meist traditioneller Szenarien: z.B. Zugriff auf einen gemeinsamen Informationspool Zukünftig: Location Based Services Dabei: Benutzer soll dann Daten nicht nur verwenden, sondern auch aktualisieren oder ergänzen Def.: nutzerdefinierte Replikation: Dienst, der dynamisch die zu replizierenden Daten abhängig von Position und Zeit bestimmt, damit diese Daten dann im Disconnected Mode weiterverarbeitet werden können

44 Neue mobile Verfahren - Nutzerdefinierte Replikation -
5 Anforderungen an die Implementierung nutzerdefinierter Replikation: Replikation: Anwendung soll nach den Vorgaben des Nutzer die Daten aus einer zentralen Datenbank lokal replizieren Replikationseffizienz: Nur Daten replizieren, die noch nicht lokal vorhanden sind Speicherplatzbeschränkung: Wenn für neue Daten kein Speicherplatz auf Client ist, müssen alte, nicht mehr benötigte Daten gelöscht werden Zugriff: jeder Nutzer soll über die notwendigen Änderungs- und Einfügerechte verfügen Konsistenz: Um Konsistenz der Daten zu garantieren, müssen Routinen für Konflikterkennung und –behandlung implementiert werden

45 Neue mobile Verfahren - Nutzerdefinierte Replikation -
Anforderungen und Ablauf: Weitere Punkte: Schnittstelle muss implementiert werden für Anwendungen, die dynamische Replikation von Daten anfordern, Replikate müssen mit Zusicherungen ergänzt werden (z.B. einem garantierten Einfügerecht) Der Abgleich der Daten zwischen Replikations- und Quellserver erfolgt asynchron Primärziel der Einführung eines Replikationsservers ist die Entkopplung der mobilen Nutzer vom Quellserver

46 4.6 Synchronization Markup Language (SyncML)
Definiert eine herstellerunabhängige Technologie für die Synchronisation von Daten in einem mobilen Client/Server-Szenario (Open Mobile Alliance: Nokia, IBM, Panasonic, Ericson, Motorola, ...) Als plattenformunabhängiges Datenformat der zu übertragenden Synchronisationsnachrichten wurde XML bestimmt Um die Abhängigkeit von bestimmten Netzwerkprotokollen zu umgehen, wurde der physikalische Transport aus SyncML ausgeklammert Welches Transportprotokoll benutzt wird, hängt von der jeweiligen Implementierung ab Ziel: alle anfallenden Synchronisationsvorgänge sollen über einen einzelnen Mechanismus abgewickelt werden Beispiel: Nokia Communicator 9210

47 Synchronization Markup Language
7 Synchronisationsszenarien: Zwei-Wege-Synchronisation (bidirektionale Synchronisation): Client und Server teilen sich nacheinander gegenseitig alle angefallenen Änderungen mit Langsame Synchronisation: Client übermittelt seine Änderungen an den Server, dort werden die empfangenen Änderungen feldweise mit dem Datenbestand verglichen Einweg-Synchronisation (Client): Client übermittelt seine Änderungen an den Server. Eventuelle zwischenzeitl. Änderungen auf dem Server werden ohne Nachfrage überschrieben Einweg-Synchronisation (Server): Wie beim Client, nur Übertragung von Server auf Client

48 Synchronization Markup Language
7 Synchronisationsszenarien: Erneuerungs-Synchronisation (Client): Der Client überträgt seinen kompletten Datenbestand an den Server. Auf dem Server werden alle entsprechenden Daten überschrieben Erneuerungs-Synchronisation (Server): Wie beim Client, nur Übertragung von Server auf Client. D.h. Server überschreibt alle Client-Daten komplett Serverinitiierte Synchronisation: Server stellt die Forderung an den Client, einen Synchroni-sationsvorgang, der einer der ersten sechs Typen sein muss, zu initialisieren

49 Synchronization Markup Language
Anforderungen für die Synchronisation: Datensätze müssen separierbar sein Jeder Datensatz muss eindeutig identifizierbar sein Identifikatoren werden serverseitig als Global Unique Identifier (GUID), clientseitig als Local Unique Identifier (LUID) bezeichnet Wenn auf Server und Client verschiedene Identifikatoren verwendet werden, muss der Server eine korrekte Zuordnung vornehmen können (Mapping-Tabelle) Datenveränderungen werden immer in Log-Dateien protokolliert (dienen als Grundlage für spätere Sync-Vorgänge)

50 Synchronization Markup Language
SyncML-Framework: Um Daten synchronisieren zu können, müssen alle beteiligten Anwendungen das SyncML Sync Protokoll implementieren SyncEngine auf Clientseite nicht abgebildet, da diese nur eingeschränkte Funktionen hat SyncML-Interface + -Adapter transformieren Originaldaten ins XML-Format Kommunikation aller beteiligten Instanzen erfolgt nur über diese Adapter Für das globale Management aller Synchronisationsprozesse wird ein Synchronisationsserver eingesetzt

51 Synchronization Markup Language
Synchronisationskonflikte: Können natürlich auch hier auftreten Konfliktlösung ist Aufgabe des Servers bzw. der SyncEngine Wenn SyncEngine Konflikt feststellt, wird dies an den konfliktauslösenden Client mitgeteilt SyncML legt aber nicht fest, welche Konfliktauflösungsroutinen in welchem Konfliktfall konkret angewandt werden sollen

52 Synchronization Markup Language
Synchronisationskonflikte Beispiele für Konfliktauflösungsmethoden: Kapitulation: Synchronisation wird nicht durchgeführt. Duplikat: Von dem Datensatz, der einen Konflikt ausgelöst hat, wird ein Duplikat angelegt. Beide Änderungen werden dann unabhängig voneinander auf jeweils einem der verfügbaren Datensätze ausgeführt. Priorität: Im Konfliktfall kann eine höhere priorisierte Operation bevorzugt werden. Gewinner: Dabei gewinnt immer eine der beiden Konfliktparteien. So kann z.B. immer der Client gewinnen.

53 4.7 Zusammenfassung Definition der Begriffe Replikation und Synchronisation Ursprung und die Vorteile der Replikation 4 Zentralen Strategien beim Einsatz der Replikation Zielkonflikt der Replikation Beispiele für konsistenz- und verfügbarkeitserhaltende Verfahren Data-Caching und Data-Hoarding-Verfahren Beispiele für neue mobile Verfahren Synchronization Markup Language (SyncML)