Grundlegendes zu benutzerdefinierten Anbietern

Microsoft Sync Framework enthält Anbieter für verschiedene Synchronisierungsszenarien wie z. B. Dateisynchronisierung. In einigen Fällen ist jedoch ein benutzerdefinierter Anbieter erforderlich. Für benutzerdefinierte Anbieter müssen Entwickler mehr Code schreiben als für die in Sync Framework enthaltenen Anbieter. Sie sind jedoch eine Schlüsselkomponente für die Flexibilität und Erweiterbarkeit von Sync Framework. Die Informationen in diesem Thema helfen Ihnen dabei, benutzerdefinierte Anbieter zu verstehen und zu entscheiden, welcher Typ von benutzerdefiniertem Anbieter für Ihre Anwendung geeignet ist. Wenn Sie mit Sync Framework noch nicht vertraut sind, sollten Sie auch den Abschnitt „Sync Framework-Komponenten“ unter Auswählen der geeigneten Sync Framework-Komponenten lesen.

Anbieter, Anwendungen und Metadatenverwaltung

Microsoft Sync Framework synchronisiert Replikate mithilfe von vier grundlegenden Komponenten: der Synchronisierungslaufzeit, einer Sychronisierungssitzung und zwei Synchronisierungsanbietern. Um Daten zu synchronisieren, erstellt eine Anwendung eine Synchronisierungssitzung und übergibt diese an einen Quellenanbieter und einen Zielanbieter. Die Sitzung verwendet den Quellenanbieter, um neue, im Quellreplikat vorgenommene Änderungen abzurufen, und den Zielanbieter, um diese Änderungen auf das Zielreplikat anzuwenden. Ein Anbieter verwaltet Metadaten, einschließlich Wissen, für jedes Replikat und zu synchronisierende Element. Als Wissen werden die Metadaten bezeichnet, mit denen alle an einem Replikat vorgenommenen Änderungen beschrieben werden, entweder direkt oder durch Synchronisierung.

Wenn Sync Framework keinen Anbieter für den zu synchronisierenden Datenspeicher bereitstellt, muss ein benutzerdefinierter Anbieter geschrieben werden. Sync Framework enthält verwaltete und nicht verwaltete APIs für zwei Typen benutzerdefinierter Anbieter: einfache benutzerdefinierte Anbieter und benutzerdefinierte Standardanbieter.

• Aufgrund einer kleineren Anzahl von Schnittstellen und der Einfachheit dieser Schnittstellen sorgen einfache Anbieter für eine kürzere Entwicklungszeit und eine intuitivere Unterstützung für Datenspeicher, denen erweiterte Mechanismen zur Änderungsnachverfolgung fehlen.

• Standardanbieter bieten die größte Flexibilität und den höchsten Grad an Leistung und Stabilität.

Beide Typen von Anbietern können verwendet werden, um eine Vielzahl von Datenspeichern zu synchronisieren, und beide bieten Optionen in wichtigen Bereichen wie Filterung und Konfliktbehandlung. Es gibt jedoch wichtige Unterschiede. Weitere Informationen finden Sie unter „Entscheiden zwischen einem einfachen Anbieter und einem Standardanbieter“ in diesem Thema.

In der folgenden Abbildung sind die Hauptelemente eines Synchronisierungsszenarios dargestellt. Die Abbildung ähnelt derjenigen unter Auswählen der geeigneten Sync Framework-Komponenten, der Begleittext bietet jedoch zusätzliche Informationen, die für benutzerdefinierte Anbieter relevant sind, und verdeutlicht den Fluss von Daten und Metadaten durch das System.

Es gibt drei Typen von Elementen in der Abbildung:

