Engineering Rich Internet Applications With A Model-Driven Approach

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/220593840
Engineering Rich Internet Applications with a Model-Driven Approach
Article in ACM Transactions on the Web · April 2010

DOI: 10.1145/1734200.1734204 · Source: DBLP
CITATIONS READS
56 297
4 authors:
Piero Fraternali Sara Comai

Politecnico di Milano Politecnico di Milano
264 PUBLICATIONS 5,764 CITATIONS 142 PUBLICATIONS 1,895 CITATIONS
SEE PROFILE SEE PROFILE
Alessandro Bozzon Giovanni Toffetti

Delft University of Technology IBM
149 PUBLICATIONS 1,149 CITATIONS 36 PUBLICATIONS 782 CITATIONS
SEE PROFILE SEE PROFILE
Some of the authors of this publication are also working on these related projects:
IFML - Interaction Flow Modeling Language View project
Cloud Native applications - Self-managing microservices View project
All content following this page was uploaded by Sara Comai on 21 August 2018.
The user has requested enhancement of the downloaded file.

Engineering Rich Internet Applications
with a Model-Driven Approach
PIERO FRATERNALI, SARA COMAI, and ALESSANDRO BOZZON
Politecnico di Milano
and
GIOVANNI TOFFETTI CARUGHI
University of Lugano
Rich Internet Applications (RIAs) have introduced powerful novel functionalities into the Web
architecture, borrowed from client-server and desktop applications. The resulting platforms allow
designers to improve the user’s experience, by exploiting client-side data and computation, bidi-
rectional client-server communication, synchronous and asynchronous events, and rich interface
widgets. However, the rapid evolution of RIA technologies challenges the Model-Driven Develop-
7
ment methodologies that have been successfully applied in the past decade to traditional Web so-
lutions. This paper illustrates an evolutionary approach for incorporating a wealth of RIA features
into an existing Web engineering methodology and notation. The experience demonstrates that it
is possible to model RIA application requirements at a high-level using a platform-independent
notation, and generate the client-side and server-side code automatically. The resulting approach
is evaluated in terms of expressive power, ease of use, and implementability.
Categories and Subject Descriptors: D.2.10 [Software Engineering]: Design—Methodologies;
H.3.4 [Distributed Systems]: Systems and Software; H.5.4 [Information Systems and Pre-
sentation (e.g., HCI)]: Hypertext/Hypermedia
General Terms: Design
Additional Key Words and Phrases: Rich Internet applications, Web engineering, model-driven
development, information storage and retrieval, information interfaces and presentation
ACM Reference Format:
Fraternali, P., Comai, S., Bozzon, A., and Toffetti Carughi, G. 2010. Engineering rich internet
applications with a model-driven approach. ACM Trans. Web 4, 2, Article 7 (April 2010), 47 pages.
DOI = 10.1145/1734200.1734204 http://doi.acm.org/10.1145/1734200.1734204
This article is an extended version of earlier works [Bozzon et al. 2006a, 2006b; Comai and Toffetti
Carughi 2007; Toffetti Carughi et al. 2007].
This work has been supported by the PHAROS Integrated Project (IST-2005-2.6.3) of the EC IST
6th Framework Program.
Authors’ addresses: P. Fraternali, S. Comai, and A. Bozzon, Dipartimento di Elettronica e
Informazione, Politecnico di Milano, Milan, Italy; email: {piero.fraternali,sara.comai,alessandro.
bozzon} @polimi.it; G. Toffetti Carughi, Faculty of Informatics, University of Lugano, Lugano,
Switzerland; email: toffettg@usi.ch.
Permission to make digital or hard copies of part or all of this work for personal or classroom use
is granted without fee provided that copies are not made or distributed for profit or commercial
advantage and that copies show this notice on the first page or initial screen of a display along
with the full citation. Copyrights for components of this work owned by others than ACM must be
honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers,
to redistribute to lists, or to use any component of this work in other works requires prior specific
permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 2 Penn
Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212) 869-0481, or permissions@acm.org.
C 2010 ACM 1559-1131/2010/04-ART7 $10.00
DOI 10.1145/1734200.1734204 http://doi.acm.org/10.1145/1734200.1734204
ACM Transactions on the Web, Vol. 4, No. 2, Article 7, Publication date: April 2010.
7:2 • P. Fraternali et al.
1. INTRODUCTION
The term Rich Internet Applications (RIAs), introduced in 2002 by Jeremy
Allaire in a Macromedia white paper [Allaire 2002], denotes a novel gener-
ation of online applications that merges a variety of technologies to provide
an extremely sophisticated user experience on top of the open architectural
standards of the Internet and the Web.
Although the most noticeable innovation of RIAs for the end users lies
in the powerful interaction mechanisms of the interface (like native mul-
timedia support, transition effects, animations, widgets, drag & drop, etc.),
these applications deeply renovate the way in which computation takes
place on the Web, by reintroducing a more flexible partition of work be-
tween the client and the server, comparable to that of pre-Web client-server
applications.
This ambivalent nature (part client-side, part server-side) of RIAs is probably
the main reason for their success: using the Web as a back-end retains all the
advantages of an open, low-cost, installation-free architecture, while increasing
the computation power of the client ensures the quality of interaction that
modern desktop applications and operating systems have made essential for
the users.
However, the advent of RIAs has also a flip side of the coin: many of the best
practices and methodologies for Web application development consolidated in
the past decade are now being challenged by the novel architecture of RIAs and
the market of development tools is still very much focused on the implemen-
tation technologies, as typical of a growing, and still immature, architectural
paradigm.
In this scenario, it becomes of prominent importance to start a reflection
on the “old” Web Engineering development methodologies versus the “new”
architecture and features of RIAs, to see if the experience, methods, and tools
of today can be adapted to the new requirements of RIA development, or a
completely novel set of development instruments must be conceived.
1.1 Rich Internet Applications: A Change of Architecture

The paradigm shift of RIAs with respect to thin-client applications purely based
on HTML and HTTP is somehow comparable to the change introduced by
data-driven, dynamic Web applications with respect to static Web sites: more
computation power is introduced in the architecture to support the development
of more sophisticated functionalities.
Specifically, RIAs extend the traditional Web architecture by moving part
of the application data and computation logic from the server to the client,
with the principal aim of providing a more autonomous and reactive user
interface.
The basic architecture of a RIA is shown in Figure 1: the system is com-
posed of a Web application server and a set of user applications running on
client machines. These applications are implemented either inside the browser,
using a variety of technologies like JavaScript, Flash animations, plug-in-
interpreted code, and Java applets, or outside the browser, by means of binaries
Engineering Rich Internet Applications with a Model-Driven Approach • 7:3
Fig. 1. A rich internet application architecture.
downloadable from the Web and interpreted in a specific runtime environment,

for example, using such technologies as Java Web Start1 and Adobe AIR.2
Having an application runtime environment also at the client-side intro-
duces a range of novel opportunities: (1) the control logic can be implemented
either at the client or at the server; (2) the business logic can be partitioned
between the client and the server; (3) data can be stored at both the client
and at the server; (4) communication can be more flexible: client to server and
server to client; (5) the client-side can work also when disconnected from the
server.
From the developers’ perspective, RIAs introduce a spectrum of new archi-
tectural patterns, design decisions, and implementation languages. In essence,
now any event (raised by the user that is interacting with the application, or
notified by the server or by another client) can be treated locally at the client,
delegated at the server, or treated at both tiers.
In summary, the new RIA architecture enables novel and more efficient Web
applications, where data and business logic are distributed between the client
and the server, and where the client and the server can communicate in both
directions; however, they also introduce many new development challenges that
demand a principled design method, supported by suitable models and tools.
1.2 Context and Problem Statement

The context in which the work of this paper is situated is the change in
the Web application development paradigm induced by the advent of RIAs,
which manifest itself in a rapid (and sometimes disordered) evolution of the
1 http://java.sun.com/products/javawebstart/
2 http://www.adobe.com/products/air/
fundamental implementation technologies, in the narrow focus of current de-

velopment practices only on the implementation phase, and in the gap between
the new architecture and the Software Engineering methods emerged and con-
solidated in the pre-RIA era.
Specifically, a wealth of methodologies have been proposed in the Web Engi-
neering community (e.g., Hera [Vdovjak et al. 2003], OOHDM [Schwabe et al.
1996], WAE [Conallen 2002], OOH [Gómez et al. 2000], UWE [Koch and Kraus
2002], WebSA [Meliá and Gómez 2006], and W2000 [Baresi et al. 2001]), which
share the idea of applying Model-Driven Engineering (MDE) to the specifica-
tion, design and implementation of traditional Web applications.
Presently, MDE for Web applications is also put to work concretely by aca-
demic and industrial-strength development environments (e.g., IBM Rational,
WebRatio, VisualWade, CodeCharge, and more3 ), which demonstrate how to
automatically generate the code of a dynamic Web application from high-level,
abstract models.
In this scenario, the problem addressed by the article is the investigation of a
Model-Driven approach to software development able to cater to the specific na-
ture of RIAs. The problem decomposes in a series of research questions, about:
— The architectural and functional features of RIAs that make them signifi-
cantly different from conventional Web applications.
— The modeling concepts and notations necessary to represent RIA-specific
features, and their semantics.
— The extent to which platform-independent models of a Rich Internet Appli-
cation can be used to generate the code automatically.
1.3 Approach and Original Contributions

The approach adopted in this work is evolutionary, and has the objective of
extending the experience gathered in designing a Web Engineering method-
ology for traditional Web applications to address the challenges of RIA
development.
The most significant contributions are:
(1) A synthesis of the common features of Model-Driven methodologies that
have been applied to the representation of traditional Web applications.
(2) A reasoned review of the features of RIAs, to understand what extensions
are necessary to current Web modeling notations.
(3) The application of the identified extensions to an existing Domain Spe-
cific Language (DSL) for Web application development: the Web Modeling
Language [Ceri et al. 2002].
(4) The illustration of the proposed RIA modeling notation on an extensive
case study.
(5) The implementation of the RIA model extensions within an industrial-
strength software development environment, which affects the IDE, the
application runtime, and the code generators.
3 www.ibm.com/rational, www.webratio.com, www.visualwade.com, www.codecharge.com
(6) An evaluation of the experience in terms of the ease of use, expressive

power, and implementability of the resulting DSL.
These questions have been addressed by several past works ([Trigueros
et al. 2007; Rossi et al. 2008; Meliá et al. 2008]) and partially described in
our previous works [Bozzon et al. 2006b; Comai and Toffetti Carughi 2007],
[Toffetti Carughi et al. 2007]. However, the contribution of this article goes
beyond previous proposals, both in the breadth of the analysis of the rele-
vant RIA features and of the required modeling notations, and in the depth
of the implementation and usage experience of the proposed Domain Specific
Language.
As in the past work of the authors, one of the possible modeling dimen-
sions (presentation) has been deliberately left unaddressed. We comment on
this issue further in Section 8.5, where we discuss two alternative approaches
currently pursued for dealing with the presentation aspects, one based on
weaving presentation into the WebML model during code generation, and
one based on a separate abstract model of presentation, stacked on top of
WebML.
The rest of the article is organized as follows: Section 2 gives an overview of
the features of the conceptual models used in Web Engineering, exemplifies the
characteristics of the WebML language, and outlines the extensions required
for addressing RIAs. Sections 3, 4, 5, and 6, respectively, describe conceptual
modeling primitives for expressing data distribution, computation distribution,
event management, and page computation; Section 7 reports on the implemen-
tation of the modeling primitives in a CASE tool for automatic Web application
code generation. Section 8 summarizes the Rich Internet Applications devel-
oped with the proposed method and tools and discusses some of the lessons
learned; Section 9 compares the related work in several fields and Section 10
draws the conclusions and highlights the future work directions.
2. WEB ENGINEERING MODELS AND NEW REQUIREMENTS

In the last decade, the Web Engineering community [Deshpande et al. 2002] has
put forth a variety of conceptual models and methods, specifically conceived for
the development of Web applications. These methods made an original synthe-
sis of previous ideas from the hypermedia, database, and software engineering
areas.
Beneath the surface of the different proposals (e.g., WebSA, Hera, OOH,
UWE, OOHDM, WebML, W2000), a common denominator can be found in
the essential ingredients advocated for the modeling (and subsequent code
generation) of Web applications [Wimmer et al. 2007]. The prevalent modeling
perspectives can be clustered into four major submodels: the domain, hypertext,
dynamic, and presentation models.
The domain (or simply data) model is used to represent the business and
data objects, their properties and methods, and their relationships. The most
commonly adopted notations are Entity-Relationship Diagrams [Chen 1976],
UML Class Diagrams [Booch et al. 2000], and semantic representations (e.g.,
RDF and OWL [Beckett and McBride 2004] [McGuinness et al. 2004]).
The front-end of the application is represented by means of the hypertext

model, which expresses the composition of the interface in terms of contain-
ers (e.g., pages) and content (e.g., data extracted from domain objects), the
navigation, that is, the mechanisms for user’s interaction through links and
form submission, and the business logics, expressing the update of the domain
objects and the invocation of arbitrary operations.
Beside the static representation of the front-end offered by the hypertext
model, most methods allow the specification of dynamics, which, in a Web
navigation, boils down to how the application reacts to the events raised by the
user’s navigation. The dynamic model can be either implicit (e.g., as in WebML
where it can be inferred from the hypertext model) or explicit (e.g., as in UML-
based methods that express dynamics with Activity Diagrams or State Charts).
Finally, the presentation model is overlaid on the hypertext model for spec-
ifying the layout and the look & feel of the interface, as well as the widgets
that enable user’s interaction. Some methods provide an abstract description of
presentation [Schwabe et al. 1996; Koch and Kraus 2002], separating abstract
and concrete interface specification, whereas other proposals [Ceri et al. 2002]
do not model presentation declaratively, but resort to code generation rules
for weaving the concrete, language-dependent presentation features into the
abstract hypertext model.
2.1 An Example of DSL for the Web: WebML

