Appendix E - Microsoft Sync Framework and Windows Phone 7

Application models based on traditional client-server and web-based technologies tend to have little need for synchronizing data between locations. In most cases, all instances of clients—such as Windows® Forms applications or web browsers—access a single store that holds the data used by the application (although this store may itself be a server farm). However, the increasing use of cloud-based data stores and mobile devices means that the capability to synchronize or replicate data across separate locations and devices is becoming even more vital.

Synchronization between databases has been a common requirement for a while, and technologies to achieve this are available and widely used. However, they are often closely tied to a specific scenario and do not support more general client application scenarios. The following are some examples of the capabilities that are becoming essential for distributed applications:

  • Synchronizing data between geographically separated cloud-based data repositories and applications
  • Synchronizing data between one or more on-premises databases or applications and one or more cloud-based databases or applications
  • Synchronizing data between rich client applications and the data source to maximize interactivity and usability of the application
  • Synchronizing data between mobile and occasionally connected devices and the application data store to allow off-line operation

Some of these requirements can be satisfied using relational database replication and synchronization technologies, generally where there is a database available on the client computer (which, in some cases, may be SQL Server® Compact Edition or another file-based database mechanism). However, there is an increasing requirement to synchronize data for devices and clients that do not have a local database mechanism available. Typical examples of this are mobile phones and similar small form factor devices.

The Microsoft® Sync Framework aims to provide an extensible and easy-to-use mechanism for synchronizing data between almost any type of data source and client. In the context of this guide, it specifically enables synchronization between Windows Azure™ technology platform services and Windows Phone 7 devices.

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 on-premises 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
Gg507824.note(en-us,PandP.10).gifNote:
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.

Gg507824.daa4c2ad-711c-4ca6-905a-22ac2b076c22-thumb(en-us,PandP.10).png

Figure 1

Overview of the Sync Framework capabilities

Components of the Sync Framework

To achieve the required flexibility, 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 conflicts. Figure 2 shows a schematic of this process.

Gg507824.24bda1ad-9775-4b7b-a59b-786ed2fea4f3-thumb(en-us,PandP.10).png

Figure 2

The components and process for synchronization with Windows clients

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) specifies 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.

Gg507824.e300c153-af66-4a8e-9725-c4039db50df8-thumb(en-us,PandP.10).png

Figure 3

The components and process for synchronization with non-Windows clients

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).

Using the Sync Framework

To perform synchronization, the developer writes code that does the following:

  • Initiates a synchronization session
  • Sets up references to two synchronization providers and configures them appropriately
  • Starts the synchronization process

Each client or server store holds information about the changes occurring in that store. This metadata, stored local to and available to each provider, contains the knowledge used by the provider to detect changes and conflicts. The Sync Framework includes a small footprint metadata store service that developers can use when implementing custom providers. Alternatively, developers can implement the metadata functionality as part of the local data store. An example is the offline store provider for Silverlight web applications and Windows phone 7 applications.

Gg507824.note(en-us,PandP.10).gifNote:
Data converters are required if the format of the data is different between the two data stores, and if the existing providers or your custom providers do not expose data in OData Sync format. For example, if one store exposes ADO.NET DataSets and the other exposes data in XML format, the developer can create a pair of data converters and specify these when setting up the synchronization process. If there are many data store formats, it may be easier to create data converters that convert to and from a common format, and then to use the appropriate pair for each synchronization session.

Events are raised during the synchronization process to indicate the individual changes occurring and any errors that arise (including conflicts if the data in both locations has changed). The application can handle these events to provide status information to the user, manage conflicts by applying business rules (such as "latest change wins"), and to display the results.

For a useful introduction to the synchronization process and details of the way that synchronization metadata is used, see "Introduction to Microsoft Sync Framework" on MSDN (http://msdn.microsoft.com/en-us/sync/bb821992.aspx). This article discusses the metadata used by the framework, the synchronization flow, and includes examples of synchronization with and without update conflicts.

Synchronization for Windows Azure and Windows Phone 7

Version 3.0 of the Sync Framework includes providers for Windows Azure and Windows Phone 7 that can exchange synchronization messages using the OData Sync protocol. The samples available for the Sync Framework include examples that use these providers. The Windows Phone 7 provider uses isolated storage on the device to hold the local data and the synchronization metadata as a series of collections in the form of a local context.

The Sync Framework includes a utility named SyncSvcUtil that developers can use to create both a set of entities that extend the IsolatedStorageOfflineEntity base class to define the data types, and a class that extends the IsolatedStorageOfflineContext class to interact with stored data.

The IsolatedStorageOfflineEntity base class exposes properties used by the Sync Framework provider to define and monitor changes to the local data. For example, it exposes the entity state (such as Unmodified, Modified, and Saved) if the change encountered a conflict or error or if the local entity is a tombstone (because it was deleted on the device). The IsolatedStorageOfflineEntity type also exposes events that indicate when the entity value changes and a method to reject the changes and restore the original version.

The concrete type created by the SyncSvcUtil that extends IsolatedStorageOfflineEntity exposes application-specific entity types based on the schema of the data source with which the device will synchronize. The application on the device uses these entity types when accessing and interacting with the data that is stored locally.

The IsolatedStorageOfflineContext base class exposes properties, methods, and events that manage the synchronization process and indicate its progress when synchronization is occurring. These include methods to initiate a session, add and remove items, and initiate synchronization; properties that expose collections of errors and conflicts; and events that indicate the progress and result of the process.

The concrete type created by the SyncSvcUtil utility that extends IsolatedStorageOfflineContext exposes the schema for the stored data, collections of the stored entities, and methods that allow the application to add and delete items in the collections. The application on the device uses these methods and properties to display and manipulate the data that is stored locally.

To learn more about using the Sync Framework with Windows Azure and Windows Phone 7, see the following resources:

These and all links in this book are accessible from the book's online bibliography. The URL to the bibliography can be found in the preface, in the final section, entitled, "Where to Go for More Information."




Show: