Creazione e negoziazione di SLA per l'architettura CloudSensor

(1)

Computers are incredibly fast, accurate, and stupid.

Human beings are incredibly slow, inaccurate, and brilliant. Together they are powerful beyond imagination.

(2)

UNIVERSIT`

A DI PISA

Facolt`

a

di Ingegneria

Corso di Laurea in Ingegneria Informatica

Tesi di Laurea Specialistica

Creazione e negoziazione di Service Level Agreements

per l’architettura CloudSensor

Relatori

Prof. Marco Avvenuti

Ing. Alessio Vecchio

Candidato Luigi Arces

(3)

Sommario

In un’epoca in cui la comunicazione tra individui la fa da padrona, lo sviluppo di dispositivi dalle dimensioni sempre più ridotte, coadiuvato dall’impego di tecnologie di comunicazione sempre più veloci, non può far altro che stimolare ed aumentare la portata delle informazioni prodotte e scambiate da tali individui. Inoltre, la pos-sibilità di recuperare e produrre informazioni in qualunque posto ed in qualunque momento è oramai diventata una pratica comune. Tutto ciò scaturisce dalla mas-siccia diffusione dei dispositivi mobili avvenuta negli ultimi anni che ha a sua volta permesso lo sviluppo di applicazioni software un tempo impensabili e di difficile im-plementazione. Il fatto che ogni individuo abbia sempre con se un piccolo elaboratore e che tale macchina abbia la possibilità di ottenere informazioni specifiche, legate al luogo in cui attualmente si trova, ha permesso alle applicazioni context aware di emergere. A questa categoria appartengono i software che effettuano l’urban sensing, ovvero l’estrapolazione di informazioni acquisite tramite i sensori presenti sui dispo-sitivi, e che permettono la raccolta di dati ambientali associati ad una particolare area geografica. In tale contesto nasce il sistema CloudSensor, il quale opera come un repository per i dati, immagazzinando e fornendo informazioni alle entità che vi accedono. La mole di dati che un sistema di questo tipo si trova a gestire è elevata e, molto spesso, parte di queste informazioni possono rivelarsi di scarso interesse per un cliente interessato alla loro fruizione. Tutto questo porta alla necessità di definire un insieme di metriche e di garazie sulla qualità del servizio da applicare al blocco di dati fornito dal dispositivo mobile.

(4)

Ringraziamenti

Un profondo ringraziamento va alla mia famiglia che mi ha sostenuto durante tutta la carriera universitaria. Grazie a Valentina e a tutte quelle persone che quotidiana-mente mi sono accanto. Last but not least grazie al prof. Marco Avvenuti e all’ing. Alessio Vecchio per il supporto ricevuto durante la preparazione di questo lavoro di tesi e a tutti quei docenti che durante gli anni di universit`a hanno continuamente stimolato la mia crescita intellettiva.

(5)

Indice

Sommario I Ringraziamenti II 1 Introduzione 1 1.1 Stato dell’arte . . . 2 1.1.1 Cloud Computing . . . 2

1.1.2 Mobile Cloud Computing . . . 3

1.1.3 Mobile Phone Sensing . . . 4

2 Tecnologie di rifermento 6 2.1 Sensor Web Enablement . . . 6

2.1.1 Architettura SWE . . . 6

2.2 L’architettura del sistema CloudSensor . . . 7

2.2.1 Struttura ad alto livello . . . 8

2.2.2 Struttura CSS . . . 10

2.2.3 Struttura CSAMS . . . 13

3 Service Level Agreement 17 3.1 Il framework WS-Agreements for Java . . . 18

3.1.1 Architettura del Framework . . . 18

3.1.2 Lo standard WS-Agreement . . . 19

3.1.3 Agreement Factory Service . . . 20

3.1.4 Agreement Service . . . 20

3.1.5 Il linguaggio WS-Agreement . . . 20

3.1.6 Monitoraggio dell’Agreement . . . 22

3.2 Esempio di Service Level Agreement . . . 22

3.2.1 Tag Name e Context . . . 23

(6)

3.2.3 Tag ServiceProperties . . . 24

3.2.4 Tag GuaranteeTerm . . . 25

3.3 Wsag for Java Server . . . 26

3.3.1 Il package wsag4jcsams.jar . . . 26

3.3.2 Configurazione del server WSAG4J . . . 27

4 Teoria dei giochi e algoritmi utilizzati 30 4.1 La Teoria dei Giochi . . . 30

4.2 Il problema dello zaino e le Flow Auctions . . . 33

4.2.1 Il problema dello zaino . . . 33

4.2.2 Flow Auctions . . . 34 4.3 Il modello matematico . . . 35 4.3.1 Terminologia . . . 35 4.3.2 Il problema . . . 35 4.4 Complessit`a computazionale . . . 36 4.5 L’Algoritmo . . . 37 4.5.1 Pseudocodice . . . 38 4.5.2 Un esempio . . . 38 4.6 Il gioco . . . 40 4.6.1 Le entit`a coinvolte . . . 41

4.6.2 Le fasi del gioco . . . 41

4.6.3 Le funzioni di utitlit`a . . . 41

4.6.4 Le strategie del buyer e dei sellers . . . 42

4.6.5 L’equilibrio . . . 45

4.7 Un esempio . . . 46

5 Service Level Agreement Manager (SLAManager) 48 5.1 Implementazione . . . 48

5.2 Il formato delle richieste . . . 50

5.2.1 I parametri delle richieste . . . 51

5.3 Database di supporto . . . 52 5.3.1 Tabella users . . . 53 5.3.2 Tabella proposals . . . 53 5.3.3 Tabella serviceterms . . . 53 5.3.4 Tabella marketplace . . . 54 5.3.5 Tabella appcliets . . . 54 5.3.6 Tabella c2dmregid . . . 55 5.3.7 Tabella negotiations . . . 55 5.3.8 Tabella agreements . . . 56 5.4 SLAManagerInterface . . . 56

(7)

5.4.1 Funzionalit`a . . . 56

5.4.2 Organizzazione del codice sorgente . . . 56

5.5 SLAManagerLogin . . . 57

5.6 SLAManagerAdmin . . . 59

5.7 SLAManagerSDC . . . 60

5.7.2 Wsag4Java Client . . . 63

5.8 SLAManagerSDP . . . 64

5.8.2 Wsag4Java Client . . . 66

5.9 SLAManagerEngine . . . 68

5.10 Service Terms . . . 71

5.10.1 Definizione ed implementazione dei Service Terms . . . 71

5.10.2 Service Terms implementati . . . 71

5.10.3 Reward e Penalty . . . 72

5.10.4 Coverage . . . 72

5.10.5 SensingTime . . . 73

5.10.6 GpsSensor e CarrierSignalSensor . . . 73

5.11 Esempio di creazione di un nuovo Service Term . . . 73

6 MyCsams 75 6.1 Creazione, visualizzazione e modifica di un SLA . . . 75

6.2 Il processo di negoziazione . . . 77

6.2.1 Cloud to Device Messaging Service (C2DM) . . . 78

6.2.2 Configurazione dell’applicazione e della strategia di negoziazione 79 7 Conclusioni e sviluppi futuri 81 7.1 In conclusione . . . 81

7.2 Sviluppi futuri . . . 82

(8)

Elenco delle figure 84

Elenco delle tabelle 86

(9)

Capitolo

1

Introduzione

Questo lavoro di tesi si propone di estendere l’architettura CloudSensor mediante l’integrazione di un nuovo componente chiamato SLAManager, che permetterà la creazione e la negoziazione di Service Level Agreements. I Service Level Agreements non sono altro che dei contratti stipulati tra due o più entità grazie ai quali è pos-sibile specificare un insieme di termini e di garanzie sulla qualità del servizio offerto o richiesto. L’ambito teorico in cui si colloca il lavoro tesi è quello del mobile and pervasive computing. Il mobile computing richiede che il dispositivo su cui avviene la computazione sia connesso ad internet o ad una infrastruttura di rete privata in modalità wireless. Tale connessione serve ad accoppiare il dispositivo mobile ad un servizio di informazioni centralizzato e/o ad applicazioni software. Dispositivi quali laptops, smartphones e tablets stanno diventando pervasivi, le loro capacità compu-tazionali aumentano di continuo e le loro dimensioni diminuiscono. L’uso combinato di tali tecnologie permette agli utenti di accedere ad informazioni personali e a risorse pubbliche in qualunque momento e da qualunque posto. Con il termine pervasività si intende inoltre un modello di interazione uomo-macchina in cui l’elaborazione del-le informazioni è interamente integrata all’interno di oggetti e attività comuni. Una definizione per il termine pervasive computing è: the creation of environments sa-turated with computing and communication capability, yet gracefully integrated with human users, e quindi la creazione di ambienti in cui si è circondati da dispositivi in grado di effettuare computazioni e scambiare informazioni. Seguendo le raccoman-dazioni fornite dalla teoria del mobile and pervasive computing è stato sviluppato il sistema CloudSensor (Seri-Filia) punto di partenza di questo lavoro di tesi. Il sistema CloudSensor rappresenta un middleware incaricato di integrare i dispositivi mobili nella rete Internet, con lo scopo di supportare le richieste per il recupero di dati ambientali forniti dai sensori presenti sugli smartphone. Due differenti tipologie di clients accedono a tale sistema: i Sensor Data Publisher (rappresentati dagli smart-phones), incaricati alla pubblicazione di dati rilevati mediante sensori, ed i Sensor

(10)

1 – Introduzione

Data Consumer (rappresentati da applicazioni in esecuzione su macchine fisse), che invece ricevono i dati pubblicati sul CloudSensor. Un tipico scenario di utilizzo può essere rappresentato da un cliente che contatta il sistema CloudSensor perchè interes-sato ad effettuare una campagna di sensing. Il sistema, per soddisfare tale richiesta, recluta un insieme di smartphones ai quali richiede l’invio periodico di rilevazioni ambientali effettuate tramite i sensori presenti sul dispositivo. Grazie all’estensione effettuata è ora possibile selezionare, per ogni campagna di sensing, un insieme di vincoli e di garanzie sulla qualità del servizio offerto/richiesto, permettendo inoltre alle entità coinvolte di negoziaziarli. Altro aspetto interessante riguarda proprio il processo di negoziazione, effettuato al fine di creare un Service Level Agreement. Questo processo è completamente automatizzato dal nuovo componente introdotto ed è stato modellizzato come un gioco strategico. Ciò ha permesso lo sviluppo di un algoritmo che, seguendo le raccomandazioni espresse dalla teoria dei giochi, permette alle entità coinvolte di selezionare strategie ottimali durante le fasi di negoziazione.

1.1 Stato dell’arte

Per comprendere meglio le finalit`a e l’ambito operativo del presente lavoro, vengono di seguito illustrati i concetti base riguardanti l’interazione tra reti di sensori e applicazioni distribuite.

