Facoltà di Ingegneria

Transcript

U NIVERSITÀ
DEGLI
S TUDI
DI
N APOLI F EDERICO II
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Tesi di Laurea
La qualità del servizio nei sistemi
middleware per nomadic computing
RELATORE
Chiar.mo Prof. Ing. Stefano Russo
CORRELATORI
Ing. Domenico Cotroneo
Ing. Armando Migliaccio
ANNO ACCADEMICO 2003-2004
CANDIDATO
Salvatore Orlando
Matricola 41/2433
Ringraziamenti
Solo al termine di un duro ma affascinante percorso di studi com’è quello di
ingegneria informatica ci si rende conto di quanto sia importante il contributo
delle persone che ti sono vicine.
A volte poche parole contano più di migliaia di pagine, e in queste poche parole
spero di poter far capire alla mia famiglia, e specialmente ai miei genitori,
Emanuele e Tina, quanto gli sia grato per avermi dato la possibilità di conseguire
questa laurea, sostenendomi sempre nelle mie scelte, anche quelle apparentemente
più incomprensibili, e riponendo la massima fiducia nelle mie capacità.
Un sentito ringraziamento va al prof. Stefano Russo, che mi ha concesso di
partecipare ad un innovativo progetto di ricerca nell’ambito del gruppo
MobiLAB, ed ai miei correlatori, gli ingegneri Domenico Cotroneo ed Armando
Migliaccio, la cui pazienza nel sopportare il mio modo non proprio canonico di
lavorare si è dimostrata esemplare.
Non posso certo dimenticare i tanti amici con i quali ho condiviso gioie e dolori
questi anni: Peppe, Marco, Federico, Antonio, Cristiano e tutti gli altri, che spero
di avere tutti vicini in questo giorno, che, almeno fino ad oggi, è il più importante
della mia vita. Un particolare ringraziamento va anche ad Eugenio e Carmela, i
genitori di Peppe, per la fiducia che hanno sempre mostrato nelle mie doti di
studente.
Infine, ultima ma non per questo meno importante, desidero ringraziare Titti, la
mia ragazza, con la quale da quasi un anno ormai condivido praticamente tutta la
mia vita.
Finalmente, dopo 7 anni, 1 mese e 8 giorni, è giunto il tanto atteso
giorno in cui mi sentirò proclamare dottore in ingegneria informatica!
Salvatore
Indice
Introduzione..........................................................................................i
Capitolo 1 - Qualità del servizio in ambienti di Nomadic
Computing ............................................................................................ 1
1.1 Introduzione .................................................................................................. 1
1.2 Distributed e Nomadic computing ................................................................ 4
1.2.2 Perché spingere sul Nomadic computing............................................... 7
1.2.3 Middleware per Nomadic computing..................................................... 8
1.3 Introduzione alla qualità del servizio ............................................................ 9
1.3.1 Parametri tecnologici ed user-perceived di QoS.................................... 9
1.3.2 Classi di servizio .................................................................................. 12
1.3.3 QoS end-to-end in un’applicazione distribuita .................................... 13
1.3.4 Aspetti di gestione “statica” della QoS ................................................ 15
1.3.5 Aspetti di gestione “dinamica” della QoS............................................ 16
1.4 QoS in ambienti di Nomadic Computing .................................................... 19
1.4.1 Problematiche tipiche........................................................................... 19
1.4.2 Requisiti di QoS per ambienti nomadici .............................................. 21
1.5 Supporto software per il management della QoS........................................ 22
1.5.1 Sistemi operativi real-time ................................................................... 23
1.5.2 Protocolli di rete con caratteristiche di qualità del servizio ................. 24
1.5.3 Middleware Object-Oriented con supporto per la qualità del servizio 25
1.5.4 Esperanto – un middleware per infrastrutture di nomadic computing . 26
Capitolo 2 - Middleware con supporto per la qualità del servizio 30
2.1 Premessa...................................................................................................... 30
2.2 Real-Time CORBA ..................................................................................... 32
2.2.1 Scopi della specifica dell’OMG ........................................................... 32
2.2.2 Architettura di RT-CORBA .................................................................. 32
2.2.3 Funzionalità.......................................................................................... 34
2.2.4 Meccanismi per la gestione della QoS ................................................. 34
2.2.4.2 Gestione delle risorse di comunicazione....................................... 36
2.3 TAO (The ACE ORB) ................................................................................ 38
2.3.1 Architettura ed ottimizzazioni di TAO ................................................ 38
2.3.2 Il Real-time Scheduling Service (RTSS) ............................................. 40
2.4 CIAO (Component Integrated ACE ORB) ................................................. 44
2.4.1 Architettura di CIAO ........................................................................... 45
2.4.2 Supporto per la QoS in CIAO .............................................................. 46
2.5 QuO (Quality Objects) ................................................................................ 48
2.5.1 Middleware e qualità del servizio dinamica......................................... 48
2.5.2 Sviluppo di applicazioni adattative con QuO....................................... 49
2.5.3 Come QuO introduce QoS dinamica in un’applicazione..................... 50
2.5.4 I Qoskets: supporto per il riutilizzo di comportamenti sistemici ......... 52
2.6 Analisi dei middleware QoS-Enabled......................................................... 53
Capitolo 3 - Introduzione alla qualità del servizio in Esperanto.. 56
3.1 Esperanto, middleware per nomadic computing......................................... 56
3.1.1 Motivazioni e contesto ......................................................................... 56
3.1.2 Architettura di Esperanto ..................................................................... 56
3.1.3 Esperanto Broker.................................................................................. 58
3.1.3.1 Device side .................................................................................... 59
3.1.3.2 Core Network side ........................................................................ 60
3.1.3.3 I protocolli per il supporto alla mobilità: TDPAM e HOPAM ..... 60
3.2 Il Problema della qualità del servizio in Esperanto Broker ........................ 63
3.2.1 Mobilità dei devices ............................................................................. 63
3.2.2 Qualità dei link wireless e carico computazionale dei mediators ........ 64
3.2.3 Comunicazioni inter-dominio .............................................................. 64
3.2.4 Cambi di contesto................................................................................ 65
3.2.5 Limitata potenza dei devices................................................................ 65
3.2.6 Requisiti e vincoli di un sistema di gestione della QoS per Esperanto
Broker............................................................................................................ 65
3.3 Soluzione proposta per la core network ...................................................... 68
3.3.1 Modello di QoS per il mediator di Esperanto ...................................... 72
3.3.2 Metodi per la specifica dei requisiti di QoS......................................... 84
3.3.3 Meccanismi per la negoziazione della QoS (raggiungimento di un
service level agreement)................................................................................ 86
3.3.4 Meccanismi per garantire la QoS richiesta .......................................... 97
3.3.5 Sistema di monitoraggio delle risorse del mediator........................... 100
3.3.6 Mobilità dei dispositivi e Supporto per l’adattatività al contesto delle
applicazioni ................................................................................................. 107
3.4 Struttura QoS-enabled del mediator ......................................................... 116
3.4.1 System Monitoring Service................................................................. 117
3.4.2 SLA Manager ..................................................................................... 118
3.4.3 Quality Manager ................................................................................ 119
3.4.4 Internal ed External Contract ............................................................ 119
3.4.5 Interceptors ........................................................................................ 120
3.5 Scenari dinamici........................................................................................ 120
3.5.1 Negoziazione della QoS tra due peers ............................................... 120
3.5.2 delivery QoS-enabled delle tuple ....................................................... 124
3.5.3 Rinegoziazione asincrona dei SLA .................................................... 125
3.6 Considerazioni sulla soluzione proposta................................................... 126
3.6.1 Il modello di QoS a classi di servizio................................................. 126
3.6.2 Mancanza di supporto per la QoS nel device ..................................... 127
3.6.3 L’utilizzo della distribuzione log-normale per le singole interazioni 127
3.6.4 Verifica delle specifiche..................................................................... 128
Capitolo 4 - Progettazione del sistema di gestione della QoS ..... 129
4.1 Introduzione .............................................................................................. 129
4.2 Meccanismi per la negoziazione della QoS .............................................. 130
4.2.1 Interfaccia verso i device.................................................................... 131
4.2.2 Interfaccia verso altri SLA Manager .................................................. 131
4.2.3 Interfaccia verso i contratti................................................................. 132
4.2.4 Interfaccia verso i componenti del mediator...................................... 132
4.2.5 Struttura interna dello SLA Manager ................................................. 133
4.2.5.1 Negotatior per il controllo d’ammissione ................................... 134
4.2.5.2 Repository per la gestione delle SLA.......................................... 135
4.2.5.3 Policy Manager ........................................................................... 137
4.2.6 La negoziazione di un SLA................................................................ 138
4.3 Sistema di monitoraggio delle risorse ....................................................... 141
4.3.1 Rilevazione dei tempi di delivery delle tuple..................................... 142
4.3.2 Le System Conditions ........................................................................ 146
4.3.2.1 Media e varianza della latenza per le classi di servizio .............. 149
4.3.2.2 Media della latenza per le singole interazioni............................. 151
4.3.2.3 Monitoraggio dello stato delle singole classi di servizio ............ 152
4.3.2.4 Rilevazione degli Handover........................................................ 154
4.3.3 Gli Aggregators.................................................................................. 155
4.3.4 Struttura del System Monitoring Service............................................ 158
4.3.5 Misurazione delle latenze................................................................... 158
4.4 Out-of-band ed in-band adaptation nel mediator ..................................... 160
4.4.1 Struttura di un contratto ..................................................................... 161
4.4.2 Definizione dell’Internal Contract .................................................... 164
4.4.3 Definizione dell’External Contract.................................................... 171
4.4.4 Il Quality Manager ............................................................................. 174
4.4.5 In-band adaptation............................................................................. 175
Capitolo 5 - Approcci realizzativi al sistema di gestione della QoS
nel mediator ..................................................................................... 180
5.1 Introduzione .............................................................................................. 180
5.2 Classi di servizio e signalling nel mediator con TAO .............................. 180
5.2.1 Configurazioni real-time dei componenti del mediator..................... 181
5.2.1.1 Definizione delle classi di servizio ............................................. 181
5.2.1.2 Instradamento delle tuple sulle diverse classi di servizio ........... 186
5.2.2 Configurazioni real-time dei componenti per la gestione della QoS. 187
5.3 Realizzazione del SM Service con QuO.................................................... 189
5.3.1 Implementazione di una System Condition ........................................ 189
5.3.2 Note per l’implementazione delle System Condition per SM Service 190
5.4 Out-of-band ed in-band adaptation con QuO........................................... 193
5.4.1 Contratti per il mediator..................................................................... 194
5.4.1.1 Descrizione in CDL dell’internal contract .................................. 195
5.4.1.2 Descrizione in CDL dell’external contract ................................. 199
5.4.2 Delegati per il mediator ..................................................................... 200
Capitolo 6 - Esperanto e gli altri middleware mobile-aware con
supporto per la QoS ........................................................................ 203
6.1 Introduzione .............................................................................................. 203
6.2 Mobiware .................................................................................................. 204
6.2.1 Obiettivi e contesto applicativo.......................................................... 204
6.2.2 Architettura ........................................................................................ 205
6.2.3 Specifica e realizzazione della QoS ................................................... 207
6.2.4 Supporto per la mobilità..................................................................... 208
6.3 Monads...................................................................................................... 211
6.3.2 Architettura ........................................................................................ 211
6.3.4 Supporto per la mobilità..................................................................... 215
6.4 UBIQoS ..................................................................................................... 216
6.4.2 Architettura ........................................................................................ 216
6.5 Confronto con Esperanto........................................................................... 221
6.6 Conclusioni ............................................................................................... 225
APPENDICE - A Sintassi dei Quality Description Languages di
QuO .................................................................................................. 228
A.1 Contract definition language (CDL) ........................................................ 228
A.2 Adaptive specification language (ASL) ................................................... 231
Bibliografia ...................................................................................... 236
Introduzione
Tipicamente si associa l’idea di real-time e di qualità del servizio a sistemi
mission-critical (flight control, applicazioni militari per il controllo di missili
balistici,
controllo
di
processo
industriale,
telecontrollo
di
robot,
telemedicina,…)¸ per le quali il non soddisfacimento dei requisiti temporali
rappresenta un fallimento del sistema, a differenza delle applicazioni di tipo
enterprise, per le quali la ricerca è stata storicamente incentrata sullo sviluppo di
soluzioni per rendere più efficiente il processo di sviluppo del software
semplificando l’integrazione di diverse parti dello stesso e sollevando gli
sviluppatori dall’onere di affrontare complessità «accidentali» come l’eterogenità
delle piattaforme e dei linguaggi, la gestione delle risorse e la fault tolerance.
La larga domanda di quest ultimo tipo di applicazioni ha portato ad una
considerevole maturazione le tecnologie middleware COTS (common off-theshelf).
Grande successo in particolare è stato riscosso dai middleware per
programmazione distribuita orientata agli oggetti, come CORBA, che si sono poi
evoluti nei component middleware, che permette il riuso di componenti
applicativi per mettere a punto rapidamente applicazioni robuste. I maggior
rappresentanti di questa categoria di middleware sono J2EE della Sun, .NET della
Microsoft lo standard di riferimento Corba Component Model (CCM), definito
dall’ Object Management Group (OMG).
Tali tecnologie hanno raggiunto un tal livello di maturazione che ormai vengono
utilizzate anche nello sviluppo di sistemi ad alta criticità, riutilizzare infatti un
componente affidabile e collaudato che sviluppi una particolare funzionalità è
preferibile rispetto a sviluppare interamente «from scratch» tale funzionalità. Tali
sistemi, cui si faceva riferimento sopra, spesso hanno stringenti requisiti di qualità
del servizio, come alto throughput, bassa latenza, jitter costante e così via.
i
Un middleware convenzionale non è
adatto ad applicazioni che devono
soddisfare determinati requisiti di qualità del servizio (QoS) come predicibilità,
latenza, larghezza di banda, jitter, efficienza o scalabilità.
La ricerca negli ultimi anni ha effettuato numerosi progressi nell’applicazione di
modelli di qualità del servizio alle tecnologie middleware, in particolar modo al
middleware per programmazione distribuita orientata agli oggetti.
Real-Time CORBA (Real-Time Corba), standard definito dall’OMG (Object
Management Group) è forse il più affermato esempio di QoS-enabled
middleware. Tale tipologia di middleware, pur preservando il supporto per
l’eterogeneità dei middleware tradizionali, fornisce strumenti per supportare la
QoS richiesta dalle applicazioni e riconfigurare dinamicamente il sistema
nonappena le condizioni operative variano al fine di garantire il mantenimento dei
requisiti di QoS richiesti.
D’altro canto, grazie al rapido sviluppo della tecnologia dell’hardware e delle
infrastrutture
telematiche
osservato
nell’ultimo
decennio,
sono
ormai
estremamente diffuse reti wireless su ampio e corto raggio (Wi-Fi, Bluetooth,
GSM ed UMTS ad esempio) e sul mercato sono disponibili, a prezzi sempre più
accessibili per buona parte della popolazione, dispositivi estremamente
miniaturizzati, con una discreta seppur limitata potenza di calcolo ed autonomia,
dotati di dispositivi di collegamento wireless.
Un notevole sforzo è stato fatto dalla ricerca, sia industriale che accademica, nel
campo delle tecnologie middleware specifiche per mobile computing, pensate per
venire incontro agli sviluppatori nell’affrontare le problematiche tipiche connesse
alla mobilità dei dispositivi ed ai collegamenti wireless.
Nel filone del mobile computing si inseriscono infrastrutture di rete dette di
nomadic computing, composte da un insieme di device mobili interconnessi
mediante collegamenti wireless ad un’infrastruttura core costituita da nodi fissi
interconnessi attraverso collegamenti di rete affidabili e caratterizzata da ampia
larghezza di banda.
ii
Le applicazioni sviluppate per tale categoria di infrastrutture devono fronteggiare
i problemi connessi alla natura inaffidabile, costosa e poco efficiente del link
wireless, alla limitatezza di risorse (CPU, memoria, batteria,…) dei dispositivi
mobili, nonché alle problematiche insite nella mobilità dei dispositivi come
disconnessioni e cambi di contesto.
La maggior parte delle applicazioni attualmente sviluppate per contesti di
nomadic computing non tengono conto della possibilità di fornire determinati
livelli di qualità del servizio, ma si «accontentano» di fornire un servizio di tipo
best-effort.
Lo scopo del presente lavoro è quello di arricchire un middleware sviluppato dal
gruppo di Architetture Distribuite del dipartimento di Informatica e sistemistica
della facoltà di Ingegneria presso l’università Federico II di Napoli, denominato
Esperanto,con strumenti di supporto per la qualità del servizio, rendendolo capace
di ottimizzare e schedulare l’utilizzo delle risorse affinché siano rispettati i
parametri di qualità del servizio richiesti dalle applicazioni. In particolare il lavoro
sarà orientato al provisioning di QoS Capabilities nella core infrastructure di
Esperanto, ovvero nella parte di rete fissa che gestisce l’interconnessione tra i
diversi dispositivi mobili.
E’ infatti opportuno, in uno scenario dove i contesti di nomadic computing vanno
diffondendosi rapidamente (basti pensare agli aeroporti, ai musei, agli stabilimenti
dove i dipendenti operano con dispositivi mobili…), provvedere un supporto agli
sviluppatori che li metta in grado di mettere a punto applicazioni a QoS garantita.
Chiaramente il senso della qualità del servizio per uno sviluppatore di
applicazioni mission-critical è diverso da quello che ha lo sviluppatore di
applicazioni per contesti mobile. Ad esempio, il primo è interessato al
determinismo nel rispetto dei tempi d’esecuzione delle proprie applicazioni,
ritenendo anche giusto sovradimensionare le risorse elaborative e di
comunicazione dedicate all’applicazione stessa, mentre il secondo è interessato
prevalentemente ad un funzionamento che entro una certa soglia di tolleranza
rispetti i requisiti di timeliness imposti, e spesso non è in grado di poter allocare
iii
staticamente risorse elaborative e di comunicazione a determinate applicazioni,
ma è vincolato a condividere le stesse risorse con altre applicazioni.
Dunque lo scopo ultimo è quello di mettere a punto un middleware che sia in
grado di ottimizzare l’utilizzo delle risorse dell’infrastruttura di rete fissa al fine di
rispettare in maniera statistica, ove possibile, i requisiti di QoS imposti dalle
applicazioni, e di riconfigurare dinamicamente l’infrastruttura stessa a seguito di
cambiamenti nelle condizioni del sistema osservato.
Nel primo Capitolo vengono introdotti i concetti di nomadic computing e di
qualità del servizio. In particolare verranno messe in evidenza le esigenze di
qualità del servizio richieste dalle peculiarità del nomadic computing. Verrà
inoltre presentata la piattaforma middleware Esperanto.
Nel secondo capitolo verrà effettuata una carrellata storica dei middleware
general purpose (ovvero non specifici per un particolare dominio applicativo) con
supporto per la qualità del servizio, partendo dallo standard OMG real-time
CORBA, per arrivare ad un framework per lo sviluppo di componenti per la
gestione dell’adattatività delle applicazioni ai requisiti di QoS, QuO (Quality
Objects)
Nel terzo capitolo viene proposto un modello di QoS a classi di servizio per il
broker di Esperanto, e viene studiata una soluzione per fronteggiare le
problematiche connesse alla gestione della qualità del servizio, come
negoziazione
dei
service
level
agreeements,
controllo
d’ammissione,
monitoraggio delle risorse disponibili, manutenzione del sistema ed adattatività
alla variazione dei livelli di QoS misurati.
Nel quarto capitolo sono affrontati con maggiore dettaglio, utilizzando gli
strumenti descritti nel secondo capitolo, gli aspetti progettuali della soluzione
proposta nel terzo capitolo, relativamente ai nuovi componenti introdotti nel
broker di Esperanto.
iv
Nel quinto ed ultimo capitolo sono forniti alcuni aspetti implementativi e i dettagli
del progetto di basso livello degli elementi dell’Esperanto Broker relativi alla
gestione della QoS.
Nel sesto capitolo verranno presentate altre soluzioni middleware per mobile
computing elaborate da gruppi di ricerca accademici europei e statunitensi.
Verranno evidenziate le differenze nel loro approccio rispetto all’approccio
adottato in Esperanto.
v
Qualità del servizio in ambienti di Nomadic Computing
Capitolo 1
Capitolo 1
1.1 Introduzione
La disponibilità di unità elaborative sempre più potenti e miniaturizzate a costi
sempre più contenuti, unitamente ai notevoli progressi fatti registrare dalla
tecnologia delle telecomunicazioni, hanno reso possibili scenari che fino a poco
più di dieci anni fa potevano sembrare fantascientifici. Non è raro trovare una
persona che utilizzi un personal computer in ufficio, un portatile o un palmare
quando si sposta, che mentre guida la propria autovettura usufruisce dei servizi di
un computer di bordo, e, una volta tornata a casa, comodamente steso sul divano,
direttamente dal suo palmare decide quali luci accendere, la temperatura
dell’impianto di condizionamento e persino cosa vedere in televisione.
E’ stata fatta molta strada dai tempi in cui per accedere ad un centro di calcolo ed
inserire la propria scheda perforata per ottenere una semplice elaborazione
bisognava effettuare una prenotazione ed attendere il proprio turno, sperando di
non aver commesso errori nel programma da eseguire.
Da uno scenario di personal computing, nel quale l’intera elaborazione viene
effettuata sulla macchina presso la quale si opera si è passati ad uno scenario nel
quale gli utenti hanno l’effettiva possibilità di accedere ad informazioni e servizi,
in qualsiasi momento,in qualsiasi luogo ed in qualunque situazione come
pronosticato da Weiser in [WEIS 96].
I trend di mercato emergenti degli ultimi anni dimostrano una sempre maggiore
attenzione verso sistemi di elaborazione nei quali l’interazione tra componenti
distinti,
che possono essere dislocati su un Web server, così come su una
Workstation,un portatile o un PDA, è di fondamentale importanza. Il distributed
1
Capitolo 1
computing ha quindi assunto un’importanza fondamentale nell’ambito della
tecnologia del software.
L’evoluzione della tecnologia delle telecomunicazione ha portato alla fusione di
collegamenti wired e wireless, di tecnologie analogiche e digitali, sicchè siamo
ormai in presenza di un infrastruttura di comunicazione che ricopre il pianeta
intero e serve miliardi di persone.
Di conseguenza si è evoluta anche la tecnologia del distributed computing. Si
parla oggi di mobile, ubiquitous, pervasive, ad hoc o nomadic computing. I
significati di questi termini saranno illustrati in seguito nel presente capitolo.
Figura 1-1 – Tipologie di connessione rispetto a throughput del canale e
libertà di movimento dell’utente
Del resto in uno scenario così variegato gli utenti ed i dispositivi si muovono da
ambienti ad alto throughput e bassa libertà di movimento come le LAN, verso
ambienti con più liberta di movimento, ma con minor throughput, come le reti
basate su segnali radio, fino ad arrivare in circostanze nelle quali questi sono
completamente disconnesse. Altri importanti problematiche da considerare sono
le restrizioni imposte dalle limitazione delle batterie dei dispositivi mobili e dalle
limitate capacità elaborative degli stessi, come descritto da Chalmers in [CHAL
99]. Per quanto infatti siano stati enormi gli sforzi della tecnologia dei processori,
non si è ancora riusciti a miniaturizzare fino alle dimensioni di un palmare un
sistema di elaborazione della potenza di una Workstation, almeno non a costi
ragionevoli.
2
Capitolo 1
E’ dunque indispensabile che le applicazioni progettate per tali ambienti distribuiti
siano capaci di adattarsi al contesto in cui operano. E’ infatti molto diverso
operare direttamente connessi ad una Gigabit LAN in ufficio o all’università,
piuttosto che lavorare su una rete Wi-Fi in Aeroporto od utilizzare la connessione
GPRS mentre si viaggia in automobile.
Per tale motivo molte delle architetture definite per supportare lo sviluppo di
sistemi distribuiti forniscono strumenti per imprimere alle applicazioni qualità del
servizio (QoS) e adattatività.
La qualità del servizio è sempre stato un’argomento molto sentito e delicato
nell’ambito dello sviluppo di sistemi di elaborazione e telecomunicazioni. La
qualità del servizio definisce le caratteristiche non funzionali di un sistema,
influenzando la qualità percepita dei risultati. Ad esempio nelle applicazioni
multimediali può includere la qualità delle immagini o la velocità di risposta nella
visualizzazione di un’immagine.
Nelle reti ATM la qualità del servizio è ben definita, attraverso classi di servizio
(Constant Bit Rate,Variable Bit Rate,Available Bit Rate,Unbounded Bit Rate) e
parametri negoziabili in base ad un contratto per ognuna di queste classi (Peak
Connection Rate, Committed Information Rate,…). I sistemi Real-time, nelle loro
realizzazioni hard e soft garantiscono l’esecuzione di determinati task entro
precise deadlines in maniera rispettivamente deterministica e stocastica.
Quando invece si intende introdurre qualità del servizio in un sistema distribuito
bisogna fare necessariamente i conti con l’eterogeneità dei devices, dei sistemi
operativi dei link di rete che interconnettono le varie unità di elaborazione del
sistema.
I tempi nei quali il software veniva sviluppato «from scratch» per raggiungere un
particolare risultato su una specifica piattaforma sono passati. Infatti, come
evidenziato da Wang in [WANG 01] fattori economici e tecnologici hanno reso
possibile la transizione da una visione hardware-centric ad una visione softwarecentric. Un tema comune che sottolinea i moderni paradigmi di sviluppo del
software è il riuso del codice e l’indipendenza dalla piattaforma. E’ per tale
3
Capitolo 1
motivo che i middleware, entità frapposte tra il livello applicativo ed i livelli
sottostanti della rete e del sistema operativo hanno ottenuto a partire dagli anni
’90 uno straordinario successo. Inoltre l’utilizzo di tecniche di programmazione
ad oggetti, che intrinsecamente, grazie a meccanismi come l’ereditarietà,
consentono il riuso del codice, hanno portato al successo middleware orientati agli
oggetti. Si parla in questi di casi di middleware per distributed object computing.
Al fine di poter fornire agli sviluppatori un supporto per la gestione della QoS
delle proprie applicazioni che li astragga dai particolari protocolli di rete, dalle
politiche di scheduling e dall’allocazione delle risorse sui singoli nodi
d’elaborazione, molti dei middleware per distributed object computing sono stati
equipaggiati con strumenti per il supporto della QoS.
Tali strumenti forniscono supporto per la specifica dei requisiti di QoS di
un’applicazione, negoziazione dei parametri di QoS, controllo d’ammissione,
prenotazione di risorse nonché monitoraggio della QoS attualmente fornita,
Policing per verificare che la QoS richiesta dalle applicazioni sia rispettata,
Manutenzione per modificare i parametri del sistema al fine di mantenere la QoS
richiesta e per finire Rinegoziazione per ridefinire le condizioni di QoS operative
delle applicazioni quando le condizioni del sistema cambiano radicalmente.
Nel seguito del capitolo verranno descritti gli elementi caratterizzanti del
distributed
computing,
con
particolar
enfasi
al
nomadic
computing;
successivamente verrà fornita un’introduzione di base alla qualità del servizio
nelle applicazioni distribuite; infine verrà posta particolare enfasi sulla qualità del
servizio applicata ad ambienti di mobile e nomadic computing.
1.2 Distributed e Nomadic computing
1.2.1 Definizioni e concetti
4
Capitolo 1
In generale un sistema distribuito è una collezione di componenti dislocata su
diversi nodi d’elaborazione connessi in qualche modo attraverso una rete
telematica. Negli anni tali sistemi si sono evoluti parallelamente all’evoluzione
dei sistemi di elaborazione e comunicazione: si parla oggi di mobile computing,
pervasive computing, ubiquitous computing, nomadic computing ed ad-hoc
computing.
In [MIGL 03] è riportata una tassonomia dei sistemi distribuiti, che di seguito
viene ripresa ed estesa tenendo conto degli aspetti di qualità del servizio di cui
bisogna tener conto in ogni classe:
•
Traditional distributed computing: i device sono fissi e general-purpose,
connessi attraverso una connessione permamente (Es.: LAN Ethernet) le
cui applicazioni vivono in un contesto di esecuzione statico. In questo
contesto il supporto per la QoS è pensato in termini di applicazioni
mission-critical, con stringenti requisiti real-time.
•
Ad-hoc mobile computing: tali sistemi sono costituiti da device mobili
tipicamente general purpose (Es.: PC Portatili), connessi tra di loro
attraverso un collegamento intermittente (Es.: UMTS) e senza alcuna
infrastruttura fissa, dove le applicazioni vivono in un contesto fortemente
dinamico. In questo tipo di sistemila QoS viene intesa soprattutto in
termini di dependability. Le problematiche connesse alla natura del link ed
alla ridotta potenza elaborativi dei devices rendono quasi inutile qualsiasi
sforzo per fornire predictability alle applicazioni.
•
Pervasive computing : il sistema è composto da dispositivi fissi specialpurpose connessi attraverso un collegamento tipicamente permanente le
cui applicazioni vivono in un contesto prevalentemente statico. La QoS
similmente alle traditional distributed computing viene intesa nel senso di
predictability end-to-end delle elaborazioni [SHIR 04]
•
Ubiquitous computing: i dispositivi sono mobili, generalmente di tipo
special-purpose connessi attraverso collegamenti intermittenti e le cui
5
Capitolo 1
applicazioni vivono in un contesto dinamico. La QoS in questi contesti
viene intesa come context awareness, le applicazioni sono consce delle
condizioni in cui operano e si adattano di conseguenza, oppure il
middleware si riconfigura per supportare l’esecuzione dell’applicazione
stessa.
•
Nomadic computing: tali sistemi rappresentano invece un compromesso tra
sistemi totalmente fissi e totalmente mobili; sono generalmente composti
da un insieme di device mobili general o special pur pose interconnessi ad
un’infrastruttura core con nodi fissi, collegati attraverso una connessione
permamente. Il collegamento al core avviene solitamente mediante
collegamenti intermittenti. In questi contesti la QoS viene intesa sia nel
senso di predictability delle invocazioni ossia di performance delle
applicazioni stesse, che in termini di dependability.
Figura 1-2 – Forme del distributed computing rispetto alla mobilità ed alla
specializzazione dei dispositivi
Nella figura 1-2 si riporta una rappresentazione di tale tassonomia, tratta da
[MIGL 03]. Si vede come il nomadic computing rappresenti un compromesso tra
6
Capitolo 1
mobilità e staticità, nonché tra apparecchiature general-purpose e specialpurpose. L’embeddness dei dispositivi implica solitamente la povertà di risorse,
non si può infatti pensare allo sviluppo di applicazioni che introducono un carico
computazionale “pesante”. L’elevata mobilità dei dispositivi implica che un
servizio possa essere non disponibile in un certo istante o in un certo intervallo di
tempo (perché la connessione non è stabile, o perché il dispositivo sta migrando
verso un altro ambiente, magari in stand-by). Queste situazioni non devono
comportare un malfunzionamento: bisogna pensare a soluzioni che tengano conto
di queste eventualità.
Nella figura 1-3 è riportata una tipica infrastruttura di nomadic computing, dove
accanto ad una core network costituita da dispositivi fissi e general-purpose dotati
di collegamenti wired si trova una vasta gamma di dispositivi mobile sia general
che special-purpose, interconnessi mediante collegamenti wireless di svariata
natura.
Figura 1-3 – Una tipica infrastruttura di Nomadic Computing
1.2.2 Perché spingere sul Nomadic computing
7
Capitolo 1
Il paradigma di comunicazione del nomadic computing si adatta bene alla nostra
realtà quotidiana: il più delle volte viaggiamo da una postazione fissa all’altra,
ufficio, casa, hotel ma anche aeroporto, stazioni ferroviare. Ovunque (o quasi),
portando con noi i nostri computer e i dispositivi di comunicazione. Si parla
infatti di Anytime, anywhere access [KLEI 95]: le persone possono svolgere delle
operazioni dove preferiscono ed in qualsiasi istante desiderano.
Gli scenari di nomadic computing, come riportato in [KLEI 95] sono d’interesse
perché la nomadicità è implicitamente presente nel nostro modo di operare.
Viviamo in un disconnected world, dove il più delle volte si viaggia da una
postazione all’altra e durante il viaggio il collegamento è interrotto (come accade
ad esempio quando ci si sposta in metropolitana dall’ufficio verso casa). Inoltre il
nomadic computing è un enorme potenziale per la convenienza che possono
ottenere gli utenti. Inoltre va osservato che il nomadic computing per la natura
intrinsecamente eterogenea dei dispositivi e dei collegamenti, obbliga
praticamente la ricerca a sviluppare soluzioni che siano a livello middleware,
venendo così anche incontro a quelli che sono i trend attuali dell’industria del
software.
1.2.3 Middleware per Nomadic computing
Come anticipato nel paragrafo precedente si è accennato alla necessità di trovare
soluzioni a livello middleware per sistemi di nomadic computing. Un middleware
per nomadic computing condivide tutti i requisiti non funzionali di un qualunque
middleware per sistemi distribuiti, tuttavia alcuni di essi vanno rivisti in relazione
alla variate circostanze in cui ci si trova ad operare.
I middleware per nomadic computing devono introdurre:
•
Un carico computazionale leggero, i devices infatti hanno spesso una
potenza di elaborazione molto limitata
•
Un paradigma di comunicazione asincrono, non è infatti detto che tutti i
devices siano contemporaneamente connessi.
8
•
Capitolo 1
Un supporto per la context-awareness, in quanto il contesto di esecuzione
delle applicazioni non è sempre statico
•
Un supporto per l’adattatività alle risorse d’elaborazione e comunicazione
disponibili che possono variare fortemente nello spazio e nel tempo
La nomadicità infatti aggrava notevolmente una serie di problemi che gli utenti
devono affrontare, tra cui:
•
Di sconnessioni
•
Connettività variabile a causa di cambi volontari (viaggi, per esempio) o
imprevisti (connessioni inaffidabili ed error-prone)
•
Requisiti variabili (in ambiente differenti, può cambiare il livello di
supporto di cui si ha bisogno)
•
La necessità di essere a conoscenza del cambio di contesto
•
La necessità per l’ambiente di essere a conoscenza della presenza e della
location dei nomads
•
La necessità di adattatività a differenti livelli (ad esempio requisiti di
compressione variabile secondo la larghezza di banda a disposizione)
1.3 Introduzione alla qualità del servizio
1.3.1 Parametri tecnologici ed user-perceived di QoS
Molte applicazioni multimediali e real-time hanno a che fare con la Qualità del
Servizio (QoS), dove ci può essere una scala di performance ritenuta accettabile
ed i confini tra il successo ed il fallimento del sistema sono confusi e/o variabili,
come del resto già evidenziato nel paragrafo 1.1.
Mentre i sistemi sono spesso definiti in termini dei loro requisiti funzionali, la
QoS definisce i requisiti non funzionali degli stessi.
Ad esempio un’applicazione per il telecontrollo di droni può avere come requisiti
funzionali la possibilità di manovrare il drone in ogni direzione, di regolarne la
velocità, nonché di poter attivare la pala meccanica presente in ognuno di questi
9
Capitolo 1
droni. I requisiti non funzionali di QoS invece possono specificare che il cambio
di direzione di un drone sia effettuato entro un certo tempo t, con possibilità di
rilassarsi fino ad un tempo t’>t solo nel caso in cui la rete sia notevolmente
congestionata, oppure ancora che le immagini trasmesse dalla telecamera del
drone, arrivino, in condizioni di rete «scarica» entro una certo tempo T con una
qualità scarsa, oppure entro un tempo T’>T con un qualità elevata.
Category
Parameter
Description / Example
Timeliness
Delay
Time taken for a message to be transmitted
Response time
Round trip time from request transmission to reply
receipt
Jitter
Variation in delay or response time
System level data rate
Bandwidth required or available, in bits or bytes per
second.
Application level data
rate
Bandwidth required or available, in application specific
units per second, e.g. video frame rate
Transaction rate
Operations requested or capable of being processed per
second
Bandwidth
Reliability
Mean Time To
Failure (MTTF)
Normal operation time between failures.
Mean Time To Repair
(MTTR)
Down time from failure to restarting normal operation
Mean Time Between
Failures (MTBF)
MTBF = MTTF + MTTR
Percentage of time
available
Loss or corruption
rate
MTTF / MTTF + MTTR
Proportion of total data which does not arrive as sent,
e.g. network error rate
Tabella 1-1 – Caratteristiche di QoS Techonology-based
Questi requisiti possono essere specificati sia in termini di caratteristiche basate
sulla percezione che gli utenti hanno della qualità del servizio (come criticità del
task, dettaglio delle immagini, profondità dei colori, fluidità del flusso
audio/video) , sia in termini di caratteristiche tecnologiche (come delay, response
time, bitter, bandwith). Solitamente in primo luogo si usa la prima categoria di
parametri per specificare la QoS e quindi si traducono i parametri user-based nei
10
Capitolo 1
corrispondenti parametri technology-based. Ad esempio la qualità di riproduzione
di un filmato (Picture Detail, Picture Color Accuracy, Video rate…) possono
essere tradotti in termini di Delay e Jitter.
Questi parametri sono riportati nelle tabelle 1-1 e 1-2, tratte da [CHALM 99].
I parametri tecnologici appartengono a tre principali categorie: timeliness,
bandwith e Reliability che esprimono rispettivamente i requisiti sul tempo di
risposta e la sua varianza, sulla larghezza di banda, espressa sia in termini di unità
grezze (come i bytes) che di unità che hanno senso per una specifica applicazione
(come i frame di un video) e sull’affidabilità del servizio espresso in termini dei
sui tempi di fallimento e ripristino e della loss rate.
Category
Parameter
Description / Example
Criticality
Importance rating
Arbitrary scale of importance, may be applied to users,
different flows in a multimedia stream, etc.
Perceived QoS
Picture detail
Pixel resolution
Picture colour
accuracy
Maps to colour information per pixel
Video rate
Maps to frame rate
Video smoothness
Maps to frame rate jitter
Audio quality
Audio sampling rate and number of bits
Video / audio
synchronisation
Video and audio stream synchronisation, e.g. for lipsync.
Cost to establish a connection, or gain access to a
resource
Cost
Security
Per-use cost
Per-unit cost
Cost per unit time or per unit of data, e.g. connection
time charges and per query charges.
Confidentiality
Prevent access to information, usually by encryption
but also requires access control mechanisms
Integrity
Proof that data sent was not modified in transit, usually
by means of an encrypted digest.
Non-repudiation of
sending or delivery.
Signatures to prove who sent or received data and
when this occurred.
Authentication
Proof of identity of user or service provider to prevent
masquerading., using public or secret encryption keys.
Tabella 1-2 – Caratteristiche di QoS user-based
11
Capitolo 1
I parametri user-based invece sono strettamente correlati con la percezione che ha
l’utente della qualità del servizio che sta ricevendo. E’ per questa ragione che uno
di questi parametri è l’importanza che l’utente dà all’applicazione (per quanto
riguarda i droni prima citati il controllo dello stesso è sicuramente molto più
importante della trasmissione delle immagini, altrimenti si potrebbe vedere con
grande smoothness e detail il drone cadere in un burrone dopo aver sperato
vanamente che rispondesse in tempo al comando di cambio di direzione…)
Una categoria a parte è invece rappresentata dal costo. Tipicamente accade che il
costo è utilizzato per piazzare limiti superiori o inferiori ad altre caratteristiche.
Ad esempio, un utente è disposto a spendere 5 € per vedere un filmo la cui qualità
è meta di quella della TV via cavo, ma non vorrà spendere in ogni caso più di 7 €
a prescindere dalla qualità dell’immagine ed in ogni caso se la qualità scende al di
sotto del 50% della TV via cavo per lunghi intervalli di tempi (>10 min.), non
vorrà spendere neanche un Euro, perché non si sente soddisfatto del servizio
ricevuto.
Anche i requisiti di sicurezza costituiscono una categoria a parte. Gli utenti
percepiscono un sistema che garantisca confidenzialità e non ripudio come un
sistema di Qualità, ma questi parametri non sono mappabili sui parametri
tecnologici esposti in tabella 1-1 e comunque vanno al di là degli argomenti
esposti in questo lavoro.
1.3.2 Classi di servizio
Una ulteriore classificazione dei requisiti di QoS, o più particolarmente dei
sistemi che implementano tali requisiti è data dalle classi di servizio che questi
sistemi offrono. Una classe di servizio è determinata una volta assegnato un range
di valori ad ogni parametro di QoS che il sistema vuole regolare. Ad esempio la
rete ATM fornisce classi di servizio distinte in base al bit rate che vanno dal
servizio garantito deterministicamente (CBR) al servizio per niente garantito
(UBR) passando per il servizio garantito stocasticamente (VBR) ed il servizio
best-effort (ABR).
12
Capitolo 1
Una classificazione generica è fornita in [BOCHM 97], il quale individua cinque
livelli fondamentali di classi di servizio:
•
Deterministic guarantee – i requisiti verranno sempre soddisfatti, in ogni
circostanza.
•
Statistical guarantee – i requisiti vengono soddisfatti in una certa
percentuale del tempo in cui l’applicazione è operativa.
•
Target objectives – il sistema proverà a soddisfare i requisiti tenendo
presenti gli obiettivi principali dell’applicazione (non c’è alcuna garanzia
deterministica di soddisfacimento dei requisiti).
•
Best effort – in realtà in questa classe di servizio non c’è QoS, si prova a
fare quanto meglio possibile per soddisfare i requisiti con le risorse
lasciate disponibili dalle applicazioni appartenenti alle classi di servizio
superiori.
•
No guarantee – simile al Best Effort, ma ci si disinteressa anche di ottenere
informazioni sulla performance delle applicazioni.
1.3.3 QoS end-to-end in un’applicazione distribuita
E’ chiaro che in un sistema distribuito tutte le componenti del sistema devono
effettuare i propri task per raggiungere un dato livello di QoS totale. La specifica
di tipo end-to-end della QoS è sempre stata un problema cruciale. La gestione
della QoS è definita da Blair come “la supervisione ed il controllo necessari ad
assicurare che le proprietà di qualità del servizio desiderate siano ottenute e, dove
possibile, mantenute”.
In un’applicazione distribuita la gestione della QoS coinvolge tutti i componenti
interagenti e le risorse di elaborazione e comunicazione tra loro utilizzate. Trovare
l’agreement tra le diverse parti del sistema sulla QoS da applicare e gestire
l’adaption delle stesse parti per mantenere o eventualmente rinegoziare tale QoS è
un compito arduo, che non può prescindere dall’utilizzo di opportuni strumenti di
supporto.
13
Capitolo 1
L’end-to-end QoS provisioning in un’applicazione distribuita comporta infatti:
•
Una fase di specifica dei requisiti di QoS desiderati dalle applicazioni e
traduzione degli stessi in requisiti di basso livello
•
Una fase di configurazione e deploying dei diversi componenti
dell’applicazione. La configurazione scelta (tra le diverse specificate al
passo precedente) sarà quella la cui richiesta di risorse è soddisfatta dalle
correnti condizioni del sistemi, e la cui risultante QoS end-to-end sia
uguale o migliore a quella specificata nei requisiti, se disponibile.
•
Una fase di allocazione delle risorse, in base un piano di allocazione di
risorse end-to-end, che verrà frammentato sui diversi nodi di elaborazione
sui quali sono dislocati il componente, in modo che localmente ad ogni
nodo possano essere fatte tutte le reservations necessarie
•
Una fase di gestione a runtime della QoS. Durante tutto il lifecycle
dell’applicazione la condizione del sistema va monitorata e nel caso si
riveli che la QoS richiesta non possa essere soddisfatta bisogna procedere
a riallocare se possibile le risorse in modo tale da poter tornare nei
parametri richiesti dalle specifiche, oppure a rinegoziare la QoS con
l’applicazione magari scegliendo una diversa configurazione nella quale
viene fornito un servizio degradato ma comunque accettabile.
Si evince quindi che un sistema di QoS provisiong per applicazioni distribuite
deve essere supportato da:
•
Un sistema di monitoraggio delle risorse elaborative e di comunicazione
disponibili, che in maniera non invasiva, fornisca una visione consistente
dello stato del sistema ad un dato istante.
•
Un sistema per la specifica, la valutazione e la negoziazione dei requisiti
di QoS delle applicazioni. La soluzione più comunemente proposta in
letteratura è quella dei contratti, in base ai quali le applicazioni specificano
in maniera formale, mediante appositi linguaggi i propri requisiti di QoS
14
•
Capitolo 1
Un sistema per l’allocazione, distribuita e coordinata delle risorse da
assegnare ad un’applicazione distribuita
•
Un sistema per gestire l’adattatività delle applicazioni a seguito di cambi
di contesto o di stato del sistema. In letteratura sono state formulate ed
implementate numerose proposte, che saranno analizzate in dettaglio nel
capitolo successivo
1.3.4 Aspetti di gestione “statica” della QoS
Gli aspetti «statici» sono quelli applicati all’atto dell’avvio di un’applicazione e
riguardano le attività riportate nella tabella 1-3, tratta da [CHALM 99]
Function
Definition
Example Techniques
Specification
The definition of QoS requirements
or capabilities.
Negotiation
The process of reaching an agreed
specification between all parties.
Admission Control
The comparison of required QoS and
capability to meet requirements.
Requirements at various levels
of abstractions are described as
combined parameter, value,
allowed variation, and guarantee
level descriptions.
A comparison of specifications
in admission control with
modification of requirements on
failure, and resource reservation
when an agreement is reached.
The modification of
requirements should consider the
inter-relation of parameters and
preferences of the user.
The available resources may be
estimated with the aid of
resource reservation information,
and performance models.
Resource
Reservation
The allocation of resources to
connections, streams etc.
A time-sliced model of capacity
reserved is common.
Tabella 1-3 – Funzioni di gestione statica della QoS
•
La specifica della QoS riguarda la creazione di un contratto tra i produttori
ed i consumatori di data (i service providers ed i service requestors in una
SOA), basato sulla specifica di opportuni requisiti, che come
15
Capitolo 1
precedentemente visto possono essere formulati a diversi livelli
d’astrazione, e descrivono un insieme di caratteristiche spesso tra loro
correlate. Il contratto viene formulato utilizzando opportuni linguaggi di
specifica, può includere più range di valori per ogni parametri di QoS,
relativi a diverse regioni di funzionamento dell’applicazione, e rappresenta
il punto di partenza per la negoziazione della QoS.
•
La negoziazione è il processo in cui viene raggiunto un agreement tra le
parti coinvolte nell’interazione ed il suo risultato è un agreed contract al
quale tutte le parti coinvolte si adeguano. Vengono prese in considerazioni
le specifiche richieste da tutte le parti in causa. Nel caso in cui le richieste
non possano essere soddisfatto il contratto può essere rigettato o può
essere formulata una diversa proposta, basata sulle risorse effettivamente
disponibili nel sistema.
•
La resource reservation è la fase complementare al controllo
d’ammissione. Quest’ultima fase è superata se viene raggiundo un agreed
contract con una QoS accettabile. Dopodichè le richieste concesse sono
registrate e le risorse allocate.
Il successo della gestione statica della QoS dipende fortemente dal supporto dalla
capacità di specifica dei requisiti degli sviluppatori (ma anche dalla bontà dei
tools di traduzione delle specifiche di alto livello in specifiche di basso livello) e
dalla capacità degli strumenti di monitoraggio di fornire una visione consistente
dello stato del sistema.
1.3.5 Aspetti di gestione “dinamica” della QoS
Gli aspetti «dinamici» rispondono ai cambiamenti nell’ambiente di esecuzione
dell’applicazione, facendo in modo, ove possibile, che un contratto sia rispettato
nel tempo, a prescindere dalle variazione nella condizione del sistema. Le funzioni
di gestione dinamica sono riportate nella tabella 1-4, tratta da [CHALM 99]
16
•
Capitolo 1
Il monitoraggio è l’attività necessaria a fornire un’immagine consistente
dello stato del sistema ai componenti adattativi ed è già stata descritta al
paragrafo 1.3.3
•
Il policing viene effettuato per assicurarsi che tutte le parti coinvolte
nell’interazione
svolgano
il
proprio
ruolo
nel
soddisfacimento
dell’agreement raggiunto nella fase di negoziazione. Ad esempio si
assicura che un video provider che deve, da contratto, fornire 15
frames/sec (lo stesso contratto può definire tolleranze) non fornisca burst
di frames che possono saturare altre parti del sistema.
•
La manutenzione implica la modifica dei parametri del sistema per
mantenere la QoS richiesta dalle applicazioni. Può comportare una
ridistribuzione delle risorse, ad esempio allocare maggiori risorse di CPU
per una più efficiente codifica delle immagini risparmiando in questo
modo risorse di comunicazione.
•
La funzione rinegoziazione viene applicata quando i parametri di QoS non
possono essere soddisfatti, magari a seguito di qualche failure nel sistema.
Per evitare rinegoziazioni inutili causate da fluttuazioni transienti nei
livelli di QoS è consigliabile considerare la QoS media fornita in un
determinato intervallo di tempo, come suggerito in [BOCHM 97]. Tale
funzione effettua una graceful degradation della qualità offerta e può
essere invocata oltre che dal sistema (al sollevamento di opportuni triggers
sul suo stato) anche dagli utenti quando ritengono che la QoS da loro
percepita non è soddisfacente.
•
Infine l’Adaptation richiede che le applicazioni siano consce delle
condizioni in cui operano e quindi possano adattarsi dinamicamente al
contesto. Un modo per raggiungere tale obiettivo è fornire più
implementazioni del codice sorgente, e che un‘applicazione effettui lo
swapping tra una versione e l’altra quando necessario, come avviene nella
tecnica dei recovery blocks per lo sviluppo di applicazioni dependable.
17
Capitolo 1
Function
Definition
Example Techniques
Monitoring
Measuring QoS actually
provided.
Monitor actual parameters in relation to
specification, usually introspective.
Policing
Ensuring all parties adhere to
QoS contract.
Monitor actual parameters in relation to
contract, to ensure other parties are satisfying
their part.
Maintenance
Modification of parameters
by the system to maintain
QoS. Applications are not
required to modify
behaviour.
The use of filters to buffer or smooth streams,
in order to maintain stable delay, data rate and
jitter. QoS aware routing to maintain network
characteristics. Scaling media, e.g. by
modifying levels of detail provided within a
stream.
Renegotiation
The renegotiation of a
contract
Adaptation
The applications adapts to
changes in the QoS of the
system, possibly after
renegotiation.
Renegotiation of a contract is required when
the maintenance functions cannot achieve the
parameters specified in the contract, usually as
a result of major changes or failures in the
system. Usually invoked by exceptions raised
by the monitoring, policing and maintenance
functions.
Application dependent adaptation may be
needed after renegotiation or if the QoS
management functions fail to maintain the
specified QoS. Often achieved by media
scaling.
Tabella 1-4 – Funzioni di gestione dinamica della QoS
In letteratura c’è una fervente discussione sul mantenimento di un contratto di
QoS in condizione avverse. Nel seguente capitolo saranno mostrate alcune
soluzioni per la gestione dinamica della QoS. Va comunque notato che le funzioni
di QoS appena elencate possono essere utilizzate per aumentare la performance di
un applicazione nonappena il sistema aumenta la sua capacità di fornire un
servizio. Si consideri ancora che queste attività come già anticipato nel paragrafo
1.3.3 per quanto concerne il monitoraggio introducono un carico nel sistema.
Bisogna scegliere il miglior trade-off tra uno scarso monitoraggio, che porterebbe
ad avere snapshots dello stato del sistema «scadute» e quindi magari i contratti
non vengono onorati per un certo periodo di tempo, prima che il gestore della QoS
se ne accorga, ed un monitoraggio intensivo, che limiterebbe seriamente le risorse
18
Capitolo 1
a disposizione per le applicazioni, inficiando quindi negativamente la QoS
globale.
1.4 QoS in ambienti di Nomadic Computing
1.4.1 Problematiche tipiche
Nei sistemi nomadici la mobilità non è problema trasparentein quanto dopo ogni
rilocazione dell’host è necessario stabilire una nuova connessione. L’utente può
spostarsi di migliaia di chilometri tra una connessione e l’altra e spostarsi tra
ambiente con differenti capacità (Es: da una LAN Ethernet ad una rete GPRS).
L’utente
nomadico
durante
la
connessione
mostra
un
comportamento
relativamente statico, si sposta all’interno di un dominio relativamente poco
esteso, ma può comunque essere soggetto a consistenti variazioni nella qualità del
link . Nella seconda metà degli anni ’90 in letteratura si faceva riferimento agli
utenti nomadici supponendo che durante la connessione il loro comportamento
fosse quasi totalmente statico, differenziandoli dagli utenti mobili, che si
muovevano in spazi ampi e lavoravano pertanto in un contesto decisamente
dinamico. Tuttavia il repentino sviluppo tecnologico cui si è fatto cenno al par. 1.1
ha fatto sì che i concetti di nomadicità e mobilità si fondessero quasi. Ormai le
problematiche degli utenti nomadici e degli utenti mobili sono quasi le stesse.
Il maggior problema da affrontare è costituito dalla nomadicità stessa dell’utente.
Infatti in un sistema distribuito tradizionale l’utente ha sempre accesso diretto ai
server applicativi ed ai servizi offerti. Invece in un sistema nomadico non è detto
che questo accada, ed in ogni modo le risorse dell’utente non si troveranno sui
suoi server locali, ma sui suoi home server. L’idea di associare ad ogni utente un
home location server, analoga alla home location register in una rete cellulare è
stata proposta da Imelinski [CHALM 99]. L’utente poi si registra presso il server
19
Capitolo 1
del dominio cui accede e quindi, mediante comunicazione tra server locali e server
home reperisce le informazioni e le risorse di cui ha bisogno (Es.: agenda, contatti,
posta elettronica). Il costo della gestione della location degli utenti può diventare
significativo, al punto di superare persino i dati scambiati, quando crescono le
dimensioni del sistema e la frequenza dei cambi di contesto. In generale:
•
C’è un trade-off tra la facilità di localizzare dispositivi e servizi ed il costo
di mantenere le informazioni relative alle location quando queste variano.
•
Meno è informato il mittente circa la location del destinatario, maggiore è
il costo di risolvere il problema della sua localizzazione. Dunque c’è un
trade-off tra la realizzazione di protocolli di comunicazione semplici, nei
quali il mittente invia semplicemente dati al destinatario senza
preoccuparsi della sua realizzazione e il costo in termini computazionali e
di risorse impegnate, per localizzare e consegnare le informazioni al
destinatario (o ai destinatari).
Neanche il problema della qualità del collegamento è trascurabile nei sistemi
nomadic. Anche se la tecnologia dei collegamenti wireless compie notevoli
progressi, i problemi sono strettamente connessi con la natura delle comunicazioni
radio. E’ inoltre ragionevole ritenere che che il throughput della connettività
wireless resterà sempre inferiore di almeno un ordine di grandezza rispetto a
quella della connettività wired. Lo stesso throughput di un canale radio è inoltre
influenzato
dalla distanza tra il device e l’access point, dalle condizioni
atmosferiche, dal cammino seguito dagli utenti (Es.: passaggio in un corridoio
sotterraneo o sotto un ponte), nonché ad interferenze causate da altre sorgenti
radio ed ostacoli come palazzi, colline o montagne. Le fluttuazioni sul throughput
possono durare a lungo e quindi influenzare seriamente anche la qualità dei servizi
forniti.
20
Capitolo 1
Infine va considerato anche il problema delle restrizioni imposte dalle limitate
capacità dei devices, specialmente in termini di potenza delle CPU, qualità del
display, memoria disponibile, software, configurazioni hardware. I componenti a
basso consumo di energia sono decisamente meno potenti dei corrispettivi
progettati per i PC laptop. Inoltre spesso i devices vengono spenti o messi in
stand-by quando non attivi per risparmiare batteria. Attività intermittenti come
quelle esibite dai nomatic devices possono apparire come failures in applicazioni
distribuite.
Ricapitolando un sistema di nomadic computing QoS-enabled dovrebbe essere
caratterizzato da:
•
Efficienti meccanismi di location dei devices e delle risorse che
richiedono.
•
Possibilità di gestire ampie variazioni nella qualità del collegamento tra
diverse connessioni e durante le stesse connessioni
•
Basso carico computazionale sui devices, i quali sono caratterizzati da
scarsa potenza elaborativa e limitata autonomia.
1.4.2 Requisiti di QoS per ambienti nomadici
La mobilità ha un impatto fondamentale sulla qualità del servizio: il matching
delle risorse con i requisiti delle applicazioni è complicato dal movimento dei
devices. In un ambiente di nomadic computing è fondamentale che, in caso di
handover, le operazioni di rinegoziazione del contratto e riallocazione delle risorse
siano effettuate in maniera estremamente efficiente, consentendo alle applicazioni
di continuare a lavorare coerentemente con i requisiti di QoS specificati nel
contratto. Anche in questo caso appare chiaro come in contesti di nomadic
computing non è praticamente possibile assumere che siano soddisfatte garanzie
deterministiche di qualità del servizio. Un device può spostarsi tra contesti dove la
disponibilità di risorse è drasticamente diversa ed in nessun modo si può
21
Capitolo 1
continuare a garantire il funzionamento di un’applicazione a certi livelli laddove si
entri in un contesto caratterizzato da estrema poorness di risorse.
La qualità del collegamento è estremamente variabile, spesso in maniera casuale.
Parametri di QoS come bandwith, latency e jitter vengono influenzate dalla
mobilità dei dispositivi.
Va detto subito che data la natura della comunicazioni wireless non è il caso di
garantire deterministicamente specifici livelli di QoS. Invece, è opportuno un
approccio adattativo, nel quale venga specificato un intervallo di risultati
accettabili. Il supporto per la gestione della QoS dialogherà con application QoSaware, in grado di adattarsi a seguito di cambi nello stato del sistema.
Bisogna inoltre gestire in maniera efficiente, minimizzando l’overhead di
comunicazione e computazione, fenomeni come l’ingresso e l’uscita di nodi dalla
rete che avviene con una certa continuità (handover).
La ristretta potenza computazionale e la disponibilità intermittente caratterizzano
i dispositivi mobili. La gestione della QoS in un ambiente di nomadic computing
dovrebbe prevedere tecniche di scaling delle informazioni distribuite ed interfacce
utente semplificate (ad esempio nel caso di trasmissione di filmati, dovrebbe
prevedere la trasmissione di immagini di dimensioni diverse secondo la
risoluzione del display del device).
1.5 Supporto software per il management della QoS
Per imprimere qualità del servizio end-to-end in un’applicazione distribuita
bisogna agire sull’allocazione delle risorse nei nodi nei quali risiedono i
componenti dell’applicazione, sui canali attraverso i quali detti componenti
comunicano e sui componenti stessi, affinché questi si adattino dinamicamente
alle variazioni di stato del sistema.
22
Capitolo 1
1.5.1 Sistemi operativi real-time
L’allocazione delle risorse d’elaborazione, nella stragrande maggioranza dei casi è
gestita dal sistema operativo (questa considerazione non è vera solo nel caso di
applicazioni scritte in assembler e quindi compilate direttamente in linguaggio
macchina). E’ dunque importante che un sistema operativo fornisca caratteristiche
di qualità del servizio. Ad esempio per garantire che un’applicazione mantenga un
determinato livello di QoS end-to-end può essere necessario che un task in
esecuzione presso un determinato nodo abbia sempre a disposizione almeno il
50% del tempo macchina oppure che fornisca il risultato della propria
elaborazione entro 10 millisecondi.
I sistemi operativi dotati di queste caratteristiche sono detti sistemi operativi realtime. A loro volta questi sistemi operativi si dividono in hard real-time e soft realtime, dove la distinzione tra hard e soft sta nel fatto che i primi allocano le risorse
in modo tale da rispettare deterministicamente le deadlines dei task o non eseguirli
proprio, mentre i secondo ammettono un certo rilassamento rispetto alle deadlines
imposte.
I meccanismi utilizzati sono essenzialmente:
•
Scheduling dei processi di tipo Fixed priority - la priorità dei thread e dei
processi non viene sottoposta ad aging come avviene nei tradizionali
sistemi operativi. Esistono due principali famiglie di algoritmi di
scheduling per sistemi real time: rate monotonic, nel quale la priorità di
ogni task è fissata secondo il suo periodo T (i task sono periodici, ovvero
vengono invocati ogni T). In tal modo i task a periodo più basso hanno
maggior priorità, da ciò il termine rate monotonic; deadline monotonic, nel
quale la priorità di ogni task è fissata secondo la sua deadline. Minore è la
deadline, maggiore sarà la priorità del task.
•
Resource reservation – Le risorse del sistema (tempo di CPU,memoria,
utilizzo di processori periferici, utilizzo delle interfacce di I/O…) vengono
allocate staticamente ai task. Nel caso in cui un task abbia requisiti hard
23
Capitolo 1
real-time le risorse allocate vengono sovradimensionate. Ad esempio un
task può avere il 50% del tempo macchina a disposizione, anche se poi
effettivamente non usa neanche il 10% di questo tempo. La garanzia del
rispetto delle deadlines ha come contropartita il sottoutilizzo dei sistemi.
1.5.2 Protocolli di rete con caratteristiche di qualità del servizio
L’IETF (Internet Engineering Task Force) per immettere qualità del servizio nelle
comunicazioni su IP ha introdotto due approcci: integrated services (IntServ), a
grana fine, e differentiated services (DiffServ), a grana grossa.
L’approccio intServ aggiunge qualità del servizio alle comunicazioni su IP
secondo il processo descritto al paragrafo 1.3.4. In una prima fasi le applicazioni
specificano il proprio traffico (flowspec), mediante due strutture: TSpec, che
caratterizza il flusso dati ed RSpec, che specifica i requisiti di QoS desiderati.
Dopo che il controllo d’ammissione determina se il flusso può essere ammesso o
meno, avviene la riservazione delle risorse e quindi può iniziare la comunicazione.
Ciò viene fatto in pratica mediante il protocollo RSVP (Resource Reservation
Protocol): il sender spedisce un messaggio PATH contenente il TSpec, che tutti
gli hop intermedi memorizzano per poter costruire un reverse path; Il receiver una
volta ricevuto tale messaggio invia al sender un messaggio RESV contenente sia
il TSpec che l’RSpec. Tale pacchetto attraversa gli hop intermedi, che verificano
se possono allocare le risorse richieste. In caso affermativo avviene l’allocazione
ed il messaggio passa all’hop successivo. In caso contrario il messaggio viene
scartato e vengono liberate tutte le risorse precedentemente allocate. Se il
messaggio RESV arriva al sender allora il controllo d’ammissione è stato
superato, le risorse sono state allocate e la comunicazione può iniziare.
Invece nell’approccio Diffserv la classe di servizio è codificata nel pacchetto
mediante I 6 bit del campo DSCP dell’header IP, che rimpiazzano 6 degli 8 bit del
campo TOS. Secondo il valore contenuto in questo campo i router intraprendono
particolari comportamenti detti PHB (Per Hop Behaviour).
24
Capitolo 1
1.5.3 Middleware Object-Oriented con supporto per la qualità del servizio
Utilizzare direttamente le API messe a disposizione dai sistemi operativi RealTime o protocolli come RSVP costringe lo sviluppatore a gestire «from scratch»
l’intero sviluppo di un’applicazione con requisiti di qualità del servizio. Lo
sviluppo richiede un sforzo considerevole, data la mancanza di astrazioni di alto
livello per la gestione delle risorse del sistema. I problemi sono sostanzialmente
gli stessi che hanno portato all’affermazione dei middleware tradizionali come
CORBA.
Utilizzare invece un middleware tradizionale ed affidarsi alle API del sistema
operativo real-time per imprimere QoS alle applicazioni distribuite è comunque
un lavoro per niente semplice e fonte di numerosi errori,si pensi ad esempio alla
gestione dell’unbounded priority inversion. Infatti gli sviluppatori sebben
operando sopra un middleware layer per le operazioni concernenti la gestione
della qualità del servizio scendono direttamente a livello delle API offerte dal
sistema operativo, laddove uno dei principali motivi che hanno spinto
all’adozione del middleware è l’astrazione dalle peculiarità dei sistemi operativi (e
dei protocolli di rete e di trasporto).
Il miglior approccio per progettare e sviluppare applicazioni con qualità del
servizio è dunque quello dell’utilizzo di middleware QoS-enabled. Nell’ultimo
decennio la ricerca ha compiuto enormi passi in avanti in questo settore, tanto che
l’OMG ha da tempo standardizzato le estensioni real-time di CORBA, RTCORBA, che sono state incluse nella versione 3.0 dello standard. Detto ciò non
bisogna dimenticare l’importanza del sistema operativo sottostante l’ORB.
Infatti come dimostrato in [SCHMIDT 02] il sistema operativo real-time resta
comunque la piattaforma da scegliere per middleware ed applicazioni che
vogliano avere caratteristiche di qualità del servizio. I sistemi operativi generalpurpose, come Windows NT,2000,XP o Linux (kernel precedenti alla versione
2.6) non sono infatti in grado di supportare applicazioni con requisiti di QoS,
nonostante l’utilizzo di ORB Real-time.
25
Capitolo 1
1.5.4 Esperanto – un middleware per infrastrutture di nomadic computing
E’ chiaro che un’infrastruttura middleware per mobile computing deve offrire un
modello di comunicazione innovativo per rispettare requisiti e vincoli degli
ambienti mobili, come mobility support ed enhanced communication paradigms.
Esperanto, un progetto di ricerca portato avanti dal gruppo di ricerca MobiLab del
dipartimento di Informatica e sistemistica della facoltà di Ingegneria presso
l’università Federico II di Napoli, è una soluzione basata su CORBA che utilizza
un’approccio tuple-oriented per affrontare i suddetti problemi.
L’approccio tuple-oriented è basato sugli spazi di tuple. Le tuple sono collezioni
di campi di dati tipizzati. Ogni campo può essere un parametro formale se non
specificato, altrimenti è un parametro attuale. Gli spazi di tuple sono aree di
memoria condivisa che contengono collezioni di tuple, che possono essere
dinamicamente depositate o rimosse. In figura 1-4 è riportato un esempio di
comunicazione in uno spazio di tuple.
Figura 1-4 – Invio di un messaggio in uno spazio di tuple
Gli spazi di tuple forniscono disaccoppiamento nel tempo e nello spazio in una
comunicazione. Il disaccoppiamento nel tempo è dovuto al fatto che le tuple sono
persistenti e mittente e destinatario non hanno necessità di esistere
contemporaneamente. Il disaccoppiamento nello spazio è dato dal fatto che il
26
Capitolo 1
mittente non ha bisogno di conoscere l’identità e la location del destinatario o dei
suoi destinatari. Semplicemente immette le tuple nello spazio e quindi uno o più
processi leggeranno o rimuoveranno tali tuple.
L’approccio di Esperanto è quello di supportare oltre al consueto paradigma di
comunicazione tipica dei midlleware DOC (Distributed Object Computing) anche
ulteriori paradigmi di comunicazione, come notify o solicit/response, sia a
molteplicità singola che multipla.
In questo modo è possibile godere dei benefici del modello di comunicazione
tuple-oriented senza dover rinunciare per questo alle caratteristiche di successo
dei DOC middleware. Nel contempo, un supporto integrato alla mobilità dei
terminale e all’accesso tramite infrastrutture di rete wireless è tale da rendere il
middleware realmente efficace nella fornitura dei suoi servizi per lo sviluppo di
applicazioni distribuite mobili.
L’infrastruttura di nomadic computing viene decomposta in domini logicamente
e/o fisicamente distinti. In ogni dominio possono essere presenti numerosi devices
mobile. Ognuno di essi è collegato all’infrastruttura fissa mediante un wireless
link e può spostarsi fisicamente da un dominio all’altro. Per fornire un supporto
alla comunicazione tra dispositivi mobili, il modello concettuale si ispira a quello
della telefonia cellulare: in ogni dominio è presente un nodo di elaborazione,
residente sulla core network, in cui sono eseguiti i componenti che offrono servizi
di connettività. L’insieme di tali componenti è detto mediatore. Esperanto inoltre
è un middleware per lo sviluppo di applicazioni service-oriented: a supporto di
questo modello d’elaborazione, in Esperanto sono presenti sia i componenti per il
service delivery, come il mediator ma anche i componenti per il service discovery,
che viene effettuato dagli explorer e gli agents, deployed come i mediators nella
core network. Gli explorer si occupano del service discovery per i devices, e gli
agents si occupano di instradare le richieste di service discovery/delivery verso
altri domini. Esperanto inoltre, mediante gli Agents , offre un meccanismo per
l’integrazione di piattaforme middleware che implementano una SOA (Service
Oriented Architecture) distine.
27
Capitolo 1
L’obiettivo di Esperanto è infatti quello di realizzare una SOA nella quale i service
requestors ed i service providers sono i devices. Sono previsti opportuni
protocolli per gestire il discovery ed il delivery tra domini diversi nonché
l’handover di un dispostivo da un dominio all’altro.
Nella figura 1-5 è esplicata l’architettura appena presentata in maniera sommaria.
Si noti la suddivisione dell’infrastruttura in domini, i peer, ovvero i componenti in
esecuzione sui devices, i mediators, che si occupano del delivery delle tuple, gli
explorers, che si occupano del service discovery e gli agents, che possono essere
anche domain specific per domini non Esperanto (Es.: Jini,Bluetooth), il cui
compito è quello di pubblicare i servizi esportati dai devices nel proprio dominio e
di fornire interoperabilità tra i diversi domini Esperanto e tra i domini Esperanto
ed i generic domains.
Figura 1-5 – il modello architetturale di Esperanto
Tipicamente l’interoperabilità tra tecnologie distinte avviene con l’uso di bridge,
la cui adozione è trasparente se essi sono localizzati all’esterno di ogni dispositivo
28
Capitolo 1
che si vuol far interoperare. Ogni dominio viene quindi dotato di un componente
localizzato sulla core network, l’Agent che ha l’incarico di emulare (nel caso
domain-specific da un lato il comportamento di un client compatibile con il suo
dominio, dall’altro il comportamento di un servizio Esperanto. Nel caso di Agent
per domini Esperanto invece l’unico ruolo è quello di notificare la pubblicazione
di nuovi servizi.
29
Middleware con supporto per la qualità del servizio
Capitolo 2
Capitolo 2
2.1 Premessa
Nell’ultimo decennio la ricerca ha compiuto notevoli sforzi e progressi finalizzati
allo studio e sperimentazione dei meccanismi per la gestione della qualità del
servizio. Storicamente l’esigenza di fornire qualità del servizio è stata sentita
specialmente per applicazioni mission-critical, come quelle per il controllo delle
operazioni di volo dei caccia-bombardieri, i sistemi di puntamento missilistici, il
controllo di processo per sistemi industriali ad alto rischio come centrali nucleari
ed altoforni.
Del resto la repentina evoluzione delle tecnologie dell’hardware e delle
infrastrutture di telecomunicazioni, come già ricordato nel precedente capitolo, ha
di conseguenza allargato il focus della ricerca sulla qualità del servizio verso le
applicazioni ed i sistemi utilizzati nella vita di tutti i giorni.
Come riportato nel paragrafo 1.4, oggi anche i sistemi operativi general-purpose
sono dotati di un supporto per lo scheduling di processi real-time, e sono diffusi
diversi sistemi operativi ibridi, che estendono un Kernel tradizionale con
funzionalità real-time. Sono stati compiuti notevoli sforzi per mettere a punto
protocolli che consentano di offrire qualità del servizio nelle telecomunicazioni
(ATM, RSVP, DiffServ…). Ed analogamente sono stati messi a punto (o sono in
corso di sviluppo) diversi middleware con supporto statico e dinamico per la QoS.
Il presente capitolo sarà incentrato sull’analisi dell’architettura delle più affermate
ed assestate piattaforme middleware QoS-enabled, come:
•
Real-Time Corba (RT-CORBA) – Set di estensioni CORBA per fornire
agli ORB caratteristiche real-time.
30
•
Capitolo 2
\TAO (The Ace ORB) – Implementazione di un ORB compliant con le
specifiche RT-CORBA , sviluppato dal gruppo di ricerca sul Distributed
Object Computing (DOC) presso le università di Washington, Vanderbilt e
Irvine, in collaborazione con molte realtà commerciali e governative, come
Siemens, BBN o il DARPA (Defense Advanced Research Projects
Agency).
•
CIAO (Component Integradet Ace ORB) – implementazione del CORBA
Component Model (CCM) sviluppata dallo stesso gruppo DOC al di sopra
di TAO. Si propone di fornire un’astrazione per la gestione dalla QoS in
termini di metadati, in modo da separarla della logica applicativa, in modo
tale da rendere più flessibile lo sviluppo di applicazioni con requisiti di
Qualità del Servizio.
•
QuO (Quality Objects) – Framework per fornire qualità del servizio in
applicazioni distribuite sviluppato dalla BBN Technologies. Lo scopo di
QuO è fornire un supporto agli sviluppatori colmando il gap tra la QoS
specificata a livello socket ed il livello degli oggetti distribuiti, nel quale
ormai vengono sviluppate la quasi totalità delle applicazioni. Inoltre il
progetto QuO pone particolare enfasi sulla specifica, misura, controllo
della QoS ed adattamento delle applicazioni ai cambiamenti nei suoi
livelli.
TAO
è
ormai
una
piattaforma
relativamente
assestata
e
supportata
commercialmente. Anche QuO è un framework, il cui progetto, partito nel 1997, è
giunto ad un discreto punto di maturazione, tanto che viene utilizzato in diversi
progetti del DoD (Department of Defense) degli Stati Uniti d’America. CIAO
invece è un progetto ancora in corso (sebbene ne esista una release ufficiale
rilasciata nel dicembre 2003) ed è inserito nel progetto CoSMIC (Component
Synthesis with Model Integrated Computing).
31
Capitolo 2
Nel seguito del capitolo verranno analizzati in dettaglio le architetture ed i
meccanismi per la gestione della qualità del servizio delle piattaforme e
frameworks sopra elencati.
2.2 Real-Time CORBA
2.2.1 Scopi della specifica dell’OMG
Gli sviluppatori spesso si trovano di fronte a seri problemi quando devono gestire
l’allocazione delle risorse e la predictability del sistema, specie quando si trovano
in scenari nei quali è fondamentale la qualità del servizio. Fornendo strumenti per
gestire le suddette problematiche, Real-Time CORBA sacrifica parte della natura
general-purpose di CORBA per supportare lo sviluppo di sistemi con requisiti di
qualità del servizio [OMG 01]
2.2.2 Architettura di RT-CORBA
RT-CORBA è un set di estensioni completamente compatibili ed interoperabili con
CORBA.
Di
seguito
vengono
descritti
i
componenti
fondamentali
dell’architettura:
•
Real-time ORB – estensione dell’interfaccia dell’ORB standard che
gestisce la creazione la distruzione di oggetti utilizzati da RT-CORBA.
Gestisce anche le real-time policies per la configurazione dei Threadpools,
dei Priority Models e dei protocolli (Priority-Banded connections, Private
connections)
•
Real-Time POA – estensione dell’interfaccia PortableServer::POA
di CORBA. Fornisce supporto per la priorità delle operazioni objectspecific.
Gli RT-POA, così come i POA standard, possono essere
organizzati gerarchicamente e sono completamente compatibili tra loro.
Ad esempio è possibile creare un POA child dal root POA e quindi
eseguirne il narrowing con un RT-POA.
32
•
Capitolo 2
PriorityMapping – RT-CORBA fornisce uno schema universale e
platform-indipendent di priorità, al fine di superare l’eterogeneità degli
schemi di priorità nei diversi sistemi operativi. L’interfaccia si occupa di
trasformare le priorità CORBA in priorità native del particolare sistema
operativo.
•
Threadpools – RT-CORBA consente di creare e configurare insiemi di
Thread. In questo modo le invocazioni di metodi remoti potranno avere a
loro disposizione dei thread a priorità appropriata. Un ThreadPool è
costituito da Thread statici (che sono assegnati al ThreadPool all’atto della
sua creazione) e dinamici (che possono essere creati nel caso i thread
statici siano tutti impegnati), può avere differenti lanes caratterizzate da
diverse priorità, ed una queue per contenere le richieste in attesa su di
esso.
Figura 2.1 – L’architettura di Real-Time Corba
33
•
Capitolo 2
Current Interface – Utilizzata per impostare la priorità del thread
correntemente in esecuzione.
•
Real-time Scheduling Service – Fornisce un livello di astrazione per la
coordinazione dei parametri di schedulazione come priorità e politiche
degli RT-POA. E’ un componente “opzionale” della specifica RTCORBA, nel senso che gli ORB che vogliono essere compliant a tali
specifiche non devono necessariamente implementarlo.
2.2.3 Funzionalità
La specifica individua diverse funzionalità che devono essere integrate nell’ORB
per assicurare predictability per le attività (definite come flusso di informazioni
tra client e server, ovvero un messaggio in un protocollo di trasporto, una richiesta
tenuta in memoria e un thread schedulato su di un processore) tra client e server.
•
Meccanismi di scheduling sul sistema operativo
•
Gestione delle risorse dell’infrastruttura di comunicazione
•
Interfacce per la specifica dei resource requirements
2.2.4 Meccanismi per la gestione della QoS
2.2.4.1 GESTIONE DELLE RISORSE DEL PROCESSORE
Meccanismi di priorità
Ad ogni operazione (one-way o two-way) CORBA viene assegnata una priorità
(tra 0 e 32767) [SCHM 00]; questa priorità viene poi tradotta in una priorità nativa
del sistema operativo dove il metodo viene eseguito (come descritto al paragrafo
2.2.2). I modelli definiti per l’assegnazione delle priorità ai metodi sono due:
Server Declared e Client Propagated . Secondo il primo modello, il server
stabilisce la priorità alla quale vengono effettuate le invocazioni sui suoi metodi;
nel secondo modello il client determina la priorità a cui deve essere eseguito un
34
Capitolo 2
metodo. La priorità viene qui mappata sulle priorità dell’OS del server, e se
disponibile un thread a tale priorità il metodo viene eseguito. Nella figura 2-2
vengono riportati gli schemi dei modelli di priorità.
Figura 2.2 – Modelli di Priorità in RT-CORBA:
A) Server Declared; B) Client Propagated
Per modificare la priorità a di un’invocazione mentre la stessa viene eseguita RTCORBA supporta i Priority Transforms. In tal modo è possibile specificare nuovi
meccanismi di priorità diversi da Server declared e Client Propagated. Si parla di
inbound Priority transform quando il cambio di priorità viene effettuato dopo che
la richiesta è pervenuta al server, ma prima che venga eseguito il codice del
servant. Si parla invece di Outbound priority transform quando la trasformazione
viene effettuata all’atto di effettuare una ulteriore invocazione di metodo remoto
all’interno del codice del servant.
Thread Pools
Mediante questo meccanismo, RT-CORBA consente agli sviluppatori di
predisporre un insieme di thread già allocati e disponibili per l’esecuzione dei
metodi, nonché di assegnare la priorità a tali thread. Ad ogni POA è associato un
solo ThreadPool, che può essere anche condiviso da più POA. In altri determini,
35
Capitolo 2
diversi POA, con diverse politiche di configurazione Real-Time (Es.: uno con
multiplexed connections ed uno con private connections) possono utilizzare lo
stesso Threadpool. I threads sono allocati all’atto della creazione del threadpool e
quindi consumano risorse del sistema, a meno che non si tratti di threads
dinamici. Un Threadpool può essere suddiviso in lanes, ognuna con la sua
priorità, il suo numero di threads statici ed il suo numero di threads dinamici. Le
differenti lanes possono essere utilizzate per realizzare diverse tipologie di
servizio (Es.: bassa latenza, alta produttività e best-effort). Nel caso in cui una
lane a priorità P non abbia più thread allocabili ed arrivi una nuova richiesta, se
una delle lane a priorità Pi<P ha un thread disponibile, allora questo thread viene
prestato alla lane a priorità P e la sua priorità cambiata esclusivamente per il
tempo necessario all’esecuzione del metodo invocato, dopodichè viene restituito
alle lane originaria.
Real-time Scheduling Service
Tale servizio utilizza informazioni disponibili a tempo di progettazione sulle
associazioni tra attivtà, oggetti, risorse e priorità per realizzare una politica di
scheduling “globale”. Il codice applicativo utilizza dei nomi mnemonici (stringhe)
per specificare attività ed oggetti. Il servizio di Scheduling poi associa questi nomi
a parametri e policies da applicare agli ORB al fine di realizzare uno scheduling
real-time delle attività stesse, liberando il programmatore dalla difficoltà di
scegliere le politiche appropriate e le priorità giuste per i threads e di sviluppare
applicazioni che diventerebbero notevolmente più complesse.
La politica di scheduling globale realizzata dallo Scheduling Service dipende dalla
particolare implementazione. La specifica OMG non fornisce alcuna indicazione
su quale politica adottare (Rate Monotonic, Deadline Monotonic, etc. etc.).
2.2.4.2 GESTIONE DELLE RISORSE DI COMUNICAZIONE
Selezione e configurazione delle proprietà dei protocolli di rete
36
Capitolo 2
RT-CORBA definisce un’interfaccia per specificare proprietà specifiche dell’IOP
(Inter-ORB Protocol) e del protocollo di trasporto sottostante (Es: TCP) per
controllare diverse caratteristiche della comunicazione. Il server nella IOR espone
i protocolli disponibili e la loro configurazione, quindi il client ad ogni
invocazione può scegliere quale protocollo utilizzare ed effettua la richiesta.
Figura 2.3 – Connessioni Priority Banded e Private
Explicit Binding
In CORBA le risorse di comunicazione sono allocate on-demand, ovvero dopo la
prima invocazione di un client. Questo approccio non è adatto per applicazioni
che richiedono qualità del servizio, pertanto in RT-CORBA viene introdotto
l’Explicit Binding, che consente di pre-stabilire connessioni tra client e server e
controllare come le richieste dei client vengono inviate su queste connessioni.
Tale meccanismo è supportato mediante due policies:
•
Priority-banded connections
Viene specificata la priorità di ogni connessione di rete. La connessione
appropriata viene selezionata in base alla priorità della richiesta che deve
essere trasmessa.
•
Private Connections
Le connessioni, anche se Priority-Banded, sono comunque multiplexed, nel
senso che una stessa connessione viene utilizzata per diversi oggetti dello
stesso ORB. Questo non è desiderabile per applicazioni con stringenti requisiti
37
Capitolo 2
di qualità del servizio. Le Private Connections assicurano che una data
connessione mentre è utilizzata per una determinata invocazione non venga
utilizzata per altre invocazioni finchè non è giunta la reply della precedente, se
il metodo è two-way.
I due meccanismi possono essere combinati per realizzare Private Priority
Banded connections, come mostrato nella figura 2-3.
2.3 TAO (The ACE ORB)
TAO è un’implementazione di un ORB compatibile con lo standard CORBA 3.0
ed implementa anche le estensioni Real-Time CORBA. La piattaforma TAO è
stata sviluppata al di sopra di ACE (Adaptive Communication Environment) , un
framework orientato agli oggetti, che implementa diversi patterns per la
comunicazione in software concorrente, come descritto in [SCHM 00b].
2.3.1 Architettura ed ottimizzazioni di TAO
In Figura 2-4 è riportata sommariamente l’architettura di TAO, nella quale sono
evidenziati i componenti principali: il sottosistema di I/O (riceve ed inoltra
all’ORB le richieste provenienti dai livelli inferiori), il core dell’ORB con i
diversi reactor che gestiscono threads di assegnata priorità, il POA, nonché altri
componenti “verticali” come il runtime-scheduler e gli zero-copy buffers.
Il sottosistema di I/O real-time estende il supporto per CORBA nel sistema
operativo. Vengono assegnate priorità ai thread per l’I/O real-time affinché
vengano rafforzate la schedulabilità dei componenti applicativi e le risorse
dell’ORB.
38
Capitolo 2
Figura 2-4 – L’archittettura di TAO
Il core dell’ORB è basato sui componenti del framework ACE, come Acceptor e
Connector, Reactor e Tasks, in modo da ottenere un core altamente performante
per minimizzare i tempi di latenza nel processo verticale che le request e le reply
devono percorrere per scendere dal livello delle applicazioni al livello
dell’interfaccia di rete.
Il POA di TAO utilizza una tecnica di demultiplexing de-layered, in modo da
ottimizzare i tempi di dispatch delle richieste verso i metodi invocati.
Negli ORB convenzionali il dispatch procede nel seguente ordine: 1) ORB 2)
POA 3) Servant 4) Skeleton 5) Operation. In TAO invece una richiesta viene
automaticamente indirizzata attraverso l’utilizzo di chiavi che mappano
direttamente le richieste dei clients alle tuple oggetto/operazione.
39
Capitolo 2
Le stub e le skeleton di TAO effettuano rispettivamente marshaling ed
unmarshaling efficiente dei parametri delle invocazioni. Inoltre, le estensioni
definite in TAO consento la specifica di requisiti di qualità del servizio per le
invocazioni di metodi remoti, mediante le strutture RT_Info ed RT_Operation.
La gestione dinamica della memoria e l’overhead per la copia dei dati è uno dei
punti di debolezza delle implementazioni convenzionali di CORBA. Ciò è
aggravato dal fatto che per i sistemi real-time la frammentazione dell’heap può
portare ad un comportamento non uniforme per messaggi di dimensioni differenti
e per differenti carichi di lavoro. Inoltre l’utilizzo eccessivo della copia di dati
attraverso un ORB può significativamente abbassare la performance end-to-end
delle applicazioni. Attraverso l’utilizzo dello zero-copy buffer management le
richieste dei client sono inviate e ricevute verso e dalla rete senza incorrere in
alcun overhead dovuto alla copia di dati.
2.3.2 Il Real-time Scheduling Service (RTSS)
Il servizio di scheduling delle operazioni in tempo-reale implementato in TAO
merita una descrizione a parte. Rappresenta infatti il meccanismo più potente è
sofisticato per fornire garanzie di qualità del servizio alle applicazioni.
Il servizio RTS di TAO intende fornire una soluzione agli svantaggi tipici di uno
scheduling statico a priorità fissata, come RMS, e specificamente: gestione
inefficiente delle computazioni non periodiche, in quanto non tutti i task real-time
sono strettamente periodici, e per garantire staticamente l’allocazione di risorse
sufficienti bisogna assegnare all’applicazione un rate pari al suo minimo periodo
possibile, introducendo così tempi di inutilizzo della CPU; eccessiva
penalizzazione dovuta a periodi non armonici: due operazioni sono dette
armoniche se i loro periodi sono multipli l’uno dell’altro. Quando ciò non accade,
lo sfasamento delle operazioni produce intervalli di tempo CPU non schedulati,
come descritto in [LAYL 73]; gestione inflessibile della variazione dei requisiti
invocazione per invocazione: non è infatti detto che un metodo ad ogni
40
Capitolo 2
invocazione impieghi sempre lo stesso tempo per essere portato a termine. Con
uno scheduling statico invece bisogna dimensionare il tempo di esecuzione del
task necessariamente con il worst case execution time dell’operazione in corso.
Queste limitazioni possono essere risolte utilizzando tecniche di scheduling
dinamico, come EDF (Earliest Deadline First), MLF (Minimum Laxity First) e
MUF (Maximun Urgency First). Il primo assegna priorità maggiore ai task con la
deadline più vicina alla scadenza; il secondo assegna priorità maggiore a task per i
quali la differenza tra la deadline ed il tempo residuo di esecuzione (la laxity
appunto) è minore, mentre il terzo assegna priorità maggiore ai task la cui urgenza
è maggiore; in caso di parità di urgenza viene considerata la laxity.
Tuttavia va considerato il fatto che queste tecniche di scheduling introducono
non-determinismo in quanto può accadere che operazioni critiche possano essere
bloccate da operazioni non critiche oppure da un numero eccessivo di altre
operazioni critiche e quindi mancare la deadline, cosa che non accade con uno
scheduling RM in quanto il tempo di CPU a disposizione di ogni task è
staticamente preassegnato.
Le strategie di scheduling dinamico utilizzate dal RTSS di TAO si propongono di
utilizzare al massimo le risorse elaborative, preservare il più possibile le deadlines
dei task, prediligendo i task critici rispetto a quelli meno critici e realizzare un
meccanismo di scheduling adattativi: diverse applicazioni possono specificare
priorità diverse per le stesse operazioni, intendendo così in maniera «propria» il
concetto di criticità di un’operazione.
I parametri di qualità del servizio vengono specificati al servizio RTSS
utilizzando le strutture RT_INFO utilizzando le quali lo sviluppatore può
specificare:
•
Criticità dell’operazione
•
Tempo di esecuzione nel caso peggiore
•
Periodo d’esecuzione
41
•
Capitolo 2
Importanza (indicazione che serve a discriminare due operazioni che
potrebbero risultar avere la stessa priorità)
•
Dipendenze: un’operazione può dipendere da un’altra operazione se viene
invocata nel flusso di controllo solo do l’altra.
Lo scheduling service di TAO supporta sia lo scheduling statico RMS che le
tecniche dinamiche EDF, MLF e MUF. Le operazioni che vengono effettuate dal
RTSS sono descritte in [SCHM 98] ed esplicate nella figura 2-5, tratta dallo stesso
articolo.
•
Passo 1 (sia on-line che off-line): Specifica dei requisiti di QoS e loro
inoltro al RTSS. L’applicazione deve definire: 1) tutte le operazioni che
vuole schedulare; 2) una RT_INFO per ogni operazione; 3) le dipendenze
tra le operazioni da schedulare
•
Passo 2 (sia on-line che off-line): Tutte le informazioni inviate dalle
applicazioni al passo 1 vengono inserite in una repository. Le informazioni
sulle dipendenze vengono quindi utilizzate per costruire un grafo, nel
quale l’ultimo nodo è il consumatore e rappresenta l’operazione che deve
essere invocata per ultima, mentre il primo nodo è il produttore e
rappresenta l’operazione che deve essere invocata per prima.
Figura 2-5 – Passi operativi del servizio di scheduling real-time di TAO
42
•
Capitolo 2
Passo 3 (eseguito Off-line, ovvero prima che l’applicazione vada in
esecuzione) – Viene asserita la schedulabilità di un set di operazioni
richieste dall’applicazione. La schedulabilità è asserita se l’utilizzo di CPU
delle operazioni critiche e non critiche dell’applicazione è minore o uguale
al limite di schedulabilità fissato.
•
Passo 4 (off-line) – Vengono assegnate le priorità statiche e dinamiche
alle operazioni. Questu valori sono assegnati secondo la strategia scelta
per lo scheduling (RMS,EDF,...)
•
Passo 5 (off-line) – Le priorità statiche vengono mappate sulle priorità di
dispatching, che verranno utilizzate dal RTSS per configurare l’ORB
durante l’esecuzione delle operazioni.
•
Passo 6 (off-line) – Vengono configurate le code per il dispatching delle
operazioni.
•
Passo 7 (on-line) – Il componente runtime scheduler fornisce all’ORB le
informazioni sul dispatching di ogni operazione schedulata.
•
Passo 8 (on-line) – Ricevute le informazioni dal runtime scheduler, l’ORB
configura i suoi moduli di dispatching, ovvero real-time I/O Subsystem ed
ORB Core
•
Passo 9 (on-line) – Una invocazione arriva da un client, i moduli di
dispatching inoltrano l’operazione alla coda appropriata (configurata
ovvero al passo precedente per supportare quell’operazione).
•
Passo 10 (on-line) – Viene aggiornata la priorità dinamica dell’operazione,
se la coda è dinamica. Tale passo viene ripetuto ogni volta che nuove
operazioni vengono inserite nella coda.
Senza entrare nei dettagli delle scelte progettuali fatte per il RTSS di TAO, il
processo che segue una RT_INFO nei passi da 1 a 10 è il seguente:
•
Viene trasformata in una urgency tuple, dove viene definita una priorità
statica (nel caso MUF determinata dalla criticità espressa nella RT_INFO,
43
Capitolo 2
ad esempio), una subpriorità dinamica (sempre nel caso MUF definita da
periodo e tempo d’esecuzione, ed una subpriorità da statica (definita nel
caso MUF dalle dipendenze e dall’importanza) . L’ordinamento delle
operazioni viene effettuata prima per priorità statica, quindi per subpriorità
dinamica ed infine per subpriorità statica.
•
La urcency tuple viene quindi trasformata in una dispatching priority ,
divisa a sua volta in una priority ed una subpriority. La priorità statica
mappa sulla dispatching priority, le altre due, nell’ordine, sulla
dispatching subpriority.
•
Le dispatching priorities sono priorità RT-CORBA che vengono mappate
dai meccanismi visti al paragrafo 2-2 su priorità del sistema operativo.
Questo sofisticato meccanismo di scheduling, i cui risultati in termini di
performance sono mostrati in [SCHM 98], consente agli sviluppatori di dichiarare
in maniera non estremamente complicata I requisiti di qualità del servizio delle
proprie applicazioni, nonchè di ottimizzare la gestione dell’allocazione delle
risorse di CPU.
2.4 CIAO (Component Integrated ACE ORB)
CIAO è un’implementazione del Corba Component Model, standardizzato nel
2002 dall’OMG. Tale standard non ha alcun supporto per la qualità del servizio, è
questo come evidenziato in [WANG 01] comporta seri limiti per lo sviluppo di
sistemi distribuiti con requisiti di qualità del servizio. Infatti gli sviluppatori, pur
potendo incorporare del codice per la fornitura di qualità del servizio all’interno
dell’implementazione di un componente (ad esempio utilizzando TAO, che è
anche la base di CIAO), non possono realizzare una gestione integrata della
qualità del servizio in quanto:
44
•
Capitolo 2
La fornitura di qualità del servizio deve essere effettuata end-to-end,
ovvero deve essere applicata a molti componenti interagenti.
•
Alcune risorse, come i threadpools, possono essere istanziati solo su una
più ampia unità di esecuzione, ad esempio un component server anziché
un component. Poiché gli sviluppatori do componenti non sanno a priori
con quali altri componenti si andrà a collaborare, il giusto livello al quale
fornire implementazione di QoS non è l’implementazione del componente.
•
Alcuni meccanismi per garantire QoS, come le private connections, hanno
a che fare con le interconnessioni tra componenti. A priori non è possibile
stabilire con quali componenti si andrà ad interagire, per cui non è
facilmente ipotizzabile uno scenario in cui i componenti isolatamente
stabiliscono le policies per la QoS.
CIAO dunque si pone l’obiettivo di estendere il CCM per includere un supporto
per il QoS Provisioning end-to-end tra i componenti.
2.4.1 Architettura di CIAO
Nella figura 2-6 sono riportati i blocchi costituenti l’architettura di CIAO.
Allo stato corrente dello sviluppo (come evidenziato al paragrafo 2.1 la prima
versione ufficiale (0.4) è stata rilasciata nel dicembre 2003), CIAO supporta la
versione 3 dell’IDL e vi sono state aggiunte molte caratteristiche del CIDL
(Component Interface Definition Language). Supporta tutti i tipi di porte per
componenti: facets (interfaccia che serve in maniera sincrona metodi remoti),
receptacles (punti di connessione per i facets) , event sources ed event sinks, che
servono a gestire lo scambio di messaggi di evento tra diversi componenti in
maniera asincrona.
Senza entrare nei dettagli del CCM, per i quali si rimanda a [OMG 02], CIAO
implementa quasi tutte le funzionalità richieste dalla specifica (tranne alcune,
come la nuova specifica per deployment and configuration ptc/03-07-02 ed il
supporto per lightwight components, ptc/04-02-03).
45
I componenti sono arrichiti con delle QoS policies
Capitolo 2
che consentono agli
sviluppatori di specificare le configurazioni real-time come descrittori XML senza
influenzare l’implementazione del componente.
Figura 2-6 – Architettura di CIAO
Rispetto al middleware QoS-enabled tradizionale il Component Middleware QoSEnabled si distingue appunto per il ciclo di sviluppo di un’applicazione e per la
distinzione delle figure professionali coinvolte nell’applicazione, grazie alla
separazione tra la logica funzionale dell’applicazione e le problematiche di
«sistema», tra cui appunto la gestione della Qualità del servizio.
2.4.2 Supporto per la QoS in CIAO
46
Capitolo 2
CIAO, che è stato sviluppato su TAO eredita le caratteristiche del middleware
QoS-Enabled da cui deriva ed è dotato di funzionalità per fornire ai componenti
QoS statica (si veda par 1.3.4).
Lo standard CCM viene esteso da CIAO in modo tale da fornire QoS nel seguente
modo:
•
Descrittori per gli assembly delle applicazioni – Nella specifica CCM
specifica
come
i
componenti
sono
interconnessi
per
formare
un’applicazione. CIAO estende la specifica includendo specifiche per il
provisioning di QoS. Viene esteso il formato del descrittore dell’assembly
per supportare la specifica di requisiti di QoS a livello di connessioni tra
componenti.
•
Aggregati di configurazione per i client – un ORB di un’applicazione
Client può essere configurato per supportare varie policies come priority
level policy e custom priority mapping. Tali aggregati vengono quindi
associati ai client e sono utilizzati per interagire con i server e fornire QoS
end-to-end. CIAO consente di installare in maniera trasparente questi
aggregati nell’ORB client.
•
QoS-enabled containers – CIAO migliora i containers così come definiti
in CCM per supportare funzionalità di gestione della QoS, come politiche
RT-CORBA. Specificamente le politiche a livello di componente in CIAO
sono le stesse a livello di POA in TAO ovvero: Priority Model,
Threadpool, Banded Connection. Invece risorse come Threadpools (con o
senza lanes), connection bands, sono comuni all’intero component server,
all’interno del quale sono istanziati i component containers.
•
QoS Adaptation – CIAO supporta l’installazione di hooks che possono
essere utilizzati per iniettare QoS dinamica in maniera trasparente. In altri
termini l’adattatività non è fornita da CIAO, ma è possibile far interagire i
componenti con altri oggetti che forniscono QoS dinamica agli stessi.
47
Capitolo 2
Gli sviluppatori, utilizzando i modelli di priorità ed i livelli di priorità delle istanze
dei componenti possono allocare staticamente risorse di CPU; utilizzando private
e banded connections possono riservare risorse di comunicazione per le
interconnessioni tra i componenti.
Inoltre è possibile installare, attraverso opportune policies di Distributed
Middleware Configuration moduli addizionali come protocolli di comunicazione
personalizzati o moduli software come quelli per supportare QoS dinamica, uno
dei quali verrà mostrato nel successivo paragrafo.
2.5 QuO (Quality Objects)
2.5.1 Middleware e qualità del servizio dinamica
Alcuni eventi, come fluttuazioni nella disponibilità delle risorse,cambiamenti nei
requisiti di QoS o ridotte capacità del sistema a causa di failures, possono forzare
la rivalutazione e riallocazione delle risorse. Le funzionalità richieste al
middleware per fornire QoS dinamica, come descritto in [WANG 01] sono le
seguenti:
•
Individuare le variazioni nelle risorse a disposizione: il middleware deve
monitorare lo stato del sistema per capire se sono necessarie riallocazioni.
Ad esempio un’applicazione per video conferencing è sensibile ai
cambiamenti nella larghezza di banda a disposizione.
•
Supporto alle applicazioni per favorire l’adattamento alle variazioni
modificando l’assegnazione delle risorse richieste da un’applicazione:
tornando all’esempio precedente l’applicazione per il video conferencing a
seguito di un decadimento della banda a disposizione può decidere di
abbassare la risoluzione temporaneamente e passare di nuovo ad una
risoluzione più alta quando una opportuna larghezza di banda ritorna a
disposizione.
Sebbene le applicazioni possano includere nel loro stesso codice la gestione
dinamica della QoS, questi approcci ad-hoc portano a codice non portabile che
48
Capitolo 2
dipende da specifiche caratteristiche del sistema operativo utilizzato ed
implementazioni della gestione della QoS strettamente accoppiato con il codice
relativo alla logica funzionale dell’applicazione stessa.
E’ dunque fondamentale [WANG 01] separare le funzionalità per la fornitura di
QoS dinamica sia dal middleware di distribuzione che dalle funzionalità
dell’applicazione. Dunque viene introdotto un nuovo livello di astrazione tra le
applicazioni ed il middleware, il QoS Adaptive Layer.
2.5.2 Sviluppo di applicazioni adattative con QuO
QuO estende il middleware tradizionale per aiutare gli sviluppatori a creare e
riutilizzare codice adattativo, tenendo separato il codice per l’adattatività da quello
per implementare la logica funzionale di un’applicazione.
Specificamente, come descritto in [BBN 02], QuO consente ad un’applicazione
di:
•
Specificare il livello di servizio desiderato – un’applicazione può
specificare i suoi requisiti non funzionali, come tempi di risposta, utilizzo
di memoria, larghezza di banda controllata, o addirittura dependability.
•
Specificare le alternative comportamentali e le strategie per adattarsi ai
differenti livelli di servizio – un’applicazione può scegliere diversi
comportamenti basati sul sua corrente regione di funzionamento, che a sua
volta funzione del livello di QoS corrente nel sistema.
•
Misurare e controllare le risorse e le condizioni del sistema – Le
applicazioni possono accedere ad interfacce, definite in QuO, per
monitorare lo stato attuale del sistema.
Il framework QuO realizza le sopra indicate funzionalità mediante i seguenti
elementi:
•
Linguaggi per la descrizione di contratti tra i clients e gli oggetti di un
sistema distribuito (CDL – Contract definition language), per la
descrizione dei comportamenti adattativi (ASL – Adaptive specification
49
Capitolo 2
language), e sonde per misurare e controllare la QoS nel sistema ed i
meccanismi che la imprimono
•
Generatori di codice
•
Un kernel per organizzare, schedulare e gestire la valutazione dei contratti
•
Librerie riutilizzabili di oggetti per monitorare la condizione del sistema e
controllare i meccanismi dei livelli sottostanti (RT-ORB e/o sistema
operativo) per la gestione della qualità del servizio.
2.5.3 Come QuO introduce QoS dinamica in un’applicazione
In una normale applicazione CORBA, le invocazioni di metodo remoto passano
dal client al servant attraverso l’ORB del client che effettua il marshaling dei
parametri, comunica con l’ORB server mediante un protocollo inter-orb
(GIOP,IIOP,…) e quindi l’ORB server effettua l’unmarshaling dei parametri e
dispaccia la richiesta all’opportuno servant.
Nella figura 2-7 è descritta un interazione tra un client ed un oggetto servente
utilizzando i QuO.
Figura 2-7 – Un’interazione remota gestita da QuO
50
Capitolo 2
I contratti definiscono le diverse regioni di funzionamento di un’applicazione e
per ognuna di queste i parametri di QoS desiderati, nonché le regole per le
transizioni tra gli stati. Sono collegati ad uno o più oggetti SysCond, che
forniscono interfacce alle risorse ed i meccanismi del sistema. Forniscono
interfacce di alto livello per misurare, manipolare e controllare le funzionalità di
basso livello di controllo real-time e misurazione delle risorse. i diversi tipi di
oggetti SysCond definiti in QuO sono riportati in figura 2-8 e sono descritti di
seguito:
•
I Simple Value, sono gli oggetti più semplici e non fanno altro che
memorizzare dei valori settati da un client o da qualche altra entità.
•
I measured value, memorizzano dati che rappresentano misure (ad
esempio il throughput di un client o il carico di un nodo)
•
I Composed value, effettuano calcoli a volte anche complicati sui valori di
QoS misurati per fornire un valore semplice al contratto
•
I Control value utilizzano direttamente i meccanismi per il supporto della
QoS forniti dall’ORB o dal sistema operativo, oppure utilizzano tale
supporto indirettamente, attraverso un opportuno provider di meccanismi
che fornisce un’interfaccia semplifica all’oggetto Syscond per la
manipolazione dei meccanismi di basso livello per la gestione della QoS
(in tal caso anche il livello dell’ORB viene inteso come «basso livello»)
•
Gli Status value, che forniscono valori che provengono direttamente
dall’ORB, dal sistema operativo o indirettamente da questi tramite i
provider di cui al punto precedente.
51
Capitolo 2
•
Figura 2-8 – Un’interazione remota gestita da QuO
Infine i Delegates sono componenti adattativi che modificano il comportamento
del sistema a runtime .
Sono supportati due diversi modelli per fornire comportamenti adattativi:
•
In-band adaptation – effettuata dai delegates, fornisce adattatività e
controllo della QoS nell’accesso all’oggetto remoto
•
Out-of-band adaptation – effettuata attraverso i contratti e gli oggetti
SysCond. Se viene rilevata una modifica nelle condizioni del sistema,
viene asincronamente effettuata una rivalutazione dei contratti che può
portare ad una variazione di regione di funzionamento delle applicazione,
con conseguente adattamento asincrono delle applicazioni alle nuove
condizioni del sistema
2.5.4 I Qoskets: supporto per il riutilizzo di comportamenti sistemici
Un Qoskets è una collezione di interfacce, contratti, oggetti SysCond,
comportamenti adattativi non specializzati e codice implementativo.
52
Capitolo 2
Un Qosket è completamente specificato dai contratti, gli oggetti SysCond ed i
componenti di callback che incapsula; dai modelli ASL che definiscono parziali
specifiche di comportamenti adattativi; da codice implementativi per istanziarie i
componenti incapsulati nel Qosket stesso, e dalle interfacce che lo stesso Qosket
espone. Tutti questi elementi sono riportati in figura 2-9.
Figura 2-9 – Composizione di un Qosket
Il Qosket espone due interfacce standard:
•
Adapter – API per l’accesso alle funzioni di misura, controllo ed
adattatività nel Qosket. Utilizzata per effettuare out-of-band adaptation
•
Delegate- interfaccia per l’adattatività in-band. I comportamenti adattativi
dei delegati sono specificati in ASL. Le strategie adattative sono quindi
introdotte nell’applicazione utilizzando i generatori di codice.
2.6 Analisi dei middleware QoS-Enabled
Nel corso del capitolo sono state presentate diverse soluzioni middleware QoSenabled, tutte legate tra loro: TAO è un’implementazione di RT-CORBA, CIAO è
un component middleware sviluppato su TAO, e QuO è un strato middleware che
risiede al di sopra del distribution middleware (come TAO) e fornisce QoS
dinamica. Ad esempio in [WANG 01] si fa riferimento all’utilizzo combinato di
CIAO e Qoskets per fornire QoS statica e dinamica alle applicazioni distribuite.
53
Capitolo 2
Progressivamente, con l’evoluzione delle tecnologie middleware, il supporto agli
sviluppatori, per la specifica dei requisiti di QoS ed il loro enforcement è andato
decisamente migliorando, tanto che come descritto in [WANG 01] e [WANG 04]
la specifica delle real-time policies per riconfigurare ORB, POA e servants in
CIAO è stata totalmente astratta dall’implementazione del componente stesso. Gli
sviluppatori possono utilizzare dei metadata per specificare requisiti e politiche
per la qualità del servizio. Tutto ciò viene ovviamente pagato in termini di
performance del middleware stesso, infatti come mostrato nei risultati
sperimentali riportati in [WANG 04] la performance di un’applicazione scritta
utilizzando CIAO è circa del 5% inferiore rispetto alla performance della stessa
applicazione scritta utilizzando TAO. Il trade-off in questo caso è tra la semplicità
e modularità del processo di sviluppo, configurazione e deploying delle
applicazioni offerta dal component middleware e le prestazioni elevate offerte da
un middleware standard con funzionalità real-time.
Di seguito viene riportata una comparazione delle tecnologie elencate in questo
paragrafo relativamente agli aspetti di gestione della QoS statica e dinamica
evidenziati nei par.1.3.4 e 1.3.5
Per ognuno di tali aspetti viene indicato se è supportato, parzialmente supportato o
per niente supportato dalla particolare tecnologia. Nei primi due casi vengono
sinteticamente indicati quali sono i meccanismi che la tecnologia stessa mette a
disposizione per gestire il particolare aspetto di qualità del servizio.
Nella comparazione non viene inserito RT-CORBA, in quanto standard. La
tecnologia che implementa le caratteristiche di RT-CORBA, nella trattazione
effettuata in questo capitolo, è TAO. I risultati della comparazione sono riportati
nella tabella 2-1.
Nessuna delle soluzioni presentate fornisce un supporto alla mobilità e nomadicità
degli utenti. In fatti in questi lavori viene sviluppato un distribution middleware,
che è di tipo general-purpose e non domain-specific, come invece un middleware
per nomadic computing. Questi strumenti possono rappresentare una valida base
di partenza sulla quale poi costruire piattaforma middleware specializzate per
54
Capitolo 2
fornire servizi a specifici tipi di applicazioni e/o specifici ambienti come appunto
il nomadic computing. Altre soluzioni middleware studiate per ambienti mobile
saranno illustrate nel Capitolo 6.
O
S
S
Descrittori specificati con
metalinguaggi (XML)
Definizione dei contratti
N
N
Riservazione
risorse
…
…
Dimensioni dei threadpools Meccanismi del Real Time
ORB sottostante
e lanes ; analisi off-line di
RTSS
S
Meccanismi di gestione dei
contratti
S
S
…
Priority models; banded &
private connections; RTSS
QoS Policies nei
componenti
Utilizzo di meccanismi dei
livelli sottostanti
N
N
S
Oggetti SysCond
Monitoraggio
N
N
S
Interazione tra contratti e
oggetti SysCond
Policing
…
Manutenzione
S
oggetti SysCond
Negoziazione
Controllo
d'ammissione
QuO
CIA
TAO
Specifica
S
Strutture RT_INFO,
parametri di basso livello
…
Schedulazione dinamica di
RTSS; interfaccia
RTCORBA::Current
Hooks a componenti
esterni
N
…
Rinegoziazione
Hooks a componenti
esterni
N
Adattatività
…
oggetti SysCond
S
oggetti SysCond
…
S
Hooks a componenti
esterni
Out of band & in-band
adaptation
Legenda: S = caratteristica supportata;…= caratteristica parzialmente supportata; N =
caratteristica non supportata
Tabella 2-1 – Comparazione tra TAO,CIAO e QuO rispetto agli aspetti di
QoS statica e dinamica
55
Introduzione alla qualità del servizio in Esperanto
Capitolo 3
Capitolo 3
3.1 Esperanto, middleware per nomadic computing
3.1.1 Motivazioni e contesto
Esperanto è stato concepito come un middleware per ambienti di nomadic
computing e si propone di integrare le tecnologie di discovery e di delivery dei
servizi. Attualmente nessuna delle soluzioni di delivery e discovery esistente ha:
•
La capacità di imporsi sulle altre tecnologie
•
L’esplicito intento di rispondere alle esigenze degli utenti di ambienti
nomadici.
Il bridiging tra le diverse tecnologie appare dunque inevitabile. Esperanto si
propone l’ambizioso obiettivo di integrare diversi domini, appartenenti a
tecnologie diverse, in un’unica infrastruttura omogenea.
3.1.2 Architettura di Esperanto
Nella figura 1-5 è stato già riportato il modello architetturale di Esperanto.
L’ambiente nel quale si svolgono le interazioni remote viene suddiviso in domini,
ognuno dei quali può essere o meno un dominio Esperanto. Nel caso di domini
Esperanto, questi è costituito da un certo numero di peers connessi mediante una
core network, che funzionalità di service discovery e delivery, ad altri peers,
appartenenti allo stesso dominio o ad altri domini, non necessariamente
Esperanto.
All’interno della core network il componente, l’Esperanto Explorer si occupa del
service discovery, mentre un altro componente, l’Esperanto Mediator si occupa
del service delivery. L’Esperanto peer, dislocato sul device, utilizza il middleware
56
Capitolo 3
Esperanto. Implementa dunque un service requestor o un service provider, o
ambedue contemporaneamente.
L’Esperanto explorer ha il compito di catalogare i servizi offerti da tutti i peer nel
suo dominio di competenza, e di soddisfare le richieste di service discovery e
service access description. Tali richieste possono essere relative ad un servizio
che non è offerto da nessun peer nel dominio, per cui l’esperanto Explorer non
possiede tali informazioni nel suo catalogo. Mediante la collaborazione tra l’agent
del dominio locale e l’agent del dominio remoto, che può anche non essere un
dominio esperanto, le informazioni vengono fornite all’Explorer che quindi le
rigira al peer che ne aveva fatto richiesta.
L’Esperanto Mediator ha invece il compito di supportare la comunicazione tra
due o più peers. Consente di effettuare comunicazione asincrone, disaccoppiate
nel tempo e nello spazio, grazie all’astrazione fornita dallo spazio di tuple già
descritto al par. 1.4.4: i peers non comunicano direttamente ma tramite il
mediatore; l’interazione funziona comunque anche se per brevi periodi di tempo
una delle controparti (client o server) non dovesse essere presente; l’uso di
primitive non bloccanti per l’accesso al mediatore consente ai peer di continuare a
lavorare anche dopo l’invocazione della primitiva.
Gli agents consentono la condivisione dei servizi tra i diversi domini.
Nel caso di domini di altre tecnologie, come Jini, il domain specific agent si
occupa dell’importazione dei servizi esterni verso il dominio locale e
dell’esportazione dei servizi interni verso i domini remoti. Inoltre si occupa di
realizzare dei proxy che nascondano le differenze tecnologiche tra i due domini. In
pratica deve garantire: l’interoperabilità tra un servizio del suo dominio di
competenza ed un cliente Esperanto, mediante un Server Side Proxy;
l’interoperabilità tra un cliente del suo dominio di compenteza ed un servizio
Esperanto, mediante un Client Side Proxy.
La parte di delivery di Esperanto è costituito da due principali piattaforme: una
relativa al dispositivo (device-side platform) ed una relativa alla core network. La
prima, come descritta in [COTR 04] si occupa di connettere i device con il
57
Capitolo 3
mediator e di fornire alle applicazioni un’astrazione ad oggetti distribuiti dei
servizi. Per quanto concerne il service delivery il mediator è sicuramente il
«cuore» di Esperanto, in quanto si occupa di gestire le connessione tra i terminali
nel suo dominio e tra terminali in altri domini in comunicazione con terminali del
proprio dominio.
Nel seguito del capitolo l’attenzione verrà posta esclusivamente sul service
delivery in Esperanto.
3.1.3 Esperanto Broker
In figura 3-1 è riportata l’architettura a livelli dell’Esperanto Broker, tratta da
[COTR 04]. Si evince subito la distinzione tra la piattaforma device-side e la
piattaforma mediator-side. Le due piattaforme sono interconnesse mediante un
link di rete che solitamente è wireless. Al livello più basso dello stack protocollare
del middleware l’interazione tra i device e mediator è affidata al livello ncsocks ,
un set di API che forniscono ai devices servizi di connessione connection e
location aware. I mediators invece interagiscono tra loro sfruttando infrastrutture
di comunicazione fornite dai middleware COTS (Common off-the-shelf), come
implementazioni di CORBA o CCM.
Figura 3-1 – Organizzazione a livelli dell’Esperanto Broker
Tale scelta è dovuta al fatto che il middleware COTS non è adatto per le
caratteristiche di limitata potenza elaborativi dei devices.
58
Capitolo 3
3.1.3.1 DEVICE SIDE
La piattaforma device-side fornisce delle facilities per astrarre lo sviluppatore dal
particolare link wireless (IrDA,Bluetooth,Wi-fi,…) , si occupa di incapsulare in
tuple le invocazioni remote per gestirne poi il delivery attraverso il mediatore
nell’infrastruttura di rete, e fornisce agli sviluppatori un linguaggio IDL per
definire le interfacce degli oggetti Esperanto, in cui le invocazioni possono essere
di tipo request/response (il client invoca un metodo remoto sul server ed attende
una risposta), one-way (il client invoca un metodo sul server senza attendere
alcuna risposta), solicit/respone (comunicazione iniziata dal server, il client
fornisce una risposta) o notify (in pratica è una oneway iniziata dal server).
Verrà ora fornita una descrizione dei livelli della piattaforma client-side: livello
ncsocks, livello di Delivery delle tuple, Livello Stub/Skeleton.
•
Ncsocks layer – Fornisce ai livelli soprastanti un canale di comunicazione
basto su IP, astraendo il particolare mezzo di comunicazione utilizzato. Le
applicazioni possono monitorare lo stato del link di rete e i cambi di
Access Point, in modo da innescare procedure di handover di basso livello.
•
tuple delivery layer – Fornisce le primitive per accedere allo spazio di
tuple. Essenzialmente tali primitive sono: write (scrive una tupla sullo
spazio), read (legge una tupla dallo spazio), take (legge e rimuove una
tupla dallo spazio), e notify (riduce l’overhead per il recupero delle tuple
dallo spazio.
•
Stub/skeleton layer – Compiono rispettivamente il marshalling e
l’unmarshalling delle invocazioni di metodo remoto in operazioni su tuple,
fornendo così agli sviluppatori un’astrazione di invocazione di metodo
remoto e celando lo spazio di tuple. Fornisce quattro metodi di
invocazione:
request/response;
asynchronous
solicit/response, precedentemente descritti.
59
one-way;
notify;
Capitolo 3
3.1.3.2 CORE NETWORK SIDE
Il componente cruciale della core network, rispetto al service delivery, è il
mediator. E’ infatti suo compito gestire le connessioni intra-dominio ed interdominio dei peers e fornire agli stessi l’astrazione di uno spazio di tuple
distribuito. Nell’implementazione di Esperanto i mediators e diversi oggetti
costituenti il mediator stesso comunicano tra di loro mediante un ORB CORBA.
Verranno ora descritti gli oggetti che costituiscono il mediator.
•
Bridge: effettua il mapping delle PDU contenenti in operazioni sullo
spazio di tuple. Ad esempio una PDU contenente un’operazione di write
con la relativa tupla viene tradotta in operazioni sul dispatcher e sul tuple
manager (locale o remoto, secondo la destinazione della tupla).
•
Dispatcher: fornisce trasparenza circa la destinazione della tupla, nel senso
che alla piattaforma device-side viene nascosto il fatto che la tupla stia
venendo instradata sul mediator locale o su qualche mediator remoto.
Avvia le operazioni di scrittura e lettura sullo spazio di tuple; gestisce i
protocolli di supporto alla mobilità dei devices, che saranno descritti nel
successivo sottoparagrafo.
•
Device manager: tiene traccia della location dei devices di cui il dominio
corrente è l’home domain, anche se questi si trovano in domini diversi
(sono roamers); tiene inoltre traccia di tutti i roamer devices attualmente
presenti nel dominio, vale a dire di tutti i dispositivi di cui il dominio
corrente è l’host domain, ma non l’home domain.
•
Oggetti per la gestione delle tuple: forniscono le primitive per la gestione
delle tuple, vale a dire read,take,write,subscribe ed unsubscribe. Le prime
tre realizzano le analoghe funzioni del tuple delivery layer della
piattaforma device-side. Le ultime due consentono l’iscrizione e la
rimozione di un device dal servizio di notifica della ricezione di tuple.
3.1.3.3 I PROTOCOLLI PER IL SUPPORTO ALLA MOBILITÀ: TDPAM E HOPAM
60
Capitolo 3
A supporto della mobilità dei devices sono forniti due protocolli: Tuple Delivery
Protocol Among Mediators (TDPAM) e HandOver Protocol Among Mediators
(HOPAM); il primo si occupa di gestire il delivery della tupla attraverso domini
diversi, il secondo di gestire l’handover di un device tra due domini fornendo
l’astrazione di una comunicazione seamless.
•
TDPAM - Le operazioni effettuate nella protocollo di delivery delle tuple
tra diversi mediatori sono le seguenti:
1. Il dominio host della tupla viene richiesto al device manager
locale; la tupla viene inviata al dominio host del peer destinatario
2. Il mediator del dominio host recupera il deviceID dalla tupla
3. Si verifica che il device DeviceID sia presente nel dominio
4. In caso positivo la tupla viene scritta nello spazio del mediator
host.
5. In caso negativo viene inviata un’eccezione al mediator mittente.
6. Il mediator mittente contatta il mediator del dominio home del
device destinatario.
7. Il device manager del dominio home cerca il corrente dominio host
del device destinatario.
8. L’informazione viene restituita al mediator del dominio del peer
mittente.
9. Il device manager del dominio del peer mittente aggiorna le
informazioni circa la locazione del device destinatario.
10. La tupla viene inviata al mediator del nuovo dominio host.
11. Il device DeviceID stavolta è presente nel dominio.
12. La tupla viene scritta
In figura 3-3 è riportato il diagramma di collaborazione del protocollo TDPAM.
61
Capitolo 3
Figura 3-3: Diagramma di collaborazione del protocollo TDPAM
Il problema di cui al punto 4 si verifica quando il device destinatario effettua un
handover durante la comunicazione con il device mittente. Non è quindi un
problema raro. Viene risolto dunque con l’utilizzo del device manager del
dominio home. Il dominio home viene avvisato del cambiamento di locazione dei
propri dispositivi durante le operazioni del protocollo HOPAM.
•
HOPAM – gestisce gli handover dei devices e garantisce la correttezza
delle operazioni svolte dal protocollo TDPAM. Effettua le seguenti
operazioni:
1. Tutte le tuple destinate al device che ha effettuato l’handover
vengono trasferite dallo spazio di tuple del vecchio dominio allo
spazio di tuple del nuovo dominio.
2. Viene inviata una notifica al mediator del dominio home affinchè
aggiorni il suo device manager.
I device periodicamente inviano un messaggio di greeting al proprio mediator. In
tale messaggio viene riportato il deviceID, l’identificativo dell’home mediator
(DHOI) e dell’host mediator (DHSI). La procedura di handover viene innescata se
CHSI ≠ DHSI, dove CHSI è l’identificativo del corrente host mediator.
62
Capitolo 3
3.2 Il Problema della qualità del servizio in Esperanto Broker
La qualità del servizio percepita nelle interazioni tra peers Esperanto viene
influenzata da diversi fattori dovuti alla natura mobile dei devices. Tali fattori
sono imputabili alle seguenti problematiche:
•
Mobilità dei devices
•
Qualità del link wireless
•
Carico computazionale dei mediators
•
Comunicazioni inter-dominio
•
Cambi di contesto
•
Limitata potenza dei devices
Tali problematiche verranno analizzate nel seguito di questo paragrafo, al termine
del quale verranno formulati i requisiti di un sistema di gestione della QoS per
Esperanto Broker.
3.2.1 Mobilità dei devices
A causa della mobilità dei devices ci si trova di fronte a numerosi handover tra un
dominio ed un altro. Il protocollo HOPAM definisce le operazioni da effettuare
affinché l’interazione possa continuiare anche dopo l’handover.
Tali operazioni sono tuttavia fonte di considerevole overhead nell’infrastruttura,
sia in termini di computazione che di comunicazione, dovuto al trasferimento
delle tuple destinate al device roamer e non ancora lette, nonché
all’aggiornamento del device manager dell’home domain del device roamer..
Al di là del sovraccarico nell’infrastruttura, l’handover rappresenta anche un
problema molto serio nel mantenimento dei livelli di qualità del servizio richiesti
dall’applicazione. In presenza di handover infatti la latenza nel dispatch di una
tupla risulta aumentata a causa de seguenti fattori:
•
Prima che il device nel nuovo dominio possa accedere alle tuple deve
attendere che queste siano trasferite dal vecchio dominio al nuovo.
•
Gli altri device in comunicazione con il roamer continueranno ad inviare
tuple al vecchio dominio. Solo dopo il primo recapito sbagliato di una
63
Capitolo 3
tupla il mediator mittente viene informato della mancanza del device nel
dominio destinatario. Il tempo di dispatch delle tuple all’interno
dell’infrastruttura risulta più che raddoppiato (2 invii di tupla mediator to
mediator più 1 interrogazione a home domain device manager anziché 1
invio di tupla mediator to mediator). Questo è un problema comune a tutte
le soluzioni mobile-enabled, come mobile-IP o wireless CORBA
3.2.2 Qualità dei link wireless e carico computazionale dei mediators
I link wireless utilizzati dai devices sono spesso scarsamente affidabili, per cui la
qualità del collegamento stesso è fortemente variabile (in termini di latenza e
larghezza di banda disponibile), inoltre i mediators devono sostenere il carico
computazionale dovuto alla comunicazione tra svariati peers, ognuno dei quali
propone il proprio traffico, che può essere anche consistente (si pensi al
trasferimento di un file di svariati megabytes). Pertanto le risorse (sia di rete che
computazionali) a disposizione sono limitate; un’applicazione quindi potrebbe
non trovare risorse sufficienti per funzionare con determinati livelli di qualità del
servizio oppure fluttuazioni nelle risorse disponibili, come il passaggio di un
device in un sotterraneo, che ne riduce significativamente la larghezza di banda a
disposizione, potrebbero non garantire più i requisiti di qualità del servizio
specificati dall’applicazione.
3.2.3 Comunicazioni inter-dominio
Due peers possono attivare un interazione anche se sono hosted in due domini
distinti, caratterizzati da diversi livelli di qualità del collegamento wireless e da
diverse prestazioni della core network.
Pertanto il funzionamento di un’applicazione con un certo livello di qualità del
servizio non può essere garantito anche se nel suo host domain i requisiti di
qualità del servizio sono soddisfatti.
Il dominio del peer nel quale il livello di QoS globale è inferiore può causare un
collo di bottiglia non solo per l’applicazione stessa ma anche per le altre
64
Capitolo 3
applicazioni del dominio. Si consideri infatti il seguente esempio: il dominio A
invia tuple al dominio B ad una velocità di 50 tuple/sec (supponiamo le tuple
abbiano tutte la stessa dimensione). Il peer sul dominio B, riesce però a leggere a
causa del cattivo collegamento wireless, appena 5 tuple/sec. Se la trasmissione
durasse 10 secondi ci sarebbero ben 450 tuple sul mediator del dominio B in
attesa di dispatching. Di conseguenza il mediator spenderà molte risorse per
scrivere e mantenere tali tuple nello spazio, pur non potendone effettuare il
dispatch in tempi rapidi.
3.2.4 Cambi di contesto
Nella transizione da un dominio all’altro il device può finire ad operare in un
contesto decisamente differente dal precedente. Ad esempio da un dominio
caratterizzato da buona potenza del segnale wireless e basso carico
dell’infrastruttura ad un dominio contraddistinto da numerosi errori sul canale
radio ed un’infrastruttura ai limiti del carico sostenibile.
Le risorse a disposizione possono notevolmente variare, e quindi i livelli di qualità
del servizio forniti potrebbero non essere più garantiti.
3.2.5 Limitata potenza dei devices
Il Device può avere una potenza elaborativa decisamente ridotta, in termini di
batteria, processore, memoria e I/O, si pensi ad esempio ad un palmare o ad un
telefono cellulare. Spesso i dispositivi di controllo del risparmio energetico
disconnettono le interfacce di rete dello stesso. Queste continue disconnessioni e
riconnessioni possono dar luogo a failures nelle comunicazioni attraverso
l’infrastruttura di Esperanto.
3.2.6 Requisiti e vincoli di un sistema di gestione della QoS per Esperanto
Broker
Alla luce delle problematiche esposte in questo paragrafo, con riferimento agli
aspetti statici e dinamici di gestione della QoS delineati nei paragrafi 1.3.4 ed ed
65
1.3.5,
Capitolo 3
è ora possibile fornire un elenco dei requisiti che un sistema di
monitoraggio e controllo della qualità del servizio progettato per Esperanto
Broker deve garantire:
•
Una metodologia per consentire in maniera semplice agli sviluppatori di
specificare i propri requisiti di QoS – In tal modo i peers (sia service
requestors che providers) possono indicare i propri requisiti di qualità del
servizio alla core network. I programmatori di applicazioni Esperanto devono
poter specificare e comunicare ai meccanismi di gestione della QoS i requisiti
di qualità del servizio desiderati.
•
Traduzione dei requisiti di alto livello in requisiti di basso livello - Fornire
degli strumenti che consentano di effettuare il mapping dei requisiti specificati
dai peers in requisiti di qualità del servizio da rispettare all’interno della core
network.
•
Minimizzazione degli effetti dell’handover nell’interazione tra i peers – In tal
modo l’infrastruttura è pronta ad affrontare in maniera efficiente e predictable
i problemi di mobilità dei devices. Come già spiegato precedentemente
l’handover è un fenomeno pericoloso per il rispetto dei requisiti imposti con il
metodo di cui al punto precedente. Tuttavia, come già ricordato nel capitolo 1,
in un ambiente di nomadic computing è praticamente impossibile pretendere
che i requisiti siano deterministicamente rispettati. La core network deve
essere comunque in grado di gestire l’handover in maniera che il periodo
transiente nel quale la QoS end-to-end peggiora sia quanto più piccolo
possibile, sia per i service requestors il cui service provider si sposta, sia per i
service requestors che si spostano tra i domini. Fornire un supporto per la
gestione efficiente
e predictable dell'handover significa minimizzare le
conseguenze della migrazione delle tuple tra i domini,tenendo conto della
criticità dell'applicazione.
•
Negoziazione di un livello accettabile di QoS relativamente alle correnti
condizioni del sistema – una volta specificati i requisiti di qualità del servizio,
66
Capitolo 3
è necessario che dei componenti sulla core network effettuino una serie di
operazioni
per
verificare
che
questi
requisiti
siano
effettivamente
soddisfacibili o meno. Ciò è vincolato alla disponibilità di un’immagine
relativamente consistente dello stato delle risorse del sistema ed alla
disponibilità
di
meccanismi
opportuni
per
garantire
le
richieste
dell’applicazione. Tali meccanismi effettuano le operazioni di negoziazione e
rinegoziazione descritte al capitolo 1. Vengono innescati sia quando un peer
richiede una certa qualità del servizio nell’usufruire o nel fornire un
determinato service, sia quando il sistema di monitoraggio rileva delle
variazioni significative nello stato del sistema, e loro finalità è il
raggiungimento di SLA (Service level agreements) tra i peers interagenti.
•
Enforcement della QoS garantita ad un’interazione – E’ compito della core
network rispettare, nei limiti del possibile, i SLA raggiunti, nei quali è
specificato il contratto sulla QoS da fornire all’interazione tra i peers,
utilizzando i meccanismi messi a disposizione dai livelli sottostanti il
middleware ed effettuando le operazioni di manutenzione descritte nel
capitolo 1 ed interagendo con i meccanismi di negoziazione. Un forte vincolo
è rappresentato dall’impossibilità di controllare tutte le componenti coinvolte
nell’interazione tra i peers. Ad esempio è praticamente impossibile pretendere
di avere nella core network meccanismi per controllare il tempo di servizio di
un task su un peer , per riservare larghezza di banda, limitare la latenza o il
jitter su canali radio.
•
Monitoraggio del livello corrente di QoS tra due peers – Affinchè la core
network possa verificare la soddisfacibilità dei requisiti richiesti da
un’applicazione nella fruizione di un servizio, deve disporre, come evidenziato
al punto precedente, di un’immagine dello stato corrente delle risorse del
sistema, per poter misurare quale sia il livello attuale di qualità del servizio.
•
Supporto per l’adattatività al contesto delle applicazioni – i peers sono
inseriti in un contesto caratterizzato da una forte dinamicità, come più volte
67
Capitolo 3
ricordato nel capitolo 1. Le risorse disponibili possono cambiare
improvvisamente (a causa di un handover, del sovraccarico di un mediator
oppure di una serie di failures sul link wireless) . Le applicazioni devono
essere consce di queste variazioni e poter intraprendere azioni correttive per
poter comunque mantenere i livelli di qualità desiderati. Ad esempio in un
servizio di retrieval di immagini si può scegliere di ottenere una versione
compressa o con meno profondità di colore della stessa (Es.: 16 tonalità di
grigio invece di colore a 32 bit); in una query su database si possono
richiedere solo i primi n record anziché l’intera query. Tali strategie sono
quindi fortemente dipendenti dal tipo di servizio fornito. Affinchè
l’applicazione sia conscia delle variazioni nel suo contesto l’infrastruttura
deve fornire dei meccanismi per notificare all’applicazione stessa tali
variazioni.
3.3 Soluzione proposta per la core network
Dato che nel presente lavoro ci si concentra esclusivamente sulla fornitura di
qualità del servizio nella core network, tutto ciò che accade dal device fino al
bridge e quindi dal bridge sino al device è non misurabile e non controllabile.
Infatti con riferimento alla figura 3-1, nell’interazione tra due peers generici, che
saranno denominati A e B, con il ruolo rispettivamente di service requestor e
service provider, la latenza nell’esecuzione di un’invocazione remota, per ognuno
dei paradigmi di interazione definiti in Esperanto, è data dalle componenti
temporali riportate in tabella 3-1.
Alcune delle componenti sono strettamente connesse alle risorse disponibili sui
devices, mentre altre dipendono dalle caratteristiche e dalle condizioni del link
wireless. La core network di Esperanto non può fare in alcun modo assunzioni
affidabili su tali componenti per quanto concerne la misurazione, né può effettuare
alcuna azione di controllo, ad esempio per riservare una certa larghezza di banda
68
Capitolo 3
sul link wireless o per eseguire i servizi ad un data priorità sui devices (ammesso
che questi supportino scheduling di tipo fixed priority).
TDA1
Latenza nell’attraversamento dello stack protocollare
dal livello applicazione fino al livello rete per il
peerA (passando per i livelli E-STUB,TDL e ncsocks)
TWA1
Latenza sulla rete wireless per il trasferimento della
PDU contenente la tupla di request dal device che
ospita il peer A alla core network
TCN1
Latenza nella core network per il delivery della tupla
da A a B. Le operazioni possono avvenire nello
stesso dominio o in due domini distinti. Nel caso in
cui il push della tupla fallisca tale latenza è aggravata
dai tempi necessari per le operazioni di read (take)
dallo spazio da parte dei device e dai tempi in cui la
tupla resta nello spazio in attesa della read (take)
stessa.
TWB1
PDU contenente la tupla di request dalla core
network al device che ospita il peer B
O
TDB1
TSB
dal livello fisico al livello applicazione fino per il
peer B (passando per i livelli ncsocks,TDL ed ESKEL)
Latenza di servizio sul peer B (il tempo necessario ad
eseguire il servizio invocato)
TDB2
dal livello applicazione fino al livello rete per il peer
B (passando per i livelli E-STUB,TDL e ncsocks)
TWB2
PDU contenente la tupla di response dal device che
ospita il peer B alla core network
TCN2
da B ad A. Le operazioni possono avvenire nello
dallo spazio da parte del device e dai tempi in cui la
stessa.
TWA2
PDU contenente la tupla di response dalla core
network al device che ospita il peer A
TDA2
peer A (passando per i livelli ncsocks,TDL ed ESKEL)
R
E Q U E S T
/R
E SP O N S E
N E
-
W A Y
Paradigma
Componente Descrizione
d’interazione
Tabella 3-1(a): Latenza in interazioni request/response e one-way
69
Capitolo 3
Pertanto gli unici termini monitorabili e controllabili nella core network sono i
termini CN1 e CN2, relativi al delivery delle tuple da A verso B e viceversa.
TDB1
B (passando per i livelli E-STUB,TDL e ncsocks)
TWB1
PDU contenente la tupla di solicit dal device che
ospita il peer B alla core network
TCN1
dallo spazio da parte dei device e dai tempi in cui la
stessa.
TWA1
PDU contenente la tupla di solicit dalla core network
al device che ospita il peer A
S
O L I C I T
/R
E SP O N S E
N
O T I F Y
Paradigma
Componente Descrizione
d’interazione
TDA1
TSA
peer A (passando per i livelli ncsocks,TDL ed ESKEL)
Latenza di servizio sul peer A (il tempo necessario ad
eseguire il servizio invocato)
TDA2
A (passando per i livelli E-STUB,TDL e ncsocks)
TWA2
PDU contenente la tupla di response dal device che
ospita il peer A alla core network
TCN2
dallo spazio da parte del device e dai tempi in cui la
stessa.
TWB2
PDU contenente la tupla di response dalla core
network al device che ospita il peer B
TDB2
peer B (passando per i livelli ncsocks,TDL ed ESKEL)
Tabella 3-1(b): Latenza in interazioni solicit/response e notify
70
Capitolo 3
Nel seguito si approfondirà la discussione relativa ai tempi di delivery, e verranno
individuate ulteriori componenti nei quali tali tempi possono essere suddivisi, in
funzione del fatto che si tratti di un interazione intra-dominio (i due peers sono
nello stesso dominio) o inter-dominio (i due peers sono in domini distinti).
In realtà i paradigmi Solicit/Response e Notify sono speculari rispetto ai paradigmi
Request/Response e one-way.
Per tale ragione i tempi di latenza saranno rispettivamente mediamente uguali.
Nel seguito del capitolo si focalizzerà l’attenzione sulla qualità nel servizio nel
delivery delle tuple all’interno della core network.
Agli sviluppatori verrà fornita una API (Application Programming Interface) per
poter specificare i requisiti di qualità del servizio delle proprie applicazioni. Tali
requisiti di qualità possono essere specificati sia dalle applicazioni che richiedono
un servizio, e quindi indicano con quale qualità un peer voglia usufruire di un
servizio, che dalle applicazioni che offrono un servizio, e quindi indicano con
quale qualità un peer intenda offrire un servizio.
L’API in questione deve essere il più semplice ed intuitiva possibile, al fine di non
complicare il processo di sviluppo di applicazioni Esperanto, e soprattutto deve
tenere gli sviluppatori all’oscuro della struttura della core network, ovvero non
sarà fatto esplicitamente riferimento al delivery delle tuple o alla gestione degli
handover.
Tuttavia
gli
sviluppatori
esprimono
dei
requisiti
end-to-end,
relativi
all’interazione «completa» tra i due peers, compresa la trasmissione sul link
wireless ed il tempo di servizio.
Dovranno dunque esistere dei componenti che:
•
Effettuano il monitoring dello stato del link wireless, in termini di latenza
e throughput della trasmissione.
•
Effettuano delle reservations di risorse sul link wireless.
•
Effettuano il monitoring dei parametri caratteristici dei device, come
batteria residua, carico elaborativi sostenibile, throughput di rete, etc. etc.
71
•
Capitolo 3
Controllano, ove possibile, la trasmissione di tuple da/verso il device
(shaping del traffico) e la priorità di elaborazione dei servizi sul device
stesso.
L’analisi, la progettazione e lo sviluppo di tali componenti, per quanto affermato
precedentemente, non è tuttavia oggetto del presente lavoro, ma sarà oggetto di
futuro lavori di ricerca che, integrati con il presente, consentiranno
l’implementazione di un sistema di gestione della QoS end-to-end in Esperanto.
Nel seguito si supporrà sempre che i requisiti di QoS specificati dai peers vengano
opportunamente rielaborati dai componenti di gestione della qualità del servizio
residenti sul devices e che al mediator vengano forniti i requisiti di QoS per
l’interazione limitati esclusivamente al compito che deve svolgere il mediator
stesso, ovvero il delivery delle tuple.
3.3.1 Modello di QoS per il mediator di Esperanto
In [BARB 95] è riportata una tassonomia degli attributi di qualità del servizio da
monitorare e controllare in un sistema QoS-enabled. Tali attributi, riportati anche
nelle tabelle 1-2 ed 1-3 sono raggruppabili nelle seguenti categorie: performance,
dependability e security, che, come anticipato nel capitolo 1 non saranno prese in
considerazione nel presente lavoro, così come le caratteristiche di dependability. Il
mediator di Esperanto provvederà meccanismi per negoziare e garantire
esclusivamente caratteristiche di performance.
Per quanto concerne tali caratteristiche, gli attributi rilevanti sono la latenza,
ovvero il tempo medio speso nel mediator per eseguire le invocazioni,il jitter,
inteso nel senso classico di varianza della latenza, il throughput, inteso come
numero di invocazioni effettuate in una data finestra temporale e la criticità,
parametro che definisce l’importanza che un servizio ha per un’applicazione.
Prima di definire il modello di QoS da adottare nel mediator è utile analizzare
cosa significhino le sopraelencate caratteristiche per il mediator stesso.
La latenza in un interazione da due peers A e B è il tempo che il mediator spende
nel compiere le operazioni connesse all’invocazione di metodo remoto, secondo
72
Capitolo 3
uno dei quattro paradigmi di Esperanto. Ad esempio per un’interazione di tipo
request/response la latenza nel mediator è costituita dai tempi necessari a
compiere il delivery della tupla di request da A verso B ed il delivery della tupla
di response da B verso A.
Il throughput di una comunicazione tra due peers A e B è il numero di
invocazioni che vengono effettuate e servite in un determinato intervallo
d’osservazione. Per quanto riguarda il mediator è evidente che più rapidamente
avviene il delivery di una tupla, maggiore è il throughput della comunicazione
stessa. Latenza e throughput sono quindi strettamente correlati: minore è la
latenza maggiore è il throughput. Una comunicazione che tiene a massimizzare il
suo throughput necessariamente deve minimizzare la latenza nel mediator.
Il jitter di una comunicazione tra due peers A e B è la varianza nella latenza delle
diverse invocazioni effettuate. Nel mediator tuttavia la latenza, come si evince dai
diagrammi di destra della figura 3-2, è fortemente dipendente dalla dimensione
della tupla che deve essere scritta o prelevata dallo spazio. Affinché il mediator
possa garantire un determinato jitter nella comunicazione tra due peers dovrebbe
conoscere a priori la dimensione delle tuple associate a tale interazione. Ciò non
può prescindere da un’interazione con il tuple delivery layer del device.
Per criticità si intende l’importanza per il peer X (service requestor) del servizio
offerto dal peer Y (service provider). L’importanza di un servizio è infatti un
concetto relativo: un determinato servizio può essere critico o meno in base agli
scopi di chi lo utilizza. La criticità di un servizio per un peer viene espresso con
un valore intero il cui significato è comune a tutti i domini Esperanto. Al fine di
non introdurre ambiguità nell’interpretazione del valore di criticità in Esperanto
vengono definite tre categorie di criticità: 0=massima criticità; 1=media
criticità;2=bassa criticità. Nel seguito ci si concentrerà esclusivamente sulla
latenza del mediator (o dei mediators, se le interazioni avvengono in domini
distinti) nelle interazioni tra peers e sulla criticità delle stesse.
73
Capitolo 3
Dati due peers A e B, hosted nello stesso dominio o in due domini distinti, la
latenza all’interno della core network, è data dalle componenti riportate in tabella
3-2, per ognuno dei paradigmi di interazione definiti in Esperanto.
Latenza
Interazione tra
peer A e peer B
Request/Response
LATRR=TDELAB+TDELBA
One-way
LATOW=TDELAB
Solicit/Response
LATSR=TDELBA+TDELAB=LATRR
Notify
LATN=TDELBA
Legenda:
TDELAB – TEMPO DI DELIVERY DI UNA
TUPLA INVIATA DA A VERSO B
TDELBA – TEMPO
DI DELIVERY DI UNA
TUPLA INVIATA DA B VERSO A
Tabella 3-2: Componenti determinanti la latenza nella core network diversi
paradigmi di interazione di Esperanto
All’interno della core network tuttavia il delivery di una tupla avviene in diverse
fasi, evidenziate nelle figure 3-4a e 3-4b:
Caso A – delivery intra-dominio, device destinatario disponibile
1. La tupla viene estratta da una PDU dal livello ncsocks ed inoltro al
Dispatcher. Tale operazione viene effettuata nel Bridge, descritto al
paragrafo 3.1.3.2
2. Inoltro della tupla verso il tuple manager del dominio locale
3. Push della tupla verso il peer destinatario; la tupla viene inserita in una
PDU e spedita al destinatario attraverso il livello ncsocks.
Caso B – delivery intra-dominio, device destinatario non disponibile
I passi 1,2 sono analoghi al caso A.
3. Il Push della tupla fallisce, il device che ospita il peer destinatario è
indisponibile per problemi di rete o perché magari è in power-saving. La
tupla viene scritta nello spazio locale.
74
Capitolo 3
4. Nonappena il device torna disponibile, effettua una read (take) sullo
spazio locale e recupera la tupla precedentemente scritta.
Figura 3-4 A) Diagramma di collaborazione per la scrittura di una tupla
Caso C – delivery inter-dominio, device destinatario disponibile
Il passo 1 è analogo al caso A.
2. La tupla viene inoltrata al dispatcher del dominio remoto
3. Il dispatcher del dominio remoto inoltra la tupla al suo tuple manager
locale
75
Capitolo 3
4. Push della tupla verso il peer destinatario; la tupla viene inserita in una
PDU e spedita al destinatario attraverso il livello ncsocks.
Figura 3-4 B) Diagramma di collaborazione per la lettura di una tupla
Caso D – delivery inter-dominio, device destinatario non disponibile
I passi 1,2,3 sono analoghi al caso C.
4. Il Push della tupla fallisce, il device che ospita il peer destinatario è
indisponibile. La tupla viene scritta nello spazio locale.
5. Nonappena il device torna disponibile, effettua una read (take) sullo
spazio locale e recupera la tupla precedentemente scritta.
Si evince dunque la necessità di differenziare le componenti della latenza nel
delivery delle tuple nello stesso dominio e in domini distinti.
Nelle tabelle 3-3 e 3-4 sono riportate le componenti delle latenze interne al
mediator (ai mediators) per i diversi paradigmi di interazione definiti in
Esperanto, nel caso di interazioni intra-dominio (tabella 3-3), in cui la latenza di
delivery viene espresso in termini di due componenti (che come si vedrà in
seguito in alcuni casi possono essere assunte identiche) ed interazioni inter-
76
Capitolo 3
dominio (tabella 3-4), in cui la latenza di delivery viene espressa in termini di
quattro componenti .
Interazione tra
peer A e peer B
(stesso dominio)
Latenza
Request/Response
LATRR=TDISAB+TTMAB+TDISBA+TTMBA=TDELAB+TDELBA
One-way
LATOW= TDISAB+TTMAB=TDELAB
Solicit/Response
LATSR= TDISBA+TTMBA+TDISAB+TTMAB = TDELBA+TDELAB
Notify
LATN= TDISBA+TTMBA=TDELBA
Legenda:
TDISAB – LATENZA NEL BRIDGE E NEL
DISPATCHER NEL DELIVERY DA A A B
TDISBA – LATENZA NEL BRIDGE E NEL
DISPATCHER NEL DELIVERY DA B AD A
TTMAB – LATENZA NEL TUPLE MANAGER
PER IL DELIVERY DA A A B (INCLUDE
ANCHE I TEMPI DI PERMANENZA DELLA
TUPLA NELLO SPAZIO E DI READ)
TTMBA – LATENZA NEL TUPLE MANAGER
PER IL DELIVERY DA B AD A (INCLUDE
Tabella 3-3: Componenti della la latenza nelle interazioni intra-dominio
Riepilogando, la latenza di un’interazione intra-dominio è data al più da due
componenti, relativi all’intero percorso di delivery della tupla, dalla ricezione sul
bridge fino al push al destinatario o al prelievo della stessa da parte di quest
ultimo con un operazione di read; la latenza di un’interazione inter-dominio è data
al più da quattro componenti, relativi al dispatching della tupla da un dominio
all’altro ed alle operazioni sul tuple manager nel dominio del destinatario della
tupla stessa.
In Esperanto sarà adottato un modello basato su tre classi di servizio a prestazioni
garantite per quanto concerne la latenza nel delivery delle tuple. Le classi di
servizio sono: GOLD,SILVER e BRONZE.
Ogni classe di servizio è caratterizzata da:
• Priorità di servizio
• Massimo numero di richieste contemporaneamente soddisfacibili
77
Capitolo 3
• Massimo numero di richieste «extra» soddisfacibili per sopperire a burst
nelle interazioni tra peers
Interazione tra
peer A (dominio 1) e
peer B (dominio 2)
Latenza
Request/Response
LATRR=TDIS1AB+ TDIS2AB +TTM2AB +TDIS2BA+TDIS1BA+TTM1BA
=TDEL1AB+ TDEL2AB + TDEL2BA+ TDEL1BA
One-way
LATOW= TDIS1AB+ TDIS2AB +TTM2AB =TDEL1AB+TDEL2AB
Solicit/Response
LATSR= TDIS2BA+ TDIS1BA +TTM1BA +TDIS1AB+TDIS2AB+TTM2AB
=TDEL2BA+ TDEL1BA + TDEL1AB+ TDEL2AB =LATRR
Notify
LATN= TDIS2BA+TDIS1BA+TTM1BA = TDEL2BA+ TDEL1BA
Legenda:
TDIS1AB – LATENZA NEL BRIDGE E NEL
DISPATCHER DEL DOMINIO 1 (DELIVERY
DA A A B)
TDIS2AB – LATENZA NEL DISPATCHER
DEL DOMINIO 2 (DELIVERY DA A A B)
TDIS2BA – LATENZA NEL BRIDGE E NEL
DISPATCHER DEL DOMINIO 2 (DELIVERY
DA B AD A)
TDIS1A – LATENZA
TTM2AB – LATENZA NEL TUPLE MANAGER
DEL DOMINIO 2 PER IL DELIVERY DA A A B
(INCLUDE ANCHE I TEMPI DI PERMANENZA
DELLA TUPLA NELLO SPAZIO E DI READ)
TTMBA – LATENZA NEL TUPLE MANAGER
PER IL DELIVERY DA B AD A (INCLUDE
NEL DISPATCHER
DEL DOMINIO 1 (DELIVERY DA B AD A)
TDEL1AB =TDIS1AB
TEMPO DI DELIVERY DA
NEL DOMINIO 1
TDEL2BA =TDIS2BA
A
A
B
SPESO
TDEL2AB=TDIS2AB +TTM2AB
TEMPO DI DELIVERY DA
NEL DOMINIO 2
A
A
TEMPO DI DELIVERY DA B AD A SPESO NEL
DOMINIO 2
TDEL1BA =TDIS1BA +TTM1BA
B
SPESO
TEMPO DI DELIVERY DA B AD A SPESO NEL
DOMINIO 1
Tabella 3-4: Componenti della la latenza nelle interazioni inter-dominio
Il dimensionamento delle classi di servizio può variare da dominio a dominio e
viene effettuato all’atto del deploying di un mediator.
Ad ogni classe di servizio sono associati dei valori nominali e dei valori misurati
di latenza. I valori nominali sono determinati sperimentalmente e dipendono da:
•
La configurazione del mediator, in funzione delle proprietà assegnate alle
diverse classi di servizio
78
Capitolo 3
•
L’hardware ed il sistema operativo sui quali gira il mediator.
•
Le condizioni di carico «ideale» nelle quali si intende far lavorare il
mediator.
I valori misurati sono rilevati dinamicamente da appositi componenti del mediator
e ne rilevano lo stato delle risorse disponibili. Per ogni classe di servizio vengono
effettuate le seguenti misurazioni:
•
Numero medio di operazioni di delivery in corso
•
Latenza media per le operazioni di delivery intra-dominio, dispatching
inter-dominio e delivery di tuple provenienti da altri domini.
•
Varianza della latenza
Tali misurazioni saranno medie pesate, calcolate attribuendo un peso α al nuovo
campione ed un peso 1−α alla vecchia media.
In tal modo agli sviluppatori viene offerta una modalità estremamente semplice
per garantire QoS alle interazioni tra i diversi peer. Compatibilmente con le
proprie richieste il mediator assegna una classe di servizio all’interazione
all’interno del proprio dominio.
In ogni dominio, per ogni tripla (X,Y,F) di peer interagenti tramite la funzionalità
F (una delle funzionalità che il servizio offerto da Y mette a disposizione) verrà
assegnata
una
particolare
classe
di
servizio
scelta
nell’insieme
(GOLD,SILVER,BRONZE). Ad ogni classe di servizio sarà associato un valore
medio ed una varianza della latenza per ognuna delle modalità di interazione
definite in Esperanto;se ad una tripla (X,Y,F) di peer interagenti non è assegnata
alcuna classe di servizio, l’interazione nel dominio sarà di tipo best-effort. Il valor
medio della latenza per ognuna delle classi di servizio definite potrebbe risultare
diverso da dominio a dominio; si pensi ad un dominio il cui mediator è deployed
su nodi ad alta performance, che utilizzano sistemi operativi real-time e lo si
confronti con un dominio il cui mediator è deployed su nodi a bassa performance,
che utilizzano sistemi operativi COTS (Es.: Windows 2000): a parità di
79
Capitolo 3
configurazioni dei mediators il primo avrà tempi di latenza medi tendenzialmente
minori per ciascuna delle tre classi di servizio definite.
Se i due peer si trovano in domini diversi le classi di servizio assegnate per
l’interazione potrebbero anche essere diverse. Ad esempio affinchè i requisiti del
peer X (dominio D1) nei confronti del peer Y (dominio D2) possano essere
soddisfati alla tripla (X,Y,F) nel dominio D1, caratterizzato da alta latenza, sarà
assegnata la classe GOLD, mentre nel dominio D2, caratterizzato da bassa
latenza, sarà assegnata la classe BRONZE. Si noti infatti le operazioni di scrittura
di X ed Y coinvolgono sia il dominio D1 che il dominio D2: una tupla da X per Y
viene inoltrata dal mediator di D1 al mediator di D2 ed ivi scritta nello spazio;
una tupla da Y per X viene inoltrata dal mediator di D2 al mediator di D1 e ivi
scritta nello spazio.
Il modello di QoS in ogni dominio prevede anche la presenza di diverse policies,
che possono essere scelte all’atto della configurazione del mediator stesso, per la
gestione dei seguenti aspetti:
•
Preemption delle risorse assegnate a processi con bassa criticità – si
supponga che ad un interazione a criticità 0 deve essere necessariamente
assegnata la classe di servizio GOLD affinché possa soddisfare i propri
requisiti di QoS, ma tale classe non può soddisfare la richiesta (tutti gli slot
impegnati). Se nel dominio la policy PREEMPTIVE avrà valore TRUE
verrà selezionata un interazione a criticità 2 (o 1 se non ve sono), che verrà
«espulsa» dalla classe GOLD in favore della nuova interazione. Se invece
si la policy PREEMPTIVE avrà valore FALSE la nuova interazione verrà
rifiutata dal controllo d’ammissione.
•
Permanenza delle tuple nello spazio – Se la policy DELIVERY avrà valore
ALWAYS allora la tupla non verrà eliminata dallo spazio alla scadenza
del suo time-to-live. Se il valore specificato è IN_TTL allora la tupla verrà
rimossa dallo spazio alla scadenza del suo time-to-live. Se il valore invece
80
Capitolo 3
è IN_DEADLINE la tupla verrà rimossa dallo spazio alla scadenza della
deadline imposta con le specifiche di QoS.
Policy
Valore
YES
PREEMPTIVE
NO
ALWAYS
DELIVERY
IN_TTL
IN_DEADLINE
MAXIMIZE
SET_SERVICE_CLASS
MINIMIZE
Significato
Interazioni a criticità x possono essere
«retrocesse» ad altre classi di servizio
se Interazioni a criticità y>x vogliono
utilizzare tale classe e non ci sono
risorse disponibili
Non sono possibili «retrocessioni» di
classe per le interazioni
Le tuple vengono sempre, prima o poi,
consegnate al destinatario
Le tuple vengono consegnate al
destinatario entro il loro time-to-live
Le tuple vengono consegnate al
destinatario entro la loro
deadline,imposta dai requisiti di QoS
Ad un interazione si assegna sempre la
classe di servizio che massimizza le
prestazioni, se ci sono risorse
disponibili
Ad una interazione si assegna la prima
classe di servizio che soddisfa i
requisiti di QoS imposti.
Tabella 3-5: Policies per i domini Esperanto
•
Assegnazione delle classi di servizio – viene definita la policy
SET_SERVICE_CLASS, che può avere due valori: MAXIMIZE o
MINIMIZE. Nel primo caso verrà assegnata sempre la classe di servizio
che massimizza le prestazioni dell’interazione, e quindi la classe GOLD,
mentre nel secondo caso verrà assegnata la prima classe di servizio che
soddisfa i requisiti imposti.
Le policies per i domini Esperanto sono riepilogate in tabella 3-5.
La scelta di una determinata combinazione dei valori delle tre policies elencate in
tabella 3-5 rappresenta un trade-off tra diverse esigenze. Ad esempio scegliendo
PREEMPTIVE=NO, DELIVERY=IN_DEADLINE e SET_SERVICE_CLASS=
MAXIMIZE, si avrà un notevole incremento dei rifiuti in fase di controllo
d’ammissione, perché le classe di servizio GOLD viene rapidamente saturata, ma
81
Capitolo 3
le applicazioni che vengono ammesse avranno ottime prestazioni, sicchè si può
ritenere che le deadlines vengano soddisfatte nella stragrande maggioranza dei
casi e quindi scegliere IN_DEADLINE come policy per la permanenza delle
tuple, in maniera tale da non occupare spazio di memoria permanente.
Accanto ad ogni quadrupla (X,Y,F,CS), dove CS è la classe di servizio assegnata,
nel modello di QoS di Esperanto verrà anche specificata la criticità CR,
La criticità viene utilizzata per effettuare il controllo d’ammissione di una
particolare richiesta di QoS e per discriminare il push del tuple verso i devices,
come verrà mostrato nel par. 3.3.5. In funzione delle policies impostate è possibile
retrocedere di classe di servizio un’interazione per favorire una nuova interazione
a criticità maggiore. Per quanto concerne le interazioni «retrocesse» saranno
attivati dei meccanismi per la rinegoziazione della QoS che verranno esposti nel
seguito di questo capitolo.
Riepilogando il modello di qualità del servizio tra due peer Esperanto in un
mediator è descritto dalle seguenti informazioni (X,Y,F,CS,CR), ovvero:
•
Il peer X che svolge il ruolo di service requestor.
•
Il peer Y che svolge il ruolo di service provider.
•
La particolare funzionalità F del servizio offerto Y.
•
La classe di servizio CS assegnata nel dominio all’interazione tra X ed Y.
•
La criticità CR del servizio Y per X.
La 5-pla (X,Y,F,CS,CR) specifica:
1. in che modo X debba usufruire della funzionalità F messa a disposizione
da Y, attraverso l’assegnazione della classe di servizio CS
2. Quale sia la criticità dell’interazione tra X ed Y sulla funzionalità F
rispetto ad altre interazioni assegnate alla stessa classe CS, attraverso il
livello di criticità CR
3. Quali siano i valori di latenza media nelle invocazioni end-to-end,
mediante le informazioni sulle latenze delle operazioni associate alla
classe di servizio CS.
82
Capitolo 3
Di seguito si riportano alcune osservazioni relative al modello stesso:
•
La media e la varianza associati alle classi di servizio GOLD,SILVER e
BRONZE possono variare a causa di variazioni del carico elaborativo, o a
seguito di failures nel mediator stesso o tra i mediators. Pertanto
un’interazione, pur restando nella classe di servizio che inizialmente
garantiva i requisiti imposti per la QoS, potrebbe non veder più soddisfatti
tali requisiti. Sarà in questo caso l’insieme dei meccanismi deputati alla
negoziazione della QoS ed al mapping della stessa sui componenti di
Esperanto ad intraprendere azioni correttive, che possono andare dalla
semplice rinegoziazione delle classi di servizio in base alla criticità delle
interazioni, fino alla dichiarazione della failure dell’interazione, nel caso
in cui i requisiti in nessun modo possano venir soddisfatti.
•
Al fine di poter valutare se i requisiti di QoS in un’interazione tra domini
distinti possano essere soddisfatti è necessario, come riportato in tabella 32, considerare alcuni tempi di latenza relativi al primo dominio ed altri
tempi relativi al secondo dominio. Ciò porta alla possibilità di scegliere
due classi di servizio distinte per la stessa interazione nei due domini.
•
Le tre classi di servizio, GOLD, SILVER e BRONZE rappresentano
modalità diverse per le operazioni sulle tuple nel mediator. A due peers
interagenti in classe di servizio GOLD saranno garantite operazioni sullo
spazio più performanti rispetto alle operazioni effettuate da due peers
interagenti in categoria SILVER,BRONZE. La predictability statistica
delle interazioni è comunque assicurata in ognuna delle tre classi definite,
mentre due peer che non hanno specificato nessun requisito di qualità del
servizio, non avranno nessuna garanzia circa le latenze nel mediator
connesse alle proprie interazioni.
•
Il modello di QoS così delineato, definendo le classi di servizio in base a
parametri statistici (media e varianza) della latenza, si presta più ad
applicazioni i cui requisiti di qualità del servizio siano di tipo statistico
83
Capitolo 3
piuttosto che deterministico. In altri termini il modello di QoS è studiato
per applicazioni di tipo soft real-time piuttosto che per applicazioni di tipo
hard real-time. Del resto, come affermato in [CROSS 02] supporre di
poter ottenere garanzie deterministiche sulla qualità del servizio in uno
scenario articolato come quello in cui operano i peers Esperanto è una
pretesa troppo forte, si pensi alle problematiche esposte al paragrafo 3.2.
3.3.2 Metodi per la specifica dei requisiti di QoS
Quando un peer richiede un servizio, utilizza le funzioni di service discovery di
Esperanto (mediante l’Esperanto Explorer descritto al capitolo1) e recupera le
informazioni relative al servizio ed al peer che lo offre, come descritto in [MIGL
03]. Il service provider utilizza un opportuno service description language (SDL)
per pubblicare informazioni quali: il nome ed il tipo del servizio offerto, le
funzioni messe a disposizione dal servizio con il relativo paradigma
(Request/Response, oneWay,…) ed il tempo previsto di servizio, i parametri di
ingresso, i parametri d’uscita ed il valore restituito dalle funzioni. Un modello di
SDL è descritto da Lee in [LEE 03]. Accanto a tali informazioni in Esperanto, per
ogni funzione messa a disposizione, sarà possibile specificare anche la QoS
ammessa in termini di latenza nell’esecuzione della funzione. Nel seguito non ci
si occuperà comunque dei problemi relativi alla descrizione ed al discovery dei
servizi, ma si supporrà che l’Esperanto Explorer possa fornire informazioni anche
sulla QoS ammessa da una particolare funzione.
Il service requestor indicherà con quale qualità del servizio intende eseguire una
particolare funzione messa a disposizione in un servizio offerto da un determinato
peer ed il livello di criticità dell’interazione.
Non è detto infatti che il requestor sia interessato ad avere QoS per ogni funzione
invocabile (ad esempio in un servizio che offre quotazioni di borsa sarà
interessato ad ottenere con notevole QoS la quotazione del FIB, mentre non avrà
alcuna necessità di QoS nell’ottenere le quotazioni dei fondi monetari); inoltre
non è detto che ogni funzione abbia la stessa criticità per il requestor. Un client
84
Capitolo 3
deve quindi avere la possibilità di effettuare richieste di qualità del servizio
relativamente a tutte o parte delle funzioni messe a disposizione da un dato peer.
La specifica dei requisiti di QoS prescinde totalmente dalla location dei peer
interagenti. Al programmatore non interessa sapere se il peer che offre il servizio
(o quello che lo richiede) sia locale o remoto, specifica semplicemente i requisiti
di QoS e li comunica al QoS management Layer del device, che, con la
collaborazione della core network, si occuperà (in modi che non sono oggetto di
questo lavoro) di valutare la soddisfacibilità dei risultati in termini di latenza dei
collegamenti wireless, availability dei devices, e tempi di servizio previsti sul
service provider (o sul service requestor se la funzione è di tipo notify o
solicit/response). Alla core network, verranno quindi proposti dei requisiti da
soddisfare, che sono esclusivamente relativi alle operazioni da compiere al suo
interno. La procedura di negoziazione sarà descritta nel paragrafo 3.3.3.
Di seguito viene riportata una API estremamente semplice per la specifica dei
requisiti di QoS (che non viene però utilizzata direttamente dagli sviluppatori, che
si interfacciano con il QoS management layer del dispositivo) , costituita dalle
seguenti primitive:
•
make_qos_request(srcPeerID,dstPeerID,QoSreq)
–
utilizzata
dal
peer
srcPeerID per stabilire se l’interazione con dstPeerID, possa avvenire o meno
con i requisiti specificati in QoSreq. I meccanismi interni al mediator (o ai
mediators) valutano la fattibilità dell’operazione, in base ai valori osservati di
QoS. Viene restituito l’ID relativo ad un agreement stabilito all’interno della
core network sul livello di QoS da fornire all’interazione tra srcPeerID o
dstPeerID oppure un valore relativo all’impossibilità di fornire la QoS
desiderata all’interazione. Il parametro QoSreq è strutturato ed organizzato nei
seguenti campi:
o FunctionName – stringa rappresentante il nome della funzione per la
quale si richiede che le invocazioni avvengano con una certa QoS
o MaxLatency – massima latenza ammessa per l’invocazione; valore
intero espresso in millisecondi.
85
Capitolo 3
o SuccessRatio – minima percentuale di successi sulle deadlines imposte
da MaxLatency ammessa; valore in virgola mobile compreso tra 0 ed
1.
o Criticality – valore intero rappresentane la criticità della funzione
functionName
per
srcPeerID
nell’interazione
con
dstPeerID;
specificare un valore maggiore di 2 per la criticità equivale ad
assegnare all’interazione la fascia di bassa criticità e quindi è
equivalente a specificare il valore 2. Nella fascia di bassa criticità
vengono inserite anche le interazioni di tipo best-effort, per le quali
non viene fatta alcuna richiesta di QoS.
•
Get_agreement_details(agreementID,,functionName) – restituisce i dettagli di
un’agreement
sotto
forma
di
quadrupla
(serviceClass,
maxLatency,
successRatio,criticality). I parametri restituiti sono relativi al dominio in cui
viene effettuata l’invocazione.
•
Release_agreement(agreementID) – rimuove un’agreement dal mediator (dai
mediators). Questa primitiva viene tipicamente invocata al termine
dell’interazione tra i due peer o quando bisogna formulare un nuovo
agreement tra i peer stessi o ancora quando, pur continuando l’interazione non
è più necessaria che questa continui con requisiti di QoS.
3.3.3 Meccanismi per la negoziazione della QoS (raggiungimento di un service
level agreement)
Quando un peer desidera utilizzare un servizio con un determinato livello di
qualità del servizio,il QoS management layer del device comunica alla core
network i requisiti da soddisfare utilizzando le API descritte al paragrafo 3.3.2.
Sarà poi la core network stessa a determinare se tali requisiti possano essere
soddisfatti o meno, ed assegnare all’interazione tra i peers una classe di servizio
nei domini nei quali avviene l’interazione.
86
Capitolo 3
La negoziazione di un SLA (service level agreement) tra due peers può essere
scomposta nelle seguenti attività:
1. Acquisizione delle specifiche di QoS del service provider (se effettuate)
2. Acquisizione delle specifiche di QoS del service requestor
3. Verifica della compatibilità della specifiche del service provider e del
service requestor
4. Controllo d’ammissione nella core network
5. Assegnazione della (o delle) classi di servizio
I primi tre passi devono necessariamente prendere in considerazione la QoS endto-end tra i due peers e dunque non possono prescindere dal considerare il
collegamento wireless , l’availability e le risorse computazionali dei devices. Per
le ragioni più volte menzionate in questo paragrafo, questi aspetti non verranno
trattati in questa sede.
Si supporrà che il QoS management layer del device del requestor acquisisca le
sue richieste di QoS e che, interrogando l’Esperanto Explorer, possa reperire i
requisiti di QoS (se presenti) imposti dal provider e quindi calcolare i requisiti
«congiunti» di QoS utilizzando la seguente procedura esemplificata in figura 3-5.
CASO 1. Il service provider ha specificato il livello di QoS desiderato, ma
non il service requestor.
CASO 2. Il service requestor ha inviato le sue specifiche di QoS, ma la
descrizione del servizio offerto non ha nessuna specifica in merito alla
QoS.
CASO 3. Sia il service requestor che il service provider hanno specificato
dei requisiti di QoS.
Nel caso 1 si verificherà se è possibile soddisfare l’interazione con i requisiti di
QoS richiesti dal service provider. Nel caso 2 si verificherà se è possibile
soddisfare l’interazione con i requisiti di QoS richiesti dal service requestor. Nel
caso 3, di natura più generale, si verificherà se è possibile verificare
contemporaneamente i requisiti di ambedue i peers.
87
Capitolo 3
La procedura generale per determinare i requisiti congiunti dell’interazione, è
molto semplice: per ogni funzione messa a disposizione dal servizio si considera il
minor tra i due valori di latenza ammissibile specificati (uno dal provider, uno dal
requestor). I valori così ottenuti saranno utilizzati per determinare se l’interazione
può avvenire. Se alcuni valori non sono specificati (ad esempio il requestor non
specifica nessun requisiti di QoS per la funzione foo del servizio dummy) verranno
considerati pari ad infinito.
Figura 3-5 – Esempio di determinazione dei requisiti congiunti di service
requestor e service provider
Per quanto concerne la percentuale di successo, se specificata verrà immessa nei
requisiti congiunti; in caso contrario verrà utilizzata una percentuale di default.
Analogo discorso vale per la criticità della funzione.
Determinati tali requisiti congiunti si procederà alla determinazione delle latenze
connesse al collegamento wireless ed ai tempi di servizio delle funzioni,
dopodichè i requisiti da soddisfare nella core network verranno sottoposti al
mediator del dominio del service requestor; si eseguiranno quindi i passi 4e 5
della procedura di negoziazione precedentemente delineata.
CONTROLLO D’AMMISSIONE NELLA CORE NETWORK
88
Capitolo 3
In questa fase si verifica che il dominio (o i domini) abbiano risorse sufficienti per
poter gestire la comunicazione secondo i requisiti di QoS specificati. La verifica
avviene in un due passi: nel primo si controlla se una data classe di servizio sia in
grado o meno di servire una nuova interazione senza pregiudicare la sua
performance; nel secondo si verifica se una data classe di servizio sia in grado o
meno di servire una nuova interazione con determinati requisiti di qualità del
servizio espressi in termini di massima latenza ammessa e percentuale di successo
desiderata per un certo numero di funzioni specificate attraverso la
make_qos_request. A tal fine si introduce il modello delle probability assertions,
utilizzato in [SCHMIDT 02b] nella specifica delle QoS proposal nel Quality
Connector Pattern, per valutare i requisiti di latenza in funzione della percentuale
di successo richiesta.
Si procederà quindi con l’analisi del caso in cui i due peers si trovino nello stesso
dominio, per poi passare ad analizzare il caso in cui i peers si trovino in domini
distinti.
⇒ Probability Assertions
Il modello di qualità del servizio adottato in Esperanto è di tipo soft real-time,
come evidenziato al par 3.3.1; pertanto non è intenzione della core network
garantire deterministicamente i requisiti di qualità del servizio imposti. Inoltre,
come riportato in [CROSS 02], poiché l’infrastruttura non è mai infinitamente
affidabile, la distribuzione della densità dei tempi di risposta mostrerà una
lunga coda. Quindi nel caso di interpretazione worst case dei limiti di latenza,
se il termine worst viene interpretato letteralmente, raramente le interazioni
potranno essere ammesse a causa della lunga cosa della distribuzione riportata
in figura 3-6, da cui si deduce che la massima latenza, anche se si verifica con
una probabilità infinitesima, è sempre estremamente elevata.
89
Capitolo 3
Figura 3-6 – Distribuzione dei tempi di risposta
Anziché dei limiti di tipo worst-case allora si formuleranno condizioni sulle
latenze del tipo “<percentuale> delle latenze minori o uguali a <limitetemporale>”, ad esempio “il 95% per cento dei tempi di latenza deve essere
minore o uguale a 800 ms”. Questo modo di specificare i requisiti è un
semplice caso particolare di una potente tecnica chiamata probability
assertions, in cui la CDF (cumulative density function) di una distribuzione di
valori viene confrontata con due funzioni, una che la limita inferiormente ed
una che la limita superiormente. In questo caso si utilizza solo il limite
superiore, con una funzione a gradino.
Tuttavia costruire la distribuzione dei tempi di risposta a run-time, ovvero
misurando le effettive latenze nelle operazioni connesse al delivery delle tuple
in Esperanto comporterebbe la raccolta e memorizzazione di un’ingente
quantità di valori, che dovrebbe essere raccolta in una lista, da scorrere ogni
qual volta si vuole valutare la CDF dei tempi di risposta.
E’ opportuno quindi utilizzare una distribuzione di probabilità continua, da
costruire in base a parametri statistici, come media e varianza, calcolati a
partire dall’osservazione delle latenze nel delivery delle tuple.
90
Capitolo 3
In [ALPERT 03] viene proposta la distribuzione log-normale come metrica
per la misura dei tempi di risposta agli impulsi. Tale distribuzione verrà
adottata anche in Esperanto per la valutazione della soddisfacibilità dei
requisiti imposti dalle applicazioni.
La distribuzione log-normale null’altro che la distribuzione di probabilità
assunta da una variabile aleatoria il cui logaritmo ha una distribuzione
gaussiana. Le formule della PDF, della CDF e dei momenti del primo ordine
di questa distribuzione sono riportate in figura 3-7, dove erf è la funzione di
errore, ed è una funzione integrale. L’argomento della funzione è il limite
d’integrazione; M ed S sono i parametri che determinano la forma della PDF e
della CDF,sono detti rispettivamente scale e shape e sono legati alla media ed
alla varianza dalle relazioni mostrate in figura.
µ = e M +S
σ = eS
2
+2 M
2
2
(e S − 1)
2
Figura 3-7 – PDF,CDF,media e varianza della distribuzione log-normale.
Assegnate media e varianza del delivery delle tuple per una data classe di
servizio, sarà possibile calcolare i valori di M e di S e quindi la CDF della
distribuzione log-normale.
Se un requisito di QoS specificato per una
determinata funzione impone di effettuare un’operazione nella core network
entro un certo tempo t con probabilità p, si calcolerà la CDF nel punto t.
Quindi:
•
Se D(t)<p il requisito non può essere garantito, in quanto la
probabilità di riuscire a portare a termine l’operazione entro il
tempo t è minore di quella richiesta (p)
91
•
Capitolo 3
Se D(t)>=p il requisito può essere invece soddisfatto.
Questi principi verranno ora applicati alla negoziazione della qualità del servizio
tra due peers.
Secondo il valore della policy SET_SERVICE_CLASS definita al par. 3.3.1 le
classi di servizio verranno considerate nel seguente ordine:
•
MAXIMIZE: GOLD,SILVER,BRONZE
•
MINIMIZE: BRONZE,SILVER,GOLD
Nel seguito, per semplificare la trattazione, si supporrà di utilizzare la policy
SET_SERVICE_CLASS MINIMIZE. Il discorso è speculare nel caso si usi l’altro
valore per la policy (MAXIMIZE).
Dati due peers X ed Y, che svolgono
rispettivamente il ruolo di service requestor e service provider, con il termine
«interazione» si farà riferimento all’invocazione da parte di X di una determinata
funzione f messa a disposizione da Y.
⇒ Interazione nello stesso dominio
In prima istanza viene interrogato il servizio di monitoraggio per ottenere una
snapshot dello stato corrente del dominio. Vengono restituiti la media,la
varianza e il numero medio di richieste contemporaneamente servite per ogni
classe di servizio.
Si passa quindi ad analizzare la classe BRONZE,verificando il numero di
richieste medio. Se è pari o superiore al numero massimo di richieste
soddisfacibili contemporaneamente, la classe viene ritenuta satura.
In base al valore della policy PREEMPTIVE sono possibili due scelte:
1. PREEMPTIVE = NO. Non si possono «retrocedere» interazioni. Si
passa al controllo d’ammissione in classe SILVER e la procedura viene
ripetuta identicamente.
2. PREEMPTIVE = YES. Si passa comunque alla verifica del
soddisfacimento dei requisiti di qualità del servizio per tutte le funzioni
del service provider indicate nella specifica. Successivamente verrà
scelta un interazione da «retrocedere».
92
Capitolo 3
Una volta individuata una classe che, con o senza preemption, abbia slot
disponibili per gestire ulteriori richieste senza aumentare le dimensioni della
coda, si prendono in considerazione le medie e delle varianze osservate
all’interno del dominio per tale classe e si verifica se i requisiti di QoS siano
soddisfacibili nella core network.
Per quanto visto precedentemente un requisito relativo ad una specifica
funzione può essere garantito se DBR(MAXLAT)>=p, dove DBR è la CDF lognormale per la classe BRONZE, calcolata a partire dalla media e dalla
varianza monitorati, MAXLAT è la massima latenza ammessa dai requisiti di
QoS per il delyvery intra-dominio delle tuple con probabilità di successo p.
Se tale condizione è verificata la classe BRONZE verrà assegnata
all’interazione tra i due peers, altrimenti si ripeterà la stessa procedura di
controllo d’ammissione per le classi SILVER e GOLD. Se nemmeno per la
classe GOLD i requisiti risultano soddisfacibili allora al peer che richiede il
servizio verrà notificata l’impossibilità di avviare l’interazione con la QoS
richiesta.
⇒ Interazione in domini distinti
In questo caso la procedura diventa più complessa. Il controllo d’ammissione
è infatti distribuito su due domini.
Si rammenti infatti che, come riportato in tabella 3-4, la latenza totale di
delivery nel mediator è data dalle seguenti componenti:
•
Dominio del requestor: latenza di dispatch inter-dominio, latenza di
delivery delle tuple provenienti da domini esterni.
•
Dominio del provider: latenza di dispatch inter-dominio, latenza di
delivery delle tuple provenienti da domini esterni.
Il procedimento seguito è il seguente (A e B sono i due peers interagenti,
dislocati rispettivamente nei domini D1 e D2, i valori di latenza cui si fa
riferimento sono relativi alle singole classi di servizio):
93
•
Capitolo 3
Secondo le policies SET_SERVICE_CLASS e PREEMPTIVE del
dominio D1 si effettua il controllo d’ammissione. Nonappena viene
trovata una classe di servizio «libera» (che cioè ha risorse sufficienti
per poter sostenere una nuova interazione), si utilizza la funzione
inversa della CDF log-normale per determinare, relativamente alle
probabilità di successo imposte, quali siano i tempi di latenza che la
classe può garantire, limitatamente alle operazioni da compiere nel
dominio D1. Tali valori vengono quindi sottratti ai requisiti di QoS da
soddisfare e la valutazione passa a D2. Ovviamente potrebbe accadere
che nessuna classe di D1 riesca a soddisfare i requisiti dell’interazione.
Si pensi ad esempio ad un’interazione per cui venga specificata una
latenza massima di 700 ms con una probabilità di successo del 90%.
Se, per ogni classe nel dominio, il 90% di probabilità di successo si
ottiene in corrispondenza di un valore di latenza maggiore di 700 ms, i
requisiti non potranno mai essere soddisfatti e la QoS richiesta non
viene accordata.
•
Secondo le policies SET_SERVICE_CLASS e PREEMPTIVE del
dominio D2 si effettua il controllo d’ammissione. Nonappena viene
trovata una classe di servizio «libera», si calcola la CDF della
distribuzione log-normale per la classe di servizio individuata per
verificare se, limitatamente alle operazioni da compiere nel dominio
D2, i requisiti comunicati da D1 possano essere soddisfatti con la
percentuale di successo specificata, analogamente a quanto viene fatto
nel caso di interazione intra-dominio.
•
In caso affermativo il gestore dei SLA del dominio D2, che da questo
punto in poi sarà chiamato SLA Manager, invia un messaggio SLA_OK
allo SLA Manager di D1 informandolo del successo dell’operazione e
si passa alla fase successiva.
94
•
Capitolo 3
In caso negativo lo SLA Manager del dominio D2 dapprima cerca di
individuare (se può) altre classi di servizio che soddisfano i requisiti,
ripetendo, nel solo dominio D2, l’intera procedura di controllo
d’ammissione. Nel caso l’operazione fallisca per tutte le classi invia al
suo corrispettivo nel dominio D1 un messaggio SLA_NO.
•
In tal caso lo SLA Manager di D1, cerca una nuova classe di servizio
(sempre ammesso che non siano già state considerate tutte), e
ricomincia l’intera procedura di controllo d’ammissione, con la
selezione di una nuova classe di servizio in D1 e l’inoltro della
richiesta di controllo d’ammissione a D2. Se il controllo d’ammissione
in D1 fallisce per ogni classe allora al requestor viene notificata
l’impossibilità di avviare l’interazione con la QoS richiesta.
ASSEGNAZIONE DELLA (O DELLE) CLASSI DI SERVIZIO
Se è stata individuata un SLA tra i due peers, lo SLA manager dovrà occuparsi di
assegnare la classe (le classi) di servizio assegnata all’interazione tra i due peers.
Lo SLA manager disporrà di un repository nel quale mantenere le informazioni
relative alle SLA agreed.
Nel caso di interazione intra-dominio, lo SLA manager scriverà nel suo repository
locale la quadrupla (P1,P2,f,CS,CR), insieme alle informazioni relative ai requisiti
da rispettare nell’interazione tra i due peers, da utilizzare per un eventuale
rinegoziazione dell’agreement raggiunto.
95
Capitolo 3
Figura 3-8 – Diagramma delle attività per la negoziazione del SLA effettuate
dallo SLA Manager
Nel caso di interazione inter-dominio, lo SLA manager del mediator del dominio
D1 scriverà nel suo repository la quadrupla (P1,P2,f,CSA,CR), insieme alle
informazioni relative ai requisiti dell’interazione tra i due peers da soddisfare nel
dominio D1, da utilizzare per un eventuale rinegoziazione dell’agreement
96
Capitolo 3
raggiunto, e contatterà lo SLA manager del mediator del dominio D2, affinchè
questi scriva nel suo repository la quadrupla (P1,P2,f,CSB,CR), insieme ai
requisiti dell’interazione tra i due peers da soddisfare nel dominio D2.
Al peer che ha invocato l’API make_QoS_request viene quindi restituito l’ID del
SLA raggiunto.
Il diagramma delle attività relativo al raggiungimento di un SLA è riportato in
figura 3-8
3.3.4 Meccanismi per garantire la QoS richiesta
Una volta che lo SLA manager ha assegnato la classe (o le classi) di servizio per
l’interazione tra due peers relativa all’invocazione di una determinata funzione, è
indispensabile che un’ulteriore entità all’interno del mediator si occupino di
garantire il soddisfacimento dei requisiti di QoS che sono stati concessi. Tale
entità deve quindi garantire che le interazioni tra i peers, avvengano rispettando la
classe di servizio assegnata dallo SLA manager e la criticità specificata dal
requestor dei servizi.
Tali requisiti verranno garantiti in maniera statistica, e sarà data maggiore priorità
alle interazioni ad alta criticità.
E’ stato ormai acclarato che le interazioni tra peers passano attraverso le seguenti
attività nel mediator:
1. Attività di scrittura delle tuple
2. Attività di lettura (read o take) delle tuple
3. Dispatch inter-dominio delle tuple
Per ognuna delle sopraelencate attività verranno ora introdotti i meccanismi con i
quali si provvederà a garantire i requisiti di QoS specificati nel SLA
precedentemente raggiunto.
OPERAZIONI DI SCRITTURA DELLE TUPLE
La scrittura di una tupla (nel mediator locale) può avvenire in due modi: se il peer
destinatario è disponibile, la tupla viene inoltrata dal dispatcher al tuple manager
97
Capitolo 3
che quindi effettua il push della tupla stessa sull’interfaccia di callback; se il
destinatario invece è irraggiungibile la tupla viene inoltrata dal dispatcher al tuple
manager che provvede a scrivere la stessa sul proprio spazio.
La predictability nelle operazioni di dispatch ,scrittura nello spazio, ed attivazione
dell’interfaccia di callback sarà fornita tenendo presente la classe di servizio
assegnata all’interazione. I meccanismi di garanzia della QoS si occuperanno di
far sì che la scrittura di tuple tra coppie di peers di una data fascia avvengano nel
rispetto dei tempi medi misurati dal sistema di monitoraggio. Le richieste di write
vengono intercettate ed inoltrate in maniera differente (ad esempio con differente
priorità) in funzione della classe di servizio assegnata nel dominio all’interazione.
Per quanto riguarda invece il push della tupla verso il peer, bisogna tener presente
che tale peer potrebbe essere coinvolto in diverse interazioni, caratterizzate da
diverse criticità. Le richieste di push si accodano dunque all’interfaccia di
callback, ma possono essere servite esclusivamente una alla volta. Se
un’applicazione a bassa criticità invia un consistente numero di tuple blocca il
push di tuple provenienti da altre applicazioni, che magari hanno una criticità più
elevata. Per risolvere questo problema il push verrà effettuato applicando un
modello semaforico, che tiene conto della criticità delle tuple, il cui schema di
funzionamento è mostrato in figura 3-9.
98
Capitolo 3
A) PUSH DI UNA TUPLA DI CRITICITA’ 0 (MAX)
Imposta S1=ROSSO
Imposta S0=ROSSO
Invia Tupla
Imposta S0=VERDE
Imposta S1=VERDE
Peer su device
B) PUSH DI UNA TUPLA DI CRITICITA’ 1 (MED)
STOP
Aspetta semaforo S0
Imposta S1=ROSSO
Invia Tupla
Imposta S1=VERDE
Peer su device
C) PUSH DI UNA TUPLA DI CRITICITA’ 2 (MIN)
STOP
Aspetta semaforo S0
STOP
Aspetta semaforo S1
Invia Tupla
Peer su device
Figura 3-9 – Semafori per disciplinare il push in base alla criticità
Con riferimento alla figura 3-9, S0 è il semaforo che blocca le richieste a criticità
CR>0, mente S1 è il semaforo che blocca le richieste a criticità CR>1. Quindi
tutte le operazioni di push per tuple a criticità 1 e 2 dovranno attendere il push
delle tuple a criticità 0; le tuple a criticità 2 (minima) dovranno invece attendere
anche il push delle tuple a criticità 1.
ATTIVITÀ DI LETTURA (READ O TAKE) DELLE TUPLE
La lettura di una tupla avviene inoltrando la richiesta al dispatcher, che a sua volta
viene inoltrata al tuple manager, il quale provvedere ad estrarre dallo spazio (se
99
Capitolo 3
presente) la tupla desiderata, che viene quindi inoltrata dal dispatcher al bridge e
quindi al peer che l’aveva richiesta.
La predictability in queste operazioni non è strettamente necessaria. Infatti
quando un peer effettua una read sullo spazio di tuple non è detto che ci sia un
tupla da recuperare, e con ogni probabilità se viene effettuata la read la deadline
imposta è già stata ampiamente mancata (magari perché il device era
disconnesso). Si definisce comunque un’ulteriore policy per il dominio,
PREDICTABLE_READ che può assumere i valori YES, ed in tal caso la lettura
avviene coerentemente con la classe di servizio assegnata nel dominio
all’interazione, e NO, ed in tal caso tutte le letture vengono considerate di tipo
best-effort.
Se PREDICTABLE_READ è impostata a YES, la predictability viene fornita allo
stesso modo delle operazioni di write. Le richieste di read vengono intercettate ed
inoltrate in maniera differente (con differente priorità) in funzione della classe di
servizio assegnata nel dominio all’interazione.
DISPATCH INTER-DOMINIO DELLE TUPLE
Quando le interazioni coinvolgono peers in domini distinti, può accadere che la
classe di servizio associata all’interazione stessa vari tra un dominio e l’altro. Ad
esempio potrebbe variare da SILVER a GOLD o da GOLD a BRONZE. In tal
caso la classe di servizio utilizzata per il delivery della tupla deve variare. La
richiesta di write proveniente da un altro dominio viene inoltrata coerentemente
con la classe di servizio assegnata nel dominio locale, il che potrebbe comportare
una trasformazione della priorità associata alla scrittura della tupla.
3.3.5 Sistema di monitoraggio delle risorse del mediator
E’ impossibile determinare se i requisiti di QoS delle applicazioni Esperanto
possano essere accettati o meno senza disporre di meccanismi che effettuino il
monitoraggio delle risorse attuali dei mediator.
100
Capitolo 3
Ne paragrafo 3.3.1, sono stati individuati i tempi caratterizzanti la latenza per ogni
paradigma d’interazione definito in Esperanto:
•
TDIS – Latenza nel dispatch intra-dominio della tupla.
•
TDIS1 – Latenza nel dispatch inter-dominio.
•
TDIS2 – Latenza nella ricezione ed inoltro al tuple manager di una tupla
proveniente da un altro dominio.
•
TTM – Latenza nel tuple manager per il push della tupla al destinatario o
per la sua scrittura nello spazio.
Il sistema di monitoraggio deve determinare media e varianza di ognuna delle
componenti sopraindicate relativamente alle classi di servizio definite nel sistema,
affinché lo SLA manager possa determinare la soddisfacibilità dei requisiti di
qualità del servizio, e relativamente ad ogni interazione tra peers che interessa il
mediator, affinché i meccanismi di adattamento descritti al paragrafo successivo
possano rendersi conto delle variazioni nelle latenze di delivery relative alle
singole interazioni. Infatti considerare esclusivamente le latenze dell’intera classe
di servizio non è sufficiente. Una singola interazione potrebbe mostrare tempi
medi e varianze decisamente più scadenti, senza intaccare significamene i valori
relativi alla classe intera.
Nel paragrafo 3.3.1 alle classi di servizio si è associato un massimo numero di
richieste soddisfacibili. Se una data classe di servizio è a pieno carico, tutti gli slot
di servizio saranno occupati, compresi quelli definiti appositamente per resistere
ad improvvisi burst di richieste.
Il compito del sistema di monitoraggio è quello di informare lo SLA manager
circa lo stato di occupazione delle richieste attualmente in servizio per ogni classe,
in maniera tale che questi possa effettuare il controllo d’ammissione, e di
segnalare ai meccanismi adattativi che saranno descritti nel paragrafo successivo
eventuali livelli delle code di richieste in attesa di servizio per ogni classe.
Dunque per ogni classe di servizio il sistema di monitoraggio deve fornire:
•
Valor medio del numero di richieste in servizio presso la classe.
101
•
Capitolo 3
Valor medio della dimensione della coda di richieste in attesa di servizio.
Nella tabella 3-6 vengono riportate tutte le grandezze «elementari» sottoposte a
monitoraggio.
Elemento
Nome
Scope
Tipo misura
Latenza nel dispatch intra-dominio
della tupla
TDIS
Classi di servizio
Interazioni tra peers
Media
Varianza
Latenza nel dispatch inter-dominio
della tupla
TDIS1
Classi di servizio
Media
Varianza
Latenza nell’inoltro di una tupla
proveniente da un altro dominio al
tuple manager
TDIS2
Classi di servizio
Media
Varianza
Latenza nelle operazioni effettuate
dal tuple manager
TTM
Classi di servizio
Media
Occupazione degli slot di servizio
delle richieste
NR
Classi di servizio
Media
Dimensione della coda di servizio
della richiesta
NQ
Classi di servizio
Media
Tabella 3-6 – Valori elementari misurati dal sistema di monitoraggio
Relativamente al calcolo delle medie e delle varianze, va tenuto presente che è
opportuno utilizzare medie e varianze mobili sui campioni più recenti piuttosto
che le medie e le varianze relative all’intero periodo di funzionamento del sistema.
E’ controproducente infatti continuare a tenere memoria di informazioni relative
ad uno stato del sistema ormai obsoleto. Il calcolo della media e delle varianza
mobile tuttavia richiederebbe di tenere in memoria l’intero intervallo di campioni
che ricadono nella finestra d’osservazione, con conseguente spreco di risorse. Si
sceglie di applicare un trade-off tra l’accuratezza della misura e lo sforzo
computazionale necessario, calcolando medie e varianze nel seguente modo:
•
x n +1
1
⎧n −1
+
x
x n +1 n < N
n
⎪⎪ n
n
=⎨
⎪ N − 1 x + 1 x n >= N
⎪⎩ N n N n +1
102
•
VAR ( x) n +1
Capitolo 3
1
⎧n −1
2
n<N
VAR
x
+
x
−
x
(
)
(
)
n
n
+
1
n
+
1
⎪⎪ n
n
=⎨
⎪ N − 1VAR ( x) + 1 ( x − x ) 2 n >= N
n
n +1
n +1
⎪⎩ N
N
Dove N è la dimensione della «memoria» della media e della varianza. Ad ogni
nuovo campione misurato viene attribuito un peso pari a 1/N, mentre al
precedente valore di media o varianza memorizzato viene attribuito un peso pari a
N-1/N.
Data la fondamentale importanza rivestita dai fenomeni di handover in un
contesto come quello di Esperanto, è dunque di fondamentale importanza che i
componenti deputati alla gestione delle strategie adattative siano informati circa
gli handover in atto nel dominio. Pertanto andranno monitorate anche le ulteriori
seguenti grandezze:
•
HIN – numero di handover in ingresso (device che entrano nel dominio)
•
HOUT – numero di handover in uscita (device che escono dal dominio)
Il sistema di monitoraggio per il mediator di Esperanto applica lo snapshot
pattern [LOYAL 01] per dividere la raccolta delle informazioni sullo stato del
sistema, dalla richiesta delle informazioni stesse, che verrà effettuata dalle entità
che si occuperanno della negoziazione e del policing delle SLA (service level
agreement) tra i peers interagenti.
La struttura dello snapshot pattern è riportata nella figura 3-10. Le system
conditions forniscono un wrapper/facade pattern [SCHM 00b] per le componenti
di interesse del sistema, e forniscono l’accesso a tali valori mediante il metodo
getValue(). Gli aggregators raccolgono e trasformano, applicando delle formule, i
valori raccolti dalle System Condtions. Gli aggregators possono essere organizzati
in una struttura gerarchica, nel senso che forniscono il valore da loro calcolato ad
altri aggregators, che a loro volta determinano la snapshot dello stato del sistema.
103
Capitolo 3
Inoltre, anche se non evidenziato in figura 3-10, ogni System Condtion può avere
un certo numero di osservatori, che da questa vengono notificati quando si
verificano dei cambiamenti nel valore monitorato.
Nel sistema di monitoraggio di Esperanto i valori elementari definiti in tabella 3-6
costituiscono le System Conditions, che mantengono ed in alcuni casi (come
mostrato nel capitolo successivo) determinano autonomamente il valore osservato,
mediante tecniche di polling o mediante invocazione esplicita di metodi della o
mediante invocazione esplicita di metodi della System Condition.
Figura 3-10 – Struttura dello snapshot pattern
Vengono dunque definiti i seguenti tipi di System conditions:
•
SC1: System condition per la valutazione della media delle latenze delle
classi di servizio – deve esserne istanziata una per ogni classe di servizio,
raccoglie i dati per la negoziazione utili allo SLA manager.
•
SC2:System condition per la valutazione della varianza delle latenze della
classi di servizio - deve esserne istanziata una per ogni classe di servizio,
raccoglie i dati per la negoziazione utili allo SLA manager.
104
•
Capitolo 3
SC3:System condition per la valutazione della media delle latenze delle
interazioni – effettua il monitoring di una repository nella quale sono
memorizzati le latenze medie osservate per ogni interazione tra peers.
Viene utilizzata dai dispositivi di adattamento descritti al paragrafo
successivo.
•
SC4:System condition per la valutazione del numero medio di richieste in
servizio – deve esserne istanziata una per ogni classe di servizio, viene
utilizzata dallo SLA manager.
•
SC5:System condition per la valutazione della dimensione media della
coda delle richieste in attesa. – deve esserne istanziata una per ogni classe
di servizio, viene utilizzata dai meccanismi adattativi.
•
SC6:System condition per la valutazione del numero di handover
attualmente in atto nel dominio – deve esserne istanziata una per gli
handover in uscita ed una per gli handover in ingresso.
Vengono inoltre definiti due Aggregators, uno per fornire un immagine dello stato
del dominio allo SLA Manager ed uno per fornire un immagine dello stato di una
particolare interazione nel dominio al gestore dei meccanismi adattativi.
Il primo Aggregator restituisce una snapshot che descrive:
•
La CDF log-normale di ogni classe di servizio attraverso i valori di media
e varianza osservati.
•
Il valor medio del numero di slot di richiesta disponibili per ogni classe di
servizio.
Il secondo Aggregator restituisce una snapshot che descrive:
•
La CDF log-normale di una determinata interazione tra peers che interessa
il dominio, mediante la media e la varianza osservate per una data classe
•
Il valor medio della dimensione della coda di richieste per la classe di
servizio assegnata all’interazione in oggetto.
Per quanto concerne i valori di latenza osservati è compito dell’aggregator
ricostruire, a partire dai dati elementari che vengono monitorati, i dati relativi
105
Capitolo 3
all’interazione completa. Così ad esempio per quanto concerne l’invocazione di
un metodo di tipo request/response in un’interazione inter-dominio, in fase di
negoziazione del SLA l’aggregator del primo dominio combina i valori
elementari in modo da fornire il tempo medio e la varianza per l’interazione
completa nel primo dominio, ed analogamente l’aggregator del secondo dominio
fornisce il tempo medio e la varianza per l’interazione nel secondo dominio.
Il componente di monitoraggio delle risorse così definito è in grado di fornire ai
componenti che si occupano della negoziazione dei contratti una snapshot dello
stato del mediator relativamente ad ogni tipo di interazione. Tuttavia è
fondamentale che il sistema di monitoraggio non sia invasivo nel sistema, ovvero
la verifica dei livelli di latenza non deve impegnare eccessivamente il mediator. In
uno scenario dove la mobilità dei devices è elevata, la negoziazione e la
rinegoziazione delle SLA è una pratica frequente.
Si sceglie di quindi di applicare la versione loose dello snapshot pattern anziché
la versione consistent. In una consistent snapshot tutti i valori monitorati dalle
system conditions e raccolti dagli aggregatori ai diversi livelli devono essere
consistenti, ovvero rappresentare valori aggiornati. Per ottenere una snapshot
consistente l’intero sistema viene fermato mentre la snapshot viene calcolata.
Dovendo calcolare snapshot potenzialmente distinte per ogni coppia di peer
interagenti, fermare ogni volta il mediator può risultare estremamente dannoso. Si
opta quindi per una loose snapshot. I valori vengono raccolti e memorizzati
periodicamente dalle System Conditions. Quando gli aggregators richiedono tale
valore prendono il valore memorizzato, senza implicare un ricalcolo del valore
osservato, riducendo così nettamente i tempi necessari ad ottenere una snapshot
dello stato del mediator.
•
Le System conditions SC1,SC2,SC3,SC4 effettuano il monitoring della
media e della varianza della latenza per ogni classe e per ogni interazione,
ma memorizzano un nuovo valore, per renderlo disponibile agli
aggregators, e notificare gli osservatori solo quando la variazione tra il
vecchio valore memorizzato ed il nuovo monitorato supera una certa
106
Capitolo 3
soglia percentuale. Il monitoraggio dei tempi di latenza nel delivery deve
avvenire mediante l’utilizzo di opportuni timer. Un monitoraggio
esaustivo, effettuato controllando gli effettivi tempi di delivery di ogni
tupla finirebbe per incidere significativamente sulle prestazioni dell’intero
sistema. Viene sottoposto a controllo solo un campione delle tuple che
attraversano il dominio.
•
Analogamente le Analogamente le System Condition SC5,SC6 effettuano
dei controlli sui meccanismi di basso livello con tecniche di polling,
tenendone quanto più possibile bassa la frequenza, al fine di non inficiare
le performance degli stessi meccanismi di basso livello. Anche in questo
caso i valori misurati vengono memorizzati e notificati agli osservatori
solo se la variazione rispetto al vecchio valore memorizzato supera una
certa soglia percentuale.
I dettagli relativi alle modalità con cui le System Condition monitorano i propri
valori,all’inizializzazione delle entità System Condition stesse ed alle modalità di
comunicazione dei valori calcolati dagli aggregators tra i diversi domini saranno
forniti nei capitoli successivi.
3.3.6 Mobilità dei dispositivi e Supporto per l’adattatività al contesto delle
applicazioni
Fino al precedente paragrafo ci si è concentrati principalmente sugli aspetti statici
della QoS descritti al paragrafo 1.3.4, l’unico aspetto dinamico considerato è il
monitoraggio. In questo paragrafo saranno affrontati gli aspetti dinamici di QoS, e
specificamente: manutenzione, rinegoziazione e adattatività.
Sebbene sia il device a migrare e non il peer, in questo paragrafo si utilizzerà
spesso il termine peer in luogo del termine device, supponendo che su ogni device
ci sia sempre un solo peer. Tutte le considerazioni restano comunque valide anche
nel caso in cui diversi peer siano in esecuzione su uno stesso roamer device.
Verranno introdotti i meccanismi che saranno utilizzati per garantire, ove
possibile, il mantenimento dei livelli di qualità richiesti nelle interazioni dei peers
107
Capitolo 3
a fronte di handovers, i quali comportano da un lato un burst di trasferimento di
tuple inter-dominio, dall’altro una variazione nei carichi elaborativi del vecchio e
del nuovo dominio nel quale opera il device, di variazioni nel numero di
interazioni che un dato mediator deve sostenere, e di variazioni nella QoS
percepita dal mediator relativamente alle singole interazioni.
Nei primi due casi (handover e variazione dei carichi elaborativi del mediator) il
mediator stesso può intraprendere azioni correttive per mantenere i livelli di
qualità. Nell’ultimo caso la possibilità o meno di mantenere i livelli di qualità
viene demandata ai comportamenti adattativi dei peers (ad esempio possono
decidere di comprimere le informazioni da trasmettere). Tali comportamenti
adattativi non sono comunque oggetto del presente lavoro e pertanto non saranno
trattati in questa sede. Il mediator si limita ad offrire un supporto di tipo contextaware alle applicazioni, notificando ai peers le variazioni sensibili nel contesto.
Di seguito vengono affrontate le problematiche appena delineate.
ADATTATIVITÀ
DEL MEDIATOR A FRONTE DI VARIAZIONE NEI CARICHI
ELABORATIVI DEI SUOI COMPONENTI
Si consideri il seguente scenario: ad un mediator sono connessi N peers che sono
in comunicazione con altri M peers nello stesso dominio o in altri domini in classe
di servizio GOLD, ognuno con la propria classe di servizio e criticità. Le
interazioni si fanno sempre più intense, finquando si arriva ad un punto che un
mediator non è più in grado di gestire le comunicazioni con la qualità richiesta.
Non tutti i peer cui è stata assegnata la fascia GOLD possono quindi continuare a
lavorare in tal classe di servizio. Il mediator deve intraprendere delle azioni
adattative.
A tal fine si applica il contract pattern [LOYAL 01], il cui schema è riportato in
figura 3-11. Un contratto è costituito da regioni, le quali valutano un predicato
sulle System Conditions (cfr. Snapshot pattern). Se il predicato è vero per una
certa regione X, allora il contratto si trova nella regione X. Ad ogni regione
possono essere associate una o più transizioni. Un transizione è un’applicazione
108
Capitolo 3
del command pattern [SCHM 00b], ed avvia le azioni necessarie nel passaggio da
una regione all’altra.
All’interno del mediator Esperanto viene così realizzata out-of-band adaptation.
Le attività adattative out-of-band vengono avviate asincronamente rispetto al
flusso delle invocazioni, quando i componenti deputati al monitoraggio rilevano
una sostanziale cambiamento nello stato del sistema. I contratti vengono rivalutati,
e se si verificano transizioni di regione, vengono eseguite le attività previste da
tale transizione. Si differenziano dalle attività adattative in-band, che invece sono
sincrone all’invocazione di metodi remoti. Ogni qualvolta viene effettuata un
invocazione, viene valutato il contratto e scelto il comportamento adattativo
opportuno in base alla regione corrente del contratto.
Il sistema di monitoraggio, una volta rilevata una sensibile variazione nei livelli di
QoS, sollecita il contratto relativo alle operazioni interne al mediator, che da ora
in poi sarà chiamato Internal contract. L’internal contract valuta i predicati delle
sue regioni: se si è verificata una transizione allora intraprende delle azioni
adattative che possono essere di manutenzione, se si riorganizzano le proprietà di
dispatcher, device manager, tuple manager e tuple factory in maniera tale da far
rientrare i valori osservati per le classi di servizio entro i valori nominali; di
rinegoziazione se risulta necessario o opportuno rinegoziare qualcuna delle SLA
agreed.
109
Capitolo 3
Figura 3-11 – Struttura del contract pattern
Il Quality manager, tenterà di effettuare operazioni di manutenzione per non
modificare le SLA raggiunte. Se le operazioni di manutenzione non risulteranno
fattibili o non avranno risultati sensibili sulle latenze misurate, si procederà a
rinegoziare gli agreement.
Vengono quindi intraprese le transizioni necessarie ad uscire da questa situazione
critica, che implicano la rinegoziazione dei SLA, dapprima per le interazioni a
bassa criticità, e poi per le interazioni di media ed eventualmente anche di alta
criticità, a prescindere dal particolare valore delle policy del dominio. Tali
operazioni vengono effettuate da un’entità deputata alla gestione dei meccanismi
descritti al par. 3.3.4, che da ora in poi sarà chiamata Quality Manager in
collaborazione con lo SLA manager. Il risultato delle operazioni, per alcune
interazioni, sarà la variazione di classe di servizio assegnata.
In ogni caso, dopo le operazioni di rinegoziazione, se i requisiti continuano ad
essere soddisfati, il nuovo SLA assegnato viene notificato ai peer che
110
Capitolo 3
nell’interazione richiedono il servizio; se invece i requisiti di QoS non sono più
soddisfacibili, l’impossibilità di proseguire secondo le modalità precedentemente
specificate viene notificata ai peers, e SLA relativa a tale interazioni vengono
rimosse dallo SLA manager (dagli SLA manager se l’interazione avviene tra
domini distinti).
ADATTATIVITÀ DEL MEDIATOR A FRONTE DI VARIAZIONE DI FATTORI ESTERNI
Le System Conditions per la valutazione di media e varianza delle interazioni
forniscono un indice importante relativo a fattori «esterni» al mediator. Ad
esempio per un’interazione una media di delivery molto più alta di quella della
classe cui è stata assegnata è indice di pessima qualità del link wireless, mentre
una elevata varianza è indice di ampie fluttuazioni nella QoS rilevata dai device
interagenti.
Anche in questo si ricorre al contract pattern. Un secondo contratto, l’External
Contract verificherà se le variazione nei fattori esterni comporta o meno il non
rispetto dei requisiti imposti. Se ciò si verifica tutto ciò che può fare il mediator è,
compatibilmente con l’attuale SLA dell’interazione in questione, verificare se è
possibile trovare un nuovo SLA che consenta di bilanciare l’effetto della
variazione dei fattori esterni. Ad esempio la classe di servizio potrebbe essere
passata da BRONZE a GOLD. Nel caso in cui la rinegoziazione abbia successo il
nuovo SLA viene notificato al peer che richiede il servizio e l’interazione può
proseguire. In caso contrario viene notificata al peer l’impossibilità di proseguire
l’interazione con i requisiti imposti ed il (i) SLA relativi a tale interazione
vengono rimossi. Il peer potrà quindi specificare nuovi requisiti ed avviare una
nuova procedura di negoziazione per ottenere un nuovo SLA.
SUPPORTO PER LE DISCONNESSIONI
Se un device si disconnette il suo SLA resta comunque valido.
Si distinguano i casi in cui il SLA è relativo ad interazioni request/response o oneway ed il caso sia relativo ad interazioni di tipo solicit/response o notify.
111
Capitolo 3
Nel primo caso se a disconnettersi è il requestor, non accade assolutamente nulla
(al più una tupla di response non verrà delivered). Il SLA resta valido e quando il
requestor torna available nel dominio continuerà ad ottenere i livelli di QoS che
aveva prima dell’handoff. Se invece a disconnettersi è il provider rapidamente la
CDF log-normale associata all’interazione rivela che i requisiti non sono più
soddisfati, in quanto le tuple inviate non vengono mai consegnate, ed il SLA viene
rimosso. Analogamente accade nel secondo caso. Se a disconnettersi è il provider
non accade nulla e il SLA resta valido. Se invece si disconnette il requestor le
tuple inviate dal provider non verranno delivered e rapidamente i requisiti non
saranno più soddisfatti, con conseguente rimozione del SLA.
Se il SLA viene rimosso il requestor può nuovamente avviare la procedura di
negoziazione di nuovi livelli di QoS.
QUALITÀ DEL SERVIZIO NELL’HANDOVER
L’handover è un fenomeno critico per le interazioni che richiedono qualità del
servizio. Si consideri il seguente scenario: il device che ospita il peer P migra dal
dominio A al dominio B. Verosimilmente prima di abbandonare il dominio A
attraverserà una zona d’ombra, per cui nel mediator di A si accumuleranno tuple
destinate a P. Una volta inviato il messaggio di greeting al subscriber agent del
dominio B, dovranno essere effettuate le seguenti operazioni:
•
Negoziare un nuovo SLA con tutti i peer con cui P interagisce
•
Recuperare le tuple per P dal dominio A
In nessun modo si può pretendere a priori che i requisiti di QoS che venivano
soddisfatti nel dominio A continuino ad essere soddisfatti nel dominio B. Il SLA
precedentemente accordato non è più valido nel nuovo dominio, e gli stessi
requisiti specificati in A potrebbero non essere soddisfatti in B, che potrebbe
mostrare tempi di latenza per le operazioni di write e read decisamente superiori,
oppure potrebbe avere un link wireless scarsamente affidabile per cui le
probabilità di disconnessione risultano più elevate.
112
Capitolo 3
Attualmente il protocollo di gestione dell’handover, HOPAM, descritto al par.
3.1.3.3 si occupa esclusivamente del trasferimento delle tuple e della notifica
all’home domain del roamer della nuova location del device che ospita il peer.
Tale protocollo non è tuttavia efficiente se messo in relazione con il protocollo
TDPAM, che si occupa del delivery inter-dominio delle tuple. Se infatti il peer P1
migra dal dominio A al dominio B, le tuple dal peer P2 saranno ancora indirizzate
verso il dominio A. Una volta ottenuta l’informazione che P1 non è più in A,
viene interrogato il dominio home di P1, C, il quale restituisce l’informazione sul
nuovo host domain.
Quindi P2 invia di nuovo, stavolta correttamente, la tupla a P1 indirizzandola
verso il dominio B. In totale vengono effettuate 3 interazioni inter-dominio: 2 per
inviare (e poi re-inviare) la tupla, ed 1 per interrogare il device manager dell’home
domain. I tempi di delivery della tupla sono nettamente più alti rispetto al caso
«standard». Si tratta comunque di una situazione eccezionale, che si verifica solo
per la prima trasmissione successiva all’handover.
Si procederà ora ad analizzare il supporto dei meccanismi di gestione della QoS
nei confronti dell’handover, sia dal punto di vista del raggiungimento di un SLA
per tutti i peer con cui il roamer interagisce, come service requestor o service
provider, che dal punto di vista dei carichi elaborativi dovuti al trasferimento della
tuple dallo spazio del vecchio dominio host allo spazio del nuovo dominio host.
⇒ Raggiungimento di SLA nel nuovo dominio ed ottimizzazione del delivery
Il protocollo di gestione dell’handover deve effettuare le seguenti attività:
1. Aggiornare il proprio device manager o inserirvi una nuova entry
con le informazioni relative al nuovo roamer.
2. Interrogare lo SLA manager del vecchio dominio per reperire tutti
i peers con i quali il peer (o i peers) sul device roamer sta
interagendo, e le relative specifiche di QoS per le interazioni.
3. Per ogni tripla (X,CR,reqs) dove X è il peer con il quale il roamer
interagisce, CR è la criticità dell’interazione e reqs sono i requisiti
113
Capitolo 3
di QoS da soddisfare nel dominio, cercare di stabilire un nuovo
SLA secondo le procedura riportata al paragrafo 3.3.3.
Il protocollo di gestione del delivery delle tuple tra diversi mediator
effettua, oltre alle attività precedentemente delineate, le seguenti attività:
1. Quando viene inoltrata una tupla ad un dominio che non è più
l’host domain del peer destinatario, il dispatcher di tale dominio,
utilizzando il device manager instrada la tupla verso il mediator
corretto.
2. Il device manager del vecchio host domain notifica la nuova
location del peer destinatario. In tal modo la prossima tupla verrà
inviata direttamente al mediator del corrente host domain.
3. Dallo SLA manager del vecchio host domain viene rimossa
l’informazione relativa all’interazione tra il peer che ha inviato la
tupla ed il destinatario. Non è infatti più necessaria, in quanto tale
dominio non verrà più coinvolto nell’interazione.
⇒ Adattatività nei trasferimenti di informazioni di signalling e dati tra i
domini
La procedura di handover innesca un’intensa attività tra il vecchio ed il
nuovo dominio host. Per quanto visto nel paragrafo 1, tutte le tuple
destinate al roamer nel vecchio host domain devono essere trasferite nel
nuovo. Per quanto visto sopra, è necessaria anche una interrogazione degli
SLA manager per ottenere le triple (X,CR,reqs) dal vecchio host-domain.
La determinazione dei nuovi SLA, o la loro rinegozazione, è un’attività
estremamente critica per il mediator. I SLA da trasferire vengono ordinati
per criticità, in modo che il nuovo dominio host possa raggiungere al più
presto nuovi SLA per le interazioni maggiormente critiche. Vengono
trasferiti mediante un apposita interfaccia tra gli SLA manager,
caratterizzata da alte prestazioni.
114
Capitolo 3
Per quanto riguarda la rinegoziazione dei SLA va sottolineato che esistono
due casi particolari:
•
L’interazione da intra-dominio diventa inter-dominio. Non ha
senso che il roamer recuperi i requisiti nel vecchio host, poiché
non saranno gli stessi che devono essere soddisfatti nel nuovo. Non
vengono quindi trasferite triple (X,CR,reqs) in cui l’host domain di
X è il vecchio dominio host del roamer.
•
L’interazione da inter-dominio diventa intra-dominio. Non ha
senso che il roamer recuperi i requisiti dal vecchio host, poiché
saranno solo una parte di quelli che devono essere soddisfatti nel
nuovo. Non vengono quindi trasferite triple (X,CR,reqs) in cui
l’host domain di X è il nuovo dominio host del roamer.
Nel nuovo host domain l’internal contract svolge anche in questo caso un
ruolo determinante, passando nella regione critica di handover. In tale
regione vengono inibiti temporaneamente i meccanismi di out-of-band
adaptation per le seguenti ragioni:
•
Il progressivo trasferimento delle tuple e la negoziazione di nuovi
SLA potrebbe causare l’innesco dei meccanismi di out-of-band
adaptation che finirebbero con l’interferire con la procedura di
handover in corso.
•
Al termine della procedura di handover sarà aumentato il numero
di interazioni nel dominio, e probabilmente alcuni SLA andranno
comunque rinegoziati.
Anche il trasferimento delle tuple dal vecchio host domain è un task
critico. Un bulk transfer di tutte le tuple potrebbe causare una saturazione
dei dispatcher di entrambi i domini e del tuple manager del nuovo
dominio.
115
Capitolo 3
In questo caso è fondamentale la criticità delle interazioni. Questa infatti
resterà costante anche nel nuovo dominio, mentre la classe di servizio
potrebbe variare. Ancora l’internal contract disciplina il trasferimento
delle tuple dal vecchio dominio al nuovo dominio, influenzando oltre che
le operazioni relative all’handover anche il flusso di scritture di tuple dal
vecchio host verso altri domini e da altri domini verso il nuovo host.
L’internal contract stavolta viene utilizzato per effettuare in-band
adaptation, applicando simultaneamente l’interceptor pattern, descritto in
[SCHM 00c] ed il contract pattern. L’obiettivo è quello di effettuare il
retrieval e trasferire le tuple in maniera predictable, senza del resto
bloccare le «normali» attività di lettura nel vecchio host domain e le
«normali» attività di scrittura nel nuovo dominio.
La predictability sarà ottenuta mediante opportune configurazioni
dell’interfaccia inter-dominio del dispatcher, limitando l’effetto della
concorrenza delle tuple dispatched per interazioni inter-dominio e delle
tuple spostate a seguito di un handover.
Gli aspetti comportamentali della in-band adaptation si occuperanno
invece di schedulare opportunamente le operazioni di trasferimento delle
tuple, evitando trasferimenti di tipo bulk. Utilizzando gli interceptor verrà
disciplinato il trasferimento delle tuple dal vecchio host domain al nuovo
host domain, valutando l’internal contract del vecchio e del nuovo
dominio host, per determinare i comportamenti adattativi da adottare.
Si rimanda ai capitoli successivi per i dettagli relativi alla specifica ed
implementazione dei comportamenti adattativi.
3.4 Struttura QoS-enabled del mediator
In figura 3-12 è riportata una rappresentazione del modello architetturale del
mediator QoS-enabled. Con tale termine si intende il mediator così come descritto
116
Capitolo 3
al paragrafo 1 del presente capitolo arricchito dei componenti che gestiscono gli
aspetti di QoS statica e dinamica nelle modalità descritte al paragrafo precedente.
Internal
Contract
External
Contract
Negoziazione
QoS
SLA
MANAGER
SYSTEM
MONITORING
SERVICE
QUALITY
MANAGER
Regolazione livelli sottostanti
(ORB,OS,network transport)
Peer
BRIDGE
DISPATCHER
TUPLE
MANAGER
Classe di servizio GOLD
Classe di servizio SILVER
Classe di servizio BRONZE
Classe best-effort
Misurazione latenze
Interceptors
Figura 3-12 – Architettura QoS-enabled del mediator
3.4.1 System Monitoring Service
Si occupa della determinazione delle snapshot dello stato del sistema (dove per
sistema si intende la parte di core network interessata dall’interazione di due
particolari peers). Contiene al suo interno le System conditions e gli aggregators
definiti al paragrafo 3.3.5.
Il System Monitoring Service (SM Service) viene utilizzato dallo SLA manager ,
ed invia notifiche relative alla variazione dello stato osservato sia all’Internal
Contract, che all’External Contract.
Le sue funzioni sono:
117
•
Capitolo 3
Calcolo delle snapshot del sistema su richiesta dello SLA manager o di
uno dei contratti.
•
Sollecitazione asincrona dell’internal contract e dell’external contract a
seguito di variazioni sensibili nelle misure effettuate dalle System
Conditions.
Una sua caratteristica importante è la bassa invasività nel sistema. L’applicazione
dello snapshot pattern ne consente il calcolo in maniera rapida e semplice.
3.4.2 SLA Manager
Si occupa della negoziazione e rinegoziazione dei SLA tra i peers. Le decisioni
vengono prese in base ai valori calcolati dal SM Service.
Lo SLA Manager interagisce con gli SLA Manager degli altri domini,con il SM
service locale, con il Quality manager e con i tuple delivery layer dei devices,
verso i quali espone un’interfaccia che contiene le API descritte al paragrafo 3.3.2,
consentendo la specifica dei requisiti di QoS.
Contiene un repository per mantenere le informazioni relative ai SLA
correntemente attivi nel dominio.
Svolge le seguenti funzioni:
•
Negoziazione di un SLA tra due peers su richiesta del service
requestor
•
Rinegoziazione di un SLA su richiesta del Quality Manager
•
Invio di informazioni ai devices circa i SLA correnti dei peers che
ospitano.
•
Notifica ai devices della rimozione forzata dei SLA dal dominio
•
Gestione delle policy di dominio (DELIVERY, PREEMPTIVE,
SET_SERVICE_CLASS e READ_PREDICTABLE)
Le attività di negoziazione e rinegoziazione devono essere effettuate in maniera
predictable per limitare il periodo nel quale i peers attendono la concessione di un
118
Capitolo 3
SLA o subiscono fluttuazioni nella QoS percepita a causa delle attività di
rinegoziazione.
3.4.3 Quality Manager
Compito del Quality Manager è cercar di garantire i SLA concessi ai peers a
fronte di variazioni nel livello di QoS rilevate dal SM Service. Si occupa di
pilotare e nei limiti del possibile modificare le configurazioni dei livelli sottostanti
i componenti del mediator deputati al delivery.
Viene attivato in seguito a transizioni nella valutazione dei contratti (Internal ed
External), e gestisce i meccanismi messi a disposizioni dall’ORB sul quale sono
installati i componenti del mediator.
3.4.4 Internal ed External Contract
I contratti sono gli elementi chiave della out-of-band adaptation e della in-bandadaptation descritta al par.3.3.6.
Interagiscono con il SM service, che comunica variazioni nei valori di QoS
misurati, innescando eventualmente transizioni di regione, con gli interceptors,
che li utilizzano per scegliere il comportamento non funzionale più appropriato
secondo la regione di funzionamento corrente e con il Quality manager, le cui
funzioni vengono invocate nelle transizioni di regione.
In particolare l’Internal contract definisce due regioni di funzionamento di base:
una critica, nella quale si entra nel caso il dominio sia coinvolto in una procedura
handover ed una di funzionamento standard. Per ognuna di queste regioni sono
definite delle sottoregioni i cui predicati valutano lo stato corrente delle classi di
servizio in termini di numero medio di richieste contemporaneamente servite e
lunghezza media delle richieste in coda. L’internal contract non tiene conto delle
System Conditions relative alle singole interazioni, che sono invece oggetto dei
predicati dell’external contract, il cui compito è valutare se e di quanto una
particolare interazione mostra latenze più elevate di quelle richieste ed
119
Capitolo 3
eventualmente valutare la possibilità di intraprendere azioni correttive o notificare
la failure dell’interazione.
3.4.5 Interceptors
Sono utilizzati nelle operazioni di trasferimento delle tuple durante le procedure
di handover. Applicano comportamenti adattativi contestuali al trasferimento
delle tuple dal vecchio al nuovo dominio host. I comportamenti adattativi vengono
scelti in base alla regione di funzionamento corrente dell’internal contract in
maniera tale da evitare la saturazione dei mediators durante gli handover e
garantire, per quanto possibile, il corretto funzionamento delle altre interazioni e
la massima efficienza in termini temporali del completamento della procedura di
handover.
3.5 Scenari dinamici
In questa sezione è presentato il comportamento dinamico dei componenti del
mediator deputati alla gestione della QoS, nei casi tipici in cui questi vengono
coinvolti: la negoziazione, il delivery delle tuple, la rinegoziazione dei SLA in
seguito a variazioni nelle latenze misurate nel mediator, l’handover di un device.
3.5.1 Negoziazione della QoS tra due peers
Il mediator negozia un service level agreement
per due peers nello stesso
dominio (figura 3-13)
1. Un
service
requestor
nel
dominio
del
provider
invoca
l’API
make_qos_request, specificando i suoi requisiti di QoS,il peer con cui
vuole interagire e la funzione che intende invocare con requisiti di QoS.
2. Il service provider è locale al dominio, per cui lo SLA Manager richiede al
sistema di monitoraggio la snapshot relativa allo stato corrente del
dominio.
120
3. Lo
SLA
Manager
recupera
SET_SERVICE_CLASS
e
i
Capitolo 3
valori
PREEMPTIVE
correnti
per
delle
determinare
policies
come
effettuare il controllo d’ammissione.
4. Data la snapshot del dominio ed i valori delle policies lo
SLA_MANAGER cerca una classe di servizio che possa garantire i
requisiti di qualità del servizio imposti.
Figura 3-13 – Negoziazione della QoS tra due peers nello stesso dominio
5. Se la classe viene trovata viene restituito l’ID dell’agreement al peer 1; i
dati del SLA vengono scritti nella repository dello SLA manager insieme
ai requisiti di QoS specificati.
6. Se la classe non viene trovata al client viene restituito un valore
(convenzionale) NO SLA, e non viene scritto nulla sul repository.
Il mediator del service requestor negozia un service level agreement per due
peers in domini diversi (figura 3-14)
121
Capitolo 3
I due peers, peer 1 e peer 2 sono ospitati rispettivamente nei domini A e B.
1. Un
service
requestor
nel
dominio
A
(peer
1)
invoca
l’API
makeQosRequest, specificando i suoi requisiti di QoS,il peer con cui vuole
interagire e la funzione per la quale richiede qualità del servizio.
2. Lo SLA manager di A richiede al System Monitoring Service di A la
snapshot dello stato attuale del dominio, in termini di media e varianza dei
tempi di dispatch delle tuple e di scrittura di tuple provenienti da altri
domini.
3. Lo
SLA
Manager
recupera
SET_SERVICE_CLASS
e
i
valori
PREEMPTIVE
correnti
per
delle
determinare
policies
come
effettuare il controllo d’ammissione
4. Selezionata in base alle policies una classe di servizio,lo SLA Manager
utilizza la CDF log-normale inversa per determinare i requisiti «parziali»
dell’interazione relativi al dominio A. Viene individuata la latenza che
deve essere garantita nel dominio A affinché l’interazione avvenga con la
probabilità di successo specificata.
5. Dai requisiti specificati con la makeQosRequest vengono sottratti i tempi
di latenza individuati per il dominio A e viene invocata la
makeQosRequest sul dominio B.
6. Nel dominio B vengono ripetute le stesse operazioni effettuate nel dominio
A. Anche in questo caso viene richiesta la snapshot del dominio relativa al
dispatch ed alla scrittura di tuple provenienti da altri domini.
7. Il controllo d’ammissione viene effettuato utilizzando la CDF lognormale. In base ai valori della snapshot, alle policies di dominio, viene
individuata una classe che può soddisfare i requisiti reqs’’. Se non viene
individuata alcuna classe di servizio, viene restituito un messaggio
NOSLA al dominio A, che può scegliere una nuova classe di servizio,
formulare nuovi requisiti reqs’’ e ripetere la procedura sul dominio B.
8. Nel caso in cui venga individuata una classe di servizio che soddisfa i
requisiti di latenza e probabilità di successo viene scritto il SLA nel
122
Capitolo 3
dominio B, nel quale vengono memorizzati gli ID dei due peers, la
funzione invocata, la classe di servizio assegnata, ed i requisiti reqs’’ che
includono: massima latenza, probabilità di successo e criticità.
Peer 1
(requestor)
A SLA Manager
B SLA Manager
A SM Service
B SM Service
makeQosRequest(p1,p2,f,reqs)
get_snapshot
getValues
(snapshot)
reqs:
requisiti da soddisfare
reqs':
requisiti nel dominio A
reqs'':
requisiti nel dominio B
getPolicies
admissionControl
makeQosRequest(p1,p2,f,reqs'')
get_snapshot
getValues
(snapshot)
getPolicies
admissionControl
write_sla(peer1,peer2,CS,f,CR,reqs'')
SLA_ID or NO_SLA
write_SLA(P1,P2,f,CS,CR,reqs')
SLA_ID or NO_SLA
Figura 3-14 – Negoziazione della QoS tra due peers in domini diversi
9. Viene scritta anche un SLA nel dominio A nel quale vengono memorizzati
gli ID dei due peers, la funzione invocata, la classe di servizio assegnata,
ed i requisiti reqs’ che includono: massima latenza, probabilità di successo
e criticità.
123
Capitolo 3
3.5.2 delivery QoS-enabled delle tuple
Una tupla viene trasferita dal peer 1 al peer 2 coerentemente con i requisiti di
QoS memorizzati nello SLA manager (figura 3-15). Per non rendere poco
leggibile il grafico si suppone che il peer 2 sia locale al peer 1,abbia effettuato il
subscribe ed il push sull’interfaccia di callback abbia successo.
Figura 3-15 – Delivery di una tupla intra-dominio
1. Il peer 1 invia un tupla che viene raccolta dal Bridge dal livello
ncsocks
2. Il Bridge interroga lo SLA manager e determina a quale classe di
servizio deve essere assegnata la tupla
3. La tupla viene inoltrata al dispatcher (l’invio tiene conto della classe di
servizio della tupla – non è mostrato nel diagramma)
4. Il Dispatcher determina che la tupla è locale, la inoltra sul tuple
manager locale.
124
Capitolo 3
5. Peer 2 ha effettuato il subscribe, pertanto esiste un’interfaccia di
callback da utilizzare per il push diretto della tuple.
6. L’interfaccia di callback interroga lo SLA manager e determina la
criticità dell’interazione cui la tupla appartiene
7. L’interfaccia di callback applica behaviours adattativi per dare
precedenza al push di tuple relative ad interazioni ad alta criticità.
8. La tupla viene inviata a Peer 2
3.5.3 Rinegoziazione asincrona dei SLA
Il system monitoring service rileva una variazione sensibile di un valore misurato,
viene valutato l’internal contract che applica i comportamenti adattativi connessi
ad una particolare transizione di regione, la quale implica la rinegoziazione di
alcuni SLA (figura 3-16).
1. In seguito alla variazione del valore mantenuto in una System
Condition viene inviata una segnalazione asincrona all’internal
contract relativa alla variazione di un valore misurato.
2. Viene effettuata la valutazione dell’internal contract che rileva una
transizione di regione
3. La transizione viene avviata asincronamente dall’internal contract
4. La transizione, utilizzando lo SLA Manager, seleziona alcuni service
level agreements e ne avvia la rinegoziazione.
5. Lo SLA Manager accetta la rinegoziazione se i requisiti possono essere
soddisfatti anche in altre classi di servizio e memorizza i nuovi SLA,
altrimenti la rifiuta inviando un messaggio SLA_NO
6. Se la rinegoziazione non ha successo la transizione rimuove dallo SLA
Manager i service level agreements precedentemente selezionati.
7. Se la rinegoziazione non ha successo, la transizione notifica ai
requestors
delle
interazioni
precedentemente
selezionate
l’impossibilità di proseguire l’interazione con i requisiti specificati e
quindi la rimozione dei service level agreements.
125
Capitolo 3
Figura 3-16 – Rinegoziazione di un SLA avviato in maniera asincrona dal
System Monitoring Service
3.6 Considerazioni sulla soluzione proposta
3.6.1 Il modello di QoS a classi di servizio
La soluzione proposta utilizza classi di servizio i cui corrispondenti valori di
latenza nominale possono variare da dominio a dominio. Ciò consente di poter
realizzare domini Esperanto con diverse caratteristiche di qualità del servizio,
secondo le configurazioni hardware e software sulle quali il mediator lavora. Ad
esempio in un cantiere il mediator potrebbe risiedere su un normale PC con un
sistema operativo COTS dotato di scarso supporto per il real-time, mentre in
un’aereoporto potrebbero esserci diversi mediators, interconnessi da una
backbone in fibra ottica; per ogni mediator i componenti potrebbero essere
distribuiti su più processori (sistemi multiprocessore o multicomputer). Nel caso
126
Capitolo 3
dell’aereoporto le prestazioni, a parità di classi di servizio, sarebbero decisamente
migliori. Ciò non toglie comunque che un peer nel dominio del cantiere possa
connettersi ad un peer in aeroporto (sempre che i due domini siano connessi in
qualche modo) specificando dei requisiti di QoS indipendenti dai particolari valori
nominali delle classi di servizio nel cantiere e nell’aereoporto.
La determinazione dei valori nominali per classi di servizio deve essere
necessariamente fatta prima della messa in opera del mediator stesso, scegliendo
un punto di carico ideale ed effettuando una serie di misurazioni. Tali valori
dovranno essere utilizzati per inizializzare le System Conditions che calcolano la
media delle latenze per le classi di servizio.
3.6.2 Mancanza di supporto per la QoS nel device
Il presente lavoro si concentra esclusivamente sulla QoS nella core network. Ciò
che è esterno, ovvero il link wireless tra mediator e device ed il device stesso allo
stato attuale del lavoro viene visto come un qualcosa di non misurabile e non
controllabile. La QoS fornita non è quindi end-to-end relativamente alle
interazioni tra peers ma end-to-end relativamente al ruolo che il mediator svolge
nell’interazione. L’allargamento ai devices del supporto per la qualità del servizio
non è oggetto di questa tesi.
3.6.3 L’utilizzo della distribuzione log-normale per le singole interazioni
Caratterizzando con una distribuzione log-normale non soltanto le latenze nelle
diverse classi di servizio, ma anche le latenze per ogni interazione tra peers, il
sistema di monitoraggio è in grado di individuare le variazioni nei tempi di
latenza per ogni interazione, in modo da poter isolare fenomeni che dipendono da
una congestione o failure del mediator, che coinvolgono intere classi di servizio,
da fenomeni che influenzano la singola interazione o al più un gruppo di
interazioni, come failures o
disconnessioni del singolo device o eventi che
influenzano la qualità di un collegamento wireless in una determinata area.
127
Capitolo 3
3.6.4 Verifica delle specifiche
Nella tabella 3-8 viene riportato un quadro sintetico nel quale è indicato se e come
sono stati soddisfatti i requisiti formulati al paragrafo 3.2.6.
Requisito
Soddisfatto
Note
Supporto per la gestione efficiente
e predictable dell'handover
e del dispatching inter-domain
delle tuple
SI
L’internal contract e la in-band adaptation
effettuata dall’inter-domain interceptor,
nonché i meccanismi messi a disposizione
dall’ORB sottostante rendono efficiente e
predictable l’handover ed il delivery interdomain,
Definire una metodologia formale
per specificare i requisiti di
qualità del servizio dei peers.
SI
Ottenuta mediante l’API di cui al par. 3.3.2,
che interfaccia la piattaforma device-side
allo SLA manager
SI
La specifica viene soddisfatta dal System
monitoring service
Mapping dei requisiti di alto
livello in requisiti di basso livello
PARZIALMENTE
Il mapping è stato definito nel modello di
QoS e viene realizzato dal SM service. Le
stime ottenute tuttavia non sono
decisamente affidabili.
Fornire dei meccanismi per
valutare se i requisiti di
funzionamento di un'applicazione
possono essere soddisfatti o meno
SI
La specifica viene soddisfatta dallo SLA
Manager
Sviluppare dei meccanismi per
garantire il soddisfacimento dei
requisiti di qualità
SI
La specifica viene soddisfatta
dall’interazione tra Quality manager,
contratti, SLA manager e meccanismi
dell’ORB sottostante
PARZIALMENTE
Il soddisfacimento completo di tale
specifica va al di là del presente lavoro che
si concentra esclusivamente sul mediator.
Viene comunque fornito supporto alle
applicazioni mediante un servizio di
notifica di cambiamento dei livelli di QoS
cui l’applicazione può reagire.
Realizzare un sistema di
monitoraggio delle risorse
disponibili nel mediator.
Fornire un supporto per
l'adattatività delle applicazioni
fornendo metodi formali per
specificare i comportamenti non
funzionali dalle applicazioni
separatamente dal codice che
implementa la logica applicativa
dell'applicazione stessa
Tabella 3-8 – Riepilogo dei requisiti
128
Progettazione del sistema di gestione della QoS
Capitolo 4
Capitolo 4
4.1 Introduzione
Nel capitolo precedente sono affrontati i problemi relativi alla gestione della
qualità del servizio nella core netowrk di un’infrastruttura di nomadic computing.
Sono stati dunque individuati i componenti da realizzare per soddisfare i requisiti
formulati al paragrafo 3.2.7. In questo capitolo verranno forniti maggiori dettagli
relativi alla progettazione di tali componenti.
Nel paragrafo 2 verrà approfondita la progettazione dello SLA manager, il
componente deputato alla negoziazione della QoS ed al controllo d’ammissione.
Nel paragrafo 3 verrà trattata la progettazione del System Monitoring Service, il
componente deputato al monitoraggio delle latenze delle interazioni nel mediator,
dello stato delle tre classi di servizio definite e delle situazioni di handover.
Nel paragrafo 4 ci si occuperà dell’adattatività in-band ed out-of-band nelle
operazioni di delivery effettuate dal mediator di Esperanto. Verrà trattata
l’infrastruttura per gestire i contratti e saranno definite le regioni e le transizioni
(che attuano i behaviours adattativi out-of-band) sia dell’internal contract che
dell’external contract. Sarà introdotto il Quality Manager, un componente
deputato alla gestione delle proprietà dell’ORB (Object Request Broker)
sottostante i componenti del mediator. Verranno inoltre introdotti i delegati,
componenti deputati alla realizzazione di comportamenti adattativi in-band per
gestire le procedure di handover.
In figura 4-1 viene riportato un diagramma di collaborazione dei componenti
costituenti il sistema di gestione della QoS per il mediator di Esperanto.
129
re
isu
registra misure
su
mi
ra
am
ist
istr
r eg
a
reg
re
snapshot
ific
ot
ad n
at
ta
Capitolo 4
Figura 4-1 – Collaborazione tra i componenti del mediator e
del sistema di gestione della QoS
4.2 Meccanismi per la negoziazione della QoS
In questo paragrafo si affronterà la progettazione del componente deputato alla
gestione dei service level agreements tra i peers.
Tale componente, denominato SLA Manager, svolge le seguenti funzioni:
•
Negoziazione di un service level agreement (SLA) relativo all’invocazione
di una determinata funzione esposta da un service provider.
•
Rinegoziazione o rimozione di un SLA.
•
Gestione delle informazioni relative ai SLA raggiunti.
•
Gestione delle policies di dominio
Lo SLA Manager, per stabilire se concedere o meno un service level agreement
utilizza le snapshot messe a disposizione dal sistema di monitoraggio, la cui
progettazione verrà affrontata nel paragrafo successivo.
Oltre alla gestione dei service level agreements è compito dello SLA manager
anche la gestione delle policy di dominio, introdotte nel capitolo 3 e di seguito
130
Capitolo 4
riportate:
•
DELIVERY – stabilisce se e quando rimuovere una tupla memorizzata
nello spazio locale
•
PREEMPTIVE – stabilisce se per assegnare un SLA ad un’interazione ad
alta criticità possa essere rimosso il SLA di un’interazione a più bassa
criticità.
•
SET_SERVICE_CLASS – stabilisce un criterio per l’assegnazione delle
classi di servizio
•
READ_PREDICTABLE – stabilisce se le operazioni di lettura nello
spazio debbano avvenire coerentemente con la classe di servizio assegnata
all’interazione o meno.
Di seguito verranno dapprima trattate tutte le funzionalità esposte nelle diverse
interfacce del componente, per poi approfondire il progetto della struttura interna
del componente stesso.
4.2.1 Interfaccia verso i device
Lo SLA Manager viene chiamato in causa direttamente dai devices durante la
negoziazione di nuovi SLA tra peers interagenti. L’interfaccia fornita dallo SLA
manager alla piattaforma device-side è descritta in figura 4-1. Essenzialmente
espone le primitive di gestione della QoS elencate nel paragrafo 3.3.2.
4.2.2 Interfaccia verso altri SLA Manager
Nel caso di agreements tra devices dislocati in domini differenti la negoziazione,
che avviene come descritto al paragrafo 3.3.3, coinvolge gli SLA Manager di
entrambi i domini. L’interfaccia, descritta in figura 4-2, fornita dallo SLA
manager agli SLA Manager di altri domini ricalca l’interfaccia verso i devices,
aggiungendovi funzioni la rimozione dei SLA ed il trasferimento delle specifiche
sui requisiti in caso di handover.
131
Capitolo 4
4.2.3 Interfaccia verso i contratti
Sia l’internal che l’external contract (che saranno descritti nel paragrafo 4 del
presente capitolo), utilizzano lo SLA Manager per innescare le procedure di
rinegoziazione dei service level agreement nel dominio o per revocare SLA
precedentemente concessi e non più rispettabili. Le attività di rinegoziazione
vengono invocate dall’internal contract, mentre la revoca dei SLA può essere
decretata sia dall’external contract che dall’internal contract.
4.2.4 Interfaccia verso i componenti del mediator
Nel caso di operazioni di scrittura quando la tupla viene prelevata dalla PDU
ricevuta sul livello ncsocks deve essere instradata alla classe di servizio assegnata
all’interazione cui appartiene.
Figura 4-2 – Interfacce del componente SLA Manager
132
Capitolo 4
Il bridge quindi, per ogni tupla estratta, interroga lo SLA Manager per ottenere la
classe di servizio sui cui instradare la tupla e la criticità dell’interazione cui la
tupla stessa appartiene, che viene quindi «etichettata» con la sua classe di servizio
e criticità, in maniera tale che non sia più necessario interrogare lo SLA manager
durante il delivery della tupla.
In caso di operazioni di lettura,se la policy PREDICTABLE_READ assume il
valore YES, il bridge interroga lo SLA Manager per verificare se per l’interazione
cui fa riferimento l’operazione di lettura è stata assegnata una classe di servizio ed
in tal caso instrada l’operazione di lettura su tale classe di servizio. In caso
contrario la lettura è di tipo best-effort.
I componenti del mediator hanno inoltre bisogno di conoscere i valori assegnati
alle policies del dominio: per quanto appena visto il bridge deve conoscere il
valore della policy PREDICTABLE_READ per instradare le operazioni di lettura,
mentre il tuple manager gestisce la persistenza delle tuple nello spazio in base alla
policy DELIVERY.
L’interfaccia esposta verso i componenti del mediator è riportata in figura 4-2.
Vengono esposte le seguenti funzionalità:
•
restituzione della classe di servizio assegnata ad un’interazione
•
restituzione della criticità associata ad un’interazione
•
restituzione del valore di una determinata policy del dominio
4.2.5 Struttura interna dello SLA Manager
Dopo aver descritto le interfacce e le funzionalità esposte dallo SLA Manager si
discuterà ora l’architettura interna dello stesso relativamente alle operazioni di
negoziazione dei service level agreement,di memorizzazione degli stessi e alla
gestione delle policies di dominio.
All’interno dello SLA Manager si distinguono pertanto tre oggetti:
•
il Negotiator, che gestisce le operazioni di negoziazione dei SLA
•
lo SLA Repository, che conserva tutte le informazioni circa i service level
133
Capitolo 4
agreements raggiunti nel dominio.
•
Il Policy Manager, che consente di ottenere ed eventualmente impostare i
valori per le policies di dominio
4.2.5.1 NEGOTATIOR PER IL CONTROLLO D’AMMISSIONE
I compiti di questo oggetto sono:
1. ammettere o rifiutare le richieste di qualità del servizio provenienti dai
peers.
2. gestire i service level agreements utilizzando lo SLA Repository.
3. tentare la rinegoziazione dei service level agreements su indicazioni
provenienti dal Quality Manager .
4. notificare ai peers la revoca di un SLA o la sua modifica.
5. interagire con gli SLA Manager di altri domini per la negoziazione della
QoS in interazioni inter-dominio.
La struttura della classe del Negotiator è riportata in figura 4-4. Di seguito viene
riportata una descrizione dei metodi e degli attributi di tale classe.
•
lnCDF – restituisce il valore della funzione distribuzione di probabilità
cumulativa log-normale per un dato valore di latenza (che può essere ad
esempio un latenza di delivery intra-dominio), assegnata la media e la
varianza di tale valore.
•
lnCDFinv – restituisce il valore della funzione inversa della CDF lognormale. Ad un valore di probabilità associa il corrispondente valore di
latenza, assegnata la media e la varianza di tale valore.
•
negotiateClass – verifica se una data interazione per la quale sono stati
specificati dei requisiti di QoS può garantire tali requisiti in una
determinata classe di servizio. Tale metodo viene utilizzato da
makeQosRequest e da renegotiateClass.
•
makeQosRequest – tenta di stabilire un SLA tra il requestor indicato nel
parametro srcPeerID ed il provider indicato nel parametro dstPeerID circa
una particolare funzione esposta dal provider stesso con determinati
134
Capitolo 4
requisiti di criticità, massima latenza e percentuale di successo. Nel caso di
interazione inter-dominio (requestor e provider in due domini distinti) tale
metodo invoca anche il metodo makeQosRequest del dominio del service
provider. Si cerca di individuare una classe (o una coppia) di classi di
servizio che possa soddisfare i requisiti per l’interazione tra i peers.
•
renegotiateClass – effettua una nuova negoziazione per un SLA
precedemente stabilito nella nuova classe di servizio specificata come
parametro dell’operazione. Viene utilizzato dai meccanismi per il controllo
della qualità del servizio descritti al paragrafo 4.4. Se la rinegoziazione ha
successo, e quindi i requisiti associati al SLA possono essere soddisfatti
anche in un’altra classe di servizio, allora viene restituito un nuovo SLAID
ed il vecchio SLA viene rimosso. In caso contrario non viene stabilito
alcun SLA e resta attivo il precedente.
Il negotiator utilizza il servizio di monitoraggio per recuperare la snapshot
corrente del sistema. Noto il peer che funge da service provider e la funzione per
l’utilizzo della quale si sta negoziando la qualità del servizio, saranno noti anche
la locazione del peer (locale,remoto) ed il paradigma dell’invocazione
(request/response,one-way,…). Queste informazioni vanno comunicate al sistema
di monitoraggio prima di ottenere la snapshot, in maniera tale che gli
Aggregators, la cui progettazione sarà affrontata in dettaglio nel paragrafo
successivo, possano combinare i valori elementari di media e varianza per fornire
il tempo medio di latenza e la varianza relativi all’intero lavoro da svolgere nel
dominio.
4.2.5.2 REPOSITORY PER LA GESTIONE DELLE SLA
I compiti di quest’oggetto sono:
1. Registrazione dei service level agreements raggiunti
2. Eliminazione degli stessi
3. Aggiornamento degli stessi
I SLA vengono memorizzati in una struttura ad albero nella quale al primo livello
ci sono gli ID dei providers, al secondo livello gli ID dei requestors ed al terzo
135
Capitolo 4
livello i metodi del service provider per i quali i requestors hanno specificato
qualità del servizio, insieme alla classe di servizio assegnata ed ai requisiti
specificati.
Figura 4-3 – Struttura dello SLA Repository
Lo SLA repository, la cui struttura è riportata in figura 4-3 contiene l’attributo dati
SLATree, struttura dati di tipo IDL sequence in cui sono conservati i dati di tutti i
SLA correntemente attivi nel dominio. Ogni elemento è una struct che contiene
l’ID del service provider ed una sequence nella quale ogni elemento è a sua volta
una struct contenente l’ID del service requestor ed un’ulteriore sequence in cui
ogni elemento è una struct contenente il nome della funzione da invocare con
garanzie di QoS ed i relativi parametri di QoS (massima latenza, percentuale di
successo, criticità). Una rappresentazione di tale struttura dati è riportata in figura
4-4.
Figura 4-4 – Struttura per la memorizzazione dei SLA
L’attributo SLAtree viene gestito mediante i metodi esposti dalla classe
SLARepository, che consentono di inserire, modificare, rimuovere e leggere i
dettagli degli agreements memorizzati nella struttura dati (classe di servizio
136
Capitolo 4
assegnata, requisiti di qualità del servizio associati, criticità dell’interazione).
Il metodo restore ricostruisce la struttura dati QoSReqsTree dai dati memorizzati
nel database dei SLA.
Ai service level agreements del dominio viene assegnato un identificatore univoco
mediante la struttura SLAID, che contiene i seguenti campi:
•
provPeerID – ID Esperanto del peer che fornisce il servizio
•
reqPeerID – ID Esperanto del peer che richiede il servizio
•
functSignature – Firma della funzione offerta da dstPeer per la quale viene
raggiunto il service level agreeement
Poiché gli ID Esperanto dei peers, per come sono concepiti, sono univoci nella
core network, non possono sorgere ambiguità in merito ai peer riguardati dal
SLA. Inoltre utilizzando la signature anziché semplicemente il nome della
funzione invocata viene eliminata qualsiasi fonte d’ambiguità concernente la
funzione per la quale viene stabilito il SLA.
4.2.5.3 POLICY MANAGER
I compiti di quest’oggetto sono:
1. Fornire i valori correnti delle policies di dominio
2. Impostare nuovi valori per le policies di dominio
Le policies sono registrate in un file di configurazione locale allo SLA manager.
Tale file viene letto una sola volta al caricamento dello SLA manager e viene
aggiornato ogni qual volta il valore di una policy viene modificato.
•
L’impostazione delle policy avverrà tramite un opportuna interfaccia
amministrativa. I valori delle policies possono essere cambiati anche a
run-time, non influenzano infatti la configurazione del mediator (per cui
sarebbe
necessario
riavviare
lo
stesso),
ma
esclusivamente
i
comportamenti dinamici del controllo d’ammissione, l’assegnazione delle
classi di servizio, le operazioni di lettura sullo spazio di tuple ed i tempi di
permanenza delle stesse tuple nello spazio. La struttura interna del policy
137
Capitolo 4
manager è riportata in figura 4-5. Il policyManager offre funzioni per
leggere, impostare e salvare in maniera permanente le policies per il
dominio.
SLADataWrapper
+add()
+update()
+remove()
+get()
SLADB
«utilizza»
SLARepository
-QoSReqsTree : SLATree
PolicyManager
-policies : sequence<Policy>
+getPolicyValue(in policyName : string(idl)) : Policy
+setPolicyValue(in policy : Policy)
+savePolicies()
+addSLA(in prov : PeerID, in req : PeerID, in reqs : QoSReqs, in svcClass : string(idl)) : SLAID
+updateSLA(in agreeementID : SLAID, in svcClass : string(idl), in reqs : QoSReqs) : long(idl)
+removeSLA(in agreementID : SLAID) : long(idl)
+getSvcClass(in agreementID : SLAID) : string(idl)
+getReqs(in agreementID : SLAID) : QoSReqs
+restore() : long(idl)
«utilizza»
«utilizza»
Negotiator
-lnCDF(in mean : float(idl), in variance : float(idl), in x : long(idl)) : float(idl)
-lnCDFinv(in mean : float(idl), in variance : float(idl), in p : float(idl)) : long(idl)
+makeQosRequest(in srcPeerID : PeerID, in dstPeerID : PeerID, in reqs : QoSReqs)
+negotiateClass(in srcPeerID : PeerID, in dstPeerID : PeerID, in svcClass : string(idl), in reqs : QoSReqs)
+renegotiate(in SLA : SLAID, in svcClass : string(idl)) : SLAID
«utilizza»
Componente per il
monitoraggio delle risorse
SM Service
. Figura 4-5 – Diagramma delle classi completo per lo SLA Manager
4.2.6 La negoziazione di un SLA
In figura 4-6 viene riportato il diagramma d’interazione per la negoziazione di un
SLA inter-dominio.
Il peer1, hosted nel dominio A, specifica dei requisiti di qualità del servizio
nell’invocazione della funzionalità f, esposta da peer2, hosted nel dominio B.
Di seguito vengono descritti i diversi passi del processo di negoziazione di un
138
Capitolo 4
SLA:
1. Lo SLA Manager del dominio A interroga il sistema di monitoraggio (SM
Service) dello stesso dominio ed ottiene una snapshot relativa allo stato di
saturazione delle classi di servizio ed alle rispettive latenze nel dispatch
inter-dominio e nella scrittura di tuple provenienti da altri domini.
2. Una volta ottenuta la snapshot lo SLA manager interroga il Policy
Manager per conoscere i valori delle Policies SET_SERVICE_CLASS e
PREEMPTIVE
3. Viene invocato il metodo negotiateclass che utilizza la snapshot e la CDF
inversa per determinare, con la percentuale di successo specificata, quali
siano i tempi di latenza attesi nel dispatch.
4. Una volta individuata una classe di servizio in A viene invocato il metodo
makeQosRequest sullo SLA Manager del dominio B, nel quale si trova il
service provider. I requisiti richiesti al dominio B sono ottenuti sottraendo
dai requisiti richiesti da peer1 i tempi di servizio che il dominio A indica
di poter garantire con la classe di servizio scelta.
5. Lo SLA manager del dominio B invoca il SM Service locale per ottenere la
snapshot del dominio B
6. Lo SLA manager del dominio B invoca il Policy Manager locale per
ottenere i valori delle policies SET_SERVICE_CLASS e PREEMPTIVE
7. Viene invocato il metodo negotiateClass, che effettua il controllo
d’ammissione per la prima classe da valutare (GOLD o BRONZE,
secondo il valore di SET_SERVICE_CLASS). Se i requisiti possono
essere soddisfatti si va al passo successivo, altrimenti il metodo viene
eseguito con la prossima classe di servizio da esaminare; se non viene
trovata alcuna classe di servizio viene restituito il valore SLA_NO allo
SLA Manager del dominio A.
8. Una volta individuata una classe di servizio nel dominio B,l’identificativo
del SLA viene restituito al dominio A.
139
Capitolo 4
Figura 4-6 – Diagramma d’interazione per la negoziazione di un SLA inter-dominio
140
Capitolo 4
9. Una volta ottenuto l’identificativo del SLA nel dominio B, A può scrivere
il suo SLA (determinato al passo 3) nel repository locale utilizzando il
metodo addSLA. Se invece lo SLA manager del dominio B restituisce al
suo corrispettivo del dominio A il messaggio SLA_NO, lo SLA Manager
del dominio A può invocare il metodo negotiate_class con un classe di
servizio diversa e più performante, se disponibile e ripetere la procedura
dai passi 3 in poi. Nel caso in cui nel dominio A non ci fossero più classi
di servizio da analizzare, viene restituito un messaggio SLA_NO al peer 1
e la sua richiesta di QoS viene rifiutata.
4.3 Sistema di monitoraggio delle risorse
In questo paragrafo sarà affrontata la progettazione del componente deputato al
monitoraggio delle risorse, denominato System Monitoring Service (SM Service).
Tale componente raccoglie misure effettuate con tecniche differenti sui tempi di
latenza medi e sulla varianza di tali tempi per le operazioni di delivery delle tuple,
e sullo stato delle singole classi di servizio in termini di numero di richieste
contemporaneamente servite e dimensione della coda di richieste di servizio,
nonché su eventi che caratterizzano l’intero dominio, come la presenza di una
procedura di handover, mediante oggetti denominati System Conditions.
Tali misure vengono quindi raccolte ed integrate dagli Aggregators, cui si
interfacciano i componenti che, come lo SLA manager, utilizzano le snapshot
dello stato del dominio.
Il sistema di monitoraggio svolge anche un ruolo fondamentale nelle operazioni di
adaptation out-of-band, in quanto è in grado di notificare sia l’internal che
l’external contract, la cui progettazione sarà affrontata nel paragrafo successivo,
quando si registra una variazione nei dati sottoposti a monitoraggio.
Nel seguito di questo paragrafo verrà trattata separatamente la progettazione degli
elementi costituenti del System Monitoring Service (SM Service): le System
141
Capitolo 4
Conditions, deputate a misurare i valori elementari così come indicati nel
paragrafo 3.3.5, e gli Aggregators, che integrano i dati elementari raccolti dalle
System Conditions e mettono a disposizione una snapshot dello stato del dominio
Esperanto. La progettazione sarà ispirata al modello delle La progettazione sarà
ispirata al modello delle system conditions di QuO [BBN http] e [BBN 02] ed
utilizzerà elementi tratti dal framework ACE (Adpative Communication
Environment) [ACE http].
4.3.1 Rilevazione dei tempi di delivery delle tuple
Per determinare il valor medio e la varianza dei tempi di latenza di ogni classe di
servizio, ma anche di ogni interazione attiva nel dominio, così come descritto nel
paragrafo 3.3.5, è necessario fornire degli strumenti per una valutazione non
invasiva, nel senso che non richieda eccessive risorse (che potrebbero intaccare le
performance del mediator), dei tempi di dispatch e delivery delle tuple.
Con riferimento alla tabella 3-6, i tempi «elementari» nel delivery di una tupla
sono:
Interazioni locali
Request/Response
One-way
Solicit/response
Notify
LATRR=2TDIS+2TTM
LATOW=TDIS+TTM
LATSR=2TDIS+2TTM
LATN=TDIS+TTM
Interazioni remote
LATRR=TDIS1+TDIS2+TTM
Request/Response
LATOW=TDIS1
One-way
LATSR=TDIS2+TTM+TDIS1
Solicit/response
LATN=TDIS2+TTM
Notify
Tabella 4-1 – Latenza delle interazioni in funzione dei tempi elementari
•
TDIS – Latenza nel dispatch intra-dominio della tupla.
•
TDIS1 – Latenza nel dispatch inter-dominio.
142
•
Capitolo 4
TDIS2 – Latenza nella ricezione ed inoltro al tuple manager di una tupla
proveniente da un altro dominio.
•
TTM – Latenza nel tuple manager per il push della tupla al destinatario o
per la sua scrittura nello spazio.
Questi tempi «elementari», sommati tra loro come in tabella 4-1, forniscono poi i
tempi di latenza nel dominio, relativamente ad ogni paradigma di interazione
definito in Esperanto ed alla sua natura locale o remota.
La rilevazione dei tempi di dispatch e delivery delle tuple verrà effettuata
utilizzando un meccanismo basato su timestamp. I timestamp vengono apposti alle
tuple come delle «etichette» da parte dei componenti del mediator. La latenza di
un’operazione viene calcolata in base al timestamp della tupla in esame. Ad
esempio per un’operazione di dispatch intra-dominio, che viene misurato in TDIS,
il timestamp viene apposto quando la tupla viene letta dalla PDU nel bridge e
viene quindi utilizzato per determinare TDIS quando sta per essere trasmessa al
local tuple manager.Al fine di valutare in maniera efficace tali tempi elementari e
di non introdurre ulteriore overhead nella loro rilevazione bisogna tener conto
delle seguenti considerazioni:
•
I timestamp vengono assegnati dall’oggetto timestampManager (cfr.
diagramma delle classi in figura 4-8) mediante il metodo getTS e le misure
vengono memorizzate mediante i metodi update e updateWithTS. La
misura dell’intervallo di tempo trascorso è una misura, necessariamente
approssimata, del particolare tempo elementare valutato.
Figura 4-7 – Tempi effettivi di esecuzione delle operazioni e loro misura
143
Capitolo 4
Se l’operazione di assegnazione del timstamp viene avviata all’istante T1,
il timestamp verrà effettivamente assegnato all’istante T1+∆T’ e
l’operazione della quale si vuole misurare il tempo di latenza partirà
all’istante T1+∆T’’; inoltre, se tale operazione termina all’istante T2, la
misurazione verrà effettuata all’istante T2+∆T’’’, come mostrato in figura
4-7. I delay ∆T’,∆T’’, ∆T’’’ sono dovuti all’attraversamento dei livelli
sottostanti i componenti del mediator e del sistema di monitoraggio.
La latenza misurata è dunque sempre superiore alla latenza effettiva di
esecuzione dell’operazione. La misurazione introduce dunque overhead
nell’esecuzione dell’operazione (∆T’+∆T’’) ed errore nella misurazione
(∆T’’ + ∆T’’’). Se l’errore relativo non è eccessivo, lo si può tollerare, in
considerazione del fatto che fornisce una stima in eccesso della latenza
(fornire una stima in difetto della latenza sarebbe stato invece molto
pericolo). L’overhead introdotto invece deve essere minimizzato a tutti i
costi, in quanto è intollerabile che la misurazione del delivery di una tupla
infici sensibilmente i tempi di delivery stessi.
•
E’ indispensabile che i timestamp vengano assegnati da un’unica entità
all’interno di ogni dominio, e che questa stessa entità si occupi di calcolare
gli intervalli trascorsi valutando gli stessi timestamps precedentemente
assegnati.
•
Quando, dato un timestamp precedentemente assegnato, viene calcolato
uno dei sopraelencati tempi elementari, bisogna poter aggiornare le
System Conditions interessate da tale misura.
Fatte tali si considerazioni, il sistema di rilevazione dei tempi elementari delineati
al capitolo precedente sarà concepito come indicato nel diagramma delle classi
riportato in figura 4-8.
La classe TimestampManager si occupa di generare i timpestamps e compiere
l’aggiornamento delle System Conditions su richiesta dei componenti del
mediator.
144
Capitolo 4
In tal modo si cerca di ridurre l’overhead di comunicazione ed elaborazione nei
componenti del mediator dovuto alla misurazione dei tempi di latenza. L’utilizzo
di una versione non bloccante della funzione update separa il task di
aggiornamento della SystemCondition dalle normali operazioni di dispatch e
delivery effettuate nel mediator.
Figura 4-8 – Struttura del timestampManager
In tabella 4-2, relativamente ad ognuno dei valori elementari misurati, si riportato
i punti di inizio e fine delle misurazioni temporali.
Tempo «elementare»
TDIS
TDIS1
TDIS2
TTM
Inizio misurazione
Fine Misurazione
Ricezione di una
tupla nel bridge
Ricezione di una
tupla nel bridge
Ricezione di una tupla nel
dispatcher proveniente da
altro dominio
Inoltro della tupla al tuple
manager locale
Ricezione della tupla nel
dispatcher del dominio remoto
Ricezione di una tupla da
scrivere sul tuple manager
locale
Inoltro della tupla al tuple
manager locale
Push della tupla verso il
device o recupero della stessa
mediante operazione di lettura
sullo spazio
Tabella 4-2 – punti di inizio e termine delle misurazioni
La misurazione dei tempi di dispatch inter-dominio merita un discorso a parte.
Data una qualsiasi interazione inter-dominio che coinvolge due generici domini
D1 e D2, si sceglie di misurare con TDIS1 la latenza di dispatch inter-dominio dal
bridge del dominio D1 fino all’arrivo della tupla al dispatcher del dominio D2,
145
Capitolo 4
mentre TDIS2 misurerà il tempo di dispatch di una tupla ricevuta dal dominio D2
fino all’inoltro sul tuple manager locale.
Tale scelta viene effettuata tenendo conto delle seguenti considerazioni:
1. Se si include tale latenza nel contributo TDIS1 il timestamp viene assegnato
nel dominio D1, per cui il dispatcher di D2 dovrebbe avere una reference al
timestampManager di D1. Una volta che il timestamp, generato in D1, è
stato ottenuto dal dispatcher del dominio D1, viene avviata l’operazione
da misurare; il timestamp viene poi letto dalla tupla ed utilizzato per
effettuare la misura in D2 (invocando il timestampManager di D1).
L’operazione viene effettivamente avviata dopo un intervallo ∆T’+∆T’’
relativamente contenuto in quanto si opera sul timestampManager locale
2. Se si include tale latenza nel contributo TDIS2 il timestamp viene assegnato
nel dominio D2, per cui il dispatcher di D1 dovrebbe avere una reference al
timestampManager di D2. Una volta che il timestamp, generato in D2 è
stato ottenuto dal dispatcher del dominio D1, viene avviata l’operazione
da misurare; il timestamp viene poi letto dalla tupla ed utilizzato per
effettuare la misura in D2 (invocando il timestampManager locale).
L’assegnazione del timestamp, operazione necessariamente bloccante,
richiede l’attraversamento del collegamento di rete tra i domini e quindi
l’intervallo ∆T’+∆T’’ è decisamente superiore a quello che si avrebbe
adottando la soluzione (1).
4.3.2 Le System Conditions
Come anticipato nel capitolo precedente, gli oggetti System Conditions raccolgono
dati «elementari», che poi vengono utilizzati dagli aggregatori per determinare la
snapshot dello stato del sistema, come descritto nello snapshot pattern [LOYAL
01].
Tali oggetti hanno anche la responsabilità di notificare ai contratti eventuali
variazioni riscontrate nelle condizioni del sistema. In tal modo questi ultimi
146
Capitolo 4
potranno, verificare se si siano verificate transizioni di regione, ed applicare gli
opportuni comportamenti adattativi.
Un’oggetto System Condition può monitorare i tempi di esecuzione o contare il
numero di invocazioni di un metodo, valutare informazioni di basso livello come
il livello di carico corrente del processore o il numero di thread attivi, oppure può
semplicemente recuperare valori impostati da qualche altro oggetto, o ancora può
effettuare un polling con una certa frequenza su una data risorsa o oggetto ed
aggiornare il valore memorizzato.
In figura 4-9 è riportato il diagramma delle classi «base» per gli oggetti System
Condition che effettueranno il monitoraggio della QoS in Esperanto.
•
Classi value,valueLong e valueDouble – non fanno altro che memorizzare
un valore. La classe value è puramente astratta, mentre le classi valueLong
e valueDouble memorizzano rispettivamente un valore intero lungo ed un
valore in virgola mobile a doppia precisione.
•
Classe SysCondValue – è il più semplice degli oggetti System Condition.
Memorizza il valore della grandezza osservata. Se dopo l’aggiornamento
del valore memorizzato si registra una variazione maggiore della soglia di
thresold, allora viene inviata una notifica a tutti gli osservatori (che
implementano la classe astratta Observer), che si trovano nella lista degli
Observables.
•
Classe Observables - gestisce un elenco di Observer. E’ una classe base
per tutte gli oggetti System Conditions. Fornisce i metodi per notificare
agli observer la variazione dei valori monitorati.
•
Classe Observer – E’ una classe astratta. Tutti gli oggetti che vorranno
essere notificati circa la variazione dei valori controllati dalle System
Conditions dovranno ereditare da questa classe ed implementare il metodo
update.
•
Classi SysCondMonitor e Task – Specializzano il SysCondValue
aggiungendogli funzioni di polling. La classe è astratta, ed il modo in cui
147
Capitolo 4
viene calcolato ed eventualmente aggiornato il valore monitorato dipende
dall’implementazione del metodo poll. Il polling viene eseguito ad una
frequenza specificata attraverso il metodo setRate. Le operazioni di polling
vengono gestite mediante la ridefinizione dei metodi della classe Task, che
fornisce un supporto per l’esecuzione dell’oggetto in un thread separato.
Observables
-changed : boolean(idl)
#setChanged()
#clearChanged()
+addObserver(in o : Observer)
+deleteObserver(in o : Observer)
+countObservers() : long(idl)
+notifyObservers(in a : any(idl))
+hasChanged() : boolean(idl)
Value
1
+getLong() : long(idl)
+setLong(in x : long(idl))
+getDouble() : double(idl)
+setDouble(in x : double(idl))
ValueLong
ValueDouble
-l : long(idl)
-d : double(idl)
+getLong() : long(idl)
+setLong(in x : long(idl))
+getDouble() : double(idl)
+setDouble(in x : double(idl))
*
«metaclasse»
Observer
1
*
+update()
SysCondValue
-name : string(idl)
-thresold : float(idl)
#setValue() : Value
#notify()
+getName() : string(idl)
+setName(in n : string(idl))
+getValue() : Value
+init() : Value
+setThresold(in t : float(idl))
+getThresold() : float(idl)
Task
+open()
+close()
+svc()
SysCondMonitor
-isPolling : boolean(idl)
-pollRate : double(idl)
+open()
+close()
+svc()
+poll()
+setRate(in r : double(idl))
Figura 4-9 – Strutturazione delle classi degli oggetti System Condition
Utilizzando tale approccio risulta molto più semplice progettare e sviluppare le
classi relative agli oggetti System Condition che saranno utilizzati nel System
Monitoring Service di Esperanto. Inoltre tale struttura può essere riutilizzata per
implementare nuove tipologie di oggetti System Condition allorquando si dovesse
rendere necessario estendere o adattare il System Monitoring Service.
Riepilogando vengono esclusivamente definiti 2 tipi di oggetti System Condition:
•
Valore (SysCondValue) – per memorizzare un qualsiasi valore di una
classe ereditata da value.
148
•
Capitolo 4
Monitor (SysCondMonitor) – per memorizzare valori con tecniche di
polling
4.3.2.1 MEDIA E VARIANZA DELLA LATENZA PER LE CLASSI DI SERVIZIO
Tali oggetti System Conditions calcolano la media e la varianza dei tempi
«elementari» di latenza TDIS,TDIS1,TDIS2,TTM per ognuna delle tre classi di servizio
definite nel capitolo precedente: GOLD, SILVER e BRONZE.
Come anticipato nel capitolo precedente, la media e la varianza hanno una
memoria limitata, in modo tale da eliminare gli effetti di misurazioni ormai datate.
I campioni (misurazioni dei quattro tempi elementari) per il calcolo di queste due
grandezze vengono forniti dal timestampManager a seguito di invocazioni del
metodo update o updateWithTS.
Ad ogni nuovo campione misurato viene dato peso 1/N, ed al valore precedente
della media (varianza) viene dato peso (N-1)/N, dove N è la «lunghezza» della
memoria della media e della varianza. Se il numero di campioni analizzato è
minore di N allora, detto n il numero di campioni considerati sino all’istante
corrente, ad ogni nuovo campione misurato viene dato peso 1/n, ed al valore
precedente della media (varianza) viene dato peso (n-1)/n.
xn+1
1
⎧n −1
x
+
xn+1 n < N
n
⎪⎪ n
n
=⎨
⎪N −1 x + 1 x n ≥ N
⎪⎩ N n N n+1
VAR( x) n+1
1
⎧n −1
VAR
x
(
)
( xn+1 − xn+1 ) 2 n < N
+
n
⎪⎪ n
n
=⎨
⎪ N − 1 VAR( x) + 1 ( x − x ) 2 n ≥ N
n
n +1
n +1
⎪⎩ N
N
Si noti che il calcolo della varianza per il campione n+1 richiederebbe la
conoscenza della media per il campione n. Se l’aggiornamento delle System
Conditions avviene in maniera asincrona rispetto alle operazioni del
timestampManager, com’è auspicabile che sia per motivi di efficienza, tale valore
149
Capitolo 4
non sarà ancora noto quando si andrà ad aggiornare la varianza. Si accetterà
l’errore commesso sostituendo x n +1 con x n , che può essere ricavato interrogando
la System Condition che mantiene il valor medio per una data classe.
Vengono pertanto definite le classi SysCondValueMean e SysCondValueVar
(descritte nel diagramma delle classi di figura 4-10) che ereditano dalla classe
SysCondValue e realizzano le tipologie di System Condition SC1 e SC2 descritte
nel paragrafo 3.3.5.
Figura 4-10 – classi System Condition per il calcolo della media e della varianza
Le istanze di queste due classi che saranno impiegate nella determinazione della
media e della varianza per le diverse classi di servizio, verranno utilizzate dallo
SLA Manager. Mediante i metodi calcNewMean e calcNewVar, utilizzati da
setValue, si aggiornano la media e la varianza corrente. A lunghezza della
memoria nel calcolo della media viene regolata mediante il metodo
setMemLength.
Al fine di effettuare il monitoraggio della media e della varianza delle latenze nel
mediator relative alle invocazioni di metodi tra requestors e providers
relativamente alle singole classi di servizio, va istanziato un’oggetto
SysCondValueMeand ed un oggetto SysCondValueAvg per ogni tempo elementare
150
Capitolo 4
misurato e per ogni classe di servizio.
4.3.2.2 MEDIA DELLA LATENZA PER LE SINGOLE INTERAZIONI
Il monitoraggio dei tempi medi di latenza relativi alle intere classi di servizio non
è sufficiente per individuare singole interazioni le cui latenze osservate eccedono i
limiti stabiliti dal service level agreement. E’ dunque indispensabile utilizzare
delle System Conditions che si occupino di monitorare le singole interazioni ed
attivare, nel caso i SLA non siano più rispettati, opportune misure adattative.
L’alimentazione di tali System Conditions anche in questo caso viene effettuata
dal timestampManager.
Per la misurazione delle latenze delle singole interazioni verranno utilizzate delle
medie. Calibrando opportunamente la scelta della lunghezza della memoria della
media si può ottenere un buon trade-off tra reattività e insensibilità alle
fluttuazioni temporanee delle latenze osservate. Nel seguito di questo lavoro si
assumerà un valore N’ per tale lunghezza, ma l’utilizzo di un valore variabile in
funzione della percentuale di successo richiesta dal peer rappresenta un ottimo
spunto per futuri sviluppi.
Le System Conditions deputate al monitoraggio delle latenze per ogni interazioni
saranno istanze della classe SysCondMeanValueInt, rappresentata in figura 4-11,
che eredita da SysCondValueMean e realizza la tipologia di System Condition SC3
descritta nel paragrafo 3.3.5. In questo caso è di fondamentale importanza il
thresold impostato sulla variazione del valore memorizzato nella SysCond. Se
infatti la variazione percentuale della media misurata supera la soglia impostata,
scatta la notifica all’external Contract, che è l’unico oggetto incluso nella lista
degli Observables (cfr. figura 3-7).
Figura 4-11 – classe SysCondValueMeanInt
151
Capitolo 4
Il metodo setSLAID viene utilizzato per distinguere tra loro le System Condition
relative alle diverse interazioni.
Per
ogni
interazione
vanno
istanziate
4
System
Conditions
di
tipo
SysCondValueMean, per monitorare le latenze TDIS,TDIS1,TDIS2,TTM relative ad
ogni singola interazione. Il numero di System Conditions relative alla valutazione
delle latenze per le singole invocazioni è dunque variabile nel tempo ed è
direttamente proporzionale al numero di SLA attualmente attivi nel dominio.
4.3.2.3 MONITORAGGIO DELLO STATO DELLE SINGOLE CLASSI DI SERVIZIO
La natura di tale oggetto System Condition è diversa da quelle analizzate
precedentemente.
Il suo compito è infatti quello di monitorare informazioni relative ai livelli
sottostanti i componenti del mediator che garantiscono la predictability nel
delivery delle tuple attraverso le classi di servizio GOLD, SILVER e BRONZE.
Anzichè istruire i componenti del mediator affinché esplicitamente aggiornino tali
valori si preferisce utilizzare tecniche di polling. La System Condition stessa, con
una data frequenza, rileva il valore desiderato ed aggiorna il proprio valore.
Nel System Monitoring service vengono definite due tipi di tali System Condition:
•
SysCondMonitorAvgReq – per valutare il numero medio di richieste
contemporanee servite da ogni classe di servizio. Sono utilizzate
dall’aggregator che fornisce allo SLA Manager una snapshot dello stato
attuale del dominio e dall’Internal Contract. Realizza la tipologia di
System Condition SC4 descritta nel paragrafo 3.3.5
•
SysCondMonitorAvgQueue – per valutare la lunghezza media delle
richieste in coda per ogni classe di servizio. Segnalano all’internal
contract il sorgere di situazioni critiche per le classi di servizio, affinché
vengano adottate le misure opportune per disciplinare la sottomissione di
richieste alle diverse classi di servizio. Realizza la tipologia di System
Condition SC5 descritta nel paragrafo 3.3.5
Anche in questo caso per la memorizzazione dei valori si fa ricorso a medie con
152
Capitolo 4
memoria come trade-off tra la reattività del sistema e l’isolamento di fluttuazioni
temporanee nei valori misurati.
Entrambe
le
SystemConditions
sono
definite
in
classi
derivate
da
SysCondMonitor, descritta precedentemente e riportata in figura 4-7. Il
diagramma delle classi per SysCondMonitorAvgReq e SysCondMonitorAvgQueue
è riportato in figura 4-12.
SysCondMonitor
-isPolling : boolean(idl)
-pollRate : double(idl)
+open()
+close()
+svc()
+poll()
+setRate(in r : double(idl))
SysCondMonitorAvgReq
SysCondMonitorAvgQueue
#calcNewMean() : long(idl)
+getMemLength() : long(idl)
+setMemLenght(in l : long(idl))
+poll()
#calcNewMean() : long(idl)
+getMemLength() : long(idl)
+setMemLength(in l : long(idl))
+poll()
Figura 4-12 – classi per il monitoraggio dello stato delle classi di servizio
Le istanze della classe SysCondMonitorAvgQueue
utilizzano il thresold
impostato sulla variazione del valore memorizzato nella SysCond per notificare
eventuali variazioni osservate all’internal Contract, che è l’unico oggetto incluso
nella lista degli Observables (cfr. figura 3-7).
Il metodo poll viene ridefinito in ognuna della due classi per adempiere,
utilizzando API messe a disposizione dall’ORB sottostante i componenti del
mediator e del SM Service, alla misurazione del particolare valore. Per la classe
misurerà
il
numero
medio
di
richieste
contemporaneamente servito, mentre per la classe SysCondMonitorAvgQueue
misurerà la dimensione media della coda di richieste (che nel caso ideale è nulla).
Per ogni classe di servizio esisterà un’istana di SysCondMonitorAvgReq ed
un’istanza di SysCondMonitorAvgQueue. In totale si avranno dunque 6 istanze di
153
Capitolo 4
System Conditions deputate al monitoraggio dello stato delle classi di servizio.
4.3.2.4 RILEVAZIONE DEGLI HANDOVER
L’handover rappresenta un fenomeno potenzialmente critico per l’equilibrio dei
SLA stabiliti nel dominio. Un’handover infatti, oltre a determinare un picco di
traffico transitorio dovuto al trasferimento di tutte le interazioni dal vecchio al
nuovo
dominio,
varia
inevitabilmente,
in
maniera
più
o
meno
consistente,l’equilibrio del dominio nel quale il device roamer entra: dovranno
infatti essere gestite nuove interazioni, molte delle quali potranno avere specifici
requisiti di qualità del servizio, che lo SLA Manager del dominio dovrà cercare di
garantire, evitando, per quanto possibile di interferire con i SLA preesistenti.
E’ dunque fondamentale che i componenti addetti alla gestione della qualità del
servizio nel dominio siano in grado di individuare il verificarsi di handover e
comportarsi di conseguenza. Come si vedrà nel successivo paragrafo 4.4, la
gestione dell’handover implica sia meccanismi di out-of-band adaptation che di
in-band-adaptation.
E’ possibile che mentre si sta gestendo un handover si verifichi un nuovo
handover, con un nuovo roamer che entra nel dominio o con un device che migra
verso un nuovo dominio. Nel primo caso l’handover comporterà la scrittura di un
certo numero di tuple sul tuple manager locale, mentre nel secondo caso
comporterà la lettura di un certo numero di tuple dal tuple manager locale.
La SystemCondition per gestire gli handover, SysCondValueHandover ha una
struttura molto semplice. Deriva dalla classe SysCondValue e ridefinisce
semplicemente il metodo setValue: un valore positivo come parametro aumenta di
1 il valore memorizzato, un valore negativo diminuisce di 1 il valore
memorizzato.
SysCondValueHandover realizza la tipologia di System Condition SC6 descritta
nel paragrafo 3.3.5 e memorizza il numero di handover attualmente in corso nel
dominio.
Per segnalare le situazioni di handover sono dunque necessarie due istanze di
SysCondValueHandover: una per tener traccia del numero di device in ingresso
154
Capitolo 4
nel dominio (parametro HIN definito nel capitolo 3) ed una per tener traccia del
numero di device in uscita dal dominio ((parametro HOUT definito nel capitolo 3).
4.3.3 Gli Aggregators
I dati raccolti dalle System Conditions, devono essere integrati ed aggregati al fine
di poter fornire le snapshot dello stato del sistema allo SLA Manager, che le
utilizzerà per effettuare il controllo d’ammissione, ed all’external contract che le
utilizzerà per effettuare il policing (cfr. Cap.1, par.1.3.5) delle diverse interazioni
con requisiti di QoS attive nel dominio.
L’internal contract invece, come apparirà evidente nel paragrafo 4.4, utilizzerà
direttamente le informazioni provenienti dalle SystemConditions.
Gli aggregators utilizzano un certo numero di istanze di System Conditions e
calcolano la snapshot interrogando il valore memorizzato nella System Condition
stessa e rielaborando i valori forniti dalle System Conditions al fine di presentare
un risultato relativo ad aspetti di QoS di più alto livello.
Nel System Monitoring Service vengono definiti due aggregators:
•
AggSLAManager – fornisce la snapshot che lo SLA Manager utilizza per
effettuare il controllo d’ammissione e per verificare la soddisfacibilità dei
requisiti di QoS specificati.
•
AggExtContract - fornisce all’external contract la snapshot dello stato di
una particolare interazione che viene utilizzata da questo per effettuare il
policing delle varie interazioni.
La struttura delle classi che descrive i due aggregators è riportata in figura 4-13.
Mentre AggSLAManager determina la snapshot in base ai valori delle SysCond
relative alle classi di servizio, AggExtContract utilizza le SysCond relative alle
singole interazione. Come ricordato precedentemente, tali System Conditions
vengono create quando si stabilisce un SLA per un’interazione e vengono distrutte
insieme a tale SLA.
155
Capitolo 4
Al fine di poter gestire una realtà così mutevole, AggExtContract utilizza una
sequenza di SysCond. Ogni System Condition relativa ai tempi medi per la singola
interazione viene inserita in tale sequenza quando viene creato il SLA ed
eliminata da tale sequenza quando il SLA viene rimosso.
Figura 4-13 – Aggregators per il calcolo delle snapshot
Ogni aggregator fornisce metodi distinti per calcolare le snapsthot relative a
ciascun paradigma d’interazione. Per tale motivo vengono definiti i metodi
getSnapshottRR, getSnapshotOW, getSnapshotSR, getSnapshotN.
Per la classe AggSLAManager ognuno di questi metodi accetta come parametro
una classe di servizio ed un parametro, denominato locale, che risulta 0 se viene
richiesta una snapshot per interazioni remote, mentre risulta diverso da 0 se viene
richiesta una snasphot per interazioni intra-dominio.
Per la class AggExternalContract ognuno di questi metodi accetta come
parametro un identificativo di service level agreement (che può essere anche
recuperato dallo SLA Manager). L’aggregator restituisce la media dei tempi di
delivery relativi all’interazione selezionata ed alla tipologia di interazione scelta.
Se l’interazione in oggetto è remota vengono restituiti esclusivamente i valori
medi relativi all’interazione nel dominio nel quale si trova l’aggregator.
156
Capitolo 4
Figura 4-14 – Struttura interna ed interfacce del SM Service
157
Capitolo 4
4.3.4 Struttura del System Monitoring Service
La struttura completa del System Monitoring Service, con le relative interfacce
esposte verso lo SLA Manager, e verso i contratti è mostrata in figura 4-14.
Non vengono mostrate in dettaglio tutte le istanze di System Conditions al fine di
non complicare la struttura del diagramma. L’interfaccia verso l’internal contract
fornisce un’astrazione allo stesso per accedere direttamente ai valori mantenuti
negli
oggetti
System
Conditions
di
tipo
e
4.3.5 Misurazione delle latenze
In figura 4-15 viene riportato il diagramma d’interazione per le operazioni di
misurazione della latenza «elementare» TDIS (tempo di dispatch intra dominio di
una tupla, dalla ricezione nel bridge sino all’inoltro sul tuple manager locale), per
la classe di servizio GOLD. Il discorso si ripete similmente per gli altri tempi
elementari e le altre classi di servizio.
La procedura avviene nei seguenti passi:
1. Il bridge riceve una tupla. Non sa ancora se sia destinata al tuple manager
locale o ad un dominio remoto. Richiede comunque un timestamp al
timestampmanager.
2. Se il timestamp viene restituito questo viene inserito nella tupla stessa,
altrimenti la tupla viene inviata senza timestamp. La tupla viene quindi
inoltrata al dispatcher.
3. Il dispatcher effettuate le sue operazioni di routine, si rende conto che la tupla
è destinata al tuple manager locale. Prima di avviare le operazioni di delivery,
se nella tupla è presente un timestamp, invoca il timestampmanager per
registrare la misurazione di TDIS.
4. Il timestampManager, una volta invocato il metodo update calcola l’intervallo
temporale trascorso tra l’assegnazione del timestamp e l’istante corrente
158
Capitolo 4
Figura 4-15 – Diagramma d’interazione per la misurazione di TDIS
159
Capitolo 4
5. Viene aggiornata la media della classe di servizio GOLD invocando il metodo
setvalue.
6. La SystemCondition della media utilizza calcNewMean per aggiornare la
media
7. Viene aggiornata la varianza della classe di servizio GOLD invocando il
metodo setvalue.
8. La SystemCondition della varianza utilizza calcNewVar per aggiornare la
varianza
9. Viene invocata la sequence delle System Conditions che mantengono le medie
delle singole interazioni
10. Viene aggiornata la media di TDIS per la specifica interazione (indicata con il
parametro SLA).
Gli aggiornamenti delle System Conditions, avvengono asincronamente rispetto
alle operazioni del timestampManager. In questo modo il dispatcher può
continuare a lavorare mentre le System Conditions aggiornano le proprie medie e
varianze ed eventualmente inviano notifiche ai contratti.
4.4 Out-of-band ed in-band adaptation nel mediator
Finora sono stati trattati principalmente gli aspetti statici della qualità del servizio
(descritti al par. 1.3.4), ovvero la specifica della QoS, la negoziazione ed il
controllo d’ammissione. Il componente SM Service introduce gli oggetti System
Condition, che, ereditando dalla classe Observables (cfr. fig. 4-9), possono
notificare variazioni nel valore memorizzato, e quindi nello stato del sistema. Il
sistema di monitoraggio verrà utilizzata per fornire un’immagine dello stato del
sistema allo SLA Manager per effettuare il controllo d’ammissione (cfr. paragrafi
3.3.3,3.4.2 e 4.2) ed ai componenti adattativi, che si occupano della gestione
dinamica della QoS, così come descritta al paragrafo 1.3.5.
Nel corso di questo paragrafo verrà approfondita la progettazione dei componenti
che saranno deputati alla realizzazione di out-of-band adaptation ed in-band
160
Capitolo 4
adapatation all’interno del mediator. In primo luogo verrà esaminata la struttura
generica di un contratto, che applica il contract pattern descritto nel paragrafo
3.3.6. Verrà quindi descritto il funzionamento dell’internal contract, che valuta lo
stato attuale del mediator applicando il contract pattern descritto al paragrafo
3.3.6, e viene utilizzato sia per l’adattatività out-of-band che in-band. Verrà
quindi descritto il funzionamento dell’external contract, che valuta lo stato delle
singole interazioni attive all’interno del mediator e viene utilizzato per attività di
policing e rinegoziazione.
Verrà quindi affrontata la progettazione del Quality Manager, che viene utilizzato
dall’internal contract per effettuare le attività di manutenzione della qualità del
servizio, che, come descritto nel paragrafo 1.3.5, implica una modifica dei
parametri del sistema per garantire la QoS richiesta.
Infine verrà presa in considerazione l’adattatività in-band e si analizzerà un suo
potenziale utilizzo sia nel delivery delle tuple che nella gestione degli handover.
4.4.1 Struttura di un contratto
Un contratto specifica le regioni operative indicanti i possibili livelli misurati di
QoS, e le azioni da intraprendere quando si verificano variazioni nei livelli di
QoS. Le regioni vengono determinate calcolando dei predicati sulle System
Conditions collegate al contratto, così come descritto nel capitolo precedente.
Il diagramma delle classi riportato in figura 4-16 mostra l’organizzazione delle
classi relative ai contratti, alle regioni ed alle transizioni tra regioni. Tale struttura
è tratta da quella descritta in [BBN http].
•
Le transizioni (classe transition) contengono un riferimento alla regione di
partenza (regionFrom) ed alla regione di arrivo (regionTo), nonché un
riferimento ad un oggetto della classe transitionCode, che viene gestito
mediante i metodi getCode e setCode. La classe transitionCode
implementa il codice che effettua la vera e propria azione adattativa
associata ad una transizione di regione mediante il metodo work.
161
•
Capitolo 4
Le regioni (classe region) sono organizzate in una struttura gerarchica ad
albero. Una regione è caratterizzata da una regione parent e da una o più
regioni children ed è collegata ad un contratto (classe contract). La classe
regionSeq è semplicemente una lista di regioni.
o Per ogni regione il metodo evalPredicate valuta il predicato
associato alla regione, che è un’espressione booleana su un insieme
di valori misurati dalle System Conditions, e se vero indica che la
regione corrispondente è attiva. Affinché sia vero il predicato di
una regione deve essere vero anche il predicato della regione di cui
è figlia.
o Il metodo evaluate viene invece invocato ricorsivamente dal
contratto cui la regione è collegata ed avvia le specificate negli
attributi entering e leaving quando si verifica una variazione di
regione. Le transizioni da applicare sono selezionate dal metodo
privato loopOverFromTo, che, data la regione di partenza e la
regione di arrivo nella transizione, avvia le opportune transizioni
dall’insieme leaving nella vecchia regione corrente del contratto e
le opportune transizioni dall’insieme entering nella nuova regione
corrente del contratto.
o I
metodi
setEntering,
setLeaving,
getEntering,
getLeaving
consentono di gestire tutte le transizioni associate ad una regione.
o I metodi setChildren, isRoot, isLeaf invece vengono utilizzati per
gestire la struttura gerarchica delle regioni.
•
Un contratto eredita dalla classe astratta Observer e ridefinisce il metodo
virtuale update di questa classe. Un contratto può pertanto ricevere
notifiche dalle System Conditions associate.
o Il metodo setRootRegion imposta la radice della gerarchia delle
regioni per il contratto. Le regioni di funzionamento potranno poi
essere aggiunte utilizzando gli appositi metodi della classe regioni.
162
Capitolo 4
o Il metodo getCurrentRegions viene utilizzato per restituire la
regioni di funzionamento correntemente attive. In un dato istante
possono infatti risultare attive più regioni e durante la valutazione
di un contratto possono verificarsi quindi anche più transizioni.
Tali informazioni vengono utilizzate dal metodo eval e componenti
che effettuano in-band adaptation.
o Il metodo update viene invocato da una System Condition quandov
viene rilevata una variazione nel valore osservato. Viene quindi
invocato il metodo eval .
o Il metodo eval svolge le seguenti attività:

A partire dai valori delle System Conditions collegate al
contratto, determina la snapshot dello stato del sistema.

Avvia la valutazione dei predicati e l’esecuzione delle
transizioni per ogni regione, invocando il metodo evaluate
su ogni regione definita.

Aggiorna la regione corrente del contratto.
In tal modo ogni volta che una System Condition contenuta nel System Monitoring
Service rileva una variazione sensibile nel valore osservato sollecita la
rivalutazione del contratto. Se tale attività porta ad una transizione di regione,
durante la rivalutazione stessa vengono avviate tutte le transizioni necessarie.
Le effettive azioni intraprese nella transizione sono codificate nel metodo work
della classe transitionCode. Ridefinendo tale metodo è possibile effettuare
un’operazione durante una transizione. Tale schema, come già ricordato nel
capitolo 3, rappresenta un’applicazione del command pattern definito in [SCHM
00b].
La definizione di un contratto può quindi essere scomposta nelle seguenti attività:
•
Individuare un insieme di oggetti System Conditions da utilizzare per
ottenere la snapshot dello stato del sistema.
•
Definire la struttura delle regioni operative del contratto.
163
Capitolo 4
•
Definire di un predicato di valutazione per ogni regione.
•
Individuare le possibili transizioni tra regioni che devono essere
controllate da comportamenti adattativi.
•
Definire le azioni da intraprendere in ogni transizione individuata
•
Collegare le transizioni alle regioni.
Figura 4-16 – Diagramma delle classi per la struttura di un contratto
4.4.2 Definizione dell’Internal Contract
L’internal contract ottimizza l’utilizzo delle tre classi di servizio (GOLD,
SILVER, BRONZE) attraverso le quali avvengono le operazioni di delivery delle
tuple e fornisce informazioni ai componenti che effettuano in-band adaptation
circa la presenza di procedure di handover. Per il monitoraggio dello stato delle
classi di servizio vengono prese in considerazione le System Conditions di tipo
SysCondMonitorAvgReq, SysCondMonitorAvgQueue, mentre per il monitoraggio
delle situazioni di handover vengono prese in considerazione le System
Conditions di tipo SysCondValueHandover. In totale vengono prese in
164
Capitolo 4
considerazione 8 System Conditions, esposte dal System Monitoring Service
nell’interfaccia iToInternalContract, riportata in figura 4-14. Le istanze di tali
oggetti System Condition che saranno collegate al contratto sono riportate in
tabella 4-3. Ad ogni System condition è stato attribuito un nome mnemonico.
Nome System Condition
Tipo
AvgGOLDReq
AvgSILVERReq
AvgBRONZEReq
AvgGOLDQueue
AvgSILVERQueue
AvgBRONZEQueue
HIn
SysCondValueHandover
Hout
Valore misurato
Numero medio di richieste
contemporaneamente servite per
la classe GOLD
la classe SILVER
la classe BRONZE
Numero medio di richieste in
coda per la classe GOLD
coda per la classe SILVER
coda per la classe BRONZE
Numero di handover dovuti a
roamer in ingresso nel dominio
in corso
Numero di handover dovuti a
roamer in uscita nel dominio in
corso
Tabella 4-3 – System Conditions utilizzate dall’internal contract
Le regioni dell’internal contract sono determinate in base ai possibili stati delle
classi di servizio del mediator ed alle situazioni di handover nel dominio. Viene
quindi definita la seguente struttura per le regioni (riportata schematicamente nella
figura 4-17):
STANDARD – nel dominio corrente non sono attualmente in corso procedure
di handover
o GOLD_NORMAL_RESOURCES – La classe di servizio GOLD
viene pienamente utilizzata, ma le richieste vengono tutte
soddisfatte immediatamente.
o SILVER_NORMAL_RESOURCES – La classe di servizio
SILVER viene pienamente utilizzata, ma le richieste vengono tutte
soddisfatte immediatamente.
165
Capitolo 4
o BRONZE_NORMAL_RESOURCES - La classe di servizio
BRONZE viene pienamente utilizzata, ma le richieste vengono
tutte soddisfatte immediatamente.
o GOLD_LOW_RESOURCES – Alcune richieste per la classe
GOLD devono essere messe in coda.
o SILVER_LOW_RESOURCES - Alcune richieste per la classe
SILVER devono essere messe in coda.
o BRONZE_LOW_RESOURCES - Alcune richieste per la classe
BRONZE devono essere messe in coda.
o GOLD_CRITICAL – La dimensione della coda di richieste per la
classe GOLD ha raggiunto dimensioni considerevoli
o SILVER_CRITICAL - La dimensione della coda di richieste per la
classe SILVER ha raggiunto dimensioni considerevoli
o BRONZE_CRITICAL - La dimensione della coda di richieste per
la classe BRONZE ha raggiunto dimensioni considerevoli
INGOING_HANDOVER – almeno un device roamer sta entrando nel
dominio
o NORMAL_RESOURCES – tutte le classi possono servire
richieste
o GOLD_LOW_RESOURCES – la classe di servizio GOLD è satura
o GOLDSILVER_LOW_RESOURCES – le classi di servizio
GOLD e SILVER sono sature
o GOLDSILVERBRONZE_LOW_RESOURCES – tutte le classi di
servizio sono sature
OUTGOING_HANDOVER
o NORMAL_RESOURCES – tutte le classi possono servire
richieste
o GOLD_LOW_RESOURCES – la classe di servizio GOLD è satura
o GOLDSILVER_LOW_RESOURCES – le classi di servizio
GOLD e SILVER sono sature
166
Capitolo 4
o GOLDSILVERBRONZE_LOW_RESOURCES – tutte le classi di
servizio sono sature
Figura 4-17 – Organizzazione gerarchica delle regioni dell’internal contract
In tabella 4-4 vengono riportati i predicati per ognuna delle regioni sopraelencate
in termini dei valori delle System Conditions descritte in tabella 4-3. Viene
definito il valore di soglia CRITICAL_QUEUE_LEN, che rappresenta la minima
lunghezza di una coda di richieste «critica» (le richieste di operazioni sulle tuple
in sospeso osserveranno tempi di latenza più lunghi dovuti all’attesa in coda).
All’interno del contratto vengono inoltre definite diverse transizioni. In tabella 4-5
per ogni regione vengono riportati i nomi mnemonici delle azioni da effettuare per
ogni transizione verso le altre regioni. Alcune transizioni non sono specificate, in
quanto non sono necessarie o non hanno senso.
167
Regione
Capitolo 4
Predicato
Hin=0 + Hout=0
Non ci sono handover né in ingresso, né in uscita.
STANDARD
GOLD_NORMAL_RESOURCES *
AvgGOLDQueue=0
Non si registrano richieste in coda per la classe GOLD
SILVER_NORMAL_RESOURCES *
AvgSILVERQueue=0
Non si registrano richieste in coda per la classe SILVER
BRONZE_NORMAL_RESOURCES *
AvgBRONZEQueue=0
Non si registrano richieste in coda per la classe BRONZE
GOLD_LOW_RESOURCES *
0<AvgGOLDQueue<GOLD_CRITICAL
Si accumulano richieste in coda alla classe GOLD. Il livello della coda non è ancora critico.
SILVER_LOW_RESOURCES *
0<AvgSILVERQueue<SILVER_CRITICAL
Si accumulano richieste in coda alla classe SILVER. Il livello della coda non è ancora critico.
BRONZE_LOW_RESOURCES *
0<AvgBRONZEQueue<BRONZE_CRITICAL
Si accumulano richieste in coda alla classe BRONZE. Il livello della coda non è ancora critico.
GOLD_CRITICAL *
AvgGOLDQueue>=GOLD_CRITICAL
Numero di richieste in coda nella classe GOLD maggiore della soglia critica
SILVER_CRITICAL *
AvgSILVERQueue>=SILVER_CRITICAL
Numero critico di richieste in coda nella classe SILVER maggiore della soglia critica
BRONZE_CRITICAL *
AvgBRONZEQueue>=SILVER_CRITICAL
Numero critico di richieste in coda nella classe BRONZE maggiore della soglia critica
Hin>0
INGOING_HANDOVER
Almeno una procedura di handover relativa a device entranti nel dominio attiva
AvgGOLDQueue>0
GOLD_LOW_RESOURCES **
Esistono richieste in coda per classe GOLD
GOLDSILVER_LOW_RESOURCES **
AvgGOLDQueue>0 AND AvgSILVERQueue>0
Esistono richieste in coda per le classi SILVER e GOLD
GOLDSILVERBRONZE_LOW_
RESOURCES **
ANDAvgBRONZEQueue>0
Esistono richieste in coda per le classi BRONZE,SILVER e GOLD
Hout>0
OUTGOING_HANDOVER
AvgGOLDQueue>0
GOLD_LOW_RESOURCES ***
GOLDSILVER_LOW_RESOURCES ***
RESOURCES ***
ANDAvgBRONZEQueue>0
* Affinché il predicato sia soddisfatto deve essere soddisfatto anche il predicato della regione STANDARD
** Affinché il predicato sia soddisfatto deve essere soddisfatto anche il predicato della regione INGOING_HANDOVER
** Affinché il predicato sia soddisfatto deve essere soddisfatto anche il predicato della regione OUTGOING_HANDOVER
Tabella 4-4 – Predicati per le regioni dell’internal contract
168
Capitolo 4
Vengono definite esclusivamente le transizioni tra gli stati NORMAL, LOW e
CRITICAL per ogni classe di servizio.
Nella
transizione
da
OUTGOING_HANDOVER
STANDARD
(o
ambedue
ad
INGOING_HANDOVER
visto
che
possono
o
verificarsi
contemporaneamente) le azioni relative alle transizioni tra le regioni figlie della
regione STANDARD vengono sospese, dato che il predicato di tali regioni,
dipendente dal predicato della regione STANDARD, risulta falso.
GOLD_NORMAL
GOLD_LOW
-
IncPerfGold
GOLD_LOW
GOLD_CRITICAL
DA\A
SILVER_NORMAL
DecPerfGold
DecPerfGold
SILVER_NORMAL
SILVER_LOW
-
IncPerfSilver
SILVER_LOW
SILVER_CRITICAL
DA\A
BRONZE_NORMAL
DecPerfSilver
DecPerfSilver
BRONZE_NORMAL
BRONZE_LOW
-
IncPerfBronze
BRONZE_LOW
BRONZE_CRITICAL
DecPerfBronze
DecPerfBronze
-
DA\A
GOLD_NORMAL
GOLD_CRITICAL
IncPerfGold
RenegotiateGold
RenegotiateGold
RenegotiateGold
SILVER_CRITICAL
IncPerfSilver
RenegotiateSilver
RenegotiateSilver
RenegotiateSilver
BRONZE_CRITICAL
IncPerfBronze
RenegotiateBronze
RenegotiateBronze
RenegotiateBronze
Tabella 4-5 – Transizioni definite nell’internal contract
Questa scelta è motivata dal fatto che durante le procedure di handover i
componenti del mediator e lo SLA Manager sono tenuti ad effettuare numerose
operazioni per trasferire le tuple dal vecchio al nuovo dominio del roamers. Le
classi di servizio possono dunque venir saturate, e potrebbero far scattare così le
azioni adattative, che possono portare anche alla rimozione di SLA. Data la natura
transitoria degli handover si preferisce dunque «tollerare» temporanei
sovraccarichi sulle classi di servizio. Del resto, come verrà evidenziato nel
paragrafo 4.4.5 il compito delle attività adattative in-band è proprio quello di
disciplinare le procedure di handover in maniera tale che non creino problemi alle
altre interazioni con requisiti di qualità del servizio accordati dallo SLA Manager.
Non sono definite transizioni tra le regioni figlie di INGOING_HANDOVER ed
OUTGOING_HANDOVER. Tali regioni sono definite infatti per fornire
169
Capitolo 4
indicazioni per realizzare i comportamenti adattativi in-band in caso di handover.
Di seguito vengono descritte le azioni effettuate per ognuna delle transizioni
specificate in tabella 4-5:
IncPerf – Qualunque sia la classe di servizio cui viene applicata, utilizza il
Quality Manager (cfr. par. 4.4.4) affinché questo regoli le proprietà dei
livelli sottostanti (ORB, sistema operativo e protocolli di trasporto) in
maniera tale da migliorare le performance (utilizzando magari al massimo
le risorse del sistema) ed annullare la coda di richieste attualmente
presente.
DecPerf – La sua azione è complementare a quella di IncPerf.
Renegotiate – Qualunque sia la classe di servizio cui viene applicata, avvia
una procedura di rinegoziazione in una classe di servizio utilizzando lo
SLA Manager (ed in particolare l’interfaccia iToContracts definita nella
figura 4-2). In base alla dimensione della coda di richieste viene
individuato il numero di interazioni da spostare dalla classe di servizio
corrente. L’oggetto transitionCode che realizza la procedura di
rinegoziazione svolge le seguenti attività:
o Controlla le System Conditions SysCondMonitorAvgReq per le
altre classi di servizio
o Se esistono classi di servizio a performance maggiore di quella in
cui viene effettuata la rinegoziazione e possono sostenere altre
interazioni, sposta progressivamente le interazioni in queste classi,
prediligendo le interazioni a maggiore priorità
o Se dopo aver effettuato l’attività di cui al punto precedente restano
ancora altre interazioni da rinegoziare, oppure non è possibile
usufruire delle classi a performance maggiore (perché la classe di
servizio in stato critico è la classe GOLD o perchè anche le classi a
performance maggiore sono in stato LOW o CRITICAL),
seleziona i service level agreements a criticità minore e con i più
laschi requisiti di qualità del servizio della classe in questione ed
170
Capitolo 4
avvia la rinegoziazione sulle classi a performance minore,
verificando nuovamente la soddisfacibilità dei requisiti.
o Se a questo punto restano ancora interazioni da rinegoziare o
qualche rinegoziazione non è andata a buon fine (lo SLA Manager
ha risposto con il messaggio SLA_NO), viene rimosso il SLA delle
interazioni in questione e viene inviata una notifica ai requestor.
In questo modo l’adattatività out-of-band esercitata dall’internal contract in
collaborazione con lo SLA Manager ed il Quality Manager, oltre a gestire gli
aspetti di manutenzione e rinegoziazione della QoS, fornisce anche un approccio
context aware ai requestor, che vengono informati circa la variazione dei livelli di
QoS all’interno del mediator che comporta la revoca del SLA precedentemente
raggiunto.
4.4.3 Definizione dell’External Contract
L’external contract è verifica che siano rispettate le specifiche di qualità del
servizio per le interazioni per le quali è stato raggiunto un SLA in fase di
negoziazione, provvede a rimuovere tali agreements quando le specifiche di QoS
sono palesemente non rispettate e notifica ai requestors la revoca dei SLA.
Per il monitoraggio dello stato delle singole interazioni vengono prese in
considerazione le System Conditions SysCondValueMeanInt. Per ogni interazione
il System Monitoring Service istanzia uno di questi oggetti e li raccoglie in
un’apposita lista. Il contratto, per effettuare la valutazione dei predicati delle
regioni, utilizzerà l’interfaccia iToExternalContract riportata in figura 4-14.. La
valutazione del contratto viene innescata dagli oggetti SysCondValueMeanInt,
raggruppati in liste come mostrato in tabella 4-6,quando viene riscontrata una
variazione sostanziale nella latenza media di delivery per le tuple di una
determinata interazione.
Nell’external contract vengono definite esclusivamente due regioni:
INTERACTIONS_IN_BOUNDS – il suo predicato è vero se tutte le
interazioni rispettano le rispettive specifiche di qualità del servizio
171
Capitolo 4
INTERACTION_OUT_OF_BOUNDS - il suo predicato è vero se viene
rilevata un’interazione che non rispetta i requisiti entro una certa soglia di
tolleranza
INTERACTION_CRITICAL – il suo predicato è vero se viene rilevata
un’interazione che non rispetta i requisiti oltre la soglia di tolleranza
Nome System Condition
Tipo
Valore misurato
SCValueMeanIntSeq
Latenze medie di dispatch
intra-dominio delle tuple
per ogni interazione
inter-dominio delle tuple
per ogni interazione
sul tuple manager locale per
tuple provenienti da altri domini
Latenze medie nelle operazioni
di delivery sul tuple manager
locale
TDISMeanIntSeq
TDIS1MeanIntSeq
TDIS2MeanIntSeq
TTMMeanIntSeq
Tabella 4-6 – System Conditions utilizzate dall’external contract
L’external contract quando viene notificato circa una variazione nei valori medi
di latenza per una data interazione viene a conoscenza del SLA di tale interazione.
Utilizza quindi per calcolare la snapshot relativa al SLA in questione (snapshot
per paradigma Request/Response, one-way…).
Una volta ottenuta la latenza complessiva nel mediator per tale interazione, viene
confrontata la latenza massima ammessa per tale interazione, e se si riscontra una
transizione di regione viene innescata l’azione adattativa associata a tale
transizione.
I predicati utilizzati nelle regioni dell’external contract sono riportati nella tabella
4-7, mentre nella tabella 4-8 vengono riportate le transizioni tra le diverse regioni
definite. TOLL_THRESOLD è la soglia di tolleranza, definita come percentuale,
che distingue l’interazione fuori dai limiti (regione INTERACTION_OUT_OF
_BOUNDS) dall’interazione critica (INTERACTION_CRITICAL).
172
Capitolo 4
Regione
Predicato
SnapShot
<1
MAX LAT
INTERACTION_IN_BOUNDS
La latenza misurata per la particolare interazione è minore della massima ammessa dai requisiti di QoS
SnapShot
− 1 < TOLL _ THRESOLD
MAX LAT
INTERACTION_OUT_OF_BOUNDS
La latenza misurata per la particolare interazione è maggiore della massima ammessa dai requisiti di QoS ma
resta confinata entro la soglia di tolleranza specificata nel contratto
SnapShot
− 1 ≥ TOLL _ THRESOLD
MAX LAT
INTERACTIONS_CRITICAL
La latenza misurata per la particolare interazione è maggiore della massima ammessa dai requisiti di QoS ed
oltrepassa la soglia di tolleranza specificata nel contratto
Tabella 4-7 – Predicati per le regioni dell’external contract
Nel caso dell’external contract l’informazione sulla regione corrente di
funzionamento non ha senso. Infatti la sua valutazione può essere innescata dalle
System Conditions relative ad una qualsiasi interazione con requisiti di QoS attiva
nel dominio. La regione corrente di funzionamento impostata nel contratto con
ogni probabilità sarà relativa ad un’altra interazione.
DA\A
INTERACTION_
IN_BOUNDS
INTERACTION_
OUT_OF_BOUNDS
INTERACTION_
CRITICAL
INTERACTION_
IN_BOUNDS
INTERACTION_
OUT_OF_BOUNDS
INTERACTION_
CRITICAL
-
Renegotiate
Remove
-
-
-
-
-
-
Tabella 4-8 – Predicati per le regioni dell’external contract
Saranno
pertanto
definite
esclusivamente
le
transizioni
dalla
regione
INTERACTION_IN_BOUNDS alle altre due regioni, ed le relative azioni
adattative al loro termine riporteranno il contratto in tale regione.
Di seguito vengono descritte le azioni effettuate per ognuna delle transizioni
specificate in tabella 4-8:
Renegotiate utilizza lo SLA Manager per negoziare un nuovo agreement per
l’interazione che non rispetta le specifiche di QoS in una classe di servizio
173
Capitolo 4
più performante di quella attualmente assegnata. Se l’operazione non è
fattibile (perché l’interazione è già in classe GOLD, perché le altre classi
di servizio sono sature) il service level agreement viene rimosso ed al
service requestor dell’interazione verrà inviata una notifica.
L’azione Remove viene invocata quando le latenze misurate sono talmente
elevate che risulta inutile tentare di effettuare rinegoziazioni dei SLA.
L’agreement viene rimosso dallo SLA Manager ed al service requestor
viene inviata una notifica.
Congiuntamente l’internal contract e l’external contract forniscono un’approccio
per l’adattatività al contesto delle applicazioni (context awareness) di tipo
application-aware. I contratti, attraverso la notifica della rimozione dei SLA,
informano i requestors delle variazioni dei livelli di qualità del servizio che
rendono impossibile lo svolgimento delle interazioni con il provider con i requisiti
specificati. L’internal contract invia notifiche ai requestor circa lo stato «globale»
del dominio, mentre l’external contract invia notifiche ai requestor circa lo stato
di una particolare interazione. Mentre nel primo caso il motivo della revoca del
SLA è interno alla core network ed è principalmente dovuto ad eccessi di
richieste, nel secondo caso la causa della revoca del SLA può essere ricercata sia
in fattori interni alla core network, che in fattori esterni, come le fluttuazioni della
qualità del collegamento di rete o il livello di carica della batteria di uno dei due
peers, che ne inficiano l’availability, e facendo sì che le tuple non possano essere
direttamente pushed al destinatario ma debbano restare per un certo periodo di
tempo nello spazio locale del mediator.
4.4.4 Il Quality Manager
Il Quality Manager viene chiamato in causa dall’internal contract, per attuare
comportamenti adattativi a seguito di transizioni di regione nel contratto.
Si occupa di gestire le proprietà e le configurazioni dei livelli sottostanti il
mediator. Come accennato nel paragrafo 3.1, i componenti del mediator di
Esperanto funzionano su di un ORB CORBA-compliant. La struttura del Quality
174
Capitolo 4
Manager è fortemente dipendente dai meccanismi messi a disposizione dalla
particolare implementazione dell’ORB adottata.
Il Quality Manager sarà dunque costituito da una semplice interfaccia che espone
i metodi IncPerf e DecPerf utilizzati dall’internal contract per aumentare o
diminuire le performance dell’ORB sottostante.
Le modalità in cui poi IncPerf e DecPerf effettuano tale lavoro,sempre ammesso
che si utilizzi un ORB conforme allo standard RT-CORBA descritto nel capitolo
2, condizione necessaria per poter utilizzare politiche che consentano di regolare
le performance dell’ORB stesso, sono strettamente dipendenti dalla particolare
implementazione dell’ORB su cui poggiano i componenti della core network Nel
successivo capitolo saranno forniti alcuni dettagli circa una possibile
implementazione del Quality Manager sulla piattaforma TAO, introdotta nel
capitolo 2.
4.4.5 In-band adaptation
Per quanto riguarda gli aspetti adattativi della qualità del servizio, finora
l’attenzione è stata principalmente focalizzata sull’adattatività out-of-band,
avviata in modo asincrono dal System Monitoring Service e gestita dalle
transazioni tra le diverse regioni dei contratti. Si andrà ora ad analizzare invece
l’adattatività in-band avviata contestualmente all’invocazione di un metodo nella
gestione delle procedure di handover.
4.4.5.1 IN-BAND ADAPTATION IN CASO DI HANDOVER
Riprendendo quanto affermato nel capitolo precedente, quando si verifica
un’handover non ci si può attendere che i requisiti di qualità del servizio garantiti
nel precedente dominio vengano ancora garantiti nel nuovo dominio nel quale il
device roamer entra, sia durante l’handover che dopo la fine dello stesso.
Quando un device cambia il proprio host domain è necessario trasferire tutte le
tuple depositate nello spazio del vecchio host. Il trasferimento coinvolge un
elevato numero di tuple, soprattutto nel caso in cui il passaggio da un dominio
175
Capitolo 4
all’altro non sia avvenuto in maniera seamless, ma sia stato preceduto da una
disconnessione dal vecchio dominio host. Durante il periodo di disconnessione
diverse tuple potrebbero essere state scritte sullo spazio in attesa che il device le
recuperasse.
La gestione adattativa dell’handover viene effettuata con i seguenti obiettivi:
Completare nel minor tempo possibile il trasferimento delle tuple, tenendo
presente la criticità specificata per le interazioni.
Limitare il più possibile l’impatto dell’handover sulle operazioni di delivery
per le altre interazioni attive sia nel vecchio che nel nuovo dominio host.
A tal fine verranno utilizzati degli oggetti, detti delegati, la cui funzione è quella
di adattare le modalità in cui viene svolto l’handover in base alle regioni correnti
dell’internal contract. Un delegato è un componente adattativo che intercetta le
invocazioni a metodo remoto e ne modifica il comportamento in base alle regioni
di funzionamento del contratto cui è collegato ed ai valori delle System
Conditions. Come descritto nel capitolo 2, in un’invocazione remota il client
accede all’oggetto remoto attraverso il delegato, che modifica le modalità con cui
avviene l’interazione con l’oggetto remoto in base ai livelli di QoS osservati nel
sistema [BBN 02].
Un handover viene rilevato dal System Monitoring Service attraverso le opportune
System Conditions descritte al paragrafo 4.3.2 e di conseguenza l’internal contract
si sposta dalla regione STANDARD alla regione INGOING_HANDOVER o
OUTGOING_HANDOVER.
Si osservi che durante la gestione di un handover ulteriori device possono entrare
nel dominio o abbandonarlo: le System Conditions addette al monitoraggio degli
handover tengono traccia del numero di procedure in corso e pertanto l’internal
contract resta nelle regioni di handover finchè tutte le procedure di trasferimento
delle tuple non vengono concluse.
La procedura di trasferimento delle tuple, senza l’introduzione di comportamenti
adattativi, avviene nei seguenti passi:
Il dispatcher del nuovo host domain rintraccia il dispatcher del vecchio host e
176
Capitolo 4
richiede il recupero tutte le tuple per il device roamer
Il dispatcher del vecchio dominio host effettua una scansione di tutte le tuple
per il roamer e le inoltra al dispatcher del nuovo host
Il dispatcher del nuovo dominio host inoltra in sequenza tutte le tuple ricevute
al tuple manager locale.
Trascurando la QoS per le interazioni che coinvolgono il roamer, affrontare la
procedura di handover mediante trasferimenti bulk delle tuple comporta
fluttuazioni nei livelli di QoS anche per le altre interazioni attive nei due domini
in quanto:
•
La scansione dell’intero insieme di tuple destinate al roamer provoca un
burst di richieste di lettura verso il tuple manager del vecchio dominio
host.
•
Il trasferimento bulk delle tuple al dispatcher del nuovo dominio host
causa un burst di richieste sull’interfaccia inter-dominio dello stesso.
•
La scrittura sequenziale delle tuple ricevute sul tuple manager del nuovo
dominio host inizia esclusivamente dopo la ricezione di tutte le tuple dal
vecchio host e causa un burst di richieste di scrittura verso il tuple
manager del nuovo host.
•
Nel trasferimento delle tuple non si tiene in alcun modo conto della
criticità delle interazioni cui le tuple sono associate.
Pertanto i delegati che effettuano in-band adaptation opereranno intervendo su:
•
Scansione sul tuple manager del vecchio host.
•
Inoltro delle tuple al dispatcher del nuovo dominio host.
•
Scrittura delle tuple sul tuple manager del nuovo dominio host.
Il delegato appliccherà comportamenti adattativi nel recupero delle tuple dal tuple
manager del vecchio dominio host in base alle correnti regioni di funzionamento
dell’internal contract.
Il delegato recupera le informazioni relative al numero totale di tuple da trasferire.
177
Capitolo 4
il numero di tuple da recuperare viene determinato in base al massimo tra il
numero medio di richieste correntemente servibile dalle diverse classi di servizio
ed ad un parametro costante MAX_SCAN (che viene utilizzato per evitare che il
dispatcher del nuovo dominio host debba attendere troppo tempo prima di poter
iniziare a scrivere le tuple sul suo tuple manager). Per default MAX_SCAN=1 e
quindi le tuple vengono lette dal vecchio dominio e scritte sul nuovo una per
volta.
In ogni caso vengono recuperate prima le tuple relative ad interazioni a massima
criticità e quindi le tuple relative ad interazioni a minor criticità.
Quindi in base alla regione corrente dell’internal contract (che sarà nella regione
OUTGOING_HANDOVER) prenderà le seguenti decisioni:
•
Il contratto è in regione NORMAL_RESOURCES. Tutte le classi di
servizio vengono utilizzate per il recupero delle tuple (si ignora la policy
PREDICTABLE_READ. Si supponga ad esempio che dalle informazioni
provenienti dalle System Conditions si rilevi di avere mediamente 5 slot di
servzio disponibili in classe GOLD, 8 in classe SILVER e 10 in classe
BRONZE e di dover trasferire in tutto 45 tuple, 15 a criticità massima, 10
a criticità media e 20 a criticità minima. Si supponga che sia
MAX_SCAN=10. Il delegato deciderà di trasferire 10 tuple utilizzando le
classi GOLD e SILVER. Verranno inviate al dispatcher le prime 10 tuple,
tute relative ad interazioni a criticità massima. Le successive invocazioni
provocheranno il trasferimento delle altre tuple.
•
Il contratto è in regione GOLD_LOW_RESOURCES. La classe GOLD
non verrà utilizzata per il recupero.
•
Il
contratto
è
in
regione
GOLDSILVER_LOW_RESOURCE.
I
trasferimenti di tuple avverranno esclusivamente in classe BRONZE
•
Il contratto è in regione GOLDSILVERBRONZE_LOW_RESOURCE. I
trasferimento di tuple avverranno in maniera best-effort, MAX_SCAN
tuple per volta.
178
Capitolo 4
Poiché il trasferimento delle tuple non è più di tipo bulk il dispatcher del nuovo
host domain dovrà sapere esattamente quante tuple sono state trasferite e quante
tuple restano da trasferire.
Nel
nuovo
host
domain
l’internal
contract
si
trova
nella
regione
INGOING_HANDOVER. Un secondo delegato, che disciplina l’inoltro delle
tuple verso il tuple manager locale, adotterà i seguenti comportamenti adattativi:
•
Il contratto è in regione NORMAL_RESOURCES: verrà utilizzata la
classe GOLD per l’inoltro.
•
Il contratto è in regione GOLD_LOW_RESOURCES: verrà utilizzata la
classe SILVER per l’inoltro.
•
Il contratto è in regione GOLDSILVER_LOW_RESOURCES: verrà
utilizzata la classe BRONZE per l’inoltro.
•
Il contratto è in regione GOLDSILVERBRONZE_LOW_RESOURCES:
l’inoltro avverrà in modalità best-effort.
Si tenga tuttavia presente che l’utilizzo di un delegato introduce overhead
dovuto alla valutazione del contratto ed all’accesso all’oggetto servente
tramite il delegato. Filtrare attraverso un delegato le operazioni di scrittura sul
tuple manager introduce dunque una latenza aggiuntiva che fa decadere le
prestazioni dell’intera infrastruttura di delivery, in quanto il delegato viene
chiamato in causa non solo durante le procedure di handover, ma anche nelle
normali operazioni di delivery. E’ quindi opportuno distinguere le operazioni
di scrittura sul tuple manager relative alle operazioni di delivery ed al
trasferimento delle tuple in caso di handover.
Riepilogando vengono introdotti i seguenti delegati:
•
Inter-domain dispatcher delegate – che disciplina il recupero delle
tuple dallo del tuple manager del vecchio host domain.
•
Local dispatcher delegate – che disciplina l’inoltro delle tuple sul tuple
manager del nuovo host domain.
179
Approcci realizzativi al sistema di
gestione della QoS nel mediator
Capitolo 5
Capitolo 5
Approcci realizzativi al sistema
di gestione della QoS nel mediator
5.1 Introduzione
Nei precedenti capitoli è stato descritto il modello di qualità del servizio adottato
per il mediator di Esperanto e sono state individuate le soluzioni per garantire
predictability nel delivery delle tuple, effettuare la negoziazione di un service
level agreement, per monitorare i livelli di qualità del servizio nel dominio e per
introdurre adattatività alle variazioni nei livelli di qualità del servizio all’interno
del mediator.
Nel presente capitolo verranno approfonditi alcuni di questi aspetti, proponendo
l’utilizzo di due tecnologie Open Source, TAO e QuO.
TAO (The ACE ORB), introdotto nel paragrafo 2.3, verrà utilizzato per introdurre
predictability nel delivery delle tuple sfruttando le politiche real-time messe a
disposizione dall’ORB su cui girano i componenti del mediator stesso e per
gestire il signalling tra i componenti addetti alla gestione della qualità del
servizio, vale a dire il System Monitoring Service e lo SLA Manager.
Il framework QuO (Quality Objects), introdotto nel paragrafo 2.5, verrà invece
utilizzato per realizzare il sistema di monitoraggio delle risorse (SM Service) e
per realizzare l’adattatività out-of-band ed in-band descritta nel paragrafo 4.4.
5.2 Classi di servizio e signalling nel mediator con TAO
Nel modello di QoS per il mediator Esperanto vengono definite tre classi di
servizio per il delivery delle tuple: GOLD, SILVER, BRONZE. Ad ognuna di
queste classi di servizio sono associate differenti latenze nelle operazioni dello
spazio di tuple. Le suddette classi di servizio vengono assegnate alle interazioni
che specificano precisi requisiti di qualità del servizio, mentre le tuple relative alle
altre interazioni vengono delivered in modalità best-effort.
180
Capitolo 5
In questo paragrafo le proprietà delle sopraelencate classi di servizio verranno
realizzate utilizzando le real-time policies messe a disposizione da TAO.
La gestione della qualità del servizio ed il delivery QoS-enabled delle tuple
inducono nel mediator un’attività di signalling tra i componenti addetti al delivery
ed i componenti addetti alla gestione della QoS. Verranno predisposte opportune
politiche dell’ORB real-time per gestire e disciplinare tale attività di signalling.
La disponibilità di politiche di scheduling real-time nel sistema operativo
sottostante l’ORB rappresenta un requisito fondamentale nella realizzazione di
questi meccanismi, in quanto a livello ORB TAO si occupa di preparare i thread
nei quali saranno gestiti le risorse ed assegnarvi delle priorità (mappando le
priorità CORBA in priorità native del sistema operativo), ma è compito del
sistema operativo non sottoporre tali thread ad aging della priorità ed
implementare algoritmi di scheduling di tipo fixed priority.
Infine verrà proposta una soluzione per la realizzazione del Quality Manager, che
si occupa di adattare la configurazione real-time dell’ORB alle variazioni dello
stato del sistema.
5.2.1 Configurazioni real-time dei componenti del mediator
5.2.1.1 DEFINIZIONE DELLE CLASSI DI SERVIZIO
Il delivery delle tuple appartenenti alle tre classi di servizio definite nel modello di
QoS per il mediator di Esperanto verrà gestito servendo le richieste di write (e di
read, se la policy PREDICTABLE_READ assume il valore YES) in threads a
priorità differente. Al POA (Portable Object Adapter) nel quale sono registrati gli
oggetti dispatcher e tuple manager verrà associato un threadpool with lanes (cfr.
paragrafo 2.2). Vengono definite 4 lanes, con differenti proprietà:

GOLD_LANE – Serve le richieste per il delivery in classe di servizio
GOLD. E’ caratterizzata da un numero S di thread statici, da un numero
D’ di thread dinamici, priorità PG.

SILVER_LANE – Serve le richieste per il delivery in classe di servizio
SLVER. E’ caratterizzata da un numero S di thread statici, da un numero
181
Capitolo 5
D’ di thread dinamici, priorità Ps<PG.

BRONZE_LANE – Serve le richieste per il delivery in classe di servizio
BRONZE. E’ caratterizzata da un numero S di thread statici, da un numero
D’ di thread dinamici, priorità PB<PS<PG.

OTHER_LANE - – Serve le richieste per il delivery best-effort. E’
costituita esclusivamente da D’’ thread dinamici che vengono schedulati
alla priorità di default del sistema operativo.
Le priorità PB,PS,PG saranno maggiori della priorità di default del sistema
operativo. L’utilizzo dei thread statici diminuisce la latenza di servizio delle
richieste, in quanto non viene sprecato tempo nella creazione del thread . Il
numero di thread statici S definisce il massimo numero di richieste servibili
contemporaneamente per ogni classe di servizio. I thread dinamici nelle lanes
dedicate alle classi di servizio GOLD, SILVER e BRONZE vengono utilizzati
per sopperire ad improvvisi burst di richieste. I thread dinamici vengono distrutti
al termine del servizio della richiesta. Le richieste best-effort vengono tutte servite
in thread dinamici, in quanto i thread statici occupano risorse (vengono schedulati
anche se non hanno nessuna richiesta da servire).
Nel threadpool viene inoltre inibito il borrowing dei thread (che consentirebbe
alle classi di servizio GOLD e SILVER di prelazionare threads alle classi di
servizio a priorità inferiore), e viene abilitato il buffering delle richieste.
I Threadpools e le banded connections verranno definiti per i POA del dispatcher
e del tuple manager. Il bridge si occuperà di instradare le operazioni sulle
opportune classi di servizio.
Si osservi che priorità appena definite sono priorità CORBA. Mediante l’utilizzo
dei meccanismi di Priority Mapping vengono quindi trasformate in priorità del
sistema operativo. TAO mette a disposizione tre tipologie di priority mapping:

Direct – mapping 1:1 delle priorità CORBA sulle priorità native del
sistema operativo.

Linear - il range [0;32767] delle priorità CORBA viene suddiviso in
intervalli, ognuno dei quali viene mappato su di una diversa priorità del
182
Capitolo 5
sistema operativo.

Continuous – le prime n priorità CORBA vengono mappate sulle priorità
del sistema operativo, dove n è la dimensione del range di priorità native
del sistema operativo

User-defined – gli sviluppatori possono definire particolari priority
mapping ridefinendo la classe TAO::PriorityMappingManager ed in
particolare i metodi toCORBA e toNative.
# Opzioni per configurazione real-time:
# Politica di scheduling FIFO
# mapping continuo delle priorità
static RT_ORB_Loader "-ORBPriorityMapping continuous ORBSchedPolicy SCHED_FIFO -ORBScopePolicy SYSTEM"
Figura 5-1 – File di configurazione dell’ORB svc.conf
Nel seguito si supporrà di utilizzare il mapping di tipo continuous. La scelta della
modalità di mapping delle priorità e della politica di scheduling da adottare può
essere effettuata utilizzando un file di configurazione, svc.conf, riportato in figura
5-1.
Insieme al threadpool con le diverse lanes vengono utilizzate le priority banded
connections, al fine di ridurre i fenomeni di priority inversioni dovuti all’utilizzo
di protocolli di trasporto standard come TCP.
Le connessioni tra i diversi
componenti del mediator possono quindi essere gestite a priorità diversa secondo
la classe di servizio cui appartengono. Vengono definite 4 bande di priorità per le
classi di servizio GOLD, SILVER, BRONZE e per il dispatching delle richieste
best-effort. Ad ogni banda può essere assegnata una priorità minima ed una
priorità massima (priorità CORBA).
In figura 5-2 viene riportato il codice C++ da utilizzare nei daemons che
istanziano i componenti del mediator per creare il threadpool e le priority banded
connections.
//recupero dei riferimenti e narrowing per:
//ROOTPOA
183
Capitolo 5
//REAL-TIME ORBA
//INTERFACCIA CURRENT
CORBA::Object_var object =
this->orb_->resolve_initial_references ("RootPOA");
PortableServer::POA_var root_poa =
PortableServer::POA::_narrow (object.in ());
PortableServer::POAManager_var poa_manager =
root_poa->the_POAManager ();
object =
this->orb_->resolve_initial_references ("RTORB");
RTCORBA::RTORB_var rt_orb =
RTCORBA::RTORB::_narrow (object.in ());
object =
this->orb_->resolve_initial_references ("RTCurrent");
RTCORBA::Current_var current =
RTCORBA::Current::_narrow (object.in ());
//Recupero della priorità di default dei thread
RTCORBA::Priority default_thread_priority = current->the_priority();
int result=0;
//Creazione del Threadpool
CORBA::ULong stacksize = 0;
CORBA::Boolean allow_request_buffering = 1;
CORBA::ULong max_buffered_requests = MAX_QUEUE;
CORBA::ULong max_request_buffer_size = 0;
CORBA::Boolean allow_borrowing = 0; //no borrowing
CORBA::ThreadpoolLanes lanes (4);lanes.length (4);
// GOLD LANE
lanes[0].lane_priority = PRIORITY_GOLD;
lanes[0].static_threads = STATIC_THREAD;
lanes[0].dynamic_threads = DYNAMIC_THREADS;
// SILVER LANE
lanes[1].lane_priority = PRIORITY_SILVER;
// BRONZE LANE
lanes[2].lane_priority = PRIORITY_BRONZE;
// best-effort LANE
lanes[3].lane_priority = default_thread_priority;
lanes[3].static_threads = 0;
lanes[3].dynamic_threads = BEST_EFFORT_THREADS;
RTCORBA::ThreadpoolId threadpool_id =
rt_orb->create_threadpool_with_lanes (stacksize,
lanes,
allow_borrowing,
allow_request_buffering,
max_buffered_requests,
max_request_buffer_size);
CORBA::Policy_var threadpool_policy =
rt_orb->create_threadpool_policy (threadpool_id);
184
Capitolo 5
//Definizione delle priority bands
RTCORBA::PriorityBands bands(4);bands.length (4);
bands[0].low = PRIORITY_GOLD-BAND_WIDTH;
bands[0].high = PRIORITY_GOLD+BAND_WIDTH;
bands[1].low = PRIORITY_SILVER-BAND_WIDTH;
bands[1].high = PRIORITY_SILVER+BAND_WIDTH;
bands[2].low = PRIORITY_BRONZE-BAND_WIDTH;
bands[2].high = PRIORITY_BRONZE+BAND_WIDTH;
bands[3].low = default_thread_priority-BAND_WIDTH;
bands[3].high = default_thread_priority+BAND_WIDTH;
//Creazione della banded connection policy
CORBA::Policy_var bandconn_policy=
rt_orb->create_priority_banded_connection_policy (bands);
//Creazione del POA e registrazione del servant
result = create_POA_and_register_servant (threadpool_policy.in (),
"mediator POA",
poa_manager.in (),
root_poa.in (),
this->orb_.in (),
rt_orb.in ());
Figura 5-2 – Creazione del threadpool e definizione delle policies real-time
In figura 5-3 viene riportato il codice C++ per la creazione del POA, che viene
associato il threadpool ed alle banded connections precedentemente definito, e
per l’attivazione del servant per il componente Esperanto. Oltre alle policies per
l’utilizzo del threadpool with lanes e delle priority banded connections il POA
viene configurato per l’utilizzo del modello di priorità client propagated. In
questo modo il servant (che sia il dispatcher o il tuple manager) serve le
operazioni sulle tuple alla priorità fissata dall’oggetto chiamante.
int create_POA_and_register_servant (CORBA::Policy_ptr
threadpool_policy,
CORBA::Policy_ptr
bandconn_policy,
const char *poa_name,
PortableServer::POAManager_ptr
poa_manager,
PortableServer::POA_ptr
root_poa,
CORBA::ORB_ptr orb,
RTCORBA::RTORB_ptr rt_orb)
{
// Policies per la creazione del POA
CORBA::PolicyList policies (4); policies.length (4);
// Implicit_activation policy
policies[0] = root_poa->create_implicit_activation_policy
185
Capitolo 5
(PortableServer::IMPLICIT_ACTIVATION);
// Thread pool policy
policies[1] = CORBA::Policy::_duplicate (threadpool_policy);
// Banded connection policy
policies[2] = CORBA::Policy::_duplicate (bandconn_policy);
// Priority Model policy - dichiara il modello client propagated
policies[3] =
rt_orb->create_priority_model_policy
(RTCORBA::CLIENT_PROPAGATED,0);
// Creazione del POA
PortableServer::POA_var poa =
root_poa->create_POA (poa_name,
poa_manager,
policies
ACE_ENV_ARG_PARAMETER);
// Distruzione oggetti policy (non servono più)
for (CORBA::ULong i = 0;
i < policies.length ();
++i)
{
policies[i]->destroy ();
}
// Creazione del servant
// SOSTITUIRE QUESTE LINEE DI CODICE CON LE RIGHE DI
INIZALIZZAZIONE
// DEI COMPONENTI DEL MEDIATOR
return result;
}
Figura 5-3 – Creazione del POA e attivazione del servant
5.2.1.2 INSTRADAMENTO DELLE TUPLE SULLE DIVERSE CLASSI DI SERVIZIO
L’instradamento della tupla su una delle classi di servizio definite al
sottoparagrafo precedente viene effettuata nel bridge (o nel dispatcher se la tupla
proviene da un’altro dominio) mediante l’utilizzo della policy client propagated
priority policy, definita nello standard RT-CORBA (cfr. Par. 2.2) ed implementata
in TAO. In questo modo le operazioni vengono effettuate alla priorità imposta dal
client (in questo caso il bridge).
Il bridge interrogherà lo SLA Manager per reperire la classe di servizio associata
alla tupla. Se esiste un service level agreement imposterà la priorità per il servizio
della richiesta ad uno dei valori PG,PS,PB, altrimenti si utilizzerà il valore di
186
Capitolo 5
default.
In funzione della priorità assegnata l’ORB del server (che potrà essere il
dispatcher o il tuple manager) gestirà la richiesta utilizzando la connection band
appropriata la lane appropriata nel threadpool.
La priorità della richiesta viene assegnata dal client semplicemente modificando la
priorità del thread che invia la richiesta stessa, utilizzando l’interfaccia
RTCORBA::current. Il frammento di codice riportato in figura 5-4 mostra
come impostare la priorità del thread.
CORBA::Short desired_priority = 0;
CORBA::String svcClass;
//recupera la priorità di default
RTCORBA::Priority default_thread_priority =current->the_priority();
// recupera la classe di servizio dallo SLA Manager
svcClass=SLAMan->getSvcClass(curSLA)
switch svcClass
{
case “GOLD” :
desired_priority= GOLD_PRIORITY;
break;
case “SILVER” :
desired_priority= SILVER_PRIORITY;
break;
case “BRONZE” :
desired_priority= BRONZE_PRIORITY;
break;
default:
desired_priority= default_thread_priority;
}
// imposta la nuova priorità
current->the_priority (desired_priority);
// controllo successo operazione
CORBA::Short priority = current->the_priority ();
if (desired_priority != priority)
ACE_ERROR_RETURN ((LM_ERROR,
"ERRORE: Impossibile impostare la "
"priorità del thread a %d\n",
desired_priority),
-1);
Figura 5-4 – impostazione della priorità di invocazione di una richiesta
5.2.2 Configurazioni real-time dei componenti per la gestione della QoS
187
Capitolo 5
All’interno do ogni dominio Esperanto è necessario gestire le attività di signalling
tra i seguenti componenti:

Componenti del mediator e SLA Manager – per il recupero dei SLA
associati alle interazioni, necessari per instradare le operazioni su
un’opportuna classe di servizio. I componenti dello SLA Manager vengono
istanziati su un POA cui è associato un threadpool costituito da due lanes,
una ad alta priorità utilizzata per le interrogazioni ed una a priorità
standard per la negoziazione di nuovi SLA. Il modello di priorità utilizzato
è server declared: le operazioni vengono sempre eseguite alle priorità
impostate nello SLA Manager.

Signaliing tra System Conditions ed Aggregators – le System Conditions
sono distribuite sui diversi componenti del mediator. In numero di
interazioni remote richieste per il calcolo di una snapshot da parte degli
aggregators viene limitato utilizzando i seguenti accorgimenti:
o Gli Aggregators ereditano dalla classe astratta Observer (cfr.
paragrafo 4.3.2) in maniera tale che possano ricevere notifiche
dalle System Conditions quando si rilevano variazioni nei valori
osservati
o Le System conditions notificano anche gli Aggregators (oltre ai
contratti) quando rilevano variazioni nel valore osservato.
o Gli aggregators mantengono una copia locale del valore mantenuto
da ogni System Condition osservata, in maniera tale da poter
effettuare il calcolo di una snapshot senza interrogare le System
Condtions. Tali valori vengono aggiornati in seguito alle notifiche
inviate dalle System Conditions.
o Gli aggregators utilizzando un threadpool con due lanes: una a
bassa priorità per l’aggiornamento dei valori mantenuti nelle
System Conditions, ed una ad alta priorità per le snapshot, in
maniera tale da ridurre l’overhead per la valutazione dei contratti.
188
Capitolo 5
5.3 Realizzazione del SM Service con QuO
Il monitoraggio dello stato del mediator è un elemento di importanza
fondamentale per la negoziazione della qualità del servizio nell’interazione tra due
peers e per la realizzazione dei comportamenti adattativi all’interno del mediator.
QuO mette a disposizione le System Conditions introdotte nel paragrafo 2.5 per
osservare lo stato delle risorse del sistema.
In QuO sono disponibili le seguenti tipologie di System Condition:

ValueSC – memorizza semplicemente un valore. L’interfaccia IDL di tale
System Conditions definisce attributi distinti per ogni tipo di valore
memorizzato (boolean, char, short, long, float,…)

ValueSCCallback – estende la System Condition di tipo ValueSC
aggiungendovi un interfaccia callback

ProbeSC – è una System Condition che effettua la misurazione su richiesta
esplicita utilizzando il metodo astratto signal definito nella sua interfaccia.
Ridefinendo il metodo signal è possibile effettuare azioni diverse in
funzione del valore del parametro del metodo.

MonitorSC – utilizzata per effettuare il polling del valore da misurare.
Ridefinendo il metodo poll si può definire l’azione da eseguire ad una
frequenza specificata.

RemoteValueSCMonitor – specializza la System Condition MonitorSC per
effettuare il polling di una System Condition di tipo ValueSC remota.

TimeSC – restituisce il valore del timer di sistema.

SlidingWindowsCounterSC – conta il numero di eventi che avvengono in
una determinata finestra temporale, impostabile mediante il metodo
SetWidnwosSize.
5.3.1 Implementazione di una System Condition
Si supponga di voler implementare una System Condition per il monitoraggio
della larghezza di banda disponibile tra due host. Il primo passo da effettuare è
189
Capitolo 5
definire l’interfaccia IDL della System Condition, che deve necessariamente
erditare, direttamente o indirettamente, dall’interfaccia quo::SysCond.
#include <quo.idl>
Module ExampleSC //System conditions di prova
{
interface BWMonitorSC: quo::MonitorSC
//MonitorSC eredita da quo::SysCond
{
//metodo aggiunto all’interfaccia Monitor
void setHosts(in string Host1, in string Host2);
};
};
La System Condition BWMonitorSC è una specializzazione di quo::MonitorSC.
Definisce un metodo aggiuntivo per impostare i due host per i quali si vuole
effettuare il monitoraggio della larghezza di banda.
5.3.2 Note per l’implementazione delle System Condition per SM Service
Nel paragrafo 4.3.2 sono stati affrontati gli aspetti relativi al design delle System
Conditions da utilizzare nel System Monitoring Service. L’architettura delle
System Conditions di QuO può essere utilizzata per l’implementazione di tali
System Conditions.
Vengono di seguito elencate le soluzioni implementative per le diverse System
Condition definite nel paragrafo 4.3.2
1. SysCondMonitorAvgReq – eredita dall’interfaccia quo::MonitorSC. Il
metodo poll, per ogni classe di servizio, determina il numero di thread nel
lane del threadpool che stanno servendo una richiesta. La misurazione
viene effettuata sul tuple manager.
2. SysCondMonitorAvgQueue – eredita dall’interfaccia quo::MonitorSC. Il
metodo pool, per ogni classe di servizio, determina la dimensione
dell’eventuale coda di richieste in attesa di essere servite per ogni classe di
servizio, valutando la dimensione della coda di richieste di ogni lane del
threadpool. La misurazione viene effettuata sul tuple manager.
3. SysCondValueMean – eredita dall’interfaccia quo::ValueSCCallback.
190
Capitolo 5
Viene specializzata per aggiornare la media del valore calcolato con
l’invocazione del metodo setvalue. La misurazione viene effettuata
utilizzando il TimeStampManager. Nel System Monitoring service viene
istanziata una System Condition di tipo di tipo SysCondValueMean per
ogni classe di servizio e per ogni latenza elementare osservata, come
riportato nel paragrafo 4.3.
4. SysCondValueMeanInt – analoga alla classe SysCondValueMean da cui
deriva. Aggiunge un attributo che specializza la classe in funzione del
SLA di cui si misura la latenza media. La misurazione viene effettuata
utilizzando il TimestampManager. Nel System Monitoring service viene
istanziata una System Condition per ogni interazione attiva nel dominio e
per ogni latenza elementare osservata. Il Timestamp Manager può
discriminare le System Conditions relative alle diverse interazioni
utilizzando il metodo getSLA.
5. SysCondValueVar – eredita dall’interfaccia quo::ValueSCCallBack. Viene
specializzata per aggiornare la varianza del valore calcolato con
l’invocazioe del metodo setvalue. Nel System Monitoring service viene
istanziata una System Condition di tipo di tipo SysCondValueVar per ogni
classe di servizio e per ogni latenza elementare osservata, come riportato
nel paragrafo 4.3.
6. SysCondValueHandover - eredita dall’interfaccai quo::ValueSCCallBack.
Viene specializzata per incrementare o decrementare il numero di
procedure di handover
in corso nel dominio.
Viene aggiornata
direttamente dal dispatcher. L’incremento dei contatori avviene nelle
seguenti modalità:

Handover in ingresso (device roamer entrante nel dominio) – il
contatore viene incrementato quando il dispatcher riceve un messaggio
greeting da un device con identificativo di host domain diverso
dall’identificativo del dominio del dispatcher; il contatore viene
decrementato
quando
vengono
191
completate
le
operazioni
di
Capitolo 5
trasferimento delle tuple.

Handover in uscita (device roamer uscente dal dominio) – il contatore
viene incrementato quando il nuovo host domain del device invoca il
metodo moveTuples sul dispatcher; viene decrementato quando tutte le
tuple sono state inoltrate al nuovo host domain.
Di seguito viene riportato il modulo delle interfacce IDL delle System
Conditions che saranno utilizzate nel System Monitoring Service.
// mediatorSC.idl
// Interfacce IDL per le System Condition utilizzate nel
// System Monitoring Service
#include "quo.idl"
#include "mediator.idl"
module mediatorSC
{
struct fnParam
{
string paramDir;
string paramType;
}
typedef sequence<fnParam> fnParamList;
struct fnSignature
{
fnParam retValue;
string fnName;
fnParamList args;
};
struct SLAID
{
PeerID provider;
PeerID requestor;
fnSignature functionSignature;
};
//specializza il metodo setvalue per aggiornare la media
interface SysCondValueMean : quo::ValueSCCallback
{
long getMemLength();
void setMemLength(in unsigned long l);
};
//specializza il metodo setvalue per aggiornare la media
//relativa ad un singolo SLA
interface SysCondValueMeanInt : mediatorSC::SysCondValueMean
{
SLAID getSLAID();
192
Capitolo 5
void setSLAID(in SLAID SLA);
};
//specializza il metodo setvalue per aggiornare la varianza
interface SysCondValueVar : quo::ValueSCCallback
{
void setMean(in unsigned long m);
};
//specializza il metodo setvalue per incrementare o decrementare un
contatore
interface SysCondHandover : quo::ValueSCCallback
{
};
//valuta il numero medio di richieste contemporaneamente servite
//per una classe di servizio
interface SysCondMonitorAvgReq : quo::MonitorSC
{
};
//valuta il numero medio di richieste in coda per una classe di
servizio
interface SysCondMonitorAvgQueue : quo::MonitorSC
{
};
};
5.4 Out-of-band ed in-band adaptation con QuO
Come evidenziato nel corso del capitolo 4, il sistema di gestione della QoS in
Esperanto realizza gli aspetti adattativi della qualità del servizio utilizzando sia
out-of-band adaptation che in-band adaptation. L’adattatività out-of-band viene
utilizzata quando le System Conditions rilevano variazioni sensibili nello stato
delle singole classi di servizio o nelle latenze medie misurate per ogni interazione,
mentre l’adattatività in-band viene utilizzata per gestire il trasferimento delle tuple
nelle procedure di handover dei devices.
Nel seguito viene descritto l’utilizzo dei Quality Description Languages (QDL),
messi a disposizione nel framework QuO: il Contract Description Language
(CDL), per la generazione dei contratti (internal ed external contract), e l’Aspect-
193
Capitolo 5
oriented Structure Description Language (ASL) per la generazione dei delegati
delineati nel capitolo precedente.
CDL e ASL sono degli aspect languages che rendono possibile la specifica di
concetti relativi alla qualità di servizio separandoli dagli aspetti funzionali delle
applicazioni ad oggetti distribuiti. Secondo in principi dell’aspect-oriented
programming (AOP) infatti un programma è diviso in diversi aspetti d’interesse,
ognuno dei quali è programmato separatamente utilizzando un linguaggio
apposito per il particolare aspetto (aspect language). L’applicazione viene poi
costruita raggruppando insieme i diversi aspetti utilizzando generatori di codice.
L’AOP consente ai programmatori di dividere un’applicazione sia in componenti
funzionali che in aspetti.
Relativamente agli aspects languages forniti da QuO il contract description
language aggiunge all’applicazione oggetti che misurano e controllano i livelli di
QoS a prescindere dal comportamento dell’applicazione. I contratti sono oggetti
che misurano le condizioni del sistema nel quale vengono inseriti e realizzano
comportamenti adattativi. Le attività di misura ed adattamento sono event-driven,
ed avvengono reagendo alle variazioni nello stato del sistema, a prescindere
dall’esecuzione di una particolare applicazione. In tal modo gli aspetti sistemici
catturati dai contratti QuO sono ortogonali alla struttura di una particolare
applicazione. L’ASL invece introduce gli advice nelle interazioni tra oggetti
distribuiti. Tali advice vengono introdotti direttamente nell’invocazione di metodi
in sistemi ad oggetti distribuiti ed accedono alle System Conditions ed ai contratti
per prendere decisioni adattative basate su informazioni relative ai correnti livelli
di QoS.
Nel seguito del paragrafo verranno descritti gli elementi adattativi del sistema di
gestione della QoS per il mediator (Internal ed External contract, delegati per il
dispatcher) in termini degli aspect languages CDL ed ASL.
5.4.1 Contratti per il mediator
194
Capitolo 5
L’internal e l’external contract, definiti nel paragrafo 4.4, verranno implementati
utilizzando il linguaggio CDL ed il generatore di codice quogen.
Figura 5-5 – regioni definite per l’internal contract
Quogen trasforma le descrizioni CDL dei contratti in interfacce IDL e codice Java
o C++. Il codice generato rispecchierà le regioni, i predicati e le transizioni
definite nel contratto.
Nel seguito verrà trattata la descrizione in CDL dell’internal contract e
dell’external contract.
5.4.1.1 DESCRIZIONE IN CDL DELL’INTERNAL CONTRACT
Nella figura 5-5 è riportata la struttura delle regioni definita nel paragrafo 4.4.2.
195
Capitolo 5
Root
INGOING_
HANDOVER
STANDARD
OUTGOING_
HANDOVER
LOW_RESOURCES
CRITICAL_
RESOURCES
GOLD_LOW_
RESOURCES
GOLD_LOW_
RESOURCES
GOLDSILVER_LOW
_ RESOURCES
GOLDSILVER_LOW
_ RESOURCES
GOLDSILVER
BRONZE_
LOW_RESOURCES
GOLDSILVER
BRONZE_
LOW_RESOURCES
Figura 5-6 – regioni inserite nella specifica CDL dell’internal contract
In quanto le regole sintattiche del CDL non specificano con quali criteri vengono
selezionate le transizioni nel caso in cui siano contemporaneamente attive più
regioni, le regioni vengono ristrutturate come riportato in figura 5-6. I relativi
predicati sono riportati in tabella 5-3.
Vengono
eliminate
le
regioni
GOLD_NORMAL_RESOURCES,
SILVER_NORMAL_RESOURCES e BRONZE_NORMA_RESOURCES, che
saranno sostituite dalla regione speciale inactive del contratto.
Le regioni relative allo stato LOW o CRITICAL delle risorse vengono accorpate e
vengono definite transizioni esclusivamente da inactive a LOW e da LOW a
critical. Non si pone il problema per le regioni INGOING_HANDOVER ed
OUTGOING_HANDOVER, in quanto non sono interessate da alcuna transizione.
196
Capitolo 5
Regione
Predicato
Hin=0 + Hout=0
Non ci sono handover né in ingresso, né in uscita.
STANDARD
(0<AvgGOLDQueue<GOLD_CRITICAL) OR
(0<AvgSILVERQueue<SILVER_CRITICAL)
OR(0<AvgBRONZEQueue<BRONZE_CRITICAL)
Si accumulano richieste in coda ad almeno una delle classi di servizio.
Il livello delle coda non è ancora critico.
LOW_RESOURCES *
(AvgGOLDQueue>=GOLD_CRITICAL) OR
(AvgSILVERQueue>=SILVER_CRITICAL) OR
(AvgBRONZEQueue>=BRONZE_CRITICAL)
Numero di richieste in coda per una delle classi di servizio maggiore della soglia critica.
CRITICAL_RESOURCES *
Hin>0
INGOING_HANDOVER
AvgGOLDQueue>0
GOLD_LOW_RESOURCES **
GOLDSILVER_LOW_RESOURCES **
RESOURCES **
ANDAvgBRONZEQueue>0
Hout>0
OUTGOING_HANDOVER
AvgGOLDQueue>0
GOLD_LOW_RESOURCES ***
GOLDSILVER_LOW_RESOURCES ***
RESOURCES ***
ANDAvgBRONZEQueue>0
* Affinché il predicato sia soddisfatto deve essere soddisfatto anche il predicato della regione STANDARD
** Affinché il predicato sia soddisfatto deve essere soddisfatto anche il predicato della regione INGOING_HANDOVER
** Affinché il predicato sia soddisfatto deve essere soddisfatto anche il predicato della regione OUTGOING_HANDOVER
Tabella 5-3 – predicati per le regioni inserite nella
specifica CDL dell’internal contract
E’ compito delle transizioni determinare quali regioni si trovano nello stato LOW
o CRITICAL e realizzare le opportune azioni adattative. In figura 5-7 viene
riportato il listato in CDL dell’internal contract.
//
//
//
Internal Contract
Individua gli handover e le condizioni di saturazione delle
classi di servizio
197
Capitolo 5
// NB:
// Quality Manager e SLA Manager devono essere indicati come System
Conditions
contract Internal
(
syscond MediatorSC::SysCondMonitorAvgReq
MediatorSC::SysCondMonitorAvgReq_impl GOLDReq,
MediatorSC::SysCondMonitorAvgReq_impl SILVERReq,
MediatorSC::SysCondMonitorAvgReq_impl BRONZEReq,
syscond MediatorSC::SysCondMonitorAvgQueue
MediatorSC::SysCondMonitorAvgQueue_impl GOLDQueue,
MediatorSC::SysCondMonitorAvgQueue_impl SILVERQueue,
MediatorSC::SysCondMonitorAvgQueue_impl BRONZEQueue,
syscond MediatorSC::SysCondValueHandover
MediatorSC::SysCondValueHandover_impl Hin,
syscond MediatorSC::SysCondValueHandover
MediatorSC::SysCondValueHandover_impl Hout,
syscond MediatorQOS::SLAManager
MediatorQOS::SLAManager_impl SLAManager,
syscond MediatorQOS::QUAManager
MediatorQOS::QUAManager_impl QUAManager
)
{
region Standard ((Hin=0) and (Hout=0))
{
region Low (((GOLDQueue<GOLD_CRITICAL) AND (GOLDQueue>0)) OR
((SILVERQueue<SILVER_CRITICAL) AND (SILVERQueue>0))
OR
((BRONZEQueue<BRONZE_CRITICAL) AND
(BRONZEQueue>0)))
{}
region Critical ((GOLDQueue>=GOLD_CRITICAL) OR
(SILVERQueue>=SILVER_CRITICAL) OR
(BRONZEQueue>=BRONZE_CRITICAL))
{}
}
region InGoing_Handover (Hin>=0)
{
region Gold_Low_Resources (GOLDQueue>0)
{}
region GoldSilver_Low_Resources ((GOLDQueue>0) AND
(SILVERQueue>0))
{}
region GoldSilverBronze_Low_Resources ((GOLDQueue>0) AND
(SILVERQueue>0) AND (BRONZEQueue>0))
{}
}
region OutGoing_Handover (Hout>=0)
{
region Gold_Low_Resources (GOLDQueue>0)
{}
198
Capitolo 5
region GoldSilver_Low_Resources ((GOLDQueue>0) AND
(SILVERQueue>0))
{}
region GoldSilverBronze_Low_Resources ((GOLDQueue>0) AND
(SILVERQueue>0) AND (BRONZEQueue>0))
{}
}
transition inactive->Low
{
asynchronous
{
//Incrementa la performance dei livelli sottostanti
QUAMan.incPerf();
}
}
transition Low->inactive
{
asynchronous
{
//Decrementa la performance dei livelli sottostanti
//si risparmiani risorse...
QUAMan.decPerf();
}
}
transition Inactive->Critical
{
asynchronous
{
//Rinegoziazione dei SLA
SLAMan.renegotiate();
}
}
transition Low->Critical
{
asynchronous
{
//Rinegoziazione dei SLA
SLAMan.renegotiate();
}
}
};
Figura 5-7 – listato CDL dell’internal contract
5.4.1.2 DESCRIZIONE IN CDL DELL’EXTERNAL CONTRACT
La specifica in CDL dell’external contract non richiede la ristrutturazione delle
regioni effettuata per l’internal contract.
Le regioni, descritte nel paragrafo 4.4.3 vengono riportate in tabella 5-4.
Il listato CDL dell’external contract è riportato in figura 5-8.
199
Capitolo 5
Per la formulazioni dei predicati delle regioni vengono utilizzate le sequenze di
System Conditions e gli operatori every e some.
Regione
Descrizione
il suo predicato è vero se tutte le
interazioni rispettano le rispettive
specifiche di qualità del servizio
il suo predicato è vero se viene rilevata
un’interazione che non rispetta i requisiti
entro una certa soglia di tolleranza
il suo predicato è vero se viene rilevata
un’interazione che non rispetta i requisiti
oltre la soglia di tolleranza
INTERACTIONS_IN_BOUNDS
INTERACTION_OUT_OF_BOUNDS
INTERACTION_CRITICAL
Tabella 5-4 – regioni dell’external contract
5.4.2 Delegati per il mediator
Nel paragrafo 4.4 sono state descritte le funzioni dei delegati per la gestione
adattativa dell’handover.
In figura 5-8 viene riportato il listato ASL (Aspect-oriented structure language)
che definisce i comportamenti adattativi adottati dal dispatcher durante le
procedure di handover.
Il metodo moveTuples viene adattato per distribuire le tuple da trasferire. Vengono
spostate al più MAXSCAN tuple contemporaneamente. Il numero di tuple
trasferito è limitato dai livelli di saturazione delle diverse classi di servizio. Le
tuple da trasferire vengono distribuite su tutte le classi da servizio, utilizzando
preferenzialmente la classe GOLD, sia in fase di lettura dallo spazio del vecchio
dominio che in fase di scrittura sul nuovo dominio.
behavior Handover ()
{
remote_object mediator::DispatcherToDispatcher dis;
remote_object mediator::DispatcherToBridge dtb;
//di default trasferisce le tuple in classe GOLD
TupleList dis::moveTuples(in mediator::DeviceId dev,
in CORBA::string newHost,
in CORBA::long nTuples)
{
//System condition del System Monitoring Service
extern MediatorSC::SysCondMonitorAvgReq GOLDReq;
extern MediatorSC::SysCondMonitorAvgReq SILVERReq;
200
Capitolo 5
extern MediatorSC::SysCondMonitorAvgReq BRONZEReq;
//GOLDSLOT=SILVERSLOT=BRONZESLOT=50
//Diposnilità di risorse per ogni classe
local CORBA::long GOLDav;
local CORBA::long SILVERav;
local CORBA::long BRONZEav;
//numero totale di tuple
local CORBA::long tupleCount;
//tuple da trasferire «one-shot»
local CORBA::long transferGOLD;
local CORBA::long transferSILVER;
local CORBA::long transferBRONZE;
local CORBA::long transferBE;
local CORBA::long toTransfer;
before PREMETHODCONTRACTEVAL {
//MAXSCAN=10
cplusplus_code#{
if (nTuples>10)
toTransfer=10;
else
toTransfer=nTuples;
}#
}
//determina il numero di tuple da trasferire per ogni classe
before METHODCALL {
//applica solo in caso di handover in uscita
region OUTGOING_HANDOVER {
GOLDav=50-GOLDReq
SILVERav=50-SILVERReq;
BRONZEav=50-BRONZEReq;
transferGOLD=GOLDav;
toTransfer-=transferGOLD;
region GOLD_LOW_RESOURCES {
cplusplus_code#{
if (toTransfer>0) {
transferSILVER=SILVERav;
toTransfer-=transferSILVER;
}
}#
}
region GOLDSILVER_LOW_RESOURCES {
cplusplus_code#{
if (toTransfer>0) {
transferBRONZE=BRONZEav;
toTransfer-=transferBRONZE;
}
}#
}
region GOLDSILVERBRONZE_LOW_RESOURCES {
cplusplus_code#{
if (toTransfer>0) {
transferBE=toTransfer;
}
}#
201
Capitolo 5
}
} //region OUTGOING_HANDOVER
} //before METHODCALL
inplaceof METHODCALL {
//applica solo in caso di handover in uscita
region OUTGOING_HANDOVER {
dis.movetuples(dev,newhost,transferGOLD)
dis.setMoveSvcClass("SILVER");
dis.movetuples(dev,newhost,transferSILVER);
dis.setMoveSvcClass("BRONZE");
dis.movetuples(dev,newhost,transferBRONZE);
dis.setMoveSvcClass("BE");
dis.movetuples(dev,newhost,transferBE);
}
dis.setMoveSvcClass("BRONZE");
dis.movetuples(dev,newhost,transferBRONZE);
}
}
} //region OUTGOING_HANDOVER
} //inplaceof METHODCALL
} //dis::moveTuples
void dtb::write(in TupleStruct ts);
{
inplaceof METHODCALL {
//applica solo in caso di handover in ingresso
region INGGOING_HANDOVER {
dtb.setSvcClass("SILVER");
dtb.write(ts);
}
dtb.setSvcClass("BRONZE");
dtb.write(ts);
}
dtb.setSvcClass("BE");
dtb.write(ts);
}
} //region INGOING_HANDOVER
} //inplaceof METHODCALL
} //dtb::writeTuples
}; //behavior handover
202
Esperanto e gli altri middleware
mobile-aware con supporto per la QoS
Capitolo 6
Capitolo 6
6.1 Introduzione
Nel secondo capitolo sono state trattate diverse piattaforme middleware con
supporto per la qualità del servizio, nessuna delle quali offriva un supporto
specifico per il mobile o nomadic computing; rappresentano una valida base di
partenza sulla quale poi costruire piattaforma middleware specializzata per fornire
servizi a specifici tipi di applicazioni e/o specifici ambienti come appunto il
nomadic computing.
Tuttavia diversi gruppi di ricerca hanno affrontato il problema della qualità del
servizio in ambienti caratterizzati da forte mobilità dei devices e/o rapide
variazioni del contesto nel quale gli stessi devices lavorano. Nel presente capitolo
verranno esaminati alcuni progetti portati avanti da tali gruppi di ricerca e
specificamente:
•
Mobiware – progetto sviluppato dal gruppo COMET del prof. Aurel A.
Lazar dell’university of Colombia di New York
•
Monads – progetto sviluppato dal gruppo del prof. Kimmo Raatikanen del
dipartimento di computer science dell’università di Helsinki
•
UBIQoS – progetto sviluppato dal LIA (Laboratorio di Informatica
Avanzata) dell’università di Bologna, portato avanzi dal prof. Antonio
Corradi e dall’ing. Paolo Bellavista.
Al fine di comprendere in cosa si differenzia Esperanto, per ognuno di questi
progetti verranno esaminati i seguenti aspetti:
•
Obiettivi proposti e contesto applicativo
•
Architettura
•
Specifica e realizzazione della QoS
•
Supporto per la mobilità
203
Capitolo 6
In conclusione verrà proposto un quadro sinottico nel quale verrà riportato in che
modo questi progetti ed Esperanto affrontino le problematiche della specifica e
del mapping dei requisiti di qualità del servizio, della realizzazione della QoS
stessa, dell’adattatività delle diverse soluzioni proposte a fronte di variazioni dei
livelli di QoS percepiti e della gestione della mobilità dei dispositivi.
6.2 Mobiware
6.2.1 Obiettivi e contesto applicativo
Mobiware è una piattaforma middleware QoS-aware studiata per applicazioni
multimediali in ambienti mobile. Tale piattaforma «gira» contemporaneamente su
devices mobili, punti di accesso alla rete fissa (access points) e switch/router
mobile capable.
Gli autori attribuiscono a questa piattaforma tre principali attributi:
•
Open – con tale termine gli autori intendono che è necessario
implementare appositi algoritmi per il signalling, il trasporto dei flussi
multimediali e la gestione adattativa della qualità del servizio verso i
dispositivi mobili. Mobiware astrae devices mobili, access points, switch e
routers e li rappresenta in termini di oggetti CORBA. Questi oggetti
possono essere programmati attraverso opportune interfacce al fine di
supportare qualità del servizio adattativa, come descritto in [LAZAR 97]
•
Programmable – le interfacce di cui sopra forniscono una API di alto
livello per la creazione di servizi di distribuzione di contenuti
multimediali, come descritto in [CAMP 97]
•
Active – Gli algoritmi per fornire QoS adattativa vengono rappresentati in
mobiware come Active transport objects (ATO), che vengono installati onthe-fly sui dispositivi nei quali gira la piattaforma middleware, al fine di
fornire supporto adattativo per la QoS dove e quando viene richiesto, come
descritto in [CAMP 96]
204
Capitolo 6
Mobiware è stato concepito principalmente per fornire qualità del servizio nella
trasmissione di flussi multimediali ed è incentrato sulla gestione delle risorse di
comunicazione, e specificamente sulla gestione della larghezza di banda.
6.2.2 Architettura
L’architettura di Mobiware è basata sulla separazione tra il signalling verso i
dispositivi mobili e la gestione dell’attività da una parte ed il trasporto dei flussi
multimediali dall’altra, come evidenziato in figura 6-1.
Come riportato in [CAMP 96],la rete wireless viene suddivisa in domini. Ogni
dominio è costituito da un certo numero di dispositivi mobili e base stations (gli
access points). Le base stations sono connesse tra di loro attraverso la rete fissa
ATM.
Signalling e gestione dell’adattatività sono realizzati mediante xbind [LAZAR
92], una piattaforma per la creazione, il deploying e la gestione di sofisticati
servizi multimediali, che costituisce un kernel per reti multimediali che garantisce
qualità del servizio, e Java, che gestisce il dispatching e la creazione degli ATO
(Active Transport Objects).
Al livello active wireless transport risiedono gli ATO e gli STO (Static Transport
Objects) che si occupano degli aspetti adattativi della QoS. Gli STO sono
analoghi agli ATO, con la differenza che non sono installati on-the-fly dove e
quando sono necessari, ma sono installati staticamente sui devices mobili e sui
punti di accesso della rete fissa. Sono definiti STO per flow control, rate control,
segmentation and reassembly, resource control e buffer management. Esistono
invece due tipi di ATO: active media filters e adaptive FEC filters; i primi
adattano il contenuto multimediale trasportato attraverso il media scaling, mentre
i secondo introducono codici ridondante per proteggere le trasmissioni dagli errori
tipi del canale radio.
Il livello programmable mobile network è basato sul kernel xbind. I flussi IP
vengono veicolati sui servizi di trasporto ATM. Il livello è costituito da oggetti
CORBA che forniscono un’astrazione per i dispositivi mobili, gli access points e
205
Capitolo 6
gli switch ATM mobile capable dell’infrastruttura fissa, e proxy che gestiscono
l’adaptation sui dispositivi mobili stessi.
Il servizio di rete a qualità del servizio fornito da xbind supporta la distribuzione
di flussi multi-risoluzione, costituiti da un livello base di qualità (Base Layer) e da
uno o più livelli di raffinamento (Enhancement Layer).
Figura 6-1 – Architettura a livelli di Mobiware
Il livello programmable MAC, descritto in [BIAN 98b], mette a disposizione un
insieme di servizi fondamentali per supportare la qualità del servizio nelle
connessioni wireless; loro obiettivo è supportare delle garanzie minime di QoS sul
link wireless e fornire supporto per le policies adattative specifiche
dell’applicazione.
La natura «programmabile» di questo livello, come riportato in [BIAN 98b], lo
distingue dagli approcci usuali che si trovano in letteratura. Infatti anziché
supportare uno specifico set di servizi hard-wired (come le classi di servizio
ATM), fornisce un’interfaccia wireless che consente l’installazione di nuovi
servizi on-the-fly.
206
Capitolo 6
6.2.3 Specifica e realizzazione della QoS
Il modello di QoS utilizzato in mobiware è basato sull’utilizzo della bandwith
disponibile come trade-off tra qualità temporali (latenza, bitter,…) e spaziali
(resolution, color depth,…) dei flussi mediali trasmessi.
L’API messa a disposizione degli sviluppatori di servizi per specificare i propri
requisiti di QoS prevede la specifica di:
•
Una utility function in cui la QoS osservata (valore compreso tra 0 ed 1),
ovvero il livello di soddisfazione percepito dall’utente del servizio
multimediale, viene espresso come una funzione della larghezza di banda
disponibile. Il dominio di tale curva ed il suo andamento esprimono le
caratteristiche adattative dei servizi multimediali. Alcuni esempi di utility
function sono riportati in figura 6-2.
Figura 6-2 – Utility function per la specifica dei livelli di QoS desiderati
•
Una adaptation policy, politiche che indicano come muoversi lungo la
curva della utility function. In mobiware sono definite 4 policies:
o FAST – rapide reazioni a variazioni nelle risorse disponibili
207
Capitolo 6
o SMOOTH – non reagisce rapidamente, ma solo dopo che le
variazioni nelle risorse sono assestate.
o HANDOFF - applica gli schemi adattativi solo in caso di handoff
(Nota: nella terminologia di mobiware, l’handoff è equivalente
all’handover in Esperanto)
o NEVER – non adattare mai il contenuto alla larghezza di banda
disponibile.
L’algoritmo di allocazione delle risorse, descritto in [BIAN 98a] riserva ai
dispositivi larghezza di banda in maniera tale che ad ogni access point i
dispositivi collegati percepiscano tutti la stessa QoS, ovvero in modo tale che il
valore dell’utility function per ogni dispositivo connesso all’Access point sia
identico. L’allocazione della banda richiesta dalle applicazioni avviene mediante
la fornitura di garanzie di QoS hard per i base layers, e garanzie di tipo soft per
gli enhancement layers ed il supporto per flussi multi risoluzione attraverso gli
ATO e gli STO precedentemente descritti. Le reservations avvengono alle base
station per la parte wireless e negli switch ATM per la parte fissa
dell’infrastruttura. Nel primo caso si parla di mobile soft-state, che viene stabilito
tra ogni dispositivo e un QoS Renegotiation Point (QRP); nel secondo stato si
parla di network hard-state, che viene stabilito tra il QRP e l’infrastruttura di rete
fissa. L’allocazione delle risorse necessarie è dunque affidata alla rete ATM per
l’infrastruttura fissa ed ai livelli di trasporto, rete e data link precedentemente
descritti per la parte wireless della rete.
6.2.4 Supporto per la mobilità
Mobiware prevede un complesso sistema di gestione per le migrazioni dei
dispositivi da un dominio all’altro (chiamato handoff), descritto in [CAMP 96].
L’algoritmo di gestione dell’handoff è progettato in maniera tale da:
•
Poter gestire flussi bidirezionali – un dispositivo può essere sia mittente
che ricevente di un dato flusso
208
Capitolo 6
•
Fornire un veloce reinstradamento delle connessioni
•
Limitare quanto più possibile il numero di re-instradamenti e riconnessioni
durante la gestione dell’handoff
•
Consentire il funzionamento del massimo numero possibili di dispositivi
durante le procedure di handoff mediante l’utilizzo degli ATO e degli STO
per adattare i flussi alla banda disponibile.
La procedura di handoff in Mobiware avviene in tre fasi: inizializzazione, path
setup e path teardown.
INIZIALIZZAZIONE DELLA PROCEDURA DI HANDOFF
Un dispositivo mobile decide di effettuare un handoff in base ad algoritmi
residenti sul dispositivo stesso che valutano la potenza del segnale e la
larghezza di banda disponibili su diverse base stations raggiungibili valutando
i messaggi beacon che periodicamente vengono inviate da queste in
broadcast. Una volta stabilita la nuova base station viene creato un canale per
il signalling (passi 1 e 2 della figura 6-3). Tale canale viene utilizzato per
scambiare i messaggi relativi alla reservation delle risorse e all’adaptation dei
contenuti.
FASE DI PATH SETUP
Il dispositivo inoltra la richiesta di handoff alla nuova base station (passo 3),
nella quale viene specificato il connection group del dispositivo ed i suoi
requisiti di QoS. Quindi lo switch cui fa riferimento la base station individua il
crossover switch attraverso cui passano i flussi diretto al dispositivo (passo 4).
Al passo 5 la richiesta di handoff viene inoltrata a tale switch, il quale a sua
volta inoltra la richiesta al routing anchor point (RAP), punto di ancoraggio
fisso per tutti i flussi del connection group del client. A questo punto se tutti
gli elementi coinvolti nell’handoff possono ammettere i requisiti minimi di
QoS, al passo 6 si informa l’applicazione che le risorse sono state allocate
(handoff Ack) oppure che l’handoff è stato rifiutato (handoff Drop).
209
Capitolo 6
Il registro dei dispositivi della vecchia base station viene aggiornato al passo 7
(in caso di ack) con le informazioni della nuova base station del dispositivo
roamer.
FASE DI PATH TEARDOWN
In questa fase avviene lo switching dei flussi dalla vecchia alla nuova base
station. Mobiware prevede un complesso meccanismo di scambio, per cui può
accadere che durante la transizione verso la nuova base station un dispositivo
può ricevere un flusso sia dalla vecchia che dalla nuova base station. Gli
switch etichettano le celle ATM in modo che poi il dispositivo possa scartarle.
Il motivo di questo apparente spreco di risorse (adottato solo quando il roamer
è ricevente del flusso) sta nel fatto che il dispositivo stesso potrebbe in un
breve intervallo di tempo avviare una nuova procedura di handoff e tornare
alla vecchia base station. In tal caso le reservations preesistenti, che vengono
liberate dopo un certo timeout, sarebbero con molta probabilità ancora
presenti, aumentando la velocità dell’handoff. Lo switching può iniziare solo
dopo la creazione del nuovo soft state tra il dispositivo ed il suo nuovo QRP,
che avviene al passo 8.
In figura 6-3 vengono riportati i diversi passi della procedura di handoff.
Figura 6-3 – Passi della procedura di handoff in Mobiware
210
Capitolo 6
6.3 Monads
Monads è un’architettura software basa su agenti adattativi che si propone
l’obiettivo di fornire comunicazioni efficienti e qualità del servizio ad utenti
nomadici che lavorano con computer portatili, PDA, smartphones, telefoni
cellulari o altri dispositivi wireless collegati mediante un punto d’accesso ad una
rete fissa, come mostrato in figura 6-4.
Monads è strutturato in maniera tale da:
•
Adattarsi dinamicamente alle caratteristiche dei diversi tipi di terminali
mobili ed alla variabilità delle condizioni di rete
•
Tenere il sistema operativo anche in caso di disconnessioni dei terminali
•
Ottimizzare l’utilizzo della larghezza di banda sui collegamenti wireless
•
Fornire una API di semplice utilizzo agli sviluppatori per lo sviluppo di
agenti mobile-aware
•
Supportare le comunicazioni con software legacy (sviluppato senza
utilizzare agenti Monads)
Di conseguenza l’infrastruttura fornisce i seguenti vantaggi agli utenti nomadici:
•
Maggior efficienza nell’utilizzo delle applicazioni preesistenti
•
Un framework per lo sviluppo di applicazioni interamente basate sulla
piattaforma monads
•
Ottimizzazione della gestione del collegamento wireless rispetto a costi e
tempi di risposta
6.3.2 Architettura
Gli elementi chiave dell’architettura di Monads sono mostrati in figura 6-4 e
descritti in [RAAT 99].
I mobile hosts sono connessi all’infrastruttura di rete fissa mediante connessioni
wireless. Gli Access node sono dislocati sull’edge dell’infrastruttura e forniscono
servizi di connettività per i mobile hosts.
211
Capitolo 6
I service node sono dislocati all’interno dell’infrastruttura e forniscono servizi sia
agli utenti nomadici che agli utenti di rete fissa.
Figura 6-4 – configurazione di riferimento di Monads
L’architettura a livelli degli elementi salienti di Monads precedentemente descritti
è riportata in figura 6-5. Ai livelli più bassi si nota subito che la connessione tra
gli host di rete fissa avviene attraverso i protocolli standard di trasporto (TCP/IP)
e per lo scambio di messaggi inter-ORB (IIOP), mentre tra gli host mobili ed i
gateway (gli Access nodes) si utilizza il protocollo MDCP (Mowgli Data Channel
Protocol), descritto in dettaglio [KOJO 97]. Tale protocollo è stato studiato per
servizi di trasporto e signalling su reti wireless caratterizzata da bassa larghezza di
banda ed alto tasso d’errori.
Al livello superiore risiede l’agent platform, conforme alle specifiche FIPA
(Foundation for Intelligent Physical Agents).
I servizi di comunicazione, insieme a tutti gli altri servizi non mostrati in figura,
interagiscono sia con l’agent platform che con i protocolli di comunicazione.
Questo gruppo di servizi include il servizio di gestione della QoS (Quality of
Service Management), che fornisce un’interfaccia agli agenti per recuperare dati
sulla performance della rete, ed è utilizzato per informare gli agenti sullo stato dei
212
Capitolo 6
servizi di rete. In altri termini un agente può sottoscriversi ad un servizio di eventi
netwrok-related utilizzando l’Event Service, anch’esso facente parte del gruppo
dei communication services. Gli agenti inoltre possono utilizzare tale servizi per
controllare esplicitamente i servizi di rete.
Figura 6-5 – visione d’insieme dell’architettura di Monads
Si noti che l’host mobile non sempre è in grado, per la limitatezza delle sue
risorse, di ospitare una agent platform.
Monads prevede due possibili soluzioni: i terminal connection agents (TCA) e gli
user connection agents (UCA).
I primi possono essere utilizzati su dispositivi che non hanno abbastanza potenza
elaborativa e di memoria per ospitare la piattaforma ad agenti, come piccoli PDA
o palmari. Attraverso un agent control tool però possono dialogare con il TCA
sulla rete fissa che avvia gli agenti utili per l’applicazione sul dispositivo mobile. I
secondi (UCA) vengono utilizzati per dispositivi di potenza estremamente ridotti,
come i telefoni cellulari. L’utente comunica con l’UCA mediante messaggi
(magari SMS), e quindi l’UCA provvede ad attivare gli opportuni agenti richiesti
per completare il task.
213
Capitolo 6
In Monads è utilizzato un approccio alternativo per la specifica ed il
mantenimento della qualità del servizio. La gestione della qualità del servizio è
infatti puramente dinamica e basata non sulla reservation di risorse, ma sulla
prediction dei livelli di qualità del servizio nel prossimo futuro. Data la predizione
gli agenti possono prendere quindi decisioni adattative. Dunque non esiste una
vera e propria fase di specifica e negoziazione della QoS, gli agenti utilizzano
direttamente il QoS management service per recuperare il livello corrente di QoS,
quello predetto entro un certo tempo T e prendono decisioni di conseguenza.
Nessuna assunzione è fatta sulla predictability per latenza e throughput dei
collegamenti wireless, ma le comunicazioni vengono ottimizzate per assicurare la
maggiore performance possibile. Nel seguito verranno analizzate separatamente
gli aspetti di ottimizzazione della comunicazione in ambienti wireless e la
prediction della qualità del servizio.
COMUNICAZIONE OTTIMIZZATA IN AMBIENTI WIRELESS
La comunicazione tra agenti può essere divisa in quattro livelli, come riportato in
[RAAT 99]:
1. Interaction Protocol Layer – contiene protocolli di alto livello per
interazioni tra le parti comunicanti: anziché mandare numerosi messaggi
di piccole dimensioni, secondo quanto riportato in [RAAT 99], accorpare i
messaggi insieme in un unico messaggio incrementa l’efficienza
dell’utilizzo del link.
2. Communication language layer – definisce il contenuto dei messaggi
scambiati tra le parti: viene ottimizzato mediante la compressione del
contenuto dei messaggi.
3. Message transport layer – si riferisce a protocolli di messaging come
HTTP,GIOP e Java RMI: tali protocolli sono inefficienti in ambienti
wireless, in quanto sono contraddistinti da un notevole overhead.
4. Transport and Signaling Protocol Layer – lavora sui meccanismi del
livello trasporto della rete, e quindi si riferisce a protocollo come TCP/IP e
214
Capitolo 6
MDCP: i protocolli standard come TCP o UDP sono inefficienti in
ambiente wireless in quanto non forniscono trasparenza rispetto alla
location dei disposititivi. Attraverso il protocollo MDCP viene fornita tale
trasparenza unitamente ad un servizio di trasporto efficiente ed affidabile,
capace di selezionare tra i diversi protocolli di trasporto, il più efficiente
relativamente al contesto nel quale il dispositivo si trova.
PREDICTION DELLA QOS
Le modalità in cui avviene la predizione del servizio in Monads sono descritte in
[MISIK 99]. Si osserva che i meccanismi di adaptation reattivi non sono
sufficienti per gestire l’adattatività a fronte di variazioni nei livelli di QoS: ad
esempio se viene persa la connessione un meccanismo reattivo non può far nulla,
mentre un meccanismo predittivo può individuare il rischio di caduta della
connessione ed intraprendere opportune azioni.
Disporre di una previsione accurata dei livelli di QoS nel prossimo futuro è
tuttavia praticamente impossibile. In Monads tale previsione, approssimata, viene
effettuata attraverso la predizione degli spostamenti dei terminali e la predizione
della QoS ad una data location in un dato momento. Il sistema di predizione della
QoS di Monads può fornire risposte a domande del tipo: “Quale quantità di dati
sarò in grado di trasferire nei prossimi k secondi con una probabilità del p%?”.
Il Qos Prediction Agent determina la predizione della QoS, utilizzando il route
modeler agent, che tiene traccia degli spostamenti tipici dell’utente nomadic ed il
QoS modeler agent, che osservando valori percepiti della QoS cerca di trovare,
mediante algoritmi di learning una funzione che rappresenti il variare della stessa
in funzione del tempo e dello spazio (location).
In [MISIK 99] sono riportati dei risultati sperimentali che mostrano un errore
nella predizione decrescente al crescere dei dati storici accumulati dai servizi di
logging.
6.3.4 Supporto per la mobilità
Il principio della QoS prediction viene utilizzato anche per fornire un supporto per
la gestione della mobilità dei dispositivi. In [MAK 00] viene descritto come il
215
Capitolo 6
meccanismo di predizione degli spostamenti dei devices, basato sul Route modeler
agent, cerca di ricostruire gli spostamenti tipici degli utenti in funzione del tempo,
in modo da poter prevedere quando probabilmente verrà effettuato un handover.
In [MAK 00] infatti si assume che è impossibile realizzare un roaming seamless
se gli handover avvengono in maniera unexpected.
6.4 UBIQoS
UBIQoS è un application-level middleware studiato per la misura, il controllo e
l’adattamento dei livelli di QoS nei servizi di Video on Demand (VoD).
Le caratteristiche principali di UBIQoS sono:
•
ubiquitous accessibility – i flussi VoD possono essere ricevuti ovunque; la
qualità del servizio del video viene automaticamente misurata ed adattata
secondo le preferenze dell’utente, le periferiche d’accesso (PC portatili,
palmari, telefoni cellulari,…) e le risorse di rete disponibili.
•
ubiquitous middleware – I componenti di UBIQoS si diffondono
dinamicamente nel sistema, grazie agli agenti mobili infatti i componenti
del middleware si distribuiscono autonomamente sugli host lungo il
percorso dalla sorgente dei flussi VoD fino ai riceventi.
UBI QoS supporta il dimensionamento dei livelli di qualità del servizio durante la
negoziazione e l’adattamento degli stessi livelli durante la fornitura del servizio
VoD in funzione dello stato del sistema e della rete nel percorso di distribuzione
del flusso VoD. L’adattamento può riguardare sia i contenuti trasmessi, e quindi
ad esempio la variazione del frame rate o della risoluzione del video, oppure il
path tra sorgente e destinatario del flusso stesso. Nel primo caso il tipo di
adattamento scelto (ad esempio modificare la risoluzione piuttosto che il tasso di
trasmissione dei frames) dipende dalle preferenze espresse dall’utente.
6.4.2 Architettura
216
Capitolo 6
L’infrastruttura di rete di UBIQoS è divisa in domini. Ogni dominio è costituito da
un solo gateway (che può essere replicato per esigenze di fault tolerance) e da un
certo numero di stubs (client o server), e proxies. L’organizzazione in domini di
UBIQoS si evince dalla figura 6-6., tratta da [UBI HTTP]
Di seguito vengono descritti i principali componenti dell’architettura di UBIQoS,
riportati anche in figura 6-6:
•
ubiQoS client stubs – inoltrano le richieste dei client ai componenti
UBIQoS e redirigono i flussi RTP (real-time transport protocol) ai tools di
visualizzazione locali in maniera trasparente, in modo da poter utilizzare la
piattaforma UBIQoS con i visualizzatori VoD esistenti.
•
ubiQoS server stubs – rispondono alle richieste di servizio dai componenti
UBIQoS incapsulando i flussi VoD in flussi RTP.
•
ubiQoS proxies – sono distribuiti lung oil percorso di distribuzione del
servizio VoD. Effettuano il controllo di ammissione e la reservation delle
risorse per i flussi in ingresso ed in uscita. Sono dotati in un monitor per lo
stato delle risorse locali e possono avviare operativi di adattamento della
QoS locali. Possono inoltre interagire con i componenti UBIQoS a loro
prossimi nel percorso di distribuzione sia nella fase di negoziazione che in
quello di fornitura del servizio, quando cambiano sensibilmente le risorse
a disposizione nel sistema.
•
ubiQoS gateways – rappresentano una estesione dei proxies. Vi
aggiungono funzioni di coordinazione inter-dominio e servizi di naming.
E’ l’unico componente nel dominio ad avere completa visibilità dei domini
adiacenti e di tutti i componenti (stubs, proxies) nel proprio dominio.
Inoltre i proxies ed i gateways al loro interno contengono ulteriori moduli per il
monitoraggio, la negoziazione e la gestione dinamica della qualità del servizio di
seguito descritti:
•
QoS Monitoring module – osserva lo stato delle risorse e dei servizi locali
al componente. Il modulo di monitoraggio controlla:
217
Capitolo 6
o le informazioni sui flussi RTP,
o le informazioni sull’invocazione di metodi e l’allocazione di
memoria della virtual machine Java utilizzata per implementare il
middleware.
o Indicatori di sistema come carico della CPU, collision rate dei
pacchetti di rete, etc. etc.
Figura 6-6 – domini, componenti e percorsi in UBIQoS
•
Admission Control module – mantiene informazioni su tutti i flussi VoD
che attraversano il componente in cui è ospitato. Per ogni flusso viene
memorizzato un identificatore univoco per il flusso stesso, una n-pla di
requisiti di QoS associati al flusso e l’identificatori dei componenti
confinati nel percorso di distribuzione del flusso. Questo modulo decide di
accattare o rigettare nuove richieste di flussi VoD secondo le informazioni
fornite dal modulo di monitoraggio.
•
Accounting module – effettua il logging del livello di QoS fornito ai
differenti riceventi dei flussi. Si occupa dell’autenticazione degli utenti. Il
log è locale e ne esiste uno per ogni componente UBIQoS nel percorso del
218
Capitolo 6
flusso VoD è può essere utilizzato off-line per la fatturazione dei costi agli
utenti.
•
QoS Manager module – imposta il livello di QoS per i successivi
componenti nel percorso verso il ricevente. Combina i requisiti di QoS
degli utenti e dei terminali con i dati di reservations forniti dal
componente relativo al controllo d’ammissione.
•
The QoS Adaptation module – viene gestito dal QoS manager con lo scopo
di preservare il livello di QoS da questi impostato. Utilizza codec per
convertire i flussi VoD in flussi MPEG i cui parametri di qualità sono
specificati a runtime. Possiede dei buffers per i flussi VoD in modo da
rispondere prontamente a richieste provenienti da clients.
I livelli di QoS desiderati per la fruizione di un flusso VoD vengono specificati
come intervalli nei valori di determinati parametri come frame rate e resolution.
E’ compito del QoS Manager, per ogni componente nel percorso di distribuzione,
scegliere il punto più appropriato nello spazio individuato dai requisiti. I client
specificano preferenze di priorità sui parametri, indicando quali parametri
desiderano siano presi in considerazione per primi dal QoS manager, ed inviano ai
componenti del middleware informazioni circa i propri terminali (dimensione
schermo, carica batteria residua, livello di carico della CPU…). Queste
informazioni vengono memorizzate in un profilo, descritto in [CORR 03], che
viene memorizzato in un server Lightweight Directory Access Protocol (LDAP),
inglobato nel gateway di dominio.
Oltre alle esigenze dei client nella scelta del livello di QoS da mantenere si
considera anche la policy di utilizzo delle risorse dell’host corrente. In UBIQoS
sono definite esclusivamente due policies: una minimizza l’utilizzo di risorse
secondo una specifica funzione di costo, l’altra sceglie il livello di QoS che
massimizza l’utilizzo di risorse locali; in tal caso l’ingresso di nuovi flussi
219
Capitolo 6
richiede di modificare dinamicamente il livello di qualità del servizio accordato ai
flussi precedenti.
Come riportato in [CORR 03], il livello di QoS fornito ai flusso VoD può essere
modificato secondo il corrente stato del sistema e delle risorse di rete nel percorso
di distribuzione. Tali variazioni vengono «catturate» dal componente di
monitoraggio che avvia le operazioni di adattamento, che come anticipato
precedentemente, può riguardare sia i dati (transcoding, frame resizing, frame
resolution, frame rate,…) che il percorso di distribuzione stesso. Nell’ultimo caso
è necessario riavviare la fase di negoziazione e distribuire nuovi componenti
UBIQoS nella rete, in maniera tale che venga stabilito il livello di QoS per il
nuovo percorso. Tipicamente questa scelta viene presa quando uno dei
componenti del percorso di distribuzione diventa unavailable.
Le negoziazione della QoS iniziale e l’adaptation di tali livelli in UBIQoS sono
mostrate in figura 6-6. Durante la negoziazione, i differenti requisiti di user1 e
user2 hanno fatto sì che il server fornisca un video ad alta qualità a user1 ed uno a
qualità ridotta a user2. Si noti come il flusso viene ottimizzato, in maniera tale che
dal server fino al proxy del dominio 2 la qualità sia alta, mentre da questo punto in
poi si differenzia tra i due utenti, minimizzando così il numero di sdoppiamenti
del flusso necessari.
Durante la fornitura del servizio tutti i componenti nel percorso di distribuzione
possono effettuare l’adaptation dei livelli di QoS. Se addirittura non ci sono
risorse per adattare la qualità del servizio rispetto ai requisiti imposti, viene
modificato il percorso stesso. Si supponga che in figura 6-6 cada il server del
flusso. Il gateway del dominio 3 lancia quindi un discovery per trovare nuovi
server. Un nuovo server viene individuato nel dominio 4. Viene creato un nuovo
percorso dal proxy del dominio 2 al gateway de dominio 4 e viene negoziato un
nuovo livello di QoS.
Nel caso di mobilità dei dispositivi tra i diversi domini si adotta comunque il
processo di establishment di un percorso dal server alla destinazione e
negoziazione per host del livello di QoS da fornire all’host successivo.
220
Capitolo 6
6.5 Confronto con Esperanto
Le tecnologie middleware presentate nei precedenti paragrafi, pur fornendo tutte
una soluzione ai problemi connessi alla mobilità, presentano caratteristiche
profondamente diverse.
Tali differenze si riscontrano innanzitutto nel range di applicazioni supportate:
mentre Monads è una piattaforma di tipo general purpose, UbiQoS e Mobiware
sono specializzate per la distribuzione di servizi multimediali.
Nel seguito di questo paragrafo si porrà particolare attenzione alle modalità con
cui le piattaforme Mobiware, Monads e UbiQoS affrontano i problemi connessi
alla gestione della qualità del servizio e saranno evidenziate le differenze rispetto
alla soluzione adottata per Esperanto.
•
Specifica della QoS – Tutte le soluzioni presentate, ad eccezione di
Monads, forniscono dei metodi per specificare i livelli di QoS desiderati.
In Mobiware i requisiti di QoS vengono formulati utilizzando come unico
parametro la bandwith, specificando l’utility function e l’adaptation
policy, mentre in UbiQoS la QoS viene specificata utilizzando range di
valori ammessi per parametri di QoS tipici delle applicazioni multimediali,
come frame rate o image size. In Esperanto, middleware di natura più
general-purpose rispetto a Mobiware ed UbiQoS, le specifiche vengono
invece formulate rispetto alla latenza nell’esecuzione delle invocazioni
remote,alla percentuale di successo attesa ed alla criticità dell’interazione.
•
Negoziazione della QoS – Anche in questo caso Monads non fornisce
alcun supporto. Il QoS prediction agent fornisce una predizione della QoS
che gli agents possono poi utilizzare per decidere se intraprendere o meno
una comunicazione con un certo livello di QoS. La politica adottata in
Mobiware è invece basata sulle utility functions ed un principio di
«equità»: la base station assegna ai flussi una larghezza di banda tale che
tutti gli utenti percepiscano la stessa utilità. UbiQoS utilizza un sistema
221
Capitolo 6
simile al protocollo RSVP: il messaggio di richiesta viene inviato al
provider, che poi si occupa di effettuare il controllo d’ammissione le
reservation su tutti i nodi intermedi di distribuzione sul path tra requestor
e provider. Esperanto utilizza una distribuzione di probabilità log-normale
costruita in base ai valori di latenza osservati per verificare se i requisiti
possano essere soddisfati. Unico fra tutti i middleware elencati, Esperanto
introduce il concetto di criticità nella negoziazione della QoS.
•
Realizzazione della QoS – Mobiware prevede sofisticati meccanismi
basati sull’infrastruttura ATM sottostante il middleware e sull’utilizzi
degli ATOs e STOs (Active e Static transport objects). Nell’infrastruttura
si realizza l’hard state che garantisce in maniera hard il base layer, mentre
ATOs e STOs realizzano il mobile soft state che si occupa di fornire, se
possibile, gli enhancement layers. Monads definisce uno stack protocollare
per ottimizzare le comunicazioni tra i dispositivi mobili, mentre UbiQoS
utilizza protocolli di trasporto come RTP (Real-time Protcol). Esperanto, a
differenza delle altre soluzioni, non fornisce alcun supporto per la qualità
del servizio nei collegamenti wireless. La QoS viene garantita nei
mediator, sfruttando le caratteristiche real-time dei livelli sottostanti
(ORB, sistema operativo, protocolli di trasporto). I meccanismi per
garantire lai QoS nei link wireless in Esperanto sono ancora oggetto di
ricerca e saranno integrati in futuro nei meccanismi di negoziazione,
monitoraggio e realizzazione della QoS.
•
Adattatività alle variazioni del contesto – Mobiware e UbiQoS, progettati
per applicazioni multimediali, forniscono un supporto basato sull’utilizzo
di filtri per variare la qualità del flusso multimediale in funzione del livello
corrente di QoS. L’adattatività in Mobiware è realizzata dagli oggetti ATO
e STO, che tengono conto delle utility functions e delle adaptation policies
specificate dalle applicazioni, mentre in UbiQoS è realizzata dai proxy che
adattano il contenuto multimediale trasmesso. Monads ed Esperanto
222
Capitolo 6
invece utilizzano un approccio alla context awareness di tipo applicationaware. In Monads la predizione della QoS fornisce alle applicazioni
informazioni in base alla quali possono effettuare l’adaptation, mentre in
Esperanto i componenti addetti alla gestione della QoS notificano
esplicitamente i peers delle variazioni nei livelli di QoS, che portano alla
revoca dei Service level agreements. Il mediator di Esperanto gestisce le
proprie risorse in maniera tale da garantire quanto più possibile i requisiti
di QoS alle interazioni a maggiore criticità.
•
Supporto per la mobilità dei dispositivi – UbiQoS non fornisce alcun
supporto per gli spostamenti dei devices tra i diversi domini, mentre
Mobiware implementa un sofisticato algoritmo per gestire i cambi di base
station dei device che prevede un progressivo routing dei flussi dalla
vecchia alla nuova base station, al fine di garantire per quanto più
possibile la trasmissione seamless dei flussi multimediali. Monads anche
in questo caso si affida alla predizione degli spostamenti dei devices
mediante il route modeler agent, che, in base a dati storici, cerca di
effettuare una predizione circa i futuri spostamenti dei devices. La mobilità
invece in Esperanto viene gestita attraverso il protocollo HOPAM ed i
delegati, che cercano di trovare, in base ai livelli correnti di QoS, il giusto
trade-off tra la continuità delle interazioni e la non ingerenza delle
procedure di handover nelle interazioni tra gli altri peers.
Un quadro sinottico riportante le differenze nella gestione dei suddetti aspetti
nelle diverse soluzioni middleware presentate in questo capitolo ed Esperanto è
riportato in tabella 6-1.
In conclusione si può affermare che UbiQoS e Mobiware, data la loro natura
domain-specific orientata ai servizi multimediali, affrontano gli aspetti di gestione
della QoS in termini di qualità dei flussi multimediali e adattamento delle
trasmissioni ai livelli di qualità del sistema. UbiQoS, a differenza di Mobiware,
non prevede un supporto per la mobilità dei devices. Tale supporto in Mobiware,
progettato per fornire un servizio continuativo ai devices, porta ad una
223
Capitolo 6
sovrallocazione di risorse per il device roamer, che può ricevere lo stesso flusso
sia dalla vecchia che dalla nuova base station.
ESPERANTO
Specifica
della QoS
Utilità percepita
in funzione della
bandwith a
disposzione;
adaptation
policies
UBIQOS
Applicazioni per
la trasmissione
di
flussi
multimediali
MONADS
MOBIWARE
Range di
applicazioni
supportato
Qualunque
applicazione
Applicazioni per
la trasmissione di
flussi
multimediali
Qualunque
applicazione
Non prevista
Range ammessi
per alcuni
parametri tipici
del VoD
Massima latenza
ammessa nelle
invocazioni,
percentuale di
successo e
criticità
Utilizzo di CDF
log-normali per
assegnare una
classe di servizio
Negoziazione
della QoS
Assegnazione
«equa» delle
risorse alle
applicazioni
Non prevista
Reservations
progressivamente
effettuate sui
nodi del path
Realizzazione
della QoS
Infrastruttura di
rete ATM;
Active e Static
Transport
Objects
Stack
protocollare
ottimizzato per
comunicazioni
tra dispositivi
mobili, QoS
prediction
Utilizzo di
protocollo di rete
real-time (RTP);
utilizzo di filtri
Classi di servizio
basate sui
meccanismi real
time offerti
dall’ORB
Adattatività al
contesto
Effettuata da
ATOs e STOs
Interamente
basata sulla
predizione della
QoS
Effettuata dai
proxy adattativi
presso ogni nodo
Rinegoziazione e
rimozione dei
SLA nel
mediator
Procedura di
handoff,
progressivo
routing dei flussi
Predizione degli
spostamenti con
QoS Route
ModelerAgent
Nessun supporto
Protocollo
HOPAM e
delegati
Mobilità dei
dispositivi
Tabella 6-1 – comparazione tra Mobiware,Monads,UbiQoS ed Esperanto
Monads, che come Esperanto è di natura general-purpose, adotta una soluzione
drasticamente diversa per gestire la qualità del servizio, basato su schemi di
predizione che fanno uso di knowledge base basate sul logging dei devices e di
algoritmi di learning. La bontà dell’intero sistema di gestione della qualità del
224
Capitolo 6
servizio è dunque subordinata alla possibilità di ottenere predizioni verosimili dei
livelli di QoS. Esperanto invece fornisce un supporto per la qualità del servizio
più «tradizionale», nel quale le applicazioni specificano i propri requisiti di QoS,
la core network effettua la negoziazione,assegna un service level agreement e
cerca di mantenerlo, ove possibile, applicando politiche adattative all’interno del
mediator stesso. La mobilità dei dispositivi viene gestita, a differenza di
Mobiware, cercando un equilibrio tra la necessità di garantire continuità alle
interazioni in cui è coinvolto il roamer e la necessità di non sottrarre eccessive
risorse alle altre interazioni in corso nei domini interessati dalla migrazione.
Esperanto, a differenza delle altre soluzioni, non fornisce al momento alcun
meccanismo per garantire qualità del servizio sui link wireless.
6.6 Conclusioni
La qualità con la quale un servizio viene offerto è ormai un aspetto di
fondamentale importanza non solo per i sistemi mission critical ma anche per il
vasto mondo dei sistemi business. Gli utenti spesso non si accontentano di
ottenere esclusivamente un servizio ma desiderano che questo sia fornito con
determinati livelli di qualità del servizio. Questa problematica è stata esacerbata
dalla recente repentina diffusione delle tecnologie di comunicazione wireless, cui
è collegato lo sviluppo del mercato dei PDA, che da semplici «agende
elettroniche» si sono trasformati in vere e proprie suite di comunicazione, e dei
telefoni cellulari, basti pensare agli innumerevoli servizi aggiunti alla mera
comunicazione.
In questa tesi è stato affrontato il progetto di un sistema di gestione della qualità
del servizio per il mediator di Esperanto. Il mediator è il «cuore» della
piattaforma Esperanto: si occupa di gestire il delivery delle informazioni
scambiate tra i peers.
Un sistema di gestione della qualità del servizio richiede che vengano affrontate
non poche problematiche. In primo luogo bisogna scegliere un modello di qualità
225
Capitolo 6
del servizio, ovvero definire i parametri di QoS di interesse per il sistema ed in
qual modo si intende garantirli alle applicazioni. Nel mediator questo problema è
stato risolto adottando un modello a classi di servizio basato sulla latenza delle
invocazioni tra peers: una richiesta in base ai suoi requisiti di QoS viene
instradata su una particolare classe di servizio, che garantisce determinate
prestazioni. Il modello adottato per il mediator è di tipo statistico: i requisiti
imposti dalle applicazioni non vengono garantiti deterministicamente, ma si
ammette un certo rilassamento sulla percentuale di deadlines mancate.
Un’altra fondamentale problematica da gestire e la specifica e negoziazione della
qualità del servizio. In Esperanto i peers specificano i propri requisiti di qualità
del servizio indicando la massima latenza ammessa nell’usufruire di una
determinata funzionalità, la probabilità di successo desiderata (Es.: esecuzione del
metodo foo di dummy entro 1320 ms con una probabilità di successo del 90%) e la
criticità che assume l’interazione per chi la richiede. La negoziazione viene
effettuata dallo SLA Manager in base ai valori correntemente osservati nel
mediator da un apposito sistema di monitoraggio, il System Monitoring Service.
La valutazione di una CDF log-normale valuta la fattibilità dei requisiti.
Altri due aspetti fondamentali sono l’adattatività al contesto ed il supporto per la
mobilità dei dispositivi, soprattutto in una piattaforma studiata per interazioni tra
peers nomadici. Il mediator di Esperanto utilizza un sistema di monitoraggio e
controllo che osserva i tempi di delivery relativi ad ogni interazione e lo stato
globale delle classi di servizio per valutare il rispetto dei requisiti di QoS per ogni
interazione ed individuare possibili situazioni di saturazione delle classi di
servizio e rinegozia o rimuove i service level agreements concessi notificando le
applicazioni circa le variazioni di QoS che implicano la non rispettabilità dei
requisti imposti.
Per quanto concerne il supporto per la mobilità dei devices, soggetti all’handover
tra i diversi domini, il sistema della gestione della qualità del servizio aggiunge
alle funzionalità del protocollo HOPAM dei behaviours non funzionali, il cui
226
Capitolo 6
scopo è quello di ottimizzare il trasferimento delle informazioni dal vecchio al
nuovo dominio nel quale il device entra.
Tuttavia non è stato possibile portare a termine in questa tesi il lavoro di progetto.
La gestione della qualità del servizio resta confinata al mediator, e quindi alla
core network. Non è stato possibile estendere la gestione della qualità del servizio
all’intera piattaforma Esperanto: al momento non sono in alcun modo contemplate
le caratteristiche di qualità dei collegamenti wireless, (in termini di latenza di
round trip time, bandwith, failure rate,…) e le informazioni relative allo stato dei
singoli device (in termini di capacità elaborative, potenza residua della batteria…).
Il principale futuro sviluppo del sistema di gestione della qualità presentato in
questa tesi è l’estensione all’intera piattaforma Esperanto. Quello presentato in
questa tesi va visto, nell’ottica dei futuri sviluppi, come un tassello sulla strada
complessa ma non per questo impraticabile, della fornitura di qualità del servizio
end-to-end in un middleware per nomadic computing.
227
Sintassi dei Quality description languages di QuO
Appendice A
APPENDICE A
Sintassi dei Quality Description Languages di QuO
A.1 Contract definition language (CDL)
Un contratto QuO, come anticipato nel capitolo 2, specifica i diversi livelli di
qualità del servizio che possono essere riscontrati in un sistema e i comportamenti
da adottare quando i livelli di QoS misurati variano.
I seguenti componenti definiscono un contratto QuO:
•
Regioni operative o stati, ognuna delle quali rappresenta un possibile
livello di qualità del servizio. Ad ogni regione è associato un predicato che
ne indica lo stato (attivo o meno), mentre uno stato include un insieme di
coppie (predicato, stato) indicando in quale stato passa il contratto in
seguito al verificarsi di un determinato predicato.
•
Transizioni tra le regioni (o stati) , indicanti i comportamenti da adottare
quando vi sono variazione nella regione (o stato) attivo.
•
Riferimenti a oggetti System condition per misurare e controllare la qualità
del servizio. Possono essere passate come parametro al contratto o
dichiarate localmente ad esso. Le System conditions vengono utilizzate
nella valutazione dei predicati (funzione di misura) ma anche nelle
transizioni per effettuare le azioni adattative (funzione di controllo).
•
Oggetti callback per inviare notifiche, sono passati al contratto come
parametri e sono utilizzati nelle transizioni di regione.
Analogamente al modello per i contratti descritto nel capitolo 4, le regioni
costituiscono una gerarchia: ogni regione può avere un certo numero di regioni
figlie e così via.
I contratti QuO supportano anche gli stati. Utilizzando stati e predicati il contratto
può evolvere come una macchina a stati finiti. Tuttavia questo tipo di utilizzo dei
contratti QuO non è di particolar interesse nell’implementazione dell’internal
228
Appendice A
contract e dell’external contract per il mediator Esperanto e non sarà
ulteriormente approfondito. Ulteriori dettagli possono essere trovati in [BBN
02b], [LOYAL 98] e [PAL 00].
Verrà ora introdotta la sintassi del linguaggio CDL.In figura A-1 sono
rappresentati i principali elementi sintattici di un contratto descritto in CDL.
contract <name> ( <args> ...)
{
<vars> ...
region <name> <predicate> <until_clause> { <nested regions> ...}
transition <transition_description> { <behavior> ... } |
};
Figura A-1 – Struttura di un contratto QuO
La definizione di un contratto inizia con la keyword contract, seguita al nome
della classe del contratto e dagli argomenti, che sono oggetti System Condition e
callback, che hanno vita propria all’esterno del contratto stesso.
Gli argomenti del contratto possono avere la forma seguente:
•
System condition – syscond [nowatch] <idl_type> <impl_type>
<name>
•
Callback – callback <idl_type> <name>
Dove idl_type è la classe IDL dell’oggetto, name è il nome con cui l’oggetto viene
referenziato e impl_type è il nome della classe in cui la System Condition è
implementata. L’opzione nowatch indica se il contratto viene notificato o meno in
seguito variazioni sulla System Condition. In un contratto è inoltre possibile
specificare, come parametri o variabili locali, anche sequenze di System condition
mediante la keywork syscond_seq. Le System conditions locali al contratto
vengono inserite nella sezione vars.
La definizione di una regione inizia con la keyword region, seguita da un nome,
un’espressione rappresentante il predicato ed un corpo racchiuso tra le parentesi
graffe. All’interno del corpo vengono definite le sottoregioni. Nel caso in cui
vengano utilizzate le sequenze di System conditions invece la definizione della
regione ha una sintassi diversa:
229
Appendice A
region <name> region_seq <iterator> <expression>
L’iteratore specifica quali sequenze di System Conditions utilizzare per
l’espressione. Viene creata automaticamente una sottoregione per ogni System
Condition nella sequenza.
I predicati sono espressioni booleane calcolate a partire dai valori delle System
Conditions collegate al contratto e da valori costanti. Nei predicati è ammesso
l’utilizzo di tutti gli operatori relazionali e logici. Il CDL introduce inoltre due
nuovi operatori, every e some, da utilizzare con le sequenze di System
Conditions. L’elenco completo degli operatori per i predicati è riportato in tabella
A-2.
Famiglia
Relazionali
Logici
Iterativi
Operatori
<,>,<=,>=,==,<>
and,or,not
Descrizione
Operatori relazionali standard
Operatori logici standard
Utilizzo:
(every | some) <iterator>
<relative_expression>
Every: restituisce true se tutti gli elementi
nell’iteratore soddisfano l’espressione
Some: restituisce true se almeno uno degli
elementi nell’iteratore soddisfa l’espressione
every, some
Tabella A-2 – operatori ammessi nella formulazione dei predicati
Come riportato in tabella A-2 la sintassi per le espressioni booleane che utilizzano
gli operatori every e some implica l’utilizzo di un iteratore, la cui sintassi è:
[element] <iteration_vars> [in] <iteration_seqs>
In cui:
•
Iteration_vars è una lista di uno o più identificatori che saranno utilizzati
per istanziare uno (o più) loop sulle sequenze di System conditions
•
Iteration_seqs rappresenta la sequenza (o le sequenze) di System
Conditions utilizzate per valutare il predicato.
E’ possibile definire i predicati in maniera tale che ad un certo istante più predicati
possano essere attivi. E’ opportuno però che ad ogni istante solo una regione sia
attiva per ogni livello della struttura. Infatti il CDL non specifica metodi per
scegliere quale regione sia attiva nel caso in cui più predicati siano veri e quali
230
Appendice A
transizioni considerare in tal caso.
Una volta descritto il contratto in termini di regioni e predicati, restano da definire
esclusivamente le transizioni tra le regioni, che realizzano i behaviours adattativi.
Una transizione descrive il comportamento da invocare in seguito ad una
variazione nelle regioni attive o nello stato di un contratto. Non è necessario
specificare transizioni per tutte le possibili variazioni di regione attiva (date N
regioni sarebbero necessarie N(N-1) transizioni).
Le transizioni possono essere definite utilizzando i nomi delle regioni oppure
utilizzando le parole chiave any ed inactive nel seguente modo:
transition <src_region> -> <dest_region>
{
Synchronous { <method_call>, ... }
Asynchronous { <method_call>, ... }
}
Utilizzando la parola chiave any come regione di partenza la transizione viene
applicata quando si entra nella regione di arrivo qualunque sia la regione di
partenza. Se invece any viene utilizzata come regione di arrivo la transizione
viene applicata quando si esce dalla regione di partenza qualunque sia la regione
di destinazione. La parola chiave inactive invece viene utilizzata per specificare le
transizioni da effettuare quando un contratto non ha nessuna regione attiva
(condizione che si verifica se tutti i predicati sono falsi).
Ovviamente non sono valide transizioni del tipo any->any, any->inactive,
inactive->any, inactive->inactive.
Le transizioni possono invocare metodi su oggetti callback o System Condition
precedentemente dichiarati nel contratti. Le invocazioni possono essere di tipo
sincrono o asincrono. Se si scelgono le invocazioni sincrone, il contratto attenderà
il completamento della transizione prima di poter essere nuovamente valutato.
A.2 Adaptive specification language (ASL)
Il delegato QuO viene generato utilizzando l’Aspect-oriented Structure Language.
Per la generazione è necessaria la descrizione IDL (Interface Definition
231
Appendice A
Language) CORBA dell’interfaccia del delegato, la descrizione in ASL dei
comportamenti adattativi e la descrizione in CDL del contratto (o dei contratti)
valutati per stabilire quali aspetti adattativi realizzare.
Il generatore di codice confronta le interfacce IDL con i behaviors ASL definiti. Il
delegato viene generato se esiste un interfaccia IDL il cui nome corrisponde a
quello di un behavior ASL. Se per alcuni metodi dell’interfaccia IDL non viene
definito alcun advice il delegato non farà altro che passare l’invocazione
direttamente all’oggetto remoto. Altrimenti genererà un nuovo metodo con la
stessa signature di quello remoto, ma che realizzerà i behaviors descritti nel
codice ASL nei diversi joinpoints definiti.
I joinpoints e gli advice in ASL sono identificati considerando:
•
La signature del metodo remoto nel quale si vogliono calare i
comportamenti adattativi.
•
Il punto preciso nel percorso d’invocazione del metodo nel quale gli
aspetti devono essere inseriti (chiamata, ritorno, eccezione) .
•
La regione del contratto utilizzato dal delegato.
Un descrittore ASL è essenzialmente diviso in due sezioni:
•
Include statements – istruzioni nella forma standard #include
<filename> che inserisce comportamenti da altri files come se fossero
definiti nel descrittore corrente
•
Behaviour list – le definizioni vere e proprie dei comportamenti adattativi
La definizione di un comportamento adattativo inizia con la parola chiave
behavior seguita da un nome mnemonico. La descrizione di un behavior passa
attraverso le seguenti fasi:
⇒ Dichiarazione delle variabili di istanza
Le variabili di istanza (instance variable) vengono espresse nella forma:
<role> <type> <name>
Dove name è il nome assegnato alla variabile che sarà usato nella definizione
del comportamento adattativo, type è un tipo CORBA (tipo IDL standard o
232
Appendice A
interfaccia IDL definita dall’utente), mentre role può assumere uno dei
seguenti valori:

remote_object – oggetto remoto sui cui metodi si applicano i
comportamenti adattativi nei pointcuts specificati.

qosket – il qosket contenente contratti, System Conditions ed
descrittori ASL da riutilizzare (cfr. paragrafo 2.5.4).

contract – il contratto da utilizzare per il delegato.

ivar – dichiarazione di una variabile locale per il delegato.
Il generatore di codice QuO, si occuperà poi del mapping dei tipi utilizzati.
⇒ Dichiarazione dei metodi
All’interno della sezione behavior vengono dichiarati i metodi sui quali si
desidera applicare gli advice. Un metodo viene dichiarato nella seguente
forma:
<type> <name> <args>
{
<aspects>
}
Dove type, name ed args identificano la signature completa del metodo ed
aspects può contenere la dichiarazione di ulteriori variabili (che saranno locali
al metodo del delegato), designatori di pointcuts e regioni, e gli advice.
Le variabili d’istanza del metodo vengono dichiarate nella stessa forma delle
variabili d’istanza del behavior, con la differenza che in questo caso role può
assumere uno dei seguenti valori:

return_value – variabile utilizzata per mantenere il valore restituito dal
metodo

signal – variabile usata per memorizzare informazioni da inviare al
contratto durante la sua valutazione

local – variabile locale al metodo del delegato
⇒ Designazione dei pointcuts
I pointcuts identificano i punti nei quali vengono inseriti gli advice. Nell’ASL
di QuO vengono definiti i seguenti pointcuts:
233
Appendice A

Methodentry – ingresso nel metodo del delegato

Premethodcontracteval – punto in cui viene valutato il contratto prima
dell’invocazione del metodo

Methodcall –invocazione del metodo

Postmethodcontrateval – punto in cui viene valutato il contratto dopo
il ritorno dal metodo

Methodreturn – punto di ritorno nel metodo del delegato
I pointcuts vengono preceduti da un qualificatore che indica dove deve essere
inserito l’advice. I possibili valori per i qualificatori sono:

Before – prima dell’esecuzione dell’azione o invocazione associata al
pointcut

After – dopo l’esecuzione dell’azione o invazione associata al pointcut

Inplaceof – in luogo dell’azione (ad esempio inplaceof methodcall
<aspect> sostituisce l’invocazione del metodo con il codice ASL
dell’aspect)

Onexception – caso particolare utilizzato per gestire comportamenti
adattativi nel caso di eccezioni causate dall’invocazione del metodo
remoto. Per ulteriori approfondimenti si rimanda a [BBN 02b]
⇒ Dichiarazione delle regioni
La designazione di una regione avviene nella seguente forma:
region <name>
{
<advice>
}
Nel caso di regioni annidate si utilizza la seguente forma:
region <rootName> {
region <child1Name> { <advice> }
region <child2Name> { <advice> }
…
region <childnName> { <advice>}
}
⇒ Definizione degli advices
L’advice costituisce il codice che viene inserito nel delegatoposto specificato
234
Appendice A
dai pointcuts, ed eseguito nel caso specificato dalle regions. Un’advice puoò
contenere:

Chiamate di funzione

Operazioni di assegnazione di variabili (locali al metodo o al behavior)

Codice nativo (Java o C++)
In tal modo viene completamente specificato un comportamento adattativo che
riguarda determinati metodi di una particolare interfaccia. Gli aspetti adattativi
vengono inseriti in punti specifici (specificati dai pointcuts con i loro
qualificatori) e vengono eseguiti secondo la particolare regione attiva nel contratto
valutato dal behavior. Secondo il qualificatore del pointcut un advice può eseguire
attività preparatorie all’esecuzione di un metodo, complementari all’esecuzione
dello stesso o può sostituire l’invocazione di un metodo (con l’utilizzo del
qualificatore inplaceof) con dei comportamenti adattativi.
235
Bibliografia
Bibliografia
[ACE http] Adaptive Communication Environment (ACE) website,
http://www.cs.wustl.edu/~schmidt/ACE.html
[ALPERT 03] Alpert, C.J.; Liu, F.; Kashyap, C.; Devgan, A.; “Delay and slew
metrics using the lognormal distribution”, Proceedings of the Design Automation
Conference, 2003. , Giugno 2003
[BARB 95] Barbacci M., Klein M., Longstaff T., Weinstock C.; “Quality
Attributes”, technical report CMU/SEI-95-021, Dicembre 1995
[BBN 02] “QuO Toolkit User’s Guide”, rev 3.0.10 - BBN Technologies, 2002
[BBN 02b] “QuO Toolkit Reference Guide”, rev. 3.0.10- BBN Technologies,
2002
[BBN http] Quality Object (QuO) website, http://quo.bbn.com
[BIANCHI 98] Bianchi G. , Campbell A.T., Liao R.R.; “Supporting Utility-Fair
Adaptive Services in Wireless Networks”, Proc. of 6th International Workshop on
Quality of Service, Maggio 1998.
[BIANCHI 98b] Bianchi G.,Campbell A.T., “A Programmable MAC”, ICUPC
'98, Firenze, Ottobre 1998.
[BOCHM 97] Bochmann, G. v., Hafid, A; “Some principles for quality of service
management”, Distributed Sytsems Engineering vol.4 ,IOP Publishing 1997
[CAMPBELL 97b] Campbell A.T.;"Mobiware: QOS-Aware Middleware for
Mobile Multimedia Communications", 7th IFIP International Conference on High
Performance Networking, Aprile 1997.
[CHAL 99] Chalmers D., Sloman M ; “Survey of Quality of Service in Mobile
Computing Environments”, Research Report 8/10, Department of Computing,
Imperial College, London, Febbraio 1999
[CORR 03] Corradi A., Bellavista P.; “Mobile Middleware Solutions for the
Adaptive Management of Multimedia QoS to Wireless portable
Devices”,Proceedings of the Ninth IEEE International Workshop on ObjectOriented Real-Time Dependable Systems,2003
[COTR 04] M. Cinque, D. Cotroneo, C. Di Flora, A. Migliaccio and S. Russo;
“ESPERANTO: a Middleware Platform to Achieve Interoperability in Nomadic
Computing Domains”, To appear in Proceedings of the 3rd ACS/IEEE Int. Conf.
on Computer Systems and Applications (CSA), Gennaio 2005
[CROSS 02] Cross, J.K.; Schmidt, D.C.; “Meta-programming techniques for
distributed real-time and embedded systems”, Proceedings of the Seventh
International Workshop on Object-Oriented Real-Time Dependable Systems,
2002,Gennaio 2002
236
Bibliografia
[KLEI 95] Bagrodia, R., Chu, W.W., Kleinrock, L., Popek, C.; “Vision, issues,
and
architecture
for
nomadic
computing”
,
IEEE
Personal
Communications, Volume: 2 , Issue: 6 , Dicembre 1995
[KOJO 97] Kojo M., Raatikainen K., Liljeberg M., Kiiskinen J., Alanko T.; “An
Efficient Transport Service for Slow Wireless Telephone Links,” IEEE Journal on
Selected Areas in Communications, Vol. 15, no. 7, Settembre 1997.
[LAZAR 92] Lazar, A.A.; "A Real-Time Control, Management and Information
Transport Architecture for Broadband Networks", Proceedings of the 1992
International Zurich Seminar on Digital Communications, Marzo 1992
[LAZAR 97] Lazar A.A.; "Programming Telecommunication Networks", IEEE
Network, October 1997.
[LEE 03] Lee C.; Helal, A.; Desai, N.; Verma, V.; Arslan, B.;”Konark: A system
and protocols for device independent, peer-to-peer discovery and delivery of
mobile services” ,IEEE Transactions on Systems, Man and Cybernetics, Part A,
Volume: 33 , Issue: 6 , Novembre 2003
[LOYAL 03] Loyall J.P., Rubel P., Atighetchi M., Schantz, R.,Zinky J.;
“Emerging Patterns in Adaptive, Distributed Real-Time, Embedded Middleware.”
Navy Sea Systems Command, Open Systems Architecture IPT meeting, Maggio
2003.
[LOYAL 98] Loyall, J.P., Schantz, R.E., Zinky, J.A., Bakken, D.E, “Specifying
and measuring quality of service in distributed object systems”, First
International Symposium on Object-Oriented Real-Time Distributed Computing,
Aprile 1998.
[MAK 00] Mäkelä M., Koskimies O., Misikangas P.,Raatikainen K.; Adaptability
for Seamless Roaming Using Software Agents. In the XIII International
Symposium on Services and Local Access, Giugno 2000
[MIGL 03] Migliaccio A.; “Un approccio innovativo per il delivery di servizi in
infrastrutture di nomadic computing” , tesi di laurea in Ingegneria Informatica
presso l’università “Federico II” di Napoli, Ottobre 2003
[MISIK 99] Misikangas P., Mäkelä M., Raatikainen K.: Predicting QoS for
Nomadic Applications Using Intelligent Agents. In Impact '99 Workshop, 1999.
[OMG 01] Object Management Group; “The Common Object Request Broker:
Architecture and Specification”, rev. 2.4.2, Febbraio 2001
[OMG 02] Object Management Group; “Corba Components”, rev. 3.0, Giugno
2002
[PAL 00] Pal, P., Loyall, J., Schantz, R., Zinky, J., Shapiro, R,; Megquier, J.;
“Using QDL to specify QoS aware distributed (QuO) application configuration”,
Third IEEE International Symposium on Object-Oriented Real-Time Distributed
Computing, Marzo 2000
237
Bibliografia
[RAAT 99] Raatikainen K.., Hippeläinen L.., Laamanen A., Turunen M.: Monads
- Adaptation Agents for Nomadic Users.,World Telecom '99, 1999
[SCHM 00] Schmidt D.C., Kuhns F.; “An overview of the Real-time CORBA
Specification”, IEEE Computer Magazine, Giugno 2000
[SCHM 00b] Schimdt D.C., Stal M.,Rhonert H., Buschmann F.; “Pattern
Oriented Software Architecture“ , Volume 1, 2000
[SCHM 00c] Schimdt D.C., Stal M.,Rhonert H., Buschmann F.; “Pattern
Oriented Software Architecture“ , Volume 2, 2000
[SCHM 98] Schmidt D.C., Gill C., Levine D.; “The Design and performance of a
Real-Time CORBA Scheduling Service”, Real-Time systems journal 1999
[SCHMIDT 02] Schmidt D.C., Deshpande M., O’Ryan C.; “Operating Systems
Performance in Support of Real-time Middleware” , Proceedings of the Seventh
International Workshop on Object-Oriented Real-Time Dependable Systems,
2002, Gennaio 2002
[SCHMIDT 02b] Schmidt
D.C.,Cross J.K.; “Applying the Quality
ConnectorPattern to Optimize Distributed Real-time and Embedded
Middleware”, Patterns and Skeletons for Parallel and Distributed Computing,
Springer Verlag, Novembre 2002.
[SHIR 04] Shirazi B., Kumar M., Sung B.Y.; “QoS Middleware Support for
Pervasive Computing Applications”, Proceedings of the 37th Annual Hawaii
International Conference on System Sciences, Gennaio 2004.
[UBI HTTP] UBIQoS home page http://lia.deis.unibo.it/Research/ubiQoS/
[WANG 01] Wang N., Schmidt D.C., et. Al..; “QoS-enabled Middleware“,
Middleware for Communications, 2001
[WANG 04] Wang N., Gill C., Subramonian V., Schmidt D.C., “Configuring
Real-Time Aspects in Component Middleware”, to be presented at DOA 2004,
Ottobre 2004
[WEIS 96] Weiser M.,Brown J.; “Designing Calm Techonology”, Powergrid
Journal, Luglio 1996
238