Components in an Adaptive and QoS-based Architecture

Transcription

1 Components in an Adaptive and QoS-based Architecture 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 ICSE 2006 Workshop on Software Engineering for Adaptive and Self-Managing Systems Shanghai, China

2 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)

3 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

4 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

5 ARM Architecture Reflective Layers Extended Reflective Layer Base Reflective Layer

6 Representation of the Reflective Knowledge Structural Property Topological Property QoS Reflective Object Location Property Property... Cost Property Reflective objects represent non-functional aspects of the systems components R_Objects are characterized by their related: QoS Properties QoS (from qualityofservice) 1..* 1..* <<observable>> R_Object name : String resource : FunctionalObject 1..* 1..* R_Property (from r_property) 1 Causal Connection 1 FunctionalObject (from functionalclasses)

7 Management of the Reflective Knowledge Views and Strategies LowLevelQoS (fromqualityofservice) R_Property (from r_property) HighLevelQoS (fromqualityofservice) 1..n 1..n R_View 1..n 1..n BestEffortStrategy (from architectural _strategies) R_LocationProperty (from r_property) * * R_LocationView R_StructuralProperty (from r_property) * * R_StructureView R_TopologyProperty (from r_property) * * R_TopologyView R_ServiceView A view = an organizational structure on the reflective objects with its own semantics and computational strategies to evaluate the objects under its control

8 The Service View Catalogs the resources based on the services they provide HighLevelQoS (from qual ityofservi ce) <<observable>> R_Object (from r_cl asses) * * * * R_ServiceView 1..* 0..* LowLevelQoS (from qualityofservice) 1 1 * * ServiceStrategy (from servicestrategy) BestEffortStrategy (from architectural_strategies)

9 Location, Topology, Structural, Views Pc Structural View Peer 2 Peer 1 c a Peer 3 e Peer 4 f g Peer 5 Case Structural View Modem Cpu

10 The Causal Connection Mechanism 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 Subject +observers Observer FunctionalObject (from functionalclasses) runservice() +subject R_Object (from r_classes) update() force()

11 The Chain of Services Views Chain of Responsibility Design Pattern ServiceStrategy Reflective View Manager R_Service_Display R_Service_Scan R_Service_Call BestEffortStrategy

12 R_View (from r_views) Strategies Strategy and Composite Design Patterns ServiceStrategy (from servicestrategy) mapdown() mapup() divide() ArchitecturalStrategy (from architectural _strategi es) mapup() mapdown() BestEffortStrategy (from architectural_strategies) mapup() mapdown() Strategies implement decisions A best effort strategy chooses the most appropriate resource for the current service request ServiceStrategy (from servicestrategy) Strategies may be simple or compositions of other strategies 0..* 1..* R_CompositeStrategy (from servicestrategy) mapdown() mapup() decompose() R_ElementaryStrategy (from servicestrategy)

13 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: display print <<observable>> R_Object (from r_classes) 0..* 0..* Service (from Service) sname : String[] sdevice : String getservice() 0..* 0..* QoS (fromqualityofservice) 1 1 Request id state requester type 1..* 0..* InputData

14 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

15 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

16 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