Conceptual Modeling and Code Generation for Rich

Internet Applications
Alessandro Bozzon
alessandro.bozzon@polimi.it
Piero Fraternali
piero.fraternali@polimi.it

Sara Comai
sara.comai@polimi.it
Giovanni Toffetti Carughi
giovanni.toffetti@polimi.it

Dipartimento di Elettronica e Informazione Politecnico di Milano

P.zza L. da Vinci, 32 I-20133 Milano, Italy

ABSTRACT
This paper addresses conceptual modeling and automatic
code generation for Rich Internet Applications, a variant of
Web-based systems bridging desktop and thin-client Web
interfaces. We show how classical Web modeling concepts
are not enough to capture the specificity of RIAs, extend an
existing Web modeling language, and provide an implementation of a CASE tool for visual modeling and code generation from RIA-aware specifications. Experimentation of the
proposed approach in real-world scenarios is also reported.
Categories and Subject Descriptors: D.2.2 [Software
Engineering]: Design Tools and Techniques, computer-aided
software engineering (CASE), evolutionary prototyping, user
interfaces, H.4.0 [Information Systems Applications]: General, H.5.4 [Information Interfaces and Presentation]: Hypertext / Hypermedia architectures, navigation, theory, user
issues
General Terms: Design.
Keywords: Rich Internet Applications, Web Engineering,
Web Site Design.

1.

INTRODUCTION AND MOTIVATION

In the last years the Web has become the reference platform for the development of all sorts of integrated business
solutions. Due to the increasing complexity of these applications, current Web technologies are starting to show
usability and interactivity limits. The user experience in
thin-client Web applications is not comparable to desktop
interfaces, responsiveness is lower due to network overhead
and unnecessary round-trip server access, and disconnected
usage is not supported [6].
Rich Internet Applications (RIAs) have been recently proposed as the response to the abovementioned drawbacks [7].
They provide sophisticated interfaces for representing complex processes and data, while minimizing client-server data
transfers and moving the interaction and presentation layers from the server to the client. However, RIAs lack development methodologies and CASE tools catering for their
specificity, notwithstanding the number of existing methodCopyright is held by the author/owner(s).
ICWE06, July 11-14, 2006, Palo Alto, California, USA.
ACM 1-59593-352-2/06/0007.

ologies and tools for Web and Hypermedia development [8],

which allow one to specify the application at an abstract
level and derive the implementation code (semi-) automatically.
In this paper we consider the WebML modeling language [4]
and extend it with the aim of reducing the gap between Web
development methodologies and the RIA paradigm, leveraging the common characteristics of RIAs and traditional
Web applications. Our focus is to enable an evolutionary
approach, whereby background knowledge acquired in the
use of Web models is put to work to meet RIA requirements. The contribution of the paper is twofold: 1) a revision of the concepts of a Web model to make them applicable to RIAs; the core problem is how to capture the split of
functionality and data between the Web client and server,
which is the major innovation of RIAs. 2) A validation-byimplementation of the proposed model extensions. We have
extended a commercial CASE tool for traditional Web application modelling and generation with novel runtime components and code generation rules able to produce a running
RIA from the extended conceptual model.
These two contributions go beyond the state of the practice in the field. Pre-Web development tools for desktop
and client server applications were essentially form editors,
with (obviously) no provisions for hypertext interfaces. Midgeneration approaches (e.g., Oracle Designer 2000) targeted
both the Web and client/server architectures, but addressed
only a very limited set of features (e.g., fixed topology hypertexts, like master-details and record set browsing). Modern
RIA development tools, instead, are low-level, technologybound, and code-oriented, with no provision for platform
independent modelling and code generation. The proposed
approach is a first step towards the full integration of RIA
and Web development: with the implemented architecture
we were able to develop, using a single tool and approach, a
complex Web application mixing HTTP+HTML interfaces,
RIA interfaces and Web Services (see Section 7).
We underline that the issues treated in the paper have a
general validity not confined to the use of WebML as a specification language; most existing Web design methodologies
could be extended to RIA support in a similar way.
The paper is organized as follows: after an introduction to
RIA features in Section 2, Section 3 presents related work
in the RIA and Web engineering field. Section 4 illustrates
a case study used throughout the paper, while Section 5

reviews the main characteristics of the WebML language

for the design of traditional applications. Then, Section 6
introduces the main extensions needed to specify RIA applications at a conceptual level, and suggests some useful
guidelines for these applications. Section 7 describes the
implementation of the prototype for generating RIAs from
the conceptual specification, and, finally, in Section 8 conclusions are drawn and future work is presented.

2.

OVERVIEW OF RIA TECHNOLOGIES

The term Rich Internet Application was introduced in

