Architektur und Klassen für die Client- und Serversynchronisierung

Sync Framework ermöglicht die Synchronisierung zwischen einer SQL Server Compact-Clientdatenbank und einer Serverdatenbank bzw. einer beliebigen anderen Datenquelle, z. B. einem Dienst, der Aktienkurse in XML bereitstellt. Für die Synchronisierung zweier Datenbanken unterstützt Sync Framework 2-Ebenen- und n-Ebenen-Architekturen, die eine beliebige Serverdatenbank verwenden, für die ein ADO.NET-Anbieter verfügbar ist. Für die Synchronisierung zwischen einer Clientdatenbank und anderen Typen von Datenquellen unterstützt Sync Framework eine dienstbasierte Architektur. Diese Architektur erfordert mehr Anwendungscode als 2-Ebenen- und n-Ebenen-Architekturen, aber der Entwickler muss keine andere Herangehensweise an die Synchronisierung verfolgen.

Die folgenden Abbildungen zeigen die Komponenten, die in 2-Ebenen-, n-Ebenen- und dienstbasierten Architekturen beteiligt sind. Jede Abbildung zeigt einen einzelnen Client. Häufig sind jedoch mehrere Clients vorhanden, die mit einem einzelnen Server synchronisiert werden. Sync Framework verwendet ein Hub-and-Spoke-Modell für Client- und Server-Datenbanksynchronisierung. Die Synchronisierung wird immer vom Client initiiert. Zunächst werden alle Änderungen von allen Clients mit dem Server synchronisiert, bevor die Änderungen vom Server auf die anderen Clients übertragen werden. (Die Clients tauschen ihre Änderungen nicht direkt miteinander aus.)

Sync Framework ermöglicht Momentaufnahmen-, Nur-Download-, Nur-Upload- und bidirektionale Synchronisierungen für Client- und Serverszenarien:

• Momentaufnahmen- und Nur-Download-Synchronisierungen werden in der Regel zum Speichern und Aktualisieren von Referenzdaten, wie z. B. Produktlisten, auf einem Client verwendet. Datenänderungen, die auf dem Server vorgenommen werden, werden beim Synchronisieren in die Clientdatenbank heruntergeladen. Bei Momentaufnahmensynchronisierungen werden die Daten jedes Mal, wenn der Client eine Synchronisierung vornimmt, vollständig erneuert. Diese Vorgehensweise bietet sich an, wenn Sie keine inkrementellen Änderungen nachverfolgen möchten oder der Server dazu nicht in der Lage ist. Bei Nur-Download-Synchronisierungen werden nur die inkrementellen Änderungen heruntergeladen, die seit der letzten Synchronisierung erfolgt sind.

• Nur-Upload-Synchronisierungen werden in der Regel zum Einfügen von Daten, z. B. von Aufträgen, auf einem Client verwendet. Einfügungen und andere Datenänderungen, die in der Clientdatenbank vorgenommen werden, werden beim Synchronisieren auf den Server hochgeladen.

• Bidirektionale Synchronisierungen werden in der Regel für Daten verwendet, die auf dem Client und auf dem Server aktualisiert werden können, wie z. B. Kundenkontaktinformationen. Bei der Synchronisierung müssen alle sich widersprechenden Änderungen behandelt werden.

Weitere Informationen zu den verschiedenen Synchronisierungsarten finden Sie unter Vorgehensweise: Angeben der Synchronisierungsart (Momentaufnahmen-, Nur-Download-, Nur-Upload- oder bidirektionale Synchronisierung). Die Sync Framework-Architektur für die Client- und Serversynchronisierungen ist asymmetrisch, d. h., dass die Änderungsnachverfolgung zwar in die Clientdatenbank integriert ist, dass Sie aber die Änderungen im Serverdatenspeicher nachverfolgen müssen, wenn inkrementelle Änderungen heruntergeladen werden sollen. Weitere Informationen zur Änderungsnachverfolgung finden Sie unter Änderungsnachverfolgung in der Serverdatenbank.

Komponenten in den Architekturabbildungen

