An extensible framework for middleware design based on concurrent event-based AOP

Instituto de Engenharia de Sistemas e Computadores Investigação e Desenvolvimento em Lisboa

An extensible framework for middleware design based on concurrent event-based AOP

Edgar MarquesLuís Veiga, Paulo Ferreira

INESC-ID / Tech. Univ. Lisbon

Edgar Marques

Finish this!

An extensible framework for middleware design based on concurrent event-based AOP – Edgar Marques, LV, PJPF 2010/11/30 00:36

Outline

Motivation

Problem

AOPBasic concepts

Typical concerns

Our approachArchitecture

Programming model (example)

Extending the framework

Implementation

Evaluation

Conclusions and future work

2


Motivation

Work anywhere, anytime!Newer, more powerful mobile devices

Proliferation of high-bandwidth wireless networks

Sophisticated applications and services (social networking, location, etc.)

However, many obstacles still remain!Still considerably less powerful than your average desktop PC

Variable quality of network link (sometimes no connection at all!)

Short battery life...

3


Problem

Modern mobile applications must be able to manage available resources through:

Distribution: delegation of data and/or tasks to other network nodes

Adaptation: change behaviour during runtime

Quite a daunting task for the average programmerInvolves dealing with low-level issues (e.g. data management, security, etc.)

Time-consuming and error-prone

4


Solution?

Encapsulate such features in a middleware solutionGeneral purpose solution for a well-defined, well-know recurrent problem in different domains

Modular and reusable

Delivers considerable savings in development effort, time and cost

However, this raises important design questionsHow to integrate an application with the middleware?

It might have to be adapted in order to fit the programming model imposed by the middleware

Will it lead to code scattering?Difficult to maintain and to understand

5


Aspect-oriented programming (AOP)

What is it?A programming paradigm focused on the separation of cross-cutting concerns (aspects) in a reusable fashion

Previous work on aspect-oriented middleware:Adaptive mobile computing applications (Costa, Strzykalski, Bernard)

Concurrency patterns and parallel computing (Sobral, Cunha, Monteiro)

Coordination in middleware infrastructures (Amor, Fuentes, Pinto)

ACID properties for transactional objects (Kienzle, Gélineau)

And others...

6


Basic concepts of AOP

Behavior-related:Advice: the code to encapsulate and reuse

Join-point: a specific point in the execution flow of a program (e.g. before a method call) where the advice code can be executed

Pointcut: query which specifies the set of join-points where the advice code should be executed

Structure-related:Introduction (or intertype declaration): member (e.g. field, method, etc.) which should be added to all types where the aspect is applied

7


Typical concerns in AOP

Aspect composition How to leverage different aspects in order to achieve complex behavior?

How to avoid interference between conflicting aspects?

Stateful aspectsAspects which trigger on a sequence of join-points

Distributed aspectsHow to define pointcuts which involve different processes running in distinct network nodes?

...

8

Edgar Marques

Add references to previous works in these areas


Our approach

Based on concurrent event-based AOP (Douence et al.)Aspects as loosely-coupled, concurrent, isolated entities

Easier to replace aspects during runtime (thus simpler to write adaptive applications)

Leveraging of multiprocessing capabilities of underlying platform if available

Isolation by running each aspect within its own process space improves robustness (implementation-dependent)

Emphasis on reusabilityPointcut definition is separated from advice / introduction definition

9

Edgar Marques

Dynamic AOP?

Edgar Marques

Compare with AspectJTwo roles: aspect programmer and client programmer


Our approach (cont.)

Programming model based on attribute-oriented programming

Aspects (advice/introductions) are declared as plain old Java objects tagged with plain Java annotations

Pointcuts are also declared using plain Java annotations

Small, simple, generic and extensibleIssues such as concurrency control and aspect composition are not dealt with

Extensible through the use of meta-aspects (aspects of aspects)

Basis for the construction of higher-level aspect libraries/frameworks/languages

10

Edgar Marques

Refeer previous work on meta-aspect runtimes and the recognition of the above issues as aspects themselves


Architecture

11


Event raising at join-point and advice execution

12


Example: logging application events

Declaring an aspect

@Aspect(Name=“Logged”,

Elements={@Element(Name=“LogFile”, Type=String.class)})

public class Logger {

...

@Member

private int eventCount = 0;

...

@Before(Actions={ActionType.METHOD_INVOKE},...)

public void log(...) {...eventCount++;...}

...

}

13


Example: logging application events (cont.)

Using the aspect in an application

@Logged(LogFile=“log.txt”)

public class SomeClass {

...

@Pointcut(Aspects={Logger.class})

public boolean predicate(AdviceType advice,

ActionType action, ...) {...}

...

}

14

Edgar Marques

Strategy pattern for dynamic behaviour


Extending the framework

Because aspects are written as plain old Java objects, a meta-aspect is declared like a regular aspect!

It simply listens for calls on the advice method of advised aspects

It may intercept and delay or even deny event delivery to the advised aspects (around advice)

Some naïve approaches to typical AOP concerns:Stateful aspects: encapsulate a Finite State Machine (FSM) in a meta-aspect which notifies the advised aspect on reaching the goal state

Aspect composition and concurrency control: redirect, delay and/or reorder delivery of events to advised aspects

Distributed aspects: broadcast intercepted local events on the network and locally dispatch received broadcasts

15


Implementation

Based on compile-time source-weavingBuild tool based on the RECODER framework for Java source code metaprogramming

However could be based on load-time bytecode-weaving as well

Program transformation pattern for a method call join-point

boolean _goAround000001 = beginMethodInvoke(HelloWorld.sayHello,

myHelloWorld, {“<My name>”});

Object _returnValue000001;

if (!_goAround000001)

_returnValue000001 = myHelloWorld.sayHello(“<My name>”);

endMethodInvoke(HelloWorld.sayHello, myHelloWorld, {“<My name>”},

_returnValue000001);

16


Evaluation

Performance overhead of our frameworkProcess/thread creation/termination and management

Mitigated by the use of process/thread pools

Should not be a frequent operation in most scenarios

Event dispatching

Advice execution

Synthetic micro-benchmarkOverhead measurement of event dispatching and advice execution as the number of concurrent aspects increases

All aspects perform the same advice code

Advice code performed CPU-bound operations only

All aspects are executed (no pointcut evaluation)

Run on a dual-core equipped PC

17


Time overhead for advice executionon a join-point

18


19

Conclusions and future work

Java framework for middleware designBased on CEAOP

Focus on aspect reusability

Small, generic and extensible through meta-aspects

Future workPerformance and scalability issues:

Execution of I/O-bound operations in advice code

Scalability of the event dispatch mechanism (with pointcut evaluation)

Overlapping of both advice execution and event delivery

Higher level aspect frameworks

Middleware solutions for adaptability and context-awareness and their use in real-world applications


20

An extensible framework for middleware design based on concurrent event-based AOP

Thank you.

Questions ?

http://www.gsd.inesc-id.pt/

An extensible framework for middleware design based on concurrent event-based AOP

Documents

Transcript of An extensible framework for middleware design based on concurrent event-based AOP