a Macromedia whitepaper [3] by Jeremy Allaire in March
2002, to denote a unification of traditional desktop and Web
applications, aimed at leveraging the advantages and overcoming the drawbacks of both architectures.
Figure 1 compares the features of desktop (including clientserver) and conventional HTML+HTTP Web applications,
highlighting the potential of RIAs, which rely on a Web
distribution model, offer improved interfaces, and reduce
communication overhead. These benefits are relevant for
a variety of tasks, like data sorting, filtering, complex visual
rendering, etc. Typically, a RIA is loaded by the client along
with some initial data, then it manages data rendering and
event processing, communicating with the server only when
the user requires further information or must submit data.
Many sample applications are available on the internet [1].
Several technologies have been proposed to support RIA development. Although different in many aspects, they can
be classified into four broad categories: 1) Scripting-based
in which the client side logic is implemented via scripting
languages, such as JavaScript, and interfaces are based on
a combination of HTML and CSS; 2) Plugin-based, where
advanced rendering and event processing are granted by
browsers plugins interpreting XML, general-purpose programs or media files (Flash, Flex, Laszlo, Xamlon); 3) Browser-based, where rich interaction is natively supported by
some browsers that interpret declarative interface definition languages (XUL); 4) Web-based desktop technologies in
which applications are downloaded from the Web but executed outside the browser (Java Web Start, Window Smart
Client).
A common set of features can be considered as characterizing the RIA approach, for the purpose of conceptual modelling and code generation: a) RIAs should support clientside processing and reduce communication with the server to
the minimum; b) the data supporting the applications could
be stored with different persistence levels, both at the client
and server-side; c) data processing (e.g., creating, modifying, filtering data) could occur both at the client and serverside; d) both online and offline use should be possible.
Further requirements concern the support of sophisticated
interface behaviors, like drag&drop, animations, multimedia
synchronization, and server-to-client communication. These
topics are outside the scope of this paper, but are part of
the ongoing work, summarized in Section 8.

3.

RELATED WORK

Research companies such as IDC and Gartner had foreseen the advent of Rich Internet Applications already in
2003 (see e.g., [7]) while industrial trends confirm the growth
of their acceptance among developers [12]. Tool vendors
have adapted to RIA requirements their existing solutions

Feature

C/S,
Desktop

Web

RIA

Universal client (browser)

Client installation
Interaction capabilities
Server-side business logic
Client-side business logic
Full page refresh required
Frequent server round-trips
Server-to-client communication
Disconnected functioning

NO
Complex
Rich
YES
YES
NO
NO
YES
YES

YES
Simple
Limited
YES
Limited
YES
YES
NO
NO

YES
Simple
Rich
YES
YES
NO
NO
YES
YES

Figure 1: Comparison of Desktop, Web applications,

and RIAs
for Web development, typically offering WYSIWYG composition of interfaces using widgets and code editing (Visual
Studio, Ide4Laszlo, FlexBuilder). In most cases, IDEs are
used to model the interface and the behavior on the clientside, leaving the specification and development of the service
/ server tier to other tools and methodologies. This practice
induces a fracture in the development of the whole application causing different processes to be misaligned. Considering Web engineering methodologies, WAE [5] uses different
stereotypes to denote components running on the client and
on the server. While the original idea referred to either simple DHTML or thick clients, it can be used to represent
generalized client-side computation and data, as required
by RIAs. However, WAE is too close to implementation,
does not provide a clear separation between data and business objects on client and server tier, and does not easily
enable automatic code generation, due to the lack of precise semantics of the methodological concepts. UWE [9]
extends Conallens concept of client page in UML deployment diagrams, to specify the distribution of application
components, but presently does not address model semantics and code generation for RIA clients. In [15] the authors
discuss a system for the generation of client-server collaborative Web applications from diagrams: although the described implementation 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. The need of modelling techniques for RIAs is
advocated in [13], where the authors analyze current Web
modeling approaches as well as hypermedia methodologies
with respect to RIA development needs.

4.

CASE STUDY

We introduce an example, based on the Amazon Store

demo application by Laszlo Systems [1]; the running example is built upon the Amazon Music Store repository, and
offers functionalities for exploring and buying CDs. When
the user accesses the application for the first time, he obtains a list of suggested CDs, chosen by the service provider
(the same list is presented to all users). Then, the user
may refine the search using different attributes, e.g., title
and price. By selecting one CD, the application displays detailed information, including tracks, editorial, or customers
reviews. Users can administer personal data, such as their
wish list and the data about payment, shipping method,
and address, which can be permanently stored into a database. The user can also fill in a shopping cart, picking up

Dimension

