Large Scale AOSD for Middleware

decorumgroveInternet and Web Development

Aug 7, 2012 (4 years and 10 months ago)

359 views

1

Aspects in Middleware

1
: Adrian Coyler, Andrew Clement

2
: Charles Zhang, Hans
-
Arno Jacobsen



Presented by: Itay Maman

2

Scope (
1
/
2
)


Middleware platforms offer great aspect
opportunities


Many policies


Many applications from different vendors


Must be highly customizable



On the other hand, there are many obstacles


Customers are reluctant to switch to a new platform


Complexity of the code/System


=> New bugs due to aspectization


3

Scope (
2
/
2
)


Our focus: lessons learnt while refactoring existing
middleware products


Original language: Java


Aspect technology: AspectJ


What makes middleware good AOP candidates?


Refactoring process


Discussion of benefits



We will
NOT

talk about developing an AOP
-
based
middleware from scratch



Complex terminology


Middleware, Three
-
tier application, Components, ...

4

Three
-
tier application

Three
-
tier application
:

An application that is organized into three
major distributed parts:

User interface (client program),

Functional processing (business rules),

and Data storage (Database)


A Common architecture for Enterprise applications


E.g.: Banks, Hospitals, Phone companies,




May get complex


More than one database


A Data storage may be a separate three
-
tier application itself


Multiple types of clients


Redundancy

5

Example: A Three
-
tier application


Browser

Database

Server

HTTP

JDBC

First Tier

Second Tier

Third Tier

6

The middle tier


The middle tier is the heart of the system


The design of the other tiers is complex but
almost mechanical


Includes most of the domain
-
specific
programming:


Algorithms & calculations


Decisions


Behavior


Usually: Encapsulation using components


(See next slide)


7

Components

Components
:

A reusable program building block that can
be combined with other components in the
same or other computers to form an
application


Examples: Enterprise Java Beans, DCOM


EJBs


Managed by a J
2
EE server


Two classifications:


Session Bean/Entity Bean


Stateless/Stateful

8

Welcome to the world of J
2
EE

Browser

JSP

Accounts EJB

Database

J
2
EE Server

HTTP

RMI

JDBC

First Tier

Second Tier

Third Tier

Servlet

Employees EJB

RMI

JDBC

9

Middleware, Application Server (
1
/
2
)

Middleware
:

Software that mediates between two
separate and often already existing
programs


Categories of middleware:


Infrastructure middleware


Distribution middleware


Common middleware services


AKA: Application Server


Domain Specific middleware

10

Middleware, Application Server (
2
/
2
)

Application Server
:

A server program (typically running on a
dedicated computer) that is dedicated for
running certain software applications


The two terms describe different levels of the same
concept


An application server is just a sophisticated type of
middleware


We will use both terms interchangeably

11

Inspection of middleware needs


Two approaches

1)
Analytic: What is so unique in middleware
platforms?

2)
Programmatic: What is needed in a typical
component code?


12

Analytic approach (
1
/
3
)


Let

s compare Application Servers (AS) with
Operating Systems (OS).



It turns out that both are platforms, which:

a)
Launch applications

b)
Supply core services to these applications

c)
Let programmers focus on domain specific
tasks


On the other hand, there are some key differences


13

Analytic approach (
2
/
3
)


Application Server (AS) vs. Operating System (OS):


Variability of applications


A single AS invokes a specific set of applications


A desktop computer launches all sorts of programs


Interconnectivity


Usually, components in an AS communicate with each
other


In an OS most applications are stand
-
alone


Money invested


A customer is willing to pay to customize his AS


14

Analytic approach (
3
/
3
)


Summary of differences


An AS is more coherent


An AS must be highly customizable



stop
-
install
-
reboot


is usually not an option




The solution: Aspects



15

Programmatic approach (
1
/
3
)


Forces in Enterprise applications


Availability/Fail Safety/Recoverability


