N.O INSTITUTO NACIONAL DE

A Brief Overview of AspectJ

The idea of AspectJ is to propose a new modularization unit (called aspect) to encapsulate cross-cutting concerns that cannot properly be captured in the OO paradigm. The goal of the aspects is to reduce the tangled and scattered code due to cross-cutting concerns, in order to ease the comprehension and maintenance of applications.

AspectJ is a popular Aspect-Oriented Programming language, which extends Java with AO concepts:

• Join Point: point of interest where an aspect can be woven. For example: a call to a method, get/set on an attribute.

• Pointcut: defines a set of join points. For example: all the call to the method m of the class C. It describes (possibly with quantification) where the aspect will be woven. • Advice: extra-behavior that extends (or replaces) the former behavior, at all the

places (join points) that match the pointcut. It describes what the aspect brings and

howit modifies the base behavior.

An aspect is thus a pair <Pointcut, Advice> that will impact all the join points inter- cepted by the the pointcut, at compile-time or load-time.

Some Approaches Mixing AOP and CBSE

Pessemier et al. propose FAC (Fractal Aspect Component) [121, 122, 123, 124, 125], an open-source aspect-oriented extension to the Fractal Component Model. It combines Component-Based Software Development (CBSD) and Aspect-Oriented Programming (AOP) by integrating CBSD notions into AOP, and vice-versa.

FAC introduces new aspect-oriented structures into the Fractal platform: Aspect Com- ponent (AC), Aspect Domain (AD) and Aspect Binding (AB). An Aspect Component is a regular component that encapsulates a cross-cutting concern providing advice pieces of code as services. Advice interface is a server interface to which an aspect can bind. A weaving interface provides a control interface for the setting and ordering of aspect bind- ings. Aspect components are Fractal components supporting the weaving interface. An Aspect Binding is a binding that links an AC to other components. Finally, an AC and all the aspectized components bound via ABs constitute an Aspect Domain. Note that FAC leverages the notion of shared components provided by Fractal to allow component to be contained into several ADs.

An aspect component, like a regular component can provide or require services via interfaces. Additionally, an aspect component can declare advice interfaces for declaring cross-cutting concerns.

An aspect domain is associated to each aspect component and encapsulates all the components aspectized by a given aspect component. In fact, aspect domains are Fractal composite components. Note that components can be shared by several composite com- ponents, and consequently a component can be aspectized by several aspect components. FAC aspect components are woven at all the join points that match the associated pointcut i.e., weaving or not weaving an aspect only depends on the topology of the run- ning system. There are no other conditions, such as environment or QoS, which can trig- ger the weaving of the aspect. In that sense, FAC proposes mechanisms to encapsulate and weave cross-cutting adaptations at runtime, but no language to express adaptations policies.

Pessemier et al. define a pointcut language for matching method calls, as follows: JP

Type; Component ; Interface ; Method, where:

• JP Type(join point type) indicates the type of the calls we want to match i.e., outgo- ing (CLIENT keyword), incoming (SERVER keyword) or both (no keyword). • Component, Interface and Method are regular expressions for referring to compo-

nents via their names, interfaces via their names and methods via their signatures. For example, the pointcut <CLIENT C* ; * ; add*> refers to all outgoing calls of any method whose name starts with add, encapsulated in any interface of any component whose name starts with C. Then, all the components that match this pointcut will auto- matically be aspectized by the Aspect Component associated to this pointcut, using an Aspect Binding. An AC and all its aspectized components form an Aspect Domain.

In FAC, an advice is a piece of code with the following structure: <before statements> <proceed> <after statements>, where:

• proceed is a call to the former service, before interception

• before/after statements represent the additional code that is introduced before/after the former code. All these statements are optional.

If proceed does not appear in the code, it means that the former service is totally re- placed. So, it is possible to modify the behavior of services by adding pre/post-treatment, or replacing the service by a new one. This definition of pointcut and advice is inspired by AspectJ [84, 83].

Note that the pointcut language does not allow to describe pointcuts like: “find all the components A, B, such as A and B are connected on a given interface I, and component A requires interface J.” In other words, each join point is limited to one given method of one given interface of one given component. It is not possible to describe additional constraints (e.g., A should be connected to B).

The advice interfaces of an aspect components implemented in FAC should imple- ment the Advice interface that extends the Interceptor interface. The Interceptor interface is defined in the AOP Alliance API (http://aopalliance.sourceforge.net/), an open source initiative to define a common API for AOP frameworks.

Surajbali et al. propose AOpenCOM [148], which offers very similar mechanisms for the OpenCOM platform.