Traditional Web
RIA modeling
Modeling
Data Modeling
Constructs
E-R, UML class diaE-R, UML class diagrams
grams
Persistence
server
(database,
server (database, session),
levels
session)
client
Relationship server
server, client, inter-layer
types
Hypertext Modeling in the large
Constructs
site views, areas,
site views, areas, pages
pages
Page types
server pages
server and client pages
Hypertext Modeling in the small
Constructs
server content units,
server and client content
server operations
units and operations
Selector
server-side
server and client-side
Ordering
server-side
server and client-side

Figure 2: Architecture of the case study

CDs from the main list. The shopping cart is kept at the
client side; it can be transformed into a purchase order or
discarded at the end of the session. As illustrated in Figure
2, the user interface of the case study runs at the client for
most of the functionalities, and the server is invoked only
for fetching CD information, requesting or saving the wish
list, and checking out the shopping cart into an order.

5.

OVERVIEW OF WEBML

WebML allows specifying at the conceptual level a Web

application publishing or manipulating data. Content is
modeled using Entity-Relationship (E-R) or UML class diagrams. Upon the same data model, it is possible to define
different hypertexts (called site views), targeted to different
types of users or to different access devices. A site view
is a graph of pages, possibly clustered into areas dealing
with a homogeneous subject (e.g., the Amazon Web Store
includes a book area, a music area, and so on) and hierarchically organized into sub-pages. Pages comprise content
units, representing components for content publishing: the
content displayed in 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
to be published. Instances selected for display can be sorted
according to ordering clauses. Units are connected to each
other through links, which carry parameters and allow the
user to navigate the hypertext.
WebML also allows specifying operations implementing arbitrary business logic; in particular, a set of data update operations is predefined, whereby one can create/delete/modify
the instances of an entity, and create or delete the instances
of a relationship.
Throughout the paper we will provide examples of WebML.
A complete illustration of the language can be found in [4].

6.

CONCEPTUAL MODELING FOR RIAS

In this section, we extend a conceptual model conceived

for traditional data-intensive Web applications to support
RIA features, in order to reuse well-proven code generation
tools and implementation architectures. Figure 3 summarizes the affected modeling issues, organized according to the
typical layers of a Web conceptual model: data modeling,
hypertext modeling in the large, and hypertext modeling in
the small.

6.1

Data modeling

In traditional data-intensive Web applications content resides solely at the server-side, either in the form of database
tuples or of main memory objects contained in server-side

Figure 3: Affected Modeling Dimensions

user sessions. In RIAs, content can also reside in the client,

as main memory objects with the same visibility and duration of the client application, or, in some technologies,
as persistent client-side objects. Data are therefore characterized by two different dimensions: the architectural tier
of existence, which can be the server or the client, and
the level of persistence, which can be permanent or temporary. For space reasons, in the sequel we will only focus
on server-side permanent storage1 and on client-side temporary storage, which are supported by all RIA technologies.
However, most of the considerations discussed in the paper
remain valid also when temporary server data and persistent
client data are considered. A data model for RIAs must be
able to capture the existence of client-side objects and their
association with server-side objects. This can be done by
marking entities and relationships with the following persistence levels 2 : a)Database: data are permanently stored
in a server-side data management system (e.g., a relational
or XML database); b)Client: data are temporarily stored at
the client side, for the duration of the application run. Modeling data over multiple tiers and with different persistence
levels raises classical problems of data distribution and management [11]. In principle, a conceptual data model should
abstract from the physical location of content and be unaffected by its persistence. In practice, these aspects affect the
implementability and efficiency of the model and therefore
must be taken into account, by associating entities to the
most appropriate persistence level and establishing suitable
relationships between entities possibly residing on different
tiers and with different durations.
For the data schema to be well-formed, the following general
constraint must hold: A relationship R with database persistence must connect entities with database persistence only.
In other words, it is not possible for an entity having client
persistence to participate to a database persistent relationship. Note that the converse is admissible: a relationship
with client persistence may connect database persistent entities (as an example, consider the case of a closed-answer
questionnaire: questions and answers are stored persistently
in the database, and the client application may create a temporary relationship between a question and the answer cho1

The modeling of session objects is treated in [10].

With abuse of terminology, we use the term persistence
level to denote also the tier where data resides.
2

Credit Card
OID
Expire Date
Number

User

Shipping Address
1:1

OID

1:1

1:N

1:N Email

Password
Username

1:N

OID
Address

1:N

0:N

1:1

Wish Item

0:N

Shipping Method
OID
Name
Cost

1:1

1:1

1:1

Order

1:1

Review

1:1

Customer
OID

1:1

CD
0:N OID
Artist
Label
/Track-number
Price
Review Release Date
Title

Order Item

1:1

0:N

1:1 OID
Total

OID
Text

OID
/CDTitle

OID
C

0:N
0:N
1:N

/CDTitle
1:1

OID
Rate
Title

1:1

Track
Recommended CD
OID

Cart Item

OID
/CDTitle
0:N

1:1

Editorial Review

Wish Item

1:1 OID

0:N

OID
Position
Title

Cart

OID
/Total
/Item-number

Figure 4: Data model with persistence specification

sen by the user and store it in the database only when the
user confirms all answers). Relationships connecting entities
belonging to different persistence levels are called inter-layer
and must be stored at the layer with shorter duration. For
example, if the shopping cart items are stored with client
persistence to be updated locally and refer to CDs stored in
the database, the relationship between cart items and CDs
must be stored with client persistence, so that relationship
instances be automatically eliminated when the application
terminates, unless the user explicitly decides to save them
(e.g., by confirming the order).
The data model of the case study. Figure 4 shows the
data model of the case study, with persistence specifications.
Client-side entities and relationships are marked with a C,
whereas inter-layer relationships are inferred from the persistence level of the involved entities (one client-side and one
server-side). The following design decisions have been taken:
a) the User, ShippingAddress, ShippingMethod, Order, and
CreditCard entities are given database persistence, because
users must register permanently before issuing orders. Similarly, the CD, Review, and Track entities (and their IS-A
descendants) are stored in the database; b) the shopping
cart and the wish list must be created and/or manipulated
at the client side; therefore, the entities Cart, CartItem, and
WishItem are given client persistence; c) the client entities
CartItem and WishItem are connected by an inter-layer relationship to the database entity CD, to enable looking up
the full details of the CD stored in the database; d) the user
may decide to save permanently his wish list and make it
available to other users. Therefore, entity WishItem is duplicated with database persistence.
The choice of separating the client and database WishItem
entities privileges the applications usability, because the
user will be able to create and modify the wish list at the
client side, without invoking the server at each update. Conversely, the client entity Cart is not replicated on the server,
because it lives only at the client. Instances of the client
entity CartItem become instances of the server entity OrderItem, after check out.
Data modeling guidelines. The data model for RIAs
blends pure data requirements with design choices aimed at
improving usability and/or performance, inferred from the

