WinFS Blog:Synchronizing Data between WinFS Stores
跳转到导航
跳转到搜索
January 25, 2006 Hi, my name is Mark Scurrell and I’m a Program Manager on the WinFS Sync team. I’d like to give you an overview of the functionality we provide to allow applications to synchronize data between WinFS stores. If you haven’t already done so, I would recommend you first read a previous post where Neil Padgett provided an overview of synchronization and described the scenario where data is synchronized between a WinFS store and a non-WinFS application store. As well as providing a set of services to synchronize with non-WinFS stores, as Neil described, we also want to allow developers to build peer-to-peer applications. So, as part of the WinFS Sync platform we provide services that will allow applications to synchronize their data between multiple WinFS stores without application developers having to design and code the sophisticated synchronization algorithms that are required for peer-to-peer applications. A good example of a peer-to-peer application that was built using WinFS Sync is Microsoft Rave, a sample application included in the WinFS Beta 1 SDK. Rave allows WinFS data to be shared between users without the need for a server – each user can directly synchronize folders on their computer with other user's peer-to-peer. The developer of Rave discussed his experience producing this application in a previous post. Let’s start with the simplest use of WinFS-to-WinFS synchronization which is to synchronize two WinFS stores. So, what happens when synchronization is initiated? WinFS Sync will do the following: * Determine the changes made to each store since the last sync (change enumeration) * Communicate those changes to the other store and update the other store (change application) * When applying the changes, determine if there is any conflicting data – the same data has been changed on both stores since the last synchronization (conflict detection) * Either log the conflicting data for later resolution or have it resolved immediately (conflict resolution). WinFS stores will contain many different types of data such as files, custom item types, links between items, and so on. WinFS Sync will synchronize all data stored in WinFS; no custom code is ever required, for example, even if a new item type is defined. Synchronization between two stores is useful; however more interesting scenarios involve multiple stores. With multiple stores there are different ways the stores can be configured to communicate – the sync topology. The Microsoft Rave sample application, for example, allows multiple users to synchronize, with each user being able to synchronize with every other user in a full mesh topology. Another application, for example, may require a topology with all changes being communicated through a central “hub”. The point that I want to emphasize here is that WinFS Sync is very flexible and has been designed to cater for any topology; there does not need to be a “master” node and true peer-to-peer applications can be built. I’ve described how WinFS Sync was built to handle peer-to-peer scenarios and different topologies, but how do we handle the fact that sync applications will need to operate in many different network configurations? Here are some possible scenarios for peer-to-peer sync applications: * There are multiple computers on a home workgroup network; a user could synchronize their data between computers so it can be accessed and updated on any computer in the home. * Users are members of a domain on a corporate network and can configure folders for sharing and collaborating with other invited users. * Family members are located in different parts of the country or in different countries; they can share photos with other members of their family by having them synchronize their computers over the Internet. WinFS Sync has no knowledge of the network configuration or the transport that will be available for communication of the changes. The application developer must provide a transport over which the sync protocol will operate. We define an interface for the transport and the sync application must supply an implementation of that interface to WinFS Sync. The developers of the transport do not have to concern themselves with the complex logic of synchronization; they implement simple methods such as ReadMessage and WriteMessage and WinFS Sync does the rest. Those of you who have had a close look at our Beta 1 release may be confused as we provided a facility called Store Synchronizer that synchronized data between WinFS stores and included a transport suitable for a local network. For Beta 2 we have decided to focus on providing the peer-to-peer synchronization platform and will not provide any specific transport implementations. We have therefore modified Store Synchronizer so it requires a transport implementation. In the Beta 2 SDK we will of course provide sample code for a transport, guidance on how to build a transport, and reference material for the Store Synchronizer classes. My main goal with this article is to raise awareness of the set of synchronization services that WinFS provides to support peer-to-peer sync application development and also to highlight the flexibility we allow in terms of diverse sync scenarios, topologies and network configurations. I hope you found this post useful. There is further information available in our Beta 1 SDK documentation if you want to dig deeper. I would be interested to hear about any scenarios where you would utilize our WinFS-to-WinFS synchronization capabilities. Author: Mark Scurrell