Freigeben über

Microsoft Sync Framework, Part 1: Introduction

  • Artikel

Introducing Microsoft Sync Framework

Microsoft has already or will shortly announce Microsoft Sync Framework at TechEd Europe in Barcelona and at DevConnections in Las Vegas. Microsoft Sync Framework is the revolutionary product which makes possible multi-master data synchronization to be relatively easy implemented and supported by various applications. MSDN web site has just launched the sync dev center which can be used as a starting point for your exploration of Microsoft Sync Framework.

Why Microsoft Sync Framework

Sync is hard. Correction: right sync is hard. Most people, when they think about sync, first think about the synchronization of data between two endpoints. Next, they think about conflicts - particularly about conflict detection, propagation of conflicts, conflict resolution and propagation of conflict resolution. Then people think about scenarios where more than two endpoints synchronize with each other and that's where the problems typically appear. The sync dev center has a great illustration of the multi-master sync:

In general, it's natural for a good data sync technology to satisfy the following requirements:

  1. Be efficient. Change detection and conflict detection should be as efficient as possible.
  2. Sync metadata should be compact. Sync metadata is required to implement any sync solution, however ideally it shouldn't introduce a significant overhead.
  3. Conflicts must not be over- and under-detected. This is a particularly important requirement - no one wants fake conflicts detected or even worse conflicts undetected which lead to data loss.

Microsoft Sync Framework addresses requirements above in the most balanced way in terms of efficiency and sync metadata size. The conflicts over- and under-detection problem is completely solved by Microsoft Sync Framework and is done automatically and transparently for users.

Sync integration levels

There are several sync integration levels possible:

  1. The UI integration level doesn't have a common implementation or store, all sync solutions are simply integrated by the common UI. This approach is the most flexible in terms of store/protocol independence, however different sync solutions cannot inter-operate.
  2. The Sync Metadata integration level requires different sync solutions to negotiate on a sync metadata level (obviously, there are other parts in this equation - sync solutions also need to negotiate on data representation and schema as well). This is the most balanced level and easiest to achieve.
  3. The Protocol level requires sync solutions to negotiate on details of data exchange. This level is also quite flexible however it can be difficult to use by solutions which use different protocols.
  4. The Store level demands all data to be stored in the same way and sync support is built into the store. It's not a particularly demanded level because applications tend to have their own data stores and it's also very to hard to develop a flexible store which could be used by various applications. Still, there can be scenarios where this particular level could be useful, for example databases.

As we'll see, Microsoft Sync Framework currently enables levels 2 thru 4. It definitely supports Sync Metadata level and partially Store level with Sync Services for ADO.NET, and in the future we can expect work done to better support Protocol level (right now Microsoft Sync Framework is protocol agnostic).

What is Microsoft Sync Framework?

Microsoft Sync Framework is a set of services which help customers develop efficient, flexible, protocol agnostic and correct sync solutions. Microsoft Sync Framework offers a set of services to do multi-master data synchronization between arbitrary stores and protocols, it has built-in efficient file sync and synchronization of database records. Microsoft Sync Framework has built-in support for Simple Sharing Extensions.

Microsoft Sync Framework offers both COM APIs and .NET APIs (with the caveat that some services are only available in .NET APIs like Sync Services for ADO.NET).

In future posts I'll cover some parts of Microsoft Sync Framework like Metadata services, Synchronization Engine, SSE interoperability and various tips for sync provider writers. There are services which I probably won't cover because other people in our team can do it much better - Rafik for example is an expert in other areas of Microsoft Sync Framework like Sync Services for ADO.NET which he'll cover in his blog.

Stay tuned

I've started this blog to keep Microsoft Sync Framework users informed about the platform, tricks and techniques to utilize it in the most effective way in various scenarios as well as to get an input from users, so if you're interested - speak up, ask questions and better yet download Microsoft Sync Framework and give it a try. Let us know what you think, what else you want us to support in Microsoft Sync Framework and what can be done differently. Our team believes in a great potential of this technology and we're very interested in making it better.

In the next post I'll write about the sync metadata which is the heart of Microsoft Sync Framework.

Comments