Implementation of a proof-of-concept mobile web OS architecture

(1)

2009:076 CIV

M A S T E R ' S T H E S I S

Implementation of a Proof-of-concept Mobile

Web OS Architecture

Mats Hamberg

Luleå University of Technology MSc Programmes in Engineering Computer Science and Engineering

Department of Computer Science and Electrical Engineering Division of Information and Communication Technology

2009:076 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--09/076--SE

(2)

Implementation of a

Proof-of-concept Mobile Web OS Architecture

Mats Hamberg

March 06, 2009

(3)

(4)

Preface

This thesis concludes my education at Lule˚a University of Technology at the Master of Science programme in Computer Science and Engineering, specializing towards software engineering.

The thesis work has been conducted at Ericsson Research in Lule˚a, during the time September 2008 to March 2009.

First of all I would like to thank K˚are Synnes at Lule˚a University of Technology for introducing me to the team at Ericsson Research in Lule˚a, which lead to an interesting and challenging thesis. I would also like to thank Johan Kristiansson at Ericsson Research for constructive criticism and suggestions throughout the project. Finally I would like to thank family and friends for their everlasting support, and special thanks to Emma.

Mats Hamberg Lule˚a, March 2009

(5)

(6)

Abstract

Today it is possible to always carry around a computer with an available network connection. These computers can be mobile phones or other handheld devices with data processing and bandwidth performance comparable to a desktop computer. This combined with the spreading of network connections makes it possible to think in new paths when developing network-based applications. Such applications can be referred to as two-tiers, and they often reside on different operating systems giving the software developer multiple aspects to consider with environments, network dependency and programming languages.

This thesis investigates how a proof-of-concept mobile Web OS architecture can be implemented. To oppose the constant network dependency an offline mode is tested with support from Google Gears. The architecture should deploy client-side applications automatically, without the client needing to download and install them separately.

The conclusion is that an offline mode is possible for Web applications with support from the Google Gears browser plugin (the same feature that can be found in the drafts of the forthcoming HTML5). It is also proven that applications can be automatically deployed on the client when they are made available on the server.

(7)

(8)

Abbreviations

AJAX Asynchronous JavaScript and XML API Application Programming Interface CSS Cascading Style Sheets

DOM Document Object Model GWT Google Web Toolkit

HTML HyperText Markup Language IP Internet Protocol

JSNI JavaScript Native Interface JSON JavaScript Object Notation JVM Java Virtual Machine OS Operating System

PHP Personal Home Page or PHP: HyperText Preprocessor PNG Portable Network Graphics

UML Uniform Modeling Language

XHTML Extensible Hypertext Markup Language XML Extensible Markup Language

(9)

(10)

List of Figures

2.1 Web technologies interacting . . . 8

2.2 Synchronous and asynchronous communication . . . 12

3.1 Layout of client framework and prototype . . . 22

3.2 UML of client structure . . . 24

3.3 UML of WorkerPool implementation . . . 24

3.4 UML of output controller, 1 worker - 1 output . . . 26

3.5 UML of output controller, many workers - many outputs . . . 26

3.6 UML of server structure . . . 28

3.7 Server structure of file system . . . 29

3.8 The different states of an application and their color . . . 30

3.9 Application structure of file system . . . 31

3.10 Drag-and-drop from server to client container . . . 32

4.1 Total number of characters used in the four tests . . . 39

4.2 Average number of characters used in the four tests . . . 39

D.1 Hello World! application with different output . . . 54

E.1 Parallel execution in JavaScript . . . 65

E.2 Total number of characters used in the four tests . . . 72

E.3 Average number of characters used in the four tests . . . 72

(15)

(16)

Chapter 1 Introduction

This chapter introduces the reader to network applications and their boundaries. First there is a brief summary covering major implications during development, deployment and network dependency regarding network applications. This is followed by possible solutions to the presented implications. In the end related work in the area of web operating systems and new technology for browsers and their content is presented ending with the purposes of this project.

1.1 Application development

An application is a program on a computer that does a few predetermined tasks. The program is most likely also bound to work on a single computer and for certain types of operating system. Due to big differences in operating systems, the application developer need to adapt the software to work in the particular environment, which will make the program unusable in other environments than the one it was intended for. An exception to this is Java which uses a virtual environment for execution, designed for a certain operating system and environment. Since it is the JVM that is adapted to the environment, the actual application is platform independent. But it is not totally independent since it can use different APIs depending on the applications tasks and usage.

Mobile devices (cellphones and handheld computers) are for each day passing closing in on desktop computers in hardware and performance.

Desktop computers (laptops and stationary) are closing in on mobile devices in size and weight. These two races will probably merge into a single type of hardware in a near future, much like todays mobile devices in size and

(17)

weight and desktop computers in performance. Until this day has arrived, the hardware in mobile devices will not be the same as in a desktop computers.

Most programming languages are designed for the environments used by desktop computers, which has lead to extensions of programming languages solely for the mobile devices. This gives mobile application developers even more obstacles.

When developing a network-based application often two applications are needed; one for the server and one for the client. Since the environments often are different the developer will have to consider a lot a aspects when creating the applications. If all environments would share the same conditions and standards, the application development would be made cheaper, easier and faster.

1.2 Application deployment

Today most applications are deployed over the Internet, making it easy for the user to instantly obtain the latest version. A new application can be deployed from the developer in two ways; either as a single package containing everything needed for the installation, or as an online service where a downloaded and installed small application downloads the remaining parts from a server repository and then installs it. Applications for mobile devices are a bit trickier since they often need to be downloaded to another computer and then sent for installation to the mobile device through a local connection.

It will be hard to obtain a service offering a general online repository for all available applications. Mostly because different developers will have their own solutions and not wanting to use a service a competitor can take credit for. But also because all applications residing in such a repository need to be approved and validated by those who host the service.

1.3 Network dependency

With todays rapid spreading of both wired and wireless broadband, Internet connections are close to a standard in industrialized countries. Also applications not using Internet are becoming more unusual, either if it uses it for its main purpose or for simple update checks. This is taking the applications from the scope of the single computer closer towards the world

