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.
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.
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. http://sterling.codeplex.com/
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