We exploit the WebML DSL [Ceri et al. 2002] to exemplify the conceptual
modeling of a traditional Web application, and its extension to RIAs.
To be concrete, a case study is introduced, which deals with a simplified
version of a Trip Planner application, where users can arrange their travel
package online.
With the Trip Planner, users can register to create and maintain personal
trip plans, consisting of a start and an end date, the characteristics of the
desired flights, hotels and cars, and of a total cost. The application comprises
forms for searching the various kinds of data, pages for visualizing the search
results and for navigating the retrieved information, and functionalities for
storing trip plans on the Web server for later manipulation.
In this Section we show how to model the Trip Planner as a traditional data-
driven Web application, using WebML; in the rest of the paper, we progressively
extend the model to incorporate the discussed RIA features.
In WebML, the domain model is specified using the Entity-Relationship
notation (or equivalently UML class diagrams); only the essential concepts are
used: entities, attributes, binary relationships, and single inheritance.
The data model of the running example is shown in Figure 2.
Upon the same data model, it is possible to define different hypertext mod-
els (called site views). Site views can be targeted to different classes of users
or to different access devices. A site view has a hierarchical, recursively nested
structure, made of areas and pages. The former are containers of pages, typi-
cally used to partition the site into relevant topics (e.g., News, Products, Ser-
vices, and so on).
User Trip
OID OID
Full Name 0:N 1:1 StartDate
Credit Card EndDate
Billing Address TotalPrice
0:N 0:N 0:N
Reservation
FlightReservation
Car
Hotel Reservation
0:N
0:N Flight
0:N
Hotel Car OID
OID Source
OID Destination
Location Operator
Name Operator
Pick-up Date Departure Date
Start Date Return Date
End Date Arrival Date
Price Price
Price
Fig. 2. The data model of the running example (initial version).
Pages contain content units, representing static content (e.g., a form) or

components for dynamic content publishing. In the latter case, the content
displayed by a unit typically comes from an entity of the data model, and can
be determined by means of a selector, which is a logical condition filtering
the entity instances (called the unit’s population) to be published. Instances
selected for display can be sorted according to ordering clauses.
WebML also includes components that do not publish content, but perform
an arbitrary business logic, called operation units; in particular, a set of data
update operations is predefined, whereby one can create/delete/modify the in-
stances of an entity, and create or delete the instances of a relationship.
Interaction is expressed at page/area level (non-contextual navigation) and
at component level (contextual navigation).
Noncontextual navigation is specified by defining pages and areas as land-
mark, default, and home, which denote global reachability. For example, a
landmark page or area is one to which an implicit navigation command is pro-
vided from all the other pages and areas at the same level in the hierarchical
structure of the site view. The home is the page accessed by default when the
site view is entered, whereas a default area or page is the one presented by
default when the enclosing container (site view, area or page) is accessed.
Contextual navigation is instead expressed through links connecting con-
tent units and operation units in a graph structure. Links have a threefold
purpose: allowing user’s navigation, enabling parameter passing, and trigger-
ing operations. Five kinds of links are defined: normal links are rendered as
navigable devices and enable parameter passing between components; trans-
port links allow only parameter passing and are not rendered as navigable
widgets; automatic links, are similar to normal links but are “automatically
navigated" by the system on page load; finally, OK and KO-links emanate only
from operation units and denote the course of action to take upon success and
failure, respectively.
HomePage H MyAccomodations MyFlights
L L L
SearchFlights L ViewFlight MyTrips L

C1 C2 C3
AvailableFlights Select Flight Details
Specify Trip SearchF Flight Trips Trip Details SelectedFlights
Location SelectT
Slocation FlightID
SLocation TripID
Elocation TripID
ELocation StartDate
EndDate
FPrice FlightID
StartDate FOperator Flight Flight Delete
[ELocation == Destination] Trip Flight
Trip Flight [FlightSelection]
EndDate [SLocation == Source] Trips [CurrentUserToTrip]
[StartDate <= Departure Date]
FPrice
[EndDate >= Arrival Date]
[Price <= FPrice]
FOperator TripID
[Operator == FOperator]
SortBy: Price
Trip
[CurrentUserToTrip]
FlightID
TripID
C4
AddFlight
ToTrip ConnectToTrip DisconnectFrom
Trip
OK OK
TripID TripID
FlightReservation FlightReservation
Fig. 3. Example of hypertext model for a traditional Web application.
Figure 3 shows an example of WebML hypertext model. The site view com-
prises a home page (marked with H) and five other pages for searching flights
and managing trip plans. Four pages are marked as landmark (L), to denote
that they are reachable by all the pages of the site view (this is achieved in
the implementation, for example, by means of links added to the appropriate
pages).
Page SearchFlights contains an entry unit (SpecifyTripLocation), which de-
notes a form for specifying the departure/arrival location and date, the maxi-
mum price and the preferred flight operator; when the user submits the selected
choices through the SearchF link, the list of available flights is displayed by
the AvailableFlights index unit, a data publishing component that extracts
instances from the Fligth entity, filters them according to a set of selector con-
ditions, and sorts them by price. By navigating the SelectFlight link, the user
may choose one item from the index and see its details in a separate page: the
ViewFlight page shows all the data of the selected flight (in the FlightDetails
data unit) and allows the user to associate it with one of his trips, by executing
the ConnectToTrip operation that creates a new relationship instance between
a flight and a trip. Finally, the MyTrips page displays the index of the user’s
trips (Trips unit), allows one to choose one trip and see its details (TripDetails)
and the flights associated with it (SelectedFligths). Selected flights can also be
disconnected from the current trip (DisconnectFromTrip).
Note that the dashed link exiting the TripDetails data unit is a trans-
port link and therefore not navigable. This means that when one trip is
selected in the Trips index unit, not only the TripDetails data unit is
displayed, but also the SelectedFlight index unit is rendered immediately,
because no further user’s action is required to determine the flights to
show.
The way in which a page is computed when the user accesses it is specified
using the dynamic model. In WebML, the dynamic model is implicit, as it can be
MyTrips Simplified State Machine in absence of failures

DisconnectFromTrip
C1 Trips index unit C2 TripDetails data unit C3 SelectedFlight index unit C4
unit
C1Disabled C2Disabled C3Disabled
3 enableC2 enableC3
[paramsNotNull(C2)] [paramsNotNull(C3)]
C4Idle
C1Enabled C2Enabled C3Enabled
on entry: on entry:
disableC1 disableC2 on entry: disableC3
EvalInputParameters(C2); enableC4
Execute(C1); Execute(C2);
EvalInputParameters(C3);
Execute(C4); /Execute(C4);
ComputeParameterPassing(C3);
ComputeParameter
enableC3
Passing(C4);
enableC2
ClickOnSelectT ClickOnDeleteFlight
/ComputeParameterPassing(C1); /ComputeParameterPassing(C3);
disableC1; disableC2; disableC3; disableC1; disableC2; disableC3;
enableC2 enableC4
Fig. 4. Example of dynamic model.
derived from the site view diagram. Every site view is equivalent to a composite
StateChart, where:
—There is one AND component for each page, content unit within a page, and
operation triggered by a link exiting from content units in the page.
—There is one event for each link, denoting its navigation, and one event for
each landmark, home, and default area or page, denoting its noncontextual
access.
—State transitions describe the order in which the content units of a page
are computed and specify the change of the page displayed to the user. The
empty event denotes an automatic state transition: this is typically used
for the computation of a unit that has no input parameters.
—State transitions may fire actions, for computing the parameters associated
with the navigated link or for executing the business logic of the component,
and may produce further events, to propagate the computation to other units
in the page.
As an example, Figure 4 shows a piece of the dynamic model corresponding
to the MyTrips page of Figure 3, which is a composite AND state made of four
AND-subcomponents: one for each content unit (labeled with C1, C2 and C3 in
Figure 3) and one for the operation triggered by the DeleteFlight link (labeled
with C4).
Each content unit can be in one of two states: enabled, when the content
of the unit is displayed in the page; disabled, when the unit is not computed
nor rendered. Operation units are in one state (idle), which denotes that they
wait for being triggered. Computation is described by state transitions that
enable/disable content units and execute operation sequences.
The StateChart of Figure 4 specifies the following behavior of the MyTrips
page: when it is accessed, only the Trips index unit is computed and displayed
(when the page state is entered, only the empty event causing the automatic
transition from the C1Disabled to the C1Enabled state of the Trips component
can be fired). From this initial state, the ClickOnSelectT event is active, which
denotes the selection of one trip in the Trips index unit. This event causes a
state transition, whereby:
— the action ComputeParametersPassing(C1) is fired, which determines the

parameter values associated with the navigated link SelectT;
— the disableC1, disableC2 and disableC3 events are generated, which de-
notes that the state of the three content units is reset and the page is thus
recomputed from scratch. Note that the Trips index unit is immediately
recomputed (due to the event), because it needs no input parameters.
— the enableC2 event is generated, which causes the transition of the TripDe-
tails unit to the enabled status.
— on entry in the C2Enabled status, unit TripDetails is computed, its output
parameters are determined, and the enableC3 event is generated, which
causes the SelectedFlight index unit to be computed. The automatic gener-
ation of event enableC3 represents the fact that the transport link between
units TripDetails and SelectedFlights enables parameter passing and the
computation of unit SelectedFlights without the need of an explicit user’s
interaction event.
At this point, no other transition can fire and computation halts. From this
state both the ClickOnSelectT and the ClickOnDeleteFlight events are fireable.
In the former case, the behavior is the one described above; in the latter case,
when the user navigates the DeleteFlight link, the DisconnectFromTrip oper-
ation is triggered, which passes parameters to (and, therefore, enables) the
TripDetails component. So the page is computed preserving the trip previously
chosen by the user.
2.2 Requirements for RIA-Aware Conceptual Modeling

RIAs differ from traditional Web applications in a number of aspects, which
must be reflected in the modeling languages used to specify them.
— Data distribution. In traditional dynamic Web applications data resides on
the server. In a RIA, data can be flexibly partitioned between the client
and the server, and the application can even operate disconnected from the
network. Data location decisions may be reflected in the conceptual model of
the application, for example to optimize efficacy of the client-side interaction
or to specify explicit data reconciliation policies. The RIA domain model
should capture the data distribution strategy.
— Computation distribution. In a thin-client Web application, data extraction
and business operations are computed at the server-side. In RIAs, the clients
host an application execution environment, too. Therefore, conceptual design
must cater for the decision on how to allocate computation both of the con-
tainers (namely, pages) and of components; several alternatives are possible:
computing at the client, at the server, and even partitioning the computation
of the same component across both tiers.
—Communication: In HTTP-based Web applications, communication is

initiated by the client and directed to the server. In a RIA, the presence of
a persistent application execution environment at the client-side enables
more communication schemes, also initiated by the server. Furthermore, the
synchronous event processing of the HTTP request-response cycle can be
sided by asynchronous event handling. The hypertext and dynamic model
must capture not only link navigation events, but also arbitrary event
occurrences, and express the policies for raising and handling them.
—Page computation: the page of a dynamic Web application is recomputed from
scratch at each user’s interaction. In a RIA, the user’s interaction is decoupled
from page computation, and the ways for updating the content of the interface
are richer: content publishing components can be recomputed from scratch,
but also hidden, or their content refreshed. The dynamic model should mirror
the added flexibility in the computation cycle of the interface elements.
3. MODELING DISTRIBUTED DATA

In a traditional dynamic Web application, content resides solely at the server-
side and is typically stored persistently in a database or in transient objects
contained in server-side users’ sessions.
RIA technologies extend the storage options: content can reside also in the
client, as main memory objects with the same visibility and duration of the
client application, or, in some technologies (e.g., in Google Gears or Adobe
Flash local shared objects4 ), as persistent client-side objects.
Client-side main memory objects can be used to temporarily store data
created or manipulated by the user. For instance, in the running example,
the profile data inserted by the user registering to the application could be
created temporarily on the client and submitted to the server at the end of
the data entry. Data can be validated on the client and modified by the user
before submission to the server.
Client-side persistent objects can also support offline usage, as in a desktop
application. For example, the data of selected hotels, cars, and flights could be
stored persistently on the client and the user may elaborate them offline.
3.1 Model Extensions

The domain model can be easily extended to capture the additional data storage
options of RIAs, by enriching data specifications with two dimensions:
(1) The location, which can be server or client,
(2) The duration, which can be persistent or temporary.
In WebML, entities and relationships are tagged with the location and
duration properties: server and client entities/relationships are graphically
denoted with a “S” or a “C” icon respectively, and persistent and temporary
entities/relationships with a filled or an empty icon, respectively (as shown in
Figure 5).
4 http://gears.google.com/, http://www.adobe.com/products/flashplayer/articles/lso/
S Persistent Server Entity C Persistent Client Entity
S Temporary Server Entity C Temporary Client Entity
Fig. 5. Data modeling notation.
If no duration and location are specified for an entity, persistent server-side