2

(18)

wide web each day, and is setting higher demands for network stability.

The dependency on an Internet connection comparing mobile devices and wired computers are the same, but the mobile device is more vulnerable since it is mobile by definition and the transmission can be lost. The biggest drawback with mobile devices are their dependency on wireless connections, since they can’t be wired. Also most wireless connections costs more money to use than a wired comparison, and is charged either by the amount of transmitted data or a cost compensating for a fixed transmission usage. Due to this the applications being developed for mobile devices need to be able to handle a lost connection anywhere in the program, since neither the user, developer nor hardware can predict a future disconnection. If all mobile applications that uses a network connection can rely on the same uptime as a wired computer, a lot of fail-safe programming and retransmitted data could be avoided.

1.4 Possible solutions

The problem when dealing with a lot of different environments and programming languages can be avoided by using a web based application environment.

A similar solution is already present in the form of web operating systems, where the user have all applications running on a server and accessible through the local web browser. With the desktop running in the browser the user always has access to documents and installed applications, no matter of client hardware or location. Application developers using an online desktop have the ability to create one application to be used in all environments.

Unfortunately do these solutions share the same drawback as mobile devices, they will not work in case the connection is lost.

Google launched a product called Google Gears in May 2007 which makes it possible to locally save copies of web pages and files which will prevent the complete downtime during a lost connection. Obviously the user will not be able to leave the cached pages, but will not be aware of the lost connection.

When running Google Gears a virtual server is running in the background caching pages on the local computer as an extension of the web browser. If the connection is lost the virtual server automatically starts acting as the remote server, giving the user the feeling of still being online. Google Gears is described in detail in section 2.4.1.

(19)

1.5 Related work

This project covers new and experimental ways to evolve techniques used when network applications are being developed, deployed and supported during runtime. In these areas a lot of research is done following different paths; virtual operating systems, new browser technology and a new presentation language for web content. But they all share the same purpose, to extend the usage of Internet.

1.5.1 Web operating system

A web operating system is a web application reachable through the normal web browser, which gives access to a virtual operating system residing on a server. In the area of web operating systems there are a few pioneers that have released working products, among them are eyeOS [6] [7] and Desktoptwo [4] [5]. Their technologies are similar but also different depending on where you look. They both uses PHP as server language but they differ a lot regarding how the web application is presented, eyeOS uses JavaScript while Desktoptwo uses Adobe Flash Player.

1.5.2 Google Chrome

During 2008 Google launched their open source web browser called Google Chrome [8], or just Chrome. It is built using new ideas, both borrowed from other projects and developed during the project by them self. The open source web engine WebKit [15] is used as the framework and to that new features have been added. Google Gears is of course already built-in supporting both offline mode and parallel script execution, and a new high performance JavaScript engine has been developed called V8 [17]. The browsers design is kept both slimmed and user friendly for improving resemblance for web applications with desktop applications. When comparing Google Chrome to other browsers an important feature is that each tab is contained in a unique process and its own sandbox, making that tab able to crash without taking the whole browser down with it. Since the testing only has come to Beta version, its future looks promising.

1.5.3 HTML5

The current standard for presenting web based content is HTML4, but the fifth version [11] is being developed. Like every other technique and language it is evolving and changing to handle more advanced tasks, and also sorting

4

(20)

out features no longer needed. Among all the differences HTML5 will bring, a few are mentioned here which all are relevant to the purposes of this thesis.

These new features will allow web applications to act and work more alike desktop applications then ever before.

• Caching for offline mode

• Workers executing scripts in parallel with the main page

• Client-side storage with SQL databases

• Maintaining two way communications with server-side processes

1.6 Purpose

The purpose of this project consist of two parts:

• Develop a proof-of-concept server architecture for web applications.

The architecture should use Google Gears to improve the users uptime, even when a connection is not possible. It should also automatically deploy or announce web applications for client installation, when installed on the server.

• Investigate performance implications during runtime of this architec- ture.

(21)

(22)

Chapter 2 Theory

This chapter is divided in four sections, each describing fundamental concepts and technologies used and associated with network applications usable in this project. The first section covers environments and known boundaries in which network applications work. It follows with a section about programming languages for both server-side and client-side development.

The third section briefly explains different technologies and the last section available aids to the development process.

In figure 2.1 a multi-tier architecture is shown to describe how the different technologies and aids presented in this chapter can cooperate. The user interacts with runtime environments working inside the web browser. A browser has usually support to describe, style and work with the web content.

It can also use plugins (such as Google Gears) to gain more runtime features, creating a more genuine resemblance to a client environment. The server uses a web server that accesses database storages and file systems. Also additional interpreters and virtual environments can be used to create as comprehensive support as the applications may need.

(23)

C l i e n t e n v i r o n m e n t

S e r v e r e n v i r o n m e n t

W e b s e r v e r

A n o r d i n a r y w e b s e r v e r w i t h a d d i t i o n a l s u p p o r t f o r J a v a a n d P H P

F i l e s y s t e m

M y S Q L d a t a b a s e s y s t e m

J a v a V i r t u a l M a c h i n e T o r u n s e r v l e t s

I n t e r p r e t e r T o r u n c o d e i n P H P D a t a r e p r e s e n t a t i o n

X M L , J S O N e t c .

U s e r

G o o g l e G e a r s B r o w s e r p l u g i n

D a t a b a s e A P I L o c a l S e r v e r A P I W o r k e r P o o l A P I

B r o w s e r A n o r d i n a r y b r o w s e r w i t h s u p p o r t f o r H T M L , C S S a n d J a v a S c r i p t

P u l l - T h e c l i e n t p u l l s t h e i n f o r m a t i o n f r o m t h e s e r v e r .

P u s h - T h e s e r v e r p u s h e s t h e i n f o r m a t i o n t o t h e c l i e n t .

S e r v e r - s i d e a p p l i c a t i o n U s e s J a v a , P H P , M y S Q L e t c . C l i e n t - s i d e a p p l i c a t i o n

U s e s H T M L , C S S a n d J a v a S c r i p t

