Programming .NET Framework 3.5 : Using Data Synchronization Services (part 1)

2/27/2012 9:43:41 AM
1. Understanding Data Synchronization Service Requirements

A Data Synchronization Service is a Web service. Like any Web service, it is accessible via a URL and contains a class of functionality whose methods can be invoked via a Web protocol. The standard for Data Synchronization Services, that is, the interface definition specified by the .NET Framework, mandates only four methods.

  1. ApplyChanges: Receive all changes that have occurred on the client since the last exchange of data (i.e., since the last synchronization) and apply them on the server.

  2. GetChanges: Retrieve all changes that have been made by other uses on the server since the last synchronization and deliver them to the client.

  3. GetSchema: Retrieve schema information regarding the tables that participate in the synchronization from the server and deliver it to the client.

  4. GetServerInfo: Retrieve the name and description of the tables that participate in the synchronization from the server and deliver them to the client.

Normally, the service combines the first two methods in the preceding list into a single method call named Synchronize.

Although few in number, these methods represent an extensive amount of functionality, for implied in ApplyChanges and GetChanges is concurrency conflict detection. That is, the service must work in conjunction with the client application and the server-side data store to detect whether the client is attempting change data that was modified on the server by some other user as it was being modified on the client. Furthermore, the service should give the client a choice between the following.

  • The modification of the row does not occur and the client is so notified.

  • The modification of the row does occur at the server, regardless of the impact on the changes made by the other user.

The second option is often referred to as “Last updater wins,” but “Forced update” is a more correct phrase.

For a data store to be able to provide concurrency conflict detection, it must be able to track changes. Any data store that is to be used by a Data Synchronization Service must be able to do this. SQL Server CE 3.5 SP1 and SQL Server 2008 have a built-in change tracking capability that was designed with Data Synchronization Services support as a requirement. SQL Server 2005, on the other hand, has no built-in change tracking support.

This is a less than ideal solution. Moving the application’s back-end component to a new server means running the scripts at the new server (and possibly running the undo scripts at the old server). Many of you have probably added some form of change tracking to a SQL Server database in support of an application that you have developed and have encountered similar database maintenance overhead. In our upcoming sample, we will use SQL Server 2005 as our server-side data store. This will allow us to see the Designer-generated SQL code and the impact that it has on the Northwind database.

Interestingly, the change tracking needed for Data Synchronization Services does not require that a before and after image of a modified row be maintained; only that the time and user of the modification be tracked. The image of a deleted row, however, must be maintained in the database. If the client submits, and is determined to force acceptance of, an update of a row that was concurrently deleted at the server, that row first must be undeleted at the server and then the client’s update applied. This can happen only if the deleted row is still available at the server. Rows that have been deleted from one table are normally maintained in a separate table that is referred to as the tombstone version of the original table.

Given this background information, we can begin development of our own Data Synchronization Service and a .NET Compact Framework application that will be a client of that service.

2. Building a Data Synchronization Service

For our Data Synchronization Service we’ll implement a very simple example; one that updates some of the Customers of the Northwind database. We develop our service, and its client application, through a specific sequence of steps. Not only is this sequence probably the easiest way to do the development, but it also helps to illustrate the nature of a Data Synchronization Service and its relationship to the .NET Compact Framework client application. Specifically, we will do the following.

Create a Visual Studio 2008 solution that contains a Windows Communication Foundation (WCF) Service Library project and a Smart Device project. The former will evolve into our Data Synchronization Service; the latter will be our client application.

Use the Sync Services Designer Wizard to generate code, some of which will be inserted in the service application and some into the client application. Most importantly, the code that is inserted into the client application will talk to two synchronization providers: one that connects to SQL Server CE on the device and one that connects to the server-side data store.

Modify and complete the service application. Some of the changes we must make, such as specifying the URL, are applicable to any Data Synchronization Service; others, such as the Web binding to be used, will make the service accessible to a mobile device client.

Once the service definition is complete, turn to our client project and add a Web reference to that service, thus generating proxy code in our client application. This code, also, will need to be modified, mainly because it will contain class definitions that we do not want; class definitions that conflict with definitions that are already in the Framework Class Library.

Once our client has the correct code for accessing the service, add the core functionality of our application.

Let us begin.

Note: Required Software

Before starting development of a Data Synchronization Service and its consuming Smart Device client application, ensure that you have the necessary software on your development machine. You’ll need Visual Studio 2008 SP1 or later for development. You will also need Microsoft Synchronization Services SP1 (Devices) or later. (Support for desktop clients comes with Visual Studio 2008, but for .NET Compact Framework clients you will need this separate download.) For the server-side data store, SQL Server 2005 or later is needed; SQL Server 2008 makes life easier; an Express version of either will do just fine. And lastly, for the client-side data store you’ll need SQL Server CE 3.5 SP1 or later.

