ASPECTFX

A Framework for Supporting Collaborative Works in RIA by Aspect Oriented

Approach

Hiroaki Fukuda and Yoshikazu Yamamoto

Graduate School of Science and Technology, Keio University

3-14-1, Hiyoshi, Kohoku-ku, Yokohama Kanagawa 223-8522, Japan

Keywords:

Framework, Rich internet application, Software engineering, Aspect oriented programming.

Abstract:

This paper presents AspectFX, a novel approach to enabling developers and designers to collaborate effectively

in RIA development. Unlike traditional web applications, RIAs are implemented by a number of developers

and designers; therefore it is reasonable to divide an application into modules and assign them to developers

and designers, and collaborative works among them have been important. MVC architecture and OOP helps to

divide an application into functional units as modules and bring efﬁciency to development processes. To play

these modules as a single application, developers have to describe method invocations to utilize functionalities

implemented in modules, however, developers need to describe additional method invocations that are not

primary tasks for them. These additional method invocations make the dependencies among modules strong

and these dependencies make it inefﬁcient/difﬁcult to implement and maintain an application.

This paper describes the design and implementation of AspectFX that introduces aspect-oriented concept and

considers the additional method invocations as cross-cutting concerns. AspectFX provides methods to separate

the cross-cutting concerns from primary concerns and weaves them for playing them as an application.

1 INTRODUCTION

Rich Internet Application (RIA) introduces the user

experience of desktop applications. RIAs provide so-

phisticated user interfaces including attractive objects

and animations for users to understand their status

and results of the operations. In this way, compared

to traditional web applications, it requires a number

of developers and designers to implement an RIAs;

therefore it is reasonable to divide an application into

modules and assign them to developers and design-

ers, and collaborative works among them have been

important. However, dependencies among each mod-

ule make it inefﬁcient and difﬁcult to implement and

maintain an application even if we introduce MVC

architecture and OOP. For example, although it is

suitable for designers to create and manage anima-

tions includingwhen animations should be started and

stopped, developersusually manage them on behalf of

designers because functionalities for these animations

are provided as APIs.

Aspect-oriented programming (AOP)(Kiczales

et al., 1997) is a new programming paradigm that

separates cross-cutting concerns from primary con-

cerns. The notion of AOP is suitable for the prob-

lems described above. Because the management of

animations is not mainstream but cross-cutting con-

cerns for for developers. Also, event handling is not

mainstream but cross-cutting concerns for designers.

This paper describes a framework called As-

pectFX that makes it possible to rule out dependencies

among modules and combine them to play a single ap-

plication at runtime. AspectFX extends and leverages

Flex framework(Adobe Systems Inc., 2009). In Flex,

we can import and utilize animated objects created by

Flash as components. AspectFX leverages this event

model(Meier and Cahill, 2005) and dependency in-

jection(Fowler, 2008) in order to weave cross-cutting

concerns to mainstream at runtime. AspectFX also

introduces name based conventions for detecting the

points where cross-cutting concerns should be woven.

This paper is organized as follows. We ﬁrst de-

scribe the background in section 2. We then explain

the design and implementation in section 3 and be-

havior in section 4. In section 5, we conclude by pro-

viding summary and discussing future issues.

398

Fukuda H. and Yamamoto Y. (2010).

ASPECTFX - A Framework for Supporting Collaborative Works in RIA by Aspect Oriented Approach.

In Proceedings of the 12th International Conference on Enter prise Information Systems - Databases and Information Systems Integration, pages

398-402

DOI: 10.5220/0002906903980402

 SciTePress

2 BACKGROUND

Almost all web applications are implemented based

on MVC architecture nowadays. Therefore it is rea-

sonable to implement RIAs based on the same archi-

tecture. In this section, we ﬁrstly explain MVC ar-

chitecture in Flex. Then, we describe dependencies

among modules in Flex applications.

Figure 1: MVC architecture in Flex.

2.1 Flex Programming Model and MVC

Flex applications works by event-driven architecture.

Therefore developers have to prepare event handlers

and associate them with events dispatched from visi-

ble components. As shown in Figure 1, in general, it

is reasonable to prepare a class called Handler that in-

cludes handler methods and correspond to an MXML

that includes visible components. In the context of

MVC architecture, as shown in Figure 1, MXML cor-

responds to View and Handler corresponds to Con-

troller. In a handler method, developers implement

business logics and create Model in order to reﬂect

the result to MXML. In addition, it is recommended

to prepare classes independent from this architecture

