An Overview of Aspects

1. An Overview of Aspects Shmuel Katz Computer Science Department The Technion Email: katz@cs.technion.ac.il

2. Overview • Motivation and Background • AspectJ: the standard for AOP • Some other languages • Aspects and design • Validating aspects • Some challenges

3. Basic claim of AOP • Pure Object-Oriented doesn’t work!!! • Gives one central decomposition—but others are possible, and sometimes needed • Cross-cutting concern: one that involves many classes/methods • Tangling: code treating the concern is mixed with that for other concerns • Scattering: code treating the concern is scattered throughout the system

4. A Personal Note: My Interest • Early work on Superimpositions for distributed systems: identical motivation • Part of core group of EU’s 6th programme for a Network of Excellence on Aspect Oriented Software Development—beginning now… • My work on aspects: • connecting requirements to proof; • Design for aspects in UML; • Specification and Correctness for aspects

5. Augmentations as subjects • Syntax: how to express them? • Classification: What types are there? • Spectative: only observes/records • Regulative: affects control/ termination • Invasive: changes values of existing fields • Specification: what do they add, to what? • Correctness/validation: how do we know they do what is intended?

6. Aspects and Superimpositions:Modularity for Cross-cutting • For distributed: • Termination detection (Regulatory) • Monitoring (Spectative) • Fault-tolerance (Invasive) • For Object Oriented • Monitoring and debugging • Adding security • Preventing overflow • Enforcing a scheduling policy • Analyzing QOS and Performance

7. Aspects (and esp. AspectJ) • Aspects: modular units that crosscut classes • Aspects are defined by aspect declarations and may include • pointcut declarations: where to add/replace • advice declarations: what to add or do instead • Can introduce new methods, variables, code… • Weave (=bind) aspect to different systems (but not entirely separated yet…)

8. Pointcuts • A program element that identifies join points • Denotes a (possibly empty) set of join points • kind of join point • signature of join point • Can be dynamic (calls within a context, look at stack) call(void Line.setP1(Point)) Denotes the set of method call join points with this signature signature primitive pointcut

9. Advice • Additional action to take at join points • Defined in terms of pointcuts • The code of a piece of advice runs at every join point picked out by its pointcut pointcut move() :call(void Line.setP1(Point)) ||call(void Line.setP2(Point)); after() returning : move() {< code here runs after completion of each join point denoted by move > } advice type parameters pointcut advice body

10. Types of joinpoints and changes • Method calls • Changes/uses of a field (variable) • Method calls while another method is active (relates to stack contents) • Add code before/after/around joinpoint • Replace previous with new code • Often use types, fieldnames,…, from the rest of the system (not fully generic)

11. Advice types • before • Before proceeding at join point • after returning • After execution of a join point completes normally • after throwing • After execution of a join point ends abnormally (exception is thrown) • after • After execution of a join point (completing either way) • around • On arrival at join point gets explicit control over when and if program proceeds

12. Some History • AspectJ started at Xerox Parc, in a team led by George Kiczales • First presented in a paper at ECOOP97, updated at ECOOP01 • Today, it is incorporated into Eclipse, and its homepage is there. • Kiczales is at U. British Columbia

13. Obliviousness: a Basic Principle? • AspectJ assumes underlying system is unaware of any aspects: no explicit hooks • Aspects either are or are not applied…the system can function in either case • Is this necessary, or always possible?

14. Languages for Aspects • AspectJ—the standard, seen so far • HyperJ ---IBM’s approach to slices (Ossher..) • Treats Concerns, • Less rich way of adding, but adds whole slice • Composition filters • Only at method calls, cleaner treatment • Mehmet Askit, U. of Twente • Demeter, Ceasar, Jasco, JAC,…

15. Hyper/J • Decomposition of a system to Concerns • Some concerns conform to class hierarchy—others do (and can) not • Define hyperslices • One logical decomposition: Company has Research, Sales, Services, etc. • Another: Company has Payroll, Reporting, Managing, Work tasks • Can move between decompositions

16. Declarative Completeness • Each concern in a hyperslice: • Must declare everything to which it refers • Don’t need to provide a full definition for these declarations • Thus, declaration can be abstract • Highly important because : • Every hyperslice must represent a legal java program • Creating self contained hyperslices • Reuse and replace • Can be done automatically by Hyper/J

17. Relationships between Hyperslices Need to define: • Composition rule: Specify how hyperslices relate to one another, which units correspond • Brings up issues like: • Are two corresponding methods… • Overriding one another? • Both executed? What order? Return value? • What if types of parameters are different?

