Modeling distributed events in data-intensive Rich Internet Applications

Modeling distributed events in data-intensive Rich Internet Applications Giovanni Toffetti Carughi, Sara Comai, Alessandro Bozzon, and Piero Fraternali Politecnico di Milano, Piazza Leonardo Da Vinci, 32 - 20133 Milano - Italy {giovanni.toffetti,sara.comai,alessandro.bozzon,piero.fraternali}@polimi.it

Abstract. Rich Internet applications (RIAs) enable novel usage scenarios by overcoming the traditional paradigms of Web interaction. Conventional Web applications can be seen as reactive systems in which events are 1) produced by the user acting upon the browser HTML interface, and 2) processed by the server hosting the application state and logic. In RIAs, distribution of data and computation across client and server broadens the classes and features of the produced events as they can originate, be detected, notified, and processed in a variety of ways. In this work, we investigate how events can be explicitly described and coupled to the other concepts of a Web modeling language in order to specify collaborative Rich Internet applications.

1

Introduction and Motivation

Rich Internet Applications (RIAs) are fostering the growth of a new generation of Web applications providing reactive user interfaces and bidirectional clientserver communication. Figure 1 depicts the general architecture of a RIA: the system is composed of a (possibly replicated) Web server and a set of user applications (implemented as JavaScript, Flash scripts, or applets) running in browsers. The latter are downloaded from the server and executed following the code on demand paradigm of code mobility [4]. In a traditional Web application the server holds the complete application state and receives all update invocations from the users: at each request the server responds with the rendering of the latest application state. In a RIA instead, the application state is scattered among different client-running components, user interactions are intercepted on the client, and relevant occurrences have to be explicitly signalled to interested applications either for state synchronization or to trigger a possible reaction. Client applications have to be notified of events occurring outside their execution environment, either triggered by other clients or by the server: examples of events that can trigger a reaction on a user client application include users’ interactions on the interface, server internal or temporal events, and Web service invocations. Our Contribution. As Rich Internet Application adoption is experiencing constant growth, a multitude of programming frameworks have been proposed

to ease their development (e.g., [1, 2]). While frameworks increase developer productivity, they fail in providing instruments that abstract from implementation details and that represent at a higher level the final application; this becomes necessary when tackling the complexity of large, data-intensive applications. Web engineering methodologies offer sound solutions to model traditional Web applications at a conceptual level and to automatically generate their code from the conceptual specification, but they generally lack the concepts to address Rich Internet Application development. In this paper we propose a model and a methodology to support the design of event-driven RIAs. Our contribution is an extension of the conceptual model of a Web engineering methodology for the high-level specification of distributed events and of new RIA-specific interaction paradigms and application functionalities. In addition, we report on our prototype implementation of the proposed model extensions in the framework of an existing commercial CASE tool (WebRatio). User Interface

1...N

UI Events UI updates

Client Logic Client Data

Web Browser

UI updates

Client Logic Client Data

Web Browser

User Interface UI Events

XML messages

Web Server Fig. 1. A Rich Internet Application architecture.

Case Study. In order to better discuss relevant aspects of the proposed approach, we introduce as case study a collaborative on-line project management application. The application aim is to let users communicate and organize projects and tasks. Application users impersonate different roles: project managers and project participants. A manager can create projects and tasks, assign tasks to participants, and define precedence relationships among the tasks of a project. Participants execute assigned tasks, possibly exchanging messages with their contacts. Although the proposed approach applies to most Web engineering methodologies, we will illustrate it using the WebML notation [5]. In WebML content to be published is modeled using Entity-Relationship (E-R) diagrams. Figure 2 shows the data model for the case study application: the user entity represents application users, a self-relationship connects each user with his contact list. A user can participate in one or more projects, while each project can be directed by a unique manager. Users are assigned tasks: each task belongs to a project and can have precedence constraints w.r.t. other tasks. Messages can be exchanged between users, having a sender and a set of recipients. Upon the same data model, it is possible to define different hypertexts (also called site views), targeted to different user roles. A site view is a graph of pages, possibly hierarchically organized into sub-pages. Pages comprise content units,

Contact S 0:N OID 0:N

Participant S

0:N

0:N

Project

Manager

0:N

Next

Sender

1:1

0:N

0:N Assigned to 1:N S