1.1.1 Cloud Computing

Con Cloud Computing si intende un insieme di teconologie informatiche che per-mettono l’utilizzo di risorse hardware e software distribuite in remoto. Il Cloud Computing si presenta come un paradigma orientato alla realizzazione del cloud, cio`e una piattaforma di calcolo che viene offerta, attraverso una rete a banda larga, a clienti che necessitano di ingenti risorse computazionali, secondo il tipico schema client-server. Il cloud offre quindi servizi e risorse all’utente, senza che quest’ultimo sia a conoscenza delle caratteristiche delle risorse e dell’implementazione dei servizi. Si distinguono tre tipologie di ruoli fondamentali:

• fornitore dei servizi: offre servizi e risorse, sia hardware che software

• cliente amministratore: configura i servizi offerti dal fornitore per adattarli alle esigenze del cliente finale

• cliente finale: utilizza i servizi offerti dal fornitore, opportunamente configu-rati dall’amministratore.

(11)

1 – Introduzione

• client layer: hardware e software lato client che si limita a rappresentare localmente l’esecuzione di un servizio remoto e ad inoltrare verso il cloud i comandi dell’utente. In questo caso si parla anche di thin client.

• application layer: `e composto dalle applicazioni sul cloud, che nel loro insie-me formano il cosiffetto Software as a Service (SaaS), che offrono il software come un servizio eseguibile in remoto su Internet, senza necessit`a da parte dell’utilizzatore di installare ed eseguire un’applicazione sul proprio dispositivo.

• platform layer: detto anche Platform as a Service (PaaS), `e concettualmen-te simile al SaaS, con la differenza che viene fornita una piattaforma soft-ware remota, che pu`o essere usata dall’utilizzatore per sviluppare le proprie applicazioni.

• infrastructure layer: detto anche Infrastructure as a Service (IaaS), permet-te l’utilizzo di risorse hardware in remoto

• server layer: risorse hardware e software lato server, tramite le quali viene implementato il cloud,

1.1.2 Mobile Cloud Computing

Con il termine Mobile Cloud Computing si intende l’uso combinato di tecniche di Cloud Computing e di dispositivi mobili. Di particolare interesse è il cosiddetto Sensor as a Service (SaaS), cioè la possibilità di usufruire tramite il cloud del-le informazioni ambientali ottenute da tali dispositivi. Servizi di questo tipo so-no detti context-aware: si tratta di applicazioni distribuite in grado di fornire un risultato a partire da informazioni di contesto riguardanti l’ambiente circostante. Un’applicazione context-aware prevede due attori principali:

• context provider: entit`a che produce le informazioni di contesto, ad esempio un determinato sensore

• context consumer: enti`a che richiede e riceve le informazioni di contesto.

Un’applicazione context-aware ha lo scopo di fornire un determinato risultato; in base a tale finalit`a `e possibile distinguere due categorie:

• context information source: l’applicazione si limita a memorizzare le infor-mazioni ricevute in strutture dati permanenti, mettendole a disposizione, tra-mite un meccanismo di interrogazioni dette context-query, di un’applicazione cliente che le utilizzer`a per trarre conclusioni circa fenomeni di interesse

• context synthesis service: l’applicazione analizza ed elabora i dati raccolti per fornire direttamente un servizio complesso all’applicazione cliente.

(12)

1 – Introduzione

Generalmente è utile disaccoppiare le due entità mediante l’utilizzo di una infrastrut-tura middleware, che raccoglie le informazioni da più providers e le offre al consumer attraverso una specifica API.

1.1.3 Mobile Phone Sensing

Un sottoinsieme dei servizi context-aware è dato dalle applicazioni Mobile Phone Sensing (MPS), cioè da applicazioni distribuite che utilizzano informazioni di con-testo provenienti da smartphone, in particolare dai sensori integrati in essi. In base all’utilizzo che viene fatto dei dati raccolti, è possibile distinguere tre diverse tipologie di servizi:

• personal sensing: i dati raccolti dallo smartphone forniscono risultati di interesse esclusivamente per l’utente possessore dello smartphone.

• group sensing: i dati raccolti da ogni smartphone vengono messi a dispo-sizione di un gruppo ben definito di utenti che partecipano ad un’attivit`a comune

• community sensing: i dati raccolti da un numero rilevante di smartphone sono utilizzati per offrire un servizio di pubblica utilit`a, come ad esempio un’a-nalisi del traffico cittadino. In questo caso all’utente possessore del dispositivo deve essere garantito un determinato livello di privacy, in quanto il servizio non deve avere alcun interesse riguardo l’identit`a del produttore di informazioni.

Un ulteriore classificazione pu`o essere fatta in base al ruolo che l’utente svolge nel processo di rilevazione dati, in particolare per quanto riguarda il grado di control-lo che il possessore del dispositivo ha sulla partecipazione del proprio smartphone all’applicazione:

• participatory sensing: l’utente ha la possibilit`a di gestire e regolare il flusso di informazioni raccolte e rese disponibili dal dispositivo

• opportunistic sensing: l’utente si limita ad avviare l’applicazione sul proprio smartphone, senza avere nessun tipo di controllo sulle informazioni che vengono prodotte.

Noi considereremo applicazioni che seguono il paradigma di participatory sensing, con il vantaggio che l’utente pu`o stabilire quando e come fornire dati evitando ad esempio l’invio di informazioni non necessarie o inutilizzabili da parte del servizio. L’utente ha inoltre maggiore controllo sulle risorse proprie dello smartphone: ad esempio, pu`o fissare una soglia massima alla frequenza di rilevazioni, permettendo un minore uso della batteria del dispositivo, e alla frequenza di invio dei dati al

(13)

1 – Introduzione

centro di raccolta, gestendo cos`ı l’utilizzo della connessione wireless. Il principale svantaggio riguarda proprio il ruolo ’attivo’ svolto dall’operatore umano nel proces-so: `e infatti necessario che l’utente abbia un minimo grado di conoscenza del servizio cui partecipa per poter configurare adeguatamente il proprio dispositivo. Il modello di opportunistic sensing dispensa l’utente da ogni compito gestionale, facendo si che venga prodotto un flusso continuo ed ininterrotto di informazioni: se da un lato questo fatto permette all’applicazione di ottenere dati senza alcun vincolo tempora-le da rispettare, dall’altro pu`o produrre un notevole overhead di informazioni non necessarie allo scopo.

(14)

Capitolo

2

Tecnologie di rifermento

In questo capitolo esamineremo le tecnologie di riferimento alla base di questo lavoro di tesi. Discuteremo del sistema di acquisizione di dati tramite sensori, basato sul framework SWE (Sensor Web Enablement) e chiamato CloudSensor. Analizzeremo nel dettaglio la sua architettura ed il funzionamento dei moduli componenti.

2.1 Sensor Web Enablement

Il framework Sensor Web Enablement (SWE) `e utilizzato per implementare il ser-vizio di raccolta dei dati provenienti dai sensori e ha lo scopo di definire interfaccie di interoperabilit`a e codifiche di metadata che permettano l’integrazione di reti di sensori eterogeneri all’interno dell’infrastruttura di rete, portando avanati un proces-so di standardizzazione avviato dall’Open Geospatial Conproces-sortium (OGC). In questo modo applicazioni e servizi saranno in grado di accedere a sensori di qualsiasi tipo-logia attraverso reti come Internet usando le stesse tecnologie e gli stessi protocolli sui quali si basa il Web.

2.1.1 Architettura SWE

