Nothing Special   »   [go: up one dir, main page]

An Architectural Style For Ajax

Download as pdf or txt
Download as pdf or txt
You are on page 1of 14

Delft University of Technology

Software Engineering Research Group


Technical Report Series

An Architectural Style for Ajax


Ali Mesbah and Arie van Deursen

Report TUD-SERG-2006-016 2nd revision

SERG
TUD-SERG-2006-016 2nd revision

Published, produced and distributed by:


Software Engineering Research Group
Department of Software Technology
Faculty of Electrical Engineering, Mathematics and Computer Science
Delft University of Technology
Mekelweg 4
2628 CD Delft
The Netherlands

ISSN 1872-5392

Software Engineering Research Group Technical Reports:


http://www.se.ewi.tudelft.nl/techreports/

For more information about the Software Engineering Research Group:


http://www.se.ewi.tudelft.nl/

c copyright 2006, Software Engineering Research Group, Department of Software Technology, Faculty
of Electrical Engineering, Mathematics and Computer Science, Delft University of Technology. All rights
reserved. No part of this series may be reproduced in any form or by any means without prior written
permission of the publisher.
SERG Mesbah & van Deursen – An Architectural Style for Ajax

An Architectural Style for Ajax


Ali Mesbah Arie van Deursen
Software Evolution Research Laboratory Software Engineering Group
Delft University of Technology Delft Univ. of Technology and CWI
Mekelweg 4, 2628 CD Delft, The Netherlands Mekelweg 4, 2628 CD Delft, The Netherlands
A.Mesbah@tudelft.nl Arie.vanDeursen@tudelft.nl

Abstract have attracted a strong interest in the web application de-


A new breed of web application, dubbed A JAX, is emerging velopment community. After the name A JAX was coined
in response to a limited degree of interactivity in large-grain in February 2005 [14], numerous frameworks1 and libraries
stateless Web interactions. At the heart of this new approach have appeared, many web applications have adopted one or
lies a single page interaction model that facilitates rich in- more of the ideas underpinning A JAX, and an overwhelming
teractivity. We have studied and experimented with several number of articles in developer sites and professional mag-
A JAX frameworks trying to understand their architectural azines have appeared. Adopting A JAX-based techniques is
properties. In this paper, we summarize three of these frame- a serious option not only for newly developed applications,
works and examine their properties and introduce the S PIAR but also for existing web sites if their user friendliness is in-
architectural style. We describe the guiding software engi- adequate.
neering principles and the constraints chosen to induce the A software engineer considering adopting A JAX, how-
desired properties. The style emphasizes user interface com- ever, is faced with a number of challenges. What are the
ponent development, and intermediary delta-communication fundamental architectural differences between designing a
between client/server components, to improve user interac- legacy web application and an A JAX web application? What
tivity and ease of development. In addition, we use the con- are the different characteristics of A JAX frameworks? What
cepts and principles to discuss various open issues in A JAX do these frameworks hide? Is there enough support for de-
frameworks and application development. signing such applications? What problems can one expect
during the development phase? Will there be some sort
1. Introduction of convergence between the many different technologies?
Which architectural elements will remain, and which ones
Over the course of the past decade, the move from desktop will be replaced by more elegant solutions?
applications towards web applications has gained much at- Addressing these questions calls for a more abstract per-
tention and acceptance. Within this movement, however, a spective on A JAX web applications. Despite all the attention
great deal of user interactiveness has been lost. Classical web the technology is receiving in the web community, there is a
applications are based on a multi page interface model, in lack of a coherent and precisely described set of architectural
which interactions are based on a page-sequence paradigm. formalisms for A JAX enabled web applications. In this paper
While simple and elegant in design for exchanging docu- we explore whether concepts and principles as developed in
ments, this model has many limitations for developing mod- the software architecture research community can be of help
ern web applications with user friendly human-computer in- to answer such questions. In particular, we propose S PIAR,
teraction. an architectural style for A JAX applications, and study to
Recently, there has been a shift in the direction of web de- what extent this style can help in addressing our questions.
velopment. A new breed of web application, dubbed A JAX This paper is organized as follows. We start out, in
(Asynchronous JavaScript And XML) [14], is emerging in Section 2 by exploring A JAX, studying three frameworks
response to the limited degree of interactivity in large-grain (Google’s GWT, Backbase, and the open source Echo2) that
stateless Web interactions. At the heart of this new approach have made substantially different design choices. Then, in
lies a single page interface model that facilitates rich inter- Section 3, we survey existing architectural styles (such as
activity. In this model, changes are made to individual user the Representational State Transfer architectural style R EST
interface components contained in a web page, as opposed on which the World Wide Web is based [12]), and analyze
to refreshing the entire page. 1 At the time of writing more than 150 frameworks are listed at http:
Thanks to the momentum of A JAX, single page interfaces //ajaxpatterns.org/Frameworks.

TUD-SERG-2006-016 2nd revision 1 1


Mesbah & van Deursen – An Architectural Style for Ajax SERG

