Reference Architecture for Aspect Oriented Middleware

1
Reference Architecture for Aspect Oriented
Middleware
2
Background

• AOSD-Europe
• A virtual network of sites across Europe
  exploring issues related to AOSD.
• Survey of Traditional and AO Middleware
• Middleware is becoming more complex
• AO middleware can ease this complexity and
  satisfy criterias of flexibility, performance and
  reliability in a more balanced manner.
• However, there now seems to be a diversity of AO
  Middleware platforms with differing concepts.
• We therefore require a reference model
• to map these concepts across different AO
  platforms.
• To provide unified model of AO in order to add
  notion of aspect orientation to non AO
  middleware.
• Survey Document available at
• http//www.aosd-europe.net/deliverables/d8.pdf

3
What is the AO Reference Architecture?

• From the abstract.
• ..The reference architecture provides a common
  reference point for the creation of key concerns
  which can then be mapped to a particular Aspect
  Oriented Middleware (AOM) platform. Additionally,
  the reference architecture facilitates the
  creation of new AOM platforms themselves..
• a generic reference architecture
• aspect composition in heterogeneous and dynamic
  environments
• provide a conceptual vocabulary for AO middleware
  systems
• facilitate the analysis, comparison and
  discussion of AO middleware platforms
• embody and encourage best practice and patterns
  in the design of AO middleware systems
• to form the basis of middleware implementation
  toolkits

4
Reference Architecture

• The reference architecture is layered into three
  levels
• Level One is the component model and abstract
  pointcut language (APL)
• Level Two contains key concerns mapped to the
  component model and APL
• Level Three is
• a mapping of the concerns in Level Two to
  specific AO middleware platforms
• Aspectising current non AO middleware

5
Level One
6
Component Model
7
Microkernel Operations

• LOAD Loads a specified component into the
  container
• UNLOAD Unloads a specified component from the
  container
• START Services the requests send to the
  component
• STOP Stops servicing the requests send to the
  component
• BIND Creates a binding between components via
  specified provides and requires interfaces
• UNBIND Unbinds specified bound components
• INSTANTIATE Instantiates a specified component
• DESTRUCT Destroys the component instance,
  freeing up memory.

8
Abstract Pointcut Language (APL)

• Pointcut/Joinpoint
• A Pointcut describes a set of joinpoints. A Join
  Point is a well-defined place in the structure or
  execution flow of a program where additional
  behaviour can be attached.
• From AOSD Ontology available from
  www.aosd-europe.net
• Design Goals of APL
• Provide a generic framework for expressing
  pointcuts
• Language neutrality to ease mapping to a concrete
  pointcut language
• Use for component based applications, therefore
  no assumptions on the way components are
  implemented (e.g. classes, functions, etc.)
• Allow definition of distributed pointcuts

9
APL Join Point Types

• Express quantifications over a set of component
  related join points
• Two levels with a set of join points defined in
  each
• Transport level
• Application level
• A pointcut may be defined which picks out join
  points in one of the two levels or in both.

10
Transport Level Join Point Types

• Transport level is concerned with sending and
  receiving messages over the network.

• Definition of four different types of transport
  level join points
• Request sending (client side)
• Request receiving (server side)
• Reply sending (server side)
• Reply receiving (client side)

11
Application Level Join Point Types

• Application level is where middleware meets the
  language
• Definition of two different types of application
  level join points
• Incoming calls on provided interface operations
• Similar to execution join points in AspectJ
• Outgoing calls on required interface operations
• Similar to call join points in AspectJ
• However, join points are coarser grained in our
  component based model compared to language based
  join points of AspectJ

12
Domain Definitions

• In conformance with our component model an
  application will be defined by the following sets
  ltCT,C,I,Ogt where
• CT is the set of containers on which the
  application is deployed
• C is the set of components of the application
• I is the set of component interfaces
• O is the set of operations.
• Need to take into account binding time
• Compile time weaving
• Dynamic weaving
• Therefore two categories of properties are
  assigned to these sets
• Static properties
• Dynamic properties

13
Static Properties

• Each ct ? CT owns a URI which can be referenced
  with ct.uri
• Each c ? C owns a name which can be referenced
  with c.name
• Each i ? I owns a name, a category (required or
  provided) and an interaction style (e.g. stream,
  request, signal), which can be referenced
  respectively as i.name, i.category, i.style
• Each o ? O owns a signature which can be
  referenced with o.signature
• Note that all names (i.e. ct.name, c.name and
  i.name) are assumed to be unique.

14
Dynamic Properties

• Dynamic properties are ltkey,valuegt pairs which
  can be attached to any architectural elements of
  the component model.
• Let x be an element of CT, C, I or O
• x.dynprop(ltkeygt,ltvaluegt) attaches the
  (ltkeygt,ltvaluegt) to the architectural element x
• x.dynprop(ltkeygt) retrieves the value attached to
  x with the given key, or null if the key does not
  exist

15
Pointcut Expressions Model

• Component-based pointcut expressions consist of 4
  terms
• ltctExpr, cExpr, iExpr, oExprgt
• Each sub-expression is a first order logic
  predicate selecting elements from CT, C, I and O
  sets.
• Sub-expressions may use
• Universal quantifiers
• e.g. ?o?O designates all the operations available
  in the application
• Comparison expression on property values
• e.g. ? i ? I, i.style ? request, stream
  designates all the request/response and stream
  interfaces (thus excluding signal ones)
• Pattern matching operations for string-like
  properties
• Boolean operators ? (logical-AND) ? (logical-OR)
  and ! (logical-NOT).

16
Examples

• ? ct ? CT, ? c ? C, ? i ? I, ? o ? O
• picks out all the join points (incoming and
  outgoing calls) for all the containers,
  components, interfaces and operations.
• ? ct ? CT, ? c ? C, ? i ? I, ? o ? O
• c.nameBank ? i.category?provided ?
  o.nameset
• picks out all the join points for set
  operations located on the provided interfaces of
  the Bank component.
• ? ct ? CT, ? c ? C, ? i ? I, ? o ? O
• c.nameBank ? c.dynprop(bean)entity
• picks out all the join points for the components
  named Bank with an attached property bean which
  values to entity.

17
Embedding Language Level Pointcut Expressions

• The pointcut model introduced so far allows
  expressing component level pointcuts.
• In some cases, we may need to cross the
  boundary of the component to express pointcuts
  relying on language elements.
• The function embed() to embed a language level
  pointcut expression.
• ? c ? C
• c.nameBank ? (let xc in embed(set(x
  point)))
• picks out all the component level join points
  located in the Bank component and all the
  language level join points which are setter
  operations on the point field defined in the
  implementation of the Bank component.

18
Level Two

• We mapped the following key concerns to the
  component model and APL
• Distribution
• Mobility
• Persistence
• Security
• Coordination
• Transactions

19
ExampleMapping of Persistence Concern
20
Core Persistence Functionality
Trap instantiations ? i ? I, ? o ? O i.category
? required ? o ? i.operations ? o.signature
PersistentRoot.new(..)
21
Complete Persistence Framework
22
Level 3

• Validation of the reference architecture
• Map the key concerns we specified in Level 2 to
  specific AO platforms
• JBoss AOP
• DAOP
• Add notions of AO to non AO middleware platforms
• OpenCOM
• Fractal

23
Open Issues

• Pointcuts only represent one element of AOP
• Still missing
• Introductions (allow refinements to existing
  components)
• Mechanisms for expressing precedence of
  operations
• Control flow function
• Other
• Embed function can be abused
• How should we expose interfaces on composite
  components.