Partager via

Design: The Sync framework

  • Article

In first place let me answer the question why do we need a sync framework. The current connected scenario present different challenges for developers, the technologies are there but all of them are different. If you want to synchronize your pictures with your computer you will use the photo sync technology, if you want to share music you will use a custom application, and if you want to share data you may use replication technologies just to mention some examples! Things become a little more complicated if you want shareable repositories like back-up models. Today the industry is taking us to the connected devices environment adding wireless and USB connectors to everything (remember the promise of an intelligent washing machine?). I believe is time to have a common framework that we can use to normalize this approach, this is time for the sync framework!

The framework comes as a separate installation as is at the moment of this article just a CTP, for more information about the basics you can check here. In this article I am going to talk about the internal architecture and how this can be used by designers in order to build scalable synchronization models aligned with the Microsoft roadmap.

The framework architecture is based on service providers, at the moment Microsoft is offering file services, ADO.NET services and SyncFeed (for RSS) providers. All these providers are used by the synchronization framework that is responsible for synchronizing them via the metadata information.

           

The application initializes the services that is going to use and then will use the SyncAgent to synchronize the local and the remote provider. The sync agent consumes the sync providers in order to synchronize the knowledge between the local and the remote provider. The agent publishes progress objects that can inform the client application about the status of the synchronization (quite handy for progress bars). As the synchronization runs on the callers thread this is a good candidate for a background thread to enhance the user experience.

       

An interesting feature of the file provider is the ability to act based on defined properties, for example, we can set that after any delete or change due synchronization the files will go to the recycle bin, using the following option:

FileSyncOptions.RecycleDeletes | FileSyncOptions.RecycleOverwrites

The filters can be configured using the FileSyncScopeFilter allowing the developer to define which files to include on the synchronization. Upon these options are published for the file provider each of the other ones will expose custom properties to set up the provider, including vertical and horizontal filters on database tables (similar to the replication model).

Different approaches can be taken when dealing with the synchronization direction, supporting a client server model, mesh or peer to peer. This will depend on the participant types:

· Full Participant: These participants will host the framework and will be responsible for triggering the synchronization.

· Partial Participant: These participants are dummy storages, which receive and synchronize information from a full participant but do not host the framework (either is aware of it). For examples, USB drives, cameras, mp3 players, remote folders

· Simple Participant: These participants provide data but do not store it, for example an RSS feed or a webservice that provides enumerable data. Again, a full participant is needed to host the framework.

The direction of the synchronization is based on the following parameters:

SyncDirection.UploadAndDownload
SyncDirection.Upload
SyncDirection.Download
SyncDirection.DownloadAndUpload

As we can see, the framework is a powerful option that can help to use a single synchronization pattern for the different models. If the implementation is a success I don’t see a reason why current replication and synchronization models like SQL replication can be based on this model, look at what happened to WF and BizTalk J.

Regarding the internal works of the framework, at the moment is in CTP and is likely to change. The current implementation is also accessible through unmanaged code as the file service provider for example uses COM to interact with the file system, not the same story for the ADO.NET provider, but at the end that is the beauty, independent providers using a common framework.

Comments