Multiplicity


Transaction Management


Scalability


Concurrency


Security


Simplicity of the algorithms


Backwards compatibility


Heterogeneity


Of platforms (HW, OS), languages, tools



Non functional requirements (?!?)

16

Programmatic approach (
2
/
3
)


Standard J
2
EE services



Dynamic web pages: JSPs, Servlets


Components: EJBs


Naming: JNDI


Messaging: JMS


E
-
Mailing


Transactions: JTA


Authentication


Imported from J
2
SE:


Remoting: RMI


DB connectivity: JDBC


XML


Other services may be provided by a specific implementations


Not part of the J
2
EE standard



Functional requirements (?!?)

17

Programmatic approach (
3
/
3
)


What is left for the programmer to do?


1)
Invoke J
2
EE services


Lookup,iterate,put,get,remove,send,receive


2)
Write domain specific algorithms/behavior


Which are typically not complicated


3)
Address various concerns


concerns which correspond to the non functional requirements


-

or
-


classical


aspects: Logging, error handling,




The
3
rd task (

Address various concerns

) is the most
complex one


Due to its cross cutting nature


Due to lack of support from the J
2
EE platform



The solution (again): Aspects

18

Classification of concerns in middleware


Conformance to a policy (homogenous)



When to log?

,

When to release a resource?

,



Homogenous: Same treatment in all locations



Scattered behavior (heterogeneous)


User authentication,Database connectivity,



Heterogenous: Treatment varies



Tier cutting concerns


Compression, Encryption,



Very interesting, but out of this lecture

s scope



Relevant to: middleware code, components code

19


Large scale AOSD for Middleware



Work of Coyler, Clement (IBM)



Used the

Websphere


application server


An IBM product


J
2
EE complaint



The idea:


Identify cross cutting concerns


Refactor them into aspects


Compare the aspectized system with the original

20

Homogenous concerns (
1
/
2
)


The WebSphere source code should conform to
several predefined standards (policies)



Each policy is defined by a specification document



Three such policies were investigated


Tracing and logging


First Failure Data Capture (FFDC)


Monitoring and statistics



Each policy creates a homogenous concern

21

Homogenous concerns (
2
/
2
)


The investigation process


Encapsulate each policy in an abstract aspect


Defines how the policy is to be applied


Write a concrete sub
-
aspect for each component


Provides concrete specification of pointcuts


Weave the advices into the program


Compare the augmented program with the original


(No details were given about the comparison process)



Results


No numerical data is reported


The authors claim that many locations were found where
the policy was not followed by the original program

22

Heterogeneous concerns (
1
/
6
)


The motivation: Decompose a certain service
(feature) off the middleware


Find the code which is part of the service


Place the code in dedicated classes/aspects


Use AspectJ to build two different flavors of the
system:


Feature turned on


Feature turned off



The problem: How to find all pieces of code
which implement a feature?


(see next slide)

23

Heterogeneous concerns (
2
/
6
)


(The problem: How to find all pieces of code which
implement a feature?)


The solution: An iterative semi
-
manual algorithm

[
1
] Choose an initial set of classes: S


(These classes are known to be part of the feature)


[
2
] for each code site that calls methods of classes in S:


[
3
] If the site takes part in the implementation


of the feature, add its class to S


(Move the site to a new class if needed)


[
4
] Go back to [
2
] if S has changed in the last pass


The challenge: Automation of step [
2
]

24

Heterogeneous concerns (
3
/
6
)


Q: What

s the easiest way to implement step [
2
]?

public aspect

EJBSeparation {


pointcut

inEjb() {


within
(T
1
) ||


within
(T
2
) ||


...;


}



pointcut

ejbCall() {


call
(* T
1
.*(..)) ||


call
(* T
2
.*(..)) ||


...; }



declare warning

:


ejbCall() && !inEjb() :


"Link to EJB Support found";

}


A: AspectJ!