Le principali funzionalit`a offerte da SWE riguardano il discovery dei sensori, il pro-cesso di tasking e lo scambio ed elaborazione delle osservazioni prodotte dai sensori. Il processo di discovery permette il rilevamento automatico di istanze di sensori pre-senti in rete, mentre il tasking regola la produzione di osservazioni da parte di tali sensori. Con il termine osservazione si intende una misurazione di fenomeni am-bientali effettuata dal sensore e codificata secondo un formato standardizzato. Nel seguito si far`a riferimento ad un un’applicazione cliente che utilizza i servizi offerti dal SWE per accedere alle osservazioni prodotte e comandare operazioni di tasking sui sensori. Attualmente sono definiti i seguenti standard e le seguenti interfacce:

(15)

2 – Tecnologie di rifermento

• Observations & Measurement (O&M): specifica modelli e schemi XML standard per codificare le osservazioni fornite da un sensore, sia archiviate sia real-time.

• Sensor Model Language (SensorML): specifica modelli e schemi XML standard per descrivere sistemi di sensori e processi associati alle osservazioni dei sensori; fornisce le informazioni necessarie per il processo di discovery dei sensori, per conoscere la locazione delle osservazioni ed elaborarle, e per listare le propriet`a dei task attivabili.

• Transducer Model Language (TML): specifica modello concettuale e sche-mi XML standard per descrivere i trasduttori (sia ricevitori che trasmettitori), i dati da essi prodotti, i fenomeni misurati e i metadata di supporto, e per fornire il supporto allo straming real-time dei dati da e verso i sistemi di sensori.

• Sensor Observation Service (SOS): definisce un’interfaccia standard per la richiesta, il filtraggio e il recupero delle osservazioni e delle informazioni su sistemi di sensori; agisce da intermediario tra un database di osservazioni e un’applicazione cliente.

• Sensor Planning Service (SPS): definisce un’interfaccia standard che per-mette la gestione di sistemi di sensori, ad esempio richiedendo; agisce da inter-mediario tra un’applicazione cliente e un ambiente di gestione di un insieme di sensori

• Sensor Alert Service (SAS): definisce un’interfaccia standard che permette all’applicazione cliente di registrarse e ricevere in maniera asincrona dai sensori messaggi che notificano la produzione di osservazioni.

• Web Notification Service (WNS): definisce un’interfaccia standard che permette all’applicazione cliente di comunicare con altri servizi quali il SAS e il SPS, in modo asincrono tramite scambio di messaggi.

2.2 L’architettura del sistema CloudSensor

Il sistema CloudSensor `e stato sviluppato per permettere l’integrazione dei dispositi-vi mobili, e quindi dell’insieme di sensori in essi presenti, nella rete Internet. Grazie a questa architettura `e possibile accedere agli smartphone mediante i protocolli di rete preesistenti e quindi, nello specifico, recuperare i dati ambientali prodotti dai sensori in essi incorporati. I sensori costituiscono i componenti di una rete che acqui-sce nuovi nodi dinamicamente ed il sistema CloudSensor rappresenta un middleware che circonda la rete rendendola a tutti gli effetti un servizio web, e mediando le

(16)

integrazioni in ingresso e in uscita con le applicazioni clienti. Un altro scopo del sistema è dato dalla possibilità di creare un servizio in grado di supportare la ri-chiesta e il recupero di dati ambientali secondo un interfaccia HTTP standard che sfrutti dialetti XML per la codifica delle richieste di operazione e delle conseguenti risposte. In questo modo le entità utilizzatrici, già in grado di gestire sessioni HTTP, non devono subire adattamenti al proprio software per supportare nuovi protocol-li atti all’accesso al servizio reaprotocol-lizzato. Una terza caratteristica consiste nella sua alta scalabilità. I possibili utilizzi del sistema CloudSensor coprono uno scenario applicativo potenzialmente molto vasto. Nella sua formulazione di base, esso po-trebbe venire impiegato come un produttore e distributore di dati rilevati secondo modalità real-time per applicazioni di monitoraggio ambientale. Integrando poi al sistema un framework per la notifica asincrona degli eventi di produzione delle os-servazioni, in modo che le applicazioni clienti possano dichiarare il proprio interesse al monitoraggio di un insieme di fenomeni, si può facilmente ottenere un sistema publish-subscribe che esegua il dispatching di dati ambientali in rete. Utilizzi più evoluti del sistema CloudSensor potrebbero implicare un suo dispiegamento come piattaforma per la realizzazione di servizi environment-aware, ovvero dal comporta-mento dinamico regolato dalle variazioni di un ambiente che si intende monitorare. In questo contesto potrebbero rientrare servizi localizzati di monitoraggio del traffi-co, di percorso e delle condizioni atmosferiche, cos`ı come sistemi di allarme sensibili al movimento, servizi di navigazione urbana in base a itinerari calcolati staticamente o dinamicamente e social-network pervasivi.

2.2.1 Struttura ad alto livello

L’architettura Cloud Sensor pu`o essere suddivisa ad alto livello in due parti: un lato server, destinato a eseguire su calcolatori fissi, e un lato dispositivo mobile, dispiegato su smartphone con il supporto alla piattaforma Android. Sono definiti dunque il CloudSensor Service (CSS) ed il CloudSensor Acquisition & Management System (CSAMS). Tutte le interazioni fra applicazioni clienti e sistema, o fra parti remote del sistema, avvengono su sessioni HTTP standard. Ogni richiesta di operazione o risposta corrisponde ad un invio di parametri, codificati come documento XML. Il CSS costituisce il frontend del sistema nella sua accezione di middleware: ogni applicazione che ne fa utilizzo deve interfacciarsi direttamente con il CSS tramite un connessione HTTP avanzando una richiesta di operazione. Le operazioni esposte dal sistema CloudSensor sono un sottinsieme dell’unione di quelle rese disponibili dai framework SOS e SPS. I compiti specifici del CSS comprendono quindi nell’ordine:

• ricezione e controllo della correttezza sintattica delle richieste di operazione,

(17)

• inoltro dell richieste di operazione ai dispositivi mobili e ricezione delle conse-guenti risposte,

• costruzione delle risposte per le richieste,

• invio all’applicazione cliente dell risposte costruite.

Cos`ı come fra applicazioni clienti e CSS anche fra quest’ultimo e CSAMS la comu-nicazione avviene tramite protocollo HTTP, ricorrendo tuttavia ad una codifica che non richieda l’inclusione di documenti XML ma che descriva il tipo di operazione richiesta e i parametri associati mediante una query string. Il CSAMS rappresenta il backend del sistema CloudSensor, provvedendo all produzione delle informazio-ni che il CSS classifica e pubblica. In questa ottica il CSAMS si configura come una macrocomponente inaccessibile e invisibile dalle applicazioni clienti, che svol-ge computazioni per loro conto su mediazione del CSS. In svol-generale saranno attive contemporaneamente in rete molte istanze di CSAMS, ognuna delle quali esegue su uno smartphone e controlla un insieme di sensori rimanendo in attesa di richiesta di operazioni in arrivo dal CSS.

(18)

2.2.2 Struttura CSS