their suitability for characterizing A JAX. Next, in Section 4, We have studied and experimented with several A JAX
we propose S PIAR, describing the architectural properties, frameworks trying to understand their architectural proper-
elements, and constraints of this style. Given S PIAR, in Sec- ties. We summarize three of these frameworks in this section.
tion 5 we use its concepts and principles to discuss various Our selection includes a widely used open source framework
open issues in A JAX frameworks and application develop- called Echo2, the web framework offered by Google called
ment. We conclude with a summary of related work, contri- GWT, and the commercial package delivered by Backbase.
butions, and an outlook to future work. All three frameworks are major players in the A JAX market,
and their underlying technologies differ substantially.
2. Ajax Frameworks Echo2
Echo23 is an open-source A JAX framework which allows
2.1. Ajax the developer to create web applications using an object-
oriented, UI component-based, and event-driven paradigm
A JAX [14] is the name given to a set of modern web appli-
for Web development. Its Java Application Framework pro-
cation development technologies, previously known as Dy-
vides the APIs (UI components, property objects, and even-
namic HTML (DHTML) and remote scripting, to provide a
t/listeners) to represent and manage the state of an applica-
more interactive web-based user interface.
tion and its user interface.
As defined by Garrett [14], A JAX incorporates: standards-
All functionality for rendering a component or communi-
based presentation using XHTML and CSS, dynamic display
cating with the client browser is specifically assembled in a
and interaction using the Document Object Model, data in-
separate module called the Web Rendering Engine. The en-
terchange and manipulation, asynchronous data retrieval us-
gine consists of a server-side portion (written in Java/J2EE)
ing XMLHttpRequest, and JavaScript binding everything to-
and a client-side portion (JavaScript). The client/server in-
gether. This definition, however, only focuses on the client
teraction protocol is hidden behind this module and as such,
side of the web application setting.
it is entirely decoupled from other modules. Echo2 has an
A JAX is an approach to web application development uti-
Update Manager which is responsible for tracking updates
lizing a combination of established web technologies. It
to the user interface component model, and for processing
is the combination of these technologies that makes A JAX
input received from the rendering agent and communicating
unique and powerful on the Web.
it to the components.
Even before the term A JAX was coined, its power was be-
The Echo2 Client Engine runs in the client browser and
coming evident by web applications such as Google Suggest
provides a remote user interface to the server-side applica-
and Google Map. Other well known examples are Flickr, tion. Its main activity is to synchronize client/server state
Gmail, and the new version of Yahoo Mail. For more techni-
when user operations occur on the interface.
cal details of A JAX see [1, 9].
A ClientMessage in XML format is used to transfer the
2.2. Frameworks client state changes to the server by explicitly stating the
nature of the change and the corresponding component ID
Web application developers have struggled constantly with the change has taken place on. The server processes the
the limits of the HTML page-sequence experience, and the ClientMessage, updating the component model to reflect the
complexities of client-side JavaScript programming to add user’s actions. Events are fired on interested listeners, possi-
some degree of dynamism to the user interface. Issues re- bly resulting in further changes to the server-side state of the
garding cross-browser compatibility are, for instance, known application. The server responds by rendering a ServerMes-
to everyone who has built a real-world web application. The sage which is again an XML message containing directives
rich user interface (UI) experience A JAX promises comes at to perform partial updates to the DOM representation on the
the price of facing all such problems. Developers are re- client.
quired to have advanced skills in a variety of Web technolo-
GWT
gies, if they are to build robust A JAX applications. Also,
much effort has to be spent on testing these applications be- Google has a novel approach to implementing its A JAX
framework, Google Web Framework (GWT)4 . Just like
fore going in production. This is where frameworks come to
Echo2, GWT facilitates the development of UIs in a fash-
the rescue. At least many of them claim to.
ion similar to AWT or Swing and comes with a library of
Because of the momentum A JAX has gained, a vast num-
widgets that can be used. The unique character of GWT
ber of frameworks are being developed. The importance of
lies in the way it renders the client-side UI. Instead of keep-
bringing order to this competitive chaotic world becomes ev-
ing the UI components on the server and communicating the
ident when we learn that ‘almost one new framework per
day’ is being added to the list of known frameworks2. 3
Echo2 2.0.0, www.nextapp.com/platform/echo2/echo/. Their on line demo
is worth looking at!
2 http://ajaxpatterns.org/wiki/index.php?title=AJAXFrameworks 4 http://code.google.com/webtoolkit/

2 TUD-SERG-2006-016 2nd revision


SERG Mesbah & van Deursen – An Architectural Style for Ajax