Die Komponenten in den Architekturabbildungen enthalten die Client- und die Serverdatenbank sowie Klassen aus der Datenbanksynchronisierungs-API von Sync Framework. Die n-Ebenen- und dienstbasierten Architekturen enthalten darüber hinaus auch Proxy-, Internetdienst- und Transportkomponenten, die von Ihnen geschrieben werden müssen.

2-Ebenen-Architektur

Die erste Abbildung zeigt eine 2-Ebenen-Architektur mit einer Clientdatenbank und einer Serverdatenbank.

Außer den zwei Datenbanken gibt es für alle Elemente in der Abbildung entsprechende Sync Framework-Klassen. Diese Klassen sind in den folgenden DLLs enthalten:

• Microsoft.Synchronization.Data.dll enthält den Synchronisierungs-Agent, Synchronisierungstabellen und Synchronisierungsgruppen.

• Microsoft. Synchronization.Data.SqlServerCe.dll enthält den Clientsynchronisierungsanbieter.

• Microsoft. Synchronization.Data.Server.dll enthält den Serversynchronisierungsanbieter und den Synchronisierungsadapter.

Alle DLLs benötigen System.dll und System.Data.dll aus .NET Framework 2.0 oder höheren Versionen. Microsoft.Synchronization.Data.SqlServerCe.dll benötigt darüber hinaus auch System.Data.SqlServerCe.dll aus SQL Server Compact. Bei 2-Ebenen-Anwendungen befinden sich alle Sync Framework-DLLs auf dem Client. Bei n-Ebenen-Anwendungen befinden sich Microsoft.Synchronization.Data.dll und Microsoft.Synchronization.Data.Server.dll auf einem separaten Computer, der einen Synchronisierungsdienst bereitstellt.

n-Ebenen-Architektur

Die zweite Abbildung zeigt eine n-Ebenen-Architektur. Eine solche Architektur benötigt einen Proxy-, einen Dienst- und einen Transportmechanismus, um die Kommunikation zwischen der Clientdatenbank und der Serverdatenbank zu ermöglichen. n-Ebenen-Architekturen werden häufiger verwendet als 2-Ebenen-Architekturen, da bei ihnen keine direkte Verbindung zwischen der Client- und der Serverdatenbank erforderlich ist.

Dienstbasierte Architektur

Die dritte Abbildung zeigt eine dienstbasierte Architektur. Diese Architektur enthält eine Clientdatenbank, aber keine Serverdatenbank und auch keinen entsprechenden Serversynchronisierungsanbieter und keine Synchronisierungsadapter. Bei einer solchen Architektur muss die Anwendung über einen benutzerdefinierten Proxy und einen benutzerdefinierten Dienst mit dem Synchronisierungs-Agent kommunizieren können. Der Proxy und der Dienst müssen dieselbe Funktionalität bieten, die normalerweise vom Serversynchronisierungsanbieter und von den Synchronisierungsadaptern bereitgestellt wird. So müssen sie z. B. die zu synchronisierenden Änderungen abrufen können.

Clientdatenbank

Die Clientdatenbank für Sync Framework-Anwendungen ist SQL Server Compact 3.5 SP1 SP1 oder höhere Versionen, einschließlich der 64-Bit-Version von SQL Server Compact. Sync Framework stellt eine Infrastruktur zur Nachverfolgung inkrementeller Änderungen in der Clientdatenbank bereit. Diese Infrastruktur wird aktiviert, wenn zum ersten Mal eine Tabelle mit einer anderen Methode als der Momentaufnahmensynchronisierung synchronisiert wird. Standardmäßig werden die Metadaten, die für Sync Framework erforderlich sind, zehn Tage lang in der Clientdatenbank gespeichert. Weitere Informationen zur Beibehaltung von Metadaten finden Sie unter RetentionInDays.

Serverdatenbank

Als Serverdatenbank kann jede beliebige Datenbank verwendet werden, für die ein ADO.NET-Anbieter verfügbar ist. Wenn Sie in der Serverdatenbank inkrementelle Änderungen nachverfolgen möchten, müssen Sie die Datenbank dafür vorbereiten. Weitere Informationen finden Sie unter Änderungsnachverfolgung in der Serverdatenbank.

