Engineering Web Applications:

Architectural Principles for

Web Software
Abstract

The popularity of the World Wide Web has been increasing ever since its
birth in the early 1990’s. It rapidly became an important medium for content
providers to publish documents for the masses. In the beginning, the content
was delivered in the form of static pages but more interactive applications
were soon to follow. The birth of e-commerce and other online services
created a demand for better and more feature rich applications. However,
web standards were not able to meet these requirements in a timely fashion
which led to a situation where browser makers and web developers were
forced to partially disregard to the standards to fulfill the market demand.
When compared to traditional desktop application development, browsers
provided a much more restricted environment for web applications. This
meant that most of the application logic had to be implemented on the
server, forcing the developers to break applications into client and server
side components. The advent of Ajax enhanced the responsiveness of web
applications, but it also created even more incoherency into the development
process by moving application logic into the client. As a result, most web
applications mix and match both approaches with little consistency.
In this thesis, the focus is on the high level architecture of web applica-
tions. Our goal is to bring proven software engineering principles into web
development and thereby increase software maintainability, reusability, and
developer productivity. Additionally, we discuss web services and show how
web applications can benefit from them. We examine the architectural weak-
nesses present in most of today’s web applications and elaborate on how they
are crippling the development process. We also present an architecture that
addresses these shortcomings and provides a coherent way for developers to
design and build web applications.
To perform fine grained analysis and verification of our observations, we
have applied the presented architecture on multiple real world web applica-
tions. We have used the experiences and feedback from these applications
to steer our research. The background, implementation, and findings of this
effort are reported in detail in this thesis.

i
ii
Acknowledgements

The work presented in this thesis was carried out during the years 2008-
2012. During the first two years I was part of a talented group of enthusias-
tic researchers at Tampere University of Technology. While continuing my
research work, during the last two years I had the opportunity to conduct
my research findings in the industry at Stratagen Systems. All this work
would not have been possible without the help and support of the people
acknowledged hereby.
First of all and mostly I would like to thank my supervisor, Professor
Tommi Mikkonen for his continuous and immediate support for my research.
He provided me with the funding, tools, facilities, and guidance to carry
out my research work during tight schedules and difficult research questions.
Whenever I was inching, he pushed me forward. His help was restricted
neither by his office space nor his office hours.
I would also like to thank my colleagues at the University. Dr. Antero
Taivalsaari, who guided me during the early stages of my research work and
introduced me to scientific research. Furthermore, I would like to thank Mr.
Janne Lautamäki and Mr. Tuomas Turto who – in their own way – gave me
inspiration and strength to carry on whenever I was in doubt. It was during
those years that we shared a room in the university when I was though how
to conduct research properly. Those were also the years I consider as being
the most fun and educating during my professional career.
At Stratagen Systems I would like to thank my superior, Mr. Jari-Pekka
Frantsi for allowing me to take time off to proceed with my research work.
Next, my gratitude goes to my long-term colleague and friend Mr. Peitsa
Turvanen, who is in great extent responsible for allowing me to execute the
findings of my research work in the industry. Jari-Pekka and Peitsa have
both shown me trust in our pursuit for the new application platform for
Stratagen. Last but not least, at Stratagen, I would like to thank the boys
in the corner office; Mr. Rami Salminen and Mr. Veli-Matti Aho for their
insightful feedback and lengthy discussions about my work as well as other
”topical” questions.

iii
iv

Finally, I am grateful to my family. My dear wife Marika, who has sup-

ported me from start to finish and with her own unyielding work ethic has set
an example for me. She has also shown me that family always comes before
work and she could not be more in the right. Thus I am most grateful for our
three lovely children Emmi, Oskari and Eemeli; indeed, not for their help in
carrying out my research but for just being there and for keeping me sane.
They bring joy and balance to my life and keep me down to earth for sure.
In addition, I am convinced that this thesis would not have been completed
if it was not for my parents and my parents-in-law. Their gratuitous help in
making my sometimes impossible schedule bearable, is without comparison.
Thank you.

Tampere, December 2013

Janne Kuuskeri
Contents

1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Thesis Questions . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Research Method . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . 8

2 Web as an Application Platform 9

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 HTTP Protocol . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Web Applications . . . . . . . . . . . . . . . . . . . . . 10
2.2 Programming Web Services . . . . . . . . . . . . . . . . . . . 11
2.2.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Programming Web Service Clients . . . . . . . . . . . . . . . . 19
2.3.1 Thin clients . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 Thick clients . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Engineering Complex Web Applications 25

3.1 Engineering Goals . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Modularity . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2 Maintainability . . . . . . . . . . . . . . . . . . . . . . 26
3.1.3 Reusability . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.4 Productivity . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.5 Responsiveness . . . . . . . . . . . . . . . . . . . . . . 28
3.1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Decoupled Way of Building Web Applications . . . . . . . . . 29
3.3 Revisiting Engineering Goals . . . . . . . . . . . . . . . . . . . 31
3.3.1 Modularity . . . . . . . . . . . . . . . . . . . . . . . . 31

v
vi CONTENTS

3.3.2 Maintainability . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Reusability . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.4 Productivity . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.5 Responsiveness . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Industrial Scale Case Study 35

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Re-engineering . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Defining Core Concepts . . . . . . . . . . . . . . . . . 39
4.3.2 Defining High Level Architecture . . . . . . . . . . . . 40
4.3.3 Applying the Decoupled Approach: The Server . . . . 42
4.3.4 Applying the Decoupled Approach: The Client . . . . . 44
4.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Related Work 51
5.1 Domain Specific Languages . . . . . . . . . . . . . . . . . . . 51
5.1.1 Mawl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.2 WebDSL . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.3 A DSL for Generating Web Applications . . . . . . . . 53
5.2 XFormsDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3 Lively Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4 Google Web Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 55
5.5 Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.6 Meteor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6 Conclusions 59
6.1 Introduction to Included Publications . . . . . . . . . . . . . . 60
6.2 Thesis Questions Revisited . . . . . . . . . . . . . . . . . . . . 61
6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.3.1 Access Control . . . . . . . . . . . . . . . . . . . . . . 62
6.3.2 Coherency to Building Single Page Applications . . . . 63
6.3.3 Distributed Notifications . . . . . . . . . . . . . . . . . 63
6.3.4 Server Side Rendering . . . . . . . . . . . . . . . . . . 63

7 Bibliography 65
List of Included Publications

[i] Janne Kuuskeri and Tommi Mikkonen Partitioning Web Applications

Between the Server and the Client. Journal of Web Engineering Vol.
9, No 3, 2010, pp.207-226.

[ii] Janne Kuuskeri, Tommi Mikkonen, Antero Taivalsaari, AsyncHttpE-

valRequest: A New Primitive for Downloading Web Applications Incre-
mentally and Securely. In Proceedings of the 35th Euromicro Confer-
ence on Software Engineering and Advanced Applications (SEAA’2009,
Patras, Greece, August 27-29, 2009), IEEE Computer Society, pp.80-
86.

[iii] Janne Kuuskeri, Janne Lautamäki, Tommi Mikkonen, Peer-to-Peer

Collaboration in the Lively Kernel. In Proceedings of the 25th ACM
Symposium on Applied Computing (SAC’2010, Sierre, Switzerland,
March 22-26, 2010), ACM Press, proceedings vol 1, pp.812-817.

[iv] Janne Kuuskeri, Tommi Mikkonen, REST Inspired Code Partitioning

with a JavaScript Middleware. In Proceedings of the 1st International
Workshop on Service Web Engineering, held in conjunction with the
10th International Conference on Web Engineering (ICWE’2010, Vi-
enna, Austria, July 5, 2010), Springer 6385, pp.244-255.

[v] Janne Kuuskeri, Tuomas Turto, On Actors and the REST. In Pro-
ceedings of the 10th International Conference on Web Engineering
(ICWE’2010, Vienna, Austria, July 5-9, 2010), Springer LNCS 6189,
pp.144-157.

[vi] Janne Kuuskeri, Experiences on a Design Approach for Interactive Web

Applications. In Proceedings of the 2nd USENIX Conference on Web
Application Development (USENIX ATC ’11, Portland, Oregon, USA),
USENIX Association, pp.87-98.

vii
viii CONTENTS
Chapter 1

Introduction

The World Wide Web was originally conceived as a platform for sharing
documents. These documents could easily be published and linked together
to constitute a network of web pages that we have become to know as the
web. The immediacy and easy accessibility of web pages was very appealing
to users and made the web an instant success. However, it quickly became
evident that the web as an application platform has a lot more to offer than
just acting as a document database. The interest to deliver working software
over the web, and to run it inside the browser was imminent.
At first, user interactivity was added into web pages by using rendering
techniques that enabled dynamic composition of web pages. This enabled
modest interactions like the use of forms and server side programming but
also dynamic capabilities on the client side. Even though these sites were
not really called web applications back then, the transformation from mere
web pages towards true web applications had started.
In many respects, web applications have come a long way. User expe-
rience in today’s modern web applications is much better while the func-
tionality provided is manifold compared to early days of web applications.
The standards – namely HTML5 [31] [133] and APIs it is associated with
(e.g. Web workers [32], Web storage [35], Microdata [33], and Canvas [54])
– have evolved over time to better facilitate web applications, and browser
vendors have invested in making browsers true application platforms instead
of just being document viewers. Lately, we have also seen the emergence of
platforms such as Firefox OS (formerly known as Boot to Gecko)1 where the
browser environment takes the role of the operating system and where so
called native applications are built with web technologies [124].
All this has resulted in web applications that are feature rich, dynamic,
1
http://www.mozilla.org/b2g/

1
2 CHAPTER 1. INTRODUCTION

collaborative, and responsive. In other words, they have many of the features
that we have come to know from desktop applications. No more is JavaScript
[48] used as a pocket knife to quickly hack a feature into a web page, but
increasingly large and complex applications are built with it.

1.1 Motivation
By current standards, web applications are inherently complex to develop
and maintain [51, 15, 83]. They are run on many different environments
such as desktop and mobile browsers, and are expected to perform equally
well on all of them. Also, bearing in mind the history of web applications,
it comes as no big surprise that they are crippled by the environment that
was not originally designed for them. Had the standards of the web and
browsers been designed from the ground up to facilitate web applications as
opposed to web pages, the development process and tools would most likely
look different today.
Another complicating factor is that the constant transformation of web
platform has left little room for the inclusion of any general conventions or
guidelines on how to build web applications. This leaves programmers at
the mercy of the frameworks, which yet poses another set of problems. The
hundreds of available frameworks all come with a different set of trade-offs
regarding security, performance, provided conventions, and the development
model in general. Different frameworks are good for different things, and
many of the frameworks differ to a great extent in how they steer or even
mandate the development model. Programmers may not always understand
the trade-offs and the risks that frameworks entail. Moreover, programmers
become dependent upon the frameworks, leaning on the utilities they provide
while ignoring or not understanding what is actually happening underneath.
Many of the frameworks also encourage coupling the client and the server
components tightly together. It is this kind of coupling that makes code and
programmers’ skill set reuse very difficult.
Even with a suitable framework for a given task, there is still a lot of
leeway for the programmer to implement the application in various ways. A
good example of this is the fragmentation of the application logic. On one
hand it is fragmented over the server side components running in the server
and the client side components running in the browser. On the other hand
it is fragmented over different technologies including multiple programming
languages and presentation templates that may all be used to implement
the application logic. Furthermore, the communication channel between the
server and the client is very versatile. The programmer must choose how to
1.2. THESIS QUESTIONS 3

use it and what kind of data should be transferred in various situations.

All this complexity results in a programming environment that is not
only filled with pitfalls of security, performance and maintainability, but this
environment is also very difficult for newcomers to adapt and learn. Granted,
a good framework can make things easier for the developer, but this does not
take away the underlying problem of code fragmentation and lack of proven
conventions. The problems hindering today’s web development need to be
addressed to at a deeper layer; not by introducing leaky abstractions2 on top
of web and HTTP, but by embracing them.

1.2 Thesis Questions

The main driving factor for the whole research work behind this thesis has
been in the identification and discovery of techniques and architectural pat-
terns that bring increased coherency into building web applications. Through
coherency, our intention is to make the process of developing and maintaining
web applications simpler and more productive.
We have identified subgoals that we need to aim for in order to reach
our final goal. Mostly they are conventions and guidelines on how to address
the problems that plague the web development at present. These include
application and responsibility partitioning between the client and the server,
better code reuse, better maintainability and better development model in
general. On the other hand, from the user’s point of view complex web
applications should be more responsive and robust. From these objectives
we have derived following thesis questions:

• Software engineering principles: How can we better apply proven

practices of software engineering in web development? Principles like
modularity, separation of concerns, encapsulation and decoupling (as
presented by MacLennan in [86]) are often compromised when devel-
oping web applications [68].

• Application logic: Which parts of the system should handle the ap-
plication logic? How can we partition the application logic between the
client and the server so that the code stays maintainable and software
architecture consistent?

• Thick or thin client: Should web applications have a thick client that
handles most of the user interactivity within the browser or should
2
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
4 CHAPTER 1. INTRODUCTION

pages be generated mostly on the server thereby using the browser

merely as a rendering engine? This is closely related to previous item
but we wanted to add it as a separate item to make it more explicit.

• Partitioning: How to actually implement the partitioning? Could

this be automated by the framework? If both the client and the server
are implemented in JavaScript, the partitioning could even be dynamic.

By finding answers to these questions in full, we are able reach our goal.
The goal is not to implement yet another framework for building web ap-
plications, but to provide guidelines and conventions, essentially a design
approach, on how to build complex web applications in general. However,
we do consider it important that these practices are validated in real world
applications, so a validating industrial-scale implementation is therefore one
of our goals, too.

1.3 Contributions
The main contribution of the thesis is in the presentation and evaluation of
a design approach for building feature rich web applications. We pinpoint
the problems burdening today’s web development and present an approach
to tackle these issues. As part of the design approach we introduce a set of
guidelines and conventions for building web applications. These guidelines al-
low developers to build maintainable and reusable web application code that
can also benefit from proven software patterns [55]. The presented approach
is investigated and discussed in detail. Moreover, it is evaluated in real world
applications. The evaluation process and its outcome are documented in this
thesis.
In the course of this process, we have also made contributions to the open
source software. We have made minor contributions to a number of existing
projects but more importantly we have implemented and open sourced REST
frameworks for two different platforms. The first one3 is implemented as an
extension to the Django [40, 63] framework, and the other one4 is a library
for the asynchronous Twisted [126, 88] networking engine.

3
https://github.com/wuher/devil/
4
https://github.com/wuher/diablo/
1.4. TERMS AND DEFINITIONS 5

1.4 Terms and Definitions

Next, we define the most relevant terms here to avoid any potential ambi-
guity. Even though these terms are widely used, they may sometimes have
different meanings in other contexts. When these terms are used in this
thesis they are faithful to the definitions laid out in this section.

Web as an application platform. This expression refers to all software

that embraces and utilizes the web and HTTP [122]. It may be an appli-
cation running in the browser, a whole web portal, or just an API that is
accessible over HTTP. Other examples could be programmatic clients that
crawl the web by sending HTTP requests and mining data or native applica-
tions, mobile applications for example, that are not running in the browser
but still use HTTP to talk to various web services. All these very different
types of applications, devices even, share one important characteristic: they
use the web as their platform.

Web application. An application that uses the web as its platform. It is

a full application containing both the client-side portions and the server-side
portions of the application. As in [6], we do not provide formal distinction
between web pages and web applications. In this thesis, we mostly talk about
web applications and web pages are something that present and embed the
application. Whenever we refer to static web pages, we clearly state so.

Web service. A service that defines its access point in the web and there-
fore operates on top of HTTP. A web service provides an interface for its
clients that they can use remotely over the network. The W3C identifies two
major classes of web services: REST-compliant web services which expose a
uniform set of stateless operations and arbitrary Web services which expose
an arbitrary set of operations for the client [24]. SOAP usually falls under
the latter category. A user interface may be built on top of web service (i.e.
it may use the web service) but the definition of web service does not include
graphical user interface.