state changes, GWT compiles all the Java UI components 2.3. Features
to JavaScript code (compile-time). Within the components
While different in many ways, these frameworks share some
the developer is allowed to use a subset of Java 1.4 API to
common architectural characteristics. Generally, the goals of
implement needed functionality.
these frameworks can be summarized as follows:
GWT uses a small generic client engine and, using the
compiler, all the UI functionality becomes available to the • Hide the complexity of developing A JAX applications -
user on the client. This approach decreases round-trips to the which is a tedious, difficult, and error-prone task,
server drastically. The server is only consulted if raw data is
needed to populate the client-side UI components. This is • Hide the incompatibilities between different web
carried out by making server calls to defined services. The browsers and platforms,
services (which are not the same as Web Services) are imple- • Hide the client/server communication complexities,
mented in Java and data is passed both ways over the network • All this to achieve rich interactivity and portability for
using serialization techniques. end users, and ease of development for developers.
Backbase
Backbase5 is an Amsterdam-based company that provided The frameworks achieve these goals by providing a li-
one of the first commercial A JAX frameworks. The frame- brary of user interface components and a development en-
work is still in continuous development, and in use by nu- vironment to create reusable custom components. The archi-
merous customers world wide. tectures have a well defined protocol for small interactions
A key element of the Backbase framework is the Back- among known client/server components. Data needed to be
base Presentation Client. This a standards-based engine writ- transferred over the network is significantly reduced. This
ten in Javascript that runs in the web browser. It can be can result in faster response data transfers. Their architec-
programmed via a declarative user interface language called ture takes advantage of client side processing resulting in
BXML. BXML offers library of UI controls, a mechanism improved user interactivity, smaller number of round-trips,
for attaching actions to them, as well as facilities for con- and a reduced web server load.
necting to the server asynchronously.
The server side of the Backbase framework is formed 3. Architectural Styles
by BJS, the Backbase Java Server. It is built on top of
JavaServer Faces (J SF)6 , the new J2EE presentation architec- 3.1. Terminology
ture. J SF provides a user interface component-based frame-
work following the model-view-controller pattern. The in- In this paper we use the software architectural concepts and
teraction in J SF is, however, based on the classical page se- terminology as used by Fielding [11] which in turn is based
quence model, making integration in a single page frame- on the work of Perry and Wolf [23]. Thus, a software ar-
work non trivial. chitecture is defined [23] as a configuration of architectural
Backbase Java Server provides its own set of UI compo- elements — processing, connectors, and data — constrained
nents and extends the J SF framework to provide a single page in their relationships in order to achieve a desired set of ar-
interface implementation. Any Java class that offers getters chitectural properties.
and setters for its properties can be directly assigned to a An architectural style, in turn, [11] is a coordinated set
UI component property. Developers can use the components of architectural constraints that restricts the roles of archi-
declaratively (web-scripting) to build an A JAX application. tectural elements and the allowed relationships among those
The framework renders each declared server-side UI com- elements within any architecture that conforms to that style.
ponent to a corresponding client-side (BXML) UI compo- An architectural style constrains both the design elements
nent, and keeps track of changes on both component trees and the relationships among them [23] in such a way as to
for synchronization. result in software systems with certain desired properties.
The state changes on the client are sent to the server on An architectural system can be composed of multiple
certain defined events. These can be action events like click- styles and a style can be hybrids of other styles. Styles can be
ing a button, or value change events such as checking a radio seen as reusable [20] common architectural patterns within
button. The server translates these state changes and identi- different system architectures and hence the term architec-
fies the corresponding component(s) in the server component tural pattern is also used to describe the same concept [3].
tree. After the required action, the server renders the changes
3.2. Existing Styles
to be responded to the engine again in BXML format.
5 www.backbase.com User interface applications generally make use of popular
6 JavaServer Faces Specification v1.1, http://java.sun.com/j2ee/javaserverfaces/ styles such as Module/View/Controler [17] to describe large
scale architecture and, in more specific cases, styles like C2

TUD-SERG-2006-016 2nd revision 3


Mesbah & van Deursen – An Architectural Style for Ajax SERG

[27] to rely on asynchronous notification of state changes and response pair in R EST. A JAX applications, however,
request messages between independent components. require a model for asynchronous communication.
Many different network-based architectural styles [11], • R EST explicitly constrains the server to be stateless, i.e.,
such as client/server [24], n-tier [29], and Code on Demand, each request from the client must contain all the infor-
exist but in our view the most complete and appropriate style mation necessary for the server to understand the re-
for the Web, thus far, is the REpresentational State Transfer quest. While this constraint can improve scalability, the
(R EST) [12]. tradeoffs with respect to network performance and user
R EST emphasizes the abstraction of data and services interactivity are of greater importance when designing
as resources that can be requested by clients using the re- an A JAX architecture.
source’s name and address, specified as a Uniform Resource
Locator (URL) [4]. The style inherits characteristics from a Because of these requirement mismatches, we do not see
number of other styles such as client/server, pipe-and-filter, how existing styles such as R EST or C2 can help to address
and distributed objects. some of the questions raised in the introduction. Therefore,
The style is a description of the main features of the Web we will propose a style specifically tailored towards A JAX
architecture through architectural constraints which have applications, and study if this style can be used for this pur-
contributed significantly to the success of the Web. pose instead.
It revolves around five fundamental notions: a resource
which can be anything that has identity, e.g., a document
or image, the representation of a resource which is in the
4. SPIAR Architectural Style
form of a media type, synchronous request-response inter- In this section, we first focus on the essential architectural
action over HTTP to obtain or modify representations, a web properties of A JAX frameworks. Then the common archi-
page as an instance of the application state, and engines (e.g., tectural elements are presented and finally the constraints
browser, crawler) to move from one state to the next. on those elements to achieve the properties are discussed.
R EST specifies a client-stateless-server architecture in Our S PIAR architectural style describes the essence of what
which a series of proxies, caches, and filters can be used and A JAX frameworks hide and prescribes constraints that such
each request is independent of the previous ones, inducing frameworks should adhere to. The style can be used when
the property of scalability. It also emphasizes on a uniform high user interaction and responsiveness is desired in web
interface between components constraining information to applications.
be transferred in a standardized form.
4.1. Architectural Properties
3.3. A Style for Ajax
Below we discuss a number of architectural properties that
A JAX applications can be seen as a hybrid of desktop relate to the essence of A JAX. Other properties, such as ex-
and web applications, inheriting characteristics from both tensibility or security, that may be desirable for any system
worlds. Can we reuse styles from these worlds? but are less directly affected by a decision to adopt A JAX,
User interface styles such as C2 are meant specifically for are not taken into account. Note that some of the properties
peer-to-peer environments and thus are not suitable for Web discussed below are related to each other: for instance, user
applications. interactivity is influenced by user-perceived latency, which
A JAX frameworks provide back-end services through UI in turn is affected by network performance.
components to the client in an event-driven style whereas
R EST provides resources. A JAX architectures are also not User Interactivity
so easily captured in R EST, due to the following differences: Human-computer interaction literature defines interactivity
as the degree to which participants in a communication pro-
• While R EST is suited for large-grain hypermedia data cess have control over, and can exchange roles in their mu-
transfers, because of its uniform interface constraint it is tual discourse. User interactivity is closely related to usabil-
not optimal for small data interactions required in A JAX ity [13], the term used in software architecture literature. Teo
applications. et al. [28] provide a thorough study of user interactivity on
• R EST focuses on a hyper-linked resource-based inter- commercial web applications. Their results suggest that an
action in which the client requests a specific resource. increased level of interactivity has positive effects on user’s
In contrast, in A JAX applications the user interacts with perceived satisfaction, effectiveness, efficiency, value, and
the system much like in a desktop application, request- overall attitude towards a Web site. Improving this property
ing a response to a specific action. on the Web has been the main motivating force behind the
A JAX movement.
• All interactions for obtaining a resource’s represen-
tation are performed through a synchronous request-

