Lightweight Web Application Framework and Its Application

Helping Improve Community Bus Timetables after Japan Earthquake

Yu Kitano

, Hiroki Suguri

and Atsushi Togashi

Graduate School of Project Design, Miyagi University, 1-1 Gakuen, Taiwa-cho, Kurokawa-Gun, Miyagi, Japan

School of Project Design, Miyagi University, 1-1 Gakuen, Taiwa-cho, Kurokawa-Gun, Miyagi, Japan

Keywords:

Web Application Framework, Lightweight Methodology.

Abstract:

We have identiﬁed four typical problems in building web applications: High cost of education for engineers;

difﬁculty of distributed development; scope creep; and coupling of UI and business logic. To solve these

problems, the authors developed lightweight methodology and Perl-based framework for web applications.

In this paper, we discuss effectiveness of our approach compared with existing tools. We have successfully

applied these techniques to development of web application for helping improve community bus timetables,

which illustrates real-world usefulness of the methodology and framework.

1 INTRODUCTION

Northeast region of Japan was severely hit by great

earthquake on 11th March, 2011. Yamamoto City in

Miyagi Prefecture lost two train stations, which were

wiped out by tsunami. Nuclear disaster made it im-

possible to reconstruct the railroads and stations. Peo-

ple who lost their homes were forced to move to tem-

porary dwellings scattered high above hills to keep

away from possible another tsunami. Although bus

routes were restored in downtown, not all hills could

be covered by existing routes and timetables.

Therefore, Yamamoto City rescheduled bus routes

by hand to encompass all habitation areas. How-

ever, the new routes were not welcomed by citizens

because bus stops were placed inconveniently and

timetables failed to match their needs. To solve these

problems, we have collaborated with Yamamoto City

to develop and deploy bus boarding and alighting in-

formation system. By using the system, we were able

to comprehend the bus usage situation and to propose

improved routes and timetables.

The system consists of information gathering sub-

system and information presentation subsystem. The

information gathering subsystem is an iPhone appli-

cation that collects location, time, and number of peo-

ple for boarding and alighting. The data are sent to

server and aggregated there. The presentation subsys-

tem is a web application that displays data analysis

report to decision makers who revise bus routes, and

to citizens who claim improvement of the routes.

Web application is the most popular client-server

model information system today. Standard web

browser is used as the client, which means no addi-

tional component is required to install on the client.

Therefore, both decision makers in the ofﬁce and citi-

zens in their homes can make use of the application

via the Internet. Consensus between provider and

users of community bus is very important.

In this paper, we focus on the web application,

the framework we developed to build web applica-

tions, and methodology behind the framework. Sec-

tion 2 discusses problems in developing web appli-

cations. Section 3 details out proposed methodology

and framework. In section 4, the application is de-

scribed. We compare our approach with Ruby on

Rails in Section 5. Section 6 concludes the paper

by summarizing the outcome and outlining the future

work.

2 PROBLEMS IN DEVELOPING

WEB APPLICATIONS

Generally speaking, following four challenges must

be overcome for effective development of web appli-

cations.

2.1 Learning Cost

Learning cost is expensivebecause wide range of exp-

252

Kitano Y., Suguri H. and Togashi A..

Lightweight Web Application Framework and Its Application - Helping Improve Community Bus Timetables after Japan Earthquake.

DOI: 10.5220/0003996402520257

In Proceedings of the 14th International Conference on Enterprise Information Systems (ICEIS-2012), pages 252-257

ISBN: 978-989-8565-11-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

ertise is necessary. In the case of developing web

applications in Java, it is indispensable to under-

stand HTML, JavaScript, web server administration,

and JSP/Servlet in addition to Java language itself.

Session management and security issues speciﬁc to

web application also increase learning cost. Usually,

knowledge about frameworks such as Struts and Hi-

bernate is additionally required.

A framework is a set of functionalities commonly

required to build applications. Many frameworks ar-

range large number of components to build feature-

rich applications. However, the initial cost of learning

to start using such heavyweight framework is huge.

2.2 Distribution and Integration

Division of work and integration of system is neces-

sary in developing web applications. Multiple tech-

nologies are involved such as server-side program-

ming, database middleware, and client-side design.

Each technology is complicated by itself, and integra-

tion is much more difﬁcult.

MVC model is a traditional approach to logically

divide the system into three components of Model,

View, and Controller. Each component is assigned

a speciﬁc task and communication between the com-

ponents drives the system. MVC model is popular