functional requirements. The following guidelines apply: a)

if an entity represents content shared among multiple users
and accessed in multiple application runs, it must have database persistence; b) if an entity represents temporary content owned by the individual user or primarily originated
and manipulated at the client side, it must have client persistence; c) if client-originated content may be saved permanently at the end of a usage session, a separate database
entity can be used for storing the saved copy (however, the
application will need to explicitly manage the bulk transfer
of content from client to server); d) if database content is
fetched at the client-side and manipulated in complex ways
(e.g., as in record-set editing), it is better to introduce a separate client entity and explicitly manage the bulk transfer
of content from server to client, and viceversa.
The choice of replicating server data on the client must
consider the trade-off between the amount of data to be
transferred and the complexity of operations executed at
the client. Section 6.4 further elaborates on this issue. Data
tuning for optimal performance could take into account also
traditional methods and techniques, as in [14].

6.2

Hypertext modeling in the large.

Hypertext modeling in the large specifies the general structure of the front-end: it associates site views to user groups
and organizes each site view into areas that aggregate pages
with a homogeneous purpose. Pages may be complex and organized in a hierarchical structure composed of nested pages.
From the technological standpoint RIAs have a different
physical structure than traditional data-intensive Web applications: the former typically consist of a single application
shell (e.g., a Java applet or a FLASH movie), which loads
different data and components based on the users interaction. The latter consist of multiple independent templates,
processed by the server and simply rendered by the client.
However, the hypertext modeling metaphor remains a good
description of the dynamics of the interface also for RIAs,
especially in the case of hybrid applications, which comprise
a mix of traditional page templates and RIA components.
The notion of page must be extended, to cope with the specificity of RIAs. Intuitively, pages, or fragments thereof, can
be produced either at the server-side or at the client-side.
The conceptual model must express this difference, because,
as we will see in the next subsections, the content and operations that can be associated with a page may depend on
the type of page.
The following concepts capture the two types of pages found
in RIAs and their organization.
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. Events
are processed at server-side3 .
Client pages: they represent pages incorporating content or
logics managed (at least in part) by the client. Their content
can be computed at the server or client side, whereas presentation, rendering and event handling occur at the client
side. Events can be processed locally at the client or dispatched to the server.
Page AND-OR tree: represents the nesting of (client/ server)
sub-pages within pages. AND-siblings are computed in one
shot and normally displayed together, whereas OR-siblings
3
Here by event we mean the triggering of some business
logic, not a presentation event like a mouse over effect.

C CdStore Demo
CDDetails
Alternative Main Page
Search

Shopping
Cart

CDInfo
Recommended
Cds

Wish List

Alternate Details
Editorial
Review

Tracks

Customer
Reviews

CheckOut
Alternative CheckOut
Shipping Address
Alternative Address
Shipping Edit
Address Shipping
Address

Payment Method
New
Address