18. Hyper/J VS. Aspect/J • Aspect/J is a language • Hyper/J is a tool with language elements Aspect/J supports augmentation of single model • Aspects augment classes & methods of distinguished base hierarchy • Hyper/J supports integration of multiple models • Can integrate few base hierarchies • Less rich notation for Joinpoints • Aspect/J – incremental changes only

19. Some language issues • Dynamic aspects: are they applied only at compile time, or dynamically added or removed? (When can we weave?) • Genericity: do aspects refer to elements in the underlying system, or can they be reused for many systems? • Efficiency versus Expressiveness • Correctness and validation: how to specify and verify/test aspects?

20. Aspect Oriented Software Design • Beyond programming languages and implementations • What should be in an aspect, or collection of aspects? • How may aspects interact? • Cooperate in Combinations of aspects • Interfere • How to capture in design stage?

21. Examples of Early Aspects • Theme/UML: adding aspects to UML, as reusable modules to add to existing systems • Can Persistence be viewed as an aspect? • Answer: yes, but not if application is oblivious • Web caching as an aspect • Extensions to UML to describe relations among aspects in a Concern Diagram

22. Support for AOSD: CME • IBM’s Concern Manipulation Environment (T.J. Watson/Hurley) for Hyper/J and AspectJ • An Eclipse AOSD Environment (as an Eclipse Open Source Project?) • Concern Explorer (part of JDK): finding them.. • Concern Manager • Concern Visualizer • Concern Composition (Weaver) for multiple languages

23. Aspects for Components • Some Aspects should be made into components (but how?) • Some Components should be Aspects! • Aspects can be associated with a component to allow customization • Component Architectures are implemented with wrappers and capture method calls

24. Services of JEBs replace aspects • Encryption, Authentication, Persistence can all be handled by standard services • Restricted to message-call pointcuts • Has a built-in fixed solution, hard to modify or configure • Does isolate part of what aspects do…

25. Implement components using Aspects • Some experiments have been done • Most promising direction: keep component architecture with stubs and skeletons, and use it to implement AOSD constructs in a language-independent way • A potential problem: lack of standardization in services and language support

26. Prominent example: JBoss • JBoss is an open-source implementation of the J2EE platform • Developed independently and freely distributed • Full support for the latest J2EE specification • Passed Sun's certification tests • The following discussion is with regard to version 4.0 • Currently in "developer release" stages

27. JBoss and Aspects • The lead developers of JBoss believe that AOP "should have the same effect on software development that object-oriented programming (OOP) had 15-20 years ago" • B. Burke (Chief Architect) and A. Brock (Director of Support), 2003 • As a J2EE platform, JBoss provides the standard EJB aspects/services • However, JBoss also includes a built-in AOP framework and is written using aspects

28. Sources • AOSD homepage: http://www.aosd.net • AOSD Conferences in 2002, 2003, 2004 • CACM issue of October 2001 • AspectJ homepage: http://www.eclipse.org/aspectj • Composition filters, Caesar, others,… • Books on aspects

29. Topics 1a 1b– 31/10 Basic syntax, principles and examples for AspectJ and use in Eclipse (the standard aspect language) • 2a – 7/11 HyperJ: language and concepts of general concern combination • 2b -- HyperJ and Concern Manipulation Environment (CME) • 3a – 14/11 Composition filters: an elegant message-based approach • 3b -- Composition filters support environment and analysis • 4a – 21/11 Demeter: interesting ideas on dynamic aspects • 4b -- Ceasar: dynamic aspect application and development

30. Topics (cont.) • 5a – 28/11 JasCo: an aspect language intended for components • 5b -- JAC an environment for system development with aspects in Java • 6a – 5/12 Implementation issues: advice weaving in AspectJ • 6b Static analysis of aspects • 7a – 12/12 Just-in-time aspects • 7b Virtual machine support for dynamic joinpoints • 8a 19/12 Event-based aspects in EAOP • 8b Composition, reuse, and interaction of stateful aspects

31. Topics (cont.) • 9a – 26/12 Verifying aspect advice modularly • 9b – Aspect Validation and aspects for specification • 10a – 2/1 Theme/UML: extending UML for aspects • 10b – Architectural views of aspects in UML • 11a – 9/1 Scenario-based specification of aspects • 11b – Aspect requirements and traceability: Arcade /Probe • 12a – 16/1 Large-scale AOSD for middleware: a case study • 12b – JBOSS and aspects for middleware • 13a – 23/1 AspectWerkz: a framework for AOdevelopment • 13b – BBN and other frameworks for aspect development