in modeling and developing web applications (Mit-

suda and Fukuyasu, 2010). However, the model must

be ﬁxed at ﬁrst. Modeling is an intensive and time-

consuming task that becomes bottleneck early in the

development process before distributing the work to

designers and programmers.

2.3 Requirement Changes

System requirements are getting more and more com-

plicated today. Since web is bleeding edge of busi-

ness, it is common to begin developing systems with-

out ﬁxing the requirements. Even in the middle of de-

velopment, requirements keep changing and the sys-

tem must quickly embrace the changes. Traditional

waterfall project management is no longer effective

in such scope creep situations.

Many web applications are developed using appli-

cation framework that is based on MVC model, such

as Struts. It is true that MVC model is said to resilient

to change. However, it is only true when the model

is kept intact. If the model is forced to change due

to requirement changes, system-wide modiﬁcation is

likely to occur.

2.4 Coupling of User Interface and

Business Logic

Web application is divided into HTML page design

rendered in client, and background business logic pro-

grammed in server side. Design of user interface

and program of business logic must be strictly distin-

guished, allowing designer and programmer to work

separately. However, in many existing web appli-

cation frameworks, programming logic such as ﬁeld

repetition and input validation must be coded in page

layout along with HTML. Therefore, changing user

interface design requires programmer’s involvement

as well as UI designer’s work.

3 PROPOSED LIGHTWEIGHT

METHODOLOGY AND

FRAMEWORK

This section explains proposed lightweight method-

ology and framework to solve the four problems dis-

cussed in the previous section. The approach is char-

acterized by the following four advantages: (1) Low

learning cost; (2) Easy distribution and integration of

work; (3) Robustness and ﬂexibility to requirement

changes; and (4) Clear decoupling of view and logic.

The proposed lightweight methodology is targeted

for small- and medium-sized applications. Suggested

number of pages is less than thirty. With such ap-

plications, large framework such as J2EE is unneces-

sary. Larger systems can be built by integrating such

medium-sized applications.

3.1 Lightweight Methodology

3.1.1 Low Learning Cost

Leaning cost is increased by complexity of the pro-

gramming language and complexity of the develop-

ment environment. For the programming language,

we selected Perl. Perl is one of the most popular

lightweight programminglanguages along with Ruby,

Python, and PHP. Learning Perl is much easier than

learning Java.

For the programming environment, we wanted to

avoid using heavyweight IDE such as Eclipse and

NetBeans. These tools are difﬁcult to learn. Differ-

ence between local debugging environment and re-

mote deployment environment is also problematic.

Instead, we incorporated browser-based development

environment (i.e, ﬁle browser, text editor, and debug-

LightweightWebApplicationFrameworkandItsApplication-HelpingImproveCommunityBusTimetablesafterJapan

Earthquake

253

ger) inside the framework, which handles server ﬁles

directly.

3.1.2 Distribution and Integration

Web application is divided into two main compo-

nents. One is client page design comprising HTML,

CSS, JavaScript, and media ﬁles. The other is server

program and database. The client and the server can

be developed asynchronously. In many cases, end

users want to see client UI before server programming

has been completed. To meet these requirements, our

lightweight methodology abstracts web application as

a set of page transitions. In our approach, MVC is

redeﬁned as follows: Model is a program that corre-

sponds to a page, View is HTML template, and Con-

troller is the web application framework itself. We

call it lightweight MVC model.

With the lightweight MVC model and its imple-

mentation in our framework, page transitions can be

performed on the client without coding the server-side

business logic. Of course, server-side programming is

necessary to complete the application. However, page

design and transitions can be demonstrated to users at

early stage of the development before ﬁxing model

(server program). In addition, scope of responsibili-

ties is made clear by assigning each programmer a set

of pages and programs that correspond to the pages.

3.1.3 Robustness and Flexibility

In our lightweight MVC model, responsibility for

each page is clearly deﬁned. If the user requests speci-

ﬁcation changes, only affected page design (view)and

program (model) must be changed. Other views and

models, along with controller (the framework itself)

are kept intact. Therefore, our methodology is ﬂexi-

ble while maintaining robustness.

3.1.4 Decoupling of View and Logic

Most web application frameworks provide HTML

template that displays run-time value of variables em-

bedded in page layout. On the other hand, it is also

common to use page design tools such as Adobe

Dreamweaver to visually design user interface. Thus,

page designersdo not haveto understand the syntax of

underlying HTML and CSS. Now, the problem is con-

ﬂict between HTML template and design tools. Each