• Vom Entwickler geschriebene Elemente

  • Die Anwendung startet die Synchronisierung, reagiert auf Ereignisse und führt andere Aufgaben auf Grundlage von Anwendungsanforderungen aus. Weitere Informationen finden Sie unter Implementieren einer Synchronisierungsanwendung.

  • Der Anbieter verwaltet die Metadaten für ein Replikat und verwendet Sync Framework, um Änderungen aufzulisten und Konflikte zu ermitteln. Weiterhin arbeitet der Anbieter auch mit dem Datenspeicher eines Replikats, um Elementdaten zu senden, wenn der Anbieter als Quellenanbieter agiert, und um Änderungen anzuwenden, wenn der Anbieter als Zielanbieter agiert. Der Anbieter ist spezifisch für den synchronisierten Datentyp. Die beiden Anbieter in einer Sitzung weisen oft den gleichen Typ auf, dies ist jedoch nicht erforderlich. Weitere Informationen zur Interoperabilität finden Sie unter Integrieren von Daten von verschiedenen Anbietern.

    Verwalteter Code Ein einfacher Anbieter implementiert FullEnumerationSimpleSyncProvider oder AnchorEnumerationSimpleSyncProvider. Ein Standardanbieter implementiert KnowledgeSyncProvider, IChangeDataRetriever und INotifyingChangeApplierTarget.

    Nicht verwalteter Code Ein einfacher Anbieter implementiert IFullEnumerationSyncProvider oder IAnchorSyncProvider. Ein Standardanbieter implementiert IKnowledgeSyncProvider, ISyncProvider, ISynchronousDataRetriever und ISynchronousNotifyingChangeApplierTarget (bzw. die asynchronen Versionen für asynchrone Anbieter).

  • Bei dem Datenspeicher handelt es sich um einen beliebigen Speicher, für den Sie einen Anbieter schreiben.

  • Das Datenübertragungsprotokoll legt fest, wie Datenänderungen zwischen zwei Anbietern übertragen werden.

• Elemente, die von Sync Framework bereitgestellt werden.

  • Abhängig davon, ob verwalteter oder nicht verwalteter Code verwendet wird, kommuniziert die Anwendung mit einem Synchronisierungsorchestrator (SyncOrchestrator) oder einer Synchronisierungssitzung (ISyncSession), die dann wiederum mit jedem Synchronisierungsanbieter kommuniziert, den Synchronisierungsvorgang steuert sowie über Status, Konflikte und Fehler der Clientanwendung benachrichtigt.

  • Die Synchronisierungslaufzeit unterstützt die Anbieter dabei, allgemeine Synchronisierungsaufgaben auszuführen, wie z. B. Metadatenverwaltung, Konflikterkennung und Änderungsübernahme.

• Elemente, die je nach Anbieter- und Anwendungsanforderungen vom Entwickler geschrieben oder von Sync Framework bereitgestellt werden

  • Der Metadatenspeicher enthält die Metadaten, mit denen Sync Framework ermittelt, aus welchen Änderungen ein Anbieter auswählen soll und welche Änderungen im entsprechenden Datenspeicher übernommen werden. Der Metadatenspeicher kann vom Datenspeicher getrennt (z. B. eine separate Datei oder Datenbank) oder in den Speicher integriert sein (z. B. eine zusätzliche Tabelle in eine Datenbank). Der Synchronisierungsanbieter verwaltet in der Regel die Metadaten, die für die Synchronisierung erforderlich sind. Abhängig von der Implementierung des Replikats kann es jedoch für einige Bereiche der Metadatenverwaltung sinnvoller sein, wenn sie von einer getrennten Komponente behandelt werden, wie zum Beispiel von einem Dienst, der alte Metadaten zu geplanten Zeiten anstatt bei der Synchronisierung bereinigt. Die erforderlichen Metadaten und die Art ihrer Speicherung und Verarbeitung ist vom verwendeten Anbieter abhängig. Informationen zu den Metadatenanforderungen für jeden Anbietertyp finden Sie unter Verwalten von Metadaten für einfache Anbieter und Metadatenanforderungen für Standardanbieter.

    Ein einfacher Anbieter reduziert die Interaktion des Entwicklers mit dem Metadatenspeicher auf ein Mindestmaß. Der Anbieter verwendet eine Implementierung des in Sync Framework enthaltenen Metadaten-Speicherdiensts. Benutzerdefinierte Standardanbieter können diese Implementierung oder eine andere Implementierung auf Grundlage der Metadaten-Speicherdienst-API verwenden. Eine weitere Möglichkeit ist eine vollständig benutzerdefinierte Implementierung, bei der Metadaten in einem separaten Speicher oder innerhalb des Datenspeichers gespeichert werden. Weitere Informationen finden Sie unter Verwalten von Metadaten für Standardanbieter.

Entscheiden zwischen einem einfachen Anbieter und einem Standardanbieter

In den meisten Fällen empfiehlt es sich, einen einfachen Anbieter zu verwenden. Sie sollten jedoch zuerst die Voraussetzungen prüfen, von denen beim Entwurf der API für einfache Anbieter ausgegangen wurde:

