| July 19, 2007 3:07 PM PDT | |
Design mobilized applications to handle network outages transparently. Although many devices include built-in connectivity, that doesn’t mean that they will always be operated in an environment with an available network. Many applications have a built-in dependency on a live network connection that doesn’t become obvious until you try to operate them on a disconnected device.
Implement cached local data, reduced functionality for offline operation, and reliable messaging as needed for the requirements of the individual application. Ideally, the combination of these elements should virtually hide the connectivity state from the user. This goal presents a number of design challenges:
- Should data be cached locally to support offline operation?
- How can we store cached data for later uploading?
- How should the application behave when the user requests an operation?
- Should some operations be disallowed when offline?
- How can we implement reliable messaging to ensure that the application applies updates when connectivity is restored?
Caching Data and Updates Locally: You need to analyze the requirements of the application and examine the types of data it uses. Identify the points within the application where data passes between the server and your application. Is direct server access necessary? Can the application reliably work from cached data or store updates until it is convenient to communicate with the server? Removing this dependence on real-time access to the server also reduces the dependency for a live network connection. Ideally, the application becomes just as productive when there is no connection as when there is a connection.
The key factor, in this approach, is the constraints set by how concurrent the data must be. Using cached data potentially means you are using “stale,” or out of date, data. Your application may be able to use stale data without causing problems. For instance, if the data is largely static and does not change very often, that data is an ideal candidate for caching on the device. If the data updates are critical to other systems, however, then caching updates for later upload may not be acceptable.
There are several possible solutions to store cached data. If the application uses the Microsoft .NET* Framework, it can leverage the ADO.NET DataSet object, with its built-in functionality to serialize to XML and save to a file on disk. Should you use a local database? For Pocket PC and Windows* CE devices, Microsoft SQL Server* CE is one solution for storing data in a local database. How about implementing some kind of message queuing system that stores data locally when offline? Alternatively, the application could implement its own file-based data storage mechanism. There are many options open to you. Some are better suited to certain scenarios than others. For example, if the application needs to cache large quantities of data, using a local database is a better solution than opting to save the data in a file-based data store.
Reduced Functionality for Offline Operations: Another key factor in designing your application is whether the application operates well with reduced function ality when disconnected.
What are the consequences of caching all the data and allowing users to have access to it when offline? If the data comes from some enterprise data store that must always be up-to-date and the stale data is uploaded to the system when connectivity is resumed, the stale data could throw the whole data store out of sync, possibly overwriting newer key data with stale data from the device.
Analyze each function of your application and determine whether it can operate off cached data or can cache updates for later upload, or whether you should deny access to the function due to its dependency on a live network connection. Think about the potential effects of allowing a user to continue to work with data that becomes stale. This kind of intelligence built into the application enables it to offer at least some level of functionality to users when offline. This is a far better solution than denying access to the application altogether.
Reliable Messaging: If the application is going to change connectivity states frequently, the application needs some mechanism that guarantees that updates are uploaded to the server and that the data on the device is refreshed with the latest changes. The application could use some kind of stateless, “store and forward” communication mechanism.
Note that there are a few problems with using Web Services for reliable messaging. Web Services rely on a network connection for communication. If the device is not connected, it cannot communicate with the Web Services server. Therefore, there is no mechanism built into Web Services protocols for storing the data until connectivity is resumed; you have to code your own custom solution for that.
One solution that does provide this functionality is message queuing. Message queuing works on the “First In, First Out” (FIFO) principle where messages (data) are stored on a queue in the order they were added. When data is retrieved from the message queue, the data is retrieved in the same order that it was added. This technique allows the data added to the message queue while offline to be uploaded to the server in the correct sequence when connectivity resumes. Whether the device is connected or not, data is uploaded to the server in the same order as if the device is always connected. Updates are never processed out of order. Older updates never overwrite newer updates. There are a variety of message queuing systems available on the market; Microsoft Message Queuing (MSMQ) and IBM MQ Services are just two of them. The Microsoft .NET Framework contains class libraries that support communication over MSMQ.
Designing Applications to Handle Network Outages Transparently
For more complete information about compiler optimizations, see our Optimization Notice.
