Offline Microsoft Silverlight Applications

At Tech Ed US in Atlanta this week I presented a session for building Offline Silvelright Applications. The session covered an end to end solution for developing applications, building on the work we’ve done with relative Sync technologies, local storage and the common feedback we’ve head over the last several years of working on these technologies.

Messaging Based Sync
The concepts presented here are just that, concepts for things we’ve been brainstorming a bit and not reflective of products we’re shipping. The idea is to bridge the gap for the “data sync” scenarios that we continually received feedback that it wasn’t very “service oriented”. It also addresses the problems for where to get data when online.
In the traditional sync scenario, we would have said always fetch your data locally, even when online and just keep synching the local cache. This is the traditional Outlook model. The problem with this approach is most LOB data isn’t “Outlook like”. Meaning, most LOB data isn’t as cleanly partitioned. In email, these are your emails. Nobody else edits your emails. In fact, you don’t really “edit” your emails either. You receive messages, view them, and create new messages..
In LOB data, you may have data that you’re viewing, but someone else edits it. In our sample, we’re assigning appointments to insurance adjusters. Someone may change that appointment, or the details of the claim.

Active/Passive Caching
The concept presented here mixes active caching and passive caching. Depending on the data, when online we look at the server/service for the data, but cache it locally. When offline, we read from the local cache for data we know changes often.
For reference data, we always read from the cache, as we don’t expect the list of states or company codes to change that often. This reduces server workload as we only periodically ask for changes, and it speeds the local processing.

Local Storage
Other topics that I didn’t have time to delve into is the local storage scenario. There are many solution for local storage, and for this presentation, I chose to use Sterling DB.
I hope you find the deck and session helpful

Jason Shaver, a PM on our Silverlight team did most of the development for the messaging portion of the Insurance Adjuster application and I know he’s interested in getting feedback on the approach.
Insurance Adjuster Sample on CodePlex


Video recording of the session



Comments (4)

  1. cristoph says:

    I just  don't understand…what you are saying in this presentation is basically what SyncFramework 4.0 do: service oriented Sync, everything related with Sync is stored on server, anchor based Sync, tombstoning, etc etc. by ODataSync protocol. Why there is no word in this presentation about SyncFramework 4.0 (…/details.aspx) ?

    I'm confused, teams inside MS not communicate each other? :O or I'm missing something?

  2. Steve Lasker says:

    Hi Cristoph

    Thanks for bringing this up. In a 1 hour  talk, it’s hard to bring up all the points and caveats. Being Tech Ed, I wanted to stay on the actionable things people can do today. For instance, I really wanted to spend more time on the local data storage options. Three’s not perfect solution today, and wanted to talk more about the various options and debates (Relational or Object) for instance.

    Sync Concepts

    I’ve had the pleasure of working on many of our sync products, including Sync Services for, Sync Framework and other components like SQL Server Compact (SQLce) and some early work on sync enabling Astoria offline which is why some of the concepts discussed, like Anchors and Tombstones look familiar. I wanted to make sure we are leveraging the great work done by various teams. That said, since the talk was at Tech Ed, as opposed to Mix or PDC, I felt I needed to focus on what developers can build today, but it’s actually not that simple, so let me explain a bit.

    Sync Framework:

    As the Sync Framework team discussed here they’re focused on cloud sync features and unfortunately have indefinitely suspended the release of future versions of the Sync Framework.

    OData Caching

    There is some great work happening here, which is leveraging the designs of the Sync Framework, and I do encourage people to take a look and give it a try. In fact, OData can be incorporated into the pattern I proposed. At least for the download. A this point, OData doesn’t address changes made locally, however, I’m not sure it should. See below for “Sync Isn’t Service Friendly”. The main reason I didn’t directly use it for the talk was it’s not yet shipping and wanted to focus on what people could do today, but there’s more:

    Messaging & Services

    The main concept I wanted to present here was the hybrid approach to Active Caching, Passive Caching and “Messaging”*. There were two main factors that contributed to this evolved design pattern:

    • Sync isn’t service friendly
    • How to minimize latency of data when online

    Sync isn’t service friendly

    After many years of feedback from customers that “Sync” is neither service friendly, nor can they typically get those services exposed directly over their data, I’ve been wanting to take a different approach. If building a system from scratch, one could likely build a “sync service” exposing their data with anchors and/or knowledge. The challenge I continually heard was very rarely did people have green field projects, they can’t expose their data directly to services as they typically aggregate data from different systems or reshape the data, or they just had fundamental issues with the 1:1 mapping of their database and the data returned from the services. The bigger challenge was the data changed locally and how it gets sent up to the server. In Sync Services for, we had several client and server events for dealing with conflicts. The problem is this didn’t mesh with the rest of their existing services for uploading changes, which also dealt with conflicts.

    Trying to convince the DBA, systems/SOA architect, and various other stake holders in a company to make these sync changes to their service architecture was a constant challenge It seemed a more digestible approach to enhance existing services with anchors. If a service already returns customers, appointments, orders, products, states, etc. is it easier to simply add an “anchor” parameter to those existing services? Then, in the result, add a collection of deletes, if needed?

    Using this approach, we still maintain the core concepts of sync, anchors, and even “knowledge”, but can incorporate it into existing services.

    Latency of data when online

    The traditional sync pattern we had proposed was to always work offline, then sync as often as you felt the data would change. Hmmm, how to predict changes? Reference data, not a big deal. There are various approaches to trigger a refresh of infrequently queried data. However, what to do with those Appointments, Reservations, or other things that may not change that often, but when they do, you want to get the updates to your users ASAP. Or, more specifically, when they want to view that data, if they’re online, to provide them the latest view.

    You could just “sync” very often, which means when you’re connected you’re probably putting a bigger load on your system as you keep asking “what changed”, “what changed”, “what changed”. Even if you’re users aren’t actually looking at the data. When you’re online, users are perfectly fine with the round-trip response time. This would be difficult to do in a sync world without a duplex type connection, which kills scalability.

    So, this is where we took a slightly different approach. We still do the periodic “sync” of data. Let’s say every 15 minutes. But, when you’re online, and your users ask for a specific Appointment, or even the list of Appointments, why not ask the server like you normally would? Then, just cache the results, on top of the previous baseline sync.

    Now, there are still plenty of optimizations here, but this pattern of utilizing requests/”messages”, and routing them, caching them locally and surfacing them to the view model felt like a better approach that’s addressed much of the feedback we’ve received over the sync patterns. But, then, that’s the point, to solicit feedback and similar to MVVM, evolve the pattern.


    I will add that I do struggle with calling the requests, messages as they contain behavior. And perhaps that’s what they should be called, requests, with a request manager.

    Continued Feedback

    Please continue the feedback. To provide Jason an opportunity to address the feedback directly, I would suggest having the discussion on codeplex discussion list.



  3. Michael Murdock says:

    Steve I attended the Offilinet Applicaition with silverlight, You said you were going to post the source code for what you went over I have not seen it on the teched site or here.


  4. Steve Lasker says:

    Hi Michael,

    Might have gotten lost in the text above, but it's on codeplex at


Skip to main content