Einführung in Microsoft Sync Framework Runtime

Microsoft Corporation
November 2007

Inhalt
Einführung
Teilnehmer
    Teilnehmertypen
Microsoft Synchronization Framework
    Hauptkomponenten
    Datenquelle
    Metadaten
    Synchronisierungsfluss
    Synchronisierungsbeispiel
    Konfliktbeispiel
Zusammenfassung

Einführung

Microsoft Sync Framework ist eine umfassende Synchronisierungsplattform, die Anwendungen, Diensten und Geräten Zusammenarbeit und Offlinezugriff ermöglicht. Es enthält Technologien und Tools zum Roaming, gemeinsamen Verwenden und Offlinebearbeiten von Daten. Entwickler werden in die Lage versetzt, mithilfe von Microsoft Sync Framework Synchronisierungsökosysteme zu erstellen, in denen alle Anwendungen mit beliebigen Datentypen aus allen Speichern mithilfe verschiedener Protokolle über alle Netzwerke integriert werden können.

Ein Hauptmerkmal von Microsoft Sync Framework ist die Erstellung benutzerdefinierter Synchronisierungsanbieter. Ein Anbieter ist eine Softwarekomponente, die ein Replikat für die Synchronisierung darstellt. Ein Replikat ist ein bestimmtes Repository mit zu synchronisierenden Informationen, wie z. B. ein Dateisystem auf einem tragbaren Gerät. Wenn ein Anbieter eine Datenquelle darstellt, listet er Änderungen von seinem Replikat auf. Wenn er ein Ziel darstellt, wendet er Änderungen auf sein Replikat an. Sollten sich die Daten an der Quelle und am Ziel hinsichtlich des Typs oder Schemas voneinander unterscheiden, führt jeder Anbieter alle notwendigen Zuordnungen oder Transformationen durch.

Microsoft Sync Framework enthält eine Anzahl von Anbietern, die übliche Datenquellen unterstützen. Auch wenn es möglich ist, eigene benutzerdefinierte Anbieter für diese Datenquellen zu schreiben, empfiehlt es sich, nach Möglichkeit von Microsoft bereitgestellte Anbieter zu verwenden. Hierdurch reduziert sich die Entwicklungszeit, und der vorhandene getestete Code kann wiederverwendet werden. Die folgenden Anbieter sind enthalten:

• Sync-Dienste für ADO.NET: Synchronisierung für ADO.NET-aktivierte Datenquellen
• Sync-Dienste für Dateisysteme: Synchronisierung für Dateien und Ordner
• Sync-Dienste für SSE: Synchronisierung für Simple Sharing Extensions (SSE) wie RSS- und ATOM-Feeds

Entwickler können letztendlich einen beliebigen der bereitgestellten Anbieter verwenden oder benutzerdefinierte Anbieter erstellen, um Informationen zwischen Geräten und Anwendungen auszutauschen.

Im restlichen Teil dieses Dokuments erfahren Sie, wie Microsoft Sync Framework die Synchronisierung ermöglicht, mit dem Ziel zum Erstellen einer Synchronisierungstopologie. Es werden einige Schlüsselkonzepte im Hinblick auf Synchronisierungsanbieter erläutert, die das Erstellen von Anbietern erklären. Ausführlichere Informationen zu Microsoft Sync Framework finden Sie unter https://msdn2.microsoft.com/en-us/sync/default.aspx.

Teilnehmer

Bevor auf die spezifischen Komponenten eines Anbieters eingegangen wird, sollen zunächst die unterschiedlichen von Microsoft Sync Framework unterstützten Synchronisierungsteilnehmertypen besprochen werden. Ein Teilnehmer ist die Kombination aus einem Anbieter und dem zugehörigen Replikat. Das Replikat ist das Repository der Informationen. Alles, von einem Webdienst, über einen Laptop bis hin zu einem USB Thumb Drive, kann synchronisiert werden.

Teilnehmertypen

