Selecting the Appropriate Sync Framework Components
This topic describes which components to use for common synchronization scenarios, and describes the high-level architecture of Sync Framework.
Sync Framework Components
Sync Framework includes a runtime, a set of synchronization providers for specific data stores, and an API for writing providers. A provider is a software component that communicates between a data source and other components in the synchronization system. If you synchronize a data store for which we supply a provider, we strongly recommend that you use that provider. Providers offer extensibility so that they can be tailored to your application. If you synchronize a data store for which we do not supply a provider, or you require a different implementation, a custom provider is appropriate.
The following illustration shows the relationships between all the components that Sync Framework supplies.
.gif "Sync Framework components")
The components in the illustration are as follows:
Database synchronization providers (referred to as Sync Services for ADO.NET in previous releases). These providers are contained in Microsoft.Synchronization.dll, Microsoft.Synchronization.Data.dll, Microsoft.Synchronization.Data.Server.dll, Microsoft.Synchronization.Data.SqlServer.dll, and Microsoft.Synchronization.Data.SqlServerCe.dll. They can be used to synchronize databases for the following types of scenarios:
Collaborative scenarios. For example, in an application that allows users to share project notes, project team members often require a local copy of data that they can work with. When they have made changes, they can synchronize with another team member to exchange changes and also synchronize changes with a central server.
Offline scenarios. For example, a sales person requires access to product data at a customer's office and also must be able to upload orders. The sales person could synchronize with the central server each morning to ensure that she has the latest products and prices, and synchronize in the evening to upload orders from the day.
For more information, see Synchronizing Databases. The offline providers were originally part of Synchronization Services for ADO.NET 1.0, which was released before Sync Framework 1.0. Collaboration providers are built on top of the core API and runtime, but offline providers are not. Offline providers cannot participate in topologies with other types of Sync Framework providers.
File synchronization provider (referred to as Sync Services for File Systems in previous releases). This provider is contained in FileSyncProvider2.dll and Microsoft.Synchronization.Files.dll. It can be used to synchronize files and folders in NTFS, FAT, or SMB file systems. The directories to synchronize can be local or remote; they do not have to be of the same file system. An application can use static filters to exclude or include files either by listing them explicitly or by using wildcard characters (such as *.txt). Or the application can set filters that exclude whole subfolders. An application can also register to receive notification of file synchronization progress. For more information, see Synchronizing Files.
Web feed synchronization components (referred to as Sync Services for FeedSync in previous releases). These components are contained in FeedSync2.dll and Microsoft.Synchronization.dll. The components can be used in two ways:
The Web feed synchronization provider services can be used to write a provider that represents a FeedSync XML file as its replica. For more information about FeedSync, see the FeedSync Web site.
The Web feed producer and consumer components can be used to synchronize the data of another type of replica (such as a file system) with an RSS or Atom feed.
For more information, see Synchronizing Web Feeds.
Custom providers. These components are contained in Synchronization2.dll and Microsoft.Synchronization.dll; and SimpleProviders2.dll and Microsoft.Synchronization.SimpleProviders.dll. They can be used to create synchronization providers for any type of data store. For example, if an application includes a custom storage system for customer contact tracking, you can use a simple provider or a full custom provider to integrate that data into your applications. For more information, see Synchronizing Data Stores by Using Custom Providers.
Metadata storage service. This component is contained in MetaStore2.dll and Microsoft.Synchronization.MetadataStorage.dll. It can be used by custom providers as a convenient way to store and process synchronization metadata, especially for replicas that cannot otherwise store metadata. The metadata storage service uses a reliable, lightweight database that has a small memory and disk footprint, and can be redistributed together with the provider. The API clearly separates the metadata store from the interfaces and methods that are used to access the store so that alternative stores can be implemented and used with minimal change to the provider. For more information, see Sync Framework Metadata Storage Service.
Core API and runtime. These components are contained in Synchronization2.dll and Microsoft.Synchronization.dll. The core API and runtime are used by all the other components except for the offline database providers. For more information about these components, see Synchronizing Data Stores by Using Custom Providers.
For information about installing components, see Installation, Redistribution, and Version Compatibility.
Sync Framework supplies a comprehensive set of components to enable synchronization for a wide variety of applications. This topic provided a basic introduction to each component, to help you decide which components are appropriate for your applications. For applications that involve more than one type of data store, your next step is to read Integrating Data from Different Providers.
Sync Framework Architecture
Sync Framework uses a provider-based architecture. Providers shield other synchronization components from the complexities and specific implementation of each data store. This architecture, coupled with the use of specialized synchronization metadata, enables Sync Framework to synchronize any type of data store for which a provider is written. Sync Framework includes providers for common data stores, such as databases and the NTFS file system, and lets you write providers for other types of stores. The provider is the main integration point into Sync Framework.
The following illustration shows the high-level architecture of Sync Framework. Synchronization always occurs between two replicas (or nodes) as shown in the illustration, but synchronization communities (or topologies) can be of any shape, such as hub-and-spoke, peer-to-peer, and so on. With some exceptions, each pair of participants can synchronize over a 2-tier architecture or an n-tier architecture, as application requirements dictate. The documentation for each Sync Framework component provides more detailed information about appropriate architectures and security considerations.
.gif "Sync Framework architectural overview")
The elements in the illustration are of three types:
Elements that are written by the developer.
The application calls synchronization methods, responds to events, and handles other tasks based on application requirements.
The data store could be a file system, a relational database, a flat file contacts store, or any other data store that needs to be synchronized.
The data transfer protocol determines how data changes are transmitted between two providers.
Elements that are provided by Sync Framework.
Depending on whether native code or managed code is used, the application communicates with a synchronization session or a synchronization orchestrator, which then communicates with each synchronization provider.
The synchronization runtime drives the synchronization process and communicates status, conflicts, and errors to the client application.
Elements that are either written by the developer or provided by Sync Framework, depending on the scenario.
The provider is specific to the type of data that is being synchronized. In some situations, an application requires a custom provider that the developer must write. Sync Framework provides a number of APIs to make this process more straightforward, as well as a number of components that assist with the most difficult parts of synchronization, such as conflict detection.
The metadata store contains the metadata that Sync Framework uses to determine which changes each provider should select from and apply to the data store that it services. How metadata is stored and worked with depends on which provider is used. For example, providers for databases typically store metadata in tracking tables in the same database as the data store. For custom providers, you can create a metadata store or use a service that is included with Sync Framework. The documentation for each Sync Framework component provides more detailed information about metadata.