A Method for Distributing Web Applications

Download PDF
4 downloads 157474 Views 2MB Size Report
Comment
However, the installation and configuration of web applications are not as easy as traditional desktop applications since the framework on which applications are ...
A Method for Distributing Web Applications Ki-Hyuk Nam, Ki-Seok Bang*, Wan Choi Software Service Research Team, ETRI College of Information and Electronic Engineering, Hallym University* {nam, choi}@etri.re.kr [email protected]

Abstract  Web has influenced the form of software applications. These web applications are generally difficult to distribute by novice users since their usage was restricted to the network based massive servers which has many server modules requiring difficult configurations. However, web applications became widespread and used in daily basis from simple utility programs to PIMS. This paper proposes a web application model and distribution method for portable web applications to adapt to current trends. The most salient features of the method are click & run interface for installing, configuring, and executing web applications, and offline execution by providing a web server, a DBMS on movable disks such as USB memory sticks. The method has been verified by developing a simple application platform and package builder supporting applications written in Ruby and PHP. Keywords  web applications, software distribution

engine into a framework. The distribution method which provides users with click-and-run metaphor can naturally be produced once the framework is implemented since it simplifies and formalizes its configuration process All the user has to do is just downloading application packages which are compliant to the framework. This paper presents a distribution method for portable web applications as follows. The next section gives a brief survey on technologies related to web applications. In Section 3, we analyze web applications in terms of online dependency and usages and then classify them into categories. Section 4 summarizes core requirements for the web application framework and we suggest a basic architecture for it in section 5. On top of the framework, section 6 explains the distribution method for web application and our prototype implementation. Finally, we conclude and present future works in section 7.

1. Introduction

2. Related Works

Web has become a major computing interface for various purposes ranging from personal homepages to software applications such as email clients, word processors and enterprise solutions. Web applications are recently replacing desktop applications due to their easy development and accessibility, so that their usage needs to be expanded and the underlying technologies should be evolved to adapt to the desktop computing environments. As our activities are going to be more dependent on computing devices which are ubiquitous in our daily life, it is required that users carry and execute their workspaces on devices from USB flash memories to mobile phones at any time without limiting their functionality. However, the installation and configuration of web applications are not as easy as traditional desktop applications since the framework on which applications are run has at least three components including web servers, server-side script engines and database management systems and each of them has their own configuration so the setting up them as one system would be difficult for novice end users. Furthermore, web applications were supposed to be fixed on servers so the portable usage of them have never considered. In this paper we suggest a web application model and a framework that are suitable for portable desktop environment where you can carry web applications on portable storages and execute them on any computing machine by just one-click. To support portable desktop environments, web applications should be able to reconfigure themselves and to run offline by incorporating web server, database, and server-side script

WHATWG’s web applications standards, which recently integrated into W3C, have also been working on the web application standards[1][2]. Google and Yahoo have released gadget or widget platforms to draw web applications into the desktop realm, but they rely on web services from remote servers so they cannot be run offline and there are no standards applied to them[3][4]. Dojo Offline Toolkit and Google Gears made web applications run offline and be synchronized to the web server whenever they are online[5][6]. Applications need to use their APIs for supporting offline functionality and should be run on the browser that has installed those toolkits. Adobe AIR/Flex, MS Silverlight, and Mozilla’s XUL are the most famous RIA (Rich Internet Applications) technologies and they provide their own languages and platforms for implementing RIA concepts[7][8][9]. APM (Apache+PHP+MySQL) has been considered to be the most famous and reliable web framework. WOS and PortableWebApps are the well-know APM framework supporting portable usages[10][11]. InstantRails added Ruby on Rails framework on APM settings so that many of Rails developers use it on their windows machines[12][13]. POW (Plain Old Webserver) suggested a very interesting idea that a light-weight web server is integrated to the Firefox browser which also has an embedded SQLite. It also supports server-side Javascript (SJS) that benefits developers to write both client and server part in one language[14].

ISBN 978-89-5519-136-3

-2179-

