Webservice architecture for online/offline applications

I'm currently writing a utility application to keep track of CodeSnippets, Favourites Links etc and, as a feature of the application, users will have the ability to take the application offline for extended periods of time and still be able to fully maintain the data while in the disconnected state - i.e.: Add/Edit/Delete/Read - not dissimilar to what the TaskVision application does.  Users may also have more than one client interface to the application - consider a WindowsForms app at work and a WebForms app running on PocketPC. 

For the purposes of discussion consider this scenario:

The application that I'm building will manage all of a users code snippets.  Code snippets appear in Categories, and Categories also be broken into sub-categories.

    - VB
        - StringHandling
            - snippet A
            - snippet B
    - C#
        - Conversion
            - snippet C
    - Misc
        - Sorting
            - snippet D

My biggest issues were: how to manage concurrency between multiple, disconnected clients and how to minimize the amount of data that I would be sending across the wire?  From what I've seen, it's not such an issue with TaskVision because of the kind of data that is being exchanged.  The data also has the potential to get big'gish, for example, given 300 snippets at an average size of 1K (including the snippet and other attributes) you'd be looking at serializing nearly .5Mb across the wire for all snippet and category data.

For those that have developed an interest in this type of problem, I've documented my chosen approach and you can view it here:

http://www.flws.com.au/MergeConflicts.html

...basically, it involves a hierarchically structured DataSet being passed between a central Service and the remote clients. Record locking conflicts are resolved through the use of an incrementing key and the size of the dataset is reduced by only passing data that has changes.  Conflicts are reported to the clients in exactly the same manner as with the TaskVision applciation, that is, via ROWVERSION'ing on the rows of the DataTables.

I hope to create a more formal "spec" of the architecture and prototype it over the coming week or two.

6 Comments

  • Ever consider using GUIDs for ids instead? Then, you could generate/use them client side and wouldn't have to updating relations, etc. Identity fields are such a pain when you are working with disconnected recordsets.

  • Jesse... thanks for the advice! I hadn't considered it, in fact I haven't really decided on that *or* where the "Version" number will come from yet but your idea of using GUID's for the ID sounds pretty solid.

  • No prob. As an alternative to version number, you might consider a TimeStamp column (just have SQL auto inject it like: "INSERT into Table (..., TimeStamp) Values (..., GetDate())"). Then, you don't have to worry about version increments, etc. Either way can work, but the TimeStamp is probably less of a hassle...plus, you get to know the last modified date, which might come in handy some time.

  • Well, my idea for the "Version" is that it is not "entity-specific". In other words, each user has a current version for the entire application. You can see why I want to do it that way if you peek at my diagrams and notice how the user sends the Version back to the server and that is the determining factor for deciding collisions on *all* tables.

  • A global version could be a pain for dealing with concurrency. With a decent amount of users, it would gaurentee that your users would only be able to modify data while online. Usually, you want to make concurrency as granular as possible, because users aren't very good at dealing with concurrency violations (and they are frustrating as hell too).

  • hi

    I am designing one client server application which need this kind of online/offline functionality.Please let me know how to hndle the sam ein design.Also how to deal with concurrancy issues.

Comments have been disabled for this content.