Microsoft Sync Framework
Microsoft Sync Framework is a comprehensive synchronization platform that enables collaboration and offline access for applications, services, and devices. It features technologies and tools that enable roaming, sharing, and taking data offline. By using Sync Framework, developers can build sync ecosystems that integrate any application with any data from any store that uses any protocol over any network.
Sync Framework consists of the following technologies, the first three of which can be installed with SQL Server 2008:
Sync Services for ADO.NET can be used to synchronize databases for offline and collaborative scenarios.
Sync Framework core components can be used by Sync Services for ADO.NET to synchronize databases, and can also be used to create synchronization providers for other types of data stores.
Sync Services for FeedSync can be used to synchronize RSS and Atom feeds with data in a local store.
Sync Services for File Systems can be used to synchronize files and folders in a file system.
Metadata Storage Service can be used to store synchronization metadata in SQL Server Compact 3.5.
The rest of this topic provides an overview of Sync Services for ADO.NET and includes a comparison to other Microsoft technologies. For the complete documentation for Sync Services for ADO.NET and the Sync Framework, see the Microsoft Sync Framework Developer Center.
Installing Microsoft Sync Framework and Sync Services for ADO.NET
Sync Framework can be installed by using the Install SQL Server 2008 wizard or by using command line installation options. To install Sync Framework by using the wizard, on the Feature Selection page, select Microsoft Sync Framework. For more information about how to install SQL Server and related components, see Overview of SQL Server Installation.
Overview and Synchronization Scenarios
The ability to support mobile and remote workers is becoming more important for organizations every day. It is very important for organizations to make sure that workers have access to the same information that they have when they are in the office. In most cases, these users will have a laptop, office desktop, smartphone, or PDA. From these devices, users can often access their data directly by using a VPN connection or some other method of connecting directly to the corporate network. For most remote users, this solution is less than satisfactory because of major disadvantages in the following areas:
Network requirements
To enable users to access information, the remote device must have a constant connection to the corporate network while it is accessing data. For some workers, such as those who are working from home, this might not be a problem. For others, such as salespeople who are constantly on the move, this could be more difficult. For example, if a salesperson is visiting a customer and cannot access inventory data because there is no network connectivity, the salesperson cannot effectively do her job.
Data access speeds
In a typical client/server corporate environment, users have high speed networks that enable quick access to information. However, remote workers are usually connected over slow, unreliable wired or wireless networks. By using a typical solution, every piece of data that a user wants must be downloaded every time it is requested because there is no way to persist the data on the device. For example, if a salesperson must download his product list every time he opens his application, the time lag required to populate the application with information could be frustrating.
Single point of failure
With this kind of solution, all users rely on a single server. If that database is not available because of planned server downtime or from server failures, all remote workers will be disconnected from their data.
Server scalability
As more people work remotely, the performance of the corporate servers will be affected, and more hardware might have to be added.
Occasionally Connected Applications
An alternative to the solution described in the previous section is to implement an occasionally connected application. An occasionally connected application enables a remote worker to continue to access data. However, unlike the previous scenario in which the user had to access the corporate database directly to get the information she wanted, the information she wants is stored locally on a device. To populate a local database, an occasionally connected application typically uses data synchronization.
Data synchronization consists of the ability to periodically take information that is stored in a client database (such as SQL Server Compact 3.5) and synchronize changes with a server database (such as SQL Server). A synchronization-based solution offers the advantage that a user no longer has to have a constant network connection to access information. Because the data is stored locally, a user has constant access to the data while processing is offloaded from the central database. Additionally, because the speed of the network is no longer a limiting factor, a user can now access the data at the speed of the device.
Sync Services for ADO.NET
Sync Services for ADO.NET enables synchronization between databases. It provides an intuitive and flexible API that enables you to build applications that target offline and collaboration scenarios. Sync Services for ADO.NET enables synchronization between two peers, such as SQL Server databases or between a SQL Server Compact 3.5 client database and any server database for which an ADO.NET provider is available. The API enables you to use all or only some of the components that are provided, depending on the architecture and requirements of an application.
The following illustrations show examples of occasionally connected applications in which data (represented by a green database) is persisted locally on the device of a remote worker. The first example shows a stand-alone database system in which information is stored directly on the user’s device. The second example shows a remote office where information is stored in a workgroup database within this remote office so that multiple local workers can access the data.
.gif "Sync Services Offline Scenario")
A common extension to this type of occasionally connected application is the ability to support collaboration scenarios. These are scenarios in which two databases can be synchronized peer-to-peer without having to go through a central hub. As shown in the following illustration, a remote database is free to exchange information with any other database. This type of solution is useful when remote workers (such as on-site financial auditors) work as a group in a remote location. These workers must often share information amongst each other. However, because they do not have connectivity to the central database, they must share information through some kind of peer-to-peer network.
.gif "Sync Services Collaboration Scenario")
Using Sync Services for ADO.NET with SQL Server
Sync Services for ADO.NET supports databases in the following ways:
In offline scenarios, the client database must be SQL Server Compact 3.5 version 3.5 or later. The server can be any database for which an ADO.NET provider is available.
In collaborative scenarios, each peer database must be SQL Server 2000 Service Pack 4 or a later version.
SQL Server is an enterprise-class database that provides a solid foundation for applications that require synchronization. SQL Server 2008 provides change tracking, one of the most useful features for synchronization developers. Sync Services for ADO.NET provides an API to synchronize changes, but it does not actually track changes in the server or peer database. (SQL Server Compact 3.5 does track changes in the client database.) You can create a custom change tracking system, but this typically introduces significant complexity and performance overhead. We recommend that you use change tracking in SQL Server 2008, because it is easy to configure and provides high performance tracking. For more information, see Tracking Data Changes.
Comparing Sync Services for ADO.NET to Other Technologies
Microsoft offers several technologies that are designed for applications that perform synchronization. Therefore, it is useful to compare Sync Services for ADO.NET to other technologies that are used in offline and collaborative scenarios.
Offline Synchronization
The most significant Microsoft technologies for offline synchronization are as follows:
Remote Data Access (RDA). This is used to synchronize a SQL Server Compact 3.5 database with a database on another edition of SQL Server. For more information, see SQL Server Compact 3.5 Books Online.
Merge replication. This is used to synchronize different editions of SQL Server, including SQL Server Compact 3.5. For more information, see Merge Replication Overview and Selecting the Appropriate Type of Replication.
Use the following table to help you determine which technology is appropriate for the applications that you want to build.
Key feature |
RDA |
Merge replication |
Sync Services |
|---|---|---|---|
Synchronize by using an n-tier or service-oriented architecture |
No |
No |
Yes |
Supports heterogeneous databases |
No |
No |
Yes |
Incremental change tracking |
No1 |
Yes |
Yes |
Conflict detection and resolution |
No |
Yes2 |
Yes |
Easily create data views on the client |
No |
No |
Yes |
Automatically initialize schema and data |
Yes |
Yes |
Yes |
Supports large data sets |
Yes |
Yes |
Yes |
Query processor is locally available |
Yes |
Yes |
Yes |
Automatically propagate schema changes |
No |
Yes |
No |
Automatically repartition data |
No |
Yes |
No |
Use on devices |
Yes |
Yes |
Yes |
1 RDA supports incremental uploads, but downloads are always a snapshot that updates all the data on the client.
2 Merge replication provides built-in conflict resolution; whereas, Sync Services for ADO.NET provides a framework for building a conflict resolution scheme.
Collaborative Synchronization
The most significant technology to compare in terms of collaborative synchronization is peer-to-peer transactional replication, which is used to synchronize two or more SQL Server Enterprise databases. Sync Services for ADO.NET and transactional replication both support peer-to-peer synchronization: transactional replication is best suited for maintaining high availability and scaling read activity across multiple servers, whereas Sync Services for ADO.NET is best suited for applications in which users work collaboratively with the same data.
The following table can help you to determine which technology is appropriate for the applications that you want to build. For more information about peer-to-peer transactional replication, see Peer-to-Peer Transactional Replication.
Key feature |
Peer-to-peer transactional replication |
Sync Services |
|---|---|---|
Synchronize by using an n-tier or service-oriented architecture |
No |
Yes |
Supports heterogeneous databases |
No |
Yes |
Incremental change tracking1 |
Yes |
Yes |
Conflict detection and resolution2 |
Yes |
Yes |
Automatically initialize schema and data |
Yes |
Yes |
Supports large data sets |
Yes |
Yes |
Query processor is locally available |
Yes |
Yes |
Automatically propagate schema changes |
Yes |
No |
Use on devices |
No |
Not in this version |
Use with SQL Server Compact 3.5 |
No |
Not in this version |
1 Sync Services for ADO.NET uses net change tracking, in which the last version of a row is synchronized. With peer-to-peer transactional replication, all changes to a row are applied in order at each peer.
2 Replication provides built-in conflict resolution; whereas, Sync Services for ADO.NET provides a framework for building a conflict-resolution scheme.
Deciding Which Technology to Use
Sync Services for ADO.NET provides the flexibility of a programming model like offline datasets and a richer synchronization feature set like that found in replication. Sync Services for ADO.NET functionality is superior to RDA. Replication is intended for database administrators and is designed primarily to synchronize SQL Server databases. Replication provides significant functionality with configuration available through wizards, stored procedures, and its own API. Sync Services for ADO.NET is intended for developers and supports heterogeneous databases and synchronization over services, such as Windows Communication Foundation (WCF). If an application involves synchronizing with non-SQL Server databases or if an application must have separate components to enable synchronization over different transports or services, use Sync Services for ADO.NET.
For some applications, the decision to use a technology is easy: If you must synchronize a data source other than a SQL Server database, Sync Services for ADO.NET is the solution. If you are a database administrator who wants to configure synchronization without much programming, replication might be a better choice. Ultimately, you must carefully consider the application requirements and determine whether the Sync Services for ADO.NET API is the appropriate technology to use. If you want to move beyond replicating a schema and its data from one database to another, we recommend that you use Sync Services for ADO.NET.