Microsoft Sync Framework unterstützt drei Teilnehmertypen: vollständig, partiell und einfach. Der Typ eines Teilnehmers wird über seine Fähigkeit definiert, Synchronisierungsmetadaten zu speichern und zu verarbeiten. Es kann auf keinen Fall davon ausgegangen werden, dass ein Replikat auf Aufforderung programmatisch Informationen zurückgeben kann. Schließlich müssen die folgenden Fähigkeiten des Replikats ermittelt werden:

1. Speichern und Bearbeiten von Informationen entweder auf dem vorhandenen Gerät oder innerhalb des aktuellen Datenspeichers und
2. direktes Ausführen von Anwendungen (in diesem Fall eines Sync-Dienstes) auf dem Gerät

Die Teilnehmertypen, die Teil des Synchronisierungsökosystem sein werden, müssen unterschieden werden können. Auf diese Weise können wir erkennen, ob sie die vom Anbieter benötigten Statusinformationen speichern können und ob der Anbieter direkt vom Gerät ausgeführt werden kann. Darüber hinaus soll das Teilnehmermodell generisch sein. Aus diesem Grund kann ein vollständiger Teilnehmer auch als partieller oder einfacher Teilnehmer konfiguriert sein.

Vollständige Teilnehmer

Vollständige Teilnehmer sind Geräte, mit denen Entwickler Anwendungen und neue Datenspeicher direkt auf dem Gerät erstellen können. Laptops und Smartphones sind Beispiele für vollständige Teilnehmer, weil neue Anwendungen direkt vom Gerät ausgeführt werden können und Sie bei Bedarf zudem neue Datenspeicher zum Beibehalten von Informationen erstellen können.

Partielle Teilnehmer

Partielle Teilnehmer sind Geräte, die Daten auf dem Gerät speichern können. Diese Geräte können jedoch keine ausführbare Datei direkt vom Gerät starten. Eine wichtige Eigenschaft eines partiellen Teilnehmers ist die Fähigkeit, für die Synchronisierung erforderliche Metadaten zu speichern und auf diese Weise mit allen vollständigen Teilnehmern eine Synchronisierung durchzuführen. Ein Beispiel für einen partiellen Teilnehmer ist ein Thumb Drive. Diese Geräte funktionieren wie eine Festplatte, auf der Informationen erstellt, aktualisiert oder gelöscht werden können. Sie stellen in der Regel jedoch keine Schnittstelle bereit, auf der Anwendungen direkt ausgeführt werden können.

Einfache Teilnehmer

Einfache Teilnehmer sind Geräte, die nur auf Anforderung Informationen bereitstellen können. Diese Geräte können neue Daten weder speichern noch ändern und können auch nicht die Erstellung neuer Anwendungen unterstützen. Ein einfacher Teilnehmer ist hinsichtlich der Speicherung seiner Metadaten von einem vollständigen Teilnehmer abhängig (und kann folglich nur mit dem bestimmten vollständigen Teilnehmer eine Synchronisierung durchführen).

RSS-Feeds und Webdienste, die von einer externen Organisation wie z. B. Amazon oder EBay bereitgestellt werden, sind Beispiele für einfache Teilnehmer. Auch wenn diese Organisationen es Ihnen ermöglichen, Webdienste auszuführen und Ergebnisse abzurufen, können Sie jedoch keine eigenen Datenspeicher erstellen oder eigene Anwendungen auf ihren Webservern ausführen.

Letzte Schritte

Das Hauptziel von Microsoft Sync Framework ist die Integration aller Datenquellen unabhängig vom Teilnehmertyp. Aus diesem Grund können einfache und partielle Teilnehmer Informationen mit vollständigen Teilnehmern synchronisieren. Mindestens ein vollständiger Teilnehmer ist erforderlich, der Informationen speichern und den Synchronisierungsvorgang starten kann.

Microsoft Synchronization Framework

Hauptkomponenten

Vor der Implementierung einer Synchronisierung mithilfe von Microsoft Sync Framework ist es wichtig, die Hauptkomponenten eines Synchronisierungsanbieters zu verstehen. Diese Konzepte werden unten in diesem Dokument in den Synchronisierungsbeispielen genauer erläutert.