Feb. 17-20, 2008 ICACT 2008

3. Web Application Classification To clarify the problem, we first classify the web applications with respect to the internet connectivity and their characteristics. Some applications should always be online by their nature, some are free to internet connectivity, and the others are in between those categories such that connection is optional so that occasional synchronization would be enough for proper execution of the applications. Another classification can be done by characteristics of applications. For example, web forums would be meaningful only when many users from internet contribute to it, but web office programs and personal content management systems can be used in full-time offline environment, while email clients and RSS readers require periodic synchronization. Our scope of web applications are narrowed down to the offline based personal applications which allow occasional online connections and social characteristic.

Blog CMS Forum PIMS Wiki Mail

Table 1. Web Applications Classification Internet Connection Characteristic Offline with occasional sync Personal + Social Online Social Online Social Offline Personal Online / Offline Personal / Social Offline with occasional sync Personal

that users can carry their applications on the portable devices and use them without connecting to the internet. When you develop a web application, you have to be familiar with at least four languages: HTML, Javascript, server-side script language such as PHP and ASP, and SQL for databases. Although most web services for massive users are usually developed by cooperation with members having different roles such as UI design, Javascript programming, server-side module development, and database design, the separation of application logic into client and server is not necessary if the application is for personal desktop purposes because it’s written more than two languages and is difficult to debug. The approach taken by GWT or POW is appropriate to our framework.

5. Web Application Framework We first provide developers and users with traditional web platforms as they are except adding click and run interface and portability support. We tried first approach to support full fledged web applications running on Apache, MySQL, PHP and Ruby.

4. Requirements The requirements for the framework and method we present can be summarized as follows: 1. 2. 3. 4.

Click & Run Portability for movable storage devices Offline support by data synchronization Easy development of GUIs using XML based languages

Complicated installation process degrades accessibility of software applications. That would be one of the reasons why computing environments are moving to the web, since they don’t require any installations or configurations from the end users’ point of view. However, system administrators have to set up applications by reading difficult user manuals and various configuration files, which can be a serious limitation since the desktop environment usually requires end users to manage their applications. Therefore, the first requirement is not an option but a necessary condition for any deployment method for desktop applications. The second requirement has two-folded effects: cross platform and portability. The machines users would be using vary from Windows XP to MacOS X, so applications must be free from considering what the underlying operating systems are by providing standard web framework on them. To be portable, the framework needs to be able to configure itself whenever it’s plugged into the new machine. The offline execution is one of the core requirements for transforming web applications into desktop applications, so

ISBN 978-89-5519-136-3

-2180-

Figure 1. Prototype system architecture

Developers can build their applications using the same way as the existing applications are made. Then the applications are packaged by archiving application files and resources including framework configurations and database schemas.

Figure 2. Packaging and executiong web applications

Feb. 17-20, 2008 ICACT 2008

When you download and click the package distributed from various media, it is unpacked and copied to the pre-defined directory by using click-and-run interface of the framework. Its databases and other configurations are set up before launching a web browser and executing the installed application. This approach easily satisfied click & run and portability requirements and partially implemented offline support without losing compatibility with existing web applications. In order to focus on the requirement 1 and 2 first, we postponed the detailed consideration of requirement 3 and 4 until evaluating the prototype.

6. Prototype Implementation Building a prototype consists of two parts: pack-to-engine interface and portability support. Pack-to-engine interface can be further divided into two parts, a packing tool and a pack recognition interface on the framework. Packing tool is very simple as can be seen in Figure 2. All it does is just archiving related files and additional information for unpacking, installing, and running the application. The information on applications is stored in an XML-based file (pack.xml). We define the package format to have a ‘.free’ extension and used tar2rubyscript for making it a self-extractable package format. The pack recognition interface is simply implemented by registering ‘.free’ extension into the underlying operating systems. We used Windows Registry for the prototype system so the Registry information is checked and set whenever our framework is started.