Il CSS rappresenta il lato server del sistema CloudSensor ed `e accessibile come un servizio web. Il suo funzionamento si basa sulla collaborazione tra istanze dei framework Sensor Observation Service (SOS) e Sensor Planning Service (SPS). I componenti del CSS sono :

• Sensor Planning Service (SPS)

• Sensor Observation Service (SOS)

• Naming Server (NS)

• SPS Plugin

• SOS Servlet

SOS e SPS

Il nucleo operativo del CSS è costituito dalle istanze dei servizi SOS e SPS. Sono in-fatti essi che contengono la logica necessaria alla gestione dei processi di tasking dei sensori, di codifica, classificazione e memorizzazione delle osservazioni. Le operazioni che il sistema CloudSensor, nella sua implementazione attuale, rende disponibili ai propri utilizzatori, sono rappresentate da un sottinsieme dell’unione delle operazioni di SOS e SPS. Occorre prestare attenzione al fatto che sia il SOS che il SPS per acquisire conoscenza dell’esistenza di un sensore, necessitano di esplicare un pro-cesso di registrazione con cui il dispositivo mobile che lo contiene richieda per esso l’assegnazione di un identificatore univoco e quindi il suo inserimento all’interno del documento di risposta ad una richiesta da parte del CSS. Tale processo viene in-nescato da ogni smartphone all’avvio del CSAMS. Al SOS è necessario far sapere che un sensore esiste come produttore di osservazioni, ovvero come entità che effet-tua inserimenti periodici di dati all’interno di una o più tabelle del database gestito dal framework, le operazioni da compiere sul SPS in fase di registrazione di sensori hanno invece una complessità maggiore. Il SPS infatti, a differenza del SOS, man-tiene al proprio interno informazioni di stato per ogni sensore che controlla. Queste informazioni vengono modellate come istanze di una classe Java, detta SPSPlugin, che prendono il nome di plugin e rapresentano la stuttura dati con cui il SPS astrae l’hardware dei sensori che gestisce, racchiudendo la logica funzionante da livello di adattamento all’interfaccia Sensor Web Enablement (SWE) offerta per ogni tipo di dispositivo. Un plugin si configura pertanto come lo strato software di mediazione fra SPS e i dispositivi mobili.

(19)

Naming Server

Nella realizzazione di un sistema che renda accessibili in rete sensori incorporati su dispositivi mobili, sorge un problema legato alla volatilità degli indirizzi IP. Dato che i moderni smartphone accedono alla rete mediante connessioni senza fili, è altamente probabile che, variando geograficamente la propria posizione, subiscano variazioni di indirizzo IP. Il fenomeno complica il recapito delle richieste di operazione dal CSS alle istanze di CSAMS, che normalmente avviene su sessioni HTTP a loro volta resi-denti su protocollo IP. Una possibile soluzione al problema implica l’indirizzamento dei dispositivi mobili per mezzo del loro numero telefonico, infomazione sicuramen-te statica nel sicuramen-tempo. Unendo quest’ultima osservazione alla necessità inderogabile di impiegare sessioni HTTP per metter in comunicazione le varie parti del sistema CloudSensor, si rende necessaria una mappatura dei numeri telefonici su indirizzi IP. In questa ipotesi, le associazioni <numero telefonico, indirizzo IP> relative a un dato smartphone, definite come binding, devono essere periodicamente aggiornate per rispecchiare correttamente le possibili variazioni dell’indirizzo IP. Inoltre ogni richiesta indirizzata a un dispositivo mobile avanzata al CSS implica una traduzione del numero telefonico, usato come parametro nel corrispondente indirizzo IP, proces-so trasparente alle applicazioni clienti autrici della richiesta e totalmente confinato all’interno del sistema. Il Naming Server è la componenete del CSS che esplica le azioni appena esposte. Modellato come una Java Servlet e quindi accessibile me-diante richieste HTTP standard, il Naming Server è un servizio web che gestisce una tabella di traduzione dei numeri telefonici in indirizzi IP e che espone ai suoi utilizzatori operazioni di registrazione, creazione di un nuovo binding del tipo <nu-mero di telefono, indirizzo ip>, risoluzione ovvero ottenere l’indirizzo IP conoscendo il numero di telefono, e cancellazione ovvero l’eliminazione del binding all’interno del Naming Server. Ogni binding ha un tempo di vita limitato al termine del quale viene eliminato dalla tabella, da qui nasce la necessità di rinnovare la registrazione periodicamente da parte delle istanze di CSAMS.

SPS Plugin

Il plugin è la struttura dati che contiene al suo interno lo stato di un sensore registrato al SPS e i metodi di gestione delle richieste SPS che esso supporta. Nel caso del sistema CloudSensor, i sensori a bordo degli smartphone possono essere astratti con una interfaccia comune, indipendentemente dal fenomeno che misurano. Ciò accade perchè ogni sensore supportato dal sistema viene considerato come un produttore di dati che può trovarsi in due stati differenti: attivato, se è stato oggetto di una richiesta e sta eseguendo un task, o disattivato se il task che eseguiva è terminato o è stato oggetto di una richiesta di cancellazione del task. In tale ipotesi non

(20)

`

e necessario differenziare la gestione delle operazioni SPS a seconda del fenomeno misurato ed `e quindi sufficiente un unico plugin, definito Android Plugin, per astrarre tutti i sensori degli smartphone che si intende registrare al sistema. Una variante dell’Android Plugin, progettato per astrarre una singola istanza di sensore, consiste nel Meta Plugin, che invece astrae tutti i sensori dediti alla misurazione di un certo fenomeno registrati al SPS. L’esistenza del Meta Plugin virtualizza quindi una classe di sensori come un unico dispositivo, il quale, pu`o essere fatto oggetto delle operazioni SPS consuete. Il vantaggio di un simile approccio si manifesta nei casi in cui una applicazione cliente necessiti di osservazioni prodotte da un alto numero di sensori.

Figura 2.2: Astrazione di un sensore singolo mediante plugin

Figura 2.3: Astrazione di pi`u sensori mediante plugin

SOS Plugin

Il SOS Plugin `e la componente del CSS che riceve dalle istanze di CSAMS i dati grez-zi delle osservagrez-zioni e li codifica in documenti XML, secondo le specifiche stabilite, per poi effettuarne l’inserimento all’interno del database del SOS. Per dati grezzi si

(21)

intende una quadrupla di letterali alfanumerici che rappresentano: valori che quan-tificano il fenomeno misurato da un sensore, marca temporale che attesta l’istante di produzione dell’osservazione, identificatore SOS del sensore che ha prodotto l’os-servazione, identificatore del fenomeno misurato. Sfruttando queste informazioni il SOS Plugin confeziona osservazioni sottoforma di documenti XML. La presenza del SOS Plugin solleva le istanze di CSAMS, quindi i dispositivi mobili, dall’elaborazio-ne e formattaziodall’elaborazio-ne di documenti XML, operaziodall’elaborazio-ne spesso dispendiosa in termini di memoria e tempo di calcolo, riducendo il consumo di potenza e rendendo il sistema pi`u reattivo.

2.2.3 Struttura CSAMS

Il CSAMS è la macrocomponente che gestisce le elaborazioni sugli smartphone uti-mando l’esecuzione delle operazioni che le applicazioni cliente richiesto al sistema CloudSensor. Il CSS infatti inoltra le richieste di operazione alle istanze di CSAMS attive e queste, a loro volta, provvederanno a tradurle in chiamate ai driver per l’interfacciamento con i sensori dello smartphone su cui eseguono. Il CSAMS pos-siede un architettura stratificata, definita stack CSAMS, in cui ogni livello, dall’alto verso il basso, compie operazioni e adotta forme di descrizione dei dati sempre più vicine a quelle del supporto ai sensori offerto dal sistema operativo Android. I livelli che compongono lo stack CSAMS, elencati per profondità crescente nell’architettura sono i seguenti: • Feasibility Engine • Task Scheduler • Sensors Wrapper • SOS Buffer • SOS Feeder

Non vengono considerati facenti parte dello stack CSAMS, che comprende la logica necessaria allo svolgimento delle computazioni, le seguenti componenti, che svolgono invece funzioni di inizializzazione:

• Interfaccia utente

• Boot Loader

Tutte le componenti citate sono state progettate e realizzate per il funzionamento su piattaforma Android. Di seguito si fornisce comunque una descrizione specifica del loro funzionamento indipendente dall’implementazione.

(22)

Figura 2.4: Rappresentazione ad alto livello del CSAMS

Interfaccia utente (UI)

L’interfaccia utente rappresenta un frontend grafico per l’applicazione CSAMS. In-tegrando con la UI, l’utente dello smartphone su cui esegue il CSAMS pu`o:

• tarare i parametri di funzionamento dell’applicazione in base alle proprie pre-ferenze

• avviare il ciclo di vita dell’applicazione, rendendo a tutti gli effetti lo smart-phone un produttore di osservazioni

• controllare lo stato del ciclo di vita in termini di osservazioni prodotte e sensori attivati, se l’applicazione `e stata gi`a avviata.

I parametri impostabili mediante UI vengono acceduti dal Boot Loader che li impiega per inizializzare il funzionamento del CSAMS.

Boot Loader (BL)

Il Boot Loader non costituisce un livello operativo dell’architettura CSAMS quan-to piutquan-tosquan-to una procedura necessaria alla sua inizializzazione. Questa componente esplica infatti le registrazioni dei sensori ospitati dallo smartphone presso le compo-nenti SOS e SPS del CSS, innescando una serie di procedure. Inoltre, per tarare il funzionamento del CSAMS, il BL raccoglie le impostazioni fornite dall’utente dello smartphone circa:

• i sensori che, fra quelli disponibili sullo smartphone, potranno essere acceduti dal CSS

(23)

• i limiti inferiori in termini di periodo di misurazione che saranno utilizzati per decretare i task accettabili

• le modalit`a di invio dati verso il CSS.

• gli URL delle componenti CSS da indirizzare nel corso del ciclo di vita del CSAMS

Il processo di registrazione prevede la costruzione di documenti che descivano i sen-sori e che sono allegati alla richieste di registrazione del sensore che il BL rivolge alle istanze si SOS e SPS del CSS. Tuttavia se i sensori risultano gi`a registrati le richie-ste citate non vengono avanzate, evitando l’apertura di connessioni HTTP inutili e dispendiose.

Feasibility Engine

Il Feasibility Engine è la componente che riceve le richieste di operazione dal CSS e rappresenta per questo il livello più alto dello stack CSAMS. I suoi compiti prevedo-no: l’attesa di richieste di operazione, il parsing dei parametri operazionali e studio di fattibilità e la registrazione al Naming Server.

Task Scheduler

Il Task scheduler riceve dal Feasibility Engine le richieste di operazione e provve-de all’attivazione o disattivazione provve-dei sensori fisici. Il TS `e quindi il livello che, in maniera indipendente dal tipo di sensore che ne `e oggetto, instrada le richieste di operazione filtrate dal FE verso le componenti software loro attuatrici, il cui com-portamento invece dipende dalle caratteristiche del sensore che gestiscono. Inoltre il TS tiene traccia dei task attivi sul CSAMS mediante una task queue, struttura dati in cui per ogni sensore disopnibile si annota lo stato di funzionamento.