Belongs to 1:1

0:N

Username Password Email

1:1

OID Name

0:N

User

S

Message

Recipient

OID 1:N Date Subject Body

Task

OID 0:N State Description Due Date Alarm Time 0:1

Fig. 2. Data Model of the project management application.

i.e., components for content publishing: the content displayed by a unit 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. 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 (e.g., to manipulate entity instances). In [3] we extended the modeling primitives of WebML to support the design of RIAs considering data and computation distribution among server and clients: pages, entities, logical conditions, operations, etc. can be marked as client or server : in the former case the client will compute them, in the latter they are computed at the server. OK

Create Task

ConnectTask Project C

OK

TaskID

BelongsTo S C C

ProjectID

Project Management Project Page

C

Create Task

Task Page Task List

Project Details

Project List

ProjectID

New Task Description

ProjectID

Project S

C

Task S

DueDate

Project S

Task S [BelongsTo S ]

Fig. 3. Example of hypertext model for the project management application.

Figure 3 depicts a fragment of the hypertext model for the case study. It represents a client (marked with an uppercase C) page Project Management including two sub-pages. Project Page contains a list of projects (Project List index unit), showing all instances of the entity Project on the server. When a project from the list is selected, the outgoing link carries the project identifier to (Project Details) showing the details of the selected instance. A list of project tasks is displayed, through the Task List index unit. Task Page also contains a form (New Task ): the link exiting the unit represents form submission, triggering a sequence of two operations: CreateTask

creates a new instance of the (server) entity Task, and BelongsTo associates such instance to the selected project.

2

Event modeling for Rich Internet Applications

The design of RIAs supporting event notifications implies the consideration of different aspects, like the identification of notification recipients, or the persistence of the communication. In this section we first introduce the possible behaviors that we want to model (represented by semantic dimensions in Table 1); then, we show the primitives for modeling distributed events in a RIA. Dimension Name Filter location Filter logic Communication Persistence

Possible Values Sender, Broker, Recipient Static, Rule-based, Query-based Persistent (asynchronous), Transient (synchronous)

Table 1. Semantic dimensions in RIA event notification

Event Filtering: not all users need to be notified of all event occurrences; in a generic distributed event system the process of defining the set of recipients is generally indicated as event filtering [9] and two dimensions can influence it: where it takes place and how. Filtering location defines where the set of recipient is identified. The RIA architecture can be seen as a particular case of the most general architecture for publish / subscribe systems [7] that involves three kinds of actors: a set of publishers (senders), a broker, and a set of subscribers (recipients). Events occur at publishers that alert the broker who, in turn, notifies the subscribers. Thus, the decision of which recipients to notify can be taken at the sender, at the broker, or all recipients can be notified leaving to them the decision of whether to discard or not an already transmitted notification. Filtering logic considers the logic that is used to identify the set of recipients: the spectrum of possibilities ranges from statically defined recipients (e.g., the recipient is User X), to conditions on event attributes or related domain entities (query-based filtering - e.g. the recipients are all the users retrieved from entity User and participating to Project Y), to interpreted run-time defined rules (rulebased filtering, e.g., using a rule engine to detect composite event patterns). Communication persistence: depending on the application, some events may need to be communicated in a persistent way to prevent their loss, others only need transient communication. We refer to this semantic dimension as communication persistence. RIAs behave like generic distributed systems, where message communication can be [12]: (i)Persistent, when the message that has been submitted for transmission is stored by the communication system as long as it takes to deliver it 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 executing while the message is submitted. Alternatively, a message is (ii) Transient when it is stored by the communication system only as long as the sending and receiving applications are executing.

Therefore the recipient application receives a message only if it is executing, otherwise the message is lost. 2.1

Proposed Extensions

