Technical Report in Engenharia Informática e de Computadores (DEIC) Curricular Year 2008/2009

Transcription

1 Technical Report in Engenharia Informática e de Computadores (DEIC) Curricular Year 2008/2009 Departamento de Engenharia Informática Title: Current approaches to add offline work in Web applications Supervisor Teacher: António Paulo de Menezes Correia Leitão (signature) Student: 2542/D, Edgar Emanuel Marques Gonçalves (signature)

2 Abstract Today, more and more organizations prefer Web applications to perform their business processes, because these allow collaborative work between several users. However, many tasks must be done while being offline. This goes against today s Web architecture, where a remote server must be contacted for each performed operation. When implementing offline work in existing data intensive Web applications, one main issue and perhaps the less studied one is the need to specify what information must be on the client side, for each functionality. In this document we shall describe the differences between the online and offline behavior in Web applications. We also review the main approaches being used in current Web applications, with the goal of adapting a Web application so that it can offer offline work to the user. We conclude that no existing solution is able to perform that task in its entirety for a generic application, specially if it contains any kind of dynamic resources and behavior. Edgar Emanuel Marques Gonçalves 2

3 Contents 1 Introduction 4 2 Web Applications Architectures Online Web Applications Offline Web Applications State of the Art Standards Evolution: HTML Application Cache Browser Offline Status Structured Client-side Storage Google Gears Local Server Local Database Worker Pools Gears Recommendations Considerations The Dojo Offline Toolkit Network Connection Data Fetching Data Storage Data Synchronization Considerations Other Offline Solutions Non Web Application Targeting Frameworks Failed Web Solutions Conclusion 19 References 20 Edgar Emanuel Marques Gonçalves 3

4 1 Introduction Nowadays Web based interfaces are taking control over most organization s applications. Benefits like ease of installation, deployment and upgrades, requiring little space on the client computer, and being virtually cross-platform, 1 make Web applications the appropriate choice to support an organization s business processes (when comparing them with Desktop-based equivalents). However, certain activities must take place outside the office, frequently while being disconnected from the Internet. Although being more and more directed towards a permanent connectivity around the entire globe, we are not there, yet (as seen in Figure 1), and thus online work isn t always feasible. Even assuming this problem could be solved solely by technological breakthroughs on short or mid-term, we are still faced with situations in which we need to be able to work while isolated from the Internet: we may be confined to an isolated room, working on a train that travels inside tunnels or simply because our mobile connection strength is too low to keep itself permanently alive. Other situations may even prohibit the use of a connection to the Internet, such as a confidential project with high security concerns. There are also financial issues at hand. When accessing the Internet without a flat-rate data plan we are often charged with high prices, and thus many people tend to work online in their homes and offices, and use a disconnected device while on the move. This happens with most mobile ISP, to whom we pay for our connection duration or for its transmited data length. This is an issue for the individual, but it gets worse at enterprise level, specially when every employee should be required to use the application everywhere. There are other development-oriented scenarios that can benefit from offline work, like changing the application s design while it is online for all other users. Figure 1: World Internet Penetration Rates for mid-year 2008 Regardless of the motivation, every organization providing both online and offline support for an activity usually prefers to offer the user the same application interface. Unlike desktop applications, Web applications 1 Unlike being cross-platform, being cross-browser still represents a major issue in current Web development, mainly due to standards compliance divergences. Edgar Emanuel Marques Gonçalves 4