storage is assumed by default. Also, when not explicitly specified, relationships
between entities with the same duration and location inherit these properties
from the associated entities.
Data distribution between the client and the server raises classical prob-
lems, thoroughly investigated in the database field [Ceri and Pelagatti 1984;
Apers 1988]; data location transparency, long advocated as a goal of distributed
database design, cannot always be achieved in a RIA, either because not sup-
ported by the underlying database system, or due to the heterogeneous tech-
nologies used for data management at the client and at the server (e.g., XML at
the client and relational at the server). Therefore, in most practical cases, the
conceptual design should allow one to explicitly express the policies for data
replication and allocation, query and update distribution, data format conver-
sion, and consistency enforcement. These are particular cases of distributed
computation, discussed in Section 4.
3.2 Running Case

Figure 6 refines the data model of Figure 2 to show the chosen location and
duration options. Besides the data persistently stored at the server-side, now
the client replicates the data about the trip planning of the user, using the
Flight, Hotel, and Car and Trip persistent client-side entities,5 so to enable
offline usage. The confirmed attribute of entity Trip, added at the client side,
distinguishes those trips that the user has paid in the current session and that
cannot be manipulated at the client side any more.
Introducing data replication raises consistency issues: for example, if the
price or availability of a service changes at the server, the update is not au-
tomatically reflected at the client. Our choice in the running case is not to
replicate the price attribute for flights, hotels, and car rentals on the client, to
avoid data replication issues for simplicity of the examples. Instead, we illus-
trate how to model data reconciliation of the replicated TotalPrice attribute of
the Trip entity, in the example of Figure 11.
4. MODELING DISTRIBUTED COMPUTATION

In a traditional Web application, both individual components and the control
logic for orchestrating them are executed within the server-side runtime envi-
ronment. In a RIA, a second runtime environment, located at the client, can
also host the control logic and the execution of components.
5 The representation of replicated entities facilitates the reading of the schema, but could be error-
prone: from a practical point of view, the designer can declare that a client entity “mirrors” a server
entity, so that after any modification the dependencies between the corresponding entities can be
tracked.
Fig. 6. Data model with persistent client and server Entities/Relationships.
In designing a RIA application, a relevant decision is how to partition the

responsibility between the two tiers. The spectrum of possibilities goes from
the extreme of computing everything at the server, using RIA technology only
for presentation purposes, to its opposite: offline disconnected functionality. In
the middle, a number of configurations are possible, like:
—Managing all data and business components at the server-side, and using
the client-side execution environment only for controlling the interaction, for
example, by buffering user’s events and sending them asynchronously to the
server for smoothing the user’s experience.
—Executing some components at the server-side and some other components
at the client-side, based on their function, the data they need, etc.
—Splitting the computation of a logically cohesive component (e.g., a data
retrieval and format converter component, or an input validation and data
update component) between the client and the server.

In WebML, and in general in most Web Engineering notations, the specification
of control and component execution is quite simple: components are denoted
by the content units and operation units, which are assumed to be executed
at the server-side. Instead, control logic is represented by links and pages:
allocating content units into pages and drawing links between them specifies
how the server-side runtime must control page and content unit execution: only
the units of the requested page must be processed, in an order that adheres
to the parameter passing dependencies induced by the links connecting the
content units. Linking operation units in a graph establishes their precedence
of execution, which must be respected by the server-side execution engine.
In RIAs, things are more complicated:
—There is an execution engine at the client side too, which allows a much more
sophisticated control over the way in which the application is executed.
—Thanks to the client-side controller, the front-end may consist of a single
interface container managing multiple nested subelements, as in a desktop
application a main window controls its subwindows and panes. The interface
container may decide to hide, display, refresh the content of any of its sub-
elements upon each interaction of the user.
— Thanks to the presence of client-resident data and control, the behavior of
content publishing and management components is more sophisticated: a
unit can use (e.g., display) content local to the client, refresh its population
after a client-side data update, or realign its content to that stored at the
server, after a server-side data update.
The objective in extending the DSL is to balance expressive power and ease
of use: on one side, the notation should capture the most significant design
options about computation distribution; on the other side, the resulting models
should not explode in complexity and loose their intuitive semantics.
The proposed model extensions address the distribution of computation at
two different levels:
— specifying which interface containers (the whole application, some pages of
the application or only some of their subparts) are executed at the client and
not only rendered; this aspect is treated in Section 4.2.
— specifying which components can be executed at the client tier, server tier, or
at both; this aspect is treated in Section 4.3.
4.2 Client-Side Application Containers

The typical structure of conventional Web applications consists of a collection
of “flat” independent pages, computed by the server and rendered by the client;
in RIAs, instead, the interface consists of an outermost container, organized
into submodules, which can be independently computed and rendered by the
client, possibly in collaboration with the server.
For continuity, we still call pages the more powerful interface containers
offered by RIAs, and distinguish between:
— Server pages: they represent traditional Web pages; content and presentation
are calculated by the server, whereas rendering and event detection are
handled by the client.
— Client pages or client containers: they represent interface containers incorpo-
rating content or logics managed (at least in part) by the client. Their content
can be computed at the server or client-side, whereas processing, rendering,
and event handling occur at the client-side.
Mixed combinations of pages/subpages are allowed, that is, server pages
can contain server subpages and/or client subpages, while client pages can
contain server subpages and/or client subpages. For example, a server subpage
nested within a client one means that the client-side controller delegates the
execution of a portion of the front-end to the server, and treats it as a black
box. Conversely, a client subpage nested inside a server page may represent
the case in which a conventional Web application allows a limited client-side
control, restricted to a part of the page (e.g., an applet implementing a smart
file uploader embedded within an HTML Web page).
Fig. 7. Page structure of the RIA version of the case study.
In the WebML notation, to distinguish server and client pages, we mark

them with a S or C icon, respectively. In case of pages organized into subpages,
the subpage type inherits the same type of the superpage, unless otherwise
specified.
4.2.1 Running Example. The specification of the Trip Planner (Figure 3)

as a traditional Web application comprises separate top-level pages, each one
embodying a main function of the system.
In a RIA, the front-end is organized as a single container page Trip Planner
(1), executed at the client, as shown in Figure 7. The topmost page accom-
modates further subpages, that support the same functionality allocated to
distinct pages in the traditional Web application: MyFlights (2), MyAccommo-
dations (3), and MyTrips (4). All the subpages are not marked, and therefore
are executed at the client as their superpage.
4.3 Distribution of Component Execution

Business components can be executed at the server, at the client, or at both the
tiers. The case of data-driven components, represented in WebML by content
and operation units based on entities and relationships, permits the illustration
of all the relevant cases of component distribution.
For example, an index unit denotes the publication of a list of objects; its
computation consists of several steps: the instances of the underlying entity
are accessed, the filtering condition for determining the actual population to be
displayed is evaluated, and possibly the resulting instances are sorted accord-
ing to some criteria.
When data and computation are distributed, several options are available
for computing the component: the content may come from the server or from
the client, and can be filtered and/or sorted at one of the two tiers.
These alternatives can be reflected in the WebML model by refining unit
specification: content and operation units, and their selector conditions and
ordering clauses, can be defined either as server or as client, with some con-
straints on the possible combinations.
In particular, client units cannot be directly inside a server page, because
they need to be executed in the scope of a client-side interface container. Sym-
metrically, a client page cannot directly contain a server content unit, because
the page is executed by the client: the publication of server content in a client
page can be achieved by using a client unit extracting data from a server entity.
Operations invoked from a server page must be defined as server units, while
they can be defined either as server or as client if they are triggered by a client
page.
For a client unit it is possible to:
— publish or manipulate content locally stored at the client-side or (by invoking
the server) at the server-side, that is, the reference entity/relationship of the
unit can be either a server or a client one, persistent or temporary;
— have client-side and/or server-side selector conditions; the former are com-
puted locally at the client, whereas the latter are executed at the server-side;
— have client-side or server-side ordering clauses; the former are computed
locally at the client, whereas the latter are executed at the server-side.
Server units are entirely computed by the server and therefore cannot use
client-side entity/relationships and cannot comprise client-side selectors and
ordering clauses. All the computations performed by the server must rely
only on data and operations computable at the server-side, to cope with the
asymmetric nature of the Web, where the client calls the server and not vice
versa.
Client and server units/selectors, and ordering clauses are marked with a
C or S icon. When not explicitly specified, content and operation units inherit
their type from the page containing or triggering them; selectors and ordering
clauses inherit their type from the source entity/relationship of the unit.
4.3.1 Running Example. To exemplify the distribution of computation, the

Trip Planner application can be extended: once logged in, the user can search
for hotels, cars, and flights to compose her travel plan. Travel plans are stored
at the client side for later reuse in a disconnected manner: given a trip the
user may choose different alternatives for hotels, flights, and car rentals, also
when she is offline. The application must also offer a reconciliation function
that aligns the information stored on the client (like the total cost of a trip)
with their updated status on the server. Finally, the user can confirm a trip
plan stored on the client by issuing a purchase order.
Figure 8 expands the model of the RIA client-side page of Figure 7, by de-
tailing the functionality for searching available flights, which exhibits a design
pattern frequently encountered in RIAs, whereby users load objects from the
server to the client and then filter and sort them locally.
The main page (Trip Planner) contains an entry unit (Enter Destina-
tion), which denotes an input form for entering the source, destination, start
and end date of the desired flight. The outgoing link SearchF of the entry
unit expresses the possibility of submitting the input, which is communi-
cated as a set of parameters to the Available Flights index unit. This is a
data-driven component, based on the content of the server-side Flight en-
tity. Its selector condition consists of two parts: one server-side (a conjunc-
tion of predicates on the start and end locations and dates) and one client-
side (a conjunction of predicates on the price and operator). Furthermore,
Fig. 8. Refinement of the hypertext model of Figure 7: flight search functionality.
the unit has one server-side ordering clause, on the price attribute, and one
client-side ordering clause, on the operator attribute.
The semantics of such a specification is the following: when the outgoing
link SearchF is navigated, an initial list of flights is retrieved from the server,
filtered by means of the server-side selector conditions, and sorted according to
the (SortBy: Price) server-side ordering clause.
After the initial set of flights has been retrieved from the server, client-
side selectors and ordering clauses allow the user to refine the filtering and
sorting on the client: the retrieved instances can be locally filtered by means
of the RefineSearch entry unit, which provides inputs for the two client-side
conditions on price and operator, without invoking the server. In the same way,
the available flights, initially sorted by price, can be reordered over the operator
attribute, without accessing the server.
Server-side selectors allow reducing the data to be transmitted to the
client, but, if they are used also for refined filtering, they slow down the
(re)computation of the unit due to server round-trip; conversely, client-side
selectors ensure smoother filtering at the cost of initial data transfer. Mixed
selectors (like those in Figure 8) can be used to reach the desired balance.
Similar considerations apply to the partitioning of ordering clauses: when data
are naturally sorted in only one way, their evaluation at server-side improves
efficiency; when alternative sorting criteria are equally meaningful to the user,
multiple ordering clauses should be used, delegating to the server the most
frequently used one, and letting the user apply other sorting criteria locally at
client-side.
The next examples further illustrate the interplay of data and computation
distribution.
Figure 9 models the possibility to saving a flight on the client. Once a flight
is selected and displayed by the FlightDetails data unit, by navigating the
ADDFlight link the user can replicate locally its data. The ADDFlight link
triggers an operation chain, which creates a flight object on the client (via
the CreateFlight create unit) and associates it (via the ConnectToTrip connect
unit) to the trip currently visualized in the MyTrips sub-page; these operations
Create Flight ConnectToTrip

ADD Flight
OK OK
C C
attribute values Flight C FlightSelection C
Trip Planner
OID, other
C 1 MyTrips
MyFlights Enter
Destination Trip Details
Slocation
Flight Details AvailableFlights Elocation SLocation
SelectF StartDate
EndDate SearchF
ELocation
FlightID
StartDate
RefineF Trip C
EndDate
Flight S Flight S FPrice
[ S ELocation == Destination] FOperator
[ S SLocation == Source] Refine
[ S StartDate <= Departure Date] Search
[ S EndDate >= Arrival Date]
[ C Price <= FPrice] FPrice
[ C Operator == FOperator]
FOperator
2 S
SortBy: Price
SortBy: Operator
4
C
Fig. 9. Refinement of the hypertext model of Figure 7: saving a flight on the client.
C Trip Planner 1 OK
MyTrips
MyFlights Trip Details DeleteFlights
SelectT
TripID
OK
2 PlannedTrips
Trip C Flight C
TripID
MyAccomo SavedFlights
dations DeleteFlights DisconnectFrom
Trip
OIDs
Trip C
[ C confirmed==false] C
Flight C
3 4 [ C FlightSelection] FlightSelection C
Fig. 10. Refinement of the hypertext model of Figure 7: client-side content management.
apply to client-side, persistent entities and relationships (denoted by the filled

C icon).
Data replicated on the client can be published and manipulated in the same
way as server-side data. Figure 10 shows an example of client-side content
management: in the MyTrips sub-page the PlannedTrips index unit, defined
on the client-side persistent Trip entity, displays the trips saved by the user on
the client. After selecting one trip, its data are shown in the Trip Details data
unit, and the flights associated with it appear in the SavedFlights multichoice
index unit; from this unit the user can make a multiple selection of the instances
of the trip’s flights to be deleted.
The navigation of the DeleteFlights link triggers a sequence of client-side
operations: the DisconnectFromTrip disconnect operation deletes the Flight-
Selection relationship instances between the chosen flight and the current
trip, after which the DeleteFlights delete operation erases the Flight instances.
Since processing is confined to the client-side, flight data on the server remain
unaffected.
ModifyTrip
C Trip Planner
MyTrips
Trip Details
OK C
PlannedTrips Select
Trip
Trip C
OK
<TotalPrice := newPrice>
Trip C
Trip C SelectedFlights CalculatePrice
[ C confirmed==false]
RefreshFlightPrices S
SelectedHotels FlightsParams $
Flight C
[ C FlightSelection]
RefreshHotelPrices
Hotel C
[ C HotelSelection] HotelsParams
Fig. 11. Refinement of the hypertext model of Figure 7: synchronization of server and client data.
C Trip Planner
OID ExportTripPlan Payment
MyTrips CCNumber
Trip Details Service S
OK
Select
Trip C $
TripID
PlannedTrips Trip C
[ C tripID = OID]
OK
Trip C Flight C
[FlightSelection C ]
Confirm Order Reserve Hotel C
CCNumber Trip [HotelSelection C ]
ImportReservation
Trip C ModifyTrip
[ C confirmed==false]
OK OK S
Trip S
Flight S
Trip C [FlightReservation S ]
<confirmed := true> Hotel S
[HotelReservation S ]
Fig. 12. Refinement of the hypertext model of Figure 7: bulk data transfer from client to server.
The storage of data on the client allows the user to interact also when he is
off-line: the MyTrips page can be navigated and its content can be updated also
when the application is disconnected. Figure 11 shows an example of how to rec-
oncile data replicated at the server and client-side. When the user goes online,
she might want to refresh the actual prices of the hotels or flights composing
a trip: this is accomplished through the RefreshHotelPrice and RefreshFlight-
Price links exiting the SelectedHotels and SelectedFlights multichoice index
units, which send the data of the selected hotels or flights to a server-side
component (CalculatePrice), which computes the updated price; this output
parameter is used by the ModifyTrip unit to update the price of the client-side
Trip object.
Figure 12 shows an example of bulk data transfer between tiers. When the
user decides to confirm the trip plan by addressing a purchase order, he fills up
the ConfirmOrder entry unit with the payment information (e.g., the credit card
number) and activates the ReserveTrip link. Such link triggers an operation
chain involving both the client and the server: the information about the trip
stored at the client is exported6 (ExportTripPlan unit), the payment is settled

