Custom Provider Fundamentals

Microsoft Sync Framework includes providers for several synchronization scenarios such as file synchronization, but in some cases a custom provider is necessary. Custom providers require a developer to write more code than the providers that are included with Sync Framework, but they are a key component to the flexibility and extensibility of Sync Framework. This topic provides information that helps you to understand custom providers and to make choices about which type of custom provider is appropriate for your application. If you are new to Sync Framework, we also recommend that you read "Sync Framework Components" in Selecting the Appropriate Sync Framework Components.

Understanding Providers, Applications, and Metadata Management

Microsoft Sync Framework synchronizes replicas by using four basic components: the synchronization runtime, a synchronization session, and two synchronization providers. To synchronize data, an application creates a synchronization session and passes it a source provider and a destination provider. The session uses the source provider to get new changes that have occurred on the source replica, and uses the destination provider to apply these changes to the destination replica. A provider maintains metadata, including knowledge, for each replica and for each item that is to be synchronized. Knowledge is the metadata that describes all the changes that have been applied to a replica, either directly or though synchronization.

When Sync Framework does not supply a provider for the data store to be synchronized, a custom provider must be written. Sync Framework includes managed and unmanaged APIs for two types of custom providers: simple custom providers and standard custom providers:

• Due to a smaller number of interfaces and the simplicity of those interfaces, simple providers offer greater speed of development and more intuitive support for data stores that lack sophisticated change tracking mechanisms.

• Standard providers offer the most flexibility and the highest levels of performance and robustness.

Both types of providers can be used to synchronize a wide variety of data stores; and they both provide options in important areas such as filtering and conflict handling. There are, however, important differences. For more information, see "Deciding Between a Simple Provider and a Standard Provider" in this topic.

The following illustration shows the main elements used in a synchronization scenario. The illustration is similar to the one in Selecting the Appropriate Sync Framework Components, but the accompanying text provides additional information relevant to custom providers and shows how data and metadata flow through the system.

The elements in the illustration are of three types:

• Elements that are written by the developer.

  • The application starts synchronization, responds to events, and handles other tasks based on application requirements. For more information, see Implementing a Synchronization Application.

  • The provider manages the metadata for a replica and works with Sync Framework to enumerate changes and detect conflicts. The provider also works with the data store of a replica to send item data when the provider is acting as the source provider, and to apply changes when the provider is acting as the destination provider. The provider is specific to the type of data that is being synchronized. The two providers in a session are often of the same type, but that is not a requirement. For more information about interoperability, see Integrating Data from Different Providers.

    Managed code A simple provider implements FullEnumerationSimpleSyncProvider or AnchorEnumerationSimpleSyncProvider. A standard provider implements KnowledgeSyncProvider, IChangeDataRetriever, and INotifyingChangeApplierTarget.

    Unmanaged code A simple provider implements IFullEnumerationSyncProvider or IAnchorSyncProvider. A standard provider implements IKnowledgeSyncProvider, ISyncProvider, ISynchronousDataRetriever, and ISynchronousNotifyingChangeApplierTarget (or for asynchronous providers, the asynchronous versions).

  • The data store is any store for which you will write a provider.

  • The data transfer protocol determines how data changes are transmitted between two providers.

• Elements that are provided by Sync Framework.

  • Depending on whether managed or unmanaged code is used, the application communicates with a synchronization orchestrator (SyncOrchestrator) or a synchronization session (ISyncSession), which then communicates with each synchronization provider, drives the synchronization process, and communicates status, conflicts, and errors to the client application.

  • The synchronization runtime helps the providers perform common synchronization tasks, such as metadata management, conflict detection, and change application.

• Elements that are either written by the developer or provided by Sync Framework, depending on the provider and application requirements.

  • 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. The metadata store can be separate from the data store (such a separate file or database), or integrated into the store (such an extra table in a database). Typically, the synchronization provider manages the metadata that is required for synchronization. However, depending on the implementation of the replica, it may be more useful for some parts of the metadata management to be handled by a separate component, such as a service that cleans up old metadata at scheduled times instead of during synchronization. The required metadata and the way in which it is stored and worked with depend on which provider is used. For information about metadata requirements for each provider type, see Managing Metadata for Simple Providers and Metadata Requirements for Standard Providers.

    The simple provider shields the developer almost entirely from interacting with the metadata store. It uses an implementation of metadata storage service that is included with Sync Framework. Standard custom providers can use this implementation or they can: use another implementation based on the metadata storage service API; or a completely custom implementation that stores metadata in a separate store or within the data store. For more information, see Managing Metadata for Standard Providers.

Deciding Between a Simple Provider and a Standard Provider

