Components in an Adaptive and QoS QoS- -based Architecture based Architecture Components in an Adaptive and Claudia Raibulet, Francesca Arcelli, Mussino Stefano, Mario Riva, Francesco Tisato, Luigi Ubezio Università degli Studi di Milano-Bicocca DISCo – Dipartimento di Informatica Sistemistica e Comunicazione Milan, Italy SEAMS 2006 SEAMS 2006 ICSE 2006 Workshop on Software Engineering for ICSE 2006 Workshop on Software Engineering for Adaptive and Self- -Managing Systems Managing Systems Adaptive and Self Shanghai, China Shanghai, China
Issue Issue � Today information systems are composed of various entities, which can provide similar or identical services � How to: identify choose exploit at runtime the entity able to provide the desired service, the one that suits best for the current request? => Adaptive Resource Management (ARM)
Solution Solution � Explicitly represent and exploit additional information about the entities providing the services: � qualities , location , cost � structural , topological information � … to adapt dynamically to the users’ requests � Examples of common scenarios: � print on the nearest A3-format printer � display an image on a monitor supporting a specific resolution � send this message using the most appropriate device and network connectivity � …
Architectural Reflection Architectural Reflection � Reflection enables a system to observe and control itself through meta-representations � Architectural reflection introduces: � additional components within the logical layer or � additional layer(s) between the application and the logical layer � Reflective components/layers are causally connected to logical components/layers
ARM Architecture ARM Architecture Reflective Layers Reflective Layers Extended Reflective Layer Base Reflective Layer
Representation of the Reflective Knowledge Representation of the Reflective Knowledge � Reflective objects represent QoS non-functional aspects of the systems components Structural Property Property ... � R_Objects are characterized Reflective by their related: Object Topological Cost � QoS Property Property � Properties Location Property <<observ able>> 1..* 1..* 1..* 1..* 1..* 1..* 1..* 1..* R _O bject Q oS R _Property (from qualityOfService) nam e : String (from r_property) resource : FunctionalObject 1 1 C ausal C onnection 1 1 FunctionalO bject (from functionalClas s es )
Management of the Reflective Knowledge Management of the Reflective Knowledge Views and Strategies Views and Strategies H ighLev elQ oS BestEf fortStrategy Low Lev elQ oS R _Vie w R _Property (from qualityOfService) (fr om arc hitec tu ra l_s tr ategies ) 1..n 1..n 1..n 1..n (from qualityOfService) 1..n 1..n (from r_property) R _LocationProperty R _Locatio nView ( from r_p roper ty ) * * * * R _StructuralProperty R _Structu reView (from r_property) * * * * R _TopologyPr operty R _T opologyView (from r_property) * * * * R _Serv iceView � A view = an organizational structure on the reflective objects with its own semantics and computational strategies to evaluate the objects under its control
The Service View The Service View � Catalogs the resources based on the services they provide Serv iceStrategy ( from serviceStrategy) * * 1 1 HighLev elQoS R_Serv iceView (fr om qualityOfService) 1 1 * * * * 1..* 1..* * * BestEffortStrategy (from architectural_s trategies ) 0..* 0..* <<observable>> * * * * LowLev elQoS R_Object (from qualityOfService) (from r_Classes)
Location, Topology, Structural, … … Views Views Location, Topology, Structural, Peer 1 a Peer 4 Pc Structural g View e Peer 2 Peer 5 c f Peer 3 Case Structural View Modem Cpu
The Causal Connection Mechanism The Causal Connection Mechanism Observer Design Pattern Observer Design Pattern � The causal connection between functional and reflective objects is implemented by: � update() – adapts reflective objects to functional objects � force() – adapts functional objects to reflective objects +observers Subject Observer R_Object FunctionalObject (from r_Classes) +subject (from functionalClasses) update() runService() force()
The Chain of Services Views The Chain of Services Views Chain of Responsibility Design Pattern Chain of Responsibility Design Pattern Reflective View Manager ServiceStrategy R_Service_Display R_Service_Scan R_Service_Call BestEffortStrategy
Strategies Strategies Strategy and Composite Design Patterns Strategy and Composite Design Patterns � Strategies implement ArchitecturalStrategy R _View decisions ( from archite ctura l_ stra teg ies ) (from r_View s ) m apU p() m apD ow n() � A best effort strategy chooses the most appropriate resource for Serv iceStrategy BestEffortStrategy (from s erviceStrategy) (from architectural_s trategies ) the current service request m apD ow n() m apU p() m apU p() m apD ow n() div ide() Serv iceStrategy (from s erviceStrategy) mapD ow n() � Strategies may be 1..* 1..* mapU p() decompose() simple or compositions of other strategies R _ElementaryStrategy R _C ompositeStrategy (from s erviceStrategy) (from s erviceStrategy) 0..* 0..*
Validation of ARM Validation of ARM � A totally distributed solution exploiting the P2P paradigm (JXTA) � Three types of requests: � Non adaptive – specify the service and the input data � Low-adaptive – specify the service, the entity that should execute the service and the required QoS � High-adaptive – specify the service and the QoS � Currently, two services: Serv ice R equest (from Service) <<observ able>> id � display sName : String[] R _O bject state sDev ice : String 1 1 1 1 (from r_Classes) 0..* 0..* 0..* 0..* requester � print ty pe getServ ice() 1..* 1..* � … 0..* 0..* 0..* 0..* 0..* 0..* Q oS InputD ata (from qualityOfService)
Conclusions (I) Conclusions (I) � ARM proposes a solution to address dynamic adaptivity through architectural reflection � Representation of the reflective knowledge: � reflective objects and QoS � properties: � model important aspects of the system (structural, topological, location, etc.) for achieving adaptivity � allow an efficient organization and management of the reflective knowledge � Management of the reflective knowledge: � views � strategies: implement decision support � Validation of ARM concepts through a prototype
Conclusions (II) Conclusions (II) � Disadvantages of architectural reflection: � significant increase of the number of software components which may reduce overall efficiency � modification of the reflective components may cause overall damages � Advantages of architectural reflection in ARM: � separation of concerns: functional vs. reflective objects � modularity: separation of the reflective entities from their management mechanisms � improving maintainability of the overall architecture � reusability and extensibility both of individual components and of the entire approach in various application domains
Further Work Further Work � Allocation and negotiation of resources � Extension of our approach to mobile devices which are not characterized by high computational capacities (e.g., mobile phones) � Extension of our current approach with other services � Using ARM in various application domains
Recommend
More recommend