using a Web Service (PaymentService unit), the exported trip is imported at
the server to create a reservation (ImportReservation unit) and, finally, the trip
confirmation status is updated on the client (ModifyTrip unit).
5. MODELING COMMUNICATION
Conventional Web applications can be seen as centralized reactive systems,
in which events are produced by the user and processed synchronously by
the server. In RIAs, the presence of an execution environment at the client-
side enables a more powerful communication and a more flexible processing of
events, which can originate at the client and server-side and can be processed
both synchronously and asynchronously. Event processing entails specifying
how and where along the delivery path the notification recipients are chosen
(event filtering, in the terminology of Meier and Cahill [2005]) and whether the
communication is asynchronous (thus persistent) or not.
The filtering location specifies the place in which the recipients of occurred
events are decided: recipient selection can be done by the event publisher, by an
intermediate broker, or no selection can be performed at notification time: in this
latter case, the event is notified to all possible recipients (in broadcast or using
a subscription mechanism) leaving to them the decision of what to do with it.
The filtering logic addresses the mechanism used to determine the set of
recipients: static filtering can be used, as in address-based communication,
where the recipients are chosen from a known list; queries on object or event
attributes, where the set of recipients is determined by means of a query; or
runtime rules with a more complex logic (e.g., detecting composite events).
Communication is persistent/asynchronous, when the submitted message
is stored by the communication system until delivery to the recipient. It is
therefore not necessary for the sending application to continue execution after
submitting the message. Likewise, the receiving application need not be ex-
ecuting while the message is submitted. It is transient/synchronous, when a
message is stored by the communication system only as long as the sending
and receiving applications are executing, and the recipient application receives
a message only if it is executing; otherwise, the message is lost.
5.1 Model Extension

Modeling events in a RIA requires overcoming the assumption that the user’s
interaction is the only source of events. In WebML, events have a fixed se-
mantics, because they are implicitly associated with links, which abstract the
navigation of an hypertext anchor or the submission of a form. They have an
implicit type, constituted by the link name and by the parameters associated
with the navigation action (e.g., the input fields submitted with a form or the
parameters needed for the computation of the content unit of a page or of the
operation units of a sequence).
6 TheWebML components for importing and exporting data using XML serialization and for inter-
acting with Web Services are described in Brambilla et al. [2004].
Fig. 13. The event model for the Trip Planner application.
Because RIAs enable collaborative work and bidirectional messaging, they

require explicit events, associated with a type, to enable event filtering and
parameters, and a persistence level, to permit asynchronous communication.
5.1.1 Event Model. The Event model extends the domain model, to rep-
resent events connected to the domain objects. Events are characterized by
a type, including attributes denoting event parameters, and by relationships
with domain entities.
5.1.1.1 Running Example. To illustrate event handling, the Trip Planner

application of the running case is extended into a collaborative environment,
similar, for example, to http://campfirenow.com. Users self-organize into travel
groups and define a trip plan together; each member can chat and change trip
details. The application allows each member to monitor the conversation with
other members and the evolution of the trip plan continuously, while interacting
with the interface.
The data model of Section 3 is extended with two new domain entities (see
Figure 13): the Message entity temporarily stores the messages that can be
exchanged between users and their online contacts; the Profile entity is a (sim-
plified) representation of a configurable rule a user can specify to validate a
planned trip and be warned if any of her desiderata is not met (e.g., change of
dates, maximum cost threshold, unwanted participants).
The event model comprises the events that are relevant for the application:
the New Message event type signals that a message has arrived, the Status
Change event types denotes the change of connection status of users, and the
Flight Update event type is raised when a selected flight is changed by some
other user. Event parameters are denoted by suitable attributes and relation-
ships; for example, the Flight Update has a mandatory 1:1 relationship to a
flight object, also represented as a derived attribute FlightOID, storing the
identifier of the novel flight selected by a user.
{followed if event was Predefined output parameters:

Predefined input parameters: succesfully signaled}
- sender ID - sender ID
- recipients ID set - recipients ID set
+ - timestamp
OK
EventType-specific parameters +
SendEvent ReceiveEvent EventType-specific parameters
No incoming links OK
No input parameters
Exiting links:
KO - 1 OK-link
- 0..N transport links
EventType EventType
<recipient := ID set | * >
<param := value>
Fig. 14. Notation for the Send Event (left) and Receive Event (right) operations.
5.1.2 Event Raising and Handling. Event notification and handling can
be represented by means of explicit operations for sending and receiving
events. Two operations are defined: send event and receive event, denoted as in
Figure 14.
A send event operation triggers the notification of an event. It can be acti-
vated by the user navigating a link, or as consequence of other external events
(e.g., a receive event). It is associated with an event type and requires the
specification of the following input parameters: the sender of the event (e.g.,
a user identifier), one or more recipients, and possibly additional parameters
based on the event type. The output is simply the success or the failure of
execution.
A receive event operation is an event notification listener: as such, it repre-
sents a subscription for the reception of an event type, and is triggered when
a notification concerning the associated event type is received. This operation
returns the following (output) parameters: the sender of the event; the set of
the recipients of the notification; the timestamp (at server) when the event was
signaled. Additional application-specific parameters can be associated with the
event type. Receive event operations can have only outgoing transport links, to
pass parameters to other units, and OK-links; no incoming links are allowed.
Send and receive operations can be combined with the retrieval of data
and with conditional expressions, either after reception of the event or before
notifying it, to express different filtering logics and locations.
5.1.2.1 Running Example. Figure 15 shows the hypertext model for the
instant messaging part of the collaborative Trip Planner, which handles events
of type Status Change and New Message.
The user starts the interaction by logging in page Insert Credentials; once
the Login operation is performed, a list of user contacts is fetched from the
database with the Get Contacts query operation; the list of user contacts is
used to identify the recipients of the Notify (I’m online) send event unit, defined
over the Status Change event type. This pattern represents an example of
query-based filtering managed by the sender: recipients are retrieved through
the query of the Get Contacts unit, triggered by the user’s login. Analogously,
when the user logs out, a notification is sent to online contacts through the
Notify (I’m offline) send event unit.
The model of Figure 15 exemplifies the handling of explicit events too: the
status of contacts of the Instant Messages page is updated when the notification
Fig. 15. Collaborative Trip Planner: patterns for query-based and static filtering at the sender.
of a Status Change event is catched by the Received Presence receive unit, which
triggers the computation of the Online Contacts index unit.
Figure 15 contains also an instance of the static filtering pattern: the user
selects a recipient from the Online Contacts list, writes a message through the
New Message entry unit, and submits it, triggering a sequence of operations:
first, the message is saved locally on the client (with the Save Outgoing create
unit), then, a New Message notification containing the message body is sent to
the selected recipient through the Send (Msg Sent) send event unit. At the end
of the sequence, the Chat Messages content unit is refreshed, to display the
newly sent message.
Message reception is represented by the Rec (Msg Sent) operation (only the
recipient of the message will receive the notification): in this case, a local copy
is saved (Save Incoming operation) and the Chat Messages unit is refreshed to
show the incoming message.
Figure 16 shows an hypertext model demonstrating the recipient-side filter-
ing pattern, based on the Flight Update event type.
Let us assume users can specify in their profile the price cap for a flight, to be
alerted at each flight update event if a proposal is too costly. The Collaborative
Trip Planning page contains the data unit Current Trip showing the current
trip information; Selected Flights and Selected Hotels respectively show the
currently selected flights and hotels for the trip, while Flight Options and Hotel
Options show available options to choose from. Whenever a trip participant
suggests a new flight through the Select Flight connect operation, an event
of type Flight Update is notified to all trip participants. The event is received
through unit Rec (Flight Change), the price cap is fetched from the Profile entity
through unit Get Profile, and the constraints are checked through unit Check
constraints: if they are not met a warning page is shown, otherwise current trip
details are refreshed (along with the selected flights list).
Rec (flight change) Check

Get Profile
constraints
E C
OK
S
[?] OK
KO
Notify
(added flight) Flight Update [Flight meets profile?]
Profile S
E S C Collaborative Trip Planner
MyTrips
Flight Update
OK
OK
OK Alert Page
Collaborative Trip Planning
Find Party Selected Flights TripId Current Trip ...

S
[?] TripId
Selected Hotels
User S Flight S Trip S
[ S FlightSelection]
OK
TripId
[Trip2Participant]
TripId
Select Flight Flight Options Hotel Options
SelectFlight
Hotel S
FlightId, TripId [ S HotelSelection]
S
FlightReservation S Flight S Hotel S

[ S Trip2FlightOption] [ S Trip2HotelOption]
Fig. 16. Collaborative Trip Planner: recipient-based filtering pattern.
Rec (flight Get User Status Online? Get Profile Check Send Email
change) constraints
E
OK
[?] OK KO
[?] OK KO
Flight Update User [status == ‘online’] Profile [Flight meets profile?]
Fig. 17. Chain of operations for storing a message when the recipient is offline.
5.1.3 Server-Side Event Handling. In the previous examples, receive event

units model the behavior of a client-side application (i.e., of the interface shown
to the user) upon the reception of an event, assuming that all the events notifi-
cation are sent synchronously. In this section, we show how to model persistent
(asynchronous) communications and event reactions on the server. Reactions
to events received on the server are modeled by means of operation chains
starting with a receive-event operation: the chain typically contains operations
that store data persistently on the server to be available at a later time and,
possibly, operations for generating new events.
5.1.3.1 Running Example. Figure 17 exemplifies a server-side event reac-

tion. When flight information is updated and the user is offline, the notification
in Figure 16 is lost. To make the notification available also to offline users,
upon the reception of the notification of the Flight Updated event (represented
by the Rec (flight change) receive event unit), the server-side sequence of op-
erations of Figure 17 is triggered: a check is performed whether the user is
online; if not, the price cap in the user profile is matched against the new flight
conditions and, if the constraint is not met, a warning email is sent to the
user.
Notice that the sequence of operations triggered by the event notification
does not terminate with a page, since the processing is confined to the server
and does not produce any synchronous change in the interface.
6. MODELING PAGE COMPUTATION

As discussed in Section 4, in a traditional Web application there is only one
controller, at the server side, which orchestrates the computation of the page. At
each interaction the whole page is computed from scratch and its components
are evaluated in the order imposed by the data flow dependencies specified by
contextual links.
In a RIA, the introduction of a controller at the client-side partitions the page
computation process into two coordinated subprocesses: the outermost client
page is computed by the client-side controller, which may entail one or more
invocations of the server-side page computation process to cater for the server
subpages nested inside the client page. Moreover, RIAs allow one to selectively
(re)compute or refresh only a portion of the interface of the application and to
maintain unchanged all the pieces of information that are not affected by the
interaction, so that unneeded recomputation can be avoided. Dually, they may
cause some pieces of content, which were previously displayed, to be invalidated
because they are no longer consistent with the rest of the page.

The dynamic model of traditional Web application can be inferred from the
graph of components and links of the page and from default rules for estab-
lishing the order of computation of components. In essence, the idea is that at
each interaction the entire page is recomputed from scratch, with a best-effort
approach: the maximum number of components for which input parameters
are known is executed.
In a RIA, the abovementioned scheme does not apply. Applications are often
hosted within a unique container page, which includes all the application com-
ponents, and at each event only the minimum number of affected components
must be recomputed.
The effect of each event on page computation can hardly be inferred from the
component graph and from default computation propagation rules; therefore,
it must be expressed explicitly. A concise way of doing so is associating to each
event (navigational or originated from the server) a sequence of actions on
components, for example, by specifying pairs <event, computation sequence>,
where:
—event is either a user-originated event (contextual link navigation, noncon-
textual page access), or a system-originated event (e.g., Web service calls,
temporal events, and data update events). For links triggering an operation
chain, a page computation sequence must be associated with the successful
execution (following OK links) and with all the possible failures, correspond-
ing to different paths terminating with a KO link.
Fig. 18. Example of RIA dynamic model.
— A computation sequence (or sequence) is an ordered sequence (a1 , . . . , an) of