W e b r u n t i m e e n v i r o n m e n t s V i r t u a l e n v i r o n m e n t s , c o m p a r a b l e t o t h e c l i e n t sW e b r u n t i m e e n v i r o n m e n t s V i r t u a l e n v i r o n m e n t s , c o m p a r a b l e t o t h e c l i e n t sW e b r u n t i m e e n v i r o n m e n t s V i r t u a l e n v i r o n m e n t s , c o m p a r a b l e t o t h e c l i e n t sW e b r u n t i m e e n v i r o n m e n t s V i r t u a l e n v i r o n m e n t s , c o m p a r a b l e t o t h e c l i e n t s

G o o g l e W e b T o o l k i t A d d i t i o n a l J a v a S c r i p t A P I

D o j o T o o l k i t A d d i t i o n a l J a v a S c r i p t A P I

Figure 2.1: Web technologies interacting

8

(24)

2.1 Environments

An application is a computer program that is designed to work with predetermined tasks and in a given environment. The number of tasks an application can perform is up to the programmer to decide when creating it, and how many tasks an applications can do has no clear upper bound.

The environment instead is often very strict, and has a restricted number of possibilities due to the operating system it was designed to work in. With this restriction it is more often then seldom that the programmer will have to make several versions of the same application, one for each environment which to the user looks and behaves the same way. This is a time-consuming and expensive procedure which should be avoided.

Since the day Internet became a standard in industrialized countries, the possibilities for applications to leave the scope of the local computer has increased. Applications not using Internet are today quite unusual, they either use it as their main purpose or for simple update checks. This has lead to an increased number of applications written for the web, and also for the web browser. Some of them are regular applications while many of them are just for advertisement. The design of these applications determines where the workload is done, either on the server or on the client. With higher performance capabilities on the clients, the design should be moved on to the client and its web browser when applicable, which is powerful enough to deliver both performance and stability. It is not just regular applications that are being developed for the web browser, also almost complete operating systems are today available to hold a users documents, applications and whole desktops online and accessible everywhere and anytime. Combining the rapid hardware development for computers, both in performance and size, with the spreading of fast Internet connections, the user is given a great possibility to always have the desktop available. Among the different drawbacks web applications and web operating systems have are their dependency on network connectivity, speed and consistent user interface.

A difference between web browsers and operating systems as application environments are that there are several of different web browsers available, with different versions and with different plugin versions. Their number of combinations outnumber regular operating systems many times around. This is making it very difficult to create a single application that will look and behave the same way on all available browsers. If web browsers are given a single standard to how information should be presented, the developers will in the future only have to consider client aspects as for example different

(25)

screen resolutions.

2.2 Programming languages

This section will cover some of the most common programming languages used for developing web applications.

2.2.1 Server language

The language used for a server-sided web application is many times a choice for the programmer, since all have favorites of their own. When selecting the language to use there are some differences to how the source code is executed.

Compiling languages A compiling language uses a compiler that translates the source code to machine code, which the hardware can understand.

Since the target code is understandable by the hardware it is faster than other implementations. Regarding web applications a strict compiling language is rather unusual, this is because these languages are low-level and a web application is rarely that close to the computers hardware.

Interpreting languages With an interpreting language an interpreter reads the code line by line, and executes it without translation. Today often a combination of a compiler and an interpreter is used; the compiler translates the source code into an intermediate form, which the interpreter uses as input. A language that uses this combination is Java, and its intermediate form is bytecode. The Java bytecode is targeted towards the JVM, which executes the code in a virtual environment.

Scripting languages A scripting language is not consider a real programming language, its rather used to allow control of other software applications.

The source code is deployed directly without any translation, and it is read and executed step by step by an interpreter. Popular languages regarding web applications and web servers are PHP and Python.

Compiling languages are good since they often create a single archive file to deploy, their downside is that they need a few steps before they are accessible to the user. A scripting language is accessible directly, but is on the other hand not compressed into an archive which can lead to a lot of files to deploy. During development a scripting language can be good since

10

(26)

changes are visible at once. When choosing language the developer will have to decide between easy deployment or easy editing, roughly said.

2.2.2 Client language

If the client is a web browser then the choice of language is quite restricted.

Most web material is presented in the form of HTML or XHTML, which are standards for presenting text, hypertext and media. XHTML is just an extension of HTML which uses the syntax of XML, explained below in section 2.3.2. HTML by itself is very static and can not do much more than present its content. By adding a scripting language HTML will improve with the ability of dynamic structure and processing capabilities. Finally by adding CSS the presentation from HTML will be improved with styling. Together these three types of languages are very powerful and can be used to create applications close to the same performance and visual effects of a regular application.

Client side scripting When dealing with client side scripting in a web environment often JavaScript [1] is used, which is one of the most popular scripting languages regarding for web based clients. During web development, scripts can easily be included or imported to a web page, giving it new capabilities and making it most of all dynamic. The dynamic feature is gained through access of the DOM, explained below in section 2.3.3, either to gather information from it or to alter it. Two important aspects about JavaScript is that is does not have the ability to import packages of already written code in a script, it need to import it to the web page during loading.

The second is that it need to have access to the DOM or window object in order to interact with the user, where the window object is the browser window in which the script resides.

2.3 Technologies

Web applications that have some of a desktop applications characteristics are called rich Internet applications [2]. They often gain their richness from browser plugins or for example through a JVM. This technique derive from desktop applications that have features making them richer than other applications. Antivirus applications often do automatic updates of their virus definitions by requesting the latest available information from a main server. Others will scan a server hosted by the developer for new updates and upgrades, instantly giving the user the newest version of the application.

(27)

2.3.1 AJAX