Sensors Wrapper

Il livello Wrapper rappresenta lo strato di interfaccia tra l’hardware del dispositivo monile, costituito da un tipo di sensore, e il resto dello stack CSAMS. Esso infatti traduce i parametri operativi dei task che il TS gli inoltra in, chiamate alle librerie per il comando dei sensori, in modo che questi producano osservazioni secondo un periodo e per un intervallo di tempo forniti dai parametri stessi. Considerata una singola istanza di CSAMS, in esecuzione su uno smartphone, esistono pertanto tante istanze di Wrapper quanti sono i tipi diversi di sensori ospitati dal dispositivo. Cia-scuno di essi gestisce in maniera specifica per il fenomeno misurato dal sensore con cui dialoga, l’evento di produzione di una nuova osservazione. Questa caratteristica consente la diversificazione delle elaborazioni che vengono compiute sui dati grezzi

(24)

ottenuti dai sensori a seconda del fenomeno rilevato, permettendo cos`ı una prima elaborazione non appena il dato viene prodotto. Effettyati quindi il raffinamento preliminare delle osservazioni grezze il Wrapper ne associa i valori numerici a una marca temporale, un identificatore del tipo di fenomeno osservato e un identificatore del sensore da cui sono stati prodotti, cos`ı costruendo la quadrupla di elementi che il CSAMS invia come output dei task eseguiti al CSS. Ogni Wrapper pertanto do-po aver recuperato e arricchito una nuova osservazione dai sensori, la invia al SOS Feeder, componente che ne curer`a la memorizzazione e invio verso il CSS.

SOS Feeder e SOS Buffer

Il SOS Feeder è la componente che riceve dai Wrapper le osservazioni e provvede al loro invio vero il database SOS del CSS. L’upload delle osservazioni può avve-nire secondo due modalità distinte, la scelta delle quali è rimandata all’utente del dispositivo mobile su cui il CSAMS è in esecuzione. Il SOS Buffer è la struttura dati deputata a contenere le osservazioni temporaneamente. SI noti che il SF non impiega il SB come un contenitore per tutte le osservazioni che riceve dai Wrap-per, ma vi ricorre solo per garantire ad esse persistenza in memoria in modo da poterle accede dopo periodi di inattività. L’upload delle osservazioni puo avvenire in maniera istantanea oppure in maniera periodica stabilendo un intervallo di tempo regolare in cui effettuare l’invio delle osservazione. Pertanto, mentre il Feasibility Engine rappresenta il punto di ingresso dei task inoltrati dal CSS, il SOS Feeder costituisce il punto di uscita delle osservazioni che essi producono.

(25)

Capitolo

3

Service Level Agreement

I Service Level Agreement (SLA) sono elementi contrattuali che definiscono formal-mente i parametri e i livelli di qualità che un servizio deve rispettare nella specifica erogazione verso un determinato cliente. Oltre alla definizione dei livelli di quali-tà del servizio, uno SLA può abilitare la definizione dei diritti e degli obblighi di entrambe le parti, i requisiti di sicurezza del servizio nonchè le caratteristiche delle tecniche di monitoring o di adattamento da attuare per garantire la corretta im-plementazione del SLA stesso. Appropriati linguaggi formali basati su XML sono stati progettati per consentire la definizione di SLA in tutti i suoi elementi. Du-rante la sua implementazione, un SLA può collezionare evidenze circa il rispetto dei requisiti che definisce, individuare possibili disservizi e scatenare logiche di notifica o adattamento al fine di garantire i requisisti contrattati, oppure evidenziare le de-ficenze del servizio per consentire al cliente la riscossione delle penali previste nel contratto. Per garantire la più corretta implementazione rispetto alle esigenze del cliente e ridurre al minimo le possibilità di generare contenziosi, un SLA dovrebbe specificare i vincoli attraverso parametri definiti allo stesso livello di astrazione del servizio oggetto della fornitura e dovrebbe essere direttamente interpretabile. Il pri-mo obiettivo di un linguaggio che definisce SLA è di fornire la capacità di esprimere, con il massimo grado di precisione, le caratteristiche qualitative e quantitative di un servizio. Attraverso questo linguaggio, le parti coinvolte nel contratto possono formulare rapidamente e con precisione il livello di un particolare servizio ed offrirlo al tempo stesso. Altri risultati rilevanti sono la possibilità di far riferimento ad uno standard, che tutti sono in grado di comprendere ed utilizzare, realizzare in maniera semplice il confronto fra le diverse offerte, pubblicizzare e recuperare informazioni sulle diverse offerte, ragionare sulle proposte di servizio, in modo da capire cosa si possa offrire e ricevere ed infine controllare facilmente le garanzie della qualità del servizio. I principali requisiti per raggiungere tali obiettivi sono:

(26)

3 – Service Level Agreement

descrizione qualitativa di un servizio

• Composizionalit`a: in un ambiente multi-domino, un servizio potrebbe essere il risultato di una cooperazione tra le diverse entit`a del dominio. I servizi possono essere dissociati o aggregati, quindi, i fornitori del servizio dovranno essere capaci di comporre SLA in modo da formulare nuove offerte per i clienti.

• Validazione: prima di iniziare un SLA, i contraenti devono essere in grado di validarlo, verficando la sua sintassi e la sua coerenza.

• Monitoraggio: idealmente, le parti dovrebbero essere capaci di controllare au-tomaticamente se i livelli del servizio stabiliti in un accordo vengono effettiva-mente forniti dai suoi fornitori ed analogaeffettiva-mente i livelli del servizio forniti ai propri clienti sono stati soddisfatti.

• Imposizione: una volta che vengono concordati i livelli del servizio, possono essere configurati router di rete, sistemi di gestione dei database, middleware e WebServer per far rispettare SLA in modo automatico utilizzando tecniche come cache, replica, clustering e farming.

In genere un SLA viene negoziato da due entità distinte: un customer o consumatore del servizio, ed un service provider o fornitore del servizio. I Service Level Agree-ments sono quindi utilizzati per stabilire un comune understanding, fra le entità coinvolte, sui servizi, sulle priorità, sulle responsabilità e sulle garanzie fornite/ri-chieste. In questo lavoro di tesi verrà estesa l’architettura CloudSensor per consentire la creazione, la gestione ed il monitoraggio dei Service Level Agreements. La ne-cessità di stipulare un contratto tra le entità coinvolte in una campagna di sensing, nasce dalla volontà di stabilire un determinato livello di qualità (QoS) sulle infor-mazioni acquisite dai clienti, i quali di conseguenza, saranno disposti ad offrire una ricompensa ai fornitori di informazioni per il raggiungimento del livello di servizio richiesto.

3.1 Il framework WS-Agreements for Java

Per raggiungere l’obiettivo imposto dal lavoro di tesi `e stato necessario ricercare e quindi selezionare un framework di supporto per l’implementazione dei Service Level Agreements, la scelta `e ricaduta sul framework chiamato Web Service Agreements for Java del quale ci accingiamo a discutere.

3.1.1 Architettura del Framework

Il framework WS-Agreement for Java `e uno strumento per creare e gestire i service level agreements (SLAs) all’interno dei sistemi distribuiti. Implementa lo standard

(27)

OGF WS-Agreement e verr`a utilizzato per modellare ed implementare SLAs per i servizi offerti. Inoltre, automatizzer`a operazioni tipiche della gestione degli SLA come: la validazione dell’offerta, il monitoraggio del livello di servizio, la persistenza e l’accounting.

Figura 3.1: Architettura del framework WSAG4J

3.1.2 Lo standard WS-Agreement

L’obiettivo della specifica Webservice-Agreement è quello di definire un linguaggio ed un protocollo per annunciare le capacità dei service providers, creare agreements basati su template e monitorare lo stato degli agreements a runtime. Un agree-ment tra un service consumer ed un service provider specifica uno o più service level objectives (SLOs) i quali esprimono le richieste di un service consumer e le assicu-razioni del service provider riguardo alla disponibilità di risorse e/o alla qualità del servizio. La specifica WS-Agreement si basa su un insieme di standard consolidati quali: XML, SOAP, WSDL e WSRF. Il protocollo WS-Agreement definisce i servizi richiesi e le operazioni per creare e monitorare i service level agreement, implementa inoltre due tipi di servizi: l’agreement factory service e l’agreement service. Il primo `

e responsabile della creazione degli agreement tra un service consumer e un provider ed istanzia il servizio associato alla QoS negoziata. Il secondo, invece, `e responsabile del monitoraggio sulla conformit`a degli agreements e dei servizi associati.

(28)

3.1.3 Agreement Factory Service

Questo servizio è utilizzato dall’agreement initiator (il service consumer) per istan-ziare SLAs con l’agreement responder (il service provider) ed è inoltre incaricato alla pubblicazione degli agreement templates, ovvero dei modelli di agreements preco-struiti. Durante il processo di creazione di un nuovo agreement il service consumer come prima cosa interroga l’agreement factory service ottenendo cos`ı la lista dei templates disponibili, successivamente, seleziona il template che meglio si adatta alle sue esigenze e, partire da questo, genera un’offerta. L’offerta generata contiene al suo interno la descrizione del servizio che deve essere fornito, le garanzie ad esso associate, i metodi di ricompensa o penalità in caso di adempimento o violazione delle garanzie ed infine gli obblighi di entrambe le parti. Una o più offerte vengono inviate al service provider con lo scopo di istanziare un nuovo agreement, non appena una di queste offerte è accettata da parte dell’agreement responder viene creato un vincolo contrattuale tra le entità. Questo processo è indicato nella figura 2.2.