Das folgende Diagramm zeigt, wie ein Anbieter mit einer Datenquelle kommuniziert und Statusinformationen von einem Metadatenspeicher abruft. Diese Anbieter kommunizieren über eine Synchronisierungssitzung abwechselnd mit anderen Anbietern.

Datenquelle

In der Datenquelle werden alle zu synchronisierenden Informationen gespeichert. Eine Datenquelle kann eine relationale Datenbank, ein Dateisystem, ein Webdienst oder sogar eine benutzerdefinierte Datenquelle sein, die Teil einer Branchenanwendung ist. Solange Sie programmgesteuert auf die Daten zugreifen können, kann sie sich an der Synchronisierung beteiligen.

Metadaten

Eine grundlegende Eigenschaft eines Anbieters ist die Fähigkeit, Informationen zum Datenspeicher und zu den Objekten innerhalb des Datenspeichers hinsichtlich der Status- und Änderungsinformationen zu speichern. Metadaten können an einem beliebigen Ort gespeichert werden. Das kann eine Datei, eine Datenbank oder der vorhandene Datenspeicher des Replikats sein. Praktischerweise bietet Microsoft Sync Framework eine vollständige Implementierung eines in SQL Server Compact Edition erstellten Metadatenspeichers an. Dieser Speicher ist zwar nicht erforderlich, wenn Sie ihn jedoch verwenden, müssen Sie sich nicht mehr um die Speicherung von Synchronisierungsmetadaten kümmern.

Die Metadaten für einen Datenspeicher können in drei Hauptkomponenten aufgeteilt werden:

• Versionen: Ein kleiner Teil der Informationen wird für jedes synchronisierte Element gespeichert. Diese tragen die Bezeichnung Versionen. Diese Informationen zeichnen auf, wo und wann ein Element und die dem Element zugeordnete Element-ID geändert wurden. Im Fall einer Datenbank kann ein Element die ganze Zeile innerhalb einer Tabelle einnehmen. Alternativ kann ein Element eine Spalte innerhalb einer Tabellenzeile sein.

  Wenn ein Element geändert wird, enthalten die gespeicherten Informationen für diese Änderung eine Erstellungsversion und eine Updateversion. Diese Versionen bestehen aus zwei Komponenten: Ein Tickzähler ist eine in der ganzen Quelle verwendete logische Uhr, mit der eine Änderung eindeutig identifiziert werden kann, und eine Replikat-ID dient zur eindeutigen Identifizierung des Datenspeichers, der die Änderung durchgeführt hat. Die Erstellungssversion ist beim anfänglichen Erstellen des Elements mit der Updateversion identisch. In folgenden Updates des Elements ändert sich nur die Updateversion.

  Das Nachverfolgen von Änderung muss mindestens auf Elementebene stattfinden. Das heißt, dass jedes Element eine unabhängige Version besitzen muss. In einigen Situationen wäre eine präzisere Nachverfolgung wünschenswert, weil das Potenzial für Datenkonflikte herabgesetzt wäre (wenn beispielsweise zwei Benutzer das gleiche Element auf verschiedenen Replikaten aktualisieren). Der Nachteil besteht darin, dass der Umfang gespeicherter Informationen über nachzuverfolgende Änderungen erhöht wird.

  Es gibt zwei Hauptmethoden zum Implementieren der Versionskontrolle:

  1. Inlinenachverfolgung: Mit dieser Methode wird die Änderungsnachverfolgung von Informationen für ein Element aktualisiert, während die Änderung vorgenommen wird. Im Fall einer Datenbank kann zum Beispiel ein Trigger verwendet werden, um eine Änderungsnachverfolgungstabelle sofort nach der Aktualisierung einer Zeile zu aktualisieren.
  2. Asynchrone Nachverfolgung: Mit dieser Methode werden Änderungen über einen externen Prozess ausgeführt und gesucht. Alle ermittelten Updates werden den Versionsinformationen hinzugefügt. Dieser Prozess kann Teil eines geplanten Prozesses sein oder wird vor der Synchronisierung ausgeführt. Er wird normalerweise verwendet, wenn es beim Aktualisieren von Elementen keine internen Methoden zur automatischen Aktualisierung von Versionsinformation gibt (z. B. besteht keine Möglichkeit, Logik in die Updatepipeline einzufügen). Eine geläufige Methode des Suchens nach Änderungen besteht darin, den Status eines Elements zu speichern und ihn mit seinem aktuellen Status zu vergleichen. Zum Beispiel kann überprüft werden, ob seit der letzten Synchronisierung das Datum des letzten Schreibvorgangs oder die Dateigröße geändert wurde.