template engine has its own syntax to embed values,

repetitions and control ﬂows, which often cannot be

properly handled by design tools.

Therefore, we came up with minimum extension

to HTML for our template language that does not con-

ﬂict with design tools. In addition, Perl code can be

executed on the template on the server side.

3.2 Lightweight Framework

Figure 1 depicts the structure of lightweight frame-

work. As illustrated in Figure 2, the framework con-

sists of three Perl modules.

Figure 1: Structure of lightweight framework.

Figure 2: Perl modules.

The module kw.cgi is the core of the framework.

It calls back HTML template and transaction module

supplied by user, then generates HTML output. The

module kwﬁle.cgi is responsible for binary ﬁle output

from ﬁle box. The module kwdebug.cgi is a superset

of kw.cgi for debugging purposes. In addition to all

functionalities of kw.cgi, kwdebug.cgi can generate

debugging information to browser. It also provides

simple text editor of server ﬁles to browser client.

HTML template embedsdata items in page layout.

The data items are deﬁned in the transaction module.

In the HTML template, designer can use special tags

to be replaced with run-time data, which are speci-

ﬁed by hash variable %kw::out

param in transaction

module. Example will be shown in Section 5.

In MVC terms, kw.cgi corresponds to Controller,

HTML template corresponds to View, and transaction

module corresponds to Model. Page transition of the

web application controlled by kw.cgi is handled by

HTML form parameters sm and ss. The parameter

sm speciﬁes transaction module that is executed after

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

254

page transition. The parameter ss designates HTML

template used by the transaction module. If ss is null,

default HTML template is used, which is speciﬁed in

the transaction module. In other words, transaction

module run after pressing submit button is determined

by the value of sm, while HTML template is chosen

by the values of sm and ss.

If transaction module is empty, empty application

is generated that only performs page transitions de-

ﬁned by HTML template. This is useful for check-

ing the page transitions before getting to the program-

ming. It is recommended that HTML template (View)

is designed and implemented at ﬁrst, before transac-

tion module (Model) is designed and implemented.

It is common that web application must deal with

image ﬁles, PDF ﬁles and Microsoft Ofﬁce docu-

ments. To output these non-HTML ﬁles, ﬁle box may

contain arbitrary binary ﬁles.

Transaction module may register non-HTML ﬁles

with the ﬁle box. These ﬁles are sent as a part of

HTTP response by specifying the ﬁle identiﬁers in

kwﬁle.cgi. Especially, XML ﬁles can be generated

and registered as easily as HTML templates. This is

useful when the web application produces XML data

ﬁles that are used by client applications such as Mi-

crosoft Excel. An example will be presented in the

next section.

Debugging module kwdebug.cgi displays run-

time values of variables. It also offers Adobe Flash-

based text editor for client to edit server ﬁles with-

out using local editor and ﬁle transfer tools over ssh

or scp. This simpliﬁes the development of web ap-

plication. Especially in Japan, character code set

on server (UTF-8) is different from that of Windows

client (Shift JIS). Programmers must always be very

careful to convert the character set properly, which

is heavy stress. We solved the problem by offering

server-based text editor.

In addition, the framework provides miscella-

neous functions such as numeric formatting and

Japanese Imperial Calendar processing.

4 BUS BOARDING AND

ALIGHTING APPLICATION

Figure 3 shows page transition of bus boarding and

alighting information system. The application starts

from user authentication page, where the user enters

user name and password. Global navigation menu

branches to boarding and alighting summary page,

data analysis page, and map visualization page. The

collected data from information gathering subsystem

can be summarized in tabular format in web browser,

analyzed and graphed in Microsoft Excel via XML

intermediate ﬁle, and plotted on Google Maps using

JavaScript.

㻭㼡㼠㼔㼑㼚㼠㼕㼏㼍㼠㼕㼛㼚

㻹㼑㼚㼡

㻮㼛㼍㼞㼐㼕㼚㼓㻌㼍㼚㼐㻌㻭㼘㼕㼓㼔㼠㼕㼚㼓㻌㻿㼡㼙㼙㼍㼞㼥

㻰㼍㼠㼍㻌㻭㼚㼍㼘㼥㼟㼕㼟㻌㼍㼚㼐㻌㻳㼞㼍㼜㼔

㻹㼍㼜㼟

Figure 3: Page transition of the bus application.

During the development of the application, the re-

quirements from users kept changing. Speciﬁcations

revised repeatedly and new features added frequently.