Alternative Payment
Payment Edit
Payment
Method
Method

New
Method

Shipping
Method

Complete
Order

Figure 5: Hypertext model in the large

Figure 6: Rendition of the page modeled in Figure 5
are always displayed in alternative and computed only when
requested for (re)display. By default, a sub-page inherits its
type (server or client) from its parent page.
Page AND-OR trees may contain any combination of server
and client pages: 1) server sub-pages contained within a
client page can be generated by the server and rendered by
the client; 2) client sub-pages nested inside a server page
can be considered as independent client applications.
Hypertext model in the large of the case study.
Figure 5 shows the hypertext model in the large of the case
study. Graphically, pages are denoted with rectangles, and
marked with an uppercase C if they are client4 . The meaning of the example is best appreciated by comparing the
model with the implemented Amazon Store application visible at the address [1] (a snapshot of which appears in Figure 6). The model consists of a topmost client page (CD
Store Demo), including five AND sub-pages, which are simultaneously accessible: page Search, for searching CDs,
page WishList and ShoppingCart for displaying the content
of the wish list and shopping cart, page CheckOut for performing the check out process, and page CDDetails, a composite page for displaying either the list of preferred CDs
(sub-page RecommendedCds) or the various details of a specific CD (sub-page CDInfo); note that OR sub-pages are
contained in a grey box. Page CDInfo is itself a composite
one: it alternatively displays the Tracks, EditorialReview or
CustomerReview sub-pages. Similarly, the CheckOut page
has a complex nested structure, whereby the user can fill in
his details and confirm the order.
Figure 6 shows a snapshot of the page modeled in Figure 5,
highlighting the sub-pages Search (1), CDDetails (2), ShoppingCart (3), WishList (4) and CheckOut (5). Note that the
Search, CheckOut, WishList and ShoppingCart sub-pages
can be open simultaneously together with either the recommended CDs list or the details of a single CD, as precisely
expressed by the AND-OR page nesting of Figure 5.
Guidelines for hypertext modeling in the large. As
exemplified by Figure 5, hypertext design assumes a different flavor with respect to conventional Web applications,
which typically consist of a collection of flat independent pages. The structure of a RIA interface consists of
a topmost page partitioned into peer-level AND sub-pages,
which should implement frequently accessed content and services or logically consecutive steps of a workflow; in some
4

WAE [5] also distinguish client and server pages. However,

we introduce client pages only in those cases where clientside content or business logic is involved.

cases, first-level sub-pages could represent loosely related,

but equally important, pieces of content or services (e.g., in
a portal or dashboard application). In the example of Figure 5, the topmost page contains five first-level sub-pages.
The Search and the CDDetails pages jointly implement a
well-defined navigation process, because the former is used
to fill the content of the latter. Pages ShoppingCart and
CheckOut represent two distinct steps of a workflow. Finally, page WishList implements an independent, but frequently used, task. With this organization, the user can
visualize at the same time all the main tasks to be performed. When a page contains complex content or serves a
structured process, it should be decomposed using sub-pages
nested at a lower level: the sub-pages should implement subordinate content or sub-tasks, presented only after accessing
some top-level content or superior step of the process. In the
example of Figure 5, the CDDetails page contains three subordinate sub-pages displaying the editorial review, the CD
tracks, and the customer reviews, which are a refinement
of the main content of the CDDetails page. Similarly, the
CheckOut page is substructured into a number of sub-pages,
mirroring the check out process sub-tasks.

6.3

Page content modeling

Hypertext modeling in the small refines the coarse model

of the application with details about the content of pages,
the links for users interaction, and the operations triggered
by the user. In this section, we discuss page content modeling, postponing operations to the next one.
The content of pages in WebML is represented as a graph of
content units connected by links. Units extract their content
from an entity, possibly filter it through selector conditions
and sort it according to an ordering clause. Links express
both parameter passing, needed for computing the data of
parametric units, and users interaction, needed for requesting page (re)computation.
In traditional Web applications, content unit processing occurs at the server: data reside in the database and selector
conditions and ordering clauses are applied server-side. In
RIAs, computation is distributed between the server and
the client, according to the page type: units contained in a
server page are computed by the server, like in traditional
Web applications, and units contained in a client page are
managed by the client. The type of a content unit can be
implicitly derived by the type of the page containing it: 1) a
unit contained in a server page is defined as server unit; 2)

C
Search CD From
Catalog

CDList
K: string

Price Filter
Min: float
Max: float

Min
Max

[Title contains K] [

CD
Price >= Min] [

Price <= Max]

Figure 7: An example of layered selector conditions

a unit contained in a client page is defined as a client unit.

