1. Aspects in the Real World Applying AOSD techniques in large systems

2. Overview AspectJ Case Studies  IBM Websphere Introduction to AspectWerkz Issues for commercial adoption Discussion  What are the best/worst uses of AOP?  Is there a killer tool (or enhancement) still needed?  Advantages of AspectJ vs. HyperJ (Homogeneous vs. Heterogeneous concerns)

3. Case Studies IBM Websphere  Using AOP to solve middleware complexity issues Applying policies across product line Enabling optional features Efficient refactoring Other Studies  QuO – Programming QoS adaptive applications  COMQUAD

4. Homogeneous Crosscutting Concerns Homogeneous Concern applies consistent policy across code Tracing and Logging  Aspects are useful when dividing responsibility (component developers need not worry about implementing orthogonal policies in their code) Monitoring and Statistics Error Capturing  Catch ‘throws’ join point

5. Aspect-driven homogeneous policies Intuitively it seems that Aspects are well- suited to implementing tasks such as logging Question: is it worth re-engineering systems? IBM did some analysis of non-AO code  Admin component of Websphere 355 errors found (missing trace points, 33% of FFDC entries incorrect  Runtime component of Websphere Missing trace points, 17% of FFDC entries incorrect

6. Heterogeneous Crosscutting Concerns Heterogeneous concern impacts multiple places yet exhibits different behavior in each place Using aspects to perform efficient refactoring  Separate a feature of the system (EJB Support)  Goal: Create a refactored system that can build with or without EJBs  Problem: Large code base with many hard to find hooks into EJB code

7. Refactoring Process Concern Modelling Visualization Concern-based queries Refactoring (AO & OO) Analyze Query Report Refactor Component Alter EJB Support pointcut definition Run Query

8. Refactoring – Searching for Links public aspect EJBSupportSeparation { pointcut inEjbSupport() { within(T1) || within(T2) ||...; } pointcut ejbSupportLink() { call(* T1.*(..)) || call(* T2.*(..)) ||...; } declare warning : ejbSupportLink() && !inEjbSupport() : "Link to EJB Support found."; }

9. public class Account { private int _accountNumber; private float _balance; public Account(int accountNumber) { _accountNumber = accountNumber; } public int getAccountNumber() { AccessController.checkPermission( new BankingPermission("accountOperation")); return _accountNumber; } public void credit(float amount) { AccessController.checkPermission( new BankingPermission("accountOperation")); _balance = _balance + amount; } … Sample Refactoring – Bank Account

10. Add empty aspect/pointcut private static aspect PermissionCheckAspect { private pointcut permissionCheckedExecution() : (execution(public int Account.getAccountNumber()) || execution(public void Account.credit(float))) && within(Account); before() : permissionCheckedExecution() { }

11. Sample Refactoring – Bank Account Add crosscutting functionality (+ Warning) // optional declare warning: call(void AccessController.checkPermission(java.security.Permission)) && within(Account) && !within(PermissionCheckAspect) : "Do not call AccessController.checkPermission(..) from Account"; // end optional private pointcut permissionCheckedExecution() : (execution(public int Account.getAccountNumber()) || execution(public void Account.credit(float))) && within(Account); before() : permissionCheckedExecution() { AccessController.checkPermission( new BankingPermission("accountOperation")); }

12. Sample Refactoring – Bank Account public class Account { private int _accountNumber; private float _balance; public Account(int accountNumber) { _accountNumber = accountNumber; } public int getAccountNumber() { return _accountNumber; } public void credit(float amount) { _balance = _balance + amount; } private static aspect PermissionCheckAspect { private pointcut permissionCheckedExecution() : (execution(public * Account.*(..)) && !execution(String Account.toString())) && within(Account); before() : permissionCheckedExecution() { AccessController.checkPermission( new BankingPermission("accountOperation")); }

13. Results AspectJ compiler worked with over 20,000 source files  10.5% faster than javac with no aspects  30-50% increase in compilation with aspects (rest of build time unaffected) Queries are efficient when using CME Case for Test Driven Development?

14. Peculiarities of AO Refactoring Approach towards crosscutting functionality  Prototype conventional solution first? Applicability of aspect's crosscutting  Limiting the scope of the aspects Coupling consideration  Minimize coupling between classes and aspects not as important Placement of aspects  Keep aspects closer to targets (even nested)

15. AspectWerkz Dynamic AOP framework for Java Tailored for real world JLS compatible Definition syntax in XML and/or Attributes Load time, runtime and static weaving Allows redefinition of aspects at runtime

16. AspectJ Example aspect AsynchAspect { private ThreadPool m_threadPool =... Object around(): execution(void foo.bar.Baz.*(..)){ m_threadPool.execute(new Runnable() { public void run() { try { // proceed the execution in a new thread proceed(); } catch (Throwable e) { throw new WrappedRuntimeException(e); } }); return null; }

17. AspectWerkz Example class AsynchAspect extends Aspect { private ThreadPool m_threadPool =... /** @Around execution(void foo.bar.Baz.*(..)) */ Object execute(JoinPoint joinPoint) throws Throwable { m_threadPool.execute(new Runnable() { public void run() { try { // proceed the execution in a new thread joinPoint.proceed(); } catch (Throwable e) { throw new WrappedRuntimeException(e); } }); return null; }

18. XML Definition syntax <aspect class="samples.AsynchAspect" deployment-model="perJVM"> <pointcut name="executePoint“ expression="execution(void foo.bar.Baz.*(..))“/> <advice name="execute" type="around" bind-to=“executePoint"/>

19. Issues for commercial adoption As proposed by BEA Systems Usability Agility Integration Expressiveness Performance Tool Support Aspect Container

20. Usability JLS Compatibility Stays out of the way  Developer can code just as usual in favorite IDE.  No immediate needs for custom plugins and specific tool support. Attribute definition  Self-defined and self-contained aspects  Easier to build reusable aspect libraries XML definition  Allows loose coupling between advice and pointcuts

21. Integration How to weave the aspects? AW uses JVM-wide hook mechanism to control all class loading (load-time weaving)  Easier to work with application servers  Weaving is platform/vendor independent AW also does runtime weaving  Uses two-phase weaving (to prepare classes)  Multi-weaving. Classes can be woven, rewoven or unwoven at any point Slower startup time (scales poorly with large codebase and freely defined pointcuts)

22. Tool Support AspectWerkz currently lacks good tool support apart from:  Plugin for the Maven build system  Support for debugging aspects within an IDE  JUnit extension Standardization of attributes in JSR-175 will bring many tools for working with metadata

23. Dynamicity vs. Performance AspectWerkz is designed to have a dynamic runtime model, which means that the user can redefine his aspect system at runtime. To support a dynamic runtime model the framework makes use of delegation and reflection and introduces a level of indirection to allow the aspects and target classes to be loosely coupled. Runtime compiler, which has similarities with JIT compilers in modern JVMs, detects advice chains that are often executed and creates a custom class on the fly that invokes the advice chain and the target method statically. AspectWerkz makes heavy use of caching and lazy loading to improve the runtime performance

24. Discussion Best mechanism for weaving aspects Aspects as language extension or pure Best place to use aspects? AOP refactoring Test-Driven Development via AOP Need for AOP patterns

25. Addendum – AspectJ Design Patterns http://www.cs.ubc.ca/~jan/AODPs/

26. QuO toolkit The QuO Toolkit provides support for building systems with adaptive QoS Four main entities in the QuO model  Contracts: used to define adaptation policy  System Condition Objects: used to monitor the environment  Callbacks: used for middleware, system, and out-of-band application adaptation  Delegates: used for in-band application adaptation

27. Quality of Service issues in Distributed Applications Remote invocations  Can take longer than local calls  Might fail when local call doesn’t  Might expose security issues Impact of these factors varies during runtime due to environment Impact of the distributed application on the environment (changing operational mode)

28. Handling QoS Initial idea: modify code to examine situation and act accordingly  Violates distributed object model  Affects application code in many places Providing QoS management and control features in the system  Only partially successful since each application has specific QoS needs

29. QoS as an Aspect Build QoS management as an aspect and weave the result between application and middleware  aspect code has access to application-specific, middleware, and system information and controls without having to modify either the application logic or the underlying distribution middleware

30. QuO Aspect Model Delegates  Compile aspect into delegate which acts as proxy for calls to remote object and adds desired behavior to invocation Advice Model  applied to a particular method of a particular interface as specified in CORBA IDL  Join points METHODENTRY, PREMETHODCONTRACTEVAL, METHODCALL, POSTMETHODCONTRACTEVAL, METHODRETURN  Advice BEFORE, AFTER, INPLACEOF, ONEXCEPTION

31. QuO Example Document Server // Document Server IDL module Document { typedef string Query; typedef string DocumentData; typedef sequence Image; interface Server { DocumentData get_document(in Query q); Image get_image(in Query q); ); QoS Strategy  Operate Normally OR Compress images OR Give up

32. QuO Example Aspect behavior CompressImage () { qosket CompressImageDelegateQosket qk; ivar onserver quo::ValueSC allow compression; Document::Image Document::Server::get_image(in Document::Query q) { return value Document::Image rval; inplaceof PREMETHODCONTRACTEVAL onclient {} before METHODCALL onclient { q = qk.add_alloweompression{q); } after METHODENTRY onserver { allow_compression.booleanValue(qk.get_allow_compression(q)); ) after POSTMETHODCONTRACTEVAL onserver { region NetworkLoad { region CriticalLoad { throw CORBA::NORESOURCES; } region Compress { rval = qk.compress_image(rval); } region NoCompress { throw CORBA::NO_RESOURCES; )

33. Concern Manipulation Environment Tools to support usage of AOSD throughout software lifecycle  Concern Composition Component Composes/weaves different concerns in any of the supported artifact languages supported by the CME.  Concern Manager Models software in terms of arbitrary concerns and their interrelationships.  Concern Assembler Toolkit  Concern Informant Toolkit  Pattern Underlying Matcher