A common technique today is AJAX [3], which is based on a combined usage of JavaScript, HTML, CSS and XML. Despite the name there is no requirement to use JavaScript or XML, or to make the communications asynchronous. With JavaScript the web page is given capabilities to make computations on the client machine and removes the demand where all computations are residing on the server. Since the script running on the web page is loaded in the browser window, the web page will be stalled during heavy computations and if no status of the computation is presented to the user it might give the feeling that the browser has crashed. Problems like this are for example synchronous requests from the client to the server, where the client sends a request and waits until the server has responded, which may take a while due to big data requests, slow bandwidth or a high workload at the server. An illustration over synchronous requests are shown in figure 2.2(a). One of the ideas behind AJAX is to allow the client to request data from the server asynchronous without stalling the client. This is done with a response handler being registered with the request and to be executed when the servers response is received. It means that the client will send the request and then continue its computations with the request waiting to be processed only when it arrives. This asynchronous method is shown in figure 2.2(b).

(a) Synchronous communication (b) Asynchronous communication

Figure 2.2: Synchronous and asynchronous communication Image reference:

http://www.adaptivepath.com/images/publications/essays/ajax-fig2.png

12

(28)

2.3.2 Data representation

In a server and client architecture data will be transported between the two participants. In what form the data is being presented to the participants is not only a question of how it should be sent for the other side to understand what it is and what to do with it, it is also a question about the amount of data being transmitted over the network connection. For wired connections the amount of data is not as big deal as it is with wireless connections, where the bandwidth is often limited.

XML An XML document [18] is used for creating custom markup languages designed for a special kind of purpose. It allows the user to design the elements used for markup and the documents structure. Its basic usage is in sharing structured data over the Internet, encoding documents and serializing data. Below is an XML structure describing a book about JavaScript.

<book>

<title>JavaScript: The Definitive Guide</title>

<author>David Flanagan</author>

<publisher>O’Reilly Media Inc</publisher>

<chapter>Chapter 1</chapter>

</chapters>

</book>

XML uses two levels of correctness. The first is that an XML document need to be well formed, which means that every start-tag (< >) need an end-tag (</ >). The second level is that it need to be valid, meaning that it should be matched against an XML-schema describing the elements used by the XML document. If XML is used it is considered very robust since the structure is well defined where each element has a start and an end, which makes parsing easy. The downside of XML is the addition of characters used in the tags describing the information.

JSON JSON [12] [13] is a format considered to be light weighted and human readable compared to similar alternatives, like XML. Its usage is mostly sharing data and describing data structures in a serialized way. Below is a JSON structure describing a book about JavaScript.

(29)

{

‘‘title’’: ‘‘JavaScript: The Definitive Guide’’,

‘‘pages’’: ‘‘994’’,

‘‘author’’: ‘‘David Flanagan’’,

‘‘publisher’’: ‘‘O’Reilly Media Inc’’,

‘‘chapters’’: [

‘‘Chapter 1’’,

‘‘Chapter 2’’,

‘‘Chapter 3’’

] }

Compared to XML, JSON lacks the need to be well defined but still need to be valid in order to avoid being misinterpreted. A JSON-schema is a specification for the structure and tells the document what information it should contain. Due to the lack of the well definition demand, JSON does not add close to the amount of extra characters XML adds to describe the content.

2.3.3 Document Object Model

The Document Object Model [16], DOM, is a language used to access and update content, structure and style of documents. The language is platform and language independent which makes it highly adoptable to any program and script. Elements in the document can be accessed through the hierarchical location or by their given names. For example accessing an input field in a form from the web page could look like this:

“document.formName.inputName”.

2.3.4 Information spreading

In computer network relationships the need to spread information from the server to the client can be crucial. There are two main strategies used for this and they are called Pull and Push, depending on which of the participants that begin the transaction.

Pull technology When information is pulled, it means that the client request the information it need from the server. Pulling is the most common way to spread information regarding network communication. But if the client request updates to often it can create unnecessary workload for the

14

(30)

server. The amount of requests should be tuned due to the informations usage.

Push technology With push technology, or server push, the server has control over when information is announced to the client. This can make the client a target since advertisement can be spread without the client wanting the knowledge of it. For this to work a connection between the client and server need to be active, in which the server can push the information directly out to the client.

2.4 Plugins and toolkits

Developing web applications is often a more tedious process than with desktop applications. This is due to the different browsers and their own interpretations of web content. There are available plugins for the browser and toolkits for the application with different approaches to aid the developer in its process.

2.4.1 Google Gears

By installing a plugin to the web browser a numerous of new features becomes available for web applications using JavaScript. Among the features Google Gears [9] deliver are offline mode and parallel script execution. Web pages using this plugin requires that the browser has the plugin installed and running, otherwise the features are unavailable.

Database API The Database API provides a local database usable in JavaScript for web applications. Google Gears does this through the open source SQLite database system. By creating a local database the client can take advantage of already downloaded information, instead of requesting them each time needed. Also an application can save status and content from a computation, and later in another application and/or browser window access the same database and reuse the stored information.

LocalServer API The ability to work offline with a web application can seem impossible. The LocalServer API provides the web browser with an ability to at least act as it is online, when it in fact is offline.

Two resource stores are needed for this to work, which both run in the background collecting information as the user is doing the normal browsing. The first store is called ResourceStore and it captures data

(31)

files addressed with a URL, for example images. The second store is called ManagedResourceStore and it captures the URLs declared in the sites manifest file. The ManagedResourceStore is automatically updated when new versions of the URLs are available on the server, keeping the client repository up to date. The LocalServer basically works as a layer between the server and the client, and can serve the client with locally stored information instead of requesting the servers version every time. With this ability the client will not be aware of the lost connection, since the pages are served from a local repository. When the connection is restored the ManagedResourceStore automatically checks with the server to see if the manifest file has been updated, and if so the local repository is updated. The manifest file has an entry called version, which the client uses as a reference to see if a new version is available on the server. If the user in offline mode tries to access a URL not declared in the sites manifest file it will fail, since the ManagedResourceStore did not know it should have captured it.

WorkerPool API One of the biggest drawbacks with client-side JavaScript is that it only supports serial execution. In a complex client architecture a lot of computation might be needed to execute in parallel, which will result in a queue where each execution replaces the next until they are all done. This will give the user the feeling that the application lacks an executing flow. The WorkerPool API gives the developer a possibility to make JavaScript execute in parallel. It works as a pool where a collection of processes are held. Each process, also called a worker, consists of a message handler combined with application specific JavaScript code. A worker is created either by the address to a JavaScript file, or by the content of a function. Each worker will execute in its own environment, unaware of the rest of the application. The only connection a worker has with the application is through the message system, in which each worker has a unique id number. The consequence of a worker not being aware of the rest of the application is that it does not have access to the DOM or window object, which makes some of the predefined JavaScript functions unaccessible.