• Kenntnisse: Kenntnisse sind eine kompakte Darstellung der einem Replikat bekannten Datenänderungen. Mithilfe von Kenntnissen soll die Synchronisierung effizienter gestaltet werden, weil der Umfang der zwischen den Replikaten versendeten Informationen beschränkt wird. Während der Aktualisierung der Versionsinformationen werden Kenntnisse für den Datenspeicher aktualisiert. Anbieter verwenden Replikatkenntnisse zu folgenden Zwecken:

  1. Auflisten von Änderungen: Bestimmen, über welche Änderungen ein anderes Replikat keine Kenntnisse hat.
  2. Erkennen von Konflikten: Festlegen, welche Vorgänge ohne Kenntnis voneinander vorgenommen wurden.

• Tombstones: Jedes Replikat muss zudem Informationen zum Tombstone aller gelöschten Elemente speichern. Wenn gelöschte Elemente nicht nachverfolgt werden, weiß ein Anbieter nicht, ob ein Element (wie z. B. eine Datei) gelöscht wurde. Im diesem Fall könnte der Anbieter Änderungsversionsinformationen nicht an andere Anbieter weiterleiten. Ein Tombstone muss die folgenden Informationen enthalten:

  • **Globale ID:  **Replikat-ID und Tickzähler zur eindeutigen Identifizerung des Tombstoneelements in allen Replikaten.
  • Löschungsversion: Dem Tombstoneelement zugeordnete Updateversion
  • Erstellungsversion: Replikat-ID und Tickzähler, die dem Element bei der ursprünglichen Erstellung zugeordnet wurden

  Da die Informationen im Tombstoneprotokoll mit der Zeit wachsen, empfiehlt es sich, einen Prozess zum regelmäßigen Bereinigen dieses Speichers einzurichten. Das Bereinigen von Tombstonedaten spart Platz und kann die Synchronisierungsleistung verbessern. Microsoft Sync Framework enthält Unterstützung für die Verwaltung von Tombstoneinformationen.

Synchronisierungsfluss

Das Replikat, in dem die Synchronisierung initiiert wird, ist die Quelle und das Replikat, zu dem es eine Verbindung herstellt, das Ziel. Im weiteren Verlauf dieses Artikels wird der Synchronisierungsfluss besprochen, der im folgenden Diagramm dargestellt wird. Dieser Prozess wird bei der bidirektionalen Synchronisierung zweimal ausgeführt, wobei die Quelle und das Ziel bei der zweiten Iteration ausgetauscht werden.

Mit Ziel initiierte Synchronisierungssitzung

In dieser Phase wird eine Synchronisierungssitzung eingerichtet, die eine Verknüpfung zwischen der Quelle und dem Anbieter herstellt.

Ziel bereitet Kenntnisse vor und sendet sie

Wie oben besprochen, speichert jedes Replikat seine eigenen Kenntnisse. Die im Ziel gespeicherten Kenntnisse werden an die Quelle weitergegeben.

Verwendete Zielkenntnisse zur Bestimmung der zu sendenden Änderungen

Auf der Quellseite wurden die soeben empfangenen Kenntnisse mit den lokalen Elementversionen verglichen, um die Elemente zu bestimmen, von denen das Ziel keine Kenntnisse hat. Beachten Sie, dass es sich bei den versendeten Versionen nicht um die tatsächlichen Elemente, sondern um eine Zusammenfassung der letzten an jedem Element durchgeführten Änderungen handelt.