and delegate business logics to them (we call these

classes as Logic).

On the other hand, the triggers to start and stop an-

imations embedded in a Flash component can be right

before and after event handling. Consequently, we

start and stop an embedded animation at the beggin-

ing and at the end of the handler method by invoking

methods as Figure 2(a)-(i) and (iii). In addition, we

also delegate business logics to another class by creat-

ing an instance and invoking a method in Figure2(a)-

(ii).

2.2 Dependencies among Modules

It is also reasonable to assign developers and de-

signers to each module for efﬁcient RIA develop-

ment; however dependencies among modules still

make it inefﬁcient and difﬁcult. For example, design-

ers mainly create MXML ﬁles for the design of an ap-

Figure 2: Pieces of code as cross-cutting concerns.

plication and developers have to modify the MXML

ﬁles to make associations between events and event

handlers. Likewise, designers may modify event han-

dlers implemented by developers to manage anima-

tions as shown in Figure 2(a).

Besides, there will be more complicated depen-

dencies between Handler and Logic. As we described

in section 2.1, Logic is usually introduced for in-

dependent processes, especially RPCs, from speciﬁc

architectures. As well as other components, RPC

components adopt event-driven architecture. That

is, when developers leverage RPC components, they

have to prepare event handlers and add them to the

RPC components. The handlers will be invoked by

RPC components to notify the result of operations. If

developers try to delegate a task to Logic that lever-

ages RPCs, they have to prepare a callback method to

create/modify Model that reﬂect the result of the task

because the task is processed asynchronously. More-

over, if developers or designers try to apply an anima-

tion for the task, they have to specify method invoca-

tions for the animation in different methods as shown

in Figure 2(b)-(i) and (ii).

3 SYSTEM IMPLEMENTATION

In AspectFX, we consider events in Flex as JoinPoint

and leverage name based conventionsas Pointcut. Be-

sides, we also consider event handlers and methods

to manage animations as Advice. AspectFX prepares

two advice types such as “beforeAdvice” and “after-

Advice” to manage animations. These advice types

need to be embedded in animated obejects as meth-

ASPECTFX - A Framework for Supporting Collaborative Works in RIA by Aspect Oriented Approach

399

Figure 3: An architecture of AspectFX.

ods. In addition, AspectFX adopt eventmodel to dele-

gate tasks from Handler to Logic(we call this event as

an application speciﬁc evnet). We show the architec-

ture of AspectFX in Figure 3 and explain name based

conventions.

3.1 Name based Conventions

AspectFX leverages convention over conﬁguration

concept to identify events and event handlers to be

woven. Therefore AspectFX has several name based

conventions for weaving. In addition, we assume

Flash components are imported and utilized as visible

components in MXML. Based on this assumption, we

explain the conventions as follows.

1. Every component including Flash component de-

ﬁned as MXML tag must have “id” attribute and

the value that can identify each component.

2. MXML and corresponded Handler have to be de-

ﬁned as MXML tag(Figure 4(a)). In addition,

these modules must have the same parent in the

composition of components(Figure 4(a)(b)).

3. MXML and corresponded Handler must have id

attribute and the value of each. In addition, the

preﬁx of each value must be the same to show they

are relevant. Moreover the sufﬁx of each must be

“View” and “Handler” characters. For example,

developers and designers should name each mod-

ule with preﬁx “main” as “mainView” and “main-

Handler”(Figure 4(a)).

4. In order to weave events and event handlers, the

name of event handlers must be deﬁned as “com-

ponent id” + “event name” + “Handler” characters

Figure 4: Name based conventions in AspectFX.

and “event name” must be capitalized. For ex-

ample, to handler “click” event dispatched from

a component named “ﬂButton”, developers have

to deﬁne “ﬂButtonClickHandler” method in Han-

dler(Figure 4(d)).

5. For leveraging animations, designer have to em-

bed two types of advices in a Flash component

as callback methods such as “beforeAdvice” and

“afterAdvice”. “beforeAdvice” will be invoked

before the event handling and “afterAdvice” is

done after the event handling.

6. Developers need to prepare a class that extends

Event Controller in order to leverage event model.

They can use “addLogic” method to register a

set of application speciﬁc event and Logic(Figure

4(e)). In addition, the name of event handlers de-

ﬁned in Logic that will handle application speciﬁc

events must be deﬁned as “event type” + “Even-

tHandler” characters as shown in Figure 4(f)).

4 APPLICATION BEHAVIOR

In this section, we describe application’s behavior