Figura 3.2: Il protocollo Wsag

3.1.4 Agreement Service

L’Agreement Service `e il servizio che implementa i meccanismi necessari all’accesso ai contenuti associati ad un agreement esistente, al monitoraggio dell’agreement a runtime e alla gestione del suo ciclo di vita. Una nuova istanza dell’agreement service viene generata per ogni agreement creato dall’Agreement Factory Service .

3.1.5 Il linguaggio WS-Agreement

Il linguaggio WS-Agreement definisce i tipi di dato per l’espressione dei contenuti di un agreement. Questo linguaggio `e definito indipendentemente dal protocollo

(29)

WS-Agreement è può quindi essere usato in un ampio insieme di scenari. È definito mediante schemi XML che descrivono i tipi di dato e la struttura di un agreement. La specifica WS-Agreement definisce due tipi di schemi separati: l’agreement schema e l’agreement state schema. L’agreement schema definisce i tipi di dato fondamentali mentre l’agreement state schema definisce i tipi di dato utilizzati per il monitoraggio dell’agreement e nello specifico definisce: gli agreement states, i service term states ed i guarantee term states. I componenti principali di un agreement sono:

• Name

• Context

• Service Description Term

• Service References

• Service Properties

• Guarantee Terms

Tali componenti sono espressi all’interno dell’agreement mediante tag XML, la cui grammatica `e definita all’interno dell’agreement schema e dell’agreement state sche-ma . Il primo componente presente nell’elenco (Name) serve a selezionare un nome per l’agreement, il secondo (Context ) serve invece ad esplicitare informazioni riguar-danti: le entit`a coinvolte nel contratto (agreement initiator e agreement responder), la scadenza del contratto e l’identificatore numerico e testuale per il template. Il componente Service Description Term viene impiegato per la specifica di un parti-colare termine di servizio, inoltre, mediante l’utilizzo di schemi XML customizzati, `

e possibile definire nuovi termini di servizio specifici per lo scenario in cui ci si tro-va. Le Service Properties servono a stabilire un insieme di variabili il cui valore è valutato a runtime, e vengono successivamente impiegate nella validazione dei Gua-rantee Terms. Un esempio pratico è quello in cui sono definite due variabili: una statica, recuperata all’interno dell’agreement, che stabilisce il numero di osservazioni contrattate, ed una dinamica, il cui valore è generato e aggiornato dal servizio di monitoring, che stabilisce il numero di osservazioni attualmente inviate al sistema. Queste variabili sono messe a in relazione all’interno dei Guarantee Terms mediante espressioni di uguaglianza, diseguaglianza, maggiorazione o minorazione. Il risulta-to ottenurisulta-to dalla valutazione di queste espressioni, di tipo vero/falso, determina il rispetto o la violazione di un Service Level Objective associato al termine di servizio contrattato nell’agreement. Al termine di questo capitolo verrà mostrato un agree-ment di esempio dove saranno descritti nello specifico le modalità di utilizzo e lo scopo dei componenti sovracitati.

(30)

Figura 3.3: Struttura del template

3.1.6 Monitoraggio dell’Agreement

Per quanto detto sinora un agreement consiste nella descrizione del servizio fornito e delle garanzie ad esso associate. La descrizione del servizio e delle garanzie associate sono inizialmente definite all’interno dell’agreement template. Nel momento in cui un service provider accetta un’offerta, una nuova istanza di agreement viene creata e successivamente monitorata ad intervalli regolari. Tale processo di monitoraggio `e costituito dalle seguenti attivit`a:

• Monitoraggio del servizio contrattato e aggiornamento dei Service Term States

• Valutazione dell garanzie e aggiornamento dei Guarantee States

• Accounting delle Penalties e Rewards, se applicabile.

Come già preannunciato durante il processo di monitoraggio i service term states e i guarantee term states vengono periodicamente valutati ed aggiornati. Per portare a compimento questo processo è necessario valutare l’insieme di proprietà associate ai service term states. Tali proprietà si suddividono in due categorie: statiche e dinamiche. Le proprietà statiche sono specificate nell’offerta di un agreement e non possono essere modificate una volta che l’agreement è stato creato. Le proprietà dinamiche, invece, possono cambiare durante il ciclo di vita dell’agreement e la loro modifica è effettuata dal componente incaricato al monitoraggio dell’agreement.

3.2 Esempio di Service Level Agreement

Vediamo un esempio concreto di Service Level Agreement negoziato tra CSAMS e SLAManager, e descriviamo i tag principali che lo compongono.

(31)

Figura 3.4: Wsag4j Monitoring

3.2.1 Tag Name e Context

Il tag Name identifica quello che `e il nome dell’agreement, mentre nel tag Context troviamo informazioni riguardanti l’Agreement Initiator e l’Agreement Responder (CSAMS e SLAM), l’ExpirationTime ovvero la validit`a temporale dell’agreement, il TemplateId e il TemplateName che specificano un identificatore numerico e testuale per il template da cui l’agreement discende.

< w s a g : N a m e > C s a m s G u a r a n t e e T e m p l a t e < / w s a g : N a m e > < w s a g : C o n t e x t > < w s a g : A g r e e m e n t I n i t i a t o r / > < w s a g : A g r e e m e n t R e s p o n d e r > CN = S LAM < / w s a g : A g r e e m e n t R e s p o n d e r > < w s a g : S e r v i c e P r o v i d e r > A g r e e m e n t R e s p o n d e r < / w s a g : S e r v i c e P r o v i d e r > < w s a g : E x p i r a t i o n T i m e > 2012 -01 -01 T 0 0 : 0 0 : 0 0 +02 :00 < / w s a g : E x p i r a t i o n T i m e > < w s a g : T e m p l a t e I d > 1 < / w s a g : T e m p l a t e I d > < w s a g : T e m p l a t e N a m e > C s a m s G u a r a n t e e T e m p l a t e < / w s a g : T e m p l a t e N a m e > 3.2.2 Tag ServiceDescriptionTerm

Il tag ServiceDescriptionTerm pu`o essere utilizzato pi`u volte all’interno dell’a-greement per la specifica di un particolare servizio offerto. Nell’esempio riporta-to di seguiriporta-to notiamo la presenza di due servizi: OBSERVATION-SERVICE e COVERAGE-SERVICE. All’interno dell’OBSERVATION-SERVICE trovia-mo il tag ObservationsToSend utilizzato per specificare il numero di osservazioni offerte dal CSAMS. All’interno dell’COVERAGE-SERVICE troviamo invece un insieme di tag utilizzati per stabilire l’area di copertura selezionata dal CSAMS per

(32)

la campagna di sensing. I tag presenti in questo secondo servizio sono: Percenta-ge, che stabilisce la percentuale di copertura dell’area selezionata, StartLatitude, StartLongitude, EndLatitude e EndLongitude che stabiliscono invece le coordi-nate geografiche dell’area di sensing, all’interno della quale verranno effettuate le rilevazioni. < w s a g : S e r v i c e D e s c r i p t i o n T e r m w s a g : N a m e = " O B S E R V A T I O N S " w s a g : S e r v i c e N a m e = " O B S E R V A T I O N S - S E R V I C E " > < s e r v i c e t e r m s : O b s e r v a t i o n s x m l n s : s e r v i c e t e r m s = " h t t p : // s c h e m a s . w s a g 4 j . org / 2 0 0 9 / 0 7 / s e r v i c e t e r m s " > < s e r v i c e t e r m s : O b s e r v a t i o n s T o S e n d > 20 < / s e r v i c e t e r m s : O b s e r v a t i o n s T o S e n d > < / s e r v i c e t e r m s : O b s e r v a t i o n s > < / w s a g : S e r v i c e D e s c r i p t i o n T e r m > < w s a g : S e r v i c e D e s c r i p t i o n T e r m w s a g : N a m e = " C O V E R A G E " w s a g : S e r v i c e N a m e = " CO VER AGE - S E R V I C E " > < s e r v i c e t e r m s : C o v e r a g e x m l n s : s e r v i c e t e r m s = " h t t p : // s c h e m a s . w s a g 4 j . org / 2 0 0 9 / 0 7 / s e r v i c e t e r m s " > < s e r v i c e t e r m s : P e r c e n t a g e > 90 < / s e r v i c e t e r m s : P e r c e n t a g e > < s e r v i c e t e r m s : S t a r t L a t i t u d e > 1 1 . 1 2 3 4 3 2 < / s e r v i c e t e r m s : S t a r t L a t i t u d e > < s e r v i c e t e r m s : S t a r t L o n g i t u d e > 2 8 . 3 4 5 4 < / s e r v i c e t e r m s : S t a r t L o n g i t u d e > < s e r v i c e t e r m s : E n d L a t i t u d e > 1 2 . 1 2 3 4 5 < / s e r v i c e t e r m s : E n d L a t i t u d e > < s e r v i c e t e r m s : E n d L o n g i t u d e > 2 7 . 3 4 5 6 7 < / s e r v i c e t e r m s : E n d L o n g i t u d e > < / s e r v i c e t e r m s : C o v e r a g e > < / w s a g : S e r v i c e D e s c r i p t i o n T e r m > 3.2.3 Tag ServiceProperties

Il tag ServiceProperties viene utilizzato per definire un insieme di variabili la cui valutazione, effettuata a runtime, servirà a stabilire se le garanzie negoziate sono rispettate. Queste variabili servono quindi per specificare quelle che rappresenta-no le proprietà di un servizio e devono esplicitamente essere associate ad esso. È possibile dichiarare due tipi differenti di variabili: statiche e dinamiche. Il valo-re delle variabili statiche viene valo-recuperato all’interno dell’agvalo-reement, mentvalo-re per quanto riguarda la variabili dinamiche, il loro valore viene recuperato ed aggiornato dal servizio di monitoring incaricato di valutare il rispetto delle garanzie negoziate. Nell’esempio sotto riportato vediamo associate al servizio precedentemente defini-to e chiamadefini-to OBSERVATIONS-SERVICE due variabili. La prima, chiamata REQ OBSERVATIONS, è una variabile di tipo statico ed il suo valore viene recu-perato dal tag ObservationToSend precedentemente definito all’interno del Servi-ceDescriptionTerm corrispondente. All’interno il tag <wsag:Location> viene spe-cificato il percorso all’interno dell’agreement per recuperare tale valore. La seconda variabile, chiamata ACT OBSERVATIONS, è una variabile di tipo dinamico. Il

(33)

tag ObservationsSent da cui verrà recuperato il valore non è attualmente presente nell’agreement ma verrà generato dal sistema di monitoring una volta che lo SLA è stato istanziato. La variabile REQ OBSERVATIONS indicherà quindi il numero di osservazioni che il CSAMS ha offerto per questo specifico contratto e rappresenta quindi una costante, invece la variabile ACT OBSERVATIONS verrà aggiornata durante il ciclo di vita dello SLA ed in un determinato istante indicherà il numero di osservazioni che fino ad ora sono giunte al CloudSensor tramite il CSAMS a cui ` e associato l’agreement. < w s a g : S e r v i c e P r o p e r t i e s w s a g : N a m e = " S e r v i c e _ P r o p e r t i e s " w s a g : S e r v i c e N a m e = " O B S E R V A T I O N S - S E R V I C E " > < w s a g : V a r i a b l e S e t > < w s a g : V a r i a b l e w s a g : N a m e = " R E Q _ O B S E R V A T I O N S " w s a g : M e t r i c = " x s : i n t " > < w s a g : L o c a t i o n > d e c l a r e n a m e s p a c e s e r v i c e t e r m s = " h t t p : // s c h e m a s . w s a g 4 j . org / 2 0 0 9 / 0 7 / s e r v i c e t e r m s " ; d e c l a r e n a m e s p a c e w sag = ’ h t t p : // s c h e m a s . ggf . org / g r a a p / 2 0 0 7 / 0 3 / ws - a g r e e m e n t ’ ; th is / w s a g : T e r m s / w s a g : A l l / w s a g : S e r v i c e D e s c r i p t i o n T e r m [ @ w s a g : N a m e = " O B S E R V A T I O N S " ]/ s e r v i c e t e r m s : O b s e r v a t i o n s / s e r v i c e t e r m s : O b s e r v a t i o n s T o S e n d < / w s a g : L o c a t i o n > < / w s a g : V a r i a b l e > < w s a g : V a r i a b l e w s a g : N a m e = " A C T _ O B S E R V A T I O N S " w s a g : M e t r i c = " x s : i n t " > < w s a g : L o c a t i o n > d e c l a r e n a m e s p a c e s e r v i c e t e r m s = " h t t p : // s c h e m a s . w s a g 4 j . org / 2 0 0 9 / 0 7 / s e r v i c e t e r m s " ; d e c l a r e n a m e s p a c e w sag = ’ h t t p : // s c h e m a s . ggf . org / g r a a p / 2 0 0 7 / 0 3 / ws - a g r e e m e n t ’ ; th is / w s a g : S e r v i c e T e r m S t a t e [ @ w s a g : t e r m N a m e = " O B S E R V A T I O N S " ]/ s e r v i c e t e r m s : O b s e r v a t i o n s S e n t < / w s a g : L o c a t i o n > < / w s a g : V a r i a b l e > < / w s a g : V a r i a b l e S e t > < / w s a g : S e r v i c e P r o p e r t i e s > 3.2.4 Tag GuaranteeTerm