A client unit can have the following functionalities, which
are not available for server units: 1) publish content drawn
from an entity with client persistence; 2) have client-side selector conditions, used to filter the instances to be displayed
based on a predicate computed by the client without invoking the server; 3) have a client-side ordering clause, used to
sort the instances to be displayed based on a criterion computed by the client without invoking the server.
For a unit to be computable, the following constraints must
hold: a) server units cannot be specified on an entity with
client persistence and cannot comprise client-side selectors
and ordering clauses; b) a client unit that draws content
from an entity with client persistence, cannot contain serverside selector conditions and ordering clauses. These constraints ensure that all the computations performed by the
server rely only on data and operations computable at the
server-side and thus cope with the asymmetric nature of the
Web, where the client calls the server and not vice versa.
Page content modeling in the case study. We exemplify the use of client units by means of an example extending the search function of the Amazon Store site [1]. We
model a Search page behaving as follows: the user can enter
a keyword to be matched in the title of CDs for retrieving
from the database an initial album list; then, the retrieved
instances can be filtered by means of two conditions (price
between a minimum and a maximum). Such filtering must
occur at the client, without recomputing the list of albums
fetched from the server. Figure 7 shows the detailed model
of the Search page and Figure 8 shows its rendition. The
Search page contains two entry units: Search CD From Catalog (1) accepts a keyword to be matched in the CD title;
PriceFilter (3) accepts the value of the minimum and maximum price. Both entry units are linked to the CDList index unit (2), defined over the database entity CD, and their
outgoing links are associated with parameters coupling the
values input by the user to the respective parametric conditions of the index unit (e.g., parameter K: string matches
the homonymous parameter of the selector condition [Title
contains K]). The selector conditions [price >= Min] and
[price <= Max] are marked as client-side (graphically denoted with a C icon), whereas Title contains K is executed at the server (by default). As a consequence of such
design, when the user navigates the outgoing link of the
SearchCDFromCatalog unit a server selector condition must
be evaluated, which implies a round-trip to the server and
the re-computation of the index content; conversely, when
the user navigates the outgoing link of the PriceFilter unit,
a client selector condition must be evaluated, which filters
the instances locally at the client.

Figure 8: Rendering of the Search page of Fig. 7

Content unit modeling guidelines. As for pages, content unit specification has a different flavor in traditional
Web applications and RIAs. The following guidelines apply
in the RIA context: 1) When a unit draws content from a
server entity, the type of selector conditions must be decided
by trading-off between efficiency and usability. Pushing selection to the server reduces the data transmitted to the
client, but slows down refined filtering due to server roundtrip. Selection on the client ensures smoother filtering at
the price of initial data loading overhead. Mixed selectors
(like those exemplified in Figure 7) can be used to reach
the optimal balance. 2) When data are naturally sorted
in only one way, evaluating ordering clauses at the server
improves efficiency. When data admit alternative sorting
criteria, equally meaningful to the user, then multiple ordering clauses should be used, delegating to the server the
most frequently used one.

6.4

Operation modeling

WebML operations model arbitrary business logic and

predefined content updates (creating, deleting or modifying
entities, connecting or disconnecting pairs of entities belonging to relationships). In the RIA context, operations can be
executed by the client or by the server, as captured by the
following definitions: 1) server operation: a piece of business
logic or data update executed by the server; 2) client operation: a piece of business logic executed by the client or an
update on a client-side entity or relationship; 3) operation
chain: a sequence of operations, possibly mixing client and
server operations.
Operation modeling in the case study. Figure 9
shows a hypertext fragment for inserting the currently visualized CD item into the shopping cart. Page CDDetails
contains a data unit showing the details of the currently
visualized album; the outgoing link of the unit triggers a
sequence of two operations, represented outside the page:
CreateItem creates a new instance of the client entity CartItem and ConnectToCd associates such instance to the current CD, creating an instance of the inter-layer relationship
between entities CD and CartItem. Note that both operations are marked as client-side with a C icon and thus the
execution of the operation chain takes place entirely on the
client, without involving the server. In the next paragraph
we will show the specification of the operation chain needed
to transfer the shopping cart to the server, for making the
selected items persistently associated to an order.
Bulk data transfer between layers. With the introduction of different persistence layers, the need arises to
transfer data from a source to a destination layer in a bulk
manner: 1) server-side data must be transferred to the client

CD Details
CD Details

Create Item

ConnectToCD
OK
C

CD

CartItemToCD

CartItem
OK

Figure 9: Inserting an item in the shopping cart

Total
Shopping Cart

Export Cart
Items
Xml

Create Order
OK

OK

Import Order
Items
Xml

Cart

OK

Order

Figure 10: Operation chain for bulk data transfer

