Check out the new USENIX Web site. next up previous
Next: Related Work Up: The Design and Implementation Previous: The Design and Implementation

Introduction

Object-oriented design is based on abstraction and information hiding (encapsulation). These concepts have provided an effective framework for the management of complexity of applications. Within this framework, software developers strive to obtain applications that are highly coherent and loosely coupled. Unfortunately, object orientation alone does not address the development of software that can be easily adapted.

The concept of open architectures [6,7] has been proposed as a partial solution to the problem of creating software that is not only modular, well-structured, but also easier to adapt. Open architectures encourage a modular design where there is a clear separation of policy, that is, what a module has been designed for, from the mechanisms that implement a policy, that is, how a policy is materialized. The implementation of system-oriented mechanisms such as concurrency control, distribution, persistence and fault-tolerance can benefit from this approach to software construction.

Computational reflection [13,21] (henceforth just reflection) has been proposed as a solution to the problem of creating applications that are able to maintain, use and change representations of their own designs (structural or behavioral). Reflective systems are able to use self-representations to extend and adapt their computation. Due to this property, they are being used to implement open software architectures. In reflective architectures, components that deal with the processing of self-representation and management of an application reside in a software layer called meta-level. Components that deal with the functionality of the application are assigned to a software layer called base-level. In object-oriented reflective systems, meta-level objects that implement management policies are called meta-objects.

Due to their inherent structure, the existing reflective architectures and MOPs may induce developers to create complex meta-objects that, in an all-in-one approach, implement many management aspects of an application or, alternatively, to construct coherent but tightly coupled meta-objects. Both alternatives make reuse, maintenance and adaptation of an application harder, especially of its meta-level, the layer in which most of the adaptations tend to occur in an open architecture.

In contrast, Guaranį [20] allows meta-objects to be combined through the use of composers. Composers [17] are meta-objects that can be used to define arbitrary policies for delegating control to other meta-objects, including other composers. They provide the glue code to combine meta-objects, and to resolve conflicts between incompatible ones. The use of composers encourages the separation of the structure of the meta level from the implementation of individual management aspects.

Our implementation of Guaranį, based on a Java interpreter that supports just-in-time compilation, has shown that it is possible to introduce interception mechanisms, essential for the deployment of behavioral reflection, with a small overhead. We believe that this overhead is a minor drawback, when compared with the flexibility introduced by our MOP.


This paper is structured as follows. In the next section, we discuss some related works. In Section 3, we present the reflective architecture of Guaranį. Section 4 contains a short description of our implementation of this architecture, extending a freely-available Java Virtual Machine. In Section 5, we present some figures about the impact of Guaranį on the performance of applications. Section 6 lists some possible future optimizations for our implementation of Guaranį. Finally, in Section 7, we summarize the main points of the paper.


next up previous
Next: Related Work Up: The Design and Implementation Previous: The Design and Implementation
contact the authors