RDN Directions
Sync Framework Sunk?
Synchronization between PCs and servers -- if it were easy would have been solved years ago.
A new developer framework from Microsoft promises to help programmers build applications that synchronize data between PCs and servers, as well as among PCs. But synchronization is inherently difficult, and the increasing availability of high-speed Internet connections -- even in such previously disconnected locations as airplanes -- may render the exercise moot.
For as long as there have been laptop computers, users have looked for ways to take important business data on the road with them, make changes and have their changes reflected when they get back online. Over the years, Microsoft has taken numerous stabs at trying to solve this problem. The most recent attempt is the Microsoft Sync Framework -- a runtime engine that's supposed to provide a general-purpose framework for data synchronization.
The Sync Framework, currently in a preview release, will support a variety of data formats, including ADO.NET data sources, disk-based files and folders, and RSS and ATOM feeds. It also includes a pluggable framework that enables developers to add their own data formats and sources.
Microsoft also aims to enable PCs to synchronize data with other PCs. This would allow, for example, a group of workers to update a shared document as each makes changes.
The goal is to help developers build applications that work like Microsoft Outlook's "cached mode." Introduced in Outlook 2003, cached mode continuously synchronizes a user's messages and calendar items in the background whenever a connection to the server is available. The user may not even notice when a connection is dropped -- new messages and changes to existing messages are queued and automatically submitted when the connection is restored.
A Thorny Problem
But if data synchronization were easy, the problem would have been solved years ago. It took a large team of Microsoft engineers years to build Outlook's cached mode, and that was with Microsoft controlling the client, the server and the protocol used to connect them. What chance does an IT developer have, working in a small team without access to the technical guts of both the client and the server?
There are several keys to making synchronization work. The software must track changes made to the various offline and online versions of the data (including the core CRUD operations: create, read, update and delete). It has to communicate changes between participants and resolve conflicts. And it must process synchronization of potentially large datasets over relatively slow connections, while performing synchronization in the background so as to not interfere with the user's activities.
Conflict resolution is particularly thorny: The Sync Framework must track changes made by each participant in a synchronization session and determine if those changes conflict with one another. Developers can choose from a variety of policies for resolving conflicts, including choosing one change over the other, merging all changes together, or punting by logging the conflict and deferring the resolution until later.
Depending on the data being synchronized, merging may not be an option. Combining two users' changes to an Office document, for example, requires specific knowledge of the internal structure of those file formats. In many cases, the users will have to be involved in making the decision of what data should be kept and what should be discarded.
Furthermore, reliability of data synchronization is critical. Anyone who has ever tried to put their calendar and contacts on a mobile phone has experienced data synchronization gone wrong, including duplicate appointments on a calendar or vanishing contacts. Proper testing is critical to protect the integrity of back-end systems.
Up in the Air
Even if the Sync Framework is successful in providing a robust general-purpose platform for synchronization, it may end up being a case of closing the barn door after the horse has bolted. Virtually every IT organization has already built, or is in the process of building, Web-based interfaces for important business data, even as access to high-speed Internet connections continues to expand. WiFi hotspots are widespread in major cities and all of the major U.S. mobile phone carriers offer fast, 3G services.
Microsoft and others have countered with the "airline scenario," in which a traveling businessperson wants to update sales data during a flight. Obviously, that means synchronizing offline data. But the Internet is reaching there as well. JetBlue is rolling out e-mail and instant messaging access during flights, while others -- including American Airlines, Virgin America and Alaska Airlines -- have plans to offer broader network access for around $10 per flight.
A few years ago, the Sync Framework would have been a surefire hit, but the Web continues to change everything and Sync may turn out to be a technology whose time has come and gone.
About the Author
Greg DeMichillie analyzes and writes about Microsoft's development platform and tools for Directions on Microsoft, a research firm dedicated to tracking Microsoft. He was previously the group program manager at Microsoft responsible for the overall design and feature set for Visual C# and C++. A founding member of the C# language team, DeMichillie was a key contributor to the initial design and development of .NET.