2.1. Beginning Development of Both Projects

We begin the actual development by creating a solution, named DataSyncDemo, containing two projects: a Visual C# / WCF / WCF Service Library project named SyncClnt and a Visual C# / Smart Device / Smart Device Project / Device Application named SyncServ. Figure 1 shows the resulting Solution Explorer window.

Figure 1. Server and Client Projects in the Same Solution

As we can see from Figure 1, we have a device application with a default form defined and a service application with a default WCF Service and contract defined. These last two are of no use to us, and we will delete them shortly. What we want is not a WCF Service but rather a Data Synchronization Service. To have Visual Studio generate the starter code for us, we need to invoke the Configure Data Synchronization Wizard. To do that, we need to add a Local Data Cache item to our project.

“Which project?” you ask. Normally, it would not matter which project, for the wizard will generate code into both projects, which is why we needed both projects to be in the same solution. Whenever you are adding a Local Data Cache item, keep the following in mind: A Local Data Cache item consists of both server-side and client-side components. It is easiest if you think of yourself as adding the Local Data Cache to the entire solution, not to a single project within that solution.

In actuality, the term Local Data Cache is misleading. It is not a memory-resident cache such as the Web application Cache object is, for its data is maintained in a SQL Server CE database. It is not just data, for it includes the components necessary to synchronize that data with the back-end data store. And although it resides on the local device, it is frequently communicating with the server and bringing data that originated on the server down to the device. Perhaps the best name would be the class name of its keystone object, SyncAgent.

In our situation it does matter to which project we try to add the Local Data Cache, for Smart Device projects do not provide you the option of adding a Local Data Cache item. Therefore, we must add a new Local Data Cache item to the service project, as shown in Figure 2.

Figure 2. Adding a Local Data Cache Item

This will result in the appearance of the Configure Data Synchronization Wizard, shown in Figure 3. First, we make our Server Connection selection to choose the connection to the server database. You probably have a data source connection already defined within your development environment for the target database. If so, select it; if not, select New and create one. Once we have made our selection, the Client Connection drop down and the Add button become enabled. We can either select a client connection or have a new one created for us. If we select New, the wizard will not ask us for further information; it knows where the client-side database will be located, on the device, and it knows that it will be a SQL Server CE database. The wizard will simply generate the code to create and use a SQL Server CE database file on the device.

Figure 3. Configuring Data Synchronization

The “Use SQL Server change tracking” option is disabled because we chose a SQL Server 2005 database rather than a SQL Server 2008 database. Since SQL Server 2005 does not have built-in change tracking, the option is disabled.

If the selected SQL Server 2005 database has not had the necessary scripts run against it to create a change tracking capability, the word “(New)” will appear next to the choices in the Server Location drop downs. If this is the case, when we finish using the wizard, it will generate SQL scripts and display a dialog asking us whether we want the scripts run now and where we want them stored.

If asked, the wizard will modify the selected Northwind database, adding/altering the tables and triggers necessary to provide a change tracking capability sufficient for use with a Data Synchronization Service.

Click on the Advanced chevron and you will be able to tell the wizard that you want code generated for both the service and the client. Be sure to select the correct projects in the Server Project and Client Project drop downs. When you have done this you should be in the state shown in Figure 3.

At this point, we can click on the Add button and begin to specify which server-side tables will participate in the synchronization and provide some information about how the rows of each are to be synchronized, as shown in Figure 4.

Figure 4. Specifying Tables

When we click OK twice to dismiss both dialog boxes, the Designer adds some references and writes some code into both projects. We cannot see what that code is yet, for a new dialog box has appeared; but some of the newly added code relates to the addition of the earlier mentioned SQL Server CE database file onto our device store. Since the wizard is providing for the storage of data on the client, why is the new dialog box (see Figure 5) offering to include a data set on the client as well? The answer is, because data tables are data-bindable, whereas a database is not.  The wizard is merely offering to include an ADO.NET typed data set in your client project so that you can more easily display synchronized data to the user by moving it from the SQL Server CE database into a data set and then binding the data tables to controls.

Figure 5. Providing a Client-Side Data Set

The fact that this dialog is presented as part of adding a new Local Data Cache item to the Data Synchronization Services project hides the fact that the data set will be added to the client project, not to the Data Synchronization Services project. Always remember, a Local Data Cache item consists of both service components and client components.

We’ll accept the offer of a typed data set in our device client application and dismiss the dialog. A look at the Solution Explorer window, shown in Figure 6, reveals that much has been added to our projects.

Figure 6. Viewing the Designer-Added Components

On the client side, references to two Microsoft.Synchronization libraries have been added. The SynchProvider and SynchAgent classes (more on these in a minute) have been added into CustCache.Client.sync. Also added to the client project is the SQL Server CE database file and the ADO.NET typed data set. What has not been added is the proxy code necessary for calling the service. This cannot be done at this time because we have not yet finished developing the service; therefore, a Web reference to the service cannot be set, and therefore the proxy cannot be generated.