Browser application. An application that is built with web technologies.

That is, using HTML, CSS and JavaScript. It does not contain any server
side components and is therefore a subset of the web application. Browser ap-
plication may also utilize plug-in based proprietary runtimes such as Adobe
Flash, Java Applets, and Microsoft Silverlight. Its host environments in-
clude not only desktop and mobile browsers, but also native applications
6 CHAPTER 1. INTRODUCTION

that embed the browser runtime allowing the application to be built with
web technologies but still be shippable as a native application.

Programmatic client. A client that does not necessarily have any end-
users or even a user interface. It can be for example a script, a batch process
or another web service.

Ajax. An umbrella term for a group of web technologies such as HTML,

CSS and JavaScript that are used to create dynamic web applications. Ajax
enabled applications use asynchronous networking and do partial page up-
dates by manipulating the DOM tree. Ajax is also often though of as the
technology behind the Web 2.0 [56].

Mashup application. A web application that uses or combines data, func-

tionality or presentation from two or more web services to create a new web
application or service [60]. A mashup application may be composed on the
server, in the client or both.

Single page web applications. Web applications that fit on a single

page are referred to as single page web applications or simply single page
applications (SPAs). SPAs mimic desktop applications by not reloading the
web page on user interactions but instead making heavy use of JavaScript
to manipulate the existing page. SPAs need to either load all the required
HTML, CSS and JavaScript files during the initial page load or load them
on demand in the background.

1.5 Research Method

We chose to use the taxonomy of research methods defined by Järvinen [67]
when choosing our research method. This was mainly because Järvinen’s
taxonomy is aimed at computer science research and emphasizes research
questions over abstract objects and research outcomes. Another reason was
the fact that it uses research approaches instead of research methods in the
taxonomy. This keeps the number of available options smaller and therefore
the taxonomy itself easier to comprehend. The taxonomy is presented in
Figure 1.1. In the figure we have highlighted the approaches that we have
followed in our research.
In our research we have been dealing with various digital artifacts. These
artifacts include web services, web clients and web applications in general.
1.5. RESEARCH METHOD 7

Research
approaches

Approaches Mathematical
studying reality approaches

Researches Researches
stressing stressing utility of
what is reality artifacts

Conceptual-
Approaches for Artifacts- building Artifacts- evaluating
analytical
empirical studies approaches approaches
approaches

Theory-testing Theory-creating
approaches approaches

Figure 1.1: Taxonomy of research methods

8 CHAPTER 1. INTRODUCTION

We have been investigating the current state of web applications and sug-
gested an approach defining how these applications should be architectured.
Furthermore, we have built several web applications, web services and even
frameworks to be able to evaluate our approach. For these reasons, our re-
search methods include artifacts building approaches and artifacts evaluating
approaches.
Artifacts building approach tries to answer the question whether it is
possible to build the artifact and how it should be built? Artifacts evaluating
approach, on the other hand, tries to answer the question about the artifact’s
efficiency. Both of these approaches also fall under broader method called
Action research [121]. In our thesis we have answered and analyzed both of
these problem domains.

1.6 Structure of the Thesis

The introductionary part of this thesis is organized as follows. We start by
introducing the web as an application platform in Chapter 2. This introduc-
tion includes overview of web services and web applications. In Chapter 3, we
first describe requirements and desired characteristics for a web application
architecture. As our main contribution we then present the solution that
meets these demands and continue into the evaluation of the architecture in
a real world context. Moreover, in Chapter 4 we report our findings from the
industrial scale case study. We have not reported these results in any earlier
publication and therefore they are also part of the contribution of this thesis.
Chapter 5 addresses related work that already exists related to our research.
The conclusions and final discussion is conducted in Chapter 6.
Chapter 2

Web as an Application
Platform

To gain better understanding about the architecture of web applications it

is useful to first have a closer look at the web as an application platform.
We do this from the viewpoint of client-server programming by investigat-
ing server- side and client-side programming environments separately [116].
First, we examine server-side programming by looking at different types of
web services. After that, we explore client-side programming from the view-
point of true web applications. This means that while we have a strict focus
on programming in the client-side, we will also discuss the role of the server
with different types of clients.

2.1 Introduction
As an application platform, the web has a lot to offer. The coverage of In-
ternet access has allowed the web to become ubiquitous thereby making web
applications easily accessible [11]. Indeed, one of the most powerful features
of the web as an application platform is the immediacy of it; once something
is published in the web, it is immediately accessible to everyone [134]. This,
in turn, enables seamless updates and easy deployment. Granted, the re-
cent emergence of various online distribution networks (namely, App Stores)
has bridged the gap between the web and native applications when it comes
to distribution of applications. Also, there are applications such as Google
Chrome1 that constantly update themselves in the background and without
user interruption over the web. However, these channels still introduce an
1
http://www.google.com/chrome/

9
10 CHAPTER 2. WEB AS AN APPLICATION PLATFORM

extra level of indirection for the users and the application manufacturers
compared to using purely the web and its main protocol, HTTP.

2.1.1 HTTP Protocol

HTTP is the application protocol that empowers the web. It was originally
designed by Tim Berners-Lee and his team in 1991 for transmitting docu-
ments across the Internet. Five years later the first official HTTP/1.0 (RFC
1945) standard [9] was released. It defined the core features like request
methods, status codes, and content types. In 1999, HTTP/1.1 was intro-
duced in RFC 2616 to further refine the specification but also to enhance
and add features such as security, caching, and connection handling [141].
HTTP versions 1.0 and 1.1 are still the most commonly used versions, and
all major clients and servers support these protocols [141].
From the technical perspective, HTTP is a text based request/response
protocol. Communication is initiated by the client opening a TCP connection
to the server and then sending a formatted text message – that is, an HTTP
request – to the server. Server processes the request and generates an HTTP
response, another formatted text message, for the client. After this, the TCP
connection is closed. This chain of events is repeated for each message the
client wishes to send and therefore each request occurs in isolation of any
other request, thus creating a stateless communication channel between the
client and the server. It should be noted that HTTP does include mechanisms
for reusing the existing TCP connection for consecutive messages, but this is
an optimization to the protocol and not to be relied on when implementing
applications on top of it.

2.1.2 Web Applications

Applications that run on top of HTTP are generally referred to as web ap-
plications. Normally they are accessed using the browser, but this is not
always the case. Web applications are more than just documents residing in
the Internet, because they are interactive and dynamic.
As an example, we take a typical web application that is accessed using
a web browser and loaded from the server hosting it, that is, there is a web
service and a downloadable web service client. What the user does is type
in the URL of the application and start using the application. Depending
on the application she may customize it to better suit her needs, do some
work, and then save that work. When she later returns to the application –
assuming that the server is able to store persistent data – she may restore her
work and continue where she left off. While doing so, she might be running a
2.2. PROGRAMMING WEB SERVICES 11

newer version of the application without even being aware of it. Furthermore,
she may do so using a different browser or a different computer at a different
location or even a mobile device and still have access to the same application.
One more thing to notice in the example is that the user does not need
to install anything, a URL is enough. Moreover, the application is platform
independent; users may use their choice of device, operating system, and
browser to access and use the application. This is emphasized even more
by the fact that HTTP is the prevalent protocol in the web and therefore
rarely blocked by firewalls or proxies. These same benefits apply to other
scenarios too. For example, if we think about web services; regardless of the
application level protocol that is used, underneath web services usually run
on top of HTTP and therefore clients utilizing it may all use their choice of
programming languages and libraries for consuming the service.
Programmatic access via web services has become an important part of
web applications. Many popular web sites like Twitter2 , Facebook3 , and
Tumblr4 provide an API for third party clients to build their own applications
on top of the provided web service. These web services provide an access to
the same data as the applications themselves have, thereby making it possible
for third party clients to create mashup applications on top of the available
data.

2.2 Programming Web Services

In the realm of the web, server side programming has two features that
distinguish it from other type of server side programming. Firstly, the system
needs to acknowledge that the interface it exposes uses HTTP as its protocol.
HTTP can be hidden from clients by introducing layers of abstractions on
top of it, but in the end HTTP is a request/response protocol based on a
well defined standard that needs to be adhered to.
Secondly, in other server-side programming environments the protocol
and the content encoding may be a bigger issue than the API design itself. In
the web, on the other hand, HTTP is already a standard, and it is commonly
preferred to choose an existing standard (such as JSON [38], XML [28] or
XHTML [22]) for content encoding than it is to come up with a custom
format. Because of these facts, clients in the web are only interested in the
interface of the service and it is much less important, if not irrelevant, what
2
https://twitter.com
3
https://www.facebook.com/
4
https://www.tumblr.com/
12 CHAPTER 2. WEB AS AN APPLICATION PLATFORM

kind of architecture and programming languages are used to implement the

service. This emphasizes the importance of the API design of the interface.
There are many different approaches to implementing web services, most
of which are more or less customized for the given purpose and domain.
However, in order to make a service more easy to define and more accessible
to clients, it is favorable to use an existing standard. Again, there are many
different standards for building networked services on top of HTTP, but for
our purposes it is enough to distinguish the most relevant ones. We have
used ProgrammableWeb5 as our reference when comparing the popularity
of web service implementations. ProgrammableWeb is an online database
for public APIs and mashups. It is based on voluntary registration, and
therefore it only represents a subset of all APIs. Nonetheless, it gives us a
good conception of the distribution of different technologies that are used for
implementing web services (see Figure 2.1). The two leading standards in
this area are SOAP [26] and REST [112, 47]. JavaScript APIs (as defined
by ProgrammableWeb) as a category is not very interesting in our context
because it doesn’t really describe how the communication is carried out.
The remaining group of web services are custom implementations often built
around using the HTTP POST method to send instructions to the server
about client’s intentions with the accompanied data. These types of services
are usually variations of the XML-RPC protocol [120]. In XML-RPC, XML
[28] is used for defining the method to be executed and the data it passed to
that method. Likewise, the response of the method invocation is encoded in
XML.
The comparison of SOAP and REST is not entirely justified or even
meaningful because they have different characteristics; SOAP is a protocol
whereas REST is an architectural style for composing web services. How-
ever, these are the two widely used approaches for building web services and
to be able to compare the results of our research work we need a way to
compare their suitability for building complex web applications. This is why
we refrain ourselves from ranking these two techniques and instead describe
their key characteristics in the context of web applications. In article [104]
Pautasso et al. provide an in-depth comparison of REST and SOAP. The
comparison is performed from the viewpoint of application integration styles
through which they are able to perform a more general and quantitative com-
parison. Furthermore, various patterns for implementing SOA with REST
are explained in [43].

5
http://www.programmableweb.com/
2.2. PROGRAMMING WEB SERVICES 13

XML-RPC
2%
JavaScript
6%

SOAP
21%

REST
70%

Figure 2.1: Protocol distribution in APIs (August, 2012)

2.2.1 SOAP
SOAP is a part of the service-oriented architecture (SOA) family of tech-
nologies. It is just one of the many technologies involved in SOA, but in
the context of this dissertation, it is the most interesting one. To be able to
describe SOAP and its features better, we will first provide an overview of
SOA itself.

SOA
SOA is a set of principles and methodologies for designing and developing
software in the form of interoperable services. SOA helps in building appli-
cations in terms of modularized and loosely coupled software components.
These components are implemented as web services that provide information
and functionality to other applications [84]. New and complete applications
may then be built by combining one or more of these web services. Indeed,
one of the key ideas behind SOA is that service providers may advertise
their services in centralized service registries, from which service consumers
are able to find them and then connect to appropriate services directly.
Many technologies are involved in the SOA architecture. In Figure 2.2
we have depicted some of these along with involved actions and stakeholders.
Service providers formally define the interface to the service they are exposing
14 CHAPTER 2. WEB AS AN APPLICATION PLATFORM

Service Registry WSDL

WSDL
WSDL

UDDI (find) UDDI (register) WSDL

Service Consumer SOAP (interact) Service Provider

Figure 2.2: Service-oriented architecture; involved technologies

using the Web Service Description Language (WSDL) [27]. The service may
publish this description into a service registry using Universal Description
Discovery and Integration (UDDI) protocol [98]. If a service consumer does
not know about the service provider directly, it also can use the UDDI in
finding the service from the service registry. Finally, the consumer uses SOAP
(formerly Simple Object Access Protocol ) to interact with the web service.
All of the aforementioned SOA technologies rely on XML [28] and its schema
validation (XSD) [25] for communication and description of services.

SOAP
SOAP is a protocol that can be used on top of HTTP to implement Remote
Procedure Call (RPC) [12] [125] style of communication between the client
and the server. In its simplest form, SOAP is a way to exchange typed
messages over a network and therefore it is independent of the used transport
layer and supports for example, HTTP, SMTP [72], TCP [96], and JMS
[111, 110]. Since the scope here is HTTP, we are examining SOAP in the
context of HTTP only. HTTP is also the dominant transport used for when
building SOAP services. The way RPC manifests itself in SOAP is that
the client wraps its intention into a message, sends it over the HTTP to
the server, which then interprets the message and executes the requested
operation.
The default message format in SOAP is XML, and in the case of HTTP,
POST method is used to carry the message over to the server. The XML
document contains the information about the function and its parameters
the client wishes to invoke. The server decodes this information, executes
2.2. PROGRAMMING WEB SERVICES 15

the function, and then returns the output of the function in another XML
document to the client. In SOAP, these XML messages are called Envelopes
[26]. An example of two SOAP messages – request and response – are given in
Listings 2.1 and 2.2, respectively. In the example, the client wishes to perform
a basic addition of two numbers by invoking a function called addNumbers.

Listing 2.1: SOAP Request

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<mynamespace:addNumbers
xmlns:mynamespace="urn:MySoapService">
<param1 xsi:type="xsd:int">4</param1>
<param2 xsi:type="xsd:int">8</param1>
</mynamespace:addNumbers>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Listing 2.2: SOAP Response

<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<mynamespace:addNumbersResponse
xmlns:mynamespace="urn:MySoapService"
SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:int">12</return>
</mynamespace:addNumbersResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP is a part of a wide set of standards for defining web services. These
are informally referred to as the WS-* stack [132], [2]. The WS-* stack in-
cludes (but is not limited to) standards for messaging, service description,
16 CHAPTER 2. WEB AS AN APPLICATION PLATFORM

XML schema and security. When defining web services utilizing SOAP, the
most important standards are SOAP itself, XML schema, and WSDL. WSDL
is used to formally define the interface; the functions it exposes, the param-
eters these functions accept and their return types. Leveraging these stan-
dards, SOAP enjoys vast and complete tool and library support. Graphical
tools may be used for defining the interface and generating the WSDL doc-
ument. The WSDL document, on the other hand, may be consumed by a
different tool to generate the code for the server and client implementations.
This way, when working with SOAP environment, tooling is able to hide all
the networking details from the programmer.
To summarize, SOAP raises the level of abstraction in the HTTP envi-
ronment by implementing another protocol on top of HTTP. By doing so, the
interface exposed by the web service looks more like a traditional RPC inter-
face and may be consumed as such. The fact that it comprises namespaces
and functions means that it conforms more directly to concepts familiar from
programming languages. Therefore, software architects usually feel comfort-
able in utilizing SOAP and defining service oriented interfaces. Also, they are
free to steer the architecture of the application independently of the HTTP’s
stateless and resource oriented model.

2.2.2 REST
While SOAP is a protocol, REST is an architectural style built around the
idea of Resource Oriented Architecture (ROA) [41] [99]. RESTful interface
and its implementation are tied to resources as opposed to modules and
functions. These resources are exposed by the servers and consumed by the
clients using the standard HTTP methods. A resource is accessed via a URL,
and its state is transferred using its representation. A key characteristic of a
RESTful interface is the clear division of application state between the client
and the server.
Much like SOAP, REST is also independent of HTTP and can be deployed
on top of other protocols besides HTTP. In practice, however, RESTful ar-
chitecture is very rarely used without HTTP. Moreover, REST was originally
designed hand-in-hand with HTTP itself and therefore embraces HTTP’s key
concepts. Because it is also our interest to investigate REST in the HTTP
environment, we consider RESTful interfaces only in the context of web ser-
vices. In the following we present the key characteristics of REST. For the
most part, these descriptions are extracted from Publication [v], but it is
worth repeating them here for describing the technical contributions of this
thesis.
2.2. PROGRAMMING WEB SERVICES 17

