Architecture and Classes for Client and Server Synchronization
注意
The following information is included as reference for existing applications that support offline scenarios only. For developing new applications, please see Architecture and Classes for Database Synchronization.
Sync Framework enables synchronization between a SQL Server Compact client database and a server database or any other data source, such as a service that provides stock quotes in XML. For synchronizing two databases, Sync Framework supports two-tier and N-tier architectures that use any server database for which an ADO.NET provider is available. For synchronizing between a client database and other types of data sources, Sync Framework supports a service-based architecture. This architecture requires more application code than two-tier and N-tier architectures; however, it does not require a developer to take a different approach to synchronization.
The following illustrations show the components that are involved in two-tier, N-tier, and service-based architectures. Each illustration shows a single client, but there are frequently multiple clients that synchronize with a single server. Sync Framework uses a hub-and-spoke model for client and server database synchronization. Synchronization is always initiated by the client. All changes from each client are synchronized with the server before the changes are sent from the server to other clients. (These are clients that do not exchange changes directly with one another.)
Sync Framework provides snapshot, download-only, upload-only, and bidirectional synchronization for client and server scenarios:
Snapshot and download-only synchronization are typically used to store and update reference data, such as a product list, on a client. Data changes that are made at the server are downloaded to the client database during synchronization. Snapshot synchronization completely refreshes data every time that the client is synchronized. This is appropriate when you do not want to track incremental changes or the server cannot do so. Download-only synchronization downloads only the incremental changes that have occurred since the previous synchronization.
Upload-only synchronization is typically used to insert data, such as a sales order, on a client. Inserts and other changes to data that are made in the client database are uploaded to the server during synchronization.
Bidirectional synchronization is typically used for data, such as customer contact information, that can be updated at the client and server. Any conflicting changes must be handled during synchronization.
For more information about the types of synchronization, see How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization. The Sync Services architecture for client and server synchronization is asymmetric: This means that change-tracking is built into the client database, but you must track changes in the server data store if you want incremental changes to be downloaded. For more information about change tracking, see Tracking Changes in the Server Database.
Components in the Architecture Illustrations
The components in the architecture illustrations include the client and server databases and a set of classes from the Sync Framework database synchronization API. The N-tier and service-based architectures also include Web Service and Transport components that you must write.
Two-Tier Architecture
The first illustration shows a two-tier architecture that has a client database and a server database.
.gif "2 層同期トポロジ")
Except for the two databases, all items in the illustration correspond to Sync Framework classes. These classes are contained in the following DLLs:
Microsoft.Synchronization.Data.dll contains Synchronization Agent, Synchronization Tables, and Synchronization Groups.
Microsoft. Synchronization.Data.SqlServerCe.dll contains the Client Synchronization Provider.
Microsoft. Synchronization.Data.Server.dll contains the Server Synchronization Provider and Synchronization Adapters.
All the DLLs depend on System.dll and System.Data.dll from .NET Framework 2.0 or later versions. Microsoft.Synchronization.Data.SqlServerCe.dll also depends on System.Data.SqlServerCe.dll from SQL Server Compact. For two-tier applications, all Sync Framework DLLs reside on the client. For N-tier applications, Microsoft.Synchronization.Data.dll and Microsoft.Synchronization.Data.Server.dll reside on a separate computer that provides a synchronization service.
N-Tier Architecture
The second illustration shows an N-tier architecture. This requires a proxy, a service, and a transport mechanism to communicate between the client database and the server database. This architecture is more common than a two-tier architecture, because an N-tier architecture does not require a direct connection between the client and server databases.
.gif "N 層同期トポロジ")
Service-based Architecture
The third illustration shows a service-based architecture. This architecture includes a client database, but does not include a server database or the corresponding Server Synchronization Provider and Synchronization Adapters. To use this kind of architecture, an application must be able to communicate to the Synchronization Agent through a custom proxy and custom service. These must provide the same functionality that the Server Synchronization Provider and Synchronization Adapters usually provide, such as retrieving changes to synchronize.
.gif "サービスに基づく同期トポロジ")
Client Database
The client database for Sync Framework applications is SQL Server Compact and later versions, including the 64-bit version of SQL Server Compact. Sync Framework provides an infrastructure to track incremental changes in the client database. This infrastructure is enabled the first time any table is synchronized by using a method other than snapshot synchronization. By default, the metadata that Sync Framework requires in the client database is stored for 10 days. For more information about metadata retention, see RetentionInDays.
Server Database
The server database can be any database for which an ADO.NET provider is available. If you want to track incremental changes in the server database, you must prepare the database to do this. For more information, see Tracking Changes in the Server Database.
Sync Framework Classes
The following classes are represented in the previous illustration: SyncAgent, SqlCeClientSyncProvider, DbServerSyncProvider, SyncTable, SyncGroup, and SyncAdapter. For an example of how to use these classes in an application, see Getting Started: Client and Server Synchronization.
Synchronization Agent
The synchronization agent drives synchronization in the following ways:
Loops through each of the tables to be synchronized.
Calls the client synchronization provider to retrieve and apply changes at the client database.
Calls the server synchronization provider to retrieve and apply changes at the server database.
The synchronization agent also maintains session-level information for the synchronization and provides success messages, errors, and statistics to the application on the client. For more information, see SyncAgent and How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization.
Client Synchronization Provider
The client synchronization provider communicates with the client and shields the synchronization agent from the specific implementation of the client database. Sync Framework includes a provider for the SQL Server Compact database. The principal activities of the client synchronization provider are as follows:
Stores information about tables on the client that are enabled for synchronization.
Retrieves changes that occurred in the client database since the last synchronization.
Applies incremental changes to the client database.
Detects conflicting changes.
For more information, see SqlCeClientSyncProvider and How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization.
Server Synchronization Provider
The server synchronization provider communicates with the server and shields the synchronization agent from the specific implementation of the server database. The principal activities of the server synchronization provider are as follows:
Stores information about tables on the server that are enabled for synchronization.
Enables applications to retrieve changes that occurred in the server database since the last synchronization.
Applies incremental changes to the server database.
Detects conflicting changes.
For more information, see DbServerSyncProvider and How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization.
Synchronization Table and Synchronization Group
A synchronization table is defined for each table that is synchronized. It stores settings, such as the direction of synchronization. Each client can request only the tables it needs. This might not include all the tables that the server synchronization provider makes available. For example, there might be 20 tables, 10 of which are configured for bidirectional synchronization in the Server Synchronization Provider. A client might request only 12 of the tables as download-only. Although the server supports upload, the client does not have to make changes or to synchronize all tables. For more information, see SyncTable.
After a synchronization table is defined, it can be added to a synchronization group. A synchronization group is a mechanism to ensure consistent application of changes for a set of tables. If tables are included in a synchronization group, changes to those tables are transferred as a unit and applied at the server in a single transaction. If any change in the group fails, changes for the whole group are retried on the next synchronization. For more information, see SyncGroup and How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization.
Synchronization Adapter
Modeled after the data adapter in ADO.NET, the synchronization adapter is defined for each table that is synchronized. The synchronization adapter provides the server synchronization provider with the specific commands that are required to interact with the server database, such as the InsertCommand that applies inserts from the client database to the server database. Because synchronization adapters use the ADO.NET DbCommand object, you can use any command structure that is supported by ADO.NET. This includes inline Transact-SQL, stored procedures, views, functions, and so on. The commands only require a single result that defines the structure and data to be transferred and applied. For more information, see SyncAdapter and How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization.
Proxy, Service, and Transport
Proxy, Service, and Transport are used in N-tier and service-based architectures. In N-tier applications, Microsoft.Synchronization.Data.Server.dll is used but it does not reside on the client. Typically, the DLL resides on a middle tier that has a direct connection to the server database. In this case, a proxy and service are required to communicate between the client and the middle tier:
On the client, application code references a proxy for the server synchronization provider (ServerSyncProviderProxy) instead of directly referencing the provider. The proxy communicates with a service on the middle tier.
On the middle tier, the service inherits from and exposes the same methods as ServerSyncProvider (the abstract class from which DbServerSyncProvider inherits). The server synchronization provider methods are then executed over a direct connection to the server database. The results are routed through the middle tier and back to the client.
For more information, see How to: Configure N-Tier Synchronization.
In service-based applications, Microsoft.Synchronization.Data.Server.dll is not used on the client. The application code must provide the same functionality that the server synchronization provider and synchronization adapters usually provide:
On the client, application code references a proxy for the application code that handles server synchronization provider tasks, such as retrieving changes from the data source. The proxy communicates with a service on the middle tier.
On the middle tier, the service inherits from and exposes the same methods as ServerSyncProvider (the abstract class from which DbServerSyncProvider inherits). The methods are then executed by the application code over a direct connection to the server database. The results are routed through the middle tier and back to the client.
Additional Classes in the API
The illustrations in this topic show the major classes in the API. However, there are many classes that are not shown. To obtain information about all the available classes, see Microsoft.Synchronization, Microsoft.Synchronization.Data, Microsoft.Synchronization.Data.SqlServerCe, and Microsoft.Synchronization.Data.Server. The following sections provide introductions to four other important classes that you should be familiar with.
Synchronization Anchor
A synchronization anchor is a reference point in time for a set of tables that are synchronized from the server. Synchronization anchors enable an application to determine which changes should be synchronized during a specified session. During synchronization, the client synchronization provider stores the following reference points in the client database:
Last received anchor
Identifies the last change that was downloaded from the server.Last sent anchor
Identifies the last change that was uploaded from the client.
On the next synchronization, an application can use these anchors to identify the starting point for synchronizing the next set of changes. For more information, see SyncAnchor and Tracking Changes in the Server Database.
Synchronization Session Statistics
Session statistics are a set of statistics that the Synchronization Agent provides for each synchronization session. The statistics include information about synchronization times, the number of changes processed, and any conflicts or exceptions that occurred. For more information, see SyncStatistics and How to: Work with Events and Program Business Logic.
Synchronization Session Variables
Session variables are variables that are provided for a developer to use as parameters for the select, insert, update, and delete commands executed at the server. The variables can be used in several ways: to provide support for conflict detection and to avoid downloading changes to a client more than one time. For more information, see SyncSession and How to: Use Session Variables.
SQL Server Synchronization Adapter Builder
Modeled after the command builder in ADO.NET, the synchronization adapter builder helps you develop code for the synchronization commands that are executed by the server synchronization provider. The synchronization adapter builder produces SELECT, INSERT, UPDATE, and DELETE statements for SQL Server databases. These statements are based on information that you provide about the tables that are involved in synchronization. For more information, see SqlSyncAdapterBuilder and Tools to Help You Develop Applications.