Components in an Adaptive and QoS QoS- -based Architecture based - - PowerPoint PPT Presentation

Components in an Adaptive and Components in an Adaptive and QoS QoS-

• based Architecture

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 SEAMS 2006 ICSE 2006 Workshop on Software Engineering for ICSE 2006 Workshop on Software Engineering for Adaptive and Self Adaptive and Self-

• Managing Systems

Managing Systems 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

• r

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

Base Reflective Layer Extended Reflective Layer

Representation of the Reflective Knowledge Representation of the Reflective Knowledge

Structural Property Reflective Object Topological Property Location Property Property ... Cost Property QoS

Reflective objects represent

non-functional aspects of the systems components

R_Objects are characterized

by their related:

QoS Properties

R _Property

(from r_property)

Q

• S

(from qualityOfService)

R _O bject nam e : String resource : FunctionalObject <<observ able>> 1..* 1..* 1..* 1..* 1..* 1..* 1..* 1..* FunctionalO bject

(from functionalClas s es )

1 1 C ausal C

• nnection

1 1

Management of the Reflective Knowledge Management of the Reflective Knowledge Views and Strategies Views and Strategies

R _Property

(from r_property)

R _StructuralProperty

(from r_property)

R _Structu reView * * * * R _TopologyPr

• perty

(from r_property)

R _T

• pologyView

* * * * R _LocationProperty

( from r_p roper ty )

R _Locatio nView * * * * H ighLev elQ

• S

(from qualityOfService)

BestEf fortStrategy

(fr

• m arc

hitec tu ra l_s tr ategies )

R _Vie w 1..n 1..n 1..n 1..n 1..n 1..n Low Lev elQ

• S

(from qualityOfService)

R _Serv iceView

A view = an organizational structure on the reflective

• bjects with its own semantics and computational

strategies to evaluate the objects under its control

The Service View The Service View

R_Object

(from r_Classes)

<<observable>> BestEffortStrategy

(from architectural_s trategies )

Serv iceStrategy

( from serviceStrategy)

LowLev elQoS

(from qualityOfService)

* * * * HighLev elQoS

(fr

• m

qualityOfService)

R_Serv iceView * 1 * 1 * 1 * 1 0..* 1..* 0..* 1..* * * * *

Catalogs the resources

based on the services they provide

Location, Topology, Structural, Location, Topology, Structural, … … Views Views

Peer 1 Peer 2 Peer 4 Peer 3 Peer 5 c f g e a Pc Structural View Modem Cpu Case Structural View

The Causal Connection Mechanism The Causal Connection Mechanism Observer Design Pattern Observer Design Pattern

FunctionalObject runService()

(from functionalClasses)

R_Object update() force()

(from r_Classes)

Subject Observer +observers +subject

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

The Chain of Services Views The Chain of Services Views Chain of Responsibility Design Pattern Chain of Responsibility Design Pattern

ServiceStrategy

Reflective View Manager R_Service_Scan R_Service_Call R_Service_Display

BestEffortStrategy

Strategies Strategies Strategy and Composite Design Patterns Strategy and Composite Design Patterns

Serv iceStrategy m apD

• w

n() m apU p() div ide()

(from s erviceStrategy)

BestEffortStrategy m apU p() m apD

• w

n()

(from architectural_s trategies )

ArchitecturalStrategy m apU p() m apD

• w

n()

( from archite ctura l_ stra teg ies )

R _View

(from r_View s )

R _ElementaryStrategy

(from s erviceStrategy)

R _C

• mpositeStrategy

(from s erviceStrategy)

Serv iceStrategy mapD

• w

n() mapU p() decompose()

(from s erviceStrategy)

0..* 1..* 0..* 1..*

Strategies implement

decisions

A best effort strategy

chooses the most appropriate resource for the current service request

Strategies may be

simple or compositions

• f other strategies

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:

display print …

InputD ata R equest

id state requester ty pe 1..* 0..* 1..* 0..*

R _O bject

(from r_Classes)

<<observ able>> Serv ice

sName : String[] sDev ice : String getServ ice()

(from Service)

1 1 1 1 0..* 0..* Q

• S

(from qualityOfService)

0..* 0..*

0..* 0..*

0..* 0..*

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

• verall 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