Architecture and Classes for Peer-to-Peer Synchronization
The Sync Services for ADO.NET 2.0 peer-to-peer API architecture is designed to allow peers to exchange changes with each other without having to synchronize through a central server. Sync Services also offers APIs that are designed to synchronize clients with a central server; for more information, see Architecture and Classes for Client and Server Synchronization. In peer-to-peer synchronization, each peer typically contains the application code and Sync Services code to initiate synchronization. During each synchronization session, a pair of peers is synchronized. For example, given three peers, you could synchronize peer1 and peer2, then peer2 and peer3, and finally peer1 and peer3. In each case, one of the peers would be the local peer, and the other would be the remote peer. You are not required to synchronize every peer with every other peer, but that does provide redundancy in the system. In the case of three peers, you could synchronize peer1 and peer2 and then peer2 and peer3. Peer1 and peer3 would receive changes from each other through peer2.
Components in the Architecture Illustrations
The following illustrations show the components that are involved in two-tier and N-tier architectures. The components in the architecture illustrations include the peer databases and a set of classes from the Sync Services API. The N-tier architecture also includes a proxy and a service component that you must write.
Two-Tier Architecture
The first illustration shows a two-tier architecture that has two peer databases.
Except for the two databases, all items in the illustration correspond to Sync Services classes. These classes are contained in the following DLLs:
Microsoft.Synchronization.dll contains SyncOrchestrator. The SyncOrchestrator class is described in the Sync Framework core documentation.
Microsoft.Synchronization.Data.dll contains DbSyncProvider and DbSyncAdapter.
The DLLs depend on System.dll and System.Data.dll from .NET Framework 2.0 or later versions. For two-tier applications, all Sync Services DLLs reside on the local peer for the particular synchronization session. For N-tier applications, some DLLs must also reside on the remote computer. For more information, see How to: Configure Change Tracking and Synchronize Peers.
N-Tier Architecture
The second illustration shows an N-tier architecture. This requires a service and a transport mechanism to communicate between a proxy on the local computer and a service on the remote computer. Unlike client and server synchronization, the proxy is not part of the Sync Services API. You must write a proxy that derives from KnowledgeSyncProvider. The KnowledgeSyncProvider class is described in the Sync Framework core documentation. To download this documentation, go to this Microsoft Web site. The service then communicates with the DbSyncProvider on the remote computer. How to: Configure N-Tier Peer-to-Peer Synchronization.
Peer Database
The peer database can be any database for which an ADO.NET provider is available. For information about how to track changes in each database, see How to: Configure Change Tracking and Synchronize Peers.
Sync Services Classes
The following classes are represented in the previous illustration: SyncOrchestrator, DbSyncProvider, and DbSyncAdapter. For an example of how to use these classes in an application, see How to: Configure Change Tracking and Synchronize Peers.
Synchronization Orchestrator
The synchronization orchestrator drives synchronization in the following ways:
Loops through each of the tables to be synchronized.
Calls the local peer synchronization provider to retrieve and apply changes at the local database.
Calls the remote peer synchronization provider to retrieve and apply changes at the remote database.
The synchronization orchestrator also maintains session-level information for the synchronization and provides success messages, errors, and statistics to the application that initiates synchronization. For more information, see SyncOrchestrator in the Sync Framework core documentation.
Peer Synchronization Provider
The peer synchronization provider communicates with each peer and shields the synchronization orchestrator from the specific implementation of the peer database. The principal activities of the peer synchronization provider are as follows:
Stores information about tables on the peer that are enabled for synchronization.
Enables applications to retrieve changes that occurred in the peer database since the last synchronization.
Applies incremental changes to the peer database.
Detects conflicting changes.
For more information, see DbSyncProvider.
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 peer synchronization provider with the specific commands that are required to interact with the peer database, such as the InsertCommand that applies inserts from one peer database to the other peer 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 DbSyncAdapter.
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 in this documentation and in the Sync Framework core documentation, and Microsoft.Synchronization.Data. The following sections provide introductions to three other important classes that you should be familiar with. For an example of how to use these classes in an application, see How to: Configure Change Tracking and Synchronize Peers.
Synchronization Scope
A scope is a logical grouping of objects to be synchronized. In the case of peer-to-peer database synchronization, a scope is typically a set of tables. For more information, see DbSyncScope.
Synchronization Session Statistics
Session statistics are a set of statistics that the Synchronization Orchestrator 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 SyncOperationStatistics in the Sync Framework core documentation.
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 each peer. For more information, see How to: Use Session Variables for Peer-to-Peer Synchronization.
See Also
Concepts
Collaboration Scenarios (Sync Services)
How to: Configure Change Tracking and Synchronize Peers