Middleware and Architectural Reflection

The overall goal of the MAIS framework is to support services that are capable of adapting their behavior to changing requirements, environments, user profiles and platforms, in order to provide the user with a suitable quality of service (QoS) [112, 181, 292]. To accomplish this goal, both the front-end and the back-end MAIS environment exploit knowledge about the architecture and configuration of the underlying platform. By platform we mean of all the hardware and software system objects that support the services, for example computing nodes, interaction devices, software components and communication networks. Applications usually rely on abstractions that expose the functional aspects of the system objects. For instance, an application can display something, or send a request through a communication service. System objects also exhibit non functional aspects: in particular, basic QoS features such as bandwidth, availability, screen size, memory size, and battery level [23, 246]. Such features are subject to changes, the rate of which can go from static (e.g., the screen size of a user device) to highly dynamic (e.g., the transfer rate of a network service). In any case, the QoS of the system objects are unknown when the software components that implement the services are being developed. Therefore, in order to provide an adaptive service, such components must be capable of observing and (if possible) of controlling the QoS of the system objects they rely on [24, 25, 26]. Unfortunately, QoS is usually hidden from high-level software components. Sometimes it can be managed via tricky low-level mechanisms. In any case, there are no high-level abstractions that allow an object's QoS to be observed and controlled by high-level, platform-independent software components. To fill this gap, the MAIS project exploits a reflective architecture. The architecture is "reflective" because it allows high-level software components to observe and control the features and the inner state of the system itself. System objects are modeled by meta objects (reflective objects, or R Objects, see [251]) which expose, at a suitable level of abstraction, their meaningful features in terms of QoS. System objects and R Objects are causally connected [241]. The existence of a causal connection means that a state change in the system object causes a state change in the corresponding R Object, and vice versa. Figure 4.1 shows the various layers of the reflective system, in accordance with the general scheme sketched in Fig. 2.6. Functional objects model the functional and non reflective aspects of system objects, as exposed by the technological layer; for instance, a screen is an object where applications can display images. Reflective objects, on the other hand, model the non functional and QoS-related aspects of the system objects; for instance, a screen is modeled by its size, resolution and so on. The figure shows how the reflective mechanisms can be exploited in various ways, which will be discussed in the rest of this chapter. (Figure presented) Reflective applications rely on both domain-specific and reflective knowledge in order to provide adaptive services. Such applications exploit both functional and reflective objects. For instance, a reflective application (Reflective Application B in Fig. 4.1) can exploit both domain knowledge (e.g., user profiles) and reflective knowledge (e.g., QoS features of the devices exposed by the base reflective layer via Base R Objects) in order to provide the end user with an "optimal" service. The base reflective layer is discussed in Sect. 4.2. This approach allows sophisticated solutions to be devised, although they imply that software developers must be aware of the low-level QoS features of the underlying platform. To reduce this drawback, the extended reflective layer provides mechanisms for defining suitable QoS strategies that provide the visibility of extended R Objects. Such objects expose to the applications (Reflective Application A in Fig. 4.1) the QoS of the system objects at a higher level of abstraction. The extended reflective layer is discussed in Sect. 4.3. Reflective middleware is an intermediate tier that exploits reflective knowledge to provide applications with enhanced functional objects (i.e., functional objects with a better QoS). Non stationary distributed systems, i.e. systems where different parts exhibit great diversity in terms of message transfer delays, provide a difficult background for traditional two-tier architectures. In order to provide QoS, such as reliability and availability, for such systems we envisage the use of a three-tier architecture for service replication, where reflective middleware (i.e., an extended reflective layer) is interposed between the client layer and the end tier. The goal of this middle tier is to limit the scope of agreement protocols to well behaved parts of the system (where the middle and end tiers are located), thus relieving non reflective applications from the burden of such protocols. The three-tier scheme is represented on the right side of Fig. 4.1, where the middle tier exploits reflective knowledge to provide applications with the visibility of enhanced functional objects with improved QoS. This approach relieves the applications from the management of non functional issues, although the middle tier is bound to implement best effort policies that do not exploit domain specific knowledge. The three tier scheme for replication is discussed in Sect. 4.4. A simple example may help us to understand the two approaches. Assume that a back-end application generates a streaming video towards a front-end device. If the application itself is reflective, it can observe the QoS in detail via the appropriate R Objects and, possibly, the topology of the underlying communication subsystem as well. Therefore the application may either adapt itself to the available bandwidth (for instance, by tuning the compression rate) or control, whenever possible, the QoS of the communication subsystem (for instance, by choosing an alternate communication path). This allows the application to exploit domain knowledge (for instance, by choosing the communication path according to the requirements exposed by the user profile), at the price of a higher complexity. On the other hand, a reflective middleware layer can be interposed between the base reflective layer and the application. It would be in charge of exploiting some best-effort strategy (for instance, by choosing a communication path) in order to provide the application with a suitable QoS. The application would be simpler, as it would not have to manage reflective issues. The drawback is that the strategies implemented by the reflective middleware cannot exploit specific domain knowledge (for instance, the user profile). The proposed mechanisms can be exploited by higher-level software components, which are denoted in Fig. 4.1 as applications. In this perspective, the higher level components that implement the MAIS framework can be viewed as applications, even if they should more properly be viewed as middleware components. Section 4.2 recalls the concepts related to the computational reflection, and presents the base reflective layer. Section 4.3 describes the extended reflective layer. Section 4.4 discusses the three-tier model for replication. Finally, Section 4.5 sketches two application examples