Adaptive & Reflective Middleware Andreas Rasche Roadmap • Quality of Service • Adaptive Middleware • Classification of Adaptive Middleware • Reflective Middleware & Reflection & Metaprogramming Overview • Adaptive Middleware Implementations • Patterns (Component Configurator, Virtual Component, Quality Connector) • BBN Quality Objects, TAO, DynamicTAO, OpenORB • Adaptation-enabling vs. adaptive middleware Adaptive & Reflective Middleware | Middleware and Distributed Systems 2 AR 2007 Quality of Service (QoS) • QoS in field of telephony defined in ITU X.902 as “A set of quality requirements on the collective behavior of one or more objects” • At the network level QoS refers to • control mechanisms that can provide different priority to different users • guarantee a certain level of performance to a data flow • QoS is used as a general quality measure in the sence of “user perceived performance”, or “degree of satisfaction to the user” • Application-level Quality of Service can be ensured by: • Ressource/QoS-reservations at all underlying levels • Adaptation of application to cope with changing resource availabilites Adaptive & Reflective Middleware | Middleware and Distributed Systems 3 AR 2007 Adaptive Middleware • Adapt: To alter or modify so as to fit for a new use • Adaptive middleware is software whose functional behavior can be modified dynamically to optimize for a change in environmental conditions or requirements • Adaptations can be triggered by: • changes to a configuration file by an administrator • instructions from another program • user requests • Requirements of runtime adaptive system: measurement, reporting, control, feedback and stability • Adaptive middleware concerned with adapting non-functional aspects of distributed appplications including QoS Adaptive & Reflective Middleware | Middleware and Distributed Systems 4 AR 2007 Classification of Adaptive Middleware by Domain[Sadjadi] Adaptive Middleware Dependable Middleware QoS-Oriented Middleware Embedded Middleware Real-time Middleware Aspect-Oriented Middleware Stream-Oriented Middleware Reflection-Oriented Middleware Adaptive & Reflective Middleware | Middleware and Distributed Systems 5 AR 2007 Reflective Middleware • Reflection on programming languages started by Brian Smith at MIT • “Reflection is the integral ability for a program to observe or change its own code as well as all aspects of its programming language - even at runtime” • Reflective middleware moves reflection to the middleware level • Often implemented as a number of components that can be configured • System and application code can use meta-interfaces to: • inspect internal configuration of the middleware • reconfigure it to adapt to changes in the environment • Reflection is a technique to enable adaptation Adaptive & Reflective Middleware | Middleware and Distributed Systems 6 AR 2007 Common Terms • Reification: Process of providing an external representation of the internals of a system. Representation allows for manipulation of system internals • Structural Reflection: Provides the ability to alter the statically fixed internal data/funtional structures. Structural Reflection changes the internal makeup of a program. • Behavioral Reflection: The ability to intercept an operation such as a method invokation and alter the behavior of that operation. Behavioral Reflection alters the actions of a program. • Introspection: Read access to meta data (type information, classes, methods, members, inheritance) • Intercession: Manipulation of meta data Adaptive & Reflective Middleware | Middleware and Distributed Systems AR 2007 7 Classification (II) of Adaptive Middleware Adaptive Middleware Static Middleware Dynamic Middleware Customizable Configurable Tunable Mutable • after startup • during runtime • compile / link time • startup time • before usage • evolution to unexpected • static aspect weaving • command line parameter • reflection • configuration files • AOP + reflection • compiler flags • late composition • Eternal, IRL, Rocks • DynamicTAO • pre-compiler directives • dynamic weaving • QuO, EmbeddedJava • TAO • OpenORB Adaptation Type Application Lifetime Compile Time | Startup Time | Run Time Adaptive & Reflective Middleware | Middleware and Distributed Systems 8 AR 2007 BBN Quality Objects (QuO) Application set client expectation • Contracts summarize possible states of QoS (C++ or Java) and behavior to trigger when QoS changes Functional QuO Runtime System (Java) • Defined as regions in form of predicates Delegate (C++ or Java) over system condition objects premethod System Contract postmethod Conditions • System Condition Objects are used to ORB set object expectation measure and control QoS system event • Delegates provide local state for remote objects • Upon method call/return, delegates can check current contract state and choose behavior based on the current state of QoS • Delegates can choose between alternate methods, alternate remote object bindings, perform local processing of data, or simply pass the method call or return through Adaptive & Reflective Middleware | Middleware and Distributed Systems 9 AR 2007 BBN Quality Objects (QuO) - Adaptive Behavior Client 1.Client calls delegate Client Code Reference Connect Callback 2.Delegate evaluates contract 6 1 11 QuO Kernel 3.Measurement system conditions are signaled 2 Contract Delegate Factory 4.Contract snapshots value of system conditions 7 5 10 5.Contract is re-evaluated 8 3 4 6.Region transitions trigger callbacks Proxy 9 Syscond Syscond ORB ORB 7.Current region is returned Network Control Manager 8.If QoS is acceptable, delegate passes the call to the remote object ORB Proxy Proxy SC SC 9.Remote object returns value Del. Contract 10.Contract is re-evaluated... Object 11.Return value given to client Adaptive & Reflective Middleware | Middleware and Distributed Systems 10 AR 2007 BBN - Quality Objects - QDL Example Adaptive & Reflective Middleware | Middleware and Distributed Systems 11 AR 2007 The ACE ORB (TAO) • Implemented at Washington University St. Louis (D. Schmidt) • ACE: Adaptive Communication Environment • Object-oriented framework that implements many core patterns for concurrent communication software • TAO - Real-Time CORBA ORB developed on top of the ACE framework • Uses the strategy design pattern for the encapsulation of ORB internals • IIOP pluggable protocols, concurrency, request demultiplexing, scheduling, connection management • Strategies defined in configuration files, which are evaluation at start-up (dynamic configuration possible in DynamicTAO and later versions of TAO) Adaptive & Reflective Middleware | Middleware and Distributed Systems 12 AR 2007 3: POPULATE OFF LINE struct RT_Info { - per-connection basis [29]. Likewise, research on real-time op- RT_INFO Time worstcase_exec_time_; SCHEDULER Period period_; REPOSITORY erating systems has focused largely on avoiding priority inver- Criticality criticality_; sion and non-determinism in synchronization and scheduling Importance importance_; TAO - QoS Specification RT_INFO }; REPOSITORY mechanisms for multi-threaded applications [13]. 1: CONSTRUCT CALL 4: ASSESS Determining how to map the insights and mechanisms pro- CHAINS OF RT_OPERATIONS SCHEDULABILITY DEPENDS UPON = duced by QoS work at the network and OS layers onto an OO EXECUTES AFTER 2: IDENTIFY THREADS 5: ASSIGN OS THREAD programming model is a key challenge when adding QoS sup- • Application specifies QoS using PRIORITIES AND DISPATCH QUEUE RT RT RT port to ORB middleware [15, 40]. This subsection describes 6: SUPPLY ORDERING an RT_Info interface Operation Operation Operation RUN-TIME PRIORITIES SUBPRIORITIES the real-time OO programming model used by TAO. TAO sup- SCHEDULER OBJECT ADAPTER TO ORB ports the specification of QoS requirements on a per-operation Priority/ MODE 0 ORB CORE Subpriority • For every RT_OPERATION the MODE 1 basis using TAO’s real-time IDL schemas. Table Per CURRENT MODE 2 Mode MODE application specifies MODE 3 SELECTOR I/O SUBSYSTEM 3.3.1 Overview of QoS Specification in TAO • WCET, period, importance Several ORB endsystem resources are involved in satisfying Figure 10: Steps Involved with Off-line and On-line Schedul- application QoS requirements, including CPU cycles, mem- • During a configuration run the off-linei nschedulerg extracts QoS specification ory, network connections, and storage devices. To support end-to-end scheduling and performance guarantees, real-time ORBs must allow applications to specify their QoS require- • During the configuration run a RT_OPERAconfigTIONuration pdependencyrocess. Finally, t hgraphe priorit yista bcrleeated,s generat ed in ments so that an ORB subsystem can guarantee resource avail- which can be used for configuration ofste thep 5 a rmiddleware used at run-tiem e in step 6 by TAO’s ORB endsystem. ability. In non-distributed, deterministic real-time systems, TAO’s real-time Scheduling Service guarantees that all CPU capacity is typically the scarcest resource. Therefore, RT Operations in the system are dispatched with suffi- • Scheduler calculates threads, priority dispatch tables, thread priorities for the the amount of computing time required to process client re- cient time to meet their deadlines. To accomplish this, the application including feasibility analysis quests must be determined a priori so that CPU capacity can Scheduling Service can be implemented to perform various be allocated accordingly. To accomplish this, applications real-time scheduling policies. [23] describes the rate mono- must specify their CPU capacity requirements to TAO’s off- • Approach also allows