1. The Role of Reflection in Next Generation Middleware
Gordon S. Blair

2. Changing Marketplace New Demands on Middleware Platforms
Emerging technical challenges such as multimedia, mobility, real-time
Increasing need to tackle complexity by offering a greater separation of concerns (cf transparency)
Functional and non-functional requirements tend to change over time
Strong Requirement for New Approach
Build-time configurability
Run-time re-configurability
More general support for evolution

3. Problems with Existing Solutions
OMG Solutions
Both real-time CORBA and Minimal CORBA provide fixed solutions for given application domains
Interceptors provide a limited ad hoc approach to adaptation
Other Solutions
EJB offers only limited capabilities in terms of configurability
Open languages have severe restrictions (e.g. LAAS experience)
Open source solutions involve considerable development effort and result in proprietary solutions

4. Solution based on Marriage of Two Technologies
Reflection
Build on experiences of reflection community in areas such as programming language design, operating systems, distributed systems, windowing software, etc
Apply to middleware platforms (most appropriate place)
Components
Recognise important of emerging component technology
Apply component-oriented programming at base and meta levels

5. Open ORB: General Principles
Configurable component-based architecture
Support for multimedia (cf Sumo and RM-ODP)
Per component (interface) meta-space
Procedural approach
Orthogonal meta-space models

6. Open ORB: The Design of Meta-Space
Structural reflection
Encapsulation meta-model
What is behind the interface (cf introspection in Java)?
Composition meta-model
What other components are used in the construction?
Behavioural reflection
Environmental meta-model
What activity is there on an interface?

7. Example: An Open Binding

8. The Resources Meta-Model
Objectives
To provide a complete and consistent CCSR of resources and associated resource management at various levels of abstraction
To support introspection of resources, resource usage, etc
To support adaptation of resource allocations, management policies, etc

9. General Approach high level abstract resources low level
provided by
provides
resource manager
manages(high)
managed by
low level
abstract resources

10. Summary of Overall Architecture

11. Introducing QoS Management
Overall approach
Inject QoS management components into meta-space
Interaction via event notification service
Styles of management component
Monitors
Controllers
Strategy selectors
Strategy activators

12. Specifying Policies: The Use of Timed Automata
…. and then there are meta-policies!

13. Verification

14. Implementation Status
Initial prototype completed
Constructed using Python 1.5 (extended with a library of reflective features)
Incorporates FC2 interpreters (cf timed automata)
Simple QoS management scenario implemented
Audio buffer management

15. Ongoing Work Efficiency Integrity Generality
Re-implementation using lightweight reflective component model
Use of component frameworks
Integrity
Investigation of the role of software architecture in constraining change (with INRIA)
Generality
Extensions of architecture to include group services

16. Concluding Remarks
There is a strong need for more open and adaptable middleware platforms
Our approach provides a principled means of achieving such requirements
c.f. “black box” approach of CORBA
c.f. viewpoints of RM-ODP
Towards a CORBA MOP