Making Applications Work Offline

Several weeks ago, I posted some thoughts about AJAX in particular and web applications in general.  I talked about the fact that web applications trade user productivity for ease of deployment.  I bring this up because I want to talk about something that has always puzzled me. 

Periodically, customers ask me how to make web applications work offline.  They want to install a web server on a user's laptop so that, if they are disconnected, the users can point their browser at the local web server and keep working.  This seems to me to provide the worst of the web world (the less productive user interface) and the worst of the rich client world (all of the code on every server now has to be deployed to each of the laptops).  It seems to me, that if you are going to have to deploy code to the client anyway, why not deploy a rich client app and make it work online as well as offline?  That way, you can provide a better experience for your users.

The trick to writing an application that works offline as well as online (regardless of whether that application is web based or client based) is dealing with data.  You have to maintain a cache of the data on the laptop.  In addition, when the laptop is offline, you have to maintain the changes in a queue so that they can be passed to the server when connectivity is re-established.  The smart client application block provides guidance for dealing with these issues.  It talks about both a database driven approach (which uses replication) and a services based approach (which uses message queuing). 

SQL Server 2005, if you are able to use it, introduces a new feature, SQL Server Service Broker, which is a message queue inside the database.  This provides an option for combining the database driven and services based approaches.  SQL Server Express, a freely re-distributable version of SQL Server 2005, provides the ability to use service broker, as long as messages are sent to a licensed (non Express) version of SQL Server 2005.  Because of this, it is a great option for making applications work offline.


Comments (4)

  1. First just wanted to say great article. Looks like this will really get anyone started in the exact right direction where disconnected access is a concern.

    I wanted to say, though, that I’ve heard this question a lot lately.

    Generally speaking, companies are not entirely concerned about the user experience (especially where intranet applications are concerned). The primary concern here for the people in charge is cost. They can’t see the value in paying for the same application twice.

    In most cases this starts out as a web application for external and internal users, but then morphs because they suddently discover that they have roaming users that are often in a disconnected environment. They are faced with two choices: get the application they just paid for on the PC locally somehow (probably with the use of copius amounts of duct tape) or pay for the application all over again for their roving band of twenty minority, but extremely valuable, employees.

    This is the area that I think MS needs to focus its energy. The driving force in the industry is always cost. "Snazzy" can be sold to a degree, but this is most likely not your customer’s motivation for asking such a question. Your proposed solution is obviously what you would want to do in a money-is-not-an-object situation, but what about those other pesky financial states.

    When Microsoft figures out how to get the rich client experience to the customer with the deployment cost of the web application, you’ll never hear this question again.

  2. I’ve receieved several great comments, both online and offline, regarding my previous posts around smart…

Skip to main content