4 TUD-SERG-2006-016 2nd revision


SERG Mesbah & van Deursen – An Architectural Style for Ajax

User-perceived Latency Processing Elements


User-perceived latency is defined as the period between the The processing elements are defined as those components
moment a user issues a request and the first indication of a that supply the transformation on the data elements.
response from the system. Generally, there are two primary The Client Browser offers support for a set of standards
ways to improve user-perceived performance. First, by re- such as HTTP, HTML, Cascading Style Sheets, JavaScript,
ducing the round-trip time and second, by allowing the user and Document Object Model. It processes the representa-
to interact asynchronously with the system. This is an impor- tional model of a web page to produce the user interface.
tant property in all distributed applications with a front-end The user interaction can be based on a single page user in-
to the user. terface model. All the visual transitions and effects are pre-
sented to the user through this interface. Just like a desktop
Network Performance
client application, it consists of a single main page with a
Network performance is influenced by throughput which is
set of identifiable widgets. The properties of widgets can be
the rate of data transmitted on the network and bandwidth,
manipulated individually while changes are made in-place
i.e., a measure of the maximum available throughput. Net-
without requiring a page refresh.
work performance can be improved by means of reducing
The A JAX Engine is a client engine that loads and runs in
the amount and the granularity of transmitted data.
the client browser. There is no need for a plug-in for the web
Simplicity application to function. However, downloading the engine
Simplicity or development effort is defined as the effort that does introduce an initial latency for the user which can be
is needed to understand, design, implement, and re-engineer compensated by the smaller data transfers once the engine is
a web application. It is an important factor for the usage and in place. The engine is responsible for the initialization and
acceptance of any new approach. manipulation of the representational model. It handles the
events initiated by the user, communicates with the server,
Scalability
and has the ability to perform client-side processing.
In distributed environments scalability is defined by the de-
The Server Application resides on the server and operates
gree of a systems ability to handle growing number of com-
by accepting HTTP-based requests from the network, and
ponents. In Web engineering, a system’s scalability is deter-
providing responses to the requester. All server-side func-
mined, for instance, by the degree in which a client can be
tionality resides in the server application processing element.
served by different servers without affecting the results. A
The Service Provider represents the logic engine of the
scalable Web architecture can be easily configured to serve a
server and processes state changes and user requested ac-
growing number of client requests.
tions. It is capable of accessing any resource (e.g., database,
Portability Web Services) needed to carry out its action. A Service
Software that can be used in different environments is said to Provider’s functionality is invoked by event listeners, at-
be portable. On the Web, being able to use the Web browser tached to components, initiated by incoming requests.
without the need for any extra actions required from the user, The Delta Encoder/Decoder processes outgoing/incom-
e.g., downloading plug-ins, induces the property of portabil- ing delta messages. It is at this point that the communication
ity. protocol between the client and the server is defined and hid-
den behind an interface. This element supports delta com-
Visibility
munication between client and server which improves user-
Visibility [11] is determined by the degree in which an exter-
perceived latency and network performance.
nal mediator is able to understand the interactions between
UI Components consist of a set of server-side UI compo-
two components. The easier it is for the mediator to un-
nents. The component model on the server is capable of ren-
derstand the interactions, the more visible is the interaction
dering the representational model on the client. Each server-
between those two components. Looking at the current im-
side component contains the data and behavior of that part
plementations of A JAX frameworks, visibility in the client/-
of the corresponding client-side widget which is relevant for
server interactions is poor, as they are based on proprietary
state changes; There are different approaches as when and
protocols.
how to render the client-side UI code. GWT, for instance,
4.2. Architectural Elements renders the entire client-side UI code compile-time from the
server-side Java components. Echo2, on the other hand, ren-
Following [11, 23] the key architectural elements of S PIAR ders the components at run-time and keeps a tree of compo-
are divided into three categories, namely processing, data, nents on both client and server side. These UI components
and connecting elements. An overview of the elements is have event listeners that can be attached to client-side user
depicted in Figure 1, which will be explained in Section 4.3. initiated events such as clicking on a button. This element
enhances simplicity by providing off-the-shelf components

TUD-SERG-2006-016 2nd revision 5


Mesbah & van Deursen – An Architectural Style for Ajax SERG

Client Browser HTTP Server App.


DOM Decoder UI Comp.
event Ajax C update
Engine
update S Encoder update
Engine

update invoke
event update

Service
UI Provider

Figure 1. Processing View of a S PIAR-based architecture.