An das Ziel gesendete Änderungsversionen und Quellkenntnisse

Nachdem die Quelle die Liste der erforderlichen Änderungsversionen vorbereitet hat, werden sie an das Ziel transportiert.

Lokale Version wird für Änderungselemente abgerufen und mit der Quellversion und den Kenntnissen verglichen

Das Ziel verwendet die Versionen zur Vorbereitung einer Liste mit Elementen, die von der Quelle gesendet werden müssen. Das Ziel verwendet diese Informationen darüber hinaus zum Ermitteln von Einschränkungskonflikten. Bei Einschränkungskonflikten handelt es sich um Konflikte, die gegen Einschränkungen verstoßen, die Elementen auferlegt wurden. Dazu gehören die Beziehung von Ordnern oder der Speicherort für identisch bezeichnete Daten innerhalb eines Dateisystems.

Konflikte werden erkannt und aufgelöst oder zurückgestellt

Grundsätzlich kommt es zu einem Konflikt, wenn zwischen Synchronisierungen auf zwei unterschiedlichen Replikaten am gleichen Element eine Änderung durchgeführt wird. In Microsoft Sync Framework Runtime wird ein Konflikt erkannt, wenn die Änderungsversion in einem Replikat KEINE Kenntnisse über die Änderung am anderen Replikaten enthält. Ein ausführlicheres Beispiel für diese Erkennung befindet sich unten im Abschnitt „Konfliktbeispiel“.

Replikate können eine Vielzahl von Richtlinien für die Auflösung von Elementen implementieren, die sich in einer Synchronisierungstopologie im Konflikt befinden. Beispiele für häufige Auflösungsrichtlinien:

• Quelle gewinnt: Änderungen, die vom Quellreplikat vorgenommen werden, gewinnen immer, wenn ein Konflikt erkannt wird.
• Ziel gewinnt: Änderungen, die vom Zielreplikat vorgenommen werden, gewinnen immer.
• Zusammenführen: Die zwei Änderungen werden zusammengeführt. Bestandszahlen sind ein Beispiel dafür, die Werte aus zwei Replikaten zusammenzuführen (Summe), anstatt einen Wert als richtigen Wert auszuwählen.
• Protokollkonflikt: Konflikt protokollieren oder zurückstellen.

Ziel fordert von Quelle Elementdaten an

Während dieser Phase hat das Ziel die Elemente in der Quelle bestimmt, die abgerufen werden müssen, und teilt diese Anforderung der Quelle mit.

Quelle bereitet Elementdaten vor und sendet sie

Die Quelle nimmt die Elementdatenanforderung an und bereitet die Daten auf die Übertragung an das Ziel vor. Wenn das nachzuverfolgende Element eine Zeile in einer Datenbank ist, wird die Zeile gesendet. Wenn das Element eine Datei in einem Ordner ist, wird die Datei übertragen.

Elemente werden am Ziel angewendet

Die empfangenen Elemente werden entnommen und am Ziel angewendet. Wenn während dieses Prozesses Fehler auftreten, wie z. B. Netzwerkfehler, werden die Elemente als Ausnahmen gekennzeichnet und während der nächsten Synchronisierung korrigiert. Die von der Quelle empfangenen Kenntnisse werden der Zielkenntnis hinzugefügt.

Synchronisierungsbeispiel

Im Folgenden wird anhand des im vorherigen Abschnitt beschriebenen Synchronisierungsflusses ein Dateisynchronisierungsbeispiel durchlaufen, in dem die Auflistung von Änderungen in Microsoft Sync Framework gezeigt wird und schließlich Elementdaten angewendet werden. Dieses Beispiel enthält zwei Replikate: Replikat A und Replikat B. Replikat A initiiert die Synchronisierung mit Replikat B (folglich ist Replikat A die Quelle und Replikat B das Ziel). Angenommen, zwischen diesen beiden Replikaten sollen Dateien synchronisiert werden. Das nachzuverfolgende Element befindet sich in einer einzelnen Datei in einem Ordner und wird als I bezeichnet_n (z. B. I_1, I_2, I_3…). Wenn eine neue Datei (I₁) erstellt wird, müssen die der Datei zugeordneten Metadaten folgendermaßen aktualisiert werden:

