OpenORB - A Marriage of three technologies
The OpenORB project proposed a philosophy for the development of reflective middleware platforms, which idenitifed that they should be built upon a combination of the following three technologies:
Components
A component is defined as:
"a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties" [C. Szyperski, "Component Software: Beyond Object-Oriented Programming", Addison-Wesley, 1998].
Component programming at the middleware level has the advantage of enhancing configuration, reconfiguration and re-use. Therefore, components become the middleware building blocks, acting as both units of composition and reconfiguration.
Our middleware technologies are devleoped upon a single component platform: OpenCOM. Hence, this acts as a point of integration for our research. OpenCOM is a lightweight, efficient and reflective component model that uses the core features of Microsoft COM to underpin its implementation; these include the binary level interoperability standard, Microsoft's IDL, COM's globally unique identifiers and the IUnknown interface. The higher-level features of COM, including distribution, persistence, transactions and security are not used.
Reflection
Access to the underlying middleware platform, and by implication the associated component structure, is provided by reflection. In particular, every application-level component offers a meta-interface providing access to an underlying meta-space which is in effect the support environment for this component (cf the middleware platform). Crucially, meta-space is itself composed of components. Such (meta-level) components also have a meta-interface, offering access to their support environment. This approach is therefore recursive, leading to an infinite tower of reflection. In order to overcome this, meta-components are instantiated on demand; unless accessed, they exist in theory but not in practice.
In our approach, meta-space is partitioned into a number of distinct meta-space models (see below).
Component Frameworks
Component frameworks are defined by Szyperski as:
"a collection of rules and contracts that govern the interaction of a set of components".
Or more generally, a component framework is the domain-specific "life-support environment" for plug-in components. Hence, a component framework enforces architectural principles on the components it supports; this is especially important in reflective architectures that dynamically change, and whose changes must be verified. The motivation behind component frameworks is to constrain the design space and the scope for evolution. Moreover, they simplify component assembly and increase the understanding and maintainability of the system.
The Multi-Model Approach
Overview
In our design, meta-space is partitioned into a number of distinct meta-space models. This approach was first advocated by the designers of AL-1/D. The benefit of this approach is to simplify the interface offered by meta-space by maintaining a separation of concerns between different system aspects. This is particularly important in distributed systems given the wide range of concerns that must be considered (in comparison to the design of a single programming language for example). The structure of meta-space is captured by the figure below.
There are four distinct meta-space models:
In reflective systems, structural reflection is concerned with the content and structure of a given component. In our architecture, this aspect of meta-space is represented by two distinct meta-models, namely the interface and architecture meta-models. The two meta-models represent a separation of concerns between the external view of a component (i.e. its set of interfaces), and the internal construction (i.e. its software architecture). We introduce each model in turn below.
Behavioural reflection is concerned with activity in the underlying system. More specifically, the design of Open ORB distinguishes between actions taking place in the system, and the resources required to support such activity. These two aspects are represented by the interception and resources meta-models respectively.
Interface Meta Model
The interface meta-model provides access to the external representation of a component in terms of the set of provided and required interfaces. In particular, it is possible to enumerate all provided (or required) interfaces offered by a given component, or to discover the type signature associated with a given interface. This meta-model therefore provides a capability similar to introspection facilities in the Java reflection API, allowing a programmer to interact with a component discovered dynamically in the environment. It is not possible to add methods to this implementation. Rather, we enforce the strict separation referred to above between interface and implementation, in keeping with this important principle of component-based programming.
Architecture Meta Model
The architecture meta-model then provides access to the implementation of the component as a software architecture, consisting of two key elements: a component graph and an associated set of architectural constraints. The concept of the component graph is central to this design, and is represented by a set of components (more specifically interfaces) connected together by local bindings, where a local binding represents a mapping between a required and provided interface in a single address space. Distribution can be added into the model by introducing (distributed) binding components into the graph (cf connectors in the software architecture literature). Normally this structure would be hidden from a user of a component. However, the architecture meta-model can be used to both discover and also make changes to this structure at run-time.
If unconstrained, this is a rather dangerous approach to advocate. Consequently, we extend the software architecture to include a set of architectural constraints. The type management system offers one level of constraints, i.e. a new component must be a valid substitution of the old component (cf subtyping of the respective interfaces). This is however not enough; it is also important to take a more global view of the architecture in determining validity of adaptations. For example, changing a compression component may require a similar change to the peer decompression component. Similarly, it may be necessary to preserve a given architectural style over time such as pipes-and-filters. Our approach is to record such constraints explicitly in the architecture and to ensure that adaptations preserve the architectural rules before committing the changes (cf atomic transactions). At design time, we adopt a combination of UML, OCL and natural language to capture such constraints.
Note that the approach described above is applied recursively in that components within a component graph may themselves have architecture, accessed via its architecture meta-model (i.e. at a meta-meta- level relative to the uppermost component. For example, a binding component within a graph may itself have a structure consisting of stubs and protocol components. This recursion terminates with primitive components, which have no visible underlying structure, and whose internal implementation details are inaccessible to the programmer.
Interception Meta Model
The interception meta-model is arguably the most straightforward in the Open ORB design, and is a simplified version of the environmental meta-model from the first version of the architecture. In keeping with a number of reflective middleware proposals, this meta-model enables the dynamic insertion of interceptors. Such interceptors are associated with interfaces (more specifically, local bindings) and enable the insertion of pre- and post- behaviour. This mechanism is useful, for example, to dynamically introduce monitoring or accounting into a running system. Similarly, interceptors can be used to introduce additional non-functional behaviour, such as security checks or concurrency control.
Resources Meta Model
The resources meta-model offers access to underlying resources and resource management. We believe that for many classes of application (including multimedia applications) it is just as important to be able to adapt resource usage and management policies as to evolve the basic structure of the system, e.g. when now operating in a mobile environment. The resources meta-model is based around the abstractions of resources and tasks. Resources can be either primitive (e.g. raw memory or OS threads) or complex (e.g. buffers or user-level threads multiplexed on to kernel-level threads). They are created by resource factories and managed by resource managers, the latter typically building complex resources by adding value to, or combining, primitive resource instances. For example, a user level scheduler is a resource manager that builds user level threads from OS threads. Tasks are then the logical unit of activity in the system with the precise granularity varying from configuration to configuration. For example, there could be a single task dealing with the arrival, filtering and presentation of an incoming video stream, or alternatively this could be divided into a number of smaller tasks. Importantly, tasks can span component boundaries and are thus orthogonal to the structure of the system. Tasks are essentially the unit of resource allocation, i.e. tasks have a pool of resources to support their execution.
There is a resources meta-model per address space, i.e. resources are associated with a particular address space and all components within that address space share the same meta-model. The meta-model provides access to a set of components representing resource management. As with other meta-models, it is then possible to either inspect or adapt activity associated with resources. For example, it is possible to insert monitors to capture statistics on the effectiveness of a thread scheduling policy and then possibly change this policy based on the information collected. In programming terms, the resources meta-model is accessed as a graph structure that organises resources, tasks and managers into hierarchical structures.