actions ai (i = 1..n) of the following types:
— Content/Operation Unit Evaluation (denoted by the term Evaluate(ui ),
where ui is a unit): causes the complete computation of a content unit or
the execution of the operation unit, which consists of (1) the evaluation
of the input parameters (e.g., all the mandatory parameters must have a
value); 2) the execution of its business logic.
— Content Unit Refresh (denoted by the term Refresh(ui )): causes the com-
putation of the population of a content unit, without redetermining the
values of the input parameters.
— Content Unit Invalidation (denoted by the term Invalidate(ui )): discards
the population of a content unit and the values of its input parameters.
— Content Unit Deactivation (denoted by the term Deactivate(ui )): discards
the population of a content unit, but preserves the values of its input
parameters.
Syntactically, sequences are denoted as model annotations on navigational

links, OK/KO links, and pages (for expressing the sequence associated with
the noncontextual accesses to the page). From action sequences and from
the topology of the components and links of a page, the formal dynamic
model is uniquely determined, in the form of a StateChart like the one of
Figure 18.
The following well-formedness constraints apply: (1) a sequence must include

operators acting on units belonging to the same page (possibly, the outermost
client page, in case of nested pages); (2) to avoid cyclic computations, the same
unit cannot be evaluated and/or refreshed twice in the same sequence; (3) to
avoid the early evaluation of units, a sequence must prescribe an order of
evaluation such that each unit is preceded by all the units that may provide
input parameters to it.
The dynamic model of traditional Web applications is a special case of the
dynamic model for RIAs. The following restrictions reproduce the page compu-
tation semantics of traditional Web applications: (1) the sequence contains
a Unit Deactivation action for each unit having at least one input trans-
port link and a Unit Invalidation action for all the other units; (2) the se-
quence does not contain Refresh actions; (3) for each unit, the Unit Deac-
tivation and Unit Invalidation actions precede any of the Unit Evaluation
action.
These conditions produce sequences that consists of two steps: (1) first the
population of all units and the parameters not affected by the user’s interaction
are discarded, so that the state of the page is reset, keeping only the parameter
values that derive from the user’s interaction (e.g., the OID of the object selected
in an index unit); (2) then, only Unit Evaluation actions are applied to compute
the page.
6.2 Running Example

As an example, consider the MyTrips page depicted in Figure 10, which extends
the original WebML model of Figure 3. A RIA-enabled page computation policy
can be specified using three event-actions sequences: (a) after noncontextual
page access; (b) after the navigation of the SelectT link; (c) after the navigation
of the DeleteFlights link and the successful execution of the operation chain.7
On noncontextual access, only the Trips index unit can be computed:
this behavior is captured by the computation sequence <OnPageEntry,
(Evaluate(Trips))>.
When the user navigates the SelectT link, that is, an item is selected from the
Trips index, only the TripDetails data unit and the corresponding SavedFlights
index unit need to be evaluated. This behavior is represented by the sequence
<SelectT, (Evaluate(TripDetails), Evaluate(SelectedFlights))>.
When the user navigates the DeleteFlights link, the chain of operation
units is started and the page is reaccessed; a possible way of recomputing
the page can be: recomputing only the population of the SelectedFlights index
and leaving the other units unaffected, because they refer to the currently se-
lected trip. This behavior is captured by the sequence <DeleteFlightsOKLink,
(Refresh(SelectedFlights))>. Notice that this sequence exceeds the restrictions
that characterize the behavior of a traditional Web application, where all units
would be unnecessarily recomputed.
The site view model and the action sequences associated with events allow
the inference of a StateChart representing the formal dynamic model of a RIA.
7 For brevity, we omit the case of operation failure.
Figure 18 shows the StateChart derived from the model in Figure 10 and from
the above illustrated action sequences.
Compared to Figure 4, the StateChart in Figure 18 has a more articulated
topology: in addition to the AND-component for each content unit (C1,C2,C3)
and operation unit (C4,C5), the dynamic model also contains: one AND-
component for each other user-originated or system-originated event (E1,E2),
which dictates the associated event-actions sequence; one AND-component for
each operation triggering event (E3), which denotes the operation chain acti-
vation; and one AND-component for each OK or KO link terminating the chain
(E4), which specifies the event-actions sequence for computing the page.
Also, the composite state representing a content unit has a more refined
internal structure, comprising four sub-states corresponding to the main steps
of unit computation. Such a refinement is necessary to represent the separa-
tion, possible in a RIA, between the computation or invalidation of the input
parameter and of the content. Finally, the AND-component of content units
in the RIA StateChart contains more precise state transitions, which specify
the effect of the Unit Evaluation, Unit Content Refresh, Unit Invalidation, and
Unit Deactivation actions.
Note that the StateChart of Figure 18 is inferred from the site view model
and not specified by the developer, who has only to express the sequence of
actions associated to links and noncontextual navigation.
7. IMPLEMENTATION
The modeling primitives introduced in the previous sections have been imple-
mented within WebRatio,8 a commercial CASE tool for designing dynamic and
service-oriented Web applications with the WebML language, and for generat-
ing their code for the Java Enterprise Edition platform.
7.1 Architecture for Traditional Web Applications

Figure 19 illustrates the high-level structure of WebRatio:
(1) The WebRatio IDE supports the definition of projects, which consist of
the WebML data and hypertext models and of presentation specifications.
The models are internally stored in XML format. The IDE also addresses
the binding of the data model to data sources, the reverse engineering
of existing databases, the validation of models, the import of presenta-
tion mock-ups, and the definition of the visual properties of the inter-
face for different rendering technologies, such as HTML, XML, PDF, or
Flash.
(2) The Runtime is a set of components supporting the execution of Web appli-
cations built with WebRatio. Its architecture, shown in Figure 20, builds
on the Apache Struts MVC 2 framework and on the Hibernate persistence
layer. Browser requests for dynamic pages and sequences of operations
are handled by a configurable Controller servlet, which maps each request
to a specific Action Class in the Model. Actions orchestrate the execution
8 http://www.webratio.com
Fig. 19. WebRatio architecture.
Fig. 20. WebRatio JSP 2.0 runtime architecture.
of pages and of sequences of operations: they invoke generic services and

may produce data in state objects (e.g., Java Beans). The generic services
correspond to each WebML primitive: there is one service for page com-
putation, one for each type of WebML unit, and one for link computation.
Each instance of a page, link, or unit in a WebML model is associated with
a configuration file (called XML Descriptor), used to instantiate the generic
service. For example, an index unit has a descriptor specifying the source
entity, the attributes to show, and the parameters that are necessary for
processing the data retrieval query. After executing an action, control goes
back to the Controller, which invokes a View component to return a re-
sponse to the browser. View components are JSP templates for rendering
the state objects in the rendition language of choice.
(3) The Code Generator transforms the XML project into the various compo-
nents of the Web application code: the Controller configuration file; the
XML descriptors of pages, links, units, and operations; the JSP templates
of the View; and the configuration files for auxiliary services such as au-
thentication, logging, and internationalization.
Fig. 21. Runtime architecture for supporting RIAs.
7.2 Extended Runtime Architecture for RIAs

To support RIAs, the existing architecture has been integrated with a client
runtime environment, devoted to the execution of client-side pages and units.
The client runtime is implemented in OpenLaszlo, an open source RIA platform
allowing both AJAX and Flash deployment, programmable in an object-oriented
language called LZX.9 The architecture of the client is organized as shown in
the left part of Figure 21:
— The Controller is responsible for handling events and for orchestrating the
computation of client-side pages, content, and operation units. The Con-
troller is implemented on top of the built-in controller mechanism of Laszlo,
extended with custom events and reactions to WebML specific events. It is
configurable by means of client-side XML descriptors produced by the We-
bRatio code generator and compiled with the LZX application.
— The Model includes generic LZX libraries for client-side services, configured
with descriptors of the actual pages, content and operation units appearing
in the hypertext model; and client-side state objects, storing the population
of client-side units, encoded in XML.
— The View consists of LZX presentation components produced by WebRatio
and compiled into a Flash application.
Figure 22 represents the process for requesting a client page and for interact-
ing with it. When the browser issues a requests, the server Controller finds in
its configuration file the Action associated with the request and invokes it. The
Action instantiates the proper runtime services to produce the State Objects
that the View component serializes in the response to the browser. The result
page may include client components (e.g., Flash objects), which are requested
by the browser to the Laszlo Presentation Server (LPS) and returned as ex-
ecutable FLASH bytecode. Once instantiated in the browser, a Flash object
can ask server controller to fetch the population of units based on server-side
entities; it can also interact with the LPS, to notify or be notified of events,
9 http://www.openlaszlo.org
Fig. 22. Sequence diagram showing the retrieval of a client page with client components.
and with the browser and other Flash object to exchange data (e.g., to get/set
parameters from/to other client-side components).
7.2.1 Fetching Data from the Server. Client units defined on server-side
entities (as those in Figure 8) need to fetch their population from the server.
Each unit has an associated View component, responsible of rendering its
content. The view is bound, by means of an observer pattern, to a state ob-
ject (Unit Content), implemented as an XML DataSet, which holds the data
displayed by the unit. The unit content can be updated by the Unit Logic com-
ponent, a library class instantiated and configured through an XML descriptor.
The content of the unit is built from the Unit Source dataset: if the unit is
defined on a client-side entity, the Unit Source is the client-side storage for the
entity population (e.g., in-memory XML, or persistent client-side data); if it is
based on a server-side entity, the unit source is the shared dataset holding the
server responses, formatted in XML.
Figure 23 shows the computation steps: the client-side Unit Logic performs
a request to the server; the server-side Unit Logic assembles the proper query
and retrieves server data; these are transmitted back to the client and stored in
the Unit Source; the Unit Logic reads data from its source, applies client-side
selection predicates and ordering clauses, to prepare the Unit Content; when
this is ready, the View is notified, which displays it.
7.2.2 Execution of Operation Sequences. A runtime client page can in-

voke server-side operations, possibly interleaved with client-side operations,
as shown in the example of Figure 7. Figure 24 shows an activity diagram
illustrating the computation cycle for a sequence constituted by two server
operations, delimited by client operations: the initial sequence of client opera-
tions is performed on the client (1); when the first server operation is requested,
Fig. 23. Client/Server interaction for a client unit relying on a server entity.
Fig. 24. Example of a client/server operation chain execution invoked by a client page.
an operation proxy implemented at the client-side is activated, which controls

the execution of all the server-side operations in a batch, to avoid multiple
server invocations (2–3). Then, execution continues with the subsequent client
operations (4).
7.2.3 Event Notification. The extended runtime supports bidirectional

communication with the send event and receive event operations. Client-to-
server communication exploits the usual HTTP request-response cycle, and
thus the send event operation is implemented like any other server oper-
ation. Server-to-client communication, instead, utilizes the persistent con-
nection mechanism offered by most RIA technologies (e.g., Laszlo persistent
connections,10 Flex data services11 ). Persistent connections may either exploit
ad hoc communication protocols and sockets, or use HTTP trickling; in the
latter case, a dedicated HTTP request is made to the server and kept open
so that the server can trickle information back on it, to push an event to the
10 http://www.laszlosystems.com/lps/docs/lzx-developers-guide/persistent connection.html
11 Flex 2 Developer’s Guide, Adobe Inc.
client or just to keep the connection alive. The receive event operation is realized
using the OpenLaszlo implementation of HTTP persistent connections, which
includes an API to send XML messages from the server to all users running an
LZX client application.
Figure 21 shows the components devoted to the management of server to
client communication: the persistent connection between the client and the
server is managed by the LPS; on the client-side, a dataset is dedicated to
receiving messages from the server; each time a message arrives, an event
manager component identifies the client receive event operation in charge of
processing the event and triggers it.
7.3 Server Runtime and Code Generator Extensions

Figure 21 also shows the extensions to the server runtime. The original MVC
components were revised to support the fine-grained HTTP requests needed by
the more flexible client page computation algorithm, which required the addi-
tion of services for executing individual content and operation units. To support
the event model, services were also implemented for setting and retrieving
parameters of events. Finally, the OpenLaszlo’s LPS was integrated to pro-
vide server-to-client communication. A new generator was implemented to pro-
duce the client-side code, including the configurable libraries for client pages,
content units, operations, and links, and the XML configuration descriptors
needed to instantiate them. Also the code generator for the server-side was
extended to output the controller configuration files enabling the fine-grained
invocation of individual content and operation units and the code and configu-
ration files for the send event and receive event units.
8. EXPERIENCE AND EVALUATION

The implementation of the illustrated modeling concepts granted the oppor-
tunity to put RIA conceptual modeling to work in the development of real-
world applications, in order to evaluate the strengths and weaknesses of the
approach.
The evaluation concentrated on three issues, which are fundamental in the
design of a Domain Specific Language:
—Expressive Power: the notation should be able to address the requirements

