locked
Custom provider: Sync Services for ADO.NET 2.0 vs. Sync Framework? RRS feed

  • Question

  • I have data in a SQL Server 2008 database, and I need to sync it via a proprietary REST-like web API to a similar (though not identical) schema.  I know I need to write a custom provider.  But, it's not clear to me which kind is best to write, one that uses the Sync Framework (i.e. subclassed from KnowledgeSyncProvider, using SyncOrchestrator), or the Sync Services (subclassed from ClientSyncProvider, using SyncAgent).  It looks like you can't mix-and-match them (i.e., using a KnowledgeSyncProvider against a (for instance) DbServerSyncProvider).

    I'm brand new to Sync, turning to it when I realized that writing a bunch of sync logic would be duplication of effort.  I assume that leveraging change tracking built into SQL 2008 would tilt me in the ClientSyncProvider direction, but, it's unclear to me whether writing 2 KnowledgeSyncProvider providers (1 for the API, 1 to use SQL change tracking) is easier than writing 1 based on ClientSyncProvider.

    A little more background:  the local SQL Server is the server in this situation, and the web API is the client.  Data will be flowing both ways, but, there will never be conflicts to resolve (data after it reaches it's destination will always be read-only).

    Thoughts?

    Thanks,
    Brad
    • Moved by Max Wang_1983 Thursday, April 21, 2011 1:21 AM forum consolidation (From:SyncFx - Technical Discussion [ReadOnly])
    Tuesday, April 21, 2009 6:28 PM

Answers

  • Yes, Mike, I believe you are correct.  Thanks for posting!  I was going to say what you said, after I asked the question and did more investigation, and got distracted when I was composing a reply and didn't return.

    Yup, they have different inheritance hierarchies.  Actually, I did go with subclassing Microsoft.Synchronization.Data.ClientSyncProvider for my REST-ish API.  If I were to guess, I'd say that my ClientSyncProvider subclass ended up being less code than writing a SQL-Server-2008-Change-Tracking-aware KnowledgeSyncProvider (if that kind of KnowledgeSyncProvider is even possible to write).  I say that because the hardest part was dealing with anchor management.  I assume that would be a non-trivial chunk of code in either provider, so, Change-Tracking-awareness in a KnowledgeSyncProvider would be work on top of that anchor management work.

    I think the hardest part was groking the documentation.  It's unfortunate that they have essentially 2 different stacks to do the same thing, with slightly different usage.  I assume it's because of legacy; after implementing things, I hope that they will unify the stacks, which will simplify things.

    Although the above has some what-ifs, what I do know is that my ClientSyncProvider is using Change Tracking and talking to my REST api successfully!

    Thanks again,
    Brad
    • Marked as answer by bradser Wednesday, July 8, 2009 6:59 PM
    Wednesday, July 8, 2009 6:59 PM

All replies

  • Hi -

    Even the DbServerSyncProvider is a KnowledgeSyncProvider and as such should be able to synchronize against any other KnowledgeSyncProvider. I am posting a link to another post that should help -

    http://social.microsoft.com/Forums/en-US/uklaunch2007ado.net/thread/35d4deb8-a861-4fe3-a395-d175e14c353f/

    Thanks
    Deepa
    Deepa ( Microsoft Sync Framework)
    Tuesday, May 5, 2009 8:36 PM
    Answerer
  • Hi, I'm interested in the answer to this question too.

    Sorry, I dont want to seem ungrateful for this answer, but it really doesn't make much sense to me...

    I don't understand how the link above relates to the question asked.  Plus in Sync Framework V2 CTP2 DbServerSyncProvider does NOT inherit from KnowledgeSyncProvider...

    As you can see from....
    http://msdn.microsoft.com/en-us/library/microsoft.synchronization.data.server.dbserversyncprovider%28SQL.105%29.aspx

    System.Object
       Microsoft.Synchronization.SyncProvider
         Microsoft.Synchronization.Data.ServerSyncProvider
          Microsoft.Synchronization.Data.Server.DbServerSyncProvider

    As such I do not believe it can be used as a provider with the SyncOrchestrator, as the providers need to inherit from KnowledgeSyncProvider.  Also to use the ADO.NET SyncAgent the local provider needs to inherit from ClientSyncProvider, which is probably not going to be ideal for implementing your custom provider.

    I'm not entirely sure, so please correct me if I'm wrong, I think to sync a database provider with a custom provider you're going to need to use the SyncOrchestrator and inherit your database provider from some subclass of the RelationalSyncProvider...

    Inheritance Hierarchy
    System.Object
       Microsoft.Synchronization.SyncProvider
         Microsoft.Synchronization.KnowledgeSyncProvider
          Microsoft.Synchronization.Data.RelationalSyncProvider
             Microsoft.Synchronization.Data.DbSyncProvider
             Microsoft.Synchronization.Data.SqlServer.SqlSyncProvider
             Microsoft.Synchronization.Data.SqlServerCe.SqlCeSyncProvider

    Your custom provider would of course inherit from KnowledgeSyncProvider.

    Mick Lang
    • Proposed as answer by Mick Lang Wednesday, July 8, 2009 7:05 AM
    Wednesday, July 8, 2009 7:04 AM
  • Yes, Mike, I believe you are correct.  Thanks for posting!  I was going to say what you said, after I asked the question and did more investigation, and got distracted when I was composing a reply and didn't return.

    Yup, they have different inheritance hierarchies.  Actually, I did go with subclassing Microsoft.Synchronization.Data.ClientSyncProvider for my REST-ish API.  If I were to guess, I'd say that my ClientSyncProvider subclass ended up being less code than writing a SQL-Server-2008-Change-Tracking-aware KnowledgeSyncProvider (if that kind of KnowledgeSyncProvider is even possible to write).  I say that because the hardest part was dealing with anchor management.  I assume that would be a non-trivial chunk of code in either provider, so, Change-Tracking-awareness in a KnowledgeSyncProvider would be work on top of that anchor management work.

    I think the hardest part was groking the documentation.  It's unfortunate that they have essentially 2 different stacks to do the same thing, with slightly different usage.  I assume it's because of legacy; after implementing things, I hope that they will unify the stacks, which will simplify things.

    Although the above has some what-ifs, what I do know is that my ClientSyncProvider is using Change Tracking and talking to my REST api successfully!

    Thanks again,
    Brad
    • Marked as answer by bradser Wednesday, July 8, 2009 6:59 PM
    Wednesday, July 8, 2009 6:59 PM