when they have to be manipulated client-side without invoking the server at each update (e.g., the wish list is loaded
from the server for disconnected client-side manipulation);
2) client-side data must be transferred to the server for permanent storage or for subsequent use by other users (e.g.,
the shopping cart items are sent to the server to be associated to the order). Data transfer leverages two WebML
operations, first introduced for data transfer from/to Web
Services [10]: XMLIn and XMLOut. The former takes in input a piece of XML data, structured according to a canonical
XML Schema5 , and stores it into a set of entities and relationships; the latter does the reverse operation: it exports
a set of entity and relationship instances into a canonical
XML fragment. As an example of bulk client-to-server data
transfer, consider the creation of an order from the items
in the shopping cart (Figure 10). From the Total page the
user may see the total price of his cart and, by navigating the
outgoing link of the ShoppingCart data unit, trigger a chain
of operations. The ExportCartItems client XMLOut unit
extracts the shopping cart items from the client entity CartItem; the server CreateOrder operation produces a new instance of the server-side Order entity; the ImportOrderItems
operation stores the shopping cart items into the OrderItem
entity and connects them to the order instance, received as
input parameter6 . This is an example of mixed client/server
operation chain: the first operation is marked as client; the
next operations are performed server-side. Notice that, in
general, transactional properties are not applicable to mixed
operation chains, as this would require a distributed transaction manager comprising the client, which is incompatible with the asymmetry of HTTP and unrealistic also when
symmetric protocols are used. However, it remains possible to define transactional server or client blocks inside an
operation chain. In Figure 10, a transaction (denoted as a
dashed rectangle) is defined for the server operations.
Operation modeling guidelines. As for page and content modeling, design guidelines and constraints apply to operation modeling too, including the bulk transfer of content
between tiers as a special case. In case of mixed client/server
5

The canonical XML Schema is simply a conventional set of

XML elements useful for representing data about entities,
attributes, and relationships, as defined in [10].
6
For simplicity, we omit the units and operations for connecting the order to the current user and to the chosen address, shipping method, and payment method.

operation chains, server and client operations should be grouped according to their type (when possible) to minimize the
client-server round-trips and to allow transactional blocks.
In the example of Figure 10, all the server operations are
performed consecutively. Client operations acting on temporary data should precede (when possible) server operations acting on permanent data. This guarantees a simpler
recovery in case of failure of one of the operations of the
sequence.
As a concluding remark, we observe that data access and usage at the client side can be modeled in three decreasingly
sophisticated ways: with client entities, with server entities
published in client pages, and with purely server pages. In
the first case, disconnected filtering, sorting, and manipulation are possible; the second choice allows disconnected
filtering and sorting, but not offline manipulation; the third
option does not permit disconnected work on the data.

7.

IMPLEMENTATION AND EXPERIENCE

The RIA modelling primitives discussed in the paper have

been implemented in WebRatio [2], a CASE tool for the visual specification and the automatic code generation for Web
applications. WebRatio adopts an MVC-based organization
and maps the various concepts of WebML (pages, content
units, and operations) into the components of the MVC 2
architecture, as illustrated on the right side of Figure 11.
Each WebML primitive is mapped onto run-time services,
model objects and, where needed, view templates. The
look&feel of the view templates is specified with page and
content unit mockups, manually coded by the graphic designer in XHTML and automatically transformed by WebRatio into XSLT style sheets applied during code generation:
in this way, arbitrary sophisticated look&feel specifications
can be exploited to generate code for WebML pages.
We adopted the same design for generating the client-side
code, exploiting Laszlo LZX [1] as the implementation technology. LZX is an object oriented, tag-based language that
uses XML and JavaScript to create the presentation layer
of RIAs served by the Laszlo Presentation Server. The runtime architecture extended for RIAs is shown in Figure 11.
A client-side controller, coded in LZX, is responsible of handling events and managing the computation of client-side
content units and operations. Each content unit is mapped
into: (1) a view component for rendering, (2) a model component for data management, business logic, and server communication, (3) possibly a service on the server-side for data
query and result formatting in XML. Operations are implemented like content units, without view components. The
code generator of WebRatio, which produced only serverside code, has been extended to produce also the client side
code; this includes the generic LZX Model classes and View
components, deployed as libraries in the client-side, and the
application-specific XML descriptor files to instantiate such
generic classes. Besides these extensions, existing rules for
server-side code generation have been reused, to produce
the components needed to implement those client-side units
that access server-side entities. Presentation is also generated automatically, by incorporating into the view component of units the look&feel mockups manually coded in
LZX. The implementation has revealed an architecture bottleneck in the client-side, due to the evaluation of selector
conditions involving join operations between entities. Current RIA technologies are heavily based on main memory

Configuration File:
- Action Mapping

Client
Browser
Flash Plug-In

Controller
(Script)

H
T
T
P

Model
Descriptors
Business Logic

View
(Lzx Components)

Unit Services

Controller
(servlet)
View
(JspTemplate)

http

Page Services
Operation Services

