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

1. An extensible framework for middleware design based on concurrent event-based AOP Edgar Marques Luís Veiga, Paulo Ferreira INESC-ID / Tech. Univ. Lisbon

2. Outline • Motivation • Problem • AOP • Basic concepts • Typical concerns • Our approach • Architecture • Programming model (example) • Extending the framework • Implementation • Evaluation • Conclusions and future work

3. 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...

4. 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 programmer • Involves dealing with low-level issues (e.g. data management, security, etc.) • Time-consuming and error-prone

5. Solution? • Encapsulate such features in a middleware solution • General 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 questions • How 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

6. 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...

7. 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

8. 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 aspects • Aspects which trigger on a sequence of join-points • Distributed aspects • How to define pointcuts which involve different processes running in distinct network nodes? • ...

9. 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 reusability • Pointcut definition is separated from advice / introduction definition

10. 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 extensible • Issues 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

11. Architecture

12. Event raising at join-point and advice execution

13. 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++;...} ... }

14. 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, ...) {...} ... }

15. 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

16. Implementation • Based on compile-time source-weaving • Build 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);

17. Evaluation • Performance overhead of our framework • Process/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-benchmark • Overhead 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

18. Time overhead for advice executionon a join-point

19. Conclusions and future work • Java framework for middleware design • Based on CEAOP • Focus on aspect reusability • Small, generic and extensible through meta-aspects • Future work • Performance 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/