The article is a follow up article to Introduction to ADO .NET Sync Services and takes a look at how easily we can convert a two Tier Sync application to N tier using WCF services. The ability to sync up your data without connecting to the main database is a great value and opens the door to many complex architecture implementations. There are many examples on sync services online but most of them are in C#, hence here I am just trying to have very basic examples for the VB community.
Background
In the previous article we saw how easily we can create an occasionally connected smart client application using ADO.NET Sync services, but it may not work in many architects where your database server is not exposed to the clients for security reasons or due to some other restrictions like network restrictions. In those cases you need to sync the client using an intermediate service. The beauty of the Sync Framework is that it makes even that task a lot easier, you can communicate on any channel using any protocol and still sync up your data with the main data source in many configurable ways.
Using the Code
In this example I will continue from where we left in Introduction to ADO Sync Services, and you can download the project from the article and continue the steps below.
In the current project (2 tier example) we have a client connected to the main SQL server and syncing up directly. Both the server sync provider and client sync provider are residing on our client project. In order to make it N tier all we have to do is move the server sync provider out of the client project into a separate service.
Architecture of 2 Tier Sync Applications
Architecture of N Tier Sync Applications
As you can see from the architecture above the Server Sync Provider and Sync Adapter has been moved to separate service and the client Sync Agent talks with Server Sync provider using service proxy using any transport protocol.
Now let's see how we can convert our current project. First add a new project to our solution of type WCF Service Library and name it WcfSyncService1 (ok you don't have to name it WcfSyncService1, you can call it Mickey mouse or whatever you want).
Now on the client project, double-click the LocalDataCache1.sync to open it. This file was generated by a studio when we added the local data cache to our project. Click the Advanced options to expand the options and change the Server project location to WCFSyncService1. In an earlier project both server project location and client project location were SyncService2Tier.
As soon as we click OK, the wizard moves the server sync provider to the WCFSyncService1 project by creating two new files, LocalDataCache1.Server.Sync and LocalDataCache1.Server.SyncContract.vb
To make our life easy, the service end points and the behavior definitions are provided in the LocalDataCache1.Server.SyncContract.vb file. All we have to do is uncomment it, copy it, and move it to appropriate section of the App.config file in our service project. Move the service end points under <services> under <system.serviceModel> and behavior section under <serviceBehaviors> under <behaviors>. Remember to make one change; the base address will be defined as localhost:8080/LocalDataCache1SyncService/ you may want to remove the port number from the URL as many times we have some other services running on port 8080, in which case it will give us an error while running the service. The best option for now is to remove the port number from the URL and leave it as just localhost/LocalDataCache1SyncService/
Now the last manual thing we have to do is to move our custom written code from the client project to our service. We had written our custom conflict handling code under LocalDataCache1ServerSyncProvider in our client sync provider (LocalDataCache1.Sync). View code for LocalDataCach1.sync in the client project and cut past the following code to LocalDataCache1.Server.sync. The studio does not automatically move this code to service as it is custom code written by us.
Partial Class LocalDataCache1ServerSyncProvider
Private Sub LocalDataCache1ServerSyncProvider_ApplyChangeFailed _
(ByVal sender As Object, _
ByVal e As Microsoft.Synchronization.Data.ApplyChangeFailedEventArgs) _
Handles Me.ApplyChangeFailed
e.Action = Microsoft.Synchronization.Data.ApplyAction.RetryWithForceWrite
End Sub
End Class
Let's make our WCF project the start up project and run it. Copy the address for the service by right clicking on the running service.
Add a new service reference to our client project. Now set the remote provider for our server sync provider to our new service proxy. For this, right click the LocalDataCache1.sync on the client project and do View code. Add this definition under OnInitialized.
Me.RemoteProvider = New Microsoft.Synchronization.Data.ServerSyncProviderProxy(
New ServiceReference1.LocalDataCache1SyncContractClient)
And you are done. Just set your client project as a startup project and run it. Remember to keep your service running while you are running the client project. You have an N tier smart client application which will run in occasionally connected environment and it will sync data on demand using the WCF service.
Points of Interest
This is a real simple example showing how you can utilize services to sync up your client data with master database. I will try to post more articles on sync services using VB.NET and exploring more advanced features and complex scenarios.