Resources and URLs. In a RESTful interface, everything is a resource.

Conversely, everything that can be represented by a URL can be a resource.
A resource can be static (e.g. /blog/2010-01-03) or its representation
can change over time (e.g. /blog/latest). Moreover, the resource can
also represent a list of things (e.g. /blog/2010/). Although every resource
must be addressable by a URL, the REST itself does not mandate any scheme
for constructing URLs. Human readable URLs are preferred, as they should
suggest how to use the interface, but not required by REST. However, the
URL should not contain any information about any operation that might be
applied to the resource (e.g. /add/ or /remove/).

Connectedness. A property that is closely related to addressability is con-

nectedness. For a client to be able to consume a RESTful service, it needs to
know the addresses of all the necessary resources. These resource identifiers
can be pre- configured into the client but this is not desirable because it
does not enforce connectedness. Instead, the server should guide the client
by letting it know about all meaningful resources and then the client can
make the decision which path to choose. The server can do this be sending
hypermedia links to other resources it exposes. This pattern is also known
as Hypermedia as the Engine of Application State [46].

Methods of REST. For RESTful services, the most commonly used HTTP
methods are POST, GET, PUT and DELETE. These methods define the ba-
sic CRUD6 operations for resources. These methods can be categorized in
accordance to how they operate on resources. The GET method is said to
be safe because it has read only semantics on the resource, implying that
it is meant only for information and data retrieval without any side effects.
With PUT and DELETE, GET is also idempotent, since it does not matter
whether the operation is applied once or several times on a resource. The
end result is always the same. For instance, it does not make a difference if
a resource /blog/2010-02-09 is deleted once or twice; it will not exist
afterwards.

Statelessness. Honoring the principles of HTTP, REST is strictly state-

less. Any application state is stored only on the client. The server, on the
other hand, only stores the resources and their states. This also means that
each request to a resource must be self-containing; i.e. each request must
contain all the information needed to carry out the request. So, the server
does not need to – nor should it – know anything about any previous or
6
Create, Read, Update, Delete
18 CHAPTER 2. WEB AS AN APPLICATION PLATFORM

future request made by the client. Each request should happen in complete
isolation from any other request.

Uniform Interface. A very unique characteristic of REST is the uniform

interface that it imposes on the services that employ it. Where RPC style
services expose bespoke objects and methods for clients, RESTful interfaces
expose resources with a fixed set of HTTP methods and return values for
each resource. Most importantly this is a profound change in the way the
interface for a web service is designed. Everything needs to be designed in
terms of resources as opposed to functionality.

Example. When describing SOAP in Subsection 2.2.1, we used an example

to clarify how the protocol works. We are now revisiting that example in the
context REST. In the example we had a remote service to calculate two
numbers together. The service had one function called addNumbers() but
because REST operates in terms resources instead of functions, we define a
resource called sum which supports two numbers as input parameters. The
sequence of using this service is illustrated in Listings 2.3 and 2.4.

Listing 2.3: HTTP request