to build web applications. type of the event, a request to the server, or a partial update
of the interface might be needed. The event can be handled
Data Elements
asynchronously, if desired, in which case the control is im-
The data elements contain the information that is used and
mediately returned to the user.
transformed by the processing elements.
On the server, the request initiated by an event invokes a
The Representation element consists of any media type
service. The service can be either invoked directly or through
just like in R EST. HTML, CSS, and images are all members
the corresponding UI component’s event listeners.
of this data element.
Delta connectors are light-weight communication media
The Representational Model is a run-time abstraction of
connecting the engine and the server using a request/re-
how a UI is represented on the client browser. The Document
sponse mechanism over HTTP.
Object Model inside the browser has gained a very important
Delta updates are used to update the representational
role in A JAX applications. It is through dynamically manipu-
model on the client and the component model on the server
lating this representational model that rich effects have been
to reflect the state changes. While a delta update of the rep-
made possible. Some frameworks such as Backbase use a
resentational model results in a direct apparent result on the
domain-specific language to declaratively define the struc-
user interface, an update of the component model invokes
ture and behaviour of the representational model. Others like
the appropriate listeners. These updates are usually through
GWT use a direct approach by utilizing JavaScript.
procedural invocations of methods.
Delta communicating messages form the means of the
delta communication protocol between client and server. 4.3. Processing View
S PIAR makes a distinction between the client delta data
(DELTA - CLIENT) and the server delta data (DELTA - SERVER). Given the processing, data, and connecting elements, we can
The former is created by the client to represent the client-side use different architectural views to describe how the ele-
state changes and the corresponding actions causing those ments work together to form an architecture. Here we use
changes, while the latter is the response of the server as a a processing view, which concentrates on the data flow and
result of those actions on the server components. The delta some aspects of the connections among the processing ele-
communicating data are found in a variety of formats in the ments with respect to the data [11]. This view is fits in the
current frameworks, e.g., XML, BXML, JavaScript Object Components and Connectors viewtype as discussed by [8].
Notation (JSON), JavaScript. The client delta messages con- Figure 1 depicts the processing view of an S PIAR-based
tain the needed information for the server to know for in- architecture based on run-time components rendering as in,
stance which action on which component has to be carried e.g., Echo2. The view shows the interaction of the differ-
out. GWT uses an RPC style of calling services while in ent components some time after the initial page request (the
Backbase and Echo2 a component-based approach is imple- engine is running on the client). User activity on the user in-
mented to invoke event listeners. terface fires off an event to indicate some kind of component-
defined action which is delegated to the A JAX engine. If a
Connecting Elements listener on a server-side component has registered itself with
The connecting elements serve as the glue that holds the the event, the engine will make a DELTA - CLIENT message
components together by enabling them to communicate. of the current state changes with the corresponding events
Events form the basis of the interaction model in S PIAR. and send it to the server. On the server, the decoder will con-
An event is initiated by each action of the user on the in- vert the message, and identify and notify the relevant compo-
terface, which propagates to the engine. Depending on the

6 TUD-SERG-2006-016 2nd revision


SERG Mesbah & van Deursen – An Architectural Style for Ajax

nents in the component tree. The changed components will


ultimately invoke the event listeners of the service provider. Table 1. Constraints and induced properties

User-perceived Latency
The service provider, after handling the actions, will update

Network Performance
the corresponding components with the new state which will

User Interactivity
be rendered by the encoder. The rendered DELTA - SERVER
message is then sent back to the engine which will be used

Scalability

Portability
Simplicity

Visibility
to update the representational model and eventually the in-
terface. The engine has also the ability to update the repre-
Asynchronous Interaction + +
sentational model directly after an event, if no round-trip to Delta Communication + + + – –
the server is required. Client-side processing + + +
UI Component-based + +
4.4. Architectural Constraints Web standards-based
Stateful + + +
+

+

Architectural constraints can be used as restrictions on the
roles of the architectural elements to induce the architectural the computational load since the server generates the entire
properties desired of a system. Table 1 presents an overview page for each request [21].
of the constraints and induced properties. A “+” marks a di- S PIAR goes one step further, and uses a delta-
rect positive effect, whereas a “–” indicates a direct negative communication style of interaction. Here merely the state
effect. changes are interchanged between the client and the server as
S PIAR rests upon the following constraints chosen to re- opposed to the full-page retrieval approach in classic web ap-
tain the properties identified previously in this section. plications. Delta-communication is based on delta-encoding
Interaction and Synchronicity architectural principles but is different: delta-communication
The client-server interaction can be realized in both a push- does not rely on caching and as a result, the client only needs
or pull-based style. In a push-based style [15], the server to process the deltas. All A JAX frameworks hide the delta-
broadcasts the state changes to the clients asynchronously communication details from the developers.
every time its state changes. Event-based Integration [2] This constraint induces the properties of network perfor-
and Asynchronous R EST [16] are event-based styles allow- mance directly and as a consequence user-perceived latency
ing asynchronous notification of state changes by the server. and user interactivity. Network performance is improved be-
This style of interaction is mainly supported in peer-to-peer cause there are less redundant data (merely the delta) being
architectural environments. transported.
In a pull-based style, client components actively request User Interface Component-based
state changes. Event-driven [22] architectures are found in S PIAR relies on a single page user interface with components
distributed applications that require asynchronous commu- similar to that of desktop applications, e.g., AWT’s UI com-
nication, for instance, a desktop application, where user ini- ponent model. This model defines the state and behavior of
tiated UI inputs serve as the events that activate a process. UI components and the way they can interact.
A JAX applications are designed to have a high user inter- UI component programming improves simplicity because
activity and a low user-perceived latency. Asynchronous in- developers can use reusable components to assemble a Web
teraction allows the user to, subsequently, initiate a request page either declaratively or programmatically. User inter-
to the server at any time, and receive the control back from activity is improved because the user can interact with the
the client instantly. The requests are handled by the client application on a component level, similar to desktop appli-
at the background and the interface is updated according to cations.
server responses. This model of interaction is substantially
Web standards-based
different from the classic synchronous request, wait for re-
Constraining the Web elements to a set of standardized for-
sponse, and continue model.
mats is one way of inducing portability on the Web. This
Delta-communication constraint excludes approaches that need extra functionality
Redundant data transfer which is mainly attributed to re- (e.g., plug-ins, virtual machine) to run on the Web browser,
transmissions of unchanged pages is one of the limitations of such as Flash and Java applets, and makes the client cross-
classic web applications. Many techniques such as caching, browser compatible. This constraint limits the nature of the
proxy servers and fragment-based resource change estima- data elements to those that are supported by web browsers.
tion and reduction [5], have been adopted in order to reduce
Client-side Processing
data redundancy. Delta-encoding [19] uses caching tech-
Client-side processing improves user interactivity and user-
niques to reduce network traffic, however, it does not reduce
perceived latency through round-trip reduction. For instance,
client-side form validation reduces unnecessary server-side