most frequently encountered in the development of real-world RIAs.
—Ease of use: the notation and development methodology should provide tan-
gible benefits, in terms of learning curve, intuitiveness and communicability
of the specifications, and ease of maintenance.
—Implementability: the conceptual models should be transformable into run-
ning code at least as efficient as the one written by a RIA developer manually;
this entails that the code optimizations that a programmer would put in place
should be embeddable in the code generation process.
8.1 Implemented Applications

The RIA modeling concepts and code generation facilities implemented in
WebRatio have been exploited to build a sophisticated interface for an au-
diovisual search engine, called PHAROS [Debald et al. 2006]. RIA technologies
are employed to optimize the usability of a function-rich interface, which allows
users to pose a variety of queries (keyword, audio similarity, image similarity,
video similarity), to save and refine queries, to receive suggested queries and
content, and more. In particular, the management of queries exploits client
and server entities and operations, to allow the user build a new query starting
from a collection of past queries, and edit the locally saved query collection,
without accessing the server.
A second implemented application is the MetalC document exchange plat-
form,12 a Web-based business process integration system conceived for SMEs
wishing to structure their commercial relationship via the Web. The appli-
cation can be used in a stand-alone manner or connected to the informa-
tion system of the company, and allows the electronic exchange of more than
twenty types of document (invoices, bills of material, requests for quotations,
delivery plans, etc.). The exchanged documents are modeled as server enti-
ties, which can be totally or partially replicated on the client, for a more
ergonomic editing and conversion process. After a document is checked out
and manipulated at the client, it can be delivered to a business partner or
checked in again in the information system. MetalC makes heavy use of client-
side entities, content units and operation units, because document processing
must be performed both online and offline. Also, a push notification mech-
anism is implemented: when a document is submitted to a party, a notifi-
cation event is raised, which is managed asynchronously by all employees
of the partner company in charge of validating or processing the submitted
document.
8.2 Expressive Power

Evaluating the expressive power requires understanding to what extent the
requirements of a typical RIA can be captured in the modeling language, which
is quite a subjective task. To have a more reliable idea of the coverage of
the proposed modeling concepts, we evaluated them with respect to the RIA
functional requirements highlighted in Wright and Dietrich [2008]. Table I
illustrates the results of the evaluation. The requirements listed in Table I
are a subset of the ones identified in Wright and Dietrich [2008], where the
features that are the same in a traditional Web application are omitted; for
each requirement, the Table shows if the requirement is fully supported by the
RIA-extended WebML concepts, is representable using a conjunct of WebML
modeling concepts somehow, or is not expressible.
Requirements 1–5 concern distributed data management. They are all ad-
dressed in the proposed model, which comprises server and client entities, per-
sistent and volatile data, and server and client units defined on client and server
12 www.metalc.it
Table I. Evaluation of Modeling Concepts with Respect to RIA Requirements

N. Requirement [Wright and Fully Represented Expressible Nonexpressible
Dietrich 2008]
1 View data Server and client content
units
2 Update data Server and client operation
units
3 Offline data Client-side persistent data
4 Access server data Client units over server
entities; server
operations
5 Local Variables/Data Client-side (temporary or
persistent) data
6 Scheduled Events Events and their features
7 Client/Server Timer Support Events + hypertext
(synchronization) patterns for
synchronization
8 User Collaboration/Chats Events and their features +
hypertext patterns
9 Asynchronous Form Validation X
10 Client Form Validation Expressible through
client operations
11 Presentation X
12 Client-side Scripting X
13 Drag&Drop Expressible by associ-
ating a single event to
two links
14 Runtime Interface Updates Page computation model
15 Pagination Server and client pages,
possibly nested
data. The increase in expressive power comes at the price of a more verbose
data and hypertext model, where data persistence/location and component dis-
tribution must be mentioned explicitly. Data replication at the client and server
also raises a problem of consistency, since the designer may need to state data
requirements twice (as visible in Figure 6). However, these drawbacks can be
alleviated by state-of-the-practice model management mechanisms adopted in
WebRatio also for traditional Web applications, like wizard-based editing of re-
lated concepts (e.g., the one-click cloning of a server entity into a client entity,
and vice versa), the automatic tracking of model dependencies (e.g., the impact
analysis of a change to entities that exist at both the client and server tier),
and semantic model checking (e.g., to enforce the discussed constraints on the
usage of client pages, components, entities and relationships).
Requirements 6–8 deal with events management, synchronization, and
collaborative applications, which can be supported by means of the send
and receive operations and with suitable hypertext patterns, as shown in
Section 5.1.2. Adding events to the hypertext model increases its complex-
ity and diminishes its readability, since both human-originated events (link
navigation) and system events are mixed in the same diagram. The alterna-
tive would be expressing events in a separate dynamic model (e.g., a UML
StateChart), leaving in the hypertext model only the links that express pa-
rameter passing between components. However, this solution would require
an additional modeling layer on top of the hypertext model, making model
maintenance and code generation significantly more complex.
Wright and Dietrich [2008] propose two specific requirements (9 and 10) for
input validation. The former requires the validation of one field at a time: this
option is not available in WebML, which does not express events on individual
form fields. The latter requires that validation occurs on the client (in addition
to the server side, as in traditional Web applications): in WebML client-side
validation can be expressed by means of client operations.
Requirement 11 is not specifically addressed by our approach (see
Section 8.5 for further details on presentation management); in Wright and
Dietrich [2008] requirement 12 specifies that it should be possible to include
client-side scripting: in our approach client-side scripting involving only pre-
sentation aspects is not captured by our modeling concepts; client-side scripting
incorporating some business logic (e.g., a counter) must be instead modeled by
means of specific model components implementing the desired behavior.
Finally, the last three requirements on presentation aspects and drag&drop
are explained in Section 8.5.
8.3 Ease of Use

Ease of use can be evaluated qualitatively in two ways: comparing model-
driven development of RIAs with their manual coding, and comparing the
model-driven development using a traditional Web Engineering notation with
an extended (and probably more complex) model incorporating RIA features.
The comparison of model-driven and traditional development is a long-
debated issue, which is outside the scope of this paper. However, the observation
can be made that the perceived ease of use of a methodology based on platform-
independent abstractions and code generation increases when technology is
evolving and common standards are lacking. This is the current situation with
RIAs, where cross-platform portability is still problematic and a variety of dif-
ferent languages, tools, and architectures are available for achieving much the
same objectives.
Regarding the comparison with traditional Web Engineering methodologies,
the experience of exposing the RIA extensions of WebML to developers trained
in the original version of the language revealed both positive and negative
aspects. On the positive side, the modeling of client-side data and computation
was considered an extension both intuitive and with substantial added value.
Indeed, the code for implementing client pages and components is very different
from the analogous server-side code, which makes the decision of manually
moving functionality from the client to the server and vice versa very costly.
Instead, modeling the distribution of data and processing and generating the
code makes prototyping alternative allocations attractive and reduces the cost
of reaching the final architecture. Similarly, a positive evaluation was given to
the explicit modeling of events, which naturally integrates with the modeling
of synchronous business component invocation, expressed by operation units,
and of asynchronous Web Service invocation, already present as an extension
of the WebML language supported by WebRatio.
On the negative side, the less satisfactory innovation concerns the page
computation model. Dynamic modeling is one of the most difficult tasks in
model-driven development, and the implicitness of event handling and page
computation in the original version of WebML is one of the main factors that
favors its adoption. Exposing the page computation model, in the form of
explicit sequences of actions on page components, is generally perceived as

confusing, especially in absence of appropriate tools for simulating and debug-
ging the behavior of the page computation algorithm with different sequences of
actions.
8.4 Implementability
Section 7 has illustrated the techniques employed for implementing the ex-
tensions of WebML in the WebRatio IDE, runtime and code generator, which
demonstrated the general feasibility of producing the client and server code
of a RIA from its conceptual model. However, implementability requires also
that the generated code lends itself to be optimized in much the same way as
the manually written code. This goal has been investigated by analyzing the
performance bottlenecks of the generated applications, identifying the needed
improvements, and implementing them in the code generator, and not in the
generated code. In this way, the needed optimizations are embodied in the
forward engineering cycle, the code remains reproducible from the model auto-
matically, and the identified improvements become available to all the modeled
applications.
The following aspects of the generated code have been identified as prob-
lematic, and the solutions for addressing them have been incorporated in the
runtime and code generator:
—Queries on Client Relationships. Performance of client-side queries can be
improved by identifying recurrent query patterns and optimizing their ex-
ecution. For example, in the selected development platform, client data are
encoded in XML data sets. By default, separate data sets are used for entities
and relationships, which makes query over relationships slow, due to XML
navigation, but partitions the overhead symmetrically between the two rela-
tionship navigation directions. When a relationship is preferably accessed in
one direction, it can be marked as nested in the data model, which instructs
the code generator to produce a different implementation of the client data
sets, in which the instances of the enclosing entity physically contain the
instances the enclosed entity. Then, by mapping the relationship to XPATH
axes, queries from the enclosing entity to the enclosed entity are accelerated.
The drawback of this solution is that updates to the relationship instances
become slightly slower. The designer should therefore tailor the data model
to the relationship access paths of the application, which are clearly visible
in the hypertext model.
—Data Transmission. Bulk data transfers from the server are often needed
to populate client-side entities and when client-side content units have a
server-side source entity. The standard computation of a client content unit
with a server source entity consists of: (1) issuing an HTTP request for the
execution of the server-side part of the unit (2) performing the query for
server-side selectors on the server, (3) returning relevant data to the client,
(4) applying client-side selectors on the client (e.g., see Figure 23). However,
there are cases in which pushing condition evaluation to the server is a better
choice, because it reduces the time for transferring data from the server and
for performing selector evaluation at the client. For example, consider the
case of a client content unit (e.g., an index of objects) built by evaluating a
selector condition based on a client relationship between a client entity and a
server entity (for instance, an index of the items preferred by the user, where
the items are stored on the server and the preferences are managed at the
client). The standard process would transfer the whole set of items stored
at the server, which would then be filtered using the user preferences at
the client. This is a classical situation in distributed query execution, which
demands for the execution of as many selection predicates as possible before
the transmission of data. To address this and other similar patterns, the code
generator has been updated so that whenever a client unit with server-entity
has no server-side selectors, client-side selector conditions are pushed to the
server. In the previous example, the OIDs of the items associated to the
current user are sent to the server, so that only the information of relevant
items is returned to the client.
8.5 Presentation Management

A distinctive aspect of the proposed work is the position with respect to pre-
sentation modeling, often considered one of the most distinctive features of
RIAs.
In the extension of WebML, the modeling language does not represent pre-
sentation issues, like the elements for structuring the page layout (e.g., win-
dows, tabbed panes, accordions), the widgets for user’s interaction, and the
visual properties, which in several other proposals are instead captured by a
dedicated presentation model (see Section 9.2 for an overview).
This approach is motivated by the wish to separate the specification of data
and functions from that of presentation, often performed by graphic designers,
and by the preference, manifested by many industrial developers, for coding
presentation features using native languages rather than abstract models. This
principle is followed by the commercial implementation of WebML in WebRatio:
application designers provide the data and hypertext model, whereas look &
feel is defined by graphic designers. To enable the generation of code, blending
the data and functional specifications with the presentation specification is
necessary. This is achieved in the code generator with an approach similar
to Aspect Oriented Computing: presentation is considered as a cross-cutting
concern, to be weaved into the presentation-neutral code of the View produced
by the code generator. To achieve this, each presentation module (e.g., the
look & feel of a set of pages, of links, and of the various classes of content
units) is encoded as a mock-up, directly written by the graphic designer in the
rendition language of choice, and comprises suitable join points (e.g., a place
where a dynamic menu must be injected), that will be filled in by the advice
code produced by the generator. In this way, the graphic designer can exploit
the full power of his preferred rendition platform, and simply specify the points
where the code for dynamic content production will be weaved.
In the proposed implementation, the interface designer can use any widget
or native script, and mark in the program or in the declarative specification the
points where the code associated with the abstract elements of the hypertext
model must be injected. In this way, presentation elements do not surface to
the abstract hypertext model, which remains platform independent, and the
hypertext model specifies the events and dynamic content elements that can
be weaved into the presentation modules.
The illustrated approach works well when the presentation aspects and the
hypertext model are orthogonal. One exception is, for example, drag & drop,
where the presentation aspect (the dragging and dropping of some interface
element) surfaces to the hypertext model, because two interaction events (the
drag and the drop) are necessary to complete the interaction. This has been
solved by the not-so-satisfactory solution of explicitly pairing events and links
in the hypertext model, so to make them denote a single drag & drop composite
action, as required for the presentation.
Specific presentation widgets requiring also the execution of client-side
and/or server-side business logic can be added to the WebML hypertext model,
thanks to the extendibility of the model and code generator of the architec-
ture of WebRatio. Indeed, new business components and code generation rules
can be added to model specific RIA components and to generate the corre-
sponding RIA code. This fosters a component-driven design, where the devel-
oper can add any desired feature to the model/code generator, and then can
reuse such a feature in an unlimited way in all future projects. For example,
fields auto-completion, cascade selections in a form, tooltips and so on, can
be realized by means of specific WebML units and/or specific code generation
rules.
The proposed approach instead does not allow to explicitly capture behaviors
related only to the presentation, like for example, change the layout, the color,
or the font, upon user interaction or upon temporal events.
A different approach to presentation has also been experimented, based on
the integration of a specific RIA presentation model (RUX [Trigueros et al.
2007]) on top of WebML, able to express complex behaviors at the inter-
face level, not captured by the extended hypertext model of WebML (e.g.,
involving temporal events or requiring actions involving only the presenta-
tion features). In RUX, a presentation model is created at three levels (lay-
out, abstract widgets, and concrete widgets) and then bound to the site view
model expressed in WebML. The two models communicate by means of data
sources (the content unit of WebML) and events (navigation and other ex-
plicit events in WebML). A RUX model editor imports the WebML model and
allows the designer to bind it to the RUX presentation model. For details
on RUX the reader my refer to Trigueros et al. [2007] and to the RUX tool
Web site.13
Both approaches to presentation have pros and cons. We plan to
compare them more thoroughly, by monitoring the creation of RIAs
by industrial developers using the available implementations of both
techniques.
13 http://www.homeria.com
9. RELATED WORK
In this section we first give an overview of the most relevant RIA develop-
ment tools and frameworks; then we overview Web Engineering methodolo-
gies dealing with Rich Internet Applications; finally, we briefly show how the
works on data distribution and event-driven systems are complementary to our
proposal.
9.1 Commercial Tools and Frameworks