Sync Framework-Klassen

Die folgenden Klassen sind in der vorherigen Abbildung dargestellt: SyncAgent, SqlCeClientSyncProvider, DbServerSyncProvider, SyncTable, SyncGroup und SyncAdapter. Ein Beispiel für die Verwendung dieser Klassen in einer Anwendung finden Sie unter Erste Schritte: Client- und Serversynchronisierung.

Synchronisierungs-Agent

Der Synchronisierungs-Agent sorgt auf folgende Weise für die Synchronisierung:

• Er durchläuft jede der zu synchronisierenden Tabellen in einer Schleife.

• Er ruft den Clientsynchronisierungsanbieter auf, um Änderungen abzurufen und auf die Clientdatenbank anzuwenden.

• Er ruft den Serversynchronisierungsanbieter auf, um Änderungen abzurufen und auf die Serverdatenbank anzuwenden.

Der Synchronisierungs-Agent bewahrt auch sitzungsspezifische Informationen für die Synchronisierung auf und stellt der Anwendung auf dem Client Erfolgsmeldungen, Fehler und Statistiken bereit. Weitere Informationen finden Sie unter SyncAgent und Vorgehensweise: Angeben der Synchronisierungsart (Momentaufnahmen-, Nur-Download-, Nur-Upload- oder bidirektionale Synchronisierung).

Clientsynchronisierungsanbieter

Der Clientsynchronisierungsanbieter kommuniziert mit dem Client und schirmt den Synchronisierungs-Agent vor der spezifischen Implementierung der Clientdatenbank ab. Sync Framework enthält einen Anbieter für die SQL Server Compact-Datenbank. Der Clientsynchronisierungsanbieter hat hauptsächlich die folgenden Aufgaben:

• Speichern von Informationen zu Tabellen auf dem Client, die für die Synchronisierung aktiviert sind

• Abrufen von Änderungen, die seit der letzten Synchronisierung in der Clientdatenbank vorgenommen wurden

• Anwenden inkrementeller Änderungen für die Clientdatenbank

• Erkennen sich widersprechender Änderungen

Weitere Informationen finden Sie unter SqlCeClientSyncProvider und Vorgehensweise: Angeben der Synchronisierungsart (Momentaufnahmen-, Nur-Download-, Nur-Upload- oder bidirektionale Synchronisierung).

Serversynchronisierungsanbieter

Der Serversynchronisierungsanbieter kommuniziert mit dem Server und schirmt den Synchronisierungs-Agent von der spezifischen Implementierung der Serverdatenbank ab. Er hat hauptsächlich die folgenden Aufgaben:

• Speichern von Informationen zu Tabellen auf dem Server, die für die Synchronisierung aktiviert sind

• Befähigen von Anwendungen, Änderungen abzurufen, die seit der letzten Synchronisierung in der Serverdatenbank vorgenommen wurden

• Anwenden inkrementeller Änderungen für die Serverdatenbank

• Erkennen sich widersprechender Änderungen

Weitere Informationen finden Sie unter DbServerSyncProvider und Vorgehensweise: Angeben der Synchronisierungsart (Momentaufnahmen-, Nur-Download-, Nur-Upload- oder bidirektionale Synchronisierung).

Synchronisierungstabelle und Synchronisierungsgruppe

Für jede Tabelle, die synchronisiert wird, wird eine Synchronisierungstabelle definiert. Sie dient zum Speichern von Einstellungen, wie z. B. der Synchronisierungsrichtung. Jeder Client kann nur die Tabellen anfordern, die er benötigt. Unter Umständen werden so nicht alle Tabellen angefordert, die der Serversynchronisierungsanbieter verfügbar macht. So wäre z. B. ein Fall mit 20 Tabellen denkbar, von denen 10 Tabellen im Serversynchronisierungsanbieter für die bidirektionale Synchronisierung konfiguriert sind. Ein Client könnte dann nur 12 der Tabellen für Nur-Download-Synchronisierungen anfordern. Auch wenn der Server Hochladevorgänge unterstützt, muss der Client keine Änderungen vornehmen, und er muss auch nicht alle Tabellen synchronisieren. Weitere Informationen finden Sie unter SyncTable.

