Introducing the Microsoft Sync Framework (Again)

Posted by Jonathan Allen on Oct 27, 2008

Sections

Operations & Infrastructure,

Enterprise Architecture,

Development,

Architecture & Design

Topics

Data Warehousing ,

.NET ,

Data Access

Tags

RSS ,

Sync Framework ,

Atom

Back in August, we reported on the release of the Microsoft Sync Framework. Strangely enough, they recently have released it again. In honor of this bizarre event, we are following up with what information we have on this muddled framework.

The Sync Framework is actually five separate technologies that work together.

• Sync Framework core components – These can be used to create synchronization providers for any type of data store.
• Microsoft Sync Services for ADO.NET – This can be used to synchronize databases for offline and collaborative scenarios.
• Metadata Storage Service – This can be used to store synchronization metadata in a lightweight data store.
• Sync Services for File Systems – This can be used to synchronize files and folders in a file system.
• Sync Services for FeedSync – This can be used to synchronize RSS and Atom feeds with data in a local store.

Elsewhere in the same documentation, the components are listed somewhat differently.

• Microsoft Sync Framework
• Sync Services for ADO.NET 2.0
• Sync Services for File Systems
• Sync Framework Metadata Storage Service
• Synchronization Services for ADO.NET 1.0 SP1

The differences between "Sync Services for ADO.NET 2.0" and "Synchronization Services for ADO.NET 1.0 SP1" are not clear. The overviews of each overlap greatly and don't contain much more than general marketing fluff. The Hardware and Software Requirements for Synchronization Services for ADO.NET 1.0 SP1 are actually a direct copy of the documentation for Sync Services for ADO.NET 2.0.

Here is what we can figure out:

In any synchronization scenario each participating data store will fall into one of four categories. First is the Full Participant, which is a peer in every respect and can initiate synchronization. Next is a Proxy Participant, which can initiate synchronization while handling communication on behalf of another data store. A Partial Participant can store the metadata needed for synchronization, but has no ability to process it. This is appropriate for small devices like mobile phones. Finally, there is the Simple Participant, which is entirely dependent on a Full Participant.

Synchronization is based heavily on the existence of metadata. This metadata stores information about the creation, versioning, and deletion of items. The documentation talks a lot about metadata management and ways in which individual replica sets can implement it.

Synchronization Providers can be written in both managed and unmanaged code. For managed code, developers start with the KnowledgeSyncProvider class. Unmanaged code uses the interface IKnowledgeSyncProvider.

Out of the box developers get providers for both ADO.NET and File Systems, the latter used to synchronize directories and files. But having providers is not enough; developers still need to write a considerable amount of code to setup replication. Some samples are given, but the documentation is rather clumsy and hard to follow. Given the complexity of the topic, a full book would serve better than the handful of confused web pages on MSDN.

Normally we try to not pass judgment, but in the opinion of this reporter the Microsoft Sync Framework should be avoided until Microsoft can figure out exactly what their stuff actually does and find a way convey that in their documentation.

• Older >