The SynchProvider and SynchAgent classes that are defined in the newly added CustCache.Client.Designer.cs file know how the data is to be synchronized and where it is located on the device, for we provided that information to the wizard. What they do not know is what Data Synchronization Service will be used. That will not be known until we have completed the service project, run it, and set a client project Web reference to it. In other words, the SynchProvider and SynchAgent classes will work in conjunction with the to-be-written Proxy class to synchronize data between device and server. In production, if the service is moved to a different server, the SynchProvider and SynchAgent classes will remain unchanged; the Proxy class, or at least its URL property, will need to be updated.

At this point, the Configure Data Synchronization Wizard has written as much skeleton code as it can. We need to finish developing the service and then complete the client.

  •  # BlackBerry Java Application Development : Networking - HTTP Basics
  •  Mobile Phone Game Programming : Analyzing 2D Sprite Animation
  •  Mobile Phone Game Programming : Understanding Animation
  •  Synchronizing Mobile Data - Using Merge Replication (part 2) - Programming for Merge Replication
  •  Synchronizing Mobile Data - Using Merge Replication (part 1) - Using Good Design to Avoid Synchronization Failures
  •  Windows Phone 7 Advanced Programming Model : Advanced Data Binding (part 4) - Data Bind to Anything
  •  Windows Phone 7 Advanced Programming Model : Advanced Data Binding (part 3) - Showing Progress & Lazy Load Images
  •  Windows Phone 7 Advanced Programming Model : Advanced Data Binding (part 2) - Syndicated Services
  •  Windows Phone 7 Advanced Programming Model : Advanced Data Binding (part 1)
  •  Beginning Android 3 : The Input Method Framework - Fitting In
  •  Mobile Application Security : Mobile Geolocation - Geolocation Methods & Geolocation Implementation
  •  Mobile Application Security : SMS Security - Application Attacks & Walkthroughs
  •  iPad SDK : Popovers - The Stroke Width Popover
  •  iPad SDK : Popovers - The Font Size Popover
  •  Beginning Android 3 : The Input Method Framework - Tailored to Your Needs
  •  Beginning Android 3 : Working with Containers - Scrollwork
  •  Mobile Application Security : SMS Security - Protocol Attacks (part 2)
  •  Mobile Application Security : SMS Security - Protocol Attacks (part 1)
  •  Mobile Application Security : SMS Security - Overview of Short Message Service
  •  iPad SDK : Popovers - The Font Name Popover (part 2)
    Top 10
    Nikon 1 J2 With Stylish Design And Dependable Image And Video Quality
    Canon Powershot D20 - Super-Durable Waterproof Camera
    Fujifilm Finepix F800EXR – Another Excellent EXR
    Sony NEX-6 – The Best Compact Camera
    Teufel Cubycon 2 – An Excellent All-In-One For Films
    Dell S2740L - A Beautifully Crafted 27-inch IPS Monitor
    Philips 55PFL6007T With Fantastic Picture Quality
    Philips Gioco 278G4 – An Excellent 27-inch Screen
    Sony VPL-HW50ES – Sony’s Best Home Cinema Projector
    Windows Vista : Installing and Running Applications - Launching Applications
    Most View
    Bamboo Splash - Powerful Specs And Friendly Interface
    Powered By Windows (Part 2) - Toshiba Satellite U840 Series, Philips E248C3 MODA Lightframe Monitor & HP Envy Spectre 14
    MSI X79A-GD65 8D - Power without the Cost
    Canon EOS M With Wonderful Touchscreen Interface (Part 1)
    Windows Server 2003 : Building an Active Directory Structure (part 1) - The First Domain
    Personalize Your iPhone Case
    Speed ​​up browsing with a faster DNS
    Using and Configuring Public Folder Sharing
    Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing OCS 2007 (part 1)
    Google, privacy & you (Part 1)
    iPhone Application Development : Making Multivalue Choices with Pickers - Understanding Pickers
    Microsoft Surface With Windows RT - Truly A Unique Tablet
    Network Configuration & Troubleshooting (Part 1)
    Panasonic Lumix GH3 – The Fastest Touchscreen-Camera (Part 2)
    Programming Microsoft SQL Server 2005 : FOR XML Commands (part 3) - OPENXML Enhancements in SQL Server 2005
    Exchange Server 2010 : Track Exchange Performance (part 2) - Test the Performance Limitations in a Lab
    Extra Network Hardware Round-Up (Part 2) - NAS Drives, Media Center Extenders & Games Consoles
    Windows Server 2003 : Planning a Host Name Resolution Strategy - Understanding Name Resolution Requirements
    Google’s Data Liberation Front (Part 2)
    Datacolor SpyderLensCal (Part 1)