The Reflective Architecture of Guaraná

  

Figure 3: Operations and Results.

This figure presents the basic MOP of Guaraná: although a meta-object is allowed return a result when requested to handle an operation (a), it may prefer to return an operation to be performed (b), with or without an indication that it is interested in its result (c). If it is, it will be presented the result after the execution of the operation (d). Meta-objects can use operation factories to create operations (e) that can replace other operations (b,c) or be performed as stand-alone ones (f).

The problems presented in the end of Section 2 are solved in the MOP of Guaraná by splitting the meta-level processing associated with a base-level operation in the following steps:

1.

If the target object of the operation is associated with a meta-object, the kernel of Guaraná--the entity that implements the MOP-- intercepts and reifies the operation and requests the meta-object to handle it; otherwise, no meta-level computation occurs, reducing the overhead for non-reflective objects.

2.

A meta-object may produce a result for an operation, as in Figure 3(a). In this case, the meta-level processing terminates by unreifying the result as if it had been produced by the execution of the intercepted operation.

3.

However, the meta-object is not required to reply with a result. This permission is essential because it cannot deliver the operation to the base-level object. Instead, it should reply with an operation to be delivered to the base level (Figure 3(b)) --usually the operation it was requested to handle-- and with an indication of whether it is interested in observing and/or modifying the result of the operation (Figure 3(c)).

4.

Finally, the operation is delivered to the base level, and its result may or may not be presented to the meta-object, depending on its previous reply (Figure 3(d)). If it had requested for permission to modify the result, it may now reply with a different result for the operation.

Replacement operations can be created in the meta-level using operation factories, as in Figure 3(e). Operation factories allow meta-objects to obtain privileged access to the base-level objects they manage. Stand-alone operations can also be created with operation factories, and then performed, i.e., submitted for interception, meta-level processing and potential delivery for base-level execution, as in Figure 3(f).

We have been able to define composers by separating operation handling from result handling, implemented in two distinct methods, namely, handle operation and handle result. A composer is a meta-object that delegates operations and results to multiple meta-objects, then composes their replies in its own replies. For example, a composer can implement the chain of meta-objects presented before, but in a way that one meta-object does not have to keep track of its successor. Another implementation of composer may delegate operations and/or results concurrently to multiple meta-objects, or refrain from delegating an operation to some meta-objects if it is aware they are not interested in that operation.

In Guaraná, at any given moment, each object can be directly associated with at most one meta-object, called its primary meta-object. If there is no such association, operations addressed to that object are not intercepted, and we say that the object is not reflective at that moment.

The fact that Guaraná associates a single (primary) meta-object with an object keeps the design of the interception mechanism simple. Since the primary meta-object can be a composer, as can any meta-object it delegates to, multiple meta-objects can reflect upon an object. These meta-objects form a Composite pattern [5, chapter 4] that we call the meta-configuration of that object (Figure 4), a potentially infinite hierarchy of composition that is orthogonal to the well-known infinite tower of meta-objects [13].

  

Figure 4: Meta-configurations.

The meta-configuration of O₁ is elaborate: a composer, called its primary meta-object, delegates to three other meta-objects, one of which is a composer itself, and delegates to two other meta-objects. O₂ is not associated with any meta-object, so its operations are not intercepted; it is not reflective. O₃ shares MO₄ with O₁. MO₁ is a reflective meta-object, since it has its own (meta-)meta-configuration.