> GET /sum?param1=8&param2=4 HTTP/1.1
> User-Agent: curl/7.21.4
> Host: localhost:8080
> Accept: */*

Listing 2.4: HTTP response

< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Date: Thu, 08 Dec 2011 22:08:13 GMT
< Server: localhost
12

In the SOAP example we did not include any information about HTTP
headers, the request method, or event the URL that was used as a service
endpoint. In the case of REST, however, we deliberately included this infor-
mation to emphasize the point that REST conforms to HTTP, and at the
protocol level is HTTP.
2.3. PROGRAMMING WEB SERVICE CLIENTS 19

2.3 Programming Web Service Clients

The simplicity and lightness of HTTP allows many different types of clients to
consume services in the web. Clients with limited processing power are able to
consume the same services as more powerful machines. Furthermore, HTTP
conveniently decouples the client and the server implementations, thereby
making the communication transparent; the service does not necessarily need
to know what type of a client is consuming it. This separation, however,
is often compromised by applications lending themselves to excessive use
of frameworks, custom protocols, cookies, and predefined control-flows of
application state.
In this thesis we are mainly interested in browser based web applications
and not so much about the programmatic clients. Programmatic clients
are briefly discussed but mostly we will be concentrating on the applica-
tions running in the browser. The three main technologies for implementing
web applications inside the browser are HTML, JavaScript, and CSS[90].
HTML is used for declaratively defining the layout of the user interface,
while JavaScript is used for implementing the user interactions. The loaded
HTML document is translated by the browser into the elements of the Doc-
ument Object Model (DOM) tree [23]. The DOM is essentially an API for
accessing and manipulating the web page and therefore mandates the final
outcome of the page. JavaScript code running inside the browser may use the
DOM API to alter the page and therefore create dynamic web pages. Finally,
CSS rules are applied to create the desired look and feel for the application.

2.3.1 Thin clients

Today, web applications are rarely built without the help of a web application
framework. There are dozens of frameworks to choose from when building
web applications. Some examples include Ruby on Rails [109, 80], Django
[40, 63], ASP.NET MVC [4, 52] and Spring MVC [119, 62]. What is common
for most of the frameworks is that they are built around the MVC pattern
[75]. The implementation of the MVC however, comes in many flavors among
the frameworks but usually model, view and controller are distinguishable in
their design. For the purpose of the thesis, this breakdown is detailed enough
in order for us to explain how the majority of web applications are built.
Figure 2.3 shows how these different components are distributed between
the server and the client at runtime.
In a generic web application, it is common that the model and the con-
troller are implemented in a server side programming language and reside on
the server. The model represents the persistence layer and the business logic
20 CHAPTER 2. WEB AS AN APPLICATION PLATFORM

Browser

View

Controller Model

Server

Figure 2.3: MVC pattern in traditional web applications. (Thin client)

of the application, while the controller is responsible for handling and routing
the requests and generating the view for the browser. This is a radical sim-
plification of the responsibilities of these components, but again, this is not
our focus here. Our focus is on the sequence of events that occur repeatedly
when the user interacts with the application. For example, when user clicks
a button, a request is sent to the server, and the server handles the request,
generates the application user interface from scratch, and sends it back to
the browser. Figure 2.4 illustrates the process of page generation.
Because HTTP is a stateless protocol, it separates the states of the
client and the server. Therefore, from client’s perspective, the application
is restarted every time a new page is generated and sent to the client. The
server, on the other hand, needs to remember the state of the application
in the beginning of each request. Normally, this is achieved via server side
sessions, where the client sends a cookie with each request to identify the ses-
sion on the server that should be restored. We have explained this sequence
and its implications in more detail in included Publication [vi].
After the web page is received and rendered by the browser, it can be fairly
static. User interactivity and partial page updates can be added by using
JavaScript, but most of the web frameworks encourage and steer developers
into handling the business logic and user interactions in the server. This kind
of programming model results in thin clients where pages are loaded from the
server each time the user navigates into a different view or performs actions
that require data or operations from the server.
2.3. PROGRAMMING WEB SERVICE CLIENTS 21

Client Send to browser

Server

View / HTML page

...
<ul>
<li>Luke Skywalker is 20 years old</li>
<li>Leia Organa is 20 years old</li>
<li>Han Solo is 25 years old</li>
<li>Yoda is 900 years old</li>
</ul>
...

Controller

Template engine

HTML template
...
Model <ul>
{% for row in data % }
Person: <li>{{data.name}} is {{data.age}} years old</li>
string name, {% endfor %}
int age </ul>
...

Figure 2.4: Composition of the HTML page.

22 CHAPTER 2. WEB AS AN APPLICATION PLATFORM

2.3.2 Thick clients

The opposite approach of doing client side programming in the browser is
introducing a thick client. This emerging approach emphasizes implementing
the application as far as possible in the client. For web applications this
means less web pages but with richer functionality. Indeed, it is common for a
web application with a thick client to be implemented as so called single page
web application where the application remains within a single page and no
page reloads are needed. To accomplish this, the application needs to make
large use of JavaScript and asynchronous HTTP requests to implement a
dynamic and interactive user interface. It can still have navigational features
similarly to more traditional thin client approach, but now the web page and
its views are updated dynamically using JavaScript only.
Navigational features of single page applications are closely related to
bookmarkability and handling of browser’s own navigation buttons. By de-
fault, in SPAs the URL of the application does not change and pressing
browser’s back button would cause the application to exit. However, there
are two ways to support deep linking [94] and history control in single page
applications:

1. HTML5 history API: this is also sometimes referred to as HTML5

pushState. It is an API that allows JavaScript applications to keep
browser’s URL and history stack in sync with different states of the
application. This is the preferred way of implementing deep-linking
but at the time of writing its supported in browsers is still limited.

2. URL anchors: this is also sometimes referred to as hashbang. This

approach has much better support in browsers because JavaScript ap-
plications update the anchor part of browser’s URL directly (with
location.hash). For example
http://example.com/#user/new.

Neither approach causes the web page to reload and at the same time
both approaches update the URL of the application in browser’s address
bar. Hence, both approaches enable bookmarkability and history support.
However, there is one key distinction in these two approaches when used as a
bookmark: the anchor part of the URL is never sent to server and therefore in
the hashbang-approach the server never sees which page the client is actually
requesting and cannot perform any optimizations.
In single page web applications, the MVC pattern may be fully imple-
mented inside the web page using JavaScript. The view modifies the DOM
2.3. PROGRAMMING WEB SERVICE CLIENTS 23

tree dynamically to present different views of the user interface. The con-
troller on the other hand intercepts users actions and uses the model to
perform necessary actions. Lastly, the model defines the domain model of
the application and transfers the data between the client and the server.
This way the application remains active in the browser all the time and is
not restarted as there are now page reloads. After the application has been
loaded from the server it does not need to download any further HTML,
the server is used only for data access and messaging. This arrangement is
depicted in Figure 2.5.

Browser

View

Controller Model

Server

API

Figure 2.5: MVC pattern in single page web applications. (Thick client)

Many of the plug-in based solutions for implementing user interfaces for
web applications follow the above approach. Solutions like Adobe Flash7 ,
Java Applets8 , and Microsoft Silverlight9 all make it easy to write thick clients
and encourage writing single page web applications. Especially Adobe Flash
has gained a lot of popularity over the years, and its development model has
been proven easy and productive. These plug-ins are proprietary technologies
and therefore make them less interesting research topics for us. However, they
are something we can learn from and also consider how we can apply their
best features in our research with open standards.
7
http://www.adobe.com/fi/products/flashplayer.html
8
http://docs.oracle.com/javase/tutorial/deployment/applet/
9
http://www.microsoft.com/silverlight/
24 CHAPTER 2. WEB AS AN APPLICATION PLATFORM

2.4 Summary
We can consider HTTP as the lowest common nominator for building web
services with different technologies. REST embraces HTTP and utilizes its
features – like authentication, cacheability, addressability, and resource ori-
entation – to full extent. On the other hand, RESTful interfaces also need to
be designed with this in mind; they must conform to the uniform interface
defined by the methods of HTTP. SOA, in turn, offers an object-oriented
programming (OOP) [14] approach into building web services; the interface
consists of classes and methods instead of resources. In SOA, the communi-
cation protocol is commonly implemented using SOAP and while this raises
the level of abstraction and provides an RPC style of programming model on
top of HTTP, it also largely ignores the properties of HTTP. SOAP services
usually build around a single URL and use only the POST method [66] for
passing messages. Also, in contrast to REST and HTTP, the WS-* fam-
ily of standards define their own methods for things like authentication and
caching.
One of the standards introduced by WS-* stack is business process exe-
cution language (BPEL). It may be used for defining and executing actions
between web services, thereby making it an orchestration language [103].
Paper [82] introduces a similar concept in the context of Web 2.0 [97] and
mashup applications by introducing a component model for mashup appli-
cations and an architecture that extends the SOA model with mashup com-
position. However, the complexity of these approaches has driven developers
into using custom methods for composing mashup applications. Depending
on the utilized web service, mashup applications are either composed on the
server (thin client) or in the browser (thick client).
Chapter 3

Engineering Complex Web

Applications

So far we have described commonly used approaches for building web services
and web applications. In this chapter, we present our proposed architecture
for building web applications in a way that combines applications and services
into an entity that brings together the best of both worlds. The presented
approach will address the questions and goals of this thesis. Furthermore, by
combining web applications and web services, the resulting application will
automatically entail a web service for programmatic access too. We call this
approach the decoupled way of building web applications.
In contrast, most of the web applications today are thin client applica-
tions. They may employ Ajax techniques to make them more dynamic and
thicker but they still do full and partial page loads where the payload data is
embedded within the HTML. This tightly couples the client and the server,
and the server needs to maintain the state of the application and restore
that state every time a new request comes in. This creates predefined paths
of the application control-flow between the client and the server and makes
reusability very difficult. We call this approach the traditional way of building
web applications.

3.1 Engineering Goals

The engineering goals for our proposed architecture derive from the aspira-
tion to provide an environment for developers where they are able to build
complex web applications, or Rich Internet Applications (RIAs) [51, 42], pro-
ductively and cohesively. This environment helps developers in writing well
behaving applications and services while maximizing code reuse and main-

25
26 CHAPTER 3. ENGINEERING COMPLEX WEB APPLICATIONS

tainability. From these, we can further derive a set of lower level goals. Most
importantly, making it easier for the developers to follow proven software
engineering principles like modularization, responsibility assignment and in-
formation hiding. Granted, these are goals that are good objectives for any
software project, but as we will demonstrate in the following sections, they
hold for web applications in particular. Similar topics are discussed in more
detail in [92] and [19]; here we will only cover the ones that are most relevant
to this thesis.

3.1.1 Modularity
Modularity refers to logical partitioning of software into smaller parts called
modules [101]. Each module hides its internal implementation and all com-
munication with other modules occurs via a well- defined interface. There-
fore modules are self-contained and interchangeable without having to modify
other parts of the software. Along with modularity, principles like separation
of concerns [39] and information hiding [102] are proven to be foundations
for long-lasting software designs.
In traditional web applications with thick clients, modularity is problem-
atic to implement. The logic and functionality is spread over many different
parts and layers of the application depending on the factors like network la-
tency, browser capabilities, and cacheability. This kind of fragmentation and
random optimization blurs the responsibilities of the modules that comprise
the very application. Eventually, module borders are penetrated or put down
completely. This is amplified by the fact that the application logic – imple-
mented in JavaScript (in the browser) or in another language on the server
– is usually mixed with the presentation (HTML and HTML templates).
One of the most important goals of our architecture is to address this
incoherency by introducing and even enforcing a set of rules and guidelines
to bring consistency into responsibility assignment.

3.1.2 Maintainability
From the poor ability to assign responsibilities follows poor maintainability.
In Mythical Man Month [71], Fred Brooks claimed that “The total cost of
maintaining a widely used program is typically 40 percent or more of the cost
of developing it”. However, several sources estimate even bigger numbers for
the cost of software maintenance [100] [37]. The importance of maintainabil-
ity increases with the size of the software. Not only does good maintainability
ensure that changes to the software become easier but it also protects the
architecture from being corrupted over time.
3.1. ENGINEERING GOALS 27

Many frameworks provide conventions for structuring the code and cat-
egorizing different layers of the application. However, these conventions do
not help developers in being coherent in their decisions when building the
application. They may start with the default architecture endorsed by the
framework, but as the application evolves they may seemingly randomly
abandon the original layout and make ad-hoc modifications to the applica-
tion and still adhere to the conventions set by the framework. So, even when
playing by the rules of the framework, code base can end up being difficult
to maintain. Together with the ability to better assign responsibilities for
web applications, we also seek better maintainability for them.

3.1.3 Reusability
Reusability is an important aspect of any real life application [7]. Reusability
refers to software artifacts that may be used in more than one context [113].
An artifact in this case may be, for example, a software module, a component,
or even an application. A precondition to software reusability is modularity
and well defined interfaces.
Reusability has a special role in the field of web applications because the
web offers a platform for not just applications but also services. Therefore,
the functionality implemented in the server should be reusable and not tied to
the one application using it. But even in smaller scale, reusability has been
problematic in web applications because of the fragmented nature of the
code base. One of the goals of our design is to enhance reusability by making
web applications reusable without compromising the overall architecture or
simplicity.

3.1.4 Productivity
Productivity refers to software development methods that increase the qual-
ity and quantity of code produced by a programmer. Measuring productivity
is a problematic topic and it has been covered by several studies (such as [70]
and [1]). Firstly, productivity can be affected by many factors, and secondly
the quality of the produced code should be estimated as well. In this thesis
we only focus on estimating how our proposed architecture can help pro-
grammers become more productive than they would be with a traditional
approach.
Some of the cross-cutting concerns of web can decrease the productivity of
development. Web applications are run on top of HTTP which is a stateless
protocol and at the same time in the traditional thin client approach, web
pages are reloaded into the browser frequently. A common solution to this
28 CHAPTER 3. ENGINEERING COMPLEX WEB APPLICATIONS

problem has been the use of cookies and server side sessions. This means,
however, that the client needs to send the cookie with every request and
the server needs to find and restore the session for each request it receives.
Much of this can be automated by frameworks but there still remains a lot
of boilerplate code for the developers to write in order to fully restore the
state of the application on each request.
Furthermore, developers need to decide how to partition their applica-
tions. They need to carefully think which user events should be handled
by the client and which ones by the server. Parts of the functionality may
be implemented in the client using JavaScript, some parts in the HTML
templates, while most of the functionality is implemented in the server side
programming language. There are many things for the developers to think
about and implement besides the actual application logic. Not only can this
misdirect the architecture of the application and lead into fragmented and
unmaintainable end result but it can also dramatically decrease the developer
productivity.

3.1.5 Responsiveness

In our context, by responsiveness, we mean the responsiveness of the user

interface. In human-computer interaction (HCI)[18], responsiveness is con-
sidered to be an important usability factor. Delays in the user interface may
lead users into thinking that the system is either down or just not accepting
user input. Compared to our other engineering goals, responsiveness is not
only an architectural characteristic but it also entails runtime requirements
for the application. We wanted to have responsiveness as one of our goals
because it is an especially important topic for web applications [117] because
they operate over a network.
In the early days of Internet, network connections were often slow and
web applications had very little, if any, client side functionality. This resulted
in frequent page loads over a slow connection and therefore in poor response
times and frustrated users. Since then, many things have improved. For
example, network connections are much faster, HTTP has been amended
with keep-alive connections, but most notably the advent of Ajax has allowed
applications to load data asynchronously from the server in the background.
However, there is still a tendency in web applications to be less responsive
than their desktop counterparts.
3.2. DECOUPLED WAY OF BUILDING WEB APPLICATIONS 29

3.1.6 Conclusion
We believe that developing web applications should be simpler. In fact, sim-
plicity is considered as one of the characteristics that software architectures
should aim at in general [36]. The developers should be able to focus on the
application that they are building and not be distracted by the additional
cross-cutting concerns of the web, like session management and application
partitioning. Furthermore, when building web applications that are complex,
these issues become even more important. By addressing these issues with
our proposed architecture we are able to provide an environment for the de-
velopers where they can be productive and develop web applications more
like they would develop any other software.

3.2 Decoupled Way of Building Web Appli-

cations
To achieve the goals set for the architectural design and to address the prob-
lems of web application development, we start by breaking the application
to two parts: the server side component and the client side component. We
design these two components to be autonomous, loosely coupled systems that
communicate over HTTP. The server component is a well behaved RESTful
web service, agnostic about the clients using it. The client, on the other hand,
is a thick client, using the browser as its runtime platform while consuming
the services exposed by the server when it needs to. By leaning on the prin-
ciples of REST, we can use REST as a fence to decouple the server and the
client and more importantly it allows us to better define the responsibilities
and characteristics of each individually.
Figure 3.1 illustrates the architectural differences between the decoupled
and traditional way of implementing web applications. Diagram (a) shows
the traditional thin client approach where the web application is implemented
as a series of web pages. Some of the user actions result in a new page to
be loaded from the server, while others may have dynamic content to be
loaded using asynchronous HTTP requests. However, the overall architecture
and behavior follow the thin client approach where users navigate from one
server generated web page to another, and therefore tying the server and
the client implementations into one monolithic application with incoherent
architecture.
The architecture in diagram (b) is a step towards the decoupled approach
by introducing a thick client. The client may even be a single page web
application but the application does not yet define a RESTful API to be
30 CHAPTER 3. ENGINEERING COMPLEX WEB APPLICATIONS

consumable by other applications. There are situations where the data may
still be embedded in the HTML that is dynamically loaded into the browser,
or the data maybe available outside of HTML but it is exposed through a
set of ad-hoc URLs that may have unpredictable side effects. In other words,
the data that the server possesses is not designed to be accessed outside of
the application that it was originally exposed for.
The decoupled architecture is depicted in diagram (c). In this scenario,
the browser application uses the API directly without any indirections. The
data is available to the client the same way that it is available to any other
client and there are no artificial ties between the client and the server com-
ponents.

App Single page App Single page

App Web pages

HTTP data REST data

HTML + data data

data API
App data

(a) (b) (c)

Figure 3.1: Architecture comparison of various approaches.

In the decoupled approach, the client is a single page web application

consuming the RESTful API of the server. The client application may be
pre-loaded into the browser or a specific URL can be used from where the
application is bootstrapped. After that, the communication between the
client and the server consists only of the payload data; no HTML or CSS
is transmitted. This is possible because the data is not embedded within
HTML documents as they are in the case of thin clients. This enables easy
adoption of the service API by different types of clients, applications even.
The client may be a browser application, programmatic client or even a native
application running on a mobile device or a desktop. They all have the same
access to the same web service and therefore are able to consume it as such.
This is a major benefit compared to the traditional way of building web
applications, where the server interface is tightly coupled to the application
that is using it.
When the server and the client become two loosely coupled components,
they both can and must have their own internal architecture. Compared to
the MVC model found in traditional thin client web applications, this means
that in the decoupled approach the whole MVC stack is moved into the client.
The controller intercepts all user interactions within the client and uses the
3.3. REVISITING ENGINEERING GOALS 31

model and the view within the client to carry out users actions. The model
– which also lives inside the client – is the only component contacting the
server. It does so by issuing asynchronous HTTP requests to the server when
and only when it is necessary.

3.3 Revisiting Engineering Goals

In this section we show how the decoupled way of building web applications
yields an architecture that achieves the goals that we have defined. At the
same time, this section explains the architecture in more detail.

3.3.1 Modularity
By its very nature, REST is strictly stateless; there are no cookies or server-
side sessions. From the perspective of responsibility assignment, this means
that the client-side application alone is responsible for storing the state of
the application. The server is only responsible for storing the states of the
resources it exposes. This gives us a very clear separation of concerns. The
browser application becomes an application in its own right, using the server
only when it needs to. The server in turn does not need to know anything
about client applications and their states. Modularity can then be further
defined within each side individually, and no module is fragmented over the
network.
The division of responsibilities in web applications is discussed in further
detail in Publication [i], where we present our guidelines for partitioning web
applications. Publication [v], on the other hand, discusses the modularization
of RESTful interfaces via the use of actor model of computation.

3.3.2 Maintainability
When the application is clearly separated into two autonomous components,
those components have their own architecture and development cycle and
therefore they may also be maintained separately. When separated, not
only are the maintained components smaller but also their responsibilities
become better defined. This helps in keeping the code base maintainable
and adaptable.
In Publication [vi] we have examined maintainability improvements of
decoupled web applications in more detail. We covered areas such as local-
ization, testability, and error handling and also provided experiences from
real world applications.
32 CHAPTER 3. ENGINEERING COMPLEX WEB APPLICATIONS

3.3.3 Reusability
Web applications that follow the proposed design architecture already expose
a RESTful service API that can be reused as such. In the traditional thin
client approach the server side interface makes assumptions about its clients.
Because the state of the application is stored in the server side session and the
data is embedded inside HTML documents, the client is not able to consume
the server interface freely. In the decoupled approach the client application is
able to consume the services without any predefined application control-flow
and thus becomes much more versatile. New applications may be created on
top of the same API but also existing application may be transferred on top
of a different implementation of the same service API. This way both client
applications and the server interface become reusable.
In publication [vi] we investigated the reusability improvements when
breaking the application into two parts. These improvements were examined
from both, the client’s viewpoint and the server’s viewpoint.

3.3.4 Productivity
The development of the RESTful web service and the client side application
can take place in isolation as long as the interface definition is agreed upon.
The absence of server side sessions and application state allows the server
to be developed as any other web service. In Publication [i] we outlined
the guidelines for code partitioning between the client and the server. The
conclusion was that web applications should be implemented as much as
possible in the client. To automate code partitioning for web applications
that are written in JavaScript (also server-side parts), we implemented a code
inspector that dynamically executed parts of the application on the server
and parts of the application in the client.
This approach was taken further in Publication [iv], where we turned
code partitioning into a REST-inspired middleware ([16], [136]) implemented
in CommonJS1 . There, the middleware would intercept each request that
was loading a JavaScript file, inspect the parts that needed to be run on
the server, turn them into RESTful resources, and then inject the returned
JavaScript code with proxies to these resources. While it still holds that web
applications should have a thick client, we have left the idea of automatic
code partitioning as a future research topic. The interface that the server
exposes should be a well behaved RESTful interface translating into domain
models of the application instead of an interface whose resources translate
1
CommonJS specifies a set of JavaScript APIs for different JavaScript runtimes and
libraries to implement
3.4. CONCLUSIONS 33

into functions. Automatic code partitioning is still an important research

topic, but further work falls outside the scope of this thesis. There is also at
least one other research project investigating this problem: [139], [138].

3.3.5 Responsiveness
The decoupled approach encourages in writing single page web applications.
This can mean increased initial load time, but after the application is loaded,
single page web applications can be much more responsive than traditional
web applications because the user does not need to wait for the page to load
but only for the data to appear. This way, the user interface stays responsive
even when data is being loaded from the server.
In Publication [ii] we examined various ways to make applications with
a lot of JavaScript to load faster. This would mean starting the application
with a minimal amount of JavaScript code and then dynamically loading the
rest of the code later. We discussed the advantages and disadvantages of
various approaches and presented our own suggestion for a new primitive to
load JavaScript into the browser environment.

3.4 Conclusions
By following the decoupled approach of building complex web applications,
software architects and developers are able to focus on the design and archi-
tecture of the web application that they are building. They can lean on the
proven software engineering principles and patterns when designing the ar-
chitecture for the client and the server individually. Frameworks and toolkits
should not try to hide HTTP by introducing abstractions on top of it but to
embrace it. By clearly acknowledging the HTTP, building a RESTful API on
top of it and making it available to client side applications will separate the
concerns of web applications and make the responsibility assignment explicit.
34 CHAPTER 3. ENGINEERING COMPLEX WEB APPLICATIONS
Chapter 4

Industrial Scale Case Study

An important aspect for this research was the utilization and verification of
the decoupled approach in industrial setting. From early on, we have had a
unique opportunity of working closely with a company that is in the process
of transforming its core components and applications to be web compati-
ble. It is in their interest to utilize the web as an application platform for
distributing applications but also to provide programmatic access for their
systems. Moreover, as we will explain in the following, reusability of the
applications and the programmatic interface is a key factor when moving
forward with the transition. Our research work has been carried out hand in
hand with this company, and the experiences and conclusions of the trans-
formation process towards the decoupled architecture are documented in this
chapter.

4.1 Introduction
The company we have been working closely with, Stratagen Systems, is a
United States based company, which has offices also in United Kingdom
(Mobisoft UK) and Finland (Mobisoft). Stratagen provides end-to-end soft-
ware for paratransit. Paratransit is a form of flexible passenger transporta-
tion, where routes and schedules are usually not fixed. Stratagen has dozens
of installations in United States, UK, Sweden and Finland. The degree of
flexibility that a paratransit agency offers varies greatly between these in-
stallations. Typically, the fleet of vehicles comprises mini-buses and shared
taxis, but other types of vehicles, such as normal taxis, are also used.
At the high level of abstraction, paratransit has three different types of
actors: passengers, drivers and dispatchers. There are other actors such
as service providers, vehicle operators and funding agencies, but recognizing

35
36 CHAPTER 4. INDUSTRIAL SCALE CASE STUDY

these three actors is enough for the scope of the thesis to provide good enough
overview of the application domain. These actors are presented in Figure
4.1. Stratagen provides software for each of these actors to communicate
throughout the process.

Dispatcher

Paratransit
System
Passenger

Driver

Figure 4.1: Actors in the Paratransit System.

Passenger. Typically passengers are commuters, school children, elderly

people, special needs children, or people traveling to nursing homes or hos-
pitals. They either have a subscription with the paratransit service, or they
book trips individually as they need them. Stratagen provides software for
the passengers to create and manage trips by themselves or they can call to
dispatching center to have a dispatcher to do this for them.

Dispatcher. Dispatchers take in calls from the passengers wanting to book

trips. They have access to much more feature rich software than what pas-
senger themselves have. Using this application dispatchers may book trips
for passengers, schedule them and assign to vehicles. Parts of this process
may be automated if desired.
4.2. PROBLEM STATEMENT 37

Driver. Drivers use mobile applications that run on the devices that are
either handheld or mounted into the vehicle. Using these applications drivers
are able to see the route they should be driving and the passengers that need
to be picked up. The application is also used for reporting back to the
paratransit system and letting it now how a route progresses.

Paratransit System. On top of handling all the communications between

various applications, the paratransit system’s main responsibility is the cre-
ation of optimal routes for a fleet of vehicles. Usually this means that in order
to save costs, as many passengers as possible should share a vehicle. More-
over, the paratransit system is responsible for selecting an optimal vehicle
for each route.

4.2 Problem Statement

Because of the history of the company and its mergers, Stratagen has ended
up with two completely different paratransit systems. Both of these are
systems that have evolved over the years to support a wide variety of func-
tionality. Each one is widely used and have their own family of products
including various desktop applications, web applications and mobile applica-
tions. On top of these, both systems implement several custom interfaces for
third parties. All of these different components are connected to each other
within each system but across the two systems they are completely isolated
and incompatible. There is no data format or communication channel that
could be used for information sharing between the systems.

Problem 1: Two Core Systems. In general, the two core systems have
very similar characteristics; they both provide end to end solutions in the field
of paratransit. They both have different applications for different tasks and
they both have various server side components to handle complicated tasks
such as routing algorithms, vehicle allocation and vehicle communication.
Despite of these commonalities both systems are developed in isolation from
each other. Moreover, there is very little geographical overlap because the
other system is developed and used mainly in North America and the other
one in Europe.

Problem 2: Incompatible Concepts. The first requirement for compat-

ibility or reusability is that the concepts in these two systems are the same
or at least similar enough. For the most parts this is the case, but there
are some incompatibilities in the core concepts that make it difficult for the
38 CHAPTER 4. INDUSTRIAL SCALE CASE STUDY

teams working on different systems to collaborate. If people are not able to

communicate about the concepts of the system without hindrance it would
be impossible for the computer programs across systems to do so. Therefore,
one system would need to adapt to the concepts of the other or a new set of
concepts would need to be agreed upon for the both systems to adapt to.

Problem 3: Incompatible Applications. Incompatibilities in concepts

are one thing but there are also other obstacles in making the applications of
these two systems compatible. One reason is that there are very few interfaces
that would be general enough to support different applications. Both systems
have quite many interfaces for third party access, but most of them are built
to support specific and narrow use cases. Furthermore, there are no agreed
principles regarding protocols or architectures for building these interfaces.
Some of them are built with SOAP, some with HTTP/RPC, and some with
custom TCP/IP messaging.

Problem 4: Incompatible Technologies. The two systems are built on

top of very different technology stacks making it even more difficult to have
any kind of global reusability. The core components of these systems have
strong ties to different database vendors and operating systems, and they are
built with various different programming languages. There are some com-
mon technologies involved when it comes to web applications, but they are
built with the traditional thin client approach thereby making them tightly
coupled with the server side implementation and difficult to reuse.

Problem 5: Incompatible Teams. Both systems have their own teams

for development, testing, support, and marketing. Because of the techno-
logical conflicts and some conceptual differences, it is very difficult to have
teams that are distributed or interchangeable over the two systems. There
are situations where it would be beneficial to have the same team or even
the same person to work on both systems. For example, if a marketing team
would be familiar with both systems, they would have better understanding
which system to offer for a potential customer. Also, support teams would
be able to support either system if the two systems were compatible.
When there is so little convergence in these two systems, it is very difficult
to start the transformation towards better compatibility. Where to start
when even some of the core concepts are not compatible? It is still in the
interest of the company to bring these two systems closer together because
despite all the differences and incompatibilities between them, they are still
serving the same purpose and solving the same problems for their users.
4.3. RE-ENGINEERING 39

4.3 Re-engineering
In order to make best use of company’s resources these two systems should
be merged into one. It must be recognized that this will be a long process
and cannot happen all at once. Instead, the transformation into one system
is incremental and both existing systems will need to continue to co-exist
during this process. In addition to moving towards one system, there is a
strong interest in utilizing the web as much as possible. This means building
more web applications instead of native desktop applications.
In short term, these two systems should be able to support same appli-
cations; applications that are built to be used globally in conjunction with
both systems. For example, any new development – may it be an application
for end users or an interface for a third party – should be implemented so
that it can be used in both systems. In an environment where the systems
are only conceptually connected, this kind of effort requires a lot of planning.

4.3.1 Defining Core Concepts

Defining the core concepts is the foundation for reaching towards global
reusability and compatibility. Before any two systems are able to communi-
cate they need to be able to speak the same language. This is true for the
applications as well as people working on the applications. Fundamentally,
the definition of core concepts means identifying the concepts that are rel-
evant to the domain and then refining those concepts by recognizing their
properties and relationships to other concepts.
To help in this process, teams chose to follow the practice of Domain
Driven Design (DDD) [44]. The fundamental idea in DDD is the definition
of a domain model and using that as the basis for everything else; may it be
the spoken language or the software architecture of the system being built.
As a result, a language – referred to as the ubiquitous language – will be
formed, and it is shared and understood unambiguously by all stakeholders.
The language, the domain model, and the resulting code are all tied together
to respect the same definitions of the core concepts.
It should be noted that DDD also identifies various patterns for aiding in
building the architecture for software as well as interfacing with legacy sys-
tems. These include patterns like Entity, Value Object, Repository, Factory,
Specification and the Anti- Corruption Layer [49] [44]. While proven useful,
discussing these concepts is outside the scope of this thesis.
Defining the one common domain model has been a time consuming pro-
cess. However, not only is it imperative but it has also revealed in detail
the parts of the systems that are incompatible. An unexpected benefit that
40 CHAPTER 4. INDUSTRIAL SCALE CASE STUDY

was gained from this process by the teams is the realization that not all
concepts have been clear nor well defined even within these systems. These
incompatibilities can then be worked on and the domain model ironed out to
make it work for both systems as they are moving forward. The refinement
of the domain model is an ongoing process as is the design of the software
architecture itself; both will be improved iteration by iteration.

4.3.2 Defining High Level Architecture

The one common domain model bears a lot of value by itself. It brings
the teams closer together and allow them to speak the same language. It
also makes new applications that conform to this model at least conceptu-
ally compatible. But to allow true compliance of applications and systems,
the applications should be interchangeable between the systems, and the
systems should have compatible interfaces to allow communication of core
components.
A common approach used in software for dealing with different imple-
mentations of, for example, a class library is to apply Adapter and Facade
patterns [53]. Their applicability is not restricted to low level interfaces but
they can also be used in masking the differences and complexities in bigger
software components, services even. This is the approach that was also cho-
sen by Stratagen; based on the common domain model, an interface (or a set
of interfaces) that can be supported by both systems, is defined. This inter-
face will then be consumed by all future applications developed by Stratagen
and third parties.
Figure 4.2 depicts the original situation where the two systems are com-
pletely isolated and they both have their own set of applications and inter-
faces connected to them. Following the decoupled approach, the first step
is to implement the interface on top of both systems. After that, new ap-
plications can be built on top of it or existing applications may be ported
to make use of the interface. As the Figure 4.3 shows, old applications can
now co-exist with new ones when both systems implement the same interface
specification. Even though there still exists two different systems with two
different implementations of the same interface, the company has already
improved the reusability and compatibility of the systems: applications may
now be built only once and used in conjunction with either system. More-
over, new applications are able to reuse the functionality already available in
the interface.
During the process of implementing new applications or porting old ap-
plications to consume the interface, the applications themselves may be re-
designed and their responsibilities re-evaluated. As a result, the whole prod-
4.3. RE-ENGINEERING 41

A A B B

A System A A B System B B

A A B B

Figure 4.2: Initial Architecture.

AB AB AB

Interface / API

A B

System A System B

A B

A B

Figure 4.3: Reusable Applications and Interface.

42 CHAPTER 4. INDUSTRIAL SCALE CASE STUDY

uct family will be more concise and may share similar look and feel. When
more applications are implemented on top of the interface and old ones be-
come obsolete, also the underlying systems can start to migrate safely behind
the interface (see Figure 4.4). Indeed, the ultimate goal is to fully merge these
two systems into one, and when that happens, only one implementation of
the interface is needed as shown in Figure 4.5. There are various approaches
into architecting this merger but discussing them falls outside the scope of
this thesis. Our goal here is to define the high level architecture for this kind
of transition in web environment and to demonstrate how the decoupled
approach supports this transition.

AB AB AB AB

Interface / API

System A System B

Figure 4.4: Systems Can Now Merge.

AB AB AB AB

Interface / API

System AB

Figure 4.5: Eventual Goal.

4.3.3 Applying the Decoupled Approach: The Server

In order to implement the interface to its systems, Stratagen decided to define
one interface to cover all functionality. This interface will eventually support
4.3. RE-ENGINEERING 43

all applications and it is shared by company’s own products as well as third

party applications. This sets high demands for the interface’s flexibility and
accessibility. Clients accessing the interface will have many different envi-
ronments running on many different devices. Moreover, clients have diverse
requirements for the interface in terms of read/write access and level of detail
exposed by the interface. By choosing REST as an architectural model for
implementing the interface solves many of these challenges by conforming to
well established HTTP standard and bearing no overhear on top of it. Also,
the fact that DDD is used to model the domain, helps in mapping the model
into a REST API. In [137] Selonen explains an approach to mapping from
domain model into resource model by identifying different types of resources
and how they can be identified as addressable resources.

HTTP and therefore also REST – being closely associated with it – allows
web applications to consume the interface directly from the browser. It is
the lowest common nominator for applications using the web as a platform.
HTTP is also widely supported among various devices and platforms, and it
provides built-in support for authentication, security and caching.

Resource oriented architecture of REST combined with authorized re-

quests allows straightforward and flexible implementation of access control
for the interface. RESTful HTTP requests occur in complete isolation, and
therefore each request bears with it a header that can be used to authorize
the request. Thus, access control can be implemented per resource and per
HTTP method, allowing different clients to have very different view of the
interface. For example, passenger’s mobile application may only have a very
narrow read-only access to the interface, while dispatchers have full access
to most of the resources. So, even when the interface is actually the same, it
can be easily configured to support different scenarios.

Piecemeal implementation of the interface is important for large inter-

faces where many different client applications are supported. One applica-
tion may only utilize a small subset of the interface and therefore it is not
necessary to implement the whole interface up front. The interface can be
deployed as new functionality becomes available, and new applications can
make use of it. The resource orientation of REST naturally supports this
kind of approach, where resources may be implemented one at a time as new
client applications need them.
44 CHAPTER 4. INDUSTRIAL SCALE CASE STUDY

Versatility of a RESTful interface allows leeway for clients to implement

different kinds of applications on top of the interface. When the interface
comprises resources instead of functionality and the protocol is stateless as
opposed to having a protocol-defined control-flow for applications, the clients
are in charge of how they want to consume the interface. Moreover, the
designed API should conform to the domain model and not to any specific use
case or client application. Similar approach is also encouraged in paper [79]
although the perspective is different. This kind of design is closely associated
with reusability of the resources. Applications that are implemented later will
have greater chance of being able to reuse some of the existing resources and
are therefore quicker to implement. For example, in Figure 4.6 the application
AB’ is implemented first and for that application three new resources are
implemented into the interface. Later, when application AB” is implemented,
two new resources are implemented but the third one can be reused.

AB´ AB´´

Interface / API

Figure 4.6: Reusable Resources.

4.3.4 Applying the Decoupled Approach: The Client

One of the goals of the whole transition for Stratagen is to move much of
the applications into the web platform. This would allow easier hosting
and deployment of software that has traditionally been somewhat laborious.
Currently Stratagen has many desktop applications, mobile applications, and
web applications. While the goal is to eventually have all applications con-
sume the same interface, it is not the intention to port any of these applica-
tions directly as a client of the RESTful interface. Instead, each applications’
functionality is evaluated and redesigned.

Single Page Architecture

In the traditional approach of building web applications, the user interface
is implemented as a series of web pages with a server side component that
4.3. RE-ENGINEERING 45

renders them. However, in the decoupled approach, the application running

in the browser can consume the API directly and not circulate the requests
via the server side component. Implementing the user interface as a single
page web application supports this approach by freeing the server from having
to send any HTML or CSS to the client after the initial bootstrapping of the
application. The client can call the REST API directly thereby making it
more like a standalone application that is just using the REST API as a
service.
In the single page architecture, applications use the browser as their only
runtime environment. This improves the reusability and portability of appli-
cations because they have no application specific server side component that
is platform dependent. Standalone browser applications can easily be trans-
ferred on top of another implementation of the same interface. For Stratagen,
this is notable factor because there are two different implementations of the
same interface.

Porting Applications
At the time of writing, there are five single page web applications that have
been implemented on top of the RESTful interface. Two of them are new
applications, one is an old web application and two are old native applica-
tions. On top of these there are two programmatic clients implemented by
third parties that are consuming the interface.
When new applications are built or existing ones ported to conform to
the decoupled way of building web applications, the following questions need
to be asked:

1. What functionality does the application require from the server (i.e.
what is it that cannot be done in the client)?

2. How is that functionality defined in terms of the REST API?

3. Are the required parts already present in the interface?

4. If not, new resources will need to be implemented so that they are in

line with the Interface specification.

After these questions have been answered to and necessary resources im-
plemented into the interface, the application may be implemented as a single
page web application. The applications implemented so far use a varying set
of JavaScript libraries and tools but they all share the same characteristics:
they all make heavy use of JavaScript and they are all built around the MVC
46 CHAPTER 4. INDUSTRIAL SCALE CASE STUDY

pattern. Some of the applications employ JavaScript libraries that allow them
to be written entirely in JavaScript thereby making the development expe-
rience similar to traditional desktop programming. Regardless of the tools
and libraries, the decoupled architecture lowers the barrier for developers not
familiar with web development to start building web applications.

Mobile Applications
Out of all the applications built so far, two are mobile applications. One is an
application originally implemented for desktop browsers and the other one
was built from the ground up to be mobile only. The one that was originally
implemented for desktop browsers, was optimized to be mobile friendly by
using CSS Media Queries [57]. Thus, the mobile version of the application
has all the same features as the desktop version and is used with the device’s
browser by navigating to the corresponding URL. The application has been
tested with many of the more recent mobile devices and even though it has
a rich set of functionality, there has been very little performance problems.
The other application was built with Sencha Touch [115, 73] and Phone-
Gap [105, 131] to look more like a native application that can be installed on
the device. Even though the browser is not visible to the user in this case, it
is still the runtime environment for the single page web application. Initially,
the application was a lot of transitions and animations in the user interface
but as the application was tested with more low-end devices, the decision
was to leave them out to improve performance.

4.4 Evaluation
In order to evaluate the applicability of the decoupled architecture we did
several comparisons and interviews inside the company. Based on the goals
set for the suggested approach and this thesis, we came up with a set of ques-
tions that we wanted to present to the interviewees and a set of comparisons
we wanted to do with the applications. We interviewed several developers
and architects about the development model in general. Our sample was
small; only five developers, but it was still beneficial to see whether there is a
trend in the answers. Four of the interviewees had several years of experience
in web development while one developer was fairly new to web development.
Here are the questions that were asked:
When comparing the decoupled approach to the traditional thin client ap-
proach of building web applications,

• how do you see modularity taking place?

4.4. EVALUATION 47

• what are your thoughts on the overall software architecture?

• how would you compare productivity?
• what are the main differences in writing tests?

The answers showed a trend towards enhanced modularity in web applica-

tions when built with the decoupled approach. Two of the answers included
a notion of ”convention over configuration” [135] that frameworks like Ruby
on Rails and Django provide. This was seen as a palliation to the poor
modularity of web applications in general but not as a proper solution. The
developers with most experience in developing web applications with various
frameworks appreciated the decoupled architecture the most. One reason
that was mentioned for this is that the architecture is framework agnostic;
HTTP and its request/response model is embraced as opposed to being hid-
den from the developer. The benefit of doing so is that many developers are
already familiar with HTTP protocol and its headers but they may not be
familiar with a given framework.
As a result of enhanced modularity, responsibility assignment and sepa-
ration of concerns were seen as being improved. Therefore, also the overall
architecture was more concise and easier to comprehend. The one developer
with less experience in web development compared the modularity and ar-
chitecture to the desktop programming counterparts. In the answer, he did
not see any improvement in modularity or architecture in general but more
importantly, he was comfortable with the decoupled architecture of web ap-
plications and was able understand the responsibilities of various components
quickly.
The answers regarding to productivity were scattered the most. On one
hand, it was pointed out that many web frameworks have streamlined the
generation and implementation of web applications to the point where devel-
opers can be very productive. Moreover, implementing SPAs was considered
as being very much in its infancy and the amount of libraries and the variabil-
ity in their quality was seen daunting. On the other hand, it was also noted
that the lack of tooling in the decoupled approach can be compensated by
allowing the development of the server and the client occur individually and
in parallel. It is our conclusion that the productivity of a single web appli-
cation is greatly dependent on the chosen libraries, frameworks and previous
experience of the developers. However, the overall productivity when multi-
ple applications or APIs are implemented is increased due to the reusability
of the interface.
The conclusion regarding testing was that it was easier to write tests for
decoupled web applications. When the user interface is decoupled from the
48 CHAPTER 4. INDUSTRIAL SCALE CASE STUDY

server side implementation, tests can be written for both individually. The
server API can be tested without the client and the client can be tested
without the server. Multiple answers stated that significantly more tests
were written with the decoupled approach.
Aside from the answers, it should be noted that while most existing test
tools are meant for testing traditional thin client applications, the tools for
testing single page applications are evolving rapidly. A good example of
this is the AngularJS [3, 74] library, which supports Test-Driven Develop-
ment (TDD) [8] of single page applications. Because SPAs run fully in the
browser, many of their features can be tested without the server. Tests for
the server (REST API), on the other hand, may either be written using the
tools provided by the server side framework or as a separate test application
which sends HTTP request to the API and checks the results. Therefore de-
velopers have better access for writing automated tests for web applications
and more bugs can be detected without the help of the test team.

4.5 Discussion
At the time of writing, there are two implementations of the RESTful inter-
face, one for each system. They both implement their own set of resources
which are partially overlapping. Both implementations are still far from being
complete but they are already able to support several single page web appli-
cations. Even though there are many resources that are only implemented
in either system, the domain model that these implementations are based
on is agreed upon and therefore the implementations can safely progress in
different order. These interfaces can be thought of as being Anti-Corruption
Layer s [44] to the underlying systems; they mask the quirks of legacy sys-
tems and keep the interface itself clean and according to the agreed domain
model.
The transformation towards global reusability and one common interface
has brought the teams working on different systems closer together. They
are starting to speak the same language via the mutually agreed domain
model and the development efforts for new applications are gradually being
spread across the teams. So far, there is only one application that can be
used on top of either interface, but this is purely a business decision as
opposed to a technical one. The applications are still very new and they
have been implemented based on a customer request and market demand.
North America and Europe have different customers and therefore requests
for new features and applications do not always go hand in hand. However,
this has been more a matter of prioritization in marketing and development
4.5. DISCUSSION 49

and not a question of whether the applications will be used on top of both
systems. This will take place eventually as the implementation of these
interfaces progresses.
Even when the two systems are technologically incompatible, by follow-
ing the decoupled way of implementing web applications, the company has
quickly been able to reuse client applications on top of both systems. The
decoupled approach has also increased the productivity for developing new
applications and interfaces for third parties. This is mainly because of the fact
that the web applications consume the RESTful API directly and therefore
share the same resources with other applications and programmatic clients.
This increase in productivity has also been acknowledged by the management
as they have witnessed new applications being delivered quicker than before.
Some of the applications that have been implemented on top of the REST-
ful interface have drawn interest even outside the teams working on the two
paratransit systems. For example, a taxi system – whose domain model is
not too far from paratransit’s – can reuse an application originally built for
a paratransit system by implementing the required subset of the interface.
This kind of reuse that spans over the application domains bears even more
value to the company.
Based on the positive results and strong endorsement by the management,
Stratagen will continue to apply the decoupled approach of implementing web
applications. It will keep on evolving the domain model and the RESTful
interface specification of the one common paratransit system. Moreover,
the two interface implementations are actively being developed as new web
applications are implemented on top of them. Behind the interface, the
transformation of the two core systems has also been started by introducing
a first common service that both systems can utilize.
50 CHAPTER 4. INDUSTRIAL SCALE CASE STUDY
Chapter 5

Related Work

In this chapter we examine topics that are related to our research and this
thesis. These topics share similar goals as our work; they seek to unify and
bring coherency to web application development. There exists a great deal
of research around REST and web services but we want to examine existing
research work and tools that address web development on a level that deals
with full web applications, both server and client, and not to revisit the
architectural level discussion given earlier in Chapter 2.
Similarly, there has been several studies on finding a modeling language
for Rich Internet Applications, WebML [20] being one of the more popular
ones. Specifically, in [107] Preciado et al. define the modeled features of
RIAs and give comparison of existing methodologies to do so. Again, we are
not going to go into details of these approaches, since their focus is more
on the code (or other artifacts) generation for a single web application and
not on the reusability, architecture and development model. Furthermore,
many of them seem to be more suitable for modeling traditional thin client
applications.

5.1 Domain Specific Languages

Domain specific languages (DSL) [89] remove low-level boilerplate code and
are focused on solving problems of a specific domain. For developers, this
gives the advantage of being able to better focus on the problem the applica-
tion is trying to solve rather than being overwhelmed by the infrastructure
required for building the application in the first place. The trade-off is –
other than implementing the DSL – possible inflexibility of the language. In
the following we will examine three of such languages.

51
52 CHAPTER 5. RELATED WORK

5.1.1 Mawl
Created already in 1995, Mawl [77] is the oldest DSL for building web ap-
plications. It is targeted directly for form-based services [5] because at that
time HTML forms were the only way to build interactive web applications.
In Mawl, user interactions are modeled as traditional user input and output
actions. Here, a web page is considered as being the input and output for a
sequential program that runs on the server. Developer wrote the service logic
using the domain specific language along with the user interface in HTML
templates. A separate compiler then processed these files and produces a
series of CGI scripts.
Mawl’s programming model allows it to hide the details of HTTP and CGI
from the developer. Furthermore, it addressed issues like session management
between requests, usage of HTML templates, and HTML and form validation.
Later on, these issues were solved by many other web frameworks. We were
not able to find any recent articles or other activity related to Mawl and
therefore comparing it to our work today is not reasonable.

5.1.2 WebDSL
WebDSL is a domain specific language for web applications with rich data
model [130]. At the time of writing, it is built on top of Seam framework
[114, 140] and Java EE [69]. WebDSL consists of several sub-languages, each
of which are used for a specific task such as user interface, data modeling,
workflow, database querying, validation and access control. Via linguistic
integration [58] these sub-languages can be combined together to have unified
syntax and semantics throughout the application. WedDSL also provides
static consistency checking of web applications [61]. This helps in avoiding
late failures in things like using undefined keys in HTML templates and
broken links because concepts like links and template variables are first class
citizens of the language and can be checked during compilation.
Comparing to our work, WebDSL shares our aspiration in bringing uni-
formity to web development and therefore making it easier to write web ap-
plications. The approach however, is very different. WebDSL is well suited
for traditional form based applications with thin clients. It provides data
binding from forms into models and data validation. It also couples the
client and server tightly together and has no notion of building web services.
Paper [61] elaborates on the benefits of being able to statically check the
consistency of web applications. Our approach also helps in error handling
but by separating the responsibilities of error handling into server and client
components; both parties are responsible for handling errors and always as-
5.2. XFORMSDB 53

sume that the other end may fail or not be reachable. We also believe that
you will always need a comprehensive test suite in any case [118].

5.1.3 A DSL for Generating Web Applications

Publication [17] introduces a domain specific language for generating web
applications via model transformations. The process starts with a UML do-
main model and involves model to model (M2M) and model to text (M2T)
transformations in order to produce running code. The publication defines
semantics of web applications and based on that a meta model is defined.
This metamodel is an abstract model that identifies all components neces-
sary for creating complete web applications. Based on that model a domain
specific language with concrete syntax can be defined.
While the approach demonstrated in the publication looks elegant and
indeed would help developers in building data driven web applications, we
were not able to find any information of any real world appliance of this
tool. Also, the whole concept relies on the fact that web applications can be
implemented using only the semantic concepts presented in the paper. These
include forms, lists, detail pages, dynamic lookup components, enumerated
fields and primary keys. This may work well with data-centric thin client
applications, but our assumption is that many real world web applications
need more flexibility. Furthermore, our work focuses on modern and complex
web applications and that is why more thorough comparison to our work is
not meaningful.

5.2 XFormsDB
In Publication [78] Laine et al. presented a server side extension to the
XForms markup language [29] named XFormsDB1 . It is a framework that
allows declarative implementation of web applications based on W3C stan-
dards. Being an extension to XForms, the framework relies on XML docu-
ments and their transformations. The same XML schemas can be used on
the client and on the server for data validation. In XFormsDB, the user
interface is built with Embedded XHTML and XForms without any exten-
sions. The proposed extensions to the XForms language are implemented in
the server where they can by used to implement the application logic and
database queries. Specifically, the database is accessed with XQuery [30],
which is a language for querying and manipulating data in XML documents.
1
https://code.google.com/p/xformsdb/
54 CHAPTER 5. RELATED WORK

XFormsDB is well suited for simple data-driven web applications. It

is targeted for users that are content providers and web designers whereas
our proposal is targeted for programmers implementing complex web appli-
cations. Both approaches aim at bringing coherency to web development;
XFormsDB via declarative mark-up syntax throughout the application and
our approach via architectural conventions and proven software engineering
principles. It should also be noted that XFormsDB has no support for ex-
posing a web service API and at the time of writing XForms itself has very
limited browser support.

5.3 Lively Kernel

The Lively Kernel is an open source platform for developing and running mo-
bile and web applications [123, 65, 93]. It resembles a desktop environment
with its window-based approach and the ability to run many applications
simultaneously. The development environment of Lively Kernel provides fa-
cilities for building rich, single page web applications that conform to the
MVC model. It is written entirely in JavaScript and therefore all the appli-
cations running in it are also written purely in JavaScript; no HTML or CSS
is required.
The user interface is built on top of the JavaScript version of the Morphic
[87] framework. Morphic was originally developed for the Self [128] language,
and later incorporated into the Squeak Smalltalk system [64]. The JavaScript
version of Morphic is built using scalable vector graphics (SVG) [34] and it
excels in providing user interface components that are dynamically editable,
composable and animatable.
Together with the Morphic framework, Lively Kernel provides integrated
development environment within itself. Tools such as class browser, object
inspector, and code editor make Lively Kernel self-supporting and able to
extend itself dynamically. There also exist tools for the development, modi-
fication, and deployment of applications in the Lively Kernel.
Projecting Lively Kernel with our research work, the development capa-
bilities baked into it make it a good match for our proposed architecture. Of
course, applications that run inside the Lively Kernel are client side applica-
tions only. If an application needs other services, it is outside the scope of
Lively Kernel. On the other hand that also means that Lively Kernel does
nothing to prevent any kind of service to be accessed, including RESTful web
services. Hence, a web application conforming to our proposed architecture
could use Lively Kernel to implement the client application for the browser.
5.4. GOOGLE WEB TOOLKIT 55

5.4 Google Web Toolkit

Google Web Toolkit (GWT) is an open source tool allowing developers to
write web applications completely in Java. This means that the user interface
too is written in Java rather than JavaScript. GWT also removes much of
the need to manually write networking code (that is, HTTP requests) by
hiding the communication behind Java interfaces. GWT provides a set of
user interface widgets that developers can use to build their applications but
there are also other frameworks that are built on top of GWT – such as Ext
GWT [129] and Vaadin [50] – that extend GWT to provide a richer set of
user interface controls.
Running of GWT applications has two modes. In development mode, ap-
plications are executed and debugged without the browser in the Java Virtual
Machine (JVM) [81] using GWT’s built-in runtime environment. In produc-
tion mode, applications are compiled from Java source code into HTML and
JavaScript and executed as native web applications.
Even though GWT shares our goal in bringing coherency into web devel-
opment, it does so in a very different way compared to what we are proposing.
It adds a layer of abstraction on top of HTTP that hides the browser and
the communication layer from the developer. While GWT permits different
programming models, the encouraged practice is to use the provided meth-
ods for communicating with the server which means invoking the generated
functions of remote interfaces. Underneath, these functions are implemented
as RPC style function calls to the server. This approach tightly couples the
server and the client implementations and therefore make them difficult to
reuse.

5.5 Ruby on Rails

Ruby on Rails comes from a class of frameworks that are very suitable for
building traditional thin client web applications. Other similar frameworks
are Django (for Python), Grails (for Groovy) and ASP.NET (for C#). As
many other frameworks, Rails builds on the MVC pattern. The model is
traditionally mapped to a table in the database. The controller implements
one or more actions, which in Rails are HTTP requests made by the client. A
controller may use models to query the database and then choose appropriate
view to be sent back to the client. Views are implemented as HTML tem-
plates and converted into HTML at runtime. By default, Rails uses eRuby
templating language.
Ruby on Rails was originally released in 2004 and version 1.0 came out in
56 CHAPTER 5. RELATED WORK

2005. Due to its streamlined development model it rapidly gained popularity

among web developers. Rails relies heavily on the convention over configura-
tion paradigm and provides tools for developers to quickly set up application
scaffolding and run database migrations. These aids and the Ruby program-
ming language itself make Rails very productive environment for building
web applications.
In contrast to our proposed architecture, applications created with the de-
fault workflow in Rails, follow the traditional thin client approach. However,
nothing in Rails prevents developers from implementing web applications
with the decoupled approach. Rails has good support for building REST-
ful APIs and on the other hand, the later versions also have Asset Pipeline
to better support JavaScript-heavy user interfaces. Therefore, developers
should not follow the default pattern for building web applications in Rails,
but to create the RESTful API and the client-side application separately.

5.6 Meteor
Meteor is a platform for building web applications fully in JavaScript. It
offers a unique approach to building web applications by allowing developers
to write JavaScript functions that are run either on the server, on the client
or both. It is targeted for single page web applications and features like
collaboration and data synchronization are built into its core. One of its
distinct features is to provide access to database from everywhere. That is,
developers are able to run the same database queries on the client as they
would on the server.
Meteor achieves these features via its server-side methods and Distributed
Data Protocol (DDP). Server-side methods offer access from client to arbi-
trary JavaScript functions running on the server. DDP on the other hand
solves the problem of accessing and modifying data on the server and then
pushing changes to all clients. Meteor also provides streamlined development
workflow by providing the initial application scaffolding and running its own
development server. The development server uses WebSockets [45] to enable
hot code push during development. This means that whenever a development
file is changed, Meteor automatically pushes code changes into the browser
while the client side of Meteor updates the runtime accordingly.
In many ways Meteor is in line with our approach and we have indeed
investigated similar concepts. For example, in Publication [i] we presented
our implementation of JavaScript functions that run on the server but are
callable from the client. In Publication [iv] we demonstrated how the same
thing could be done automatically at module level. Various methods for
5.6. METEOR 57

implementing collaborative code sharing features were investigated in Pub-

lication [iii]. Therefore, by seeking to provide easy and uniform develop-
ment model for building modern web applications, supporting fat clients,
and transferring only data at runtime, Meteor shares many of our goals.
However, it has one key difference when compared to our approach: Meteor
hides the HTTP and provides tight interaction between the client and the
server while our approach emphasizes the reusability of the server side API.
Meteor allows developers to easily write both server and client side for mod-
ern and collaborative web applications but it is not particularly well suited
for writing either one alone. For example, at the time of writing it has no
support for building APIs and to support single page clients, it uses another
set of libraries. Also, if meteor would only be used on the client side, its core
features such as collaboration and data synchronization would be lost.
58 CHAPTER 5. RELATED WORK
Chapter 6

Conclusions

In this thesis we have presented an approach for implementing web appli-

cations in a manner that embraces proven software engineering principles.
Principles that have somewhat been forgotten as the web has evolved from a
mere document distribution platform into a platform for feature rich appli-
cations. Instead of trying to invent something completely new – in terms of
technology or abstraction layers for instance – we have relied on established
standards and keeping the architecture simple and transparent. In the thesis,
we have examined engineering of web applications mainly in terms of modu-
larity, maintainability, reusability, and development environment. However,
these objectives spawn several smaller improvements when compared to the
traditional thick client model. These are covered in detail in Publication [vi].
An important objective of this thesis was to evaluate the applicability of
the presented architecture in industrial setting. In the thesis we described the
application domain and environment where this undertaking was carried out.
We also presented a thorough evaluation of the suitability of the approach
in that context. The feedback from both, the developers and management
were largely positive and the results promising which lead the company into
making commitment to the new platform and its utilization in future appli-
cations.
While the approach presented in this thesis is not entirely new, the con-
text and the evaluation make the contributions unique. Moreover, many of
the existing web applications that come close to the presented decoupled
architecture, implement different APIs for the application itself and for 3rd
party access. We emphasize the reusability of the RESTful interface by main-
taining clear separation of responsibilities between the client and the server.
Also, when it comes to browser based applications, we argue that they should
be implemented as single page applications that use the RESTful interface
directly without any indirections.

59
60 CHAPTER 6. CONCLUSIONS

6.1 Introduction to Included Publications

In Publication [i] we focused on the partitioning of web applications between
the client and the server. We presented a set of guidelines to be used as a cri-
teria when making decisions about web application architecture. Following
these guidelines we also implemented and presented a platform for hosting
web applications that are automatically partitioned at runtime. The devel-
oper still decides which parts are run on the server and which parts are run
on the client but the platform handles the task of partitioning and seamless
communication between the two sides. The applications are implemented
in JavaScript and we therefore needed to have a JavaScript runtime on the
server. At that time this was not a mainstream approach and we ended
up implemented a lot of low level functionality which are now part of other
JavaScript runtimes (such as Node.js [95, 106] and its libraries).
The example application that we built and demonstrated in Publication
[i] used the Lively Kernel platform on the client side. This fat client approach
lead us to do further research on how to make web applications more respon-
sive, performant and secure in general. In Publication [ii] we suggested a new
primitive for browsers that would benefit dynamic JavaScript loading. We
thoroughly examined all current methods for dynamic code loading and then
presented how our suggested new primitive would tackle current problems.
Our research work with fat JavaScript clients and code partitioning con-
tinued in Publication [iii] where our main focus was on real-time collabora-
tion. In this publication, we took the platform we built during Publication
[i] and we enhanced it with collaborative features so that client side applica-
tions would be able to share massages and even code in real-time. The main
research topics dealt with pushing data into the client, object serialization
and remote code evaluation. To demonstrate the conclusions of our work we
implemented few JavaScript applications on top of our platform that were
able to not share messages and application code between clients.
Continuing our research work on server side JavaScript, we added new fea-
tures and refined our platform for running JavaScript based web applications.
By this time, the CommonJS1 group had proposed a standard for interfacing
JavaScript applications from web servers (JSGI [21]). This specification also
included the notion of middleware [142] components. In Publication [iv] we
presented our JSGI and middleware based platform in detail. Even though
the platform does not follow all the principles of REST verbatim, we adapted
it to suit our needs. More importantly, it acted as a catalyst in our research
work around REST.
1
http://www.commonjs.org
6.2. THESIS QUESTIONS REVISITED 61

In Publication [v] we took REST related research further and combined

the idea of Actor computation model with the principles of REST. Our claim
is that by defining RESTful services as a network of actors we are able gain
better understanding of REST itself. In the publication, we identified the
analogy between the core principles of REST and the core components of
the Actor model of computation. We also suggested a notation for defining
RESTful services in terms actors.
We used the results and experiences of our research work done so far to
formulate a design approach for building web applications. This approach
was first introduced in Publication [vi] and refined in the introductory part
of this dissertation. In the publication we evaluated all the pros and cons of
the suggested approach in detail and presented a real world application that
was implemented using this approach. This publication can be considered
the corner stone of our research work. It pulled together the research work
we had done so far and at the same time, it provided good foundations and
direction for future research work.

6.2 Thesis Questions Revisited

In this section we will revisit the thesis questions presented in Section 1.2.
We will explain how the approach presented in this thesis answers these
questions.

• Software engineering principles: When the server side component

is clearly separated from the client, it can be implemented as web ser-
vice, rather than web application. In other words, the server does not
need to support cookies, sessions or generate HTML for the client. It’s
architecture and implementation may follow patterns and principles
typical for servers [10]. The same applies to client too: it can be imple-
mented more like a traditional client that is not dependent on the server
for rendering its user interface. It can be autonomous application and
for example fully implement the MVC pattern.

• Application logic: With the decoupled architecture, the client should

implement the application logic as much as possible. The server pro-
vides services that the client may use, but it is the responsibility of the
client to implement fully functional application. This makes services
provided by the server more generic and reusable by other applications.

• Thick or thin client: Because the client becomes responsible for im-
plementing the application logic and the server only provides services,
62 CHAPTER 6. CONCLUSIONS

the client becomes more independent and therefore also thicker. It is

also our guideline that clients should be implemented as single page
applications.

• Partitioning: In the decoupled architecture, partitioning of web ap-

plications is explicit and strict. The server provides services to be
consumed by the clients but it does not generate HTML pages where
the data is embedded within the page. The client, on the other hand,
includes all the necessary assets for implementing the fully functional
application. This approach makes automatic code partitioning possible
(provided that both sides are implemented in JavaScript) but such a
possibility is not investigated in this thesis.

By answering these questions and elaborating on their details, we have

been able to bring increased coherency into building web applications. Through
coherency, we can reach our final goal of making the process of developing
web applications simpler and more productive.

6.3 Future Work

Here we list some of the topics that are outside the scope of this thesis but
are things that we would like to address in the future.

6.3.1 Access Control

Regarding the server side of web applications and REST, our next research
subject involves access control and authorization. We aim at finding a way
that would enable the definition of, what we call, a four tiered access control
for REST APIs. These four tiers are:

1. Filtering by resources: ability to define which resources clients have

access to.

2. Filtering by methods: ability to define (per resource) which methods

of the REST clients may apply for the resource.

3. Filtering by row: ability to define which set of data client has access
to. For example, if the client asks for all the orders (GET /orders/),
the server should only return the orders that the client has access to
and not all the orders of the system.
6.3. FUTURE WORK 63

4. Filtering by property: ability to define which properties of a repre-

sentation the client has access to. For example, if there was a Person
resource, some clients might have access to all the properties of a per-
son, while others would not have access to social security number.

6.3.2 Coherency to Building Single Page Applications

On the client side, we will concentrate on finding more coherent ways to
build applications for the browser. Recently, there has been an emergence of
libraries that support building single page applications. However, many times
developers end up mixing and matching different libraries which can lead to
problems with compatibility, maintainability and testing. Libraries may also
overlap in terms of functionality and developers can end up implementing
same things in different manner. We feel that developing applications for
the browser should be more like developing applications for the desktop,
where the developer usually deals with a single framework (such as Qt [108,
13], GTK+ [59, 76] or WPF [91, 85]). This would provide more uniform
development model by not having to mix different styles, conventions and
functionality.

6.3.3 Distributed Notifications

Distributed notifications have always been a problematic concept in the web
environment. With the advent of WebSockets and concepts like Webhooks, it
is possible to implement two way communication between client and server.
However, there is still no well established convention on how to implement
that with SPAs interfacing with a REST API. This is also one of the areas
we should further investigate.

6.3.4 Server Side Rendering

The architecture, as we have proposed it, incurs only client side rendering
for the user interface. For big web applications, this can lead to longer initial
startup times as the whole JavaScript application (and libraries) needs to be
loaded into the browser before anything can be shown. This has also to do
with deep linking with URL-anchors (hashbang) discussed in Section 2.3.2
because the anchor part of the URL is never sent to server, so it would not
be even possible for the server to pre-render the requested page for the client.
A good example of this is Twitter which recently (in 2012) moved most of
their client side rendering to server and gave up the use of hashbang in their
URLs [127]. Initial page load time is very important for them because they
64 CHAPTER 6. CONCLUSIONS

want to be able to give their users the possibility to enter their first tweet as
soon as possible (they call this the ”time to first Tweet”).
Server side rendering mixes data and presentation by composing the page
on the server and is therefore against our approach for providing reusable
API. On the other hand, our proposed architecture does not support server
side rendering which, in some cases, could provide performance optimizations
into page loading. We leave it as a future work to investigate how this
shortcoming could be remedied without sacrificing the reusability of the API
and without compromising the separation of concerns of this architecture.
Chapter 7

Bibliography

[1] Allan J Albrecht. Measuring application development productivity. In

Proceedings of the Joint SHARE/GUIDE/IBM Application Develop-
ment Symposium, volume 10, pages 83–92. SHARE Inc. and GUIDE
International Corp. Monterey, CA, 1979.

[2] Gustavo Alonso, Fabio Casati, Harumi Kuno, and Vijay Machiraju.
Web Services: Concepts, Architectures and Applications. Springer Pub-
lishing Company, Incorporated, 1st edition, 2010.

[3] Angularjs. http://angularjs.org, 2013. [Online; accessed 11-

Dec-2013].

[4] Asp.net mvc. http://www.asp.net/mvc/, 2011. [Online; accessed

11-Jun-2013].

[5] David L. Atkins, Thomas Ball, Glenn Bruns, and Kenneth Cox. Mawl:
A domain-specific language for form-based services. IEEE Trans.
Softw. Eng., 25(3):334–346, May 1999.

[6] Luciano Baresi, Franca Garzotto, and Paolo Paolini. From web sites to
web applications: New issues for conceptual modeling. In StephenW.
Liddle, HeinrichC. Mayr, and Bernhard Thalheim, editors, Conceptual
Modeling for E-Business and the Web, volume 1921 of Lecture Notes
in Computer Science, pages 89–100. Springer Berlin Heidelberg, 2000.

[7] Victor R Basili. Software development: A paradigm for the future.

In Computer Software and Applications Conference, 1989. COMP-
SAC 89., Proceedings of the 13th Annual International, pages 471–485.
IEEE, 1989.

65
66 CHAPTER 7. BIBLIOGRAPHY

[8] Kent Beck. Test Driven Development: By Example. Addison-Wesley

Professional, 1 edition, 11 2002.

[9] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext Transfer Pro-

tocol – HTTP/1.0. RFC 1945, May 1996.

[10] Alex Berson. Client/Server Architecture (McGraw-Hill Computer

Communications Series). Mcgraw-Hill (Tx), 2nd edition, March 1996.

[11] Daniel Billsus, Clifford A. Brunk, Craig Evans, Brian Gladish, and
Michael Pazzani. Adaptive interfaces for ubiquitous web access, volume
45 Issue 5, pages 34–38. ACM, New York, NY, USA, May 2002.

[12] Andrew D. Birrell and Bruce Jay Nelson. Implementing remote proce-
dure calls. ACM Trans. Comput. Syst., 2(1):39–59, February 1984.

[13] Jasmin Blanchette and Mark Summerfield. C++ GUI Programming

with Qt 4 (2nd Edition) (Prentice Hall Open Source Software Develop-
ment Series). Prentice Hall, 2 edition, February 2008.

[14] Grady Booch. Object-oriented development, volume 12, pages 211–221.

IEEE Trans. Soft. Eng., February 1986.

[15] Pearl Brereton, David Budgen, and Geoff Hamilton. Hypertext: the
next maintenance mountain. In Computer, volume 31, pages 49–55.
IEEE Computer Society Press, Los Alamitos, CA, USA, December
1998.

[16] Chris Britton and Peter Bye. IT Architectures and Middleware: Strate-
gies for Building Large, Integrated Systems (2nd Edition). Addison-
Wesley Professional, 2 edition, June 2004.

[17] Juan José Cadavid, Juan Bernardo Quintero, David Esteban Lopez,
and Jesus Andrés Hincapié. A domain specific language to generate
web applications. In CIbSE, pages 139–144, 2009.

[18] Stuart K. Card, Allen Newell, and Thomas P. Moran. The Psychology
of Human-Computer Interaction. L. Erlbaum Associates Inc., Hillsdale,
NJ, USA, 1983.

[19] Richard Cardone, Danny Soroker, and Alpana Tiwari. Using xforms
to simplify web programming. In Proceedings of the 14th international
conference on World Wide Web, WWW ’05, pages 215–224, New York,
NY, USA, 2005. ACM.
 67

[20] Stefano Ceri, Piero Fraternali, and Aldo Bongio. Web modeling lan-
guage (webml): a modeling language for designing web sites. Computer
Networks, 33(1):137–157, 2000.
[21] CommonJS. Jsgi. http://wiki.commonjs.org/wiki/JSGI,
2011. [Online; accessed 11-Jun-2013].
[22] World Wide Web Consortium. Xhtml 1.0 the extensible hyper-
text markup language (second edition). http://www.w3.org/TR/
xhtml1/, August 2002. [Online; accessed 8-Jun-2013].
[23] World Wide Web Consortium. Document object model. http://
www.w3.org/DOM/, 2004. [Online; accessed 11-Jun-2013].
[24] World Wide Web Consortium. Web services architecture.
http://www.w3.org/TR/ws-arch/#relwwwrest, 2004. [Online; ac-
cessed 18-Jun-2013].
[25] World Wide Web Consortium. XML schema part 0:
Primer second edition. http://www.w3.org/TR/2004/
REC-xmlschema-0-20041028, October 2004. [Online; accessed
11-Jun-2013].
[26] World Wide Web Consortium. Soap version 1.2 part 1: Mes-
saging framework (second edition). http://www.w3.org/TR/
soap12-part1/, April 2007. [Online; accessed 11-Jun-2013].
[27] World Wide Web Consortium. Web services description language
(WSDL) version 2.0 part 1: Core language. http://www.w3.org/
TR/2007/REC-wsdl20-20070626/, June 2007.
[28] World Wide Web Consortium. Extensible markup language
(XML) 1.0 (fifth edition). http://www.w3.org/TR/2008/
REC-xml-20081126, November 2008. [Online; accessed 3-Jun-2013].
[29] World Wide Web Consortium. Xforms 1.1. http://www.w3.org/
TR/xforms/, October 2009. [Online; accessed 11-Jun-2013].
[30] World Wide Web Consortium. Xquery 1.0: An xml query language
(second edition). http://www.w3.org/TR/xquery/, December
2010. [Online; accessed 11-Jun-2013].
[31] World Wide Web Consortium. Html5. http://www.w3.org/TR/
html5/single-page.html, March 2012. [Online; accessed 3-Jun-
2013].
68 CHAPTER 7. BIBLIOGRAPHY

[32] World Wide Web Consortium. Web workers. http://www.w3.org/

TR/workers/, May 2012. [Online; accessed 3-Jun-2013].

[33] World Wide Web Consortium. Microdata. http://www.w3.org/

html/wg/drafts/microdata/master/, May 2013. [Online; ac-
cessed 13-Jun-2013].

[34] World Wide Web Consortium. Scalable vector graphics. http:

//www.w3.org/Graphics/SVG/, 2013. [Online; accessed 3-Jun-
2013].

[35] World Wide Web Consortium. Web storage. http://www.w3.org/

TR/webstorage/, 2013. [Online; accessed 3-Jun-2013].

[36] Fernando J. Corbató. On building systems that will fail. Commun.

ACM, 34(9):72–81, September 1991.

[37] Thomas A. Corbi. Program understanding: Challenge for the 1990s.

IBM Systems Journal, 28(2):294–306, 1989.

[38] D. Crockford. The application/json Media Type for JavaScript Object

Notation (JSON). RFC 4637, 2006.

[39] E. W. Dijkstra. On the role of scientific thought. In Selected Writings

on Computing: A Personal Perspective, pages 60–66. Springer-Verlag,
1974.

[40] Django. http://www.djangoproject.com/, 2013. [Online; ac-

cessed 11-Jun-2013].

[41] Dominic Duggan. Resource-oriented architecture. Enterprise Software

Architecture and Design: Entities, Services, and Resources, pages 359–
415, 2012.

[42] Joshua Duhl. Rich internet applications. A white paper sponsored by

Macromedia and Intel, IDC Report, 3906, 2003.

[43] Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubrama-

nian, Herbjörn Wilhelmsen, and David Booth. SOA with REST: Prin-
ciples, Patterns & Constraints for Building Enterprise Solutions with
REST (The Prentice Hall Service Technology Series from Thomas Erl).
Prentice Hall, 1 edition, 8 2012.
 69

[44] Eric Evans. Domain-Driven Design: Tackling Complexity In the Heart

of Software. Addison-Wesley Longman Publishing Co., Inc., Boston,
MA, USA, 2003.

[45] I. Fette and A. Melnikov. The WebSocket Protocol. RFC 6455, 2011.

[46] Roy T. Fielding. Rest apis must be hypertext-

driven. http://roy.gbiv.com/untangled/2008/
rest-apis-must-be-hypertext-driven, October 2008.
[Online; accessed 23-Jun-2013].

[47] Roy Thomas Fielding. Architectural Styles and the Design of Network-
based Software Architectures. PhD thesis, University of California,
Irvine, 2000.

[48] David Flanagan. JavaScript: The Definitive Guide: Activate Your Web
Pages (Definitive Guides). O’Reilly Media, 6th edition, May 2011.

[49] Martin Fowler. Patterns of Enterprise Application Architecture.

Addison-Wesley Professional, 1 edition, November 2002.

[50] Nicolas Frankel. Learning Vaadin. Packt Publishing, October 2011.

[51] Piero Fraternali, Gustavo Rossi, and Fernando Sánchez-Figueroa. Rich

internet applications. Internet Computing, IEEE, 14(3):9–12, 2010.

[52] Adam Freeman. Pro ASP.NET MVC 4. Apress, 4 edition, 1 2013.

[53] Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra, and Elis-
abeth Robson. Head First Design Patterns. O’Reilly Media, 1 edition,
November 2004.

[54] Steve Fulton and Jeff Fulton. HTML5 Canvas. O’Reilly Media, second
edition edition, April 2013.

[55] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. De-
sign patterns: elements of reusable object-oriented software. Addison-
Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995.

[56] Paul Graham. Web 2.0. http://www.paulgraham.com/web20.

html, 2006. [Online; accessed 11-Jun-2013].

[57] Stephen Greig. CSS3 Pushing the Limits. Wiley, 1 edition, 7 2013.
70 CHAPTER 7. BIBLIOGRAPHY

[58] Danny Groenewegen, Zef Hemel, and Eelco Visser. Separation of con-
cerns and linguistic integration in webdsl. IEEE Softw., 27(5):31–37,
September 2010.

[59] Gtk+. http://www.gtk.org, 2013. [Online; accessed 11-Jun-2013].

[60] Björn Hartmann, Scott Doorley, and Scott R. Klemmer. Hacking,

mashing, gluing: Understanding opportunistic design. IEEE Perva-
sive Computing, 7(3):46–54, July 2008.

[61] Zef Hemel, Danny M. Groenewegen, Lennart C. L. Kats, and Eelco

Visser. Static consistency checking of web applications with webdsl. J.
Symb. Comput., 46(2):150–182, February 2011.

[62] Clarence Ho and Rob Harrop. Pro Spring 3. Apress, 1 edition, 4 2012.

[63] Adrian Holovaty and Jacob Kaplan-Moss. The Definitive Guide to

Django: Web Development Done Right (Expert’s Voice in Web Devel-
opment). Apress, 2 edition, July 2009.

[64] Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay.
Back to the future: the story of squeak, a practical smalltalk written
in itself. SIGPLAN Not., 32(10):318–326, October 1997.

[65] Daniel Ingalls, Krzysztof Palacz, Stephen Uhler, Antero Taivalsaari,

and Tommi Mikkonen. The lively kernel a self-supporting system on a
web page. In Robert Hirschfeld and Kim Rose, editors, Self-Sustaining
Systems, volume 5146 of Lecture Notes in Computer Science, pages
31–50. Springer Berlin Heidelberg, 2008.

[66] Ian Jacobs. Uris, addressability, and the use of http get and
post. http://www.w3.org/2001/tag/doc/whenToUseGet.
html, 2004. [Online; accessed 11-Jun-2013].

[67] Pertti Järvinen. Research questions guiding selection of an appropriate

research method. In Proceedings of the 8th European Conference on
Information Systems, pages 124–131, Vienna, 3-5 July 2000. ECIS.

[68] Mehdi Jazayeri. Some trends in web application development. In 2007

Future of Software Engineering, FOSE ’07, pages 199–213, Washington,
DC, USA, 2007. IEEE Computer Society.

[69] Eric Jendrock, Ricardo Cervera-Navarro, Ian Evans, Devika Gollapudi,

Kim Haase, William Markito, and Chinmayee Srivathsa. The Java EE
 71

6 Tutorial: Advanced Topics (4th Edition) (Java Series). Addison-

Wesley Professional, 4 edition, January 2013.

[70] T. C. Jones. Measuring programming quality and productivity. IBM

Systems Journal, 17(1):39–63, 1978.

[71] Frederick P. Brooks Jr. The Mythical Man-Month: Essays on Software

Engineering. Addison-Wesley Longman Publishing Co., Inc., Boston,
MA, USA, 1st edition, 1978.

[72] J. Klensin. Simple Mail Transfer Protocol. RFC 2821, 2001.

[73] Adrian Kosmaczewski. Sencha Touch 2 Up and Running. O’Reilly

Media, 2 2013.

[74] Pawel Kozlowski and Peter Bacon Darwin. Mastering Web Application
Development with AngularJS. Packt Publishing, 8 2013.

[75] Glenn Krasner and Stephen Pope. A cookbook for using the model-view
controller user interface paradigm in smalltalk-80. J. Object Oriented
Program., 1(3):26–49, 1988.

[76] Andrew Krause. Foundations of GTK+ Development (Expert’s Voice

in Open Source). Apress, 1 edition, April 2007.

[77] David A Ladd and J Christopher Ramming. Programming the web:

An application-oriented language for hypermedia service programming.
In Fourth International World Wide Web Conference, Boston, Mas-
sachusetts, 1995.

[78] Markku Laine, Denis Shestakov, and Petri Vuorimaa. Xformsdb: an

extensible web application framework built upon declarative w3c stan-
dards. SIGAPP Appl. Comput. Rev., 12(3):37–50, September 2012.

[79] Markus Lanthaler and Christian Gütl. Model your application domain,
not your json structures. In Proceedings of the 22Nd International
Conference on World Wide Web Companion, WWW ’13 Companion,
pages 1415–1420, Republic and Canton of Geneva, Switzerland, 2013.
International World Wide Web Conferences Steering Committee.

[80] Simon St. Laurent, Edd Dumbill, and Eric J. Gruber. Learning Rails
3. O’Reilly Media, 1 edition, 7 2012.
72 CHAPTER 7. BIBLIOGRAPHY

[81] Tim Lindholm, Frank Yellin, Gilad Bracha, and Alex Buckley. The
Java Virtual Machine Specification, Java SE 7 Edition (Java Series).
Addison-Wesley Professional, 1 edition, February 2013.

[82] Xuanzhe Liu, Yi Hui, Wei Sun, and Haiqi Liang. Towards service
composition based on mashup. In IEEE Congress on Services, 2007.

[83] Giuseppe Antonio Di Lucca, Anna Rita Fasolino, Porfirio Tramontana,

and Corrado Aaron Visaggio. Towards the definition of a maintainabil-
ity model for web applications. In Proceedings of the Eighth European
Conference on Software Maintenance and Reengineering. IEEE, 2004.

[84] Roberto Lucchi, Michel Millot, and Christian Elfers. Resource oriented
architecture and rest. Office for Official Publications of the European
Communities, 2008.

[85] Matthew MacDonald. Pro WPF 4.5 in C#: Windows Presentation

Foundation in .NET 4.5. Apress, 4 edition, November 2012.

[86] Bruce J. MacLennan. Principles of Programming Languages: Design,

Evaluation, and Implementation, 3rd edition. Oxford University Press,
1999.

[87] John Maloney. Morphic: The self user interface framework. 1995.

[88] Jessica McKellar and Abe Fettig. Twisted Network Programming Es-
sentials. O’Reilly Media, second edition edition, 3 2013.

[89] Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how
to develop domain-specific languages. ACM Comput. Surv., 37(4):316–
344, December 2005.

[90] Eric A. Meyer. CSS: The Definitive Guide. O’Reilly Media, third
edition edition, November 2006.

[91] Windows presentation foundation. http://msdn.microsoft.

com/en-us//library/ms754130.aspx, 2013. [Online; accessed
11-Jun-2013].

[92] Tommi Mikkonen and Antero Taivalsaari. Web applications - spaghetti

code for the 21st century. Software Engineering Research, Management
and Applications, ACIS International Conference on, 0:319–328, 2008.
 73

[93] Tommi Mikkonen and Antero Taivalsaari. Creating a mobile web ap-
plication platform: the lively kernel experiences. In Proceedings of the
2009 ACM symposium on Applied Computing, SAC ’09, pages 177–184,
New York, NY, USA, 2009. ACM.

[94] Jakob Nielsen. Deep linking is good linking. http://www.nngroup.

com/articles/deep-linking-is-good-linking/, 2002.
[Online; accessed 11-Dec-2013].

[95] Node.js. http://nodejs.org, 2013. [Online; accessed 11-Jun-

2013].

[96] Information Sciences Institute University of Southern California.

Transmission Control Protocol. RFC 2821, 1981.

[97] Tim O’Reilly. What Is Web 2.0: Design Patterns and Business Models
for the Next Generation of Software, pages 17–37. Number 65. O’Reilly
Media, 2007.

[98] UDDI Spec Technical Committee Draft Organization for the Ad-
vancement of Structured Information Standards. UDDI version 3.0.2.
http://uddi.org/pubs/uddi-v3.0.2-20041019.htm, Octo-
ber 2004. [Online; accessed 11-Jun-2013].

[99] Hagen Overdick. The resource-oriented architecture. In Services, 2007

IEEE Congress on, pages 340–347. IEEE, 2007.

[100] Girish Parikh and Nicholas Zvegintzov. Tutorial on software mainte-

nance. IEEE Computer Society, 1983.

[101] D. L. Parnas. On the criteria to be used in decomposing systems into

modules. Commun. ACM, 15(12):1053–1058, December 1972.

[102] D. L. Parnas, P. C. Clements, and D. M. Weiss. Software reusabil-

ity: vol. 1, concepts and models. chapter Enhancing reusability with
information hiding, pages 141–157. ACM, New York, NY, USA, 1989.

[103] J. Pasley. How bpel and soa are changing web services development.
Internet Computing, IEEE, 9(3):60 – 67, may-june 2005.

[104] Cesare Pautasso, Olaf Zimmermann, and Frank Leymann. Restful web
services vs. ”big”’ web services: making the right architectural deci-
sion. In WWW ’08: Proceeding of the 17th international conference on
World Wide Web, pages 805–814, New York, NY, USA, 2008. ACM.
74 CHAPTER 7. BIBLIOGRAPHY

[105] Phonegap. http://phonegap.com, 2013. [Online; accessed 11-Dec-

2013].

[106] Shelley Powers. Learning Node. O’Reilly Media, 1 edition, 10 2012.

[107] Juan Carlos Preciado, Marino Linaje, Fernando Sanchez, and Sara
Comai. Necessity of methodologies to model rich internet applications.
In Web Site Evolution, 2005.(WSE 2005). Seventh IEEE International
Symposium on, pages 7–13. IEEE, 2005.

[108] Qt project. http://qt-project.org, 2013. [Online; accessed 11-

Jun-2013].

[109] Ruby on rails. http://rubyonrails.org/, 2013. [Online; ac-

cessed 11-Jun-2013].

[110] Mark Richards, Richard Monson-Haefel, and David A Chappell. Java

Message Service. O’Reilly Media, second edition edition, 6 2009.

[111] Mark Richards, Richard Monson-Haefel, and David A. Chappell. Java

Message Service, 2nd Edition. O’Reilly Media, 2009.

[112] Leonard Richardson and Sam Ruby. RESTful Web Services. O’Reilly,
2007.

[113] Johannes Sametinger. Software Engineering with Reusable Compo-

nents. Springer, softcover reprint of hardcover 1st ed. 1997 edition,
December 2010.

[114] Seam framework. http://www.seamframework.org, 2013. [On-

line; accessed 11-Jun-2013].

[115] Sencha touch. http://www.sencha.com/products/touch/,

2013. [Online; accessed 11-Dec-2013].

[116] Alok Sinha. Client-server computing, volume 37, pages 77–98. ACM,
New York, NY, USA, July 1992.

[117] Connie U. Smith and Lloyd G. Williams. Building responsive and

scalable web applications. In Proceedings of Computer Measurement
Group Conference. Software Engineering Research and L & S Computer
Technology, Inc., 2000.

[118] Joel Spolsky and Bruce Eckel. The Best Software Writing I: Selected
and Introduced by Joel Spolsky. Apress, 1 edition, June 2005.
 75

[119] The spring framework. http://www.springsource.org/, 2011.

[Online; accessed 11-Jun-2013].

[120] Simon St. Laurent, Joe Johnston, Edd Dumbill, and Dave Winer. Pro-
gramming Web Services with XML-RPC. O’Reilly Media, 2001.

[121] G.I. Susman and R.D. Evered. An assessment of the scientific merits
of action research, volume 23, pages 582–603. 1978.

[122] A. Taivalsaari and T. Mikkonen. The web as an application platform:

The saga continues. In Software Engineering and Advanced Applica-
tions (SEAA), 2011 37th EUROMICRO Conference on, pages 170–174,
2011.

[123] Antero Taivalsaari, Tommi Mikkonen, Dan Ingalls, and Krzysztof

Palacz. Web browser as an application platform: the lively kernel
experience. Technical report, Sun Microsystems, Inc., Mountain View,
CA, USA, 2008.

[124] Antero Taivalsaari and Kari Systä. Cloudberry: an html5 cloud phone
platform for mobile devices. Software, IEEE, 29(4):40–45, 2012.

[125] R. Thurlow. RPC: Remote Procedure Call Protocol Specification Ver-

sion 2. RFC 5531, May 2009.

[126] Twisted. http://twistedmatrix.com, 2013. [Online; accessed

11-Jun-2013].

[127] Twitter. Improving performance on twitter.com. https://blog.

twitter.com/2012/improving-performance-twittercom,
2012. [Online; accessed 01-Jan-2014].

[128] David Ungar and Randall B. Smith. Self: The power of simplicity. In
Conference proceedings on Object-oriented programming systems, lan-
guages and applications, OOPSLA ’87, pages 227–242, New York, NY,
USA, 1987. ACM.

[129] Daniel Vaughan. Ext GWT 2.0: Beginner’s Guide. Packt Publishing,
November 2010.

[130] Eelco Visser. Generative and transformational techniques in software

engineering ii. chapter WebDSL: A Case Study in Domain-Specific Lan-
guage Engineering, pages 291–373. Springer-Verlag, Berlin, Heidelberg,
2008.
76 CHAPTER 7. BIBLIOGRAPHY

[131] John M. Wargo. PhoneGap Essentials: Building Cross-Platform Mobile

Apps. Addison-Wesley Professional, 1 edition, 6 2012.

[132] Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony

Storey, and Donald F. Ferguson. Web Services Platform Architecture:
SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable
Messaging and More. Prentice Hall PTR, Upper Saddle River, NJ,
USA, 2005.

[133] Web Hypertext Application Technology Working Group (WHATWG).

Html. http://www.whatwg.org/specs/web-apps/
current-work/, May 2013. [Online; accessed 3-Jun-2013].

[134] J.E. White. High-level framework for network-based resource sharing.

RFC 707, December 1975.

[135] Wikipedia. Convention over configuration. http://en.

wikipedia.org/w/index.php?title=Convention_over_
configuration&oldid=547050979, 2013. [Online; accessed
29-April-2013].

[136] Wikipedia. Middleware. http://en.wikipedia.org/wiki/

Middleware, 2013. [Online; accessed 15-May-2013].

[137] Erik Wilde and Cesare Pautasso, editors. REST: From Research to
Practice. Springer, 2011 edition, 8 2011.

[138] Fan Yang, Nitin Gupta, Nicholas Gerner, Xin Qi, Alan Demers, Jo-
hannes Gehrke, and Jayavel Shanmugasundaram. A unified platform
for data driven web applications with automatic client-server partition-
ing. In Proceedings of the 16th international conference on World Wide
Web, WWW ’07, pages 341–350, New York, NY, USA, 2007. ACM.

[139] Fan Yang, Jayavel Shanmugasundaram, Mirek Riedewald, and Jo-

hannes Gehrke. Hilda: A high-level language for data-driven web appli-
cations. In Proceedings of the 22nd International Conference on Data
Engineering, ICDE ’06, pages 32–, Washington, DC, USA, 2006. IEEE
Computer Society.

[140] Michael Juntao Yuan, Jacob Orshalick, and Thomas Heute. Seam
Framework: Experience the Evolution of Java EE (2nd Edition). Pren-
tice Hall, 2 edition, February 2009.
 77

[141] Michal Zalewski. The Tangled Web, A Guide to Securing Modern Web
Applications, pages 46–47. No Starch Press, November 2011.

[142] Kris Zyp. Jsgi vs connect for node middleware.

http://www.sitepen.com/blog/2010/06/11/jsgi-vs-connect-for-node-
middleware/, June 2011. [Online; accessed 10-Jun-2013].