Il tag GuaranteeTerm mette in relazione le varibili dichiarate nei ServiceProperties che a loro volta sono legate ai servizi dichiarati all’interno dei ServiceDescrip-tionTerms. Riassumendo: si definisce un servizio, si definiscono le propriet`a del servizio ed infine si stabiliscono le garazie sul servizio mettendo in relazione i valori delle variabili dichiarate nelle propriet`a del servizio. Nell’esempio riportato trovia-mo un GuaranteeTerm chiamato OBSERVATIONS GUARANTEE associato al

(34)

servizio OBSERVERIONS-SERVICE che ha come ServiceLevelObjective un KeyPerformanceIndicator (KPI) chiamato NUMBOFOBS. All’interno di que-sto KPI si valuto se il valore della variabile ACT OBSERVATIONS è maggiore uguale del valore della variabile REQ OBSERVATIONS. Il risultato del confron-to, di tipo vero o falso, stabilirà se la garazia sul servizio specificato è attualmente rispettata. < w s a g : G u a r a n t e e T e r m w s a g : N a m e = " O B S E R V A T I O N S _ G U A R A N T E E " > < w s a g : S e r v i c e S c o p e w s a g : S e r v i c e N a m e = " O B S E R V A T I O N S - S E R V I C E " / > < w s a g : S e r v i c e L e v e l O b j e c t i v e > < w s a g : K P I T a r g e t > < w s a g : K P I N a m e > N U M B O F O B S < / w s a g : K P I N a m e > < w s a g : C u s t o m S e r v i c e L e v e l > A C T _ O B S E R V A T I O N S ge R E Q _ O B S E R V A T I O N S < / w s a g : C u s t o m S e r v i c e L e v e l > < / w s a g : K P I T a r g e t > < / w s a g : S e r v i c e L e v e l O b j e c t i v e > < / w s a g : G u a r a n t e e T e r m >

3.3 Wsag for Java Server

Il server Wsag4Java implementato tramite servlet e fornito dal framework utilizzato supporta un insieme di operazioni in ingresso tra cui: la richiesta dell’elenco dei template presenti, la richiesta degli agreements attualmente istanziati e la richiesta di informazioni sullo stato di un agreement utlizzate per il monitoraggio. Il ser-ver Wsag4J necessita di alcune configurazioni per poter aggiungere il supporto agli agreements customizzati. Bisogna esplicitare, all’interno di un file di configurazione, la posizione del file in formato XML rappresentante il template per l’agreement, inoltre, andranno specificate ed implementate alcune classi Java utilizzate sia per la creazione delle istanze dell’agreement all’interno server, sia per la specifica del meccanismo di monitoraggio ad esso collegato. Per tale motivo `e stato realizzato un package Java chiamato wsag4jcsams contenente l’implementazione di queste classi.

3.3.1 Il package wsag4jcsams.jar

Il package Java wsag4jcsams.jar contiene un insieme di classi di supporto alla ser-vlet Wsag4J Server, utilizzate per la creazione di un agreement (CsamsAgreement.java) e per il suo successivo monitoraggio (CsamsSDTMonitor.java). All’interno del pac-kage troviamo le seguenti classi Java:

• CreateCsamsAgreementAction.java

• CsamsAgreement.java

(35)

• CsamsSDTMonitor.java

• SOSAnswer.java

• SOSRequest.java

La classe CreateCsamsAgreementAction estende la classe astratta AbstractCrea-teAgreementAction, quest’ultima implementa l’interfaccia ICreateAgreementAc-tion per la creazione di una istanza dell’agreement. Al suo interno viene istanziato l’oggetto CsamsAgreement rappresentante l’agreement, ed al quale viene associato un secondo oggetto, istanziato dalla classe CsamsSDTMonitor, contenente la logi-ca per l’implementazione della strategia di monitoraggio. Analizziamo ora le classi CsamsAgreement e CsamsSDTMonitor. La prima estende la classe astratta Abstrac-tAgreementType che implementa l’interfaccia Agreement. Il suo obiettivo `e sempli-cemente quello di recuperare il file XML associato al template dell’agreement e, se necessario, inserire al suo interno dei valori per i termini di servizio, trasformandolo cos`ı in un’offerta di contratto. La seconda classe, CsamsSDTMonitor implementa l’interfaccia IServiceTermMonitoringHandler e definisce al suo interno un metodo periodicamente invocato durante il ciclo di vita dell’agreement. Tale metodo ha il compito di recuperare i valori associati ai termini di servizio negoziati, e contenuti all’interno dell’agreement istanziato, per poi confrontarli con i dati generati a run-time dall’applicazione mobile. Tutto ci`o serve a stabilire se le garanzie associate ai termini di servizio sono rispettate. La classe CsamsSDTMonitor utilizza due classi ausiliarie: SOSAnswer.java e SOSRequest.java, le quali sono impiegate per la ri-chiesta, e quindi l’ottenenimento, dell’insieme dei dati inviati dai dispositivi mobili. Questi dati vengono ottenuti mediante un interrogazione, effettuata tramite query, sul database associato al SOS.

