About the Microsoft Sync Framework

The Microsoft Sync Framework version 3.0 is designed to make it easy to allow synchronization of databases (including complete tables
and individual rows), file system content, and arbitrary data in a range of scenarios. The following are some of these synchronization scenarios:

• Between on-premises databases and single or multiple cloud databases
• Between multiple on-premises databases via the cloud (“data hub in the sky”)
• Between multiple cloud databases
• Between remote data store(s) and client applications
• Between data stores and Microsoft Excel® spreadsheet software (Pivot) or other Microsoft Office applications such as Microsoft SharePoint® team services, Exchange Server, and other enterprise solutions
• To populate remote databases from on-premises databases
• To aggregate data from multiple remote databases to onpremises databases
• To maintain a consistent view of data across “three screens” (mobile, desktop, and cloud)
• To allow reuse of the same application model and logic with just a different user interface (UI) for each client type
• To enable simple development of occasionally-connected (“offline-and-sync”) clients

The Sync Framework exposes changes to data using the OData Sync protocol. This is based on the Open Data (OData) protocol. OData allows a wide range of data sources to be exposed and consumed over the web in a simple, secure, and interoperable format. It uses well-established standards and web technologies such as XML, HTTP, Atom Publishing (Atom Pub), and JavaScript Object Notation (JSON). For information about OData, see the Developers page on the Open Data Protocol website (http://www.odata.org/developers). For a list of OData providers and tools, see the OData SDK page on the Open Data Protocol website (http://www.odata.org/developers/odata-sdk).

Figure 1 shows an overview of how the Sync Framework can be used in a Windows Azure service to synchronize data with different types of clients. The service exposes synchronization endpoints to which clients can connect. The way that the synchronization occurs depends on the type of client, and the synchronization protocols it supports. The synchronization is managed by the Sync Framework itself, and can optionally include custom business logic to perform tasks such as authentication, authorization, and management.

Components of the Sync Framework

To achieve the required fl exibility, the architecture of the Sync Framework consists of a central orchestration mechanism, a small synchronization runtime for each client, and individual pluggable providers for each of the data stores and client types.

In many cases, the synchronization runtime and provider can run on the client; this enables full integration with the sync framework as
well as the capability for peer-to-peer synchronization. Code on the client can access the functionality of the Sync Framework using the
simple API available in the provider runtime to synchronize with another data source, send changes to that data source, and access data
in the data source that has changed since the last synchronization. The mechanism also allows clients and data stores to specify rules on
how to resolve confl icts. Figure 2 shows a schematic of this process.

In cases in which the synchronization provider cannot execute on the client, such as with non-Windows devices or web browsers, developers can write code that accesses the provider on the remote data store using the OData Sync protocol to synchronize data, send updates, and get changes from the remote data store.

The server (in this example, running in Windows Azure) specifi es an endpoint that exposes changes using the OData Sync protocol.
Typically, this is a Windows Communication Foundation (WCF) service. The client may use a runtime and provider that understands the OData Sync protocol, or—where this is not available or practical—it can use custom code to read and parse the OData Sync information.
Figure 3 shows a schematic of this approach.

The main advantage is that there is now a standard way to read and submit changes for synchronization between the data store, this client device, and other devices that use the same set of data.

Sync Framework Providers

Some providers are still under development, and others will be added to the list in the future. At present, the range of providers available, or soon to be available, includes the following:

• SQL Server using tabular data stream (TDS) protocol over HTTP(S) and a wizard in SQL Server 2008 R2
• SQL Server Compact Edition over HTTP(S)
• SQL Azure™ technology platform using the TDS protocol over HTTP(S) and a wizard in SQL Server 2008 R2
• Azure Web Roles using an HTTP(S) endpoint with access to Azure table and binary large object (BLOB) storage
• Silverlight synchronization to isolated storage using HTTP(S) to synchronize data stored as collections
• Windows Phone 7 synchronization to isolated storage using HTTP(S) to synchronize data stored as collections
• Windows Mobile 6.x support over HTTP(S) to SQL Compact Edition
• Synchronization to HTML 5 clients over HTTP(S) (coming in a future release)
• Synchronization to any existing HTTP-enabled client using HTTP(S) with a custom proxy and code
• File-based synchronization across computers and networks using standard network protocols

For more information about the Sync Framework, see the Microsoft Sync Framework Developer Center on MSDN® (http://msdn.microsoft.com/en-us/sync/default.aspx).