In most cases we recommend that you use a simple provider, but you should first understand the assumptions that were made in the design of the simple provider API:

• The data stores to be synchronized do not support any type of change tracking, or support only anchor-based change tracking.

  An anchor is an object that indicates which items in a data store have changed since the last synchronization session. In stores that have no change tracking or only anchor-based change tracking, updates to synchronization knowledge occur during the synchronization session (asynchronously), rather than when the change occurs in the store (synchronously). This can affect performance if many synchronization sessions happen concurrently on a particular replica. Therefore, if an application requires high concurrency and each data store supports synchronous updates to synchronization knowledge, use a standard provider.

• The replica requires only one item type to be synchronized.

• Due to data store limitations or application requirements, metadata must be stored outside the data store.

  Simple providers store metadata by using the implementation of the metadata storage service that is included with Sync Framework. Metadata is stored separately from the data that it describes, which presents two potential issues:

  • If the metadata is stored remotely, it could be completely unavailable during a synchronization session. For example, the network connection between the two replicas to synchronize is available, but the connection to the server that hosts the metadata is not.

  • Transactional consistency between data and metadata is not guaranteed. Storing metadata on the same computer as the data is recommended, but transactional support is not available unless you use a standard provider and store metadata in the data store (or use a distributed transaction to update both stores). Note that standard providers can also use the metadata storage service, but they are not required to do so like simple providers.

If your application requirements fit well with these assumptions, we recommend that you use simple providers. For more information about simple providers, see Implementing a Simple Custom Provider. For more information about standard providers, see Implementing a Standard Custom Provider.

Understanding Sync Framework Participant Types

Sync Framework can be used to synchronize data among participants of varying functionality. A participant is a device or service that can synchronize with other systems that are running Sync Framework.

Sync Framework supports the following types of participants:

• Full participant

• Proxy participant

• Partial participant

• Simple participant

Full Participant

A full participant locally hosts the runtime and stores metadata. Full participants can take part in peer-to-peer synchronization scenarios because both participants can start synchronization.

Two Full Participants in Peer-to-Peer Synchronization

Partial Participant

A partial participant can store synchronization metadata but cannot process it. A partial participant relies on several full participants to host the runtime and start synchronization. Data can flow through these participants because they can carry the multimaster synchronization metadata and communicate this metadata with any other full participant. Partial participants cannot take part in peer-to-peer scenarios because of their inability to process the metadata or host the runtime. Some examples of partial participants are USB thumb drives and mobile phones that have data storage capabilities.

The following illustration shows how a full participant, such as a computer, synchronizes with a partial participant, such as a mobile phone. The full participant enumerates or filters changes on behalf of the partial participant and stores the metadata on the partial participant. This enables any other full participant to synchronize this partial participant.

Full Participant Synchronizing with a Partial Participant

Simple Participant

A simple participant does not store metadata, cannot house the runtime, and might not have change tracking. Instead, a simple participant relies on a single full participant to do everything with regard to enumerating changes, applying changes, and manipulating and storing the metadata. Because a simple participant cannot store metadata, it can only act as a leaf node that is partnered with a single full participant that transfers data to and from any other participants.

The following illustration shows a full participant that uses the metadata storage service to store metadata for a simple participant and that drives all aspects of synchronization on behalf of the simple participant. The metadata store is used to track changes related to the simple participant but is stored on the full participant because of the storage limitations of the simple participant.

Full Participant Using the Metadata Storage Service to Synchronize a Simple Participant

Proxy Participant

A proxy participant starts synchronization for a remote provider by handling calls locally and forwarding them to the remote provider, such as a database that is stored on a server.

Security Note
Sync Framework does not provide authentication or encryption between the proxy provider and the remote provider. To help prevent unauthorized access or tampering, the communication channel between the proxy provider and the remote provider must be secured by using an appropriate mutual authentication and encryption mechanism, such as Secure Sockets Layer (SSL).

The following illustration shows a full participant provider synchronizing with a proxy provider. Notice that the proxy provider just sends commands and metadata over the network to the remote provider. The remote provider exists on the database server and implements the actual logic that is used for the synchronization. The dashed red line represents a computer boundary.

Full Participant Synchronizing with a Proxy Participant

The following illustration shows how Sync Framework can be used to synchronize providers that are remote to the application that starts synchronization. The controlling application could be connecting two Web services or smart devices that must be synchronized. Notice that both local providers are proxy providers to the remote providers. The dashed red lines represent computer boundaries.

Central Application Synchronizing Two Proxy Participants

See Also

Concepts

Selecting the Appropriate Sync Framework Components
Implementing a Simple Custom Provider
Implementing a Standard Custom Provider
Implementing a Synchronization Application
Sync Framework Samples