Wenn die Datei erneut aktualisiert wird, könnte die Versionstabelle folgendermaßen aussehen:

Im vorangegangenen Beispiel wurde der Tickzähler für das Update auf 5 festgelegt, weil sich die logische Uhr für den Tickzähler auf die gesamte Quelle bezieht. Das bedeutet, dass Tickzähler von 2 bis 4 für Änderungen an anderen Elementen im Replikat verwendet wurden.

Im folgenden Diagramm können Sie beispielsweise erkennen, dass es im Replikat zwei zusätzliche nachverfolgte Elemente I₂ und I₃ gibt. Die Versionsinformationen werden folglich immer umfangreicher, wenn weitere Elemente erstellt werden. Microsoft Sync Framework muss keine vorherigen Updateversionen speichern. Nur die neueste Updateversion muss bekannt sein.

Wenn wir den aktuellen Status der Elemente für dieses Replikat verwenden, werden die Kenntnisse von Replikat A folgendermaßen dargestellt:

Replikat A Kenntnisse = A₅

Wie oben erwähnt, sind Kenntnisse eine kompakte Darstellung von Datenänderungen, die ein Replikat kennt. In diesem Fall ist A die diesem Replikat zugeordnete eindeutige ID, und 5 ist der aktuelle Tickzähler für die Änderungen, die dem Replikat bekannt sind. Wenn dieses Replikat mit anderen Replikaten synchronisiert wäre, würden diese Kenntnisse auch in der Liste angezeigt werden.

Auf Replikat B können sich auch mehrere Dateien befinden. Dieses Replikat sieht folgendermaßen aus:

Replikat B

Die aktuellen Kenntnisse für Replikat B sind:

Replikat B Kenntnisse = B₄

Jetzt wird die Synchronisierung zwischen den beiden Replikaten initiiert. Replikat A ist die Quelle (die die Synchronisierung initiiert), und Replikat B ist das Ziel.

Während der Synchronisierung sendet das Ziel der Quelle seine Kenntnisse. Wie oben erwähnt, bestehen folgende Kenntnisse für die beiden Replikate:

Replikat A Kenntnisse = A₅

Replikat B Kenntnisse = B₄

Die Quelle (Replikat A) erhält diese Kenntnisse und verwendet sie zur Bestimmung der Versionen, die an das Ziel gesendet werden sollen. Da Replikat B keines der Elemente in Replikat A kennt, wird der gesamte Inhalt gesendet. In diesem Fall enthält Replikat A die folgenden Versionen.

Änderungsbatch von Replikat A

Das Ziel empfängt diese Versionen und listet sie auf, um zu bestimmen, welche Elemente von der Quelle angefordert werden. Darüber hinaus werden diese Informationen zur Ermittlung möglicher Konflikte verwendet (falls beispielsweise die gleiche Datei auf beiden Replikaten aktualisiert wurde).

Danach fordert das Ziel die Quelle auf, die Elemente zu senden, die es nicht kennt. In diesem Fall sendet Replikat A die Dateien, die I zugeordnet sind_1, I₂ und  I_3.

Das Ziel empfängt diese Dateien und fügt sie seinem Ordner hinzu. Die Elemente von Replikat B enthalten jetzt Elemente, die von Replikat A empfangen wurden.

Replikat B – Aktualisierte Elementtabellen

Am Ende dieser Synchronisierung wird der Prozess noch ein weiteres Mal ausgeführt. Jetzt wird die Quelle zum Ziel und umgekehrt. Dadurch kann Replikat A alle Dateien empfangen, die auf Replikat B erstellt oder geändert wurden (I₁₀₄ und  I₁₀₅).

Am Ende der Synchronisierung besitzen beide Replikate die folgenden aktualisierten Kenntnisse.