Several commercial tools for RIA development are available, as vendors
adapted to RIA features their existing solutions for Web and desktop devel-
opment, typically offering WYSIWYG composition of interfaces using widgets
and integrated code editing (like, for example, in Visual Studio,14 Expression,15
FlexBuilder,16 DreamWeaver,17 Eclipse,18 NetBeans19 ).
In most cases, IDEs are used to model the interface and the behavior at
the client-side, leaving the specification and development of the service/server
tier to other tools and methodologies. One notable exception is Microsoft’s new
developer suite (and OS) based on WinFX (Avalon, Indigo), which addresses
client interfaces and behavior and server-side services seamlessly. However, the
focus is on implementation rather than conceptual modeling, and the produced
applications are bound to one specific platform.
An original approach to RIA development is offered by Ruby on Rails,20 an
open source MVC framework for the Ruby programming language, which has
gained wide acceptance among RIA developers, thanks to its tools for automat-
ically constructing the artifacts of a basic Web site and to its tight integration
with popular JavaScript libraries for RIA development. On the methodological
side, Ruby on Rails emphasizes a concise programming style, based on the use of
conventions (e.g., naming conventions), whereby the aspects of the application
to be stated explicitly are reduced substantially. Compared to our approach,
Rails focuses on giving developers better control over the different technical
artifacts and their dependencies, at the source code level. The model-driven
approach advocated in this article, instead, exploits a platform-independent
representation of the application, in which control is gained through ab-
straction, by factoring out of the model the technology-dependent aspects,
which are encapsulated in the development of components and in the code
generator.
Compared to the current tools and frameworks, the approach described in
this paper provides a more high-level and platform-independent perspective,
spanning the software life-cycle from specification to maintenance: the com-
plete behavior of a RIA is specified in the conceptual design phase, and the
14 http://msdn.microsoft.com/en-gb/vstudio/products/default.aspx
15 http://www.microsoft.com/expression
16 http://www.adobe.com/products/flex/features/flex builder
17 http://www.adobe.com/products/dreamweaver
18 http://www.eclipse.org
19 http://www.netbeans.org
20 http://www.rubyonrails.org
code is generated automatically from the application models, addressing com-

putation and data distribution and all the relevant communication patterns,
within a cohesive development environment.
9.2 Web Engineering Methodologies

The approach discussed in this paper is not the only one extending a traditional
Web Engineering methodology to RIAs. In Preciado et al. [2005], a survey shows
the extent to which existing Web Engineering methods and tools support RIA
development.
Considering the proposals preceding the advent of RIA technologies, the
WAE [Conallen 2002] methodology uses UML stereotypes to denote client and
server components of a Web application. While the original idea considered
simple DHTML or script-based clients, it can be used to represent generalized
client-side computation and data, as required by RIAs. However, the limits
of the WAE approach reside in being too close to implementation and in not
providing a clear separation between data and business objects on client and
server tier. Furthermore, WAE does not easily enable automatic code genera-
tion, due to the lack of precise semantics of the methodological concepts. UWE
[Koch and Kraus 2002] extends Conallen’s concept of “client page” in UML de-
ployment diagrams, to specify the distribution of application components. Also
in this proposal, model semantics and code generation for RIA clients are not
addressed.
Zheng and Pong [1992] discuss a system for the generation of client-server
collaborative Web applications from diagrams: although the described imple-
mentation is only server-side and the considered technologies are limited to
Java applets and JavaScript, the generated system architecture adheres to the
major RIA requirements related to client/server distribution.
More recently, several proposals have been advanced addressing different
RIA features.
An extension to the OOH methodology has been proposed in Meliá et al.
[2008] and Pérez et al. [2008]: an orchestration model is introduced to specify
the interaction between the RIA interface widgets and the client and server
layers. A skeleton of the orchestration model, an UML state diagram profile,
can be obtained from the navigation and presentation model of a traditional
Web application; then, interactions between interface widgets (e.g., images,
buttons) and widgets realizing navigation can be defined. An implementa-
tion based on the Google Web Toolkit (GWT) is mentioned. The orchestra-
tion model is quite similar to the dynamic model proposed in this paper, since
both aim at defining the behavior of the application upon the interaction of
the user: the most notable difference is that our approach associates each
interaction (link) with a computation sequence specifying which units (wid-
gets) to recompute or invalidate; conversely, in Meliá et al. [2008] and Pérez
et al. [2008], it is the widget that subscribes to the event representing the
interaction.
In Trigueros et al. [2007] a presentation model (called RUX) is introduced,
which includes an abstract model, representing interface concepts like content
grouping and the binding of abstract interface elements to the domain objects,
and a concrete model, which takes into account the spatial arrangement and
the look & feel for the specific device/platform. RUX is complementary to our
approach, and it could be used to specify the presentation on top of a WebML
model of the RIA application. A similar focus on presentation characterizes
[Martinez-Ruiz et al. 2006], which discusses a model-driven approach based
on the UsiXML interface description language [Limbourg and Vanderdonckt
2004] and applies XSLT to translate an abstract interface into a Final User
Interface.
Urbieta et al. [2007] extend the abstract interface model of OOHDM with
Abstract Data Views (ADVs), to represent the interface objects and their rela-
tionships; the authors do not cover RIA aspects related to data and business
logic distribution, nor communication.
Rossi et al. [2008] ADVcharts are used to evolve a conventional software into
a RIA: only limited changes (called refactorings) are applied to the navigational
or interface structure of the application, so that the enrichment with RIA
presentation features does not confuse users already accustomed to navigate
the application using a conventional interface.
Users’ interaction is the focus also of the extension of the OO-Method dis-
cussed in Valverde and Pastor [2008]: design patterns describing common RIA
interactions are described both at an abstract and at a concrete level. The user’s
actions on the interface may possibly invoke the server, for example to retrieve
data or to execute a service. Examples of widgets considered by the authors
are the auto-completion of words in a text field and the summarization of data.
The work is at a preliminary stage and is not supported yet by tools for code
generation.
In Dolog and Stage [2007] a UML-based notation, called interaction space
model, is used to specify users’ interaction, as a refinement of the task model.
Functional dependencies between the users’ interactions and the user naviga-
tion model expressed in UML-guide [Dolog and Nejdl 2003] can be defined, thus
combining interaction patterns with client-side business logic and supporting
asynchronous communication between the server and the client. This work
therefore considers some aspects of business logic distribution and of commu-
nication, addressed in this article. The work described in this article differs
from the existing extensions of Web Engineering methodologies, in several
respects:
— it is not focused on presentation specification, which is assumed to be lay-

ered on top of the hypertext model; this position descends from the opin-
ion that visual features are more efficiently expressed as mock-ups in the
rendition language of choice (possibly an abstract one) and then weaved
into the code generation process, as done in WebRatio for traditional Web
applications.
— it addresses in an integrated manner a broader set of RIAs features, from
data and computation distribution to the different communication and event
handling patterns available for RIAs, and demonstrates that the resulting
conceptual model can be efficiently implemented as an extension of IDE,
runtime, and code generation technologies already well-proven in the devel-

opment of traditional Web applications.
—it attempts a first evaluation of the RIA model, by providing an analysis of
its implementability, ease of use, and expressive power.
Upon the framework proposed in this article, richer graphical user interfaces
can be defined, by adopting a dedicated presentation model, for example RUX
[Trigueros et al. 2007]; on this line, Preciado et al. [2008] and Comai et al. [2007]
show that RUX can be connected to WebML, and it complements the extensions
proposed in this article with presentation behaviors such as animations, visual
actions on the interface, and so on.
9.3 Data Distribution

Data allocation in distributed system is a well-known topic extensively treated
in the database area [Ceri and Pelagatti 1984; Ozsu and Valduriez 1999]. A
survey on distributed query processing is provided in Kossmann [2000], and
several models exist for distributing data and minimizing various cost criteria
[Apers 1988; Ceri et al. 1989]. Franklin et al. [1996] consider client-server
architectures that can fully exploit client and server resources in a flexible
manner: they propose a hybrid-shipping technique, which can execute queries
at clients, servers, or any combination of the two, and address optimization
issues. Data partitioning and replication between the client and the server have
been studied also in the context of mobile databases [Imielinski and Badrinath
1993; Phatak and Badrinath 1999], where data are downloaded periodically on
the client and can be managed locally.
These works can be considered as a complement to our approach, as they
provide guidelines on how to partition the data between the client and the
server.
9.4 Event-Driven Systems