In this section we show how to extend the WebML model to take into account the previously introduced requirements for event management in RIAs. The extensions apply to the data and hypertext model (common to most Web modelling approaches) and therefore can be taken as a basis also for other Web Engineering methodologies. The event model. One issue to be considered when designing event-driven solutions is the choice of relevant occurrences for the system which are, in general, application-specific. Considering our case study application, each action upon a task instance can be considered a specific event type: for example an event associated to the assignment of a task to a specific project participant, or the completion of a task by a project participant. Each event type may expose specific parameters: for example, for the task assignment event its parameters can be the task to be assigned and the user to which it has to be assigned. In Web Engineering methodologies, the data model plays a central role in the specification of the structure and behavior of data-intensive Web application. We therefore extended the existing Data model for a RIA application with an appropriate Event model (expressed in an E-R like notation), in order to (i) model the event types (and their parameters) requested by the application and (ii) represent and instantiate relations between event occurrences and domain model entities. With respect to the E-R model, we define an Event Entity to represent the common features of a set of events meaningful for the application; an event instance is the occurrence of a given Event Entity. Event Entities are characterized by a set of event parameters, representing properties useful for the application’s purposes. Event entities can be organized in specialization hierarchies to inherit common parameters, and can have relationships with domain entities from the data model. Consider, for example the event types ”Task assigned”, and ”Task completed” in our case study. They are represented in the event hierarchy in Figure 4, connected to the data model of Figure 2. Contact S

S

0:N 0:N Participant 0:N 0:N Manager 1:1

Project

OID Name 0:N

Belongs to

Next

0:N

User

OID Username Password Email 0:N Assigned to 1:N S

0:N Sender 1:1 S Message 0:N

OID 1:N Date Subject Body Ass igne e

Recipient

0:N

Task

1:1 OID State 0:N Description Due Date Alarm Time

0:1

0:N

1:1 Allocation 0:N

Task Completed taskID

Completion

Task Assigned 1:1 assigneeID taskID

Event Timestamp recipient

1:1

Fig. 4. The data model of Figure 2 extended with event types.

Event primitives in the hypertext model. In order to support event notifications, two basic primitives are introduced: the send event and the receive event primitives. The former allows one to send an event notification to a (set of) recipient(s); the latter is used to receive the notification and trigger the corresponding reaction. Each primitive must be associated with an event entity, as defined in the event model. The specified event entity provides both a mapping between the send and the corresponding receive event operation (i.e., operations defined on the same event type trigger each other) as well as their specific parameter set. Send and receive primitives can be combined with other operations to obtain patterns covering all the possible combinations of filtering and communication needs. Get Prj Members C Assign Task

PrjID

Send Event primitive Current Task TaskID

Current Project

User S [Project2User]

TaskID

MemberIDs

Assign Task Select Prj Member

Task S

UserID

Project S [Task2Project]

User S [Project2User]

NotifyAssignment

C

OK

C

Task2User S

TaskID

TaskID UserID OK

PrjID

Task Assigned

Fig. 5. The hypertext to assign a task and send a notification.

Figure 5 shows a usage example of the send event primitive: it signals the assignment of a task to a project participant, triggered from a client page. The Assign Task RIA page shows the details of a selected task (Current Task data unit); the task belongs to a particular project, retrieved through the Current Project data unit. The current project allows to retrieve the list of users participating to that project (both in the Project Members index unit and in the Get Prj Members selector unit). The user can select a project member to whom the task should be assigned from the Select Prj Member index unit. This selection triggers the chain of operations represented outside the page: first, the selected project member is associated with the selected task (Assign Task operation); then this assignment is notified through a send event operation NotifyAssignment. The recipients are the whole set of project members (represented by the parameter MemberIDs) retrieved through the Get Prj Members selector unit; the current task and the selected assignee member are used to set the event parameters. Figure 6 represents the dual operation: it models client page (My Tasks) receiving a task assignment notification. RIA pages can establish a persistent connection with the server and receive notifications while the user is on-line. The Task Assigned notification is received through the RecAssignment receive event operation: notice that the same event type is used to couple this receive primitive with the corresponding send primitive shown in the previous example. Then, the Is it mine? switch operation compares the assignee of the task with the current user identifier: if they match, the task has been assigned to the

C My Tasks

NewTask Pop-up New Task

Current Tasks

Receive Event primitive UserID

taskID OK RecAssignment

assigneeID taskID

Is It Mine? UserID

OK

C

C

KO

Task S [ID = task]

Task S [User2Task]

Modified Project

Get Current User

Project Tasks

taskID Task Assigned

ProjectID

assigneeID == UserID

Project S [TaskToProject]

CurrentUser

Task S [ProjectToTask]

Fig. 6. A notification is received and the user interface is updated.