• Die zu synchronisierenden Datenspeicher unterstützen keine Änderungsnachverfolgung oder nur die ankerbasierte Änderungsnachverfolgung.

  Ein Anker ist ein Objekt, das angibt, welche Elemente in einem Datenspeicher seit der letzten Synchronisierungssitzung geändert wurden. Bei Speichern, die keine oder nur eine ankerbasierte Änderungsnachverfolgung aufweisen, erfolgen Aktualisierungen des Synchronisierungswissens während der Synchronisierungssitzung (asynchron) anstatt zum Zeitpunkt der Änderung im Speicher (synchron). Dies kann die Leistung beeinträchtigen, wenn viele Synchronisierungssitzungen gleichzeitig auf einem bestimmten Replikat stattfinden. Wenn daher eine Anwendung hohe Parallelität erfordert und jeder Datenspeicher synchrone Aktualisierungen des Synchronisierungswissen unterstützt, sollten Sie einen Standardanbieter verwenden.

• Für das Replikat muss nur ein Elementtyp synchronisiert werden.

• Aufgrund von Datenspeichereinschränkungen oder Anwendungsanforderungen müssen Metadaten außerhalb des Datenspeichers gespeichert werden.

  Einfache Anbieter speichern Metadaten mithilfe der Implementierung des in Sync Framework enthaltenen Metadaten-Speicherdiensts. Metadaten werden getrennt von den Daten gespeichert, die sie beschreiben, wodurch zwei potenzielle Probleme entstehen:

  • Wenn die Metadaten remote gespeichert werden, sind sie während einer Synchronisierungssitzung möglicherweise nicht verfügbar. Beispiel: Die Netzwerkverbindung zwischen den beiden zu synchronisierenden Replikaten ist verfügbar, die Verbindung mit dem Metadatenserver jedoch nicht.

  • Die Transaktionskonsistenz zwischen Daten und Metadaten ist nicht sichergestellt. Das Speichern der Metadaten auf demselben Computer wie die Daten wird empfohlen. Transaktionsunterstützung ist jedoch nur verfügbar, wenn ein Standardanbieter verwendet wird und die Metadaten im Datenspeicher gespeichert werden (oder eine verteilte Transaktion zum Aktualisieren beider Speicher verwendet wird). Beachten Sie, dass Standardanbieter ebenfalls den Metadaten-Speicherdienst verwenden können. Dies ist jedoch nicht Voraussetzung wie bei einfachen Anbietern.

Wenn diese Annahmen den Anwendungsanforderungen entsprechen, sollte ein einfacher Anbieter verwendet werden. Weitere Informationen zu einfachen Anbietern finden Sie unter Implementieren eines benutzerdefinierten einfachen Anbieters. Weitere Informationen zu Standardanbietern finden Sie unter Implementieren eines benutzerdefinierten Standardanbieters.

Sync Framework-Teilnehmertypen

Sync Framework kann zum Synchronisieren von Daten zwischen Teilnehmern unterschiedlicher Funktionalität verwendet werden. Ein Teilnehmer ist ein Gerät oder ein Dienst, der mit anderen Systemen synchronisieren kann, die Sync Framework ausführen.

Sync Framework unterstützt die folgenden Teilnehmertypen:

• Vollständiger Teilnehmer

• Proxyteilnehmer

• Partieller Teilnehmer

• Einfacher Teilnehmer

Vollständiger Teilnehmer

Ein vollständiger Teilnehmer hostet die Laufzeit lokal und speichert Metadaten. Vollständige Teilnehmer können an Peer-to-Peer-Synchronisierungsszenarien teilnehmen, da beide Teilnehmer die Synchronisierung starten können.

Zwei vollständige Teilnehmer bei der Peer-to-Peer-Synchronisierung

Partieller Teilnehmer

Ein partieller Teilnehmer kann Synchronisierungsmetadaten speichern, jedoch nicht verarbeiten. Ein partieller Teilnehmer verlässt sich darauf, dass mehrere vollständige Teilnehmer die Laufzeit hosten und die Synchronisierung starten. Die Daten können über diese Teilnehmer übertragen werden, da sie die Multimaster-Synchronisierungsmetadaten speichern und diese Metadaten an jeden anderen vollständigen Teilnehmer weitergeben können. Partielle Teilnehmer können an Peer-to-Peer-Szenarien nicht beteiligt sein, da sie die Metadaten nicht verarbeiten und die Laufzeit nicht hosten können. Einige Beispiele partieller Teilnehmer sind Laufwerke in Form von USB-Memory Sticks und Mobiltelefone, die über Datenspeicherfunktionen verfügen.

