Aspects in the Real World
Applying AOSD techniques in large
systems
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)
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
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
Aspect-driven homogeneous policies



Intuitively it seems that Aspects are wellsuited 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
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
Refactoring Process

Concern Modelling

Visualization

Concern-based queries

Refactoring (AO & OO)
Run Query
Analyze
Query
Report
Alter EJB Support
pointcut definition
Refactor
Component
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.";
}
Sample Refactoring – Bank Account
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

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() {
}
}
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"));
}
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"));
}
}
}
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?
Peculiarities of AO Refactoring

Approach towards crosscutting functionality


Applicability of aspect's crosscutting


Limiting the scope of the aspects
Coupling consideration


Prototype conventional solution first?
Minimize coupling between classes and aspects
not as important
Placement of aspects

Keep aspects closer to targets (even nested)
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
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;
}
}
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;
}
}
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"/>
</aspect>
Issues for commercial adoption
As proposed by BEA Systems







Usability
Agility
Integration
Expressiveness
Performance
Tool Support
Aspect Container
Usability


JLS Compatibility
Stays out of the way



Attribute definition



Developer can code just as usual in favorite IDE.
No immediate needs for custom plugins and specific tool
support.
Self-defined and self-contained aspects
Easier to build reusable aspect libraries
XML definition

Allows loose coupling between advice and pointcuts
Integration


How to weave the aspects?
AW uses JVM-wide hook mechanism to control all
class loading (load-time weaving)



AW also does runtime weaving



Easier to work with application servers
Weaving is platform/vendor independent
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)
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
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
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
Addendum – AspectJ Design Patterns

http://www.cs.ubc.ca/~jan/AODPs/
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
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)
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
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
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
QuO Example
 Document Server
// Document Server IDL
module Document {
typedef string Query;
typedef string DocumentData;
typedef sequence<octet> 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
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;
)
)
)
)
Concern Manipulation Environment

Tools to support usage of AOSD throughout
software lifecycle

Concern Composition Component


Concern Manager




Composes/weaves different concerns in any of the supported
artifact languages supported by the CME.
Models software in terms of arbitrary concerns and their
interrelationships.
Concern Assembler Toolkit
Concern Informant Toolkit
Pattern Underlying Matcher