2.4.2 Toolkits

Developers that are creating web applications often spends a big amount of time fixing errors and bugs appearing in some of the browser editions, but not in others. The benefits of using a toolkit in the development is to use already working solutions, and not reinvent fixes for frequently occurring errors. The toolkits mentioned below uses JavaScript for the client-side scripting, and are delivered as powerful APIs ready to be used.

16

(32)

Dojo Toolkit This toolkit [14] is an open source JavaScript API which will shorten the time between idea and implementation. Among the features in Dojo Toolkit are DOM-manipulation, animations, AJAX events and a package system JavaScript lacks. The structure is a single light-weighted entity of 26KB which can be expanded depending on the extra features needed.

Google Web Toolkit Google has taken another approach with their toolkit [10] than the Dojo team. With GWT the developer will use Java as programming language without the web browser being required to run a JVM. The developers toolkit is equipped with a compiler that creates optimized JavaScript code from the written Java code, and the resulting scripts will work across all major browsers. Handwritten JavaScripts can be inserted to the Java source code by using the JSNI, giving the developer even more freedom.

(33)

(34)

Chapter 3 Implementation

This chapter begins with ideas on how to proceed with the identified requirements and obstacles, in order to develop a proof-of-concept server architecture. It continues with describing the communication used, both internal and external. That follows by the implementation covering both the client-side and server-side architectures. It ends with a section about applications and how a simple API can be built in order to work with the architecture.

3.1 Ideas

The first section describes the requirements and obstacles that need to be solved before an implementation can begin. It follows with suggestions to how a suitable solution might look like, and it ends with the chosen data representation and server language.

Requirements The proof-of-concept architecture should support:

• automatic application deployment or announcement on client, when installed on server

• offline mode

• parallel execution Obstacles

• Data representation

• Language for server-side architecture

(35)

To announce information that is made available on a server, the use of either pull or push technology is required. Push technology is unavoidable if the information must be delivered instantly after it has been posted on the server. But if a client can decide for itself when the information should be delivered from the server, it can use pull instead. Implementing a push delivery system will require an open connection between the server and client, making them unable to go offline. If pull is used instead, the client is allowed to disconnect whenever it wants and the server does not need to keep track of all active information depending clients. It also gives the client total control of when the information should be transmitted.

The second and third requirement for the proof-of-concept architecture, support for offline mode and parallel execution, can be solved by using, respectively, LocalServer API and WorkerPool API as parts of Google Gears.

By extending the client further with a few more features like local storage, automatic content backup, automatic state backup and client independence, the solution will become more and more similar to a small web operating system.

• Local storage can be achieved by using the Database API as part of Google Gears.

• Automatic content backup and automatic state backup are both possible since the WorkerPool API supports parallel execution, where a background process could frequently send the local client storage to the server to keep it updated.

• Client independence is necessary in order for this architecture to avoid being static and unusable.

A normal decision for data representation would be between XML and JSON since they are both adapted to most languages, and encoding and decoding functions often are available. For this implementation another approach was taken. All communication are done by sending a string of tokens, with the pipe-character (’|’) as separator between them. This is a simple way of sending a command with a few arguments between the client and server, assuming the pipe-character will not appear as part of the content.

If a separator is part of the last argument, the damage can be repaired by rebuilding it. Take for example a command that expects 4 arguments, but due to two pipe-characters in the last of them, it is has gotten six arguments instead. By concatenating argument four, five and six with pipe-characters in between, the last argument is repaired and allowed to carry separators.

20

(36)

For the server a scripting language was preferred to enable quick editing, and PHP was chosen. The rest and the visual design of the architecture is a mix of coincidences and the programmers choice and taste.

3.2 Communication

All communication, both internal and external, uses a light weighted structure with the tokens separated with a pipe-character (’|’):

command | arg[0] | arg[1] | .. | arg[n]

Internal Internal communication are all the messages going between one worker and the WorkerPool or between two workers directly. For this to work the WorkerPool is equipped with a built-in message system. One of the reasons for this is that a worker does not have access to the DOM or window object directly and need to go through the WorkerPool to gain access. For a JavaScript code to be valid as a worker, it must contain an onmessage function to handle internal communication.

External External communication are all messages going from the client, either a JavaScript in some HTML page or from a worker inside the WorkerPool, to the server which responds according to the command sent.

3.3 Client implementation

This section starts with the clients layout and structure describing the fundamental parts of it. Secondly the implementation of the WorkerPool and its workers are described in detail. It ends with a detailed description of the LocalServer implementation.

3.3.1 Client layout

The clients layout is kept small to enable usage on mobile devices, such as mobile phones and handheld computers, which often has a limited screen size and resolution. In Appendix A a comparison is made with popular mobile phones available today. Their screens have resolutions around 320x480 pixels (width x height), and with this in mind a prototype needing higher resolutions would not be applicable. The implemented client uses 320x480 pixels as a fixed resolution to enable mobile testing and usage.

(37)

(a) Client framework (b) Client prototype

Figure 3.1: Layout of client framework and prototype

The framework of the client is shown in figure 3.1(a). It consists of three parts, a top row, a bottom row and a working area for the applications in between. The names of the different frames are given by the grid they reside in, counting from top to bottom, and from left to right. Rows are named alphabetical beginning with A, and columns are named numerical beginning with 1.

• A1 - Synchronization: An icon showing the status of the local repository being synchronized with the server, using Google Gears. Three icons are possible; a green ball telling that the local repository is up to date, a red ball telling that an update is needed and a round rolling animation telling that a synchronization is running.

• A2 - Server address: IP address to the server being used.

• A3 - Notification: An icon showing if the server has new updates and/or applications available for the active user. Two icons are possible; either

22

(38)

