s the line between the desktop and the web blurs, more applications are taking advantage of the best of both worlds. Adobe AIR and JavaFX are prime examples of frameworks that benefit from this union. However, as services deliver more of an application's functions, the offline problem starts to creep in. Simply stated, the offline problem
prompts this fundamental question: Who supplies the online data when the application goes offline?
The answer to this question may seem quite obvious; just keep a local copy of the data. That solution, however, is deceiving in its simplicity because, with the introduction of multiple copies of the same data, the real crux of the offline problem is revealed: synchronization.
|Unfortunately, synchronization is anything but simple. Even trivial synchronization between two identical databases with identical schema is a very complex undertaking.|
Related to the blur between desktop and web is the interest around service-oriented architectures (SOAs). This phenomenon is partially driving the recent interest in enterprise mash-ups, which leverage all the features offered by exposed services to quickly integrate heterogeneous data sources into a single, integrated view. This data may originate from data sources that are both internal (human resources, sales, and so on) and external (map services, stock tickers, and so forth) to the company. By their nature, service-based applications leverage a large amount of their processing power and logic from the systems that are hosting the services.
However, this leverage means that service-based applications inherently suffer from the offline problem and can work only while connected. For applications that make sense only while online, such as a live stock-ticker application, synchronization is not a problem. The offline problem becomes a true roadblock only when an application attempts to mobilize its data, or allow its users to work while disconnected.
The solution, it would seem, is that the offline application should store the data it needs from all the services locally, and synchronize everything upon reconnection. Unfortunately, synchronization is anything but simple. Even trivial synchronization between two identical databases with identical schema is a very complex undertaking. This simple case still introduces all the complexities of change tracking, managing deletes, and a host of other issues. These problems become even worse when the data is spread across many different sources, all with different protocols, and potentially not under your control (in the case of external services). The question then becomes, how do you architect an occasionally connected application that mashes up data from multiple, heterogeneous data sources?