In previous article, we had discussed about the basics of sync framework. In this article, we will look into algorithm used by this framework for synchronization. The core of the sync framework is its synchronization algorithm. Sync framework synchronizes data stores using session and provider objects. First, we will create a session and passes it a source and destination provider. The session object gets the new changes in source provider and applies it on destination provider in turn data store. Creating a provider is core task in sync framework. A provider will maintain metadata and knowledge for the replicas. It will interact with sync framework to enumerate the changes in the source, detect conflicts and apply changes on destination. Synchronization can be one-way or two-way.

Steps in one-way Synchronization:
  • Session gets the knowledge of destination and sends it to source provider.
  • Source provider enumerates the changes that are not in destination.
  • Source provider sends changes to the session.
  • Session detects conflicts and applies changes to destination through destination provider.
We can achieve two-way synchronization using two one-way synchronizations. Now, we will look into creation of providers and applications of synchronization.

Synchronization Providers:

A provider manages the metadata of a replica and works with Sync framework to enumerate changes and detect conflicts. It also works with item store of replica to send item data when it is acting as source provider and applies changes to data store while acting as destination provider. We can implement a provider using managed code by implementing abstract methods and properties from KnowledgeSyncProvider, IChangeDataRetriever, and INotifyingChangeApplierTarget (or) unmanaged code by implementing IKnowledgeSyncProvider, ISyncProvider, ISynchronousDataRetriever, and ISynchronousNotifyingChangeApplierTarget interfaces.

Synchronization Applications:

The application is a software component that creates the synchronization session object, connects it with the providers, and hosts the synchronization runtime. We can create a sync application using managed code by following below steps:
  • Create a SyncOrchestrator object.
  • Set LocalProvider and RemoteProvider properties to the SyncProvider interfaces of the two providers.
  • Call Synchronize to start synchronization. This will make Sync framework call necessary methods in the two providers.

We can use unmanaged code to create sync application by following below steps:
  • Create an ISyncSession object by passing CLSID_SyncServices and IID_IApplicationSyncServices to the CoCreateInstance function.
  • Call IApplicationSyncServices::CreateSyncSession on the IApplicationSyncServices object. We need to pass ISyncProvider interfaces of the two providers.
  • Call ISyncSession::Start to start synchronization. . This will make Sync framework call necessary methods in the two providers to perform synchronization.
Up to now, we discussed about sync algorithm. Now, we will see how this algorithm uses knowledge to enable change enumeration and detect conflicts. Knowledge is the metadata that describes all the changes that have been applied to a replica, either directly or though synchronization. Change enumeration is the process of determining which items have been changed on the source replica that the destination replica does not have knowledge of. Conflict detection is the process of determining which operations were made by one replica without transferring knowledge of the change to the other replica, for example, when two replicas make local updates to the same item. Synchronization providers and applications will not directly use knowledge. Instead, they will call Sync Framework methods that invoke knowledge operations on their behalf.

Knowledge Operations:

The following table lists and describes the synchronization knowledge operations.

Operator Description
Contains Determines whether a specified knowledge object contains a specified version of an item. (Version is a replica key and a tick count.) In other words, determine whether the replica that owns this knowledge has applied this change. The item ID and version are required inputs to this operation.
This operation is used in change enumeration and conflict detection.
Union From two knowledge objects, constructs a new knowledge object that contains exactly the same set of changes that is contained by at least one of the original knowledge objects.
This operation is used during change application.
Project By using a specified knowledge object and an item ID, change unit ID, or range of item IDs, generates a new knowledge object that contains the same changes as the original for the specified ID or range of IDs, and nothing for the rest of the items.
This operation is used when knowledge must be restricted to a particular item, change unit, or range of items; for example, during interrupted synchronization, batching, and some advanced forms of filtered synchronization.
Exclude By using a specified knowledge object and an item ID or change unit ID, generates a new knowledge object that contains nothing for the specified ID, but the same changes as the original for the rest of the items. This operation is the opposite of the project operation: an exclude operation projects the knowledge on everything except the specified item.
This operation is typically used during failures in change application.

Change Enumeration:

Change enumeration is implemented by the developer of the source provider. It works as follows:
  • The destination provider sends the current knowledge of the destination replica to the source provider.
  • The source provider iterates through all items in the source replica and performs the following steps for each item:

    1. Determines whether the destination knowledge contains the item version that is stored in the source replica.
    2. If not, includes the item in the batch of changes to send to the destination provider.
Conflict Detection:

Conflict detection is handled by Sync Framework components, such as NotifyingChangeApplier or ISynchronousNotifyingChangeApplier.
After the destination provider has received a batch of changes, which contains the learned and made-with knowledge for the batch, the following determinations must be made for each change in the batch:
  • Is this change in conflict with the current version of the item stored in the destination replica?
  • Is this change obsolete (superseded by the current version of the item that is stored in the destination replica)?
I am ending the things here. In coming article, we will look into Microsoft Sync Services for ADO.NET 2.0.I hope this article will be helpful for all.