Escolar Documentos
Profissional Documentos
Cultura Documentos
Phil]
Reflective Middleware 1. What does reflection means 2. What is Reflective Middleware 3. Importance of reflective middleware 4. An example of reflective middleware functioning 5. Reflective middleware model. 5.1 DynamicTAO 5 2 Open ORB
1. What does reflection means Abstractly, 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 that is amenable to inspection and adaptation, and is causally connected to the underlying behavior it describes. "Causally-connected" means that changes made to the selfrepresentation are immediately mirrored in the underlying systems actual state and behavior, and vice-versa. Therefore, a reflective system should support the causally connected self-representation (CCSR). adaptation, it refers to the possibility of changing the underlying structure or modifying the real state data. 2. What is Reflective Middleware Reflection enables both inspection and adaptation of systems at run time. Inspection allows the current state of the system to be observed Adaptation allows the systems behavior to be altered at run time to better match the systems current operating environment. An example of inspection is to determine the currently configured garbage collection policy. The current operating environments include the systems is being debugged, is operating in a real-time environment or in a secure environment etc. Page 1 of 11
Page 2 of 11
Page 4 of 11
Page 5 of 11
components (see Figure 1). Whenever a request for the replacement of a component C arrives, the middleware examines the dynamic dependencies between C and other middleware and application components using the ComponentConfigurator object associated with C. Programmers extend the ComponentConfigurator class through inheritance to provide customized implementations dealing with different kinds of components. Middleware developers use this feature to write code that takes the proper actions to guarantee the consistency of the ORB internal structure in the presence of dynamic reconfigurations. DynamicTAO supports safe dynamic reconfiguration of the middleware components controlling concurrency, security, and monitoring. DynamicTAO exports a meta-interface for loading and unloading modules into the system runtime, and for inspecting and changing the ORB configuration state. The meta-interface is available to developers for debugging and testing purposes, to system administrators for maintenance purposes, and to other software components that can inspect and reconfigure the internals of the ORB based on information collected from other sources, including resource utilization monitors. Page 6 of 11
he mechanisms for reification, inspection, and reconfiguration of the ORB internal engine added by DynamicTAO to the conventional TAO implementation make DynamicTAO a reflective ORB. 5.2 Open ORB The Open ORB project aims to design highly configurable and dynamically reconfigurable middleware platforms to support applications with dynamic requirements, including those involving distributed multimedia and mobility [3].
Page 7 of 11
Page 8 of 11
Figure 2. Structure of the meta-space in Open ORB i. The Interfaces meta-space The Interfaces meta-space models support structural reflection. This is concerned with the external representation of a component in terms of the set of provided and required interfaces. The associated meta-object protocol, or MOP, offers facilities to enumerate and search the elements of interface definitions, allowing, say, the dynamic discovery of the services provided by a particular component. ii. The architecture meta-space The architecture meta-space models support structural reflection This is concerned with the internal implementation of components in terms of their software architecture. The self-representation consists of two parts: o a component graph representing the interconnections between the components in a component assembly; and
o
a set of architectural constraints defining the rules needed to validate component assemblies.
Page 9 of 11
Page 11 of 11