Il processo di negoziazione sull’applicazione MyCsams si basa in su due componenti fondamentali: il servizio Cloud to Device Messaging Service di Google, e il servizio che implementa la strategia di negoziazione configurata dall’utente. Il primo `e un servizio di notifica offerto gratuitamente da Google che permette di evitare il pol- ling dei devices al server, effettuato con lo scopo di verificare la presenza di nuove informazioni. Tali informazioni riguardano: la notifica dell’inizio del processo di negoziazione e dell’esito di un round all’interno di tale processo. Il secondo servizio implementa invece la strategia di negoziazione che ha lo scopo di selezionare l’offerta ottimale collegata alla strategia selezionata.
6 – MyCsams
6.2.1 Cloud to Device Messaging Service (C2DM)
Il servizio offerto da Google e chiamato Cloud To Device Messaging Service (C2DM) fornisce un sistema di push-notification per le comunicazioni in ambiente mobile. Lo scopo princiaple di C2DM non `e quello di inviare un nuovo contenuto al software in esecuzione sul client Android bens`ı di segnalare a quest’ultimo la presenza di nuovi dati sul server. Il compito di recuperare e visualizzare la nuova informazione sul dispositivo mobile `e affidato al client che riceve il messaggio e che pu`o prevedere anche un meccanismo asincrono di fetching di dati. Per tale motivo il messaggio inviato tramite C2DM ha una dimensione massima di 1024 bytes. Un’altra carat- teristica interessante di C2DM `e quella che l’applicazione Android destinataria di un messaggio non deve essere necessariamente in esecuzione per riceverlo: il siste- ma operativo, ricevuta la segnalazione, si far`a carico di instradarla all’applicazione specifica. Quanto visto fino ad ora ci ha permesso gi`a di soffermarci su alcune delle parti coinvolte nel meccanismo di comunicazione. Con esattezza, l’architettura di C2DM prevede l’interazione di tre moduli software: il server di terze parti (Cloud- Sensor), il device Android (MyCsams) ed il server Google C2DM. Google C2DM si occupa di inviare i messaggi ai dispositivi che si sono preventivamente registrati per la ricezione dei messaggi e rappresenta il software che si pone come intermedia- rio tra i servers di terze parti e le applicazioni android, svolgendo principalmente compiti di instradamento delle informazioni. Per poter realizzare l’instradamento, il server C2DM deve ricevere ed immagazzinare le opportune informazioni sia sulla presenza dei server che sulla presenza dei client accreditati ai diversi servizi push. L’applicazione Android `e la destinataria dei messaggi di tipo push e offrir`a, tra le altre funzionalit`a, anche quella di recupero e gestione dell’informazione presente sul server. Il protocollo di comunicazione tra le parti prevede una prima fase di accre- ditamento sia del server che dei client interessati sul server C2DM. Successivamente pu`o prendere vita la comunicazione vera e propria attraverso l’invio di un messaggio push dal server al C2DM. Quest’ultimo dopo aver ricavato le informazioni dei device di destinazione, procede a consegnare la segnalazione ai device interessati. Da quan- to visto emerge che il server, e quindi lo SLAManager non ha vincoli implementativi per quanto riguarda il linguaggio e le tecnologie utilizzate per lo sviluppo in quanto deve solo occuparsi di inviare messaggi con il protocollo atteso da C2DM. Nelle fi- gure sottostanti sono mostrati i meccanismi di registrazione al servizio C2DM ed il processo di notifca. Il processo di registrazione di un client presso il server C2DM procede attraverso le seguenti fasi:
• 1. L’applicazione cliente chiede di registrarsi presso il server C2DM.
• 2. Il server C2DM risponde inviando un token che rappresenter`a l’identificatore per il dispositivo (registration-id ).
6 – MyCsams
• 3. L’applicazione cliente inoltra il registration-id allo SLAManager.
Un simile processo di registrazione avviene anche da parte dello SLAManager, in modo che questi sia abilitato all’invio di messaggi verso il server C2DM. Per quanto riguarda invece il processo di invio di notifiche push ai client Android si attraversano le seguenti fasi:
• 1. Lo SLAManager invia un messaggio al server C2DM chiedendo quindi di notificare i clients registrati.
• 2. Il server C2DM invia a sua volta una notifica ai clients che hanno in esecuzione l’applicazione MyCsams.
All’arrivo di una notifica l’applicazione viene risvegliata e notificata sulla presenza di nuovi dati sul server. Il servizio di notifica viene massicciamente utilizzato dallo SLAManager ed in particolare dalla servlet SLAManagerEngine. Quest’ultima quale sfrutta tale servizio per segnalare alle applicazioni l’esito dei round di negoziazione stimolando l’eventuale selezione di una nuova offerta per il round successivo.
Figura 6.7: Registrazione da parte delle applicazioni mobili e del CSS al server C2DM
6.2.2 Configurazione dell’applicazione e della strategia di negoziazione Si `e reso necessario introdurre, nell’interfaccia incaricata alla configuarazione dell’ap- plicazione, una serie di campi utilizzati per la specifica dell’url dello SLAManager e per le credenziali di accesso ad esso associate. L’utente possessore del dispositivo su cui `e in esecuzione l’applicazione MyCsams deve inoltre preventivamente configura- re una serie di vincoli utilizzati per l’implementazione della strategia con cui verr`a effettuato il decremento dell’offerta. Questi vincoli sono associati ad una particolare
6 – MyCsams
Figura 6.8: Meccanismo di notifica del servizio C2DM
proposta di contratto. All’utente `e quindi demandato di selezionare dei valori per le seguenti variabili:
• Last offer : valore dell’ultima offerta al di sotto della quale non si scender`a
• Estimated Rounds: stima del numero di round per la negoziazione
• Observation Window : finestra di osservazione, una volta completa provoca un decremento in base alla Decrement Threshold
• Decrement Threshold : soglia di decremento ovvero il minimo numero di volte che la proposta deve essere selezionata per evitare di far scattare il decremento
• Decrement Entity: entit`a del decremento per l’offerta
Queste variabili sono un’ausilio all’implementazione della strategia di negoziazione e di loro si `e gi`a ampiamente discusso nel capitolo Teoria dei giochi e algoritmi utilizzati.
Capitolo
7
Conclusioni e sviluppi futuri
7.1
In conclusione
Questo lavoro di tesi `e stato incentrato sullo sviluppo di un componente per la creazione di Service Level Agreement all’interno dell’architettura Cloud Sensor, imponendo il raggiungimento dei seguenti obiettivi:
• 1. Definizione, formalizzazione ed implementazione dei termini di servizio associabili ad un contratto.
• 2. Definizione, formalizzazione ed implementazione del processo di negoziazione dei contratti.
• 3. Implementazione delle risorse server per l’esecuzione delle ope- razioni sui contratti e per la comunicazione con i clients.
• 4. Aggiunta del supporto ai Service Level Agreement ed al processo di negoziazione per l’applicazione mobile.
Per quanto riguarda il primo punto presente nella lista si `e deciso di lasciare massi- ma libert`a sulla definizione dei termini di servizio, permettendo allo sviluppatore di specificarne l’opportuna sintassi senza vincoli sul numero e sulla tipologia dei valori contenuti. L’idea `e quella di costruire un dizionario dei termini che possa essere nel tempo arricchito mediante l’aggiunta di nuovi termini, permettendo la creazione di contratti sempre pi`u specifici e facilmente adattabili al contesto di riferimento. Il secondo punto, riferito al processo di negoziazione, `e stato affrontato in maniera innovativa tramite l’utilizzo della teoria dei giochi. Tale teoria fornisce numerosi ed interessanti spunti applicativi per il settore ingegneristico e informatico, permet- tendo, in maniera relativamente semplice, di passare dalla descrizione informale di problemi decisionali visualizzabili come giochi, alla creazione dei corrispondenti mo- delli matematici. Il terzo punto riguarda la definizione delle risorse sul server per
7 – Conclusioni e sviluppi futuri
l’implementazione delle funzionalit`a offerte e per la comunicazione con i clients che accedono al sistema. Qui si `e utilizzato un pattern di progettazione ampiamente diffuso in letteratura ovvero il divide-et-impera separando e specializzando l’insieme di funzionalit`a esposte dal sistema in blocchi di codice separati, semplificando cos`ı il processo di estensione e modifica delle singole componenti. Infine, per il quarto punto della lista, `e stata estesa l’applicazione mobile implementando la logica per la selezione della strategia ottimale durante il processo di negoziazione, ed il codice necessario per la comunicazione con le risorse presenti sul server. Un’ulteriore fun- zionalit`a aggiunta `e quella inerente al supporto delle notifiche push, fondamentali durante la negoziazione, ed ottenuto grazie all’utilizzo del servizio Android Cloud to Device Messaging di Google. La flessibilit`a e l’estendibilit`a del componente SLAMa- nager sono state due delle prerogative fondamentali del lavoro di tesi nell’ottica di ottenere un sistema facilmente arricchibile tramite l’aggiunta di nuove funzionalit`a e di termini di servizio.