This aspect finds all location which use the EJB service

25

Heterogeneous concerns (
4
/
6
)


The process:


Run Query (Aspect)


Inspect results (warnings)


Refactor


Add classes to pointcut definitions

public aspect

EJBSeparation {


pointcut

inEjb() {


within
(T
1
) ||


within
(T
2
) || ...; }



pointcut

ejbCall() {


call
(* T
1
.*(..)) ||


call
(* T
2
.*(..)) || ...; }



declare warning

:


ejbCall() && !inEjb() :


"Link to EJB Support found";

}

Analyze
Query
Report
Alter EJB Support
pointcut definition
Run Query
Refactor
Component
Analyze
Query
Report
Alter EJB Support
pointcut definition
Run Query
Refactor
Component
26

Refactoring (of EJB support)


Original code

public class A extends B {



public void init() {


one();


add();


two();


}



void add() { }

}


public

aspect

EJBAspect
1
{


EJBContainer ejbc;



pointcut

registration(A ci) :


execution
(* add()) &&
this
(ci);



before
(A ci) : registration(ci) {


ejbc = newContainer();


if(ejbc != null)


register(ejbc)


}

}

public class A extends B {


private EJBContainer ejbc;




public void init() {


one();


ejbc = newContainer();


if(ejbc != null)


register(ejbc)


two();


}

}


Refactored code

27

Heterogeneous concerns (
5
/
6
)


The concern which was factored out:


EJB support


Results


The two flavors passed all J
2
EE conformance tests


Except for EJB related tests in the

off


flavor


Slight improvements when EJB support is off


Performance


Footprint


Startup time

28

Heterogeneous concerns (
6
/
6
)


Why was EJB support chosen?


This is one of the

heaviest


services offered by
WebSphere.


As such, we would expect one to choose a simpler
feature for this type of research


A speculation:


EJB support is one of the primary functional
requirements of a J
2
EE server


=> The system was designed

around


this service


=> The System

s primary decomposition does not cut
the EJB service


=> It is relatively easy to refactor it

29


Quantifying Aspects
…”

(
1
/
3
)


Work of Zhang, Jacobsen (University of Toronto)


Full name:

Quantifying Aspects in Middleware Platforms




Used the

CORBA


middleware


A Distribution Middleware


Less sophisticated than an application server (WebSphere)



Methodology: Similar to the previous work


But, OO metrics were used to evaluate the benefits of AOP

30


Quantifying Aspects
…”

(
2
/
3
)


Investigated aspects


Homogenous: Logging, Error handling, Synchronization, pre/post
conditions


Heterogeneous: Dynamic programming model, Portable
interceptors



OO Metrics


Size: Total number of executable lines


Weight: Number of methods per class


CCN: Number of unique execution paths per method


Coupling: Average number of other classes

known


by a class

31


Quantifying Aspects
…”

(
3
/
3
)


Results:

Coupling

Weight

Size

CCN

21.13

16.5

5893

4.2

Original

18.33

16

4899

4.04

Refactored


Analysis:


All metrics decreased in the refactored program


This indicates that the primary code became simpler


Though the complete program code is just as complex


It is difficult to evaluate the significance of the
improvement

32

Summary



Various concerns in middleware


Homogenous


Heterogenous


Tier
-
cutting



AOP refactoring


Using aspects (!) to find concerns


Changing the original code to make it aspect
-
friendly



Numerical indications to the benefits of the
refactroring process

33

-
The End
-

34

Welcome to the world of Middleware


Browser

JSP

EJB

Database

J
2
EE Server

HTTP

RMI

JDBC

First Tier

Second Tier

Third Tier

Servlet

35

Welcome to the world of Middleware

Analyze
Query
Report
Alter EJB Support
pointcut definition
Run Query
Refactor
Component
Analyze
Query
Report
Alter EJB Support
pointcut definition
Run Query
Refactor
Component