current user and the OK-link is triggered, otherwise the KO-link is followed. In the former case the New Task data unit that will retrieve from the server the assigned task details to be shown in a pop-up window; in the same page, the Current Tasks index unit shows the updated task assignments list for the current user. Otherwise, the other part of the page is displayed: it shows the details of the project to which the novel task belongs (represented by the Modified Project data unit) with the updated list of its tasks (Project Tasks index unit). Notice that in this example filtering is performed by the recipients: the message is sent to all the members of the project and each client instance will check if the task has been assigned to the current user. Filter logic is based on a query, performed by the Is it mine? unit. Finally, communication persistence is transient (synchronous): once the event is sent, each on-line running application will immediately receive an event notification through the receive primitive. In order to model persistent (asynchronous) communications, event data need to be explicitly stored in the event model, as we will see in the next example, where we consider the generation and reaction to events on the server, instead of on the user interfaces. Reactions to events received on the server are modeled by means of operation chains starting with a receive-event operation. They can trigger any server-side operation such as invoking Web services, sending emails, performing CRUD operations on the database, or signaling new event occurrences. In particular, it is possible to make the notification persistent using the database, to asynchronously signal the event when the intended recipient is back on-line; moreover, using conditional and query operations it is possible to specify broker filtering (Section 2). Figure 7 depicts a server-side operation chain for the running example. The application requires that a notification be sent to a user when a task is assigned to her. When the user is off-line, she cannot receive notifications with server push as in the previous example: on the server, upon the reception of the notification of the Task Assigned event (represented by the RecAssignment receive event) the User Online? switch-operation triggers a create operation (Store Event) to persistently store the event occurrence if the assignee is not immediately reachable. When the assignee is back online, all the event occurrences stored on

task assignee RecAssignment

Store Event

User Online?

assignee OK

KO

Task Assigned

assignee.status == Online

Task Assigned

Fig. 7. If the assignment user is offline, store the event to assure persistance.

the server are notified, activating the associated reactions on the client. The same primitives can be used to represent other classes of system events such as, for instance, temporal events, external database updates, or Web service invocations (for a complete reference see [13]).

3

Implementation

The implementation of the presented concepts builds on the WebRatio runtime architecture we developed for the work presented in [3]. The prototype automatically generates the code and the run-time framework for the WebML notation extended with distributed data and computation; it has been implemented using the OpenLaszlo [2] technology. We extended it with the needed components for distributed event notification: the resulting architecture is shown in Figure 8. Configuration File: - Action Mapping

Client Browser HTML Page Flash Plug-In

Model

Controller (Script)

State Objects

View (Lzx Components)

Client Data Tier

Descriptors Business Logic Page Services

http

Operation Services

Unit Services Auxiliary Services

Client Event Manager

XmlHttp

Persistent Connection

H T T P S e r v e r

Controller (servlet) View (JspTemplates) HTML + Custom Tags

Servlet Container Model Actions

Descriptors

Business Logic (RTX) Page Services Unit Services Operation Services

Link Services

State Objects

Extended Laszlo Presentation Server (LPS)

Server Event Manager

Server Data Tier

Fig. 8. The runtime architecture of our prototype implementation.

OpenLaszlo natively provides a framework for enabling persistent connections and server to client communication. The implementation of the receive event and send event operations leveraged on such feature by extending both on the client and on the server side the existing architecture. On the client-side, an event handler (the client-side Event Manager in the architecture) is triggered whenever the persistent connection receives a message (i.e., an event notification) from the server. Message communication is performed by means of XML snippets, structured accordingly to the associated event type. The Event Manager is configured at compile time with a descriptor file, containing information about the event types managed by the client; it checks the received message for the carried event type and triggers the receive event operations associated

with it, passing a reference to the received message. The receive event operation extracts relevant parameters from the message, sets the values for its outgoing parameters and calls the next operation in chain. When a client-side send event operation is invoked, the client-side Event Manager builds an XML snippet reflecting the associated event type structure and whose content stems from the operation input parameters values upon invocation; then, it invokes a method of the persistent connection to send such message to the server. The server-side stub of the persistent connection is a servlet, provided by the Laszlo Presentation Server (LPS). We extended such servlet in order to bind the existing WebRatio run-time framework with the LPS server: it intercepts event reception on the server and invokes the server-side Event Manager component, also configured at compile time with a descriptor file, which, in turns, matches for the received event and triggers the appropriate server-side receive event operations.