Event-driven approaches have been thoroughly investigated in active
databases, rule-based systems, adaptive systems, security (e.g., intrusion de-
tection), graphical user interfaces, control systems, and message-oriented mid-
dleware. We addressed two main aspects: expressing reactions to events, and
distributed event notification. Concerning reaction specification, our approach
is close to Event-Condition-Action (ECA) rules of active databases [Paton and
Diaz 1999]. The hypertext model enables the expression of implicit ECA rules:
when an event occurs, conditions may be checked, and actions executed (e.g.,
operations or a page refresh). By designing sequences of operations that react
to events and raise new events, also event composition rules could be specified,
in the spirit of systems like, for example, Ode [Gehani et al. 1992]. Regard-
ing distributed event notification, we have adhered to the general taxonomy of
event notifications of Meier and Cahill [2005] and focused on the specific case
of event notification within a single Web application, where the actors to be
notified are the on-line application users.
10. CONCLUSIONS
This article has presented an evolutionary approach to the Model-Driven En-
gineering of Rich Internet Applications. An existing Web Engineering method
has been extended to represent the most notable features of this novel class
of applications, including the partition of data and computation between the
client and the server, bidirectional and asynchronous communications, gen-
eralized events, and flexible page computation. In most cases, the extension
amounts to allocating the desired functionality in the appropriate tier of the
architecture, and in specifying suitable design patterns for dealing with the
interaction between the tiers: data reconciliation, distributed component exe-
cution, and event notification and handling are examples of how responsibility
can be partitioned in a RIA.
The resulting model has been implemented within a tool suite offering
model editing and code generation functions, and field-tested in the develop-
ment of real-world applications. The most notable benefit experienced thanks
to the incorporation of RIA features is the ability to explore alternative ar-
chitectural patterns in a rapid prototyping cycle, which greatly helps to con-
verge towards the distribution of functionality best suited to the application at
hand.
Future work will progress in several directions: first of all, further experi-
mentation will be pursued on the integration of WebML and RUX, especially
with respect to model complexity, ease of use, and code generation. The current
status of the integration can be seen at the Web site http://www.homeria.com.
Another line of work will extend the model-driven testing environment de-
scribed in Fraternali and Tisi [2009] to support RIA features. The idea is to
express test cases at the conceptual level, using a platform-independent model
of user’s interaction, and then exploit the same code generation technology
used for producing applications for generating platform-dependent test suites,
for example, Selenium scripts or similar specifications. Having a model of the
RIA front-end could support the automatic (re)generation of test scripts after
a change of platform or presentation, since the platform-dependent features of
interaction can be weaved into the test script by the code generator. Finally,
research is ongoing on the use of application models to dynamically adapt a
Rich Internet Application running in a Virtualized Data Center (VDC) to the
changing workload (e.g., flash crowds); this work is driven by the advent of
cloud computing, in which resource overprovisioning is avoided by spawning
virtual machines on demand. Autonomic agents control the number of virtual
machines needed for the application, using a prediction on the workload-mix to
estimate the needed resources: this estimate is derived at staging time using a
black-box approach. Our belief is that a WebML model of the application em-
bodies enough information on functionality distribution across the client and
server tiers to enable a more refined control mechanism. Ultimately, it could
also be possible to keep the model and code generator live at runtime and auto-
matically redeploy application functionality across the tiers (e.g., for new user’s
sessions), based on the actual resource allocation profile of the cloud and on the
access device capability.
ACKNOWLEDGMENTS
We wish to thank Michela Frigerio for the support in implementing the model
extensions and the WebRatio, MetalC, and PHAROS teams for helping in the
experimental and evaluation work.
REFERENCES
ALLAIRE, J. 2002. Macromedia Flash MX-A next-generation rich client. Tech. rep., Macromedia.
APERS, P. M. G. 1988. Data allocation in distributed database systems. ACM Trans. Datab.
Syst. 13, 3, 263–304.
BARESI, L., GARZOTTO, F., AND PAOLINI, P. 2001. Extending UML for modeling Web applications.
In Proceedings of the Hawaii International Conference on System Sciences (HICSS’01). IEEE
Computer Society. 3055.
BECKETT, D. AND MCBRIDE, B. 2004. RDF/XML syntax specification (Revised). W3C Recomm. 10,
2004–02.
BOOCH, G., JACOBSON, I., AND RUMBAUGH, J. 2000. OMG unified modeling language specification.
BOZZON, A., COMAI, S., FRATERNALI, P., AND TOFFETTI CARUGHI, G. 2006a. Capturing RIA concepts
in a web modeling language. In Proceedings of the International World Wide Web Conference
(WWW). ACM, New York, NY, 907–908.
BOZZON, A., COMAI, S., FRATERNALI, P., AND TOFFETTI CARUGHI, G. 2006b. Conceptual modeling and
code generation for Rich Internet Applications. In Proceedings of the International Conference on
Web Engineering (ICWE), D. Wolber, N. Calder, C. Brooks, and A. Ginige, Eds. ACM, New York,
NY, 353–360.
BRAMBILLA, M., COMAI, S., FRATERNALI, P., AND MANOLESCU, I. 2004. Declarative specification of
Web applications exploiting Web services and workflows. In Proceedings of the ACM SIGMOD
International Conference on Management of Data. ACM Press, New York, NY, 909–910.
CERI, S., FRATERNALI, P., BONGIO, A., BRAMBILLA, M., COMAI, S., AND MATERA, M. 2002. Designing
Data-Intensive Web Applications. Morgan Kaufmann Publishers Inc., San Francisco, CA.
CERI, S. AND PELAGATTI, G. 1984. Distributed Databases Principles and Systems. McGraw-Hill,
Inc., New York, NY.
CERI, S., PERNICI, B., AND WIEDERHOLD, G. 1989. Optimization problems and solution methods in
the design of data distribution. Inform. Syst. 14, 3, 261–272.
CHEN, P. P.-S. 1976. The entity-relationship model—toward a unified view of data. ACM Trans.
Datab. Syst. 1, 1, 9–36.
COMAI, S. AND TOFFETTI CARUGHI, G. 2007. A behavioral model for rich internet applications. In
Proceedings of the International Conference on Web Engineering (ICWE). Springer, 364–369.
COMAI, S., TRIGUEROS, M. L., PRECIADO, J. C., AND SANCHEZ-FIGUEROA, F. 2007. Designing rich In-
ternet applications with Web engineering methodologies. In Proceedings of the International
Symposium on Web Service Evolution (WSE). IEEE Computer Society, 23–30.
CONALLEN, J. 2002. Building Web applications with UML 2nd Ed. Addison Wesley, Reading, MA.
DEBALD, S., NEJDL, W., NUCCI, F. S., PAIU, R., AND PLU, M. 2006. PHAROS - Platform for search of
audiovisual resources across online spaces. In Proceedings of the CEUR Workshop on Statistical
Machine Translation SAMT (Posters and Demos). Vol. 233, CEUR-WS.org, RWTH Aachen.
DESHPANDE, Y., MURUGESAN, S., GINIGE, A., HANSEN, S., SCHWABE, D., GAEDKE, M., AND WHITE, B. 2002.
Web engineering. J. Web Engin. 1, 1, 3–17.
DOLOG, P. AND NEJDL, W. 2003. Using UML and XMI for generating adaptive navigation sequences
in Web-based systems. In Proceedings of the International Conference on the Unified Modeling
Language: Modeling Languages and Applications. 205–219.
DOLOG, P. AND STAGE, J. 2007. Designing interaction spaces for rich Internet applications with
UML. In Proceedings of the International Conference on Web Engineering (ICWE). Lecture Notes
in Computer Science, vol. 4607. Springer, 358–363.
FRANKLIN, M. J., JÓNSSON, B. T., AND KOSSMANN, D. 1996. Performance tradeoffs for client-server
query processing. In Proceedings of the ACM SIGMOD International Conference on Management
of Data. ACM Press, New York, NY, 149–160.
FRATERNALI, P. AND TISI, M. 2009. A higher order generative framework for weaving traceabil-
ity links into a code generator for web application testing. In Proceedings of the International
Conference on Web Engineering (ICWE). Springer, 340–354.
GEHANI, N., JAGADISH, H., AND SHMUELI, O. 1992. Composite event specification in active
databases: Model & implementation. In Proceedings of the International Conference on
Very Large Databases (VLDB). Morgan Kaufmann Publishers Inc., San Francisco, CA, 327–
327.
GÓMEZ, J., CACHERO, C., AND PASTOR, O. 2000. Extending a conceptual modelling approach to
Web application design. In Proceedings of the International Conference on Advanced Information
Systems Engineering (CAiSE). Springer-Verlag, 79–93.
IMIELINSKI, T. AND BADRINATH, B. R. 1993. Data management for mobile computing. In Proceedings
of the ACM SIGMOD International Conference on Management of Data. Vol. 22. ACM Press, New
York, NY, 34–39.
KOCH, N. AND KRAUS, A. 2002. The expressive power of UML-based Web engineering. In Proceed-
ings of the International Workshop on Web Oriented Software Technology (IWWOST). Springer
Verlag.
KOSSMANN, D. 2000. The state of the art in distributed query processing. ACM Comput.
Surv. 32, 4, 422–469.
LIMBOURG, Q. AND VANDERDONCKT, J. 2004. USIXML: A user interface description language sup-
porting multiple levels of independence. In Proceedings of the International Conference on Web
Engineering Workshops. Rinton Press, Princeton, NJ, 325–338.
MARTINEZ-RUIZ, F. J., ARTEAGA, J. M., VANDERDONCKT, J., GONZALEZ-CALLEROS, J. M., AND MENDOZA, R.
2006. A first draft of a model-driven method for designing graphical user interfaces of rich
Internet applications. In Proceedings of the Latin American Web Conference (LA-WEB’06). IEEE
Computer Society, 32–38.
MCGUINNESS, D., VAN HARMELEN, F., ET AL. 2004. OWL Web ontology language overview. W3C
Recomm. 10, 2004–03.
MEIER, R. AND CAHILL, V. 2005. Taxonomy of distributed event-based programming systems.
Comput. J. 48, 5, 602–626.
MELIÁ, S. AND GÓMEZ, J. 2006. The WebSA approach: Applying model driven engineering to Web
applications. J. Web Engin. 5, 2, 121–149.
MELIÁ, S., GÓMEZ, J., PÉREZ, S., AND DÍAZ, O. 2008. A model-driven development for GWT-based
rich Internet applications with OOH4RIA. In Proceedings of the International Conference on Web
Engineering (ICWE). IEEE Computer Society, 13–23.
OZSU, M. T. AND VALDURIEZ, P. 1999. Principles of Distributed Database Systems 2nd Ed. Prentice-
Hall, Inc., Upper Saddle River, NJ.
PATON, N. W. AND DIAZ, O. 1999. Active database systems. ACM Comput. Surv. 31, 1, 63–103.
PÉREZ, S., DÍAZ, O., MELIÁ, S., AND GÓMEZ, J. 2008. Facing interaction-rich RIAs: The orchestra-
tion model. In Proceedings of the International Conference on Web Engineering (ICWE). IEEE
Computer Society, 24–37.
PHATAK, S. H. AND BADRINATH, B. R. 1999. Data partitioning for disconnected client server
databases. In Proceedings of the International ACM Workshop on Data Engineering for Wire-
less and Mobile Access (MobiDe). ACM Press, New York, NY, 102–109.
PRECIADO, J. C., LINAJE, M., SANCHEZ, F., AND COMAI, S. 2005. Necessity of methodologies to model
rich internet applications. In Proceedings of the International Symposium on Web Service Evo-
lution (WSE). IEEE Comp. Soc., 7–13.
PRECIADO, J. C., TRIGUEROS, M. L., AND SÁNCHEZ-FIGUEROA, F. 2008. Enriching model-based Web
applications presentation. J. Web Engin. 7, 3, 239–256.
ROSSI, G., URBIETA, M., GINZBURG, J., DISTANTE, D., AND GARRIDO, A. 2008. Refactoring to rich
Internet applications. A model-driven approach. In Proceedings of the International Conference
on Web Engineering (ICWE). IEEE Computer Society, 1–12.
SCHWABE, D., ROSSI, G., AND BARBOSA, S. D. J. 1996. Systematic hypermedia application design with
oohdm. In Proceedings of the ACM Conference on Hypertext and Hypermedia (HYPERTEXT’96).
ACM, New York, NY, 116–128.
TOFFETTI CARUGHI, G., COMAI, S., BOZZON, A., AND FRATERNALI, P. 2007. Modeling distributed events
in data-intensive rich Internet applications. In Proceedings of the International Conference on
Web Information Systems Engineering (WISE). Lecture Notes in Computer Science, vol. 4831.
Springer, 593.
TRIGUEROS, M. L., PRECIADO, J. C., AND SÁNCHEZ-FIGUEROA, F. 2007. Engineering rich Internet
application user interfaces over legacy Web models. IEEE Intern. Comput. 11, 6, 53–59.
URBIETA, M., ROSSI, G., GINZBURG, J., AND SCHWABE, D. 2007. Designing the interface of rich Internet
applications. In Proceedings of the Latin American Web Conference (LA-WEB). IEEE Computer
Society, 144–153.
VALVERDE, F. AND PASTOR, O. 2008. Applying interaction patterns: Towards a model-driven ap-
proach for rich internet applications development. In Proceedings of the International Work-
shop on Web Oriented Software Technology (IWWOST). CEUR Workshop. CEUR-WS.org, RWTH
Aachen, 13–18.
VDOVJAK, R., FRASINCAR, F., HOUBEN, G., AND BARNA, P. 2003. Engineering semantic Web informa-
tion systems in Hera. J. Web Engin. 2, 1–2, 3–26.
WIMMER, M., SCHAUERHUBER, A., SCHWINGER, W., AND KARGL, H. 2007. On the integration of Web
modeling languages: Preliminary results and future challenges. In Proceedings of the Model-
Driven Web Engineering Workshop (MDWE’07). CEUR Workshop vol. 261. CEUR-WS.org, RWTH
Aachen.
WRIGHT, J. M. AND DIETRICH, J. B. 2008. Requirements for rich Internet application design method-
ologies. In Proceedings of the International Conference on Web Information Systems Engineering
(WISE). Springer-Verlag, 106–119.
ZHENG, Y. AND PONG, M.-C. 1992. Using statecharts to model hypertext. In ECHT ’92. ACM, New
York, NY, 242–250.
Received February 2009; revised July 2009; accepted December 2009
View publication stats

Engineering Rich Internet Applications With A Model-Driven Approach

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Engineering Rich Internet Applications With A Model-Driven Approach

Caricato da

Copyright:

Formati disponibili

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Engineering Rich Internet Applications with a Model-Driven Approach

Article in ACM Transactions on the Web · April 2010

Piero Fraternali Sara Comai

SEE PROFILE SEE PROFILE

Alessandro Bozzon Giovanni Toffetti

SEE PROFILE SEE PROFILE

IFML - Interaction Flow Modeling Language View project

Cloud Native applications - Self-managing microservices View project

The user has requested enhancement of the downloaded file.

1.1 Rich Internet Applications: A Change of Architecture

Fig. 1. A rich internet application architecture.

downloadable from the Web and interpreted in a specific runtime environment,

1.2 Context and Problem Statement

fundamental implementation technologies, in the narrow focus of current de-

1.3 Approach and Original Contributions

(6) An evaluation of the experience in terms of the ease of use, expressive

2. WEB ENGINEERING MODELS AND NEW REQUIREMENTS

The front-end of the application is represented by means of the hypertext

2.1 An Example of DSL for the Web: WebML

Fig. 2. The data model of the running example (initial version).

Pages contain content units, representing static content (e.g., a form) or

HomePage H MyAccomodations MyFlights

SearchFlights L ViewFlight MyTrips L

Fig. 3. Example of hypertext model for a traditional Web application.

MyTrips Simplified State Machine in absence of failures

C1Disabled C2Disabled C3Disabled

C1Enabled C2Enabled C3Enabled

Fig. 4. Example of dynamic model.

— the action ComputeParametersPassing(C1) is fired, which determines the

2.2 Requirements for RIA-Aware Conceptual Modeling

—Communication: In HTTP-based Web applications, communication is

3. MODELING DISTRIBUTED DATA

3.1 Model Extensions

S Persistent Server Entity C Persistent Client Entity

S Temporary Server Entity C Temporary Client Entity

Fig. 5. Data modeling notation.

If no duration and location are specified for an entity, persistent server-side

3.2 Running Case

4. MODELING DISTRIBUTED COMPUTATION

Fig. 6. Data model with persistent client and server Entities/Relationships.

In designing a RIA application, a relevant decision is how to partition the

4.1 Model Extensions

4.2 Client-Side Application Containers

Fig. 7. Page structure of the RIA version of the case study.

In the WebML notation, to distinguish server and client pages, we mark

4.2.1 Running Example. The specification of the Trip Planner (Figure 3)

4.3 Distribution of Component Execution

4.3.1 Running Example. To exemplify the distribution of computation, the

Fig. 8. Refinement of the hypertext model of Figure 7: flight search functionality.

Create Flight ConnectToTrip

attribute values Flight C FlightSelection C

apply to client-side, persistent entities and relationships (denoted by the filled

stored at the client is exported6 (ExportTripPlan unit), the payment is settled

5.1 Model Extension

Because RIAs enable collaborative work and bidirectional messaging, they

5.1.1.1 Running Example. To illustrate event handling, the Trip Planner

{followed if event was Predefined output parameters:

Rec (flight change) Check

Find Party Selected Flights TripId Current Trip ...

FlightReservation S Flight S Hotel S

Fig. 16. Collaborative Trip Planner: recipient-based filtering pattern.

Flight Update User [status == ‘online’] Profile [Flight meets profile?]