a light bulb indicating something new is available, or a transparent icon telling that nothing is new.

• A4 - Client menu: A static menu for administration, such as adding and removing applications, help section and log off.

• B1 - Application work area: The biggest frame is dedicated for applications where they can interact with the user.

• C1 - Empty frame.

• C2 - Application menu: A dynamic menu showing all installed applications and their present status, explained below in section 3.5.2.

The size can hold up to ten installed applications.

• C3 - Empty frame.

3.3.2 Client structure

The client prototype works as a regular web page, which is launched into a new window with size 320x480 pixels through a login process where the user is validated by the server. The web page consists of one page built using frames named after the positions described above. As a skeleton, the framepage lies in the back and also holds a few global variables accessible by all minor frame pages. Among them are the users name and the ManagedResourceStore used by the LocalServer, explained below in section 3.3.4. Each minor frame page is kept to a minimum, except the pages controlling the application work area and the application menu which need a lot of code to work. In figure 3.2 the structure is described with its connections to different Google Gears additions, and in figure 3.1(b) the finished prototype is shown directly after the client has loaded.

Local databases are not given an own section in this chapter. That is because there is not so much to say about them except that they are accessible to all JavaScripts running in the prototype.

The HTML code in the implementation is kept to a minimum to avoid closing any doors and making the structure static. Most code is generated from JavaScripts and will support alterations during runtime.

(39)

C l i e n t s t r u c t u r e

S t r u c t u r e o f c l i e n t h o l d i n g t h e f r a m e s

W o r k e r P o o l A P I ( g o o g l e . g e a r s ) S y n c h r o n i z a t i o n

S e r v e r a d d r e s s

A p p l i c a t i o n w o r k a r e a C l i e n t m e n u N o t i f i c a t i o n

A p p l i c a t i o n m e n u

A d m i n i s t r a t i o n A p p l i c a t i o n c o n t r o l

H e l p p a g e

S i g n o f f

L o c a l S e r v e r A P I ( g o o g l e . g e a r s )

D a t a b a s e A P I ( g o o g l e . g e a r s )

Figure 3.2: UML of client structure

3.3.3 WorkerPool

The WorkerPool is placed in the frame containing the application menu, since the applications are both accessed and controlled through that frame the choice of placement was obvious. The workers are divided in two groups, shown below in figure 3.3, with one dynamic group which the user has control over by installing and uninstalling applications and with one static group which the client architecture uses.

W o r k e r P o o l A P I ( g o o g l e . g e a r s )

S t a t i c w o r k e r s D y n a m i c w o r k e r s

W o r k e r

W o r k e r W o r k e r

W o r k e r A p p l i c a t i o n # 2

A p p l i c a t i o n # n

O u t p u t W o r k e r

B a c k u p W o r k e r

U p d a t e W o r k e r W o r k e r P o o l

A p p l i c a t i o n . .

W o r k e r W o r k e r

Figure 3.3: UML of WorkerPool implementation

24

(40)

Output controller The only static controller that is implemented has a crucial task to the prototype. It works as a receiver taking output from all other workers and storing it in a local database, with the name of the user and the name of the application as key pair to find it later. This is the only way an application can send information to the user.

During the development, two solutions were compared on how information from the applications are presented. Both solutions are described with UML in figures 3.4 and 3.5.

• 1-1: All applications share one worker and one output page. With this solution a control function is needed to decide which application that has the focus. With the focus known, an update of the output page with the correct information can be done.

• M-M: Each application have their own output page, giving many workers and many output pages. If all applications would have their own output page, the focus of which application that is on top would not matter when updating the output. The source of the middle frame holding the application work area should be changed to correct output page, when the focus changes.

For the implementation the 1-1 solution was used, which seemed to be the same work using less files. Of course one could expand the usage of application specific output pages and give each application their own database for storage and their own output worker, but that would only make the architecture more complex and harder to maintain. With one database present, the backup is made simple.

When an application has loaded and is presented to the user, all information used for presentation can be found in the database. If the user interacts with the application and alters a value or some how changes the original appearance, these changes need to be saved in the database through the output worker. Changes that is not saved will be lost during the next update, since the output page only looks for information in the database registered to the user and application.

(41)

O u t p u t c o n t r o l l e r 1 - 1

W o r k e r P o o l A P I

( g o o g l e . g e a r s ) W o r k e r P o o l

O u t p u t W o r k e r W o r k e r

S t r u c t u r e o f c l i e n t h o l d i n g t h e f r a m e s

A p p l i c a t i o n w o r k a r e a

A p p l i c a t i o n m e n u D a t a b a s e A P I

( g o o g l e . g e a r s )

Figure 3.4: UML of output controller, 1 worker - 1 output

O u t p u t c o n t r o l l e r M - M

W o r k e r P o o l A P I ( g o o g l e . g e a r s )

W o r k e r P o o l

W o r k e r A p p l i c a t i o n # 1 S t r u c t u r e o f c l i e n t

h o l d i n g t h e f r a m e s

A p p l i c a t i o n w o r k a r e a - s o u r c e o f f r a m e -

A p p l i c a t i o n m e n u

A p p l i c a t i o n # 1 o u t p u t

S o u r c e o f f r a m e c h a n g e s d u e t o f o c u s o f a p p l i c a t i o n

D a t a b a s e A P I ( g o o g l e . g e a r s )

Figure 3.5: UML of output controller, many workers - many outputs

26

(42)

Backup controller - Not implemented The first static worker that is not implemented is the Backup controller which should take care of making automatic backups of the clients local databases. It could be done by using a timeout between the actions, in which the controller should check against the server for a checksum of the already saved database content, and update it if necessary. Since the controller resides in a worker, it can work in the background not disturbing the user. The implementation was not done since this controller is not needed in order to show that the architecture works and can handle an offline mode. It would also need a more extensive server-side then the one implemented.

Update controller - Not implemented The second static worker that is not implemented is the Update controller which should check the server for updates of new applications and other announces made to the user.

A fine tuned timeout is a simple procedure to make this work with pull technology without making the servers workload to high. This controller is not implemented of the same reason as the backup controller.