4

Related work

Although RIA interfaces aim at resembling traditional desktop applications, RIAs are generally composed of task-specific client-run pages deeply integrated with the architecture of a traditional Web application. Web Engineering approaches build on Web architectural assumptions to provide simple but expressive notations enabling complete specifications for code generation. Several methodologies have been proposed in literature like, for example, OOHDM [11] and WAE [6] but, to our knowledge, none of them addresses the design and development of RIAs considering them under the light of distributed event systems. This work, instead, considers system reaction to a collection of different events depending on any user interaction, Web service calls, temporal events, and data updates. Besides defining the generic concept of event in a Rich Internet Application, our approach also individuates the primitives and patterns that can be used to notify and trigger reactions upon external events. This is something that, to our knowledge, all Web engineering approaches lack, as reactions are only considered in the context of the typical HTTP request-response paradigm. Both a survey and a taxonomy of distributed events systems are given in [9]: most of the approaches bear the concepts individuated in [10] concerning event detection and notification, or in [7] w.r.t. the publish-subscribe paradigm. With respect to these works, our proposal addresses events and notifications in a single Web application where on-line application users are the actors to be notified. In contrast, the above proposals aim at representing Internet-scale events with the traditional problems of wide distributed systems such as, for instance, clock synchronization and event ordering [8]. The system we are considering, instead, is both smaller in terms of number of nodes, and simpler in terms of topology: the server acts as a centralized broker where all events are ordered according to occurrence or notification time at the server. Nevertheless, it enables the specification and the automatic code generation of complex collaborative on-line applications accessible with a browser.

5

Conclusions and future work

RIAs provide the technological means to implement a new generation of online collaborative applications accessible from a Web browser. Notification-based communication of events (e.g., publish / subscribe, distributed event systems) and server-push technologies (e.g., based on AJAX) are both well-known and established: in this work we have presented the requirements and the primitives needed to conceptually model Rich Internet applications leveraging on them. We plan to extend the event primitives to provide support for composite event recognition and explicit modeling of traditional Event-Condition-Action semantic dimensions such as event consumption and rule granularity, by means of a distributed event base across the server and the clients. Future work will also consider the integration of external rule engines or hierarchical distributed event systems to cater for scalability.

References 1. Google Gears, http://gears.google.com/. 2. OpenLaszlo, http://www.openlaszlo.org. 3. A. Bozzon, S. Comai, P. Fraternali, and G. Toffetti Carughi. Conceptual modeling and code generation for Rich Internet Applications. In D. Wolber, N. Calder, C. Brooks, and A. Ginige, editors, ICWE, pages 353–360. ACM, 2006. 4. A. Carzaniga, G. P. Picco, and G. Vigna. Designing distributed applications with a mobile code paradigm. In Proceedings of the 19th International Conference on Software Engineering, Boston, MA, USA, 1997. 5. S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, and M. Matera. Designing Data-Intensive Web Applications. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2002. 6. J. Conallen. Building Web applications with UML, 2nd edition. Addison Wesley, 2002. 7. P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec. The many faces of publish/subscribe. ACM Comput. Surv., 35(2):114–131, 2003. 8. L. Lamport. Time, clocks, and the ordering of events in a distributed system. Commun. ACM, 21(7):558–565, 1978. 9. R. Meier and V. Cahill. Taxonomy of Distributed Event-Based Programming Systems. The Computer Journal, 48(5):602–626, 2005. 10. D. S. Rosenblum and A. L. Wolf. A design framework for Internet-scale event observation and notification. In M. Jazayeri and H. Schauer, editors, Proceedings of the Sixth European Software Engineering Conference (ESEC/FSE 97), pages 344–360. Springer–Verlag, 1997. 11. D. Schwabe, G. Rossi, and S. D. J. Barbosa. Systematic hypermedia application design with OOHDM. In Hypertext, pages 116–128. ACM, 1996. 12. A. S. Tanenbaum and M. V. Steen. Distributed Systems: Principles and Paradigms. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2001. 13. G. Toffetti Carughi. Conceptual modeling and code generation of data-intensive Rich Internet applications. PhD thesis, Politecnico di Milano, Italy, 2007.