Die folgende Abbildung zeigt, wie ein vollständiger Teilnehmer, wie z. B. ein Computer, mit einem partiellen Teilnehmer, wie beispielsweise einem Mobiltelefon, synchronisiert wird. Der vollständige Teilnehmer listet die Änderungen auf der Seite des partiellen Telnehmers auf oder filtert diese und speichert die Metadaten auf dem partiellen Teilnehmer. Dies ermöglicht es jedem beliebigen anderen vollständigen Teilnehmer, diesen partiellen Teilnehmer zu synchronisieren.

Vollständiger Teilnehmer, der mit einem partiellen Teilnehmer synchronisiert

Einfacher Teilnehmer

Ein einfacher Teilnehmer speichert keine Metadaten, kann die Laufzeit nicht hosten und verfügt möglicherweise auch nicht über eine Änderungsnachverfolgungsfunktion. Stattdessen verlässt sich ein einfacher Teilnehmer darauf, dass ein vollständiger Teilnehmer alle Aufgaben hinsichtlich der Auflistung von Änderungen, der Übernahme von Änderungen sowie der Bearbeitung und Speicherung der Metadaten übernimmt. Da ein einfacher Teilnehmer nicht in der Lage ist, Metadaten zu speichern, kann er nur als Blattknoten in einer "Partnerschaft" mit einem vollständigen Teilnehmer fungieren, der Daten von und zu anderen Teilnehmern überträgt.

Die folgende Abbildung zeigt einen vollständigen Teilnehmer, der zum Speichern der Metadaten für einen einfachen Teilnehmer den Metadaten-Speicherdienst verwendet und alle Synchronisierungsaufgaben für den einfachen Teilnehmer ausführt. Der Metadatenspeicher wird zur Nachverfolgung von Änderungen bezüglich des einfachen Teilnehmers verwendet, wird jedoch aufgrund der Speichereinschränkungen des einfachen Teilnehmers auf dem vollständigen Teilnehmer gespeichert.

Vollständiger Teilnehmer, der den Metadaten-Speicherdienst verwendet, um einen einfachen Teilnehmer zu synchronisieren

Proxyteilnehmer

Ein Proxyteilnehmer startet die Synchronisierung für einen Remoteanbieter, indem er Aufrufe lokal behandelt und an den Remoteanbieter, wie eine Datenbank, die auf einem Server gespeichert ist, weiterleitet.

Sicherheit Hinweis
Sync Framework stellt keine Authentifizierung oder Verschlüsselung zwischen Proxy- und Remoteanbieter zur Verfügung. Um nicht autorisierten Zugriff und Manipulationen zu vermeiden, muss der Kommunikationskanal zwischen Proxy- und Remoteanbieter mit einem geeigneten gegenseitigen Authentifizierungs- und Verschlüsselungsmechanismus wie beispielsweise SSL (Secure Sockets Layer) gesichert werden.

Die folgende Abbildung zeigt einen vollständigen Teilnehmeranbieter, der mit einem Proxyanbieter synchronisiert. Beachten Sie, dass der Proxyanbieter nur Befehle und Metadaten über das Netzwerk an den Remoteanbieter sendet. Der Remoteanbieter befindet sich auf dem Datenbankserver und implementiert die aktuelle Logik, die für die Synchronisierung verwendet wird. Die gestrichelte rote Linie stellt eine Computerbegrenzung dar.

Vollständiger Teilnehmer, der mit einem Proxyteilnehmer synchronisiert

Die folgende Abbildung zeigt, wie Sync Framework zum Synchronisieren von Anbietern verwendet werden kann, die für die Anwendung, die die Synchronisierung startet, als Remoteanbieter gelten. Die steuernde Anwendung könnte eine Verbindung zwischen zwei Internetdiensten oder intelligenten Geräten herstellen, die synchronisiert werden müssen. Beachten Sie, dass beide lokalen Anbieter für die Remoteanbieter Proxyanbieter sind. Die gestrichelten roten Linien stellen Computerbegrenzungen dar.

Zentrale Anwendung, die zwei Proxyteilnehmer synchronisiert

Siehe auch

Konzepte

Auswählen der geeigneten Sync Framework-Komponenten
Implementieren eines benutzerdefinierten einfachen Anbieters
Implementieren eines benutzerdefinierten Standardanbieters
Implementieren einer Synchronisierungsanwendung
Sync Framework-Beispiele