3.3.2 Configurazione del server WSAG4J

Analizziamo ora la configurazione utilizzata per il server WSAG4J e contenuta nel file wsag4j-engine.conf. La configurazione `e esplicitata mediante linguag-gio XML, in essa, in aggiunta alla configurazione della Factory associata al server, troviamo tutte le informazioni fondamentali che permettono di identificare, inter-pretare e quindi istanziare un agreement. Nel tag <wsag4j-config:Validator> sono specificati i percorsi relativi che puntano ai file degli schemi XML utilizza-ti dal parser per interpretare correttamente i templates. La sezione per noi di maggior interesse `e contenuta all’interno del tag <config:Action wsag4j-config:name=WSAG4J-TEMPLATE-1» ed include Il tag <wsag4j-config:Filename> indicante il path relativo del file xml contenente il template, ed il tag <wsag4j-config:CreateAgreementConfiguration> per la specifica del path della classe Crea-teCsasmAgreementAction.

(36)

< wsag4j - c o n f i g : W S A G 4 J E n g i n e C o n f i g u r a t i o n x m l n s : w s a g 4 j - c o n f i g = " h t t p : // s c h e m a s . s cai . f r a u n h o f e r . de / c o n f i g / w s a g 4 j " >

< wsag4j c o n f i g : R e s o u r c e I d > SAMPLE I NST ANCE 1 < / wsag4j -c o n f i g : R e s o u r -c e I d >

< wsag4j - c o n f i g : F a c t o r y >

< wsag4j - c o n f i g : F a c t o r y I m p l e m e n t a t i o n >

< wsag4j - c o n f i g : I m p l e m e n t a t i o n C l a s s > org . ogf . g r a a p . wsa g . s e r v e r . e n g i n e . G e n e r i c A g r e e m e n t F a c t o r y < / wsag4j

-c o n f i g : I m p l e m e n t a t i o n C l a s s >

< / wsag4j - c o n f i g : F a c t o r y I m p l e m e n t a t i o n > < wsag4j - c o n f i g : P e r s i s t e n c e I m p l e m e n t a t i o n >

< wsag4j - c o n f i g : I m p l e m e n t a t i o n C l a s s > org . ogf . g r a a p . wsa g . s e r v e r . p e r s i s t e n c e . imp l . D a t a b a s e W S A G 4 J P e r s i s t e n c e < / wsag4j -c o n f i g : I m p l e m e n t a t i o n C l a s s > < / wsag4j - c o n f i g : P e r s i s t e n c e I m p l e m e n t a t i o n > < / wsag4j - c o n f i g : F a c t o r y > < wsag4j - c o n f i g : V a l i d a t o r > < wsag4j - c o n f i g : S c h e m a I m p o r t s > < wsag4j - c o n f i g : S c h e m a F i l e n a m e > / v a l i d a t o r / X M L S c h e m a . xml < / wsag4j -c o n f i g : S -c h e m a F i l e n a m e > < wsag4j c o n f i g : S c h e m a F i l e n a m e > / v a l i d a t o r / ws a g r e e m e n t xsd t y p e s . xsd < / wsag4j -c o n f i g : S -c h e m a F i l e n a m e > < wsag4j c o n f i g : S c h e m a F i l e n a m e > / v a l i d a t o r / ws -ad dr . xsd < / wsag4j - c o n f i g : S c h e m a F i l e n a m e > < wsag4j - c o n f i g : S c h e m a F i l e n a m e > / v a l i d a t o r / j sdl . xsd - 18. xsd < / wsag4j - c o n f i g : S c h e m a F i l e n a m e > < wsag4j c o n f i g : S c h e m a F i l e n a m e > / v a l i d a t o r / jsdl p o s i x . xsd 6. xsd < / wsag4j -c o n f i g : S -c h e m a F i l e n a m e > < wsag4j - c o n f i g : S c h e m a F i l e n a m e > / v a l i d a t o r / c o n s t r a i n t _ d e f i n i t i o n _ t y p e s . xsd < / wsag4j -c o n f i g : S -c h e m a F i l e n a m e > < wsag4j c o n f i g : S c h e m a F i l e n a m e > / v a l i d a t o r / ws a g r e e m e n t n e g o t i a t i o n t y p e s . xsd < / wsag4j -c o n f i g : S -c h e m a F i l e n a m e > < wsag4j - c o n f i g : S c h e m a F i l e n a m e > / v a l i d a t o r / wsag4j s c h e d u l i n g t y p e s . xsd < / wsag4j -c o n f i g : S -c h e m a F i l e n a m e > < wsag4j - c o n f i g : S c h e m a F i l e n a m e > / v a l i d a t o r / s e r v i c e t e r m s . xsd < / wsag4j -c o n f i g : S -c h e m a F i l e n a m e > < / wsag4j - c o n f i g : S c h e m a I m p o r t s > < / wsag4j - c o n f i g : V a l i d a t o r >

(37)

< wsag4j - c o n f i g : A c t i o n wsag4j - c o n f i g : n a m e = " WSAG4J - TEM PLAT E -1 " > < wsag4j - c o n f i g : G e t T e m p l a t e C o n f i g u r a t i o n >

< wsag4j - c o n f i g : I m p l e m e n t a t i o n C l a s s > org . ogf . g r a a p . wsag . s e r v e r . a c t i o n s . i mpl . V e l o c i t y A g r e e m e n t T e m p l a t e A c t i o n < / wsag4j -c o n f i g : I m p l e m e n t a t i o n C l a s s >

< wsag4j - c o n f i g : F i l e T e m p l a t e C o n f i g u r a t i o n >

< wsag4j c o n f i g : F i l e n a m e > / s a m p l e s / t emp late C S A M S . xml < / wsag4j -c o n f i g : F i l e n a m e > < / wsag4j - c o n f i g : F i l e T e m p l a t e C o n f i g u r a t i o n > < / wsag4j - c o n f i g : G e t T e m p l a t e C o n f i g u r a t i o n > < wsag4j - c o n f i g : C r e a t e A g r e e m e n t C o n f i g u r a t i o n > < wsag4j - c o n f i g : I m p l e m e n t a t i o n C l a s s > w s a g 4 j c s a m s . C r e a t e C s a m s A g r e e m e n t A c t i o n < / wsag4j - c o n f i g : I m p l e m e n t a t i o n C l a s s > < / wsag4j - c o n f i g : C r e a t e A g r e e m e n t C o n f i g u r a t i o n > < / wsag4j - c o n f i g : A c t i o n >

(38)

Capitolo

4

Teoria dei giochi e algoritmi utilizzati

In questo capitolo introdurremo brevemente la teoria dei giochi, esplicitando alcune nozioni fondamentali per la comprensione dei concetti sviluppati nelle successive sezioni. Illustreremo il modello di gioco corrispondente al processo di negoziazione, inizialmente in maniera puramente descrittiva e successivamente lo formalizzeremo a livello matematico. In seguito, descriveremo l’algoritmo utilizzato dal sistema per la selezione della strategia ottimale e, a conclusione del capitolo, vedremo un esempio completo di contrattazione.

4.1 La Teoria dei Giochi

La teoria dei giochi nasce con lo scopo di fornire un ambiente matematico unita-rio per l’analisi di situazioni in cui pi`u individui razionali interagiscono. I modelli utilizzati per descrivere queste situazioni sono appunto i giochi come introdotti da Von Nuemann e Morgenstern (bib). In questa tesi ci concentreremo su una parti-colare classe di giochi chiamati giochi non cooperativi nei quali non sono ammessi accordi vincolanti tra i giocatori. Analizzeremo in particolare due sottocategorie di giochi non cooperativi: i giochi in forma strategica, che rappresentano tramite giochi con un solo turno situazioni in cui tutti i giocatori scelgono contemporanea-mente la propria strategia, ed i giochi in forma estesa che aggiungono ai primi una struttura sequenziale di mosse successive dei diversi giocatori. La teoria dei giochi `

e di recente stato oggetto di un sempre crescente interesse di ricerca, grazie anche ad un’opportuna sistematizzazione e a numerose applicazioni nei pi`u svariati ambi-ti. In questo contesto si `e reso necessario formalizzare ed analizzare in dettaglio le ipotesi ed i metodi su cui si fonda l’analisi proposta dalla teoria dei giochi. Lo svi-luppo della teoria ha portato infatti alla definizione di numerosi concetti risolutivi, proposti a soluzione delle diverse classi di giochi. Nello studio sui fondamenti della teoria dei giochi vengono proposte diverse interpretazioni, allo scopo di esprimere le