XmlHttp

State
Objects

Auxiliary Services

Servlet Container

S
e
r
v
e
r

Business Logic

Model

Page Services
Unit Services

Actions
Operation Services
Validation Services

HTML +
Custom Tags

Descriptors

State
Objects

Auxiliary Services

XML +
Custom Tags

Data Tier

Figure 11: Proposed run-time architecture.

XML data represented as a DOM tree, which does not support fast execution of joins. A possible optimization could
be restructuring the XML data transferred from the server
to the client side, to speed-up the execution of the most frequent client-side join operations. Such transformation could
infer from the model of the page the fastest access structures
(e.g., node nesting) for data frequently accessed together.
The described extensions of WebRatio have been applied
to industrial cases. The first published RIA application is
www.podereforte.it, a FLASH-based application describing the wine and oil production of a Tuscany farming company. In this first experience, only pages and content units
were implemented using RIA capabilities, whereas the operations for content update have been realized using a separate HTML+HTTP site view. Another industrial application is the second version of the MetalC manufacturing
suite (www.metalc.it), which provides Italian manufacturing companies with a set of Web-based platforms to share
on-line documents, integrate heterogeneous information systems through Web Services, and exchange commercial documents. MetalC interfaces require sophisticated interactions
for complex document editing and information layout; the
pure HTML pages of the first release were hard to use by
non-technical employees familiar with traditional desktop
interfaces. The second release of the suite aims at improving the ease of use and responsiveness of interfaces using all
the described RIA extensions of WebRatio.
The two experiences, although preliminary, have demonstrated the value of having a unique framework for modelling and implementing complex applications, mixing RIA
features with HTTP+HTML front-ends and Web Service interaction, unifying three otherwise separated facets of Web
development.

8.

CONCLUSIONS AND FUTURE WORK

We have shown how to evolve present-day Web design

methods and tools to support Rich Internet Applications,
and more generally any Web-enabled technology that flexibly assigns functions and data to the client and the server.
The described work is the initial step of a research program that will address several open issues: 1) enriching the
model of the presentation layer by considering behaviors like
drag&drop and multimedia synchronization; 2) providing an
integrated model for server-to-client interaction (e.g., event
subscription and notifications); 3) revising the semantics of
the conceptual model, to enable automated model-checking;
4) distilling comprehensive guidelines supporting the design
of RIAs; 5) measuring performance and optimizing the gen-

erated code; 6) continuing the industrial experimentation,

by targeting other RIA platforms; 7) providing an UML
profile for dealing with RIAs.

9.

REFERENCES

[1] Laszlo. http://www.laszlosystems.com.

[2] WebRatio. http://www.webratio.com.
[3] J. Allaire. Macromedia Flash MX-A next-generation
rich client. Technical report, Macromedia, March 2002.
[4] S. Ceri, P. Fraternali, M. Brambilla, A. Bongio,
S. Comai, and M. Matera. Designing Data-Intensive
Web Applications. Morgan Kaufmann, 2002.
[5] J. Conallen. Building Web applications with UML, 2nd
edition. Addison Wesley, 2002.
[6] M. Driver, R. Valdes, and G. Phifer. Rich Internet
Applications Are the Next Evolution of the Web.
Technical report, Gartner, May 2005.
[7] J. Duhl. White paper: Rich Internet Applications.
Technical report, IDC, November 2003.
[8] P. Fraternali. Tools and approaches for developing
data-intensive web applications: A survey. ACM
Comput. Surv., 31(3):227263, 1999.
[9] N. Koch and A. Kraus. The expressive power of
uml-based web engineering. In Second Int. Workshop
on Web-oriented Software Technology. Springer
Verlag, May 2002.
[10] I. Manolescu, M. Brambilla, S. Ceri, S. Comai, and
P. Fraternali. Model-driven design and deployment of
service-enabled web applications. ACM Trans. Inter.
Tech., 5(3):439479, 2005.
[11] M. T. Ozsu and P. Valduriez. Principles of distributed
database systems. Prentice-Hall, Inc., Upper Saddle
River, NJ, USA, 1991.
[12] L. D. Paulson. Building Rich Web Applications with
Ajax. Computer, 38(10):1417, 2005.
[13] J. Preciado, M. Linaje, F. Sanchez, and S. Comai.
Necessity of methodologies to model rich internet
applications. In Web Site Evolution, 2005. 7th IEEE
Int. Symposium on, pages 713, Sept. 2005.
[14] D. Shasha and P. Bonnet. Database Tuning:
Principle, Experiments and Troubleshooting
Techniques. Morgan-Kaufmann, 2002.
[15] M. Taguchi and T. Tokuda. Automatic generation of
client-server collaborative web applications from
diagrams. In Web Engineering, 5th International
Conference. Springer Verlag, 2005.