3.3.4 LocalServer

The usage of the LocalServer API was a straight on procedure and did not need a lot of changes in the already working online prototype. In the implementation only the ManagedResourceStore is used. All files, including images, are declared in the manifest file making the ResourceStore superfluous.

Caching to work offline During the client startup the needed store is created, and also saved in the frame page in the new window. After that the client is being started and the manifest file is reviewed. Since the manifest file contains entries for each file needed with this specific web page, that is the client, an automatic update of the local repository can be done. If the connection would be lost after this, all files are already present in the local repository and the client will work as usual.

The user validation before the client prototype can start, is not possible to do when the client starts in offline mode. This has been solved by storing each validated user and password as a pair in a local database, which is used when a connection is not available, and updated if the pair is not present in online mode.

(43)

3.4 Server implementation

For the prototype to work a static server structure was sufficient, a UML of this is shown in figure 3.6. The communication center is the only part visible and reachable from the outside. It is constructed to take a command followed by a number of arguments, the arguments depend on the command. If the command is recognized, its arguments are sent to an internal function which then processes them. The response to the client is made from the function or directly from the communication center, depending on the command. Besides PHP as server language, MySQL was chosen as database system to hold all necessary server-sided information for this architecture.

S e r v e r s t r u c t u r e

C o m m u n i c a t i o n c e n t e r

M e s s a g e s t r u c t u r e : 0 : c o m m a n d 1 : a r g [ 0 ] 2 : a r g [ 1 ] 3 : . . .

M y S Q L

D a t a b a s e s t o r a g e

F i l e s y s t e m / w w w _ r o o t / s e r v e r /

u s e r s . i n c

H o l d s a l l u s e r s p e c i f i c f u n c t i o n s

v a r i a b l e s . i n c

S e r v e r s p e c i f i c v a r i a b l e s a p p l i c a t i o n s . i n c

H o l d s a l l a p p l i c a t i o n s p e c i f i c f u n c t i o n s

Figure 3.6: UML of server structure

3.5 Applications

In the implemented architecture an application is a program residing on the web server but working inside the client architecture. This section covers their deployment on the server and client, the needed structure to allow it to work inside the architecture, how applications are controlled by the user, and how they are loaded during startup. The section ends with test applications used during the implementation and evaluation.

3.5.1 Application deployment

A server installation of a client application is done in two steps. First the application folder is uploaded to the server, and placed in the application root

28

(44)

folder. The servers file system structure if described in figure 3.7. Secondly the new application need to be activated, which will make it visible for all client users. This is done by making an addition in the database controlling the installed applications, a graphical interface is preferred to avoid mistakes during database altering. When the database has been updated with the new application, it will become visible to clients looking for updates and available applications.

S e r v e r s t r u c t u r e o f f i l e s y s t e m

A P I s p e c i f i c f i l e s / w w w _ r o o t / s e r v e r /

S e r v e r s p e c i f i c f i l e s

C l i e n t g e n e r a l f i l e s

a p p l i c a t i o n r o o t f o l d e r a p i

a p p l i c a t i o n _ 1

a p p l i c a t i o n _ 2

a p p l i c a t i o n _ . .

a p p l i c a t i o n _ n

Figure 3.7: Server structure of file system

3.5.2 Application structure

Each application created need to use a predefined structure, before any new code can be added. This structure is available at the server and it gives the application a communication system, both for sending and receiving internal messages, along with functions for starting, stopping and changing focus. In Appendix C a minimal application is shown with the necessary functions and a possible continuation on the internal message system to handle the new commands this application might need. In order for the application to be loaded and work offline, a unique manifest file is needed declaring every file it uses. How applications are loaded is described in section 3.5.4. For new applications no limits are set, as long as it follows the built-in structure.

An application that is loaded will be found in the application menu with its icon, and a colored border surrounding it. This border will tell the user what state the application is in. The states are shown in figure 3.8; standby

(45)

(yellow), starting (orange), running (green) and stopping (red). Starting and stopping are not used in the prototype since the time it took for the test applications to start and stop was neglectable, but they are implemented for possible usage. The colors of the application borders are set for the user to easier recognize the different states. The user controls the applications state by clicking on the icon. Single clicking will start the application if it is in standby mode, if it is already running it will be given the focus instead and double clicking will stop a running application.

(a) Standby (b) Starting (c) Running (d) Stopping

Figure 3.8: The different states of an application and their color For an application to work it need to have a few files located on predetermined places. The files are described below and the places can be seen in figures 3.7 and 3.9.

• The application structure which is found on the server among the client general files.

• A manifest file for loading the application before launch and also for allowing it to be harvest by the local repository to work offline.

• An icon with size 20x24 in png format, in the img directory.

• Application specific file(s) which extends the general structure and gives the application its specific behavior.

30

(46)

A p p l i c a t i o n s t r u c t u r e o f f i l e s y s t e m

a p p l i c a t i o n n a m e i m g

A p p l i c a t i o n m a n i f e s t f i l e

C l i e n t s p e c i f i c f i l e ( s )

A p p l i c a t i o n i c o n

Figure 3.9: Application structure of file system

3.5.3 Application control

When a client is started, the installed applications for the active user is loaded and activated. Installing a new application, or uninstalling an already active application is done by using drag-and-drop functionality. On the client a special page for application control should be available. Its design should hold at least two containers of icons, one for the server-side and available applications to install, and one for the client-side and installed applications.

If more containers are to be used, it could expand to more server repositories.

By dragging an icon from the server container and dropping it on the client container will start an automatic installation. If an icon instead is dragged from the client container and dropped on the server container it will be uninstalled. If the application is running in the background, it must first be called to stop and then it should be removed from the local repository. The use of drag-and-drop for application control will ease the users interaction.

During the client development an implementation was done to test how this control might work. It uses Dojo Toolkit for drag-and-drop support, and shows in figure 3.10 how an application can be dragged from the server container over to the client container. Even though this feature works, it has not been included in the prototype. This is because it was only created to show that sufficient information about the application and the two containers needed for a real implementation could be extracted from the dragged icon.

(47)