Replikat A Kenntnisse = A_5, B₄

Replikat B Kenntnisse = A_5, B₄

Konfliktbeispiel

Wenn das vorherige Beispiel erweitert wird, sind die zwei Replikate derzeit „synchronisiert“, und jede Elementversion sieht folgendermaßen aus:

Analog dazu sehen die Kenntnisse für beide Replikate folgendermaßen aus:

Replikat A Kenntnisse = A_5, B₄

Replikat B Kenntnisse = A_5, B₄

Jetzt entscheiden beide Replikate, die gleiche Datei zu aktualisieren, (Element I_4).

Auf Replikat A wird die Elementversionstabelle folgendermaßen aktualisiert:

Auf Replikat B wurde die Elementversionstabelle folgendermaßen aktualisiert:

Die Kenntnisse für beide Replikate wurden auch folgendermaßen aktualisiert:

Replikat A Kenntnisse = A_6, B₄

Replikat B Kenntnisse = A_5, B₅

Jetzt initiiert Replikat A eine Synchronisierung mit Replikat B. Durch den Wechsel zur Phase, in der die Quelle die Elementversionen und Kenntnisse an das Ziel sendet, werden die folgenden Schritte für Element I durchgeführt:₂.

1. Replikat B erfährt eine neue Elementänderung für Element I,₂ und zwar die folgende:

   Update Tickzähler	Update Replikat-ID
   6	A

2. Replikat B überprüft die von Replikat A empfangenen Kenntnisse (A6, B4) und bestimmt, dass Replikat A keine Kenntnis einer Änderung hatte, die an dem gleichen Element von Replikat B vorgenommen wurde.

   Update Tickzähler	Update Replikat-ID
   5	B

3. Ein Konflikt wurde erkannt und an die Anwendung oder den Anbieter zur weiteren Behandlung übergeben.

Wie oben besprochen, kann die Anwendung die Art der Konfliktbehandlung wählen oder die Behandlung auf einen späteren Zeitpunkt verschieben. Wenn der Konflikt zurückgestellt wird, wird er solange während weiterer Synchronisierungen auftreten, bis er aufgelöst wird. Nach der Auflösung wird das ursprüngliche Replikat während der nächsten Synchronisierung den aktualisierten Wert erhalten.

Zusammenfassung

Microsoft Sync Framework enthält alle Funktionen, die mithilfe von zuvor erstellten oder neu geschriebenen, benutzerdefinierten Anbietern zum Integrieren von Anwendungen in ein Offline- oder auf Zusammenarbeit basiertes Netzwerk benötigt werden. Die Anbieter ermöglichen allen Datenquellen, unabhängig vom Netzwerk oder Gerätetyp, die Teilnahme an der Datensynchronisierung.

Dieses Dokument hatte die Hauptkomponenten von Microsoft Sync Framework zum Inhalt. Es wurden Beispiele gezeigt, die nachweisen, wie Kenntnisse innerhalb von Microsofts Sync Framework effizient verwendet werden, sodass alle Datenspeicher Informationen austauschen können. Darüber hinaus haben Sie erfahren, wie in Microsoft Sync Framework die Konflikterkennung funktioniert. Schließlich haben Sie Informationen über verschiedene Methoden erhalten, mit denen die Anwendung oder der Anbieter Konflikte effektiv auflösen kann.

Dieses Framework stellt die Grundlage für Synchronisierungen dar, die auf beliebige Geräte auf allen Datenspeichern in jeder Netzwerktopologie ausgedehnt werden kann. Sie können unterschiedliche Datenquellen einfach integrieren, um ein Peer-to-Peer-Netzwerk zu bilden und sogar Datenspeicher zu erweitern, wenn Schemaänderungen nicht möglich sind.

Microsoft Sync Framework stellt eine äußerst integrierbare und skalierbare Plattform für die Synchronisierung zur Verfügung.

Weitere Informationen oder eine Kopie von Microsoft Sync Framework CTP1 SDK erhalten Sie unter https://msdn2.microsoft.com/en-us/sync/default.aspx.