Resolving Feature Convolution in Middleware Systems OOPSLA 2004 Session Aspects in the Middle

1
Resolving Feature Convolution in Middleware
SystemsOOPSLA 2004Session Aspects in the
Middle

• Charles Chuan Zhang and Hans-Arno Jacobsen
• Middleware Systems Research Group
• Department of Electrical and Computer Engineering
• Department of Computer Science
• University of Toronto

2
Agenda

• Background middleware and AOP
• Goal high degree of customizability
• Problem feature convolution
• Solution principles for untangling convolution
• Result modularity in two dimensions

3
Background

• Middleware
• Working definition a set of services
  facilitating the development and the deployment
  of distributed applications.
• This talk software substrate enabling
  transparent remote method calls, such as CORBA,
  Java RMI, .Net Remoting, and Web Services.

remote invocation
client
server
network
interface account ... account withdraw(...)

amount 1000 account.withdraw(amount)
4
Background Aspect Oriented Programming

• Crosscutting concerns whenever two properties
  being programmed must compose differently and yet
  be coordinated, we say that they cross-cut each
  other (G. Kiczales et al., 1997)
• AspectJ (http//www.eclipse.org/aspectj)
• Java language extensions
• Modularization of both instrumentable points in
  the program execution and code to run at these
  points.

5
AOP
The aspect oriented programming paradigm treats
crosscutting concerns as first-class entities.
aspects
Tangled code
6
Goal High Degree of Customizability

• Difficult to pre-determine middleware
• functionality due to independent factors
• Conflict Generality and specialty
• Generality many
• Specialty less
• Orthogonal Domain features and platform
• Domain features QoS, high availability,
• Platform desktop, mobile device,

7
Configurability Map

• A unit of configuration is a point (feature,
  platform)
• A configuration is a set of points

Feature dimension
QoS
Configuration x
Configuration t
Dynamic types
Configuration z
Synchrony
Asynchrony
Security
Configuration y
Platform dimension
Mobile
Desktop
Embedded
Enterprise
Smart card
8
Problem Feature Convolution

• Feature convolution N-by-N crosscutting of
  multiple orthogonal features

9
Application of AOP to Large Systems

• What is an aspect? (ambiguity)
• What functionality to code as aspects?
• What functionality not to code as aspects?
• What is the relationship between objects and
  aspects?

10
Horizontal Decomposition (HD) Principles

• 1. Recognize the relativity of aspects
• (ambiguity)
• 2. Establish the minimum and coherent core
• decomposition (domain aspects)
• 3. Define the semantics of aspects with respect
• to the core decomposition
• 4. Maintain a class-directional architecture
• towards the core
• 5. Apply incremental refactoring (refinement)

11
Horizontal Decomposition (HD) Etymology

• Vertical
• Dijkstra and Parnas
• Factored solution
• Hierarchical abstractions
• and implementations
• Horizontal
• Complementary sets of structures
• Determine where and how to use aspects

12
First HD Principle Relativity

• Principle 1 Recognize the relativity of aspects.
  The semantics of an aspect is determined by the
  primary functionality of the application
• If A crosscuts B, A is an aspect relative to B
• Aspects are defined according to the primary
  functionality of the application
• Well-known statements
• Logging is an aspect
• Distribution is an aspect
• Essential for analyzing large systems

with respect to
with respect to
13
Second HD Principle Core

• Principle 2 Establish the coherent core
  decomposition. The basis of aspect oriented
  decomposition is the establishment of a
  functionally coherent and vertically decomposed
  core
• Definition
• The minimum coherent decomposition of the primary
  functionality
• Purpose
• Reference architecture for defining domain aspects

14
Third HD Principle Aspects according to the core
decomposition

• Principle 3 Define the semantics of an aspect
  according to the core decomposition. Using the
  core as a reference, a functionality is
  considered orthogonal if both its semantics and
  its implementations are not local to a single
  component of the core. Only the orthogonal
  functionality is treated in the aspect oriented
  way
• Not only Ilities (Security, Manageability,
  Reliability, QoS) treated as aspects
• Asynchronous Invocation Style is an aspect

15
Example Local Invocation Optimization is an
aspect
Remote Invocation (ORBacus)

• When using transparent remote invocation, the
  location of the remote service is hidden and
  could be in the same process as the client
• A common optimization is that middleware
  transparently detects this situation and directly
  dispatches the request without going through the
  network layer.

16
Example Local Invocation Optimization is an
aspect

• The sequence becomes more complex
• Ability of plugging out this feature

17
Middleware Core Our current Definition

• Minimum and coherent core (vertical dimension)
• Aspects (horizontal dimension)
• Asynchronous messaging, dynamically typed
  messages, Dynamic Invocation Interface,

Core structure
Core functionality
Primitive data types integer, string Synchronous
invocation Statically typed messages
18
Fourth HD Principle Class-directional
architecture

• Principle 4 Maintain a class-directional
  architecture. Crosscutting concerns should be
  implemented class directional towards the core.
• Class-directional is a category of relationships
  between base modules (classes) and aspects in
  which aspects know about the class but not
  vice-versa

19
Fifth Incremental refactoring

• Principle 5 Apply incremental refactoring.
  Decomposition in the aspect dimension is assisted
  by incremental refactoring.
• Refactoring is a disciplined technique for
  restructuring an existing body of code, altering
  its internal structure without changing its
  external behavior (from http//www.refactoring.com
  /)

20
Problem Feature Convolution

• Feature convolution N-by-N crosscutting of
  multiple orthogonal features

21
Problem Feature Convolution in Action
public Downcall createPIDIIDowncall(String
op, boolean resp, ) throws
FailureException com.ooc.OCI.ProfileInfoHolde
r profile new com.ooc.OCI.ProfileInfoHold
er() Client client getClientProfilePair(prof
ile) Assert._OB_assert(client ! null)
if(!policies_.interceptor) return new
Downcall(orbInstance_, client,
profile.value, policies_, op, resp)
PIManager piManager orbInstance_.getPIManager()
if(piManager.haveClientInterceptors())
return new PIDIIDowncall(orbInstance_, client,
profile.value, policies_, op, resp,
IOR_, origIOR_, piManager, args, result,
exceptions) else return new
Downcall(orbInstance_, client,
profile.value, policies_, op, resp)

DII
PI
Asyn

Validation



client


stub

Downcall
22
Untangling Convolution
Configurable systems
Convoluted code
Modularized concerns


23
1 public Downcall 2 DowncallStub.createDIIDowncall
(String op,//arguments 3 omitted) 4 throws
FailureException 5 ProfileInfoHolder profile
new ProfileInfoHolder() 6 Client client
7 getClientProfilePair(profile) 8
Assert._OB_assert(client ! null) 9 return
new Downcall(orbInstance_, client, 10
profile.value, policies_, op) 11
1 after() returning (Client c) 2
call ( .getClientProfilePair(..)) 3
Assert._OB_assert(c!null) 4
Validation E

• Configurability options
• A (Vanilla Downcall)
• A, B (DII Downcall)
• A, C (PI Downcall)
• A, B, C (PI DII Downcall)
• A, B, C, D (PI DII Async Downcall)
• A, C, D (DII Async Downcall)
• .
• 24 16 possible configurable combinations

DII B
1 after(DowncallStub s) returning (Downcall
downcall) 2 target(s)call(createDIIDowncall(
..)) 3 if(!s.policies_.interceptor) 4 return
downcall 5 PIManager piManagerorbInstance_.get
PIManager() 6 if(piManager.haveClientInterceptor
s()) 7 return new PIDIIDowncall(//arguments
omitted) 8 9 else 10 return downcall 11
12
PI C
1 aspect oneway 2 Hashtable responseflgs new
Hashtable() 3 //response table is initialized as
an earlier stage 4 after(DowncallStub s)
returning (Downcall downcall) 5 target(s) 6
call( DowncallStub.createDIIDowncall(..) 7
Object flag responseflgs.get(s) 8
downcall.responseExpected_ (flagnull) 9
Oneway D
24
Validation of HD Refactoring Legacy Middleware

• CORBA as a case study
• ORBacus
• Industrial strength CORBA implementation
• Around 2000 classes, 180K lines of Java code

25
Outcome

• Major functionality as aspects
• Data types (string, IDL any, etc.)
• Communication styles
• Code size shrunk by 40 in supporting essential
  functionalities
• Maintain performance on standard benchmark
• Achieve pluggability of features without manual
  code changes

26
Related Work

• Current applications of AOP to middleware
• QoS QuO (QDL), COMQUAD (CQML)
• Crosscutting service DADO
• Customizability FACET, WebSphere product-line
• Traditionally modularized middleware
• Adaptive middleware Reflection (OpenORB,
  DynamicTAO, CompOSEQ )
• Customizable middleware LegORB, UIC
• Feature-oriented Programming
• Share similarities
• Application of HD to FOP?

27
Conclusions

• Horizontal decomposition principles constitutes
  an attempt in analyzing and applying AOP to
  middleware
• HD principles are effective in refactoring large
  systems with aspects
• Essential functionality in vertical composition.
  Untangled features in aspect composition

28
(No Transcript)