TUD-SERG-2006-016 2nd revision 7


Mesbah & van Deursen – An Architectural Style for Ajax SERG

error reports and reentry messages. Additionally, some be divided into two categories of Safe and Unsafe interac-
server-side processing (e.g., sorting items) can be off-loaded tions [30]. A safe interaction is one where the user is not
to clients using mobile code that will improve server per- to be held accountable for the result of the interaction, e.g.,
formance and increase the availability to more simultaneous simple queries. An unsafe interaction is one where a user
connections. As a tradeoff, client performance can become request has the potential to change the state of the resource.
an issue if many widgets need processing resources on the In single page Internet applications, where interaction be-
client. GWT takes advantage of client-side processing to the comes more and more desktop-like, where eventually Un-
fullest, by generating all the UI client-side code as JavaScript do/Redo replaces Back/Forward, the safe interactions remain
and run it on the client. using URIs while the unsafe ones can be safely carried out at
the background using delta-communication in which neither
Stateful
the data transmitted nor the data received in the response nec-
A stateless server is one which treats each request as an in-
essarily correspond to any resource identified by a URI. This
dependent transaction, unrelated to any previous request, i.e.,
implies the engine should also provide the means of linking
each request must contain all of the information necessary to
to safe operations as well as hyper-linked documents. The
understand it, and cannot take advantage of any stored con-
URI’s fragment identifier can be used for this purpose. In-
text on the server [12]. Even though the Web architecture and
terpretation of the fragment identifier is then performed by
HTTP are designed to be stateless, it is difficult to think of
the engine that dereferences a URI to identify and represent
stateless Web applications. Within a Web application, the or-
a state of the application.
der of interactions is relevant, making interactions depend on
each other, which requires an awareness of the overall com- Client- or server-side processing
ponent topology. The statefulness is imitated by a combi- Within the current frameworks it is not possible for develop-
nation of HTTP, client-side cookies, and server-side session ers to choose whether some certain functionality should be
management. processed on the client or on the server. How the computa-
Unlike R EST, S PIAR does not constrain the nature of the tion is distributed can be an important factor in tunning a web
state explicitly. Nevertheless, since a stateless approach may application. A JAX frameworks architectures should provide
decrease network performance (by increasing the repetitive the means for the developer to decide if and to what extend
data), and because of the component-based nature of the user computation should be done on the client.
interactions, a stateful solution might become favorable at Asynchronous Synchronization
the cost of scalability and visibility. The asynchronous interaction in A JAX applications may
cause race conditions if not implemented with care. The user
5. Discussion can send a request to the server before a previous one has
been responded. In a server processor that handles the re-
In this section we use S PIAR to discuss various decisions and quests in parallel, the second request can potentially be pro-
tradeoffs to be made when developing A JAX frameworks and cessed before the first one. This behavior could have dras-
applications. tic effects on the synchronization and state of the entire ap-
Resource-based versus Component-based plication. A possible solution would be handling the event-
The architecture of the World Wide Web [31] is based on triggered requests for each client sequentially at the cost of
resources identified by Uniform Resource Identifiers (URI), server performance.
and on the protocols that support the interaction between Communication Protocol
agents and resources. Using a generic interface and pro- As we have seen, currently each A JAX framework has im-
viding identification that is common across the Web for re- plemented its own specific communication protocol. This
sources has been one of the key success factors of the Web. makes the visibility of client/server interactions poor as one
The nature of Web architecture which deals with Web must know the exact protocol to be able to make sense of the
pages as resources causes redundant data transfers [5]. The delta messages. It also results in a low level of scalability for
delta-communication way of interaction in S PIAR is based these applications. For a client to be able to communicate
on the component level and does not comply with the Re- with an A JAX server, again it needs to know the protocol
source/URI constraint of the Web architecture. The question of that server application. These two properties can be im-
is whether this choice is justifiable. To be able to answer this proved by defining a standard protocol specification for the
question we need to take a look at the nature of interactions communication by and for the A JAX community.
within single page applications: safe versus unsafe interac-
Design Models
tions.
Figure 2 shows a meta-model of an A JAX web application.
Safe versus Unsafe Interactions The UI is composed of widgets of UI components. The client
Generally, client/server interactions in a Web application can single page is built by the server-side widgets. Delta changes

8 TUD-SERG-2006-016 2nd revision