http://www.youfree.or.kr. We’ve tested and packaged the applications shown in Table 2. Name Blackjax Typo Expenses TextCube phpMyAdmin MoniWiki WebCal

Table 2. Tested Web Applications Usage Platform Game Blog Momey Manager Blog DB Manager Wiki Calendar

Ruby on Rails Ruby on Rails Ruby on Rails PHP (APM) PHP (APM) PHP (APM) PHP (APM)

Packing the applications in Table 2 is semi-automatic: first, just install them on the framework as they are, and then fill in the template configuration files including pack.xml, initialize and launch scripts. Most of the time in making packages consumed here. After analyzing applications, the rest of the process is straight forward. Three of the test applications are rails applications and the rests are PHP applications. The main differences in packaging are the database setting, port assignment and web servers. Rails framework provides database migration support in connection with ActiveRecord functionality, so that we executed the ‘rake db:migrate’ command when we install applications for the first time. However, Typo is packaged after pre-configuring on our framework for the convenience of end users. Whenever users launch a rails application, the framework assigns a TCP port for it until it exits. Rails framework has its own web server called Mongrel so the Apache in the framework acts as a gateway to the rails applications. The click-and-run process of PHP applications is fairly simple: it just unpacks and copies themselves into the program directory, sets the database, and launch web browser. We defined a simple protocol for communicating between Pack-to-Engine interface and Kernel. It uses the 5000 TCP port. The message is a string delimited by comma (,) consisting of application type (Rails or PHP), browser type (Firefox or Internet Explorer), and URL with application path (ex, http://localhost:9000/expenses). The figure 4 shows a screenshot of the prototype execution.

Figure 3. Packaging and executiong web applications

We adopted the same approach as the InstantRails to support portability[12]. It is implemented by managing meta-files for the configurations which manages real conf files for the web framework components such as httpd.conf for Apache, php.ini for PHP, my.ini for MySQL and other files related to the framework. We built a simple rails application for the management of web applications. The framework also provides dynamic port assignment function for the rails applications. The prototype is incorporated into the YouFree system, which is the web-based personal software and contents platform, and you can download it from

ISBN 978-89-5519-136-3

-2181-

Figure 4. Running a web application

Feb. 17-20, 2008 ICACT 2008

7. Conclusion and Future Works We defined web application model and framework from the requirements mentioned in section 3 and 4. Based on the framework we implemented a web application distribution method. It was successfully to show that click-and-run interface and portability support are feasible but failed to fully satisfy the requirement 3 and 4 in section 4, since the database synchronizations are tricky to solve without changing underlying storage mechanism, and the prototype has no solution that renders easy development of GUIs. It is inevitable to modify the application model and prototype architecture. We plan to take the POW(Plain Old Webserver) approach and Google Gears for simplifying development costs and configuration overheads caused by web server and database [6][14]. The framework also demands developers to understand more than three different languages for developing applications. For example, the MediaWiki, one of the best wiki applications, was written in PHP, HTML, JavaScript and SQL for database settings [15]. We are going to adopt Server-Side JavaScript or Google Web Toolkit’s approach to provide a specialized language for our framework with the support of APIs for storage management, framework configurations and GUI. ACKKNOWLEDGEMENT This work was supported by the IT R&D program of MIC/IITA. [2007-S-015-01, Development of a Personalized SW Service Platform on Movable Disk Devices]

REFERENCES [1] http://www.w3c.org [2] http://www.whatwg.org [3] http://www.google.com [4] http://www.yahoo.com [5] http://dojotoolkit.org/offline [6] http://gears.google.com [7] http://labs.adobe.com/technologies/air/develop_flex.html [8] http://silverlight.net [9] http://www.mozilla.org/projects/xul [10] http://www.wos.chsoftware.net [11] http://www.portablewebapps.com [12] http://instantrails.rubyforge.net [13] http://www.rubyonrails.org [14] http://davidkellogg.com/wiki/Main_Page [15] http://www.mediawiki.org

ISBN 978-89-5519-136-3

-2182-

Feb. 17-20, 2008 ICACT 2008