next up previous
Next: Meta-configuration management Up: The Reflective Architecture of Previous: The Reflective Architecture of

The MOP of Guaranį

These problems 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į 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. 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, nor can it deliver the operation to the base-level object. Instead, it can reply with an operation to be delivered to the base level --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.
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. 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, that allow meta-objects to obtain privileged access to the base-level objects they manage. Using operation factories, stand-alone operations can also be created and performed, i.e., submitted for interception, meta-level processing and potential delivery for base-level execution.

We have been able to define composers by separating operation handling from result handling, implemented in two distict 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 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 what we call the meta-configuration of that object, a potentially infinite hierarchy of composition that is orthogonal to the well-known infinite tower of meta-objects [4].


next up previous
Next: Meta-configuration management Up: The Reflective Architecture of Previous: The Reflective Architecture of
contact the authors