Nachdem eine Synchronisierungstabelle definiert ist, kann sie einer Synchronisierungsgruppe hinzugefügt werden. Eine Synchronisierungsgruppe ist ein Mechanismus, mit dem sichergestellt wird, dass Änderungen auf einen Satz Tabellen konsistent angewendet werden. Wenn Tabellen in eine Synchronisierungsgruppe aufgenommen werden, werden Änderungen an diesen Tabellen als Einheit übertragen und in einer Einzeltransaktion auf den Server angewendet. Schlägt eine Änderung in der Gruppe fehl, werden die Änderungen für die gesamte Gruppe bei der nächsten Synchronisierung erneut übertragen. Weitere Informationen finden Sie unter SyncGroup und Vorgehensweise: Angeben der Synchronisierungsart (Momentaufnahmen-, Nur-Download-, Nur-Upload- oder bidirektionale Synchronisierung).

Synchronisierungsadapter

Der Synchronisierungsadapter, der nach dem Vorbild des Datenadapters in ADO.NET entwickelt wurde, wird für jede zu synchronisierende Tabelle definiert. Er stellt dem Serversynchronisierungsanbieter die spezifischen Befehle bereit, die für die Interaktion mit der Serverdatenbank erforderlich sind. Dazu gehört z. B. der InsertCommand, der Einfügungen aus der Clientdatenbank für die Serverdatenbank übernimmt. Da die Synchronisierungsadapter das ADO.NET-DbCommand-Objekt verwenden, können Sie jede von ADO.NET unterstützte Befehlsstruktur verwenden. Dies umfasst Inline-Transact-SQL, gespeicherte Prozeduren, Ansichten, Funktionen usw. Die Befehle benötigen lediglich ein einziges Ergebnis, das die Struktur und die zu übertragenden und anzuwendenden Daten definiert. Weitere Informationen finden Sie unter SyncAdapter und Vorgehensweise: Angeben der Synchronisierungsart (Momentaufnahmen-, Nur-Download-, Nur-Upload- oder bidirektionale Synchronisierung).

Proxy, Dienst und Transport

Proxy, Dienst und Transport werden in n-Ebenen- und dienstbasierten Architekturen verwendet. In n-Ebenen-Anwendungen wird Microsoft.Synchronization.Data.Server.dll verwendet, ohne dazu auf dem Client zu residieren. Die DLL residiert in der Regel auf einer mittleren Ebene, die über eine direkte Verbindung mit der Serverdatenbank verfügt. In diesem Fall sind ein Proxy und ein Dienst für die Kommunikation zwischen dem Client und der mittleren Ebene erforderlich:

• Auf dem Client verweist der Anwendungscode nicht direkt auf den Anbieter, sondern auf einen Proxy für den Serversynchronisierungsanbieter (ServerSyncProviderProxy). Der Proxy kommuniziert mit einem Dienst auf der mittleren Ebene.

• Auf der mittleren Ebene erbt der Dienst dieselben Methoden wie ServerSyncProvider (die abstrakte Klasse, von der DbServerSyncProvider erbt) und macht diese auch verfügbar. Die Methoden des Serversynchronisierungsanbieters werden dann über eine direkte Verbindung mit der Serverdatenbank ausgeführt. Die Ergebnisse werden über die mittlere Ebene weitergeleitet und an den Client zurückgegeben.

Weitere Informationen finden Sie unter Vorgehensweise: Konfigurieren der n-Ebenen-Synchronisierung.

In dienstbasierten Anwendungen wird auf dem Client nicht auf Microsoft.Synchronization.Data.Server.dll zurückgegriffen. Der Anwendungscode muss dieselbe Funktionalität bieten, die normalerweise vom Serversynchronisierungsanbieter und von den Synchronisierungsadaptern bereitgestellt wird.

• Der Anwendungscode auf dem Client verweist auf einen Proxy für den Anwendungscode, der sich um Serversynchronisierungsanbieter-Aufgaben kümmert, wie z. B. das Abrufen von Änderungen aus der Datenquelle. Der Proxy kommuniziert mit einem Dienst auf der mittleren Ebene.