5 fall short in this capability common UI behaviours are tightly linked to a server s response to a given request. In order to change this, Web applications need to provide support for disconnected operations, and have the entire UI depend solely on the client. But supporting this infrastructure is not enough for most organizations, as a vast number of Web applications are already designed without ever having thought about the loss of their Internet connection. It is, thus, necessary to adapt and enhance existing applications with the support for disconnected operations. The fact that this scenario is not properly contemplated in Web application s development methodologies being used up until now justifies the need for a new suitable one. Both academic and enterprise researchers are aware of the need to offer offline work in Web applications. In the following section we shall briefly present a generic Web application architecture, and compare it to a web application s one that allows offline work. We follow the document with a discussion of the main approaches to achieve the desired goal, which includes a review of the relevant aspects of the HTML 5 standards current draft, Google Gears, and the Dojo Offline Toolkit. We also discuss some other approaches that aren t oriented to Web applications. 2 Web Applications Architectures A Web application is the evolved concept of Web sites, which are collections of interwoven documents (with the possible functionality of having forms submission). A Web application takes advantage of the increasingly powerful machines on the server-side, by allowing programs to perform complex functionalities for the clients. Evolution also occured on the client-side, allowing smoother interactions to happen. This turned many Web applications into Rich Internet Applications (RIA s). So what stands current Web applications apart from the Desktop ones? The use of a browser makes every web application be cross-platform. It also eases its update procedure (all clients may start using newer versions as soon as they are deployed on the remote server propagation of changes to all clients is facilitated due to the inherent client-server architecture. Web applications gain enhanced ubiquity, since a user may access them on a multitude of browserenabled devices and locations. Web applications have many security constraints that desktop applications don t need to consider. They exist to prevent malicious servers from damaging a user s machine, since web applications aren t subject to any operating system security validation. Web applications client-side has to be implemented in a scripting language (like Javascript) to be supported natively by any mainstream browser. If complex procedures are required, browser plug-ins must be used, and be given authorization to run by the end user. Generally speaking, the majority of Web applications have their server-side code written in a different language (usually a high-level one) than the client-side code. Edgar Emanuel Marques Gonçalves 5

6 Client Server Event Processor Reply Processor Connection Present UI Specs Business Logic Stored Data Figure 2: Component diagram of a common Web application. 2.1 Online Web Applications A Web application that is designed to work online is usually architecturally quite simple. Figure 2 presents the details of such architecture. The two main entities are a server machine and a client one. Note the intermediary role played by the client machine all it usually does is to accept user input, formulate server requests and process its subsequent replies to output back to the user. This is depicted by the simple interaction model between the client and the server, on Figure 3. Client Remote Server Request Proxied Reply Figure 3: Interaction model of an online Web application. The green area indicates online work. It is currently possible, however, to enrich the client-side functionality with more features, like partially Edgar Emanuel Marques Gonçalves 6

7 compute the application logic and perform data validation, but that is not required. So on common cases, all the application model and logic live within the server. This is usually a three-layered server, as depicted is Figure 4. The top one is relative to the processing of the client events and production of the appropriate UI to reply them. This controller layer can call the application model functionality, in whose layer we can find the domain and business logic, the domain definition itself and the UI specifications. The lower layer is usually a persistent storage, where information is kept along multiple user sessions (and even permanently). Application Controller Application Models UI Business Logic (Services) Domain (Types and Relationships) Stored Data Figure 4: Layered diagram of a common Web application. This is a description of common Web applications. More exquisite requirements may force the designers to make some alterations to the presented architecture. The most common change is the moving of some of the application s logic into the client machine, to shorten the UI response times. 2.2 Offline Web Applications Offline Web applications pop-up when we have to consider the apparently simple requirement of using the same application while working without a working connection to the server. In a simple Web application this means that a complete replica of the server has to exist on the client, and allow the user to stop accessing a remote server and start using the local replica. However, this is usually not possible, because: not all functionalities are valid when working offline (think of a instant messaging service); not all stored information may be stored on the client, either by space/bandwidth restrictions or by authorization constraints; Edgar Emanuel Marques Gonçalves 7

8 Client Server UI Specs Subset UI Specs Event Processor Reply Processor Business Logic Subset Stored Data Subset Connection Occasionally Present Business Logic Stored Data Figure 5: Component diagram of a common Web application with offline work. most applications designs are based on a central service repository, where each service can freely and safely access the entire code-base and the entire data storage, and thus a rewriting of such services is needed before migrating them to the client; typically the code of the application is not written in a client-side processable language. Figure 5 represents the common changes we have to consider to the application s architecture. Note that only a subset of each of the application model s sub-components on the remote server is present on the local machine. The regular client-server interaction becomes unusable, and a new workflow (depicted on Figure 6) emerges in these applications: 1. The user first navigates to a remote server, and a local application (with server functionality) is downloaded. 2. Online requests are directed towards this local server who, in its turn, proxies them to the remote, collecting their answers and forwarding them back to the client. 3. Whenever the application goes offline, all required code and data must present locally. 4. While working offline, all performed interactions are registered into a log. 5. Before resuming online work, synchronization occurs, where all logged interactions are replayed and data is merged into the remote server. Remote changes are also propagated to the local application. This new workflow poses several new challenges that existing online Web applications didn t need to consider. The local machine is going to be able to run the server s code. It also must know how to interchange Edgar Emanuel Marques Gonçalves 8

9 Client Local Server Remote Server Request Proxied Request Proxied Reply Reply Request Reply Register offline request Sync offline work Request Proxied Reply Proxied Request Reply Figure 6: Interaction model of a offline Web application. The red and green areas indicates offline and online work, respectively. information with the server. Functionalities must be defined to be able to run offline. Both machines must know how to merge data. Conflict resolution must be possible, so that the work done by the user while offline isn t ever lost. Every interaction must be logged, and the local machine must be able to replicate its effects at a later time (moreover, if we re facing a transactional operation, we have to consider its rollback in the case of abortion). In the following section we ll review the state of the art about the strategies that can be used to implement offline work in today s Web applications. 3 State of the Art In this section we shall reveal the details of the upcoming HTML 5 specification related to offline Web applications. Afterwards we show how frameworks can help implementing them, namely Google Gears and Dojo Offline Toolkit. Edgar Emanuel Marques Gonçalves 9

10 3.1 Standards Evolution: HTML 5 The HTML 5 specification[1] is still a work in progress in a draft stage, but it has been in active development in the past couple of years. Currently there s a draft recommendation available online, with a section relative to the Offline Web applications. In fact, there s an isolated document just to discuss them, in [2]. The first noteworthy aspect is that all aspects related to offline Web applications are non-normative. However, both Mozilla s Firefox and Apple s Safari have been adding support for these features on their development codebase. Apple has recently adapted Mobile-Safari with some of these features, in order to use offline Web applications on the iphone. The HTML 5 draft specification states the presence of a new feature, called Application Cache, and briefly mentions the Browser Offline Status. It also specifies the Structured Client-side Storage. We shall review these in detail in the remainder of this section Application Cache Differing from browser caches (quite volatile and not reliable), an Application Cache can now be used to collect resources on the browser. Described in a manifest file, this cache consists mainly on a set of resource entries, that can fall into one of the following categories: Master entries These are HTML documents that were navigated to on the browser, and whose meta-data point to a given manifest file. Explicit entries These entries are static resources located at a given URL. Can also be foreign, i.e., their meta-data point to another manifest file. Fallback entries These are entries that the browser will fallback to in case the primary target can t be reached. The browser would perform the activities in the sequence described in Figure Browser Offline Status At a given point in the HTML standards development it was thought to be useful to have the browser know when it was online or not. This status awareness was promptly included in the HTML 5 specification, with two main features: Status attribute From the specification, The navigator.online attribute must return false if the user agent will not contact the network when the user follows links or when a script requests a remote page (or knows that such an attempt would fail), and must return true otherwise. Status toggle event Whenever the navigator.online attribute s value is switched, the online or offline simple event is fired at the Window object, accordingly. Having considered the lack of completeness in these descriptions, the latest specification revision was appended with the pertinent note: This attribute is inherently unreliable. A computer can be connected Edgar Emanuel Marques Gonçalves 10

11 Client Server Get a.html Send a.html find manifest meta tag Get manifest.file Send manifest.file process manifest entries Get a-script.js Send a-script.js cache a-script.js Get a-logo.png Send a-logo.png cache a-logo.png Figure 7: Sequence diagram of a browser client fetching a file (a.html) with a manifest file, and its implications. to a network without having Internet access.. One common example of this definition s misalignment is a locally hosted server Structured Client-side Storage Another non-normative section of the specification draft, this one describes a storage facility, analog to HTTP session cookies but without the 2KB maximum size limitation. Actually, the maximum limit can be userspecified, and defaults are not considered in the standard, so far. Storage has also become rather simple, as it is now a plain Javascript object that can be used as a key/value pair map, where values can consist in strings (other data types must be serialized beforehand. The specification suggests the use of an SQL interface, such as SQLite). The storage facilities are split into two features, each one oriented at a specific use case scenario. Additionally, the specification includes a notification mechanism. Session Storage Whenever a user browses through multiple windows (or other navigation contexts) to the same page, it is sometimes desirable to keep a sane execution context. For this purpose the sessionstorage object can be used to store any sort of information. Local Storage If our Web application needs to store information that spans multiple browser sessions, up until now there was no mean to persist information without storing it on a remote server. The present Edgar Emanuel Marques Gonçalves 11

12 specification allows the object localstorage to be populated with domain-specific information that will reside on the local machine s disc. Storage Event One very clever addition to the specification is the storage event firing whenever any storage area changes. This event will fire up in each active Window object whose Document has the affected Storage in it. This allow active windows to synchronize, e.g., the UI when something is changed. 3.2 Google Gears Gears[3] is a framework that builds on a browser via a plug-in. It implements and extends the HTML 5 offline support via three main features: a Local Server, a Local Database and support for Worker Pools. Gears works in all web application as long as a Javascript gears_init.js initialization file is loaded beforehand, and the end user is running the Gears plug-in within his browser Local Server The Local Server is the implementation of the HTML 5 application and resources cache. This is done by including a manifest file that holds all resources online locations. This simple task will allow Gears to fetch all referred resources (all files that can be accessed statically from a server are valid candidates, such as HTML documents, script files, multimedia and other binary files). From this moment on, any web page referring one of those entries can work offline, and Gears makes sure those resources are fetched from the Local Server instead of the specified remote location. An illustrative Gears manifest file is presented in Figure 8. Written in JSON 2 format, it indicates Gears what are all of the entries that must be fetched to the browser, and where they are located. All the initial HTML page has to do is to load the gears initialization script and set the MANIFEST_FILENAME variable to the manifest (absolute or relative) location. { } "betamanifestversion": 1, "version": "my_webapp_version_string", "entries": [ { "url": "simple_app.html"}, { "url": "simple_script.js"}, { "url": "../gears_init.js"} ] Figure 8: Gears illustrative manifest.json file contents. 2 Lightweight JavaScript data-interchange format. See for details. Edgar Emanuel Marques Gonçalves 12

13 3.2.2 Local Database Static websites can easily be adapted to work offline perfectly just by using the Local Server. But what happens should the server reply with dynamic content? Neither Gears nor the browser are able to retrieve updated dynamic information from the remote server if they can t access it. The same rationale applies to information that must be sent to the server. This kind of information requires application state to be stored on the client side. Despite having been made several weakly implemented workarounds, storing data in cookies, the browser cache or fake them as a local resource was always cumbersome (if not even error-prone e.g., consider information being wiped by local cache invalidation policies, inadvertently). Gears overcomes this issue by offering web apps a relational Local Database living on the client side. This is persisted across browser sessions, and is lightweight (it uses an SQLite engine under the woods). This way, a dynamic application may perform two distinct activities without contacting the remote server: Storing information needed by some business logic to provide dynamic answers for client requests; Storing user-submitted information, along with data processed on the client-side, until the remote machine is accessible again and all data can be synchronized with it s central storage. The database works by allowing SQLlite instructions to be called in a string passed to the db.execute() method. Some local considerations are also present, such as a text search functionality or user confirmation to access the Local Database functionality for the first time Worker Pools With a Local Server and a Local Database, most Web applications can be implemented (at least in a theoretical level) on Javascript to offer offline work. There is one last drawback that must be considered. Contacting the remote server, either to fetch information or to synchronize it after offline changes are made, can be a time-consuming operation. If done in a traditional way, it d block all UI interactions with the user. Gears tackle this issue by providing support for Worker Pools. A Worker Pool is a Javascript instance that is responsible for managing all Workers created for a given application. In Figure 9 we can see the Worker Pool instance setting a callback that receives Workers messages and echoes them to the user. Afterwards it creates one Worker (whose code is represented in Figure 10 that replies the caller with the current time. Note that the Worker is located on another file, and a remote location may be used to get it by calling workerpool.createworkerfromurl(location) accordingly. Workers behave similarly to threads on an operating system, and allow a given computation to be performed in a separate environment. Despite being immediate to relate workers in a web application to threads in a process, the formers don t have shared execution state (thus they compare much easily with several processes than with several threads). Worker Pools also provide a inter-messaging mechanism, in that a worker may contact others (e.g., to provide and update its execution state or to collect results from it). This feature can be associated with the possibility to load cross-origin workers to allow remote nodes communications. This allows applications to Edgar Emanuel Marques Gonçalves 13

14 // webapp-script.js var workerpool = google.gears.factory.create( beta.workerpool ); workerpool.onmessage = function(a, b, message) { }; alert(worker + message.sender + says: + message.body); var childworkerid = workerpool.createworkerfromurl( worker.js ); workerpool.sendmessage([null, null, "Time is "], childworkerid); // worker.js Figure 9: Web application script segment managing a worker pool. var wp = google.gears.workerpool; wp.onmessage = function(a, b, message) { var d = new Date(); var reply = message.body[2] + d.gethours() + ":" + d.getminutes(); wp.sendmessage(reply, message.sender); } Figure 10: Web application worker script. display, e.g., widgets with information from several remote sources Gears Recommendations With the three main contributions of Google Gears to the browser, Web applications are undoubtedly easier to port into an offline architecture. Google goes further and suggests developers to consider some architectural design decisions: Message Dispatching Having a central messaging dispatcher on the client application (also called data switch) will allow all application data requests to be made either to the remote server or to the local one. Otherwise the client has to transform all requests and redirections in order to prevent an offline user to try to access a remote source. Data validity while offline Not all information is suited to be served on the Local server, even though that could lead to faster response times. Data can be useful in real-time (e.g., stock quotes), or being inherently online information (e.g., instant messages). The application may only have interested in the last accessed/most frequently used information. Last, physical limitations (like disk space) can force Edgar Emanuel Marques Gonçalves 14

15 the data to be served online only. Modality of the connection state change Modal applications require the user to be aware and active on the connection state change. This makes the synchronization and state change of the application very well defined, and easy to implement. Modeless applications, however, provide a fluid user experience when toggling online status, even in the presence of intermittent connections. This comes at the expense of frequent background synchronizations with the server, as well as causing testing to be harder to program. Synchronization Related to modality is fact that synchronization can be done either manually or automatically, in the background. A manual connection typically can be performed only in the presence of a small changed data set, so that it is feasible to wait for its transmission. But when the data must be accessible at all times, even if the situations where the user doesn t know the connection has been lost, then a background synchronization must be used Considerations Gears, despite all its features, can t allow an easy porting of a generic Web application to work offline. Leaving alone the fact that it requires a plug-in to be installed on the client browser (and that is still not a mainstream-level performed task, unless it starts being shipped automatically with the browser itself), the application transformation still requires the developers to think about the aforementioned issues. Specifically the data validity issues can be extrapolated to a more serious issue, not discussed at all by Gears, that consists on whether a given functionality is valid while offline. Gears just assumes all code is to be written from scratch or is already written in javascript and able to be passed along to the client. The data synchronization techniques are also stated to be quite domain-specific. 3.3 The Dojo Offline Toolkit Much like Gears is an abstraction over the HTML 5 specification features for offline work on Web applications, Dojo s effort is a solid extension over Gears, aiming for faster development of offline functionality. The Dojo Offline Toolkit (hereafter being referred to as DOT) offers a set of functionalities and abstractions to enhance the Javascript client-side application. They fall into the categories of network connection, data fetching, data storage and data synchronization Network Connection DOT respects the HTML directives and offers a mean to detect offline status via both an attribute and event triggering. It goes a step further and provides a widget that, without neededing more configuration, informs the user about all offline workflow main events, such as loosing or regaining the connection, synchronizing data or eventual failures. This widget only needs the target page to include after loading the mandatory framework scripts the HTML tag <div id="dot-widget"></div>. Edgar Emanuel Marques Gonçalves 15

16 The main offline protocol in place within Web applications with DOT consists in two main states, online and offline. When the client wants to go to the offline state, it must fetch all UI and data from the remote server. During offline state, all performed actions are stored in a log. Upon regaining connection the remote server, it must fetch the updated UI from the remote, resetting the one in the client machine, and replay all logged actions. After that, and if no conflict was detected, it reaches the online state Data Fetching Fetching offline information no longer needs the tedious and error prone writing of manifest files. DOT provides a dojox.off.files.slurp() method that is able to discover all of the resources statically linked to the document that calls it. The downside is that dynamically loaded scripts and resources (like inline CSS) aren t detected by that method. So DOT allows a manual addition of those files, using something analog to Figure 11 to populate the application cache. dojox.off.files.cache([ "images/file1.png", "images/file2.png", "scripts/some_dynamic_script_tag.js" ]); Figure 11: Dojo Offline Toolkit: Manual way to fetch online resources. The DOT development team is aware that fetching all static resources whenever a user wants to go offline is not very clever. This is why they support checking a version file, version.js, in the same place of the application s root, and its contents are used to compare with the version on the client. Remote data is fetched whenever this file s contents differ Data Storage Storage can be done in a simillar fashion to Gears Local Database, using the Dojo SQL relational storage layer. However, for simpler usage, Dojo Storage provides an hashtable mechanism of putting data into the same Gears-managed storage. Unlike the HTML 5 sessionstorage, the Dojo Storage abstraction allows any Javascript object to be stored under a given key, using the following syntaxes: dojox.storage.put("meaningofeverything", 42); var answer = dojox.storage.get("meaningofeverything"); Another interesting feature is the ability to protect information, using ENCRYPT() and DECRYPT() keywords on the Dojo SQL queries. Edgar Emanuel Marques Gonçalves 16

17 3.3.4 Data Synchronization Dojo Sync is the DOT component capable of merging offline data with the remote server. It integrates its behaviour with the widget, and works with a specific event triggering workflow to allow the programmer to adapt the Web application. Figure 12 shows how data can be downloaded to the client to be able to go offline. The callback function listening to the onsync event is called with the type of behaviour the remote server just presented, either a download of information or the conclusion of the download process. Note that we have to explicitly call dojox.off.sync.finisheddownloading(), so that DOT may proceed with the offline workflow. dojo.connect(dojox.off.sync, "onsync", this, function(type){ if(type == "download"){ // download new documents dojo.xhrget({ url: "/remote-info-place", handleas: "javascript", load: function(data){ dojox.storage.put("info", data); dojox.off.sync.finisheddownloading(); }, error: function(err){ err = err.message err; var message = "Unable to download info: " + err; dojox.off.sync.finisheddownloading(false, message); } }); } else if(type == "finished"){ // refresh our UI when we are finished syncing } }); Figure 12: Dojo Offline: synchronizing data from the remote server (example taken from the DOT documentation). The counter part of the onsync event, uploading data into the remote server, isn t this easy to implement. DOT suggests the usage of a transactional model, where each offline action is registered as an Action object. The method dojox.off.sync.actions.add(action); can be used, and every action is an object with a name property (identifying the action type) and a data property (identifying whatever information the application needs to perform the action instance in question). Actions are kept in an Edgar Emanuel Marques Gonçalves 17

18 Action log, until the client reconnects. When this happens, the UI is refreshed (if needed) from the remote server, and all state gets reset. as if all offline work hasn t been done. Then we can subscribe to the onreplay event (much like we shown previously with onsync), and handle each action in the log, accordingly, so that the entire state is replayed. When submitting information to the server, there may be times where a conflict arises. And thus all actions must be undone. DOT requires the script to call actionlog.haltreplay(msg); to do that. Also, when the server replies with a sucess peration, DOT requires the script to call actionlog.continuereplay(); in order for the replay to resume Considerations DOT, despite being built on top of Gears, offers some interesting features for offline work. The proposed offline protocol to manage information on the client offers a good boilerplate for Web applications to be written from scratch. However, all the considerations drawn for Gears in the previous section still apply. Moreover, the data synchronization is well suited only for scenarios where the remote server perform data merge and conflict detection, and returns an error on each conflict. By storing action-identifying information and requiring the programmer to describe the commands to carry them away, in order for the system to be able to replay, rollback and abort transactions on conflict detection, we are facing a known pattern: the System Prevalence[4] architectural style has been defined to perform this. So, besides not bringing new developments, Dojo s synchronization also suffers from the Prevalence stigmas side effects, specially any action that is based on the current time, will fail without drastic hacks. 3.4 Other Offline Solutions Besides the HTML 5 supporting solutions to aid offline work in Web applications, other technological researches have been made in the past 5 years in this area and its surroundings Non Web Application Targeting Frameworks Of all the issues pertaining offline work within Web applications, data storage and synchronization must be the most studied so far. Microsoft Labs have been working for some time now on Occasionally Connected Systems, and data merging and synchronization. The latest developments resulted in the Microsoft Sync Framework.[5] This framework consists on an orchestrated set of Participants devices that can provide data stores to be synchronized. These can range from computers and handheld devices (full participants that can provide writable data stores) to media players and digital cameras (partial participants that can only provide readable data stores). On the data merging techniques Microsoft attaches meta-information to each data item. With this metadata items become versioned, with indication of the moment of the item s creation and all the performed updates. They become aware of all changes that were performed on them through time (along with information of the operation that caused it, enabling its tracing, e.g., for conflict detection purposes). They also get Edgar Emanuel Marques Gonçalves 18

19 marked after being deleted, with tombstones, so that synchronization can occur without missing information for any participant. Merge of every data type is said to be done automatically. Microsoft s project Astoria, now dubbed ADO.NET Data Services[6] use this technology to provide a synchronizing-capable offline storage to Web applications. Sun also has some research on the synchronization. Java DB[7] a very lightweight implementation of Apache s Derby project is a relational database system that can be embedded within a Java archive. It is this feature that enables it to be implemented on the client to be used as a local storage. This has been used for some application, such as Zimbra, to make their data available offline. Both Sun s and Microsoft s approach lack an important factor they don t allow the synchronization of structured types. The merge of domain specific items cannot be done as trivially as a binary data merge. There must be application specific rules that should be addressed in order for the information to keep its semantic meaning in the entire Web application. The described solutions both require the programmer to specify such rules by hand, falling in the frameworks only for the basic data synchronization Failed Web Solutions In 2007 a company named Joyent released the Slingshot[8] framework. It would pick up a Rails-based Web application and, with little effort, allow its conversion to a Desktop application. It does this by providing plugins to both Mac OSX and Windows that can interpret the Rails server-side application and also includes a browser that shows the UI to the user, offline. The programmer is left with the task of specifying all synchronization rules, and it s assumed the entire application code can be run on the client side. For these reasons alone or not, this project was abandoned, and no further progress (nor any real application) was ever made. Zimbra has another excellent case of what started out as an effort to enhance an online Web application to include an offline version of its functionality. The idea, which started out by requiring a browser plugin to support service execution on the local machine (as well as data storage), has now shifted its form to a full fledged Desktop application (Yahoo! Zimbra Desktop). It now uses the aforementioned Java DB for storage, among other supporting technologies that escape the Web application context. 4 Conclusion Offline work within existing, domain-intensive Web applications with rich domain object models isn t easily achieved in the present days. In this document we presented the architecture of a Web application, for both online and offline work. Afterwards, we reviewed several currently existing approaches for implementing offline work in Web applications. We conclude that there is no existing mean to adapt a Web application with an intensive and rich domain to add offline capabilities to its functionality. Approaches that target offline work within Web applications fail in several aspects: They don t consider that some of the application s functionality isn t suited to offline work (or they just assume we re developing a new solution from scratch); Edgar Emanuel Marques Gonçalves 19

20 they generally assume data fetching can be done statically, not offering any kind of dynamic prefetching of information; they only support scenarios where data merge is done by an external system on the server, and don t cope well with complex domain types nor conflicts in their merge. References [1] W3C. HTML 5 - A vocabulary and associated APIs for HTML and XHTML [online]. February Available in: [2] W3C. Offline web applications [online]. May 2008 [last checked: March 2009]. Available in: http: // [3] Google, Inc. Google Gears [online]. Available in: [4] K. Wuestefeld, Do you still use a database?, in OOPSLA 03: Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pp , New York, NY, USA: ACM, [5] Microsoft. Introduction to the microsoft sync framework runtime [online]. November 2007 [last checked: 2009]. Available in: aspx. [6] M. Flasko. Microsoft data platform development technical article - overview: Ado.net data services [online]. August Available in: cc aspx. [7] Sun. Java db [online] [last checked: 2009]. Available in: javadb/. [8] Joyent. Slingshot [online, last checked: 2009]. Available in: projects/slingshot/wiki/slingshot. Edgar Emanuel Marques Gonçalves 20