Applications Lab

1
Applications Lab

• Open AOSD Europe Workshop
• Glasgow

2
Outline

• brief overview of the Applications Lab
• general aim
• partners
• long-term objectives
• overview of previous and currently ongoing
  activities
• survey of AO middleware platforms
• reference architecture for AO middleware

3
Applications Lab

• general aim
• applying AO to real application scenarios in
  distributed and ambient systems
• from 4 viewpoints
• key concerns that need AOSD
• adaptable middleware
• industrial demonstrators
• incremental evaluation of research concepts
• partners
• University of Lancaster, UK
• INRIA (Institut National de Recherche en
  Informatique et en Automatique), France
• Trinity College Dublin, Ireland
• University of Malaga, Spain
• Katholic University of Leuven, Belgium
• Technion Israel Institute of Technology, Israel
• Siemens AG, Germany
• IBM United Kingdom Limited, UK

4
Long-term objectives (1)

• to invest in a product-line approach that
  supports building multi-concern applications in
  the broad area of distributed and ambient
  computing.
• study key concerns that really need AOSD
  (distribution, security, persistence, mobility,
  context-awareness, etc.)
• develop aspects for specific concerns
• develop an architecture for AO middleware that
  supports composing aspects in heterogeneous and
  dynamic environments
• to use, apply and refine results from all
  research labs and the Atelier while developing
  the above product-line approach

5
Long-term objectives (2)

• to fully demonstrate the applicability of AOSD to
  industry
• develop specific demonstrators in the area of
  ambient computing
• continuously evaluate the adoptability of AO
  concepts and tools in industrial projects and
  processes
• to integrate the partners know how and research
• in terms of key concerns
• in terms of aspect-oriented middleware

6
Survey of AO Middleware
7
Goals of the survey

• overview of non-AO middleware platforms and chart
  their limitations with regard to building
  large-scale distributed systems
• overview of AO-supporting middleware platforms
• the application developers perspective
• overview of research projects that have applied
  AOSD to the construction of middleware itself
• the middleware developers perspective
• compare and position all the above platforms in a
  triangle formed by 3 requirements for middleware
• reliability
• flexibility
• performance

8
Included platforms/projects and evaluation
criteria

• non-AO middleware
• 14 non-AO middleware platforms
• evaluation criteria
• Flexibility, Reliability, Performance,
  Large-scale Customizability, Extensibility,
  Binding Adaptation, Resource Adaptation,
  Extension with Resource Management Policies, Ease
  of Customization, Ease of Use
• AO-supporting middleware
• 11 AO-supporting middleware platforms
• evaluation criteria
• Flexibility, Reliability, Performance,
  Programming Model, Primary Entities, Weaving
  Model, Joinpoint Model, Aspect Reusability,
  Application Adaptability
• applying AOSD to structure middleware
• 19 research projects
• four different layers of middleware
• contribution of these projects in terms of
  improved flexibility, reliability or performance

9
Conclusions of the survey

• traditional (non-AO) middleware platforms have
  reached a ceiling
• middleware has become overly complex and
  difficult to understand
• none of the middleware platforms satisfies our
  comparison criteria in a balanced way
• large-scale customizability remains completely
  unaddressed
• AOSD complements middleware by delivering
  flexibility, reliability and performance in a
  more balanced way
• there is a too diverse selection of AO middleware
  platforms
• Hence, the move towards a generic reference
  architecture for AO middleware

10
A reference architecture for AO middleware
11
Goals of the reference architecture (1)

• to provide a conceptual vocabulary for AO
  middleware systems
• compatible with the general vocabulary developed
  elsewhere in AOSD Europe, but specialised and
  extended for middleware
• e.g. distributed aspects?
• distinct from any particular instantiationi.e.
  independent of languages or platforms
• keep as general and non-prescriptive as possible
  to maximise applicability and future-proofness

12
Goals of the reference architecture (2)

• to facilitate the analysis, comparison and
  discussion of AO middleware platforms
• developing AO middleware
• understanding AO middleware systems
• achieved through a process of mapping between the
  architectures generic conceptual framework and
  features of specific platforms
• to embody and encourage best practice and
  patterns in the design of AO middleware systems
• to form the basis of middleware implementation
  toolkits
• in analogy with the language implementation
  toolkit being worked on in the AOSD Europe
  Atelier

13
Scope of the reference architecture

• distributed middleware
• heterogeneity, dynamicity, depth, distribution
• language independence
• can't afford to make the assumption that all code
  in a distributed system will be written in a
  single programming language
• domain independence
• should accommodate all middleware domains
  including business, grid, real-time, mobile,
  embedded,
• past-proofness
• should accommodate where possible existing
  standards and common terminology
• genericity
• should accommodate all kinds of concerns, from
  all viewpoints, and across all middleware layers

14
Structure of the reference architecture

• three levels
• general concepts, principles and patterns
• component model is crucial here
• instantiations of Level 1 for specific key
  concerns
• a set of distributed aspects built using level 1
• these aspects represent the key concerns that
  need AOSD
• 3. a configuration of level 2 distributed
  aspects in a specific system

15
The role of components

• fundamental units of computation and composition
• language independent
• non-distributed
• interfaces defined in an IDL
• first class connectors
• implication that 'application, and 'aspect' are
  both uniformly components
• simplicity - only one kind of executable and
  deployable entity
• generality role of a component is a matter of
  perspective
• advice an operation in an aspect component
• adopt a specific notion of components and define
  key operations
• loading/ unloading/ instantiation/ destruction/
  binding/ unbinding/ starting/ stopping
• based on Fractal, OpenCOM, OSGi, JMX,

16
Joinpoint and composition models

• joinpoint model
• necessarily coarse-grained and defined in terms
  of externally-visible join points such as
  operation invocations or attribute accessors
• also need systems oriented joinpoints
• resource control, plug-n-play events, packet
  arrival,
• (or are systems just more components?)
• liaise with language lab on canonical set of
  interception points
• but we must not, of course, rule out the use of
  aspect-oriented languages in the implementation
  of components!
• composition model
• FOPL based? (liaise with formal methods lab)
• key characteristic is extensibility
• extensible above for distribution etc.
• extensible below to accommodate grey box
  components