• Auf der mittleren Ebene erbt der Dienst dieselben Methoden wie ServerSyncProvider (die abstrakte Klasse, von der DbServerSyncProvider erbt) und macht diese auch verfügbar. Der Anwendungscode führt dann die Methoden über eine direkte Verbindung mit der Serverdatenbank aus. Die Ergebnisse werden über die mittlere Ebene weitergeleitet und an den Client zurückgegeben.

Zusätzliche Klassen in der API

In den Abbildungen in diesem Thema sind die Hauptklassen in der API dargestellt. Zusätzlich zu den dargestellten Klassen gibt es aber noch viele weitere Klassen. Informationen zu allen verfügbaren Klassen finden Sie unter Microsoft.Synchronization, Microsoft.Synchronization.Data, Microsoft.Synchronization.Data.SqlServerCe und Microsoft.Synchronization.Data.Server. Die folgenden Abschnitte enthalten eine Einführung in vier andere wichtigen Klassen, mit denen Sie sich vertraut machen sollten.

Synchronisierungsanker

Ein Synchronisierungsanker ist ein Referenzzeitpunkt für einen Satz von Tabellen, die vom Server aus synchronisiert werden. Synchronisierungsanker ermöglichen es einer Anwendung zu bestimmen, welche Änderungen während einer konkreten Sitzung synchronisiert werden sollen. Bei der Synchronisierung speichert der Clientsynchronisierungsanbieter die folgenden Bezugspunkte in der Clientdatenbank:

• Zuletzt empfangener Anker
  Identifiziert die letzte Änderung, die vom Server heruntergeladen wurde.

• Zuletzt gesendeter Anker
  Identifiziert die letzte Änderung, die vom Client hochgeladen wurde.

Bei der nächsten Synchronisierung können diese Anker von der Anwendung verwendet werden, um den Ausgangspunkt für das Synchronisieren des nächsten Satzes von Änderungen zu bestimmen. Weitere Informationen finden Sie unter SyncAnchor und Änderungsnachverfolgung in der Serverdatenbank.

Synchronisierungssitzungsstatistik

Die Sitzungsstatistik enthält statistische Angaben, die vom Synchronisierungs-Agent für jede Synchronisierungssitzung bereitgestellt werden. Die Statistik enthält Angaben zu den Synchronisierungszeiten, zur Anzahl der verarbeiteten Änderungen und zu aufgetretenen Konflikten oder Ausnahmen. Weitere Informationen finden Sie unter SyncStatistics und Vorgehensweise: Arbeiten mit Ereignissen und Programmgeschäftslogik.

Synchronisierungssitzungsvariablen

Die Sitzungsvariablen sind Variablen, die dem Entwickler zur Verwendung als Parameter für die auf dem Server ausgeführten Auswahl-, Einfüge-, Aktualisierungs- und Löschbefehle bereitgestellt werden. Die Variablen können auf unterschiedliche Weise verwendet werden, wie z. B. zur Unterstützung für die Konflikterkennung oder um zu verhindern, dass Änderungen mehr als einmal auf den Client heruntergeladen werden. Weitere Informationen finden Sie unter SyncSession und Vorgehensweise: Verwenden von Sitzungsvariablen.

SQL-Server-Synchronisierungsadapter-Generator

Der nach dem Vorbild des Befehlsgenerators in ADO.NET entwickelte Synchronisierungsadapter-Generator hilft Ihnen, Code für die Synchronisierungsbefehle zu entwickeln, die vom Serversynchronisierungsanbieter ausgeführt werden. Der Synchronisierungsadapter-Generator erzeugt SELECT-, INSERT-, UPDATE-, und DELETE-Anweisungen für SQL Server-Datenbanken. Diese Anweisungen basieren auf von Ihnen bereitgestellten Informationen über die an der Synchronisierung beteiligten Tabellen. Weitere Informationen finden Sie unter SqlSyncAdapterBuilder und Tools zum Entwickeln von Anwendungen.

Siehe auch

Konzepte

Offlineszenarien
Erste Schritte: Client- und Serversynchronisierung