and also explain how to manage application speciﬁc

events by introducing classes depicted in Figure 4.

4.1 Application Behavior

1. When an application starts, AspectFX conﬁrms

“id” attribute of each component and then if the

sufﬁx of the value is “View” characters, AspectFX

get the reference of MainView and corresponded

MainHandler by way of Canvas.

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

400

public class AdviceWrapper {

public var target:Object;

public var callBack:Function;

public var async:Boolean;

public function processAdvice(e:Event):void {

target[“beforeAdvice”].apply(null);

callBack.apply(null,[e]);

if(!async) target[“afterAdvice”].apply(null,[e]);

}

public function processAdviceAsync(e:Event):void {

if(async) target[“afterAdvice”].apply(null);

}

Figure 5: Implementation of Advice Wrapper.

2. Parser serializes MainView and MainHandler to

XML expressions and parses them. Parser dele-

gates Weaver to weave an event handler named

“ﬂButtonClickHandler” into “ﬂButton”.

3. If the visible component is a Flash component,

Weaver creates an Advice Wrapper and sets the

component (ﬂButton) and corresponding event

handler (ﬂButtonClickHandler) into the Advice

Wrapper. As shown in Figure 5, Advice Wrap-

per prepares event handler called “processAd-

vice” and Weaver injects the “processAdvice”

into “ﬂButton” to hook “click” event.

4. When a user clicks the ﬂButton , the dispatched

“click” event is caught by the processAdvice in

Advice Wrapper. As shown in Figure 5, Advice

Wrapper invokes “beforeAdvice” embedded the

ﬂButton ﬁrst. Then the Advice Wrapper also in-

vokes “ﬂButtonClickHandler” that is set to a vari-

able named “callBack”. Finally, if “async” vari-

able in Advice Wrapper is false, the Advice Wrap-

per invokes “afterAdvice”. 4.2.

4.2 Application Speciﬁc Event

Processing

To leverage application speciﬁc events, developers

have to specify an extension class of Event Controller

as an MXML tag as shown in Figure 6(a). Also,

AspectFX provides “AppEvent” and “AppEventDis-

patcher” classes for application speciﬁc events.

We explain these processes as follows.

1. A “click” event is dispatched by user’s opera-

tions. As described step 4 in section 4.1, Ad-

vice Wrapper invokes “beforeAdvice” and then

invokes “ﬂButtonClickHandler” deﬁned in Main-

Handler. After that, if developers do not dis-

patch an event or do not specify a notiﬁed method

in AppEvent, Advice Wrapper invokes “afterAd-

vice”.

Figure 6: Source code for application speciﬁc event.

2. An application speciﬁc event is dispatched with

an event type as “login” in ﬂButtonClickHandler

as shown in Figure 6(b).

3. Event Controller catches the “login” event and

creates its corresponded LoginLogic. Then, Event

Controller invokes “loginEventHanler” deﬁned in

LoginLogic.

4. An consume event is dispatched to notify the com-

plete of the event. Event Controller invokes the

notiﬁed method (“callback”).

5. Event Controller sends a message to Advice

Wrapper to notify the end of “login” event. Ad-

vice Wrapper invokes “afterAdvice” and then

users can understand the process is completed.

5 CONCLUSIONS

In this paper, we have presented a framework called

AspectFX for collaborative works in RIA develop-

ment. We have also explained the design and im-

plementation of AspectFX and conﬁrm its availabil-

ity via performance evaluations. AspectFX not only

provides MVC based development process but also

rules out pieces of code that make associations among

modules from each source code by introducing AOP

concept and event model. As a result, developers and

designers are able to concentrate on their tasks. We

believe these features of AspectFX help not only de-

velopers but also designers to develop and maintain

an RIA application.

ASPECTFX - A Framework for Supporting Collaborative Works in RIA by Aspect Oriented Approach

401

REFERENCES

Adobe Systems Inc. (2009). Adobe ﬂex3. http://www.

adobe.com/products/ﬂex/.

Fowler, M. (2008). Inversion of Control Con-

tainers and the Dependency Injection pattern.

http://www.martinfowler.com/articles/injection.html.

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C.,

Lopes, C., Loingtier, J., and Irwin, J. (1997). As-

pect oriented programming. In In Proceedings of Eu-

ropean Conference on Object-Oriented Programming

(ECOOP).

Meier, R. and Cahill, V. (2005). Taxonomy of distributed

event-based programming systems. The Computer

Journal, 48(5):602–626.

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

402