SERG Mesbah & van Deursen – An Architectural Style for Ajax

Server app Client Browser


1
Web App UI Page
deltaChange
1..* 1..*
<<build>>
viewChange Widget View

deltaUpdate
1..*
<<UI Component>>

Figure 2. A single page web application composed of UI components.

as well as view changes occur on the widget level. A view the technology and remain ‘pretty agnostic’ to the server
change, can be seen as navigating through the available wid- side. Crane et al. [9] provide an in-depth presentation of
gets. A JAX frameworks should provide clear navigational A JAX web programming techniques and prescriptions for
models for developers. Research is needed to propose de- best practices with detailed discussions of relevant design
sign models for A JAX developers by for instance extend- patterns. They also mention improved user experience and
ing the UML language to model user interaction, navigation reduced network latency by introducing asynchronous inter-
through components, asynchronous/synchronous actions and actions as the main features of such applications. While these
client versus server side processing. books focus mainly on the implementation issues, our work
examines the architectural design decisions and properties
Fragment-based Approach
from an abstraction level by focusing on the interactions be-
The page-sequence model of the Web makes it difficult
tween the different client/server components.
to treat portions of Web pages (fragments), independently.
Pace [26] is an event- based architectural style for trust
Fragment-based research [5, 6, 7] aims at providing mecha-
management in decentralized applications. TIGRA [10] is a
nisms to efficiently assemble a Web page from different parts
distributed system style for integrating front-office systems
to be able to cache the fragments. Recently proposed ap-
with middle- and back-office applications. Aura [25], an ar-
proaches include several server-side and cache-side mecha-
chitectural framework for user mobility in ubiquitous envi-
nisms. Server-side techniques aim at reducing the load on the
ronments, uses models of user tasks as first class entities to
server by allowing reuse of previously generated content to
set up, monitor and adapt computing environments.
serve user requests. Cache-side techniques attempt to reduce
Khare and Taylor [16] evaluate and extend R EST for de-
the latency by moving some functionality to the edge of the
centralized settings and represent an event-based architec-
network. These fragment-based techniques can improve net-
tural style called ARRESTED. The asynchronous extension
work and server performance, and user-perceived latency by
of R EST, called A+REST, permits a server to broadcast no-
allowing only the modified or new fragments to be retrieved.
tifications of its state changes to ‘watchers’. This work is
Although the fragments can be retrieved independently,
highly related to the concepts of A JAX applications. Ap-
these techniques lack the user interface component in-
plying a real push-based interaction style to A JAX, however,
teractivity required in interactive applications. The UI
will probably take some time as the standard browsers and
component-based model of the S PIAR style in conjunction
servers do not support this form of communication yet.
with its delta-communication provides a means for a client-
The S PIAR style itself draws from many existing styles
/server interaction based on state changes that does not rely
[16, 22, 24, 27] and software fields [11, 19, 23], discussed
on caching.
and referenced in the paper. Our work relates closely to
the software engineering principles of the R EST style [12].
6. Related Work While R EST deals with the architecture of the Web [31] as a
whole, S PIAR focuses on the specific architectural decisions
While the attention for rich Internet applications in general of A JAX frameworks.
and A JAX in particular in professional magazines and Inter-
net technology related web sites has been overwhelming, few
research papers have been published on the topic so far. 7. Concluding Remarks
Recently a number of technical books have appeared on
In this paper we have discussed S PIAR, an architectural style
the subject of developing A JAX applications. Asleson and
for A JAX. The contributions of this paper are in two research
Schutta [1] focus primarily on the client side aspects of

TUD-SERG-2006-016 2nd revision 9


Mesbah & van Deursen – An Architectural Style for Ajax SERG