Roughly speaking, we took three steps to develop the

application using our lightweight methodology and

framework.

In the ﬁrst step, we started from building empty

application that only performs page transitions de-

ﬁned by HTML templates. Then tasks were divided

into page design, programming of server-side logic,

and design of Microsoft Excel output. These tasks

ran concurrently. We used XML template, which is

similar to HTML template, to develop XML output to

Excel. The generated XML ﬁle is registered with ﬁle

box so that web browser can download the ﬁle, which

is then passed to Microsoft Excel.

In the second step, we plotted number of people

boarded and alighted on Google Maps. Complicated

JavaScript programming was necessary to use Google

Maps API. Thanks to our framework, JavaScript pro-

gramming was separated from HTML page design. A

skilled JavaScript programmer, who happened to be

very bad in user interface design, concentrated on the

programming.

In the third step, we refactored many parts of the

application to implement user requests and speciﬁca-

tion changes. When a set of data is analyzed and pre-

sented, users requested to add different features and to

change existing functionalities. Since no heavyweight

MVC structure was adopted, we successfully modi-

ﬁed code and user interface without major problems.

No “pseudo-MVC” problem hindered the refactoring

process.

We are planning to add new features to better ad-

dress the needs of the customers. For example, gath-

ering and visualizing accelerometer data from iPhone

is requested.

5 COMPARISON WITH RUBY ON

RAILS

Ruby on Rails (Hansson, 2004) is a popular

lightweight web application framework written in

LightweightWebApplicationFrameworkandItsApplication-HelpingImproveCommunityBusTimetablesafterJapan

Earthquake

255

Ruby language. Traditional frameworks such as

Struts require massive amount of conﬁguration ﬁles,

which leads to low productivity and low quality. On

the other hand, Ruby on Rails emphasizes “conven-

tion over conﬁguration,” reducing the need of conﬁg-

uration ﬁles and increasing productivity. For exam-

ple, ActiveRecord O/R mapper generates appropriate

class from database schema deﬁnition. Ruby on Rails

allows easy development and deployment of web ap-

plication based on MVC model.

In this chapter, we compare our lightweight

framework with Ruby on Rails in terms of the four

problems identiﬁed in Section 2: Learning cost; dis-

tribution and integration; requirement changes; and

coupling of user interface and business logic.

5.1 Learning Cost

With our lightweight application framework, no pro-

gramming knowledge is required for page designers.

Our lightweight methodology centers on page tran-

sitions, with each page corresponding to its database

table and business logic. Therefore, heavyweight O/R

mapper such as ActiveRecord is not needed. Heavy-

weight IDE like Eclipse or NetBeans is also unnec-

essary because editing and debugging support is pro-

vided by the lightweight framework itself. As a result,

learning cost of our framework is cheaper than that of

Ruby on Rails.

5.2 Distribution and Integration

It is mandatory to clearly deﬁne the scope of respon-

sibilities of each member in web application develop-

ment project. With our approach, the scope is deﬁned

by page. Once page transitions are ﬁxed, each mem-

ber clearly understands what to do. On the other hand,

modeling is essential prerequisite on Ruby on Rails,

which is based on MVC model. Scope of responsibil-

ities are made clear only after the model has been de-

veloped and entire class relationship has been ﬁxed.

This is typical bottleneck of Ruby on Rails project.

Moreover, when it becomes necessary to refactor the

implementation of the model and controller, the cost

is quite expensive.

5.3 Requirement Changes

As discussed in Section 2, requirement change or

scope creep is major reason why it is difﬁcult to main-

tain MVC structure in the course of web application

development project. Ruby on Rails enforces strict

MVC model by “convention over conﬁguration.” Re-

sulting database schema and page transitions must

conform to the model. If requirement speciﬁcations

are clear and stable from the beginning of the project

to the end, high efﬁciency and quality can be ex-

pected.

However, in a project where MVC structure can-

not be distinctively deﬁned at the beginning, or where

requirement changes occur frequently, it is common

that Model, View and Controller are getting mixed

during the course of the development. Since Ruby

on Rails requires code that conforms to the frame-

work convention and MVC structure, major refactor-

ing must be performed when requirements change. In

reality, many projects circumvent the major refactor-

ing and tend to do quick and dirty ﬁx of code, result-

ing in the deterioration of clean MVC structure. This

is sometimes called “pseudo-MVC.”

On the other hand, our lightweight methodology

abstracts web application as a set of page transitions.

In our lightweight framework, MVC is redeﬁned as