Figure 3.10: Drag-and-drop from server to client container

3.5.4 Application loading

Since each application running on the client is doing that as a worker in the WorkerPool, only pure JavaScript is allowed. For this architecture to be able to handle an external API, that is not part of the JavaScript package, some sort of import system is needed. JavaScript is not yet equipped with a proper solution to import JavaScript source code to another JavaScript. Dojo Toolkit has a way for packages to be dynamically added to the application, but for this implementation the LocalServers manifest file is used. In the manifest file all files the application need in order to work offline is declared, which then also tells what APIs the application uses. When an applications worker is about to be created, its manifest file is parsed and all JavaScript files are extracted. To each JavaScript file an XMLHttpRequest is done collecting the content, source code, of the file. Each files source code is then added together and sent to the WorkerPool for the creation of this applications worker, allowing external APIs to be used.

3.5.5 Test applications

For the client architecture to be tested, four different applications were created. The first which is used twice in the client only prints a text to the output with a delay of 1000ms in between, the printing can be controlled as turned on and off. These two is used to prove that parallel execution between workers is possible. The second application only sends requests to the server as a ping, and asking for the servers local time. The responses from the server is printed on the client, when received. The third application takes two arguments from the client; user name and password, and sends these to

32

(48)

the server for validation. The response, whether it is a valid or invalid user name and password pair, is printed. The second and third application is used to prove that a worker has the ability to communicate with an external part, without going through the WorkerPool accessing the DOM or window object. The fourth and last application is a classic Hello World! application which shows how simple printing and form usage with action can be done.

The complete architecture is runnable in offline mode. The only restriction is obviously that applications can not use a network connection while being disconnected, but internal processing is possible.

3.6 API

To show how an API can be created, the standard HTML form elements have been used. The API is equipped with functions taking the necessary arguments for the different form elements, and returns a string with the complete HTML code. The code is then prepared and ready to be sent to the application work area, through the output worker. The API is created as a JavaScript file and placed in the API directory on the server, accessible by all applications.

In Appendix B all implemented APIs and functions are listed, and in Appendix D it is shown how an API can be used. It is shown both how it is included in an applications manifest file and how its functions are used.

(49)

(50)

Chapter 4 Evaluation

This chapter evaluates the proceedings made towards this projects purposes.

In the end experiments made on the internal communication system and data representation are described, followed by their results. The complete tests and results are located in Appendix E, but the same results are also presented in section 4.2.

4.1 Proof-of-concept architecture

The purpose was to develop a proof-of-concept server architecture for web applications. The architecture should use Google Gears to improve the users uptime, even when a connection is not possible. It should also automatically deploy or announce web applications for client installation, when installed on the server.

Google Gears WorkerPool API made it possible for the architecture to execute JavaScript in parallel, which enabled it to be hosted on the client and avoiding unnecessary workload for the server. Google Gears LocalServer API gave the architecture support for offline mode, making the client independent on the server when it has been locally cached. The idea to automatically deploy an application that has been installed on the server was not used, since it could have lead to an unpredicable bandwidth usage. But close to the rejected idea is the service to announce the new application, and that has been supported. This service will require an implementation of the update controller described in section 3.3.3. A feature that was not found in Google Gears is a package handler that is needed to support additional APIs. This problem was solved using parts of the LocalServer API and WorkerPool API, and is described in section 3.5.4.

(51)

The data representation used in the implementation, both for internal and external communication, only adds separators between the command and arguments. This solution may not be applicable in a real implementation, but was considered an easy and fast choice for the architecture. A defense to the choice is that it fills the purpose of its task and the implementation is despite all just a proof-of-concept architecture, not created to make easy interpreted messages.

As long as the future applications follow the minimal application structure shown in Appendix C, no boundaries should limit the developers intentions.

In Appendix D a classic Hello World! application is presented with complete source code to show how an application can be built using both a simple and an advanced approach.

4.2 Experiments

The second purpose was to investigate performance implications during runtime of this architecture. This has been done through two quite different experiments. The first covers the implementation of the WorkerPool API and the second which is more of a theoretical experiment on the choice of the encoding in the data representation. The complete tests and their results are located in Appendix E, but the same results are also presented below.

Internal communications The experiment on the internal message system is a measurement of the messages sent in the WorkerPools built in message system during different common tasks.

• Test 1: Printing: output being sent from an application to the output worker, followed by an update of the screen.

• Test 2: Client startup: from the creation of the client window until it is fully up and running.

• Test 3: Application startup: from the user interaction thats starts the application until focus has been changed.

• Test 4: Application switching: both switching from running to standby and from running to running.

• Test 5: Application stopping: running application is being stopped.

36

Implementation of a proof-of-concept mobile web OS architecture

M A S T E R ' S T H E S I S

Implementation of a Proof-of-concept Mobile

Web OS Architecture

Mats Hamberg

Implementation of a

Proof-of-concept Mobile Web OS Architecture

Mats Hamberg

Preface

Abstract

Abbreviations

Contents

List of Figures

Chapter 1 Introduction

1.1 Application development

1.2 Application deployment

1.3 Network dependency

1.4 Possible solutions

1.5 Related work

1.5.1 Web operating system

1.5.2 Google Chrome

1.5.3 HTML5

1.6 Purpose

Chapter 2 Theory

2.1 Environments

2.2 Programming languages

2.2.1 Server language

2.2.2 Client language

2.3 Technologies

2.3.1 AJAX

2.3.2 Data representation

2.3.3 Document Object Model

2.3.4 Information spreading

2.4 Plugins and toolkits

2.4.1 Google Gears

2.4.2 Toolkits

Chapter 3

Implementation

3.1 Ideas

3.2 Communication

3.3 Client implementation

3.3.1 Client layout

3.3.2 Client structure

3.3.3 WorkerPool

3.3.4 LocalServer

3.4 Server implementation

3.5 Applications

3.5.1 Application deployment

3.5.2 Application structure

3.5.3 Application control

3.5.4 Application loading

3.5.5 Test applications

3.6 API

Chapter 4 Evaluation

4.1 Proof-of-concept architecture

4.2 Experiments