RECOM: A Reflective Architecture of Middleware

ly, reflection refers to the capability of a system to reason about and act upon itself. More specifically, a reflective system is one that provides a representation of its own behavior, which is amenable to inspection and adaptation, and is causally connected to the underlying behavior it describes. "Causally-connected" means that changes made to the self-representation are immediately mirrored in the underlying system’s actual state and behavior, and vice-versa. It can therefore be said that a reflective system is one that supports an associated causally connected self-representation (CCSR)[6]. Just as objects in conventional OOP are representations of real world entities, they can themselves be represented by other objects, usually referred to as meta-objects, whose computation is intended to observe and modify their referents (the objects they represent)[4]. Metacomputation is often performed by meta-objects by trapping the normal computation of their referents; in other words, an action of the referent is trapped by the meta-object, which performs a meta-computation either substituting or encapsulating the referent’s actions. Of course, metaobjects themselves can be represented, i.e., they may be the referents of meta-meta-objects, and so on. A reflective system is thus structured in multiple levels, constituting a reflective tower. The objects in the base level are termed base-objects and perform computation on the entities of the application domain. The objects in the other levels (termed meta-levels) perform computation on the objects residing in the lower levels. Each reflective computation can be separated into two logical aspects: computational flow context switching and meta-behavior. A computation starts with the computational flow in the base level; when the base entity begins an action, such action is trapped by the meta-entity and the computational flow raises at meta-level (shift-up action). Then the meta-entity completes its metacomputation, and when it allows the base-entity to perform the action, the computational flow goes back to the base level (shift-down action). In all reflective models, an essential concept is that of reification. In order to compute on the lower levels’ computation, each level maintains a set of data structures representing (or, in reflection parlance, a reification of) such computation. In other words, reification means making the hidden aspects explicit, so these aspects can be inspected and adapted by applications. Of course, the aspects of the lower levels’ system that are reified depend on the reflective model (e.g., structure, state and behavior, communication). In [7], according to the relationship between metaentities and base-entities, a first reflective model classification has been pointed out. Ferber remarks the existence of three major reflective approaches: meta-object model, meta-class model, and meta-communication model. In any case, the data structures comprising a reification are causally connected to the aspect(s) of the system being reified; that is, any change to those aspects reflects in the reification, and vice versa. It is a duty of the reflective framework to preserve the causal connection link between the levels: the designers and programmers of meta-objects are insulated from the details of how causal connection is achieved. 2 Reflective View of Middleware Reflective Middleware is concerned with applying techniques from the field of reflection in order to achieve flexibility and adaptability in middleware platforms. Geoff Coulson offers a concise definition of reflective middleware: reflective middleware is simply a middleware system that provides inspection and adaptation of its behavior through an appropriate CCSR[13]. The reflection does for middleware what it does for any system: it makes it more adaptable to its