fields: web application development and software architec- [10] W. Emmerich, E. Ellmer, and H. Fieglein. TIGRA an architectural
ture. style for enterprise application integration. In ICSE ’01: 23rd Inter-
national Conference on Software Engineering, pages 567–576. IEEE
From a software architecture perspective, our contribu- Computer Society, 2001.
tion consists of the use of concepts and methodologies ob- [11] R. Fielding. Architectural styles and the design of network-based soft-
tained from software architecture research in the setting of ware architectures. PhD thesis, UC, Irvine, Information and Computer
A JAX Internet applications. Our paper further illustrates how Science, 2000.
[12] R. Fielding and R. N. Taylor. Principled design of the modern Web
the architectural concepts such as properties, constraints, and architecture. ACM Trans. Inter. Tech. (TOIT), 2(2):115–150, 2002.
different types of architectural elements can help to organize [13] E. Folmer. Software Architecture analysis of Usability. PhD thesis,
and understand a complex and dynamic field such as single Univ. of Groningen, Mathematics and Computer Science, 2005.
page Internet development. In order to do this, our paper [14] J. Garrett. AJAX: A new approach to web applications. Adaptive path,
2005.
builds upon the foundations offered by the R EST style, and [15] M. Hauswirth and M. Jazayeri. A component and communication
offers a further analysis of this style for the purpose of build- model for push systems. In 7th European Software Engineering Con-
ing web applications with rich user interactivity. ference (ESEC/FSE-7), pages 20–38. Springer-Verlag, 1999.
From a web engineering perspective, our contribution [16] R. Khare and R. N. Taylor. Extending the Representational State
Transfer (REST) architectural style for decentralized systems. In ICSE
consists of the S PIAR style itself, which captures the guid- ’04: 26th International Conference on Software Engineering, pages
ing software engineering principles that practitioners can use 428–437. IEEE Computer Society, 2004.
when constructing and analyzing A JAX frameworks as well [17] G. E. Krasner and S. T. Pope. A cookbook for using the model-view
controller user interface paradigm in Smalltalk-80. Journal of Object
as applications. The style is based on an analysis of various Oriented Program, 1(3):26–49, 1988.
of such frameworks, and we have used it to address various [18] A. Mesbah, K. Broenink, and A. van Deursen. SPIAR: An archi-
design tradeoffs and open issues in A JAX applications. tectural style for single page Internet applications. Technical Report
Future work encompasses the use of S PIAR to analyze SEN-R0603, CWI, 2006.
[19] J. C. Mogul, F. Douglis, A. Feldmann, and B. Krishnamurthy. Po-
and influence A JAX developments. One route we foresee is tential benefits of delta encoding and data compression for HTTP. In
the extension of S PIAR to incorporate additional models for ACM SIGCOMM Conf. on Applications, technologies, architectures,
representing, e.g., navigation or UI components, thus mak- and protocols for computer communication, pages 181–194. ACM,
ing it possible to adopt a model-driven approach to A JAX 1997.
[20] R. T. Monroe and D. Garlan. Style-based reuse for software architec-
development. At the time of writing, we are using S PIAR in tures. In ICSR ’96: 4th International Conference on Software Reuse,
the context of enriching existing web applications with A JAX page 84. IEEE Computer Society, 1996.
capabilities. [21] M. Naaman, H. Garcia-Molina, and A. Paepcke. Evaluation of ESI
and class-based delta encoding. In 8th International Workshop Web
Acknowledgments Partial support was received from SenterNovem, content caching and distribution, pages 323–343. Kluwer Academic
project Single Page Computer Interaction (SPCI). We thank Bas Graaf (TU Publishers, 2004.
[22] W. M. Newman and R. F. Sproull. Principles of Interactive Computer
Delft), Tijs van der Storm (CWI), and Mark Schieffelbein (Backbase) for
Graphics. McGraw-Hill, 1979. 2nd Edition.
their feedback on our paper. We particularly would like to thank Kees [23] D. E. Perry and A. L. Wolf. Foundations for the study of software
Broenink (Backbase) for our earlier collaboration on S PIAR [18]. architecture. SIGSOFT Softw. Eng. Notes, 17(4):40–52, 1992.
[24] A. Sinha. Client-server computing. Communications of the ACM,
35(7):77–98, 1992.
References [25] J. P. Sousa and D. Garlan. Aura: an architectural framework for user
mobility in ubiquitous computing environments. In WICSA 3: IFIP
[1] R. Asleson and N. T. Schutta. Foundations of Ajax. Apress, 2005. 17th World Computer Congress - TC2 Stream / 3rd IEEE/IFIP Con-
[2] D. J. Barrett, L. A. Clarke, P. L. Tarr, and A. E. Wise. A framework for ference on Software Architecture, pages 29–43. Kluwer, B.V., 2002.
event-based software integration. ACM Trans. Softw. Eng. Methodol., [26] G. Suryanarayana, J. R. Erenkrantz, S. A. Hendrickson, and R. N.
5(4):378–421, 1996. Taylor. PACE: An architectural style for trust management in decen-
[3] L. Bass, P. Clements, and R. Kazman. Software architecture in prac- tralized applications. In WICSA ’04: 4th Working IEEE/IFIP Confer-
tice, 2nd ed. Addison-Wesley, 2003. ence on Software Architecture (WICSA’04), page 221. IEEE Computer
[4] T. Berners-Lee, L. Masinter, and M. McCahill. RFC 1738: Uniform Society, 2004.
Resource Locators (URL), 1994. [27] R. N. Taylor, N. Medvidovic, K. M. Anderson, J. E. J. Whitehead,
[5] C. Bouras and A. Konidaris. Estimating and eliminating redundant J. E. Robbins, K. A. Nies, P. Oreizy, and D. L. Dubrow. A component-
data transfers over the Web: a fragment based approach: Research and message-based architectural style for GUI software. IEEE Trans.
articles. Int. J. Commun. Syst., 18(2):119–142, 2005. Softw. Eng., 22(6):390–406, 1996.
[6] D. Brodie, A. Gupta, and W. Shi. Accelerating dynamic web con- [28] H.-H. Teo, L.-B. Oh, C. Liu, and K.-K. Wei. An empirical study of
tent delivery using keyword-based fragment detection. J. Web Eng., the effects of interactivity on web user attitude. Int. J. Hum.-Comput.
4(1):079–099, 2005. Stud., 58(3):281–305, 2003.
[7] J. Challenger, P. Dantzig, A. Iyengar, and K. Witting. A Fragment- [29] A. Umar. Object-oriented client/server Internet environments. Pren-
based approach for efficiently creating dynamic Web content. ACM tice Hall Press, 1997.
Trans. Inter. Tech., 5(2):359–389, 2005. [30] W3C. URIs, Addressability, and the use of HTTP GET and POST,
[8] P. Clements, D. Garlan, L. Bass, J. Stafford, R. Nord, J. Ivers, and Mar. 21 2004. W3C Tag Finding.
R. Little. Documenting Software Architectures: Views and Beyond. [31] W3C Technical Architecture Group. Architecture of the World Wide
Pearson Education, 2002. Web, Volume One, Dec. 15, 2004. W3C Recommendation.
[9] D. Crane, E. Pascarello, and D. James. Ajax in Action. Manning
Publications Co., 2005.

10 TUD-SERG-2006-016 2nd revision


TUD-SERG-2006-016 2nd revision
ISSN 1872-5392 SERG

You might also like