Conceptual Modeling and Code Generation for Rich Internet Applications Alessandro Bozzon
[email protected] Piero Fraternali
[email protected]
Sara Comai
[email protected] Giovanni Toffetti Carughi
[email protected]
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). ICWE’06, 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 browser’s 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 Conallen’s 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
C
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
C
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 application’s 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 user’s 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 user’s 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 user’s 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] [
C
CD Price >= Min] [
C
Price = Min] and [price