follows: Model is transaction module, View is HTML

template, and Controller is the framework itself. We

call it lightweight MVC model. With lightweight

MVC model, scope of responsibilities is made clear

by assigning each programmer a set of pages. In addi-

tion, lightweight MVC model does not prevent devel-

opers from using common libraries or object-oriented

data model.

5.4 Coupling of User Interface and

Business Logic

Now we compare our approach with Ruby on Rails

in terms of how much programmer has to get in-

volved in page design. On Ruby on Rails, page tem-

plate is .rhtml ﬁle, which embeds Ruby constructs

into HTML. When page designer edits the .rhtml ﬁle

with design tool such as Dreamweaver, the designer is

required to understand the Ruby language and .rhtml

tags. For example, Figure 4 is .rhtml form that dis-

plays patient name, and accepts entry of birthday.

Figure 5 shows Dreamweaver screen editing

the .rhtml ﬁle. Even in this simple example,

Dreamweaver is unable to render the form correctly

because it does not understand .rhtml tags.

On the other hand, using our lightweight frame-

work in Perl language, Figures 6 and 7 show the

form code and Dreamweaver screen respectively.

Dreamweaver appropriately renders the form because

unknown tags or tags in HTML comments are not

used.

Since we do not introduce new tags in our HTML

template, page designer can use existing tools like

Dreamweaver. In addition, no knowledge of Perl is

required for the designer.

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

256

<body>

Edit birthday

<%form_tag :action => ’edit’,

:id => @patient do %>

<%=render :partial => ’form’ %>

<br>

<%=link_to ’Patient List’,

:controller => ’patient_id’ ,

:action => ’patientList’ ,

:id => @birthday %>

<%=submit_tag ’Edit’ %>

<%end %>

</body>

Figure 4: Example of .rhtml form.

Figure 5: Display of .rhtml in Dreamweaver.

6 CONCLUSIONS AND FUTURE

WORK

In this paper, we proposed lightweight methodology

and lightweight framework for developing web ap-

plications. To develop web applications, orthodox

method is to employ highly skilled engineers and

to adopt heavyweight methodology, framework and

IDE. However, another approach is to use lightweight

methodology and lightweight framework with un-

skilled engineers. We have proven that web applica-

tion can be developed with limited ﬁnancial and hu-

man resources. The outcome of the research is sum-

marized to the following four points.

(1) The lightweight methodology and framework

enabled cost-effective development of web applica-

tion. Compared to Java-based framework and Ruby

on Rails, learning cost is cheap. Even unskilled pro-

<body>

Edit birthday

<form>

<input type=hidden name=sm

value="patientlist" >

$˜name˜$

</form>

</body>

Figure 6: Example of our HTML template.

Figure 7: Display of our HTML template in Dreamweaver.

grammers could take part in the development project

of bus information system.

(2) We made distribution and integration of work-

load effectively by deﬁning scope of responsibilities

for each page. Developers and designers cooperated

smoothly to ﬁnish the system in short time.

(3) The proposed framework allowed rapid modi-

ﬁcation of the system to satisfy requirement changes

from users.

(4) The framework decoupled page design, ap-

plication logic, and data model thoroughly. Our

lightweight MVC model separates View and Model

distinctively, and framework itself becomes Con-

troller. The application is resilient to requirement

changes.

After successful development and deployment of

applications based on the framework, we also iden-

tiﬁed two issues requiring additional work. The ﬁrst

thing to do is to incorporate test tools in the frame-

work. In unit testing framework such as PerlUnit,

dedicated testing program must be coded. However,

when speciﬁcations change, the testing program must

be changed, too. This is not productive. We are plan-

ning to develop unit testing library as a part of our

framework to solve this problem.

Second issue is version control. Tools like CVS,

Subversion, and Git are popular among skilled devel-

opers. However, unskilled programmers are not fa-

miliar with the notion and operation of version con-

trol. In many cases, simple versioning such as those

found in Microsoft Ofﬁce is sufﬁcient for small- and

medium-sized project. We are designing easy-to-

use versioning tools to incorporate to our lightweight

framework.

REFERENCES

Hansson, D. H. (2004). Ruby on rails. http://

rubyonrails.org/.

Mitsuda, N. and Fukuyasu, N. (2010). Issues behind the use

of web application frameworks. Computer Software,

27(3):3 2–3 12.

LightweightWebApplicationFrameworkandItsApplication-HelpingImproveCommunityBusTimetablesafterJapan

Earthquake

257