Università degli studi di Padova. Facoltà di Scienze MM.FF.NN. Corso di Laurea in Informatica

Transcript

1 Luca Pasa Università degli studi di Padova Facoltà di Scienze MM.FF.NN. Corso di Laurea in Informatica Tesi di laurea Trasmissione di immagini su cloud con basso TCO grazie a Windows Azure AppFabric Service Bus Candidato: Pasa Luca Matricola: Relatore: Dott.ssa Gaggi Ombretta 1 1 di 87

2 Luca Pasa Glossario Per ciò che concerne i termini tecnici utilizzati nel presente documento si faccia riferimento alla sessione glossario presente in coda al documento. Tali termini sono riportati nel documento in corsivo almeno alla loro prima apparizione. 2 2 di 87

3 Indice 1 Introduzione akite Lo Stage l azienda Cloud Computing Costi del cloud computing Cloud e green computing Tecnologie utilizzate Windows Comunication Fondation WCF e REST Feed Feed e WCF DirectShow Task Parallel Library System.Runtime.Caching Windows Phone Windows Azure platform Windows Azure Windows Azure appfabric Windows Azure AppFabric Service Bus Windows azure AppFabric access control service Descrizione del problema Analisi Requisiti Servizio Client Desktop Client Mobile Definizione Soluzione Vantaggi di Windows Azure AppFabric Service Bus Minimizzare il TCO Internet Of Thing Il servizio: ImageFabric Salvataggio e Gestione dati Interfacciamento con dispositivo di acquisizione immagini configurazione e attivazione del servizio, e visualizzazione anteprima immagini Esposizione servizio log coordinamento e gestione dei componenti

4 Luca Pasa INDICE 5.3 Il Client Desktop: ImageConsumer ricezione dati gestione interazione con il servizio gestione dei dati ricevuti visualizzazione dei dati Gestione log di sistema Il Client Windows Phone 7: ImageWP Windows Phone 7 e servizi RESTFul Connessione al servizio ricezione del feed Gestione delle informazioni ricavate dal feed e download delle immagini relative Salvataggio dei dati ricevuti Visualizzazione dei dati Gestione della disattivazione dell applicazione Conclusioni 79 A Glossario 81 B Bibliografia di 87

5 Elenco delle figure 1.1 Screen shoot di POS.net in funzione Screen shoot di SHOP.net in funzione Il datacenter Microsoft di Dublino Comunicazione tra client e servizio in WCF Struttura dell oggetto SyndicationFeed Ciclo di vita di un applicazione Windows phone Struttura di Windows Azure Platform Service Bus Pattern ESB Schema Relay Service Interazione tra access control e service bus Schema riassuntivo soluzione Schema delle classi di ImageFabric Screen shoot di ImageFabric in funzione Screen shoot della finestre di configurazione di ImageFabric Portale di gestione Windows Azure Service Bus dopo la creazione del namespace Schema delle classi di ImageConsumer Schema interazione tra componenti di ImageConsumer Screen shoot di ImageConsumer in funzione Schema delle classi di ImageWP Schema interazione componenti di ImageWP Screen shoot di ImageWP7 in funzione Diagramma di Gantt che illustra la durata effettiva dell attività di stage

6 Luca Pasa ELENCO DELLE FIGURE 6 6 di 87

7 Capitolo 1 Introduzione Questa tesi descrive l attività di stage eseguita all interno dell azienda BEDIN Shop Systems. L attività di stage ha riguardato la realizzazione di un applicazione prototipale per l invio di immagini catturate da un webcam senza che sia necessario effettuare modifiche a sistemi NAT, Firewall o Proxy. L applicazione deve risultare scalabile e non richiedere interventi di tipo sistemistico per l installazione. Deve inoltre minimizzare il TCO ed essere utilizzabile dalla quasi totalità dei possibili client. La creazione di tale prototipo ha lo scopo di verificare la fattibilità di tale applicazione, al fine di decidere poi se inserire le funzionalità offerte all interno di akite, una soluzione software offerta dall azienda ospitante. Tale funzione ha infatti lo scopo di rendere possibile il controllo della situazione dei negozi (ad esempio per valutare l affollamento). 1.1 akite akite è il primo servizio software (SaaS Software as a Service) per punti di vendita progettato per sfruttare pienamente tutte le potenzialità di una moderna piattaforma (PaaS Platform as a Service) come Windows Azure. È stato infatti rilasciato nel 2010, contemporaneamente alla disponibilità pubblica del Cloud Computing di Microsoft ed è già in funzione in diverse catene e negozi indipendenti. Il fenomeno del Cloud Computing, l elaborazione sulle nuvole di Internet, è simile a quello dell energia elettrica che, agli inizi del novecento, ha visto le fabbriche passare dalla produzione autonoma all utenza a consumo attraverso reti di distribuzione. Ora anche per usare il software non è più necessario acquistare e gestire licenze e server. Come è avvenuto per l elettricità, il cambio di paradigma del Cloud Computing impone ai progettisti sia nuovi punti di vista da assimilare, che vecchie abitudini da dimenticare. Rispetto agli approcci tradizionali, i vantaggi per gli utenti sono numerosi, importanti e riassumibili in una sola parola: semplicità. Semplicità nell acquisto, attraverso un canone per postazione tutto compreso e senza nessun investimento iniziale, come pure nell installazione e nell aggiornamento, gestiti automaticamente da Internet. La semplicità si estende ovviamente all uso per mezzo di interfacce amichevoli e alla gestione quotidiana, in quanto la complessità dell informatica viene eliminata dai negozi e spostata sul Cloud. Ma forse la semplicità più importante sta nella condivisione dei dati relativi, ad esempio, alle carte fedeltà, eventualmente anche tra negozi e catene indipendenti e nell integrazione con altri sistemi informatici, con i partner commerciali, con le associazioni d appartenenza ed i clienti attraverso i Social Network, ecc. Tutto è reso possibile grazie all architettura standard e aperta dei Retail Web Services, l hub 7

8 Luca Pasa CAPITOLO 1. INTRODUZIONE intelligente su Cloud di akite. akite permette la connessione tra i punti vendita ed il centro della distribuzione, facilitando così la condivisione dei dati comuni e la collaborazione, anche con altre aziende. Uno dei vantaggi che offre è eliminare la necessità di avere un server all interno del negozio, riducendo così i costi, e spostando quindi i dati nel cloud, aumentando la sicurezza degli stessi. Per tale gestione tutti i terminali all interno di un negozio sono connessi tra loro andando così a creare un rete paritetica. akite offre servizi a più aziende condividendo le risorse hardware e software grazie al paradigma Multi-tenant che la piattaforma di cloud Windows Azure permette di implementare, andando anche a diminuire i consumi in un ottica di Green Computing. akite si compone di alcune applicazioni che ne permettono l utilizzo nelle varie situazioni: POS.net: è lo Smart Client che gestisce una vasta gamma di servizi nei Punti Cassa basati su normali PC, assicurando la massima sicurezza e velocità di servizio alla clientela per mezzo di un database in ogni postazione e il controllo diretto delle numerose apparecchiature periferiche, touch screen compresi. L attività prosegue anche in caso di guasti esterni, poiché i documenti di vendita vengono accodati in attesa della riconnessione automatica ai servizi centralizzati; SHOP.net: è lo Smart Client di Back Store, utilizzabile sia nei negozi che al centro della catena per gestire i magazzini, i rifornimenti, gli inventari, analizzare i dati di vendita, stampare cartelli, etichette ed eventualmente aggiornare articoli, prezzi, promozioni e assortimenti, qualora tali dati non provengano già dal sistema centrale e a condizione che l utente possieda la necessaria autorizzazione; ads, (akite Digital Signage): è lo strumento marketing e promozionale che consente di definire delle sequenza di video e immagini (denominate palinsesti) e di inviarle su degli schermi nei negozi; Vengono qui riportati alcuni immagini di akite in funzione: Figura 1.1: Screen shoot di POS.net in funzione. Fonte: di 87

9 Luca Pasa 1.2. LO STAGE Figura 1.2: Screen shoot di SHOP.net in funzione. 1.2 Lo Stage La creazione del progetto ha richiesto un attività durata circa 8 settimane lavorative. Tale attività è stata svolta all interno dell azienda con la collaborazione del tutor aziendale, e di altri impiegati dell azienda che hanno dato supporto allo stagista. Per lo sviluppo dell applicazione prototipale è risultato necessario un primo importante periodo di apprendimento delle numerose tecnologie necessarie, poi applicate con successo alla soluzione realizzata, e che verrà esposta in seguito. A seguito dell attività di apprendimento è seguito un lavoro volto ad analizzare il problema ed estrarne i requisiti fondamentali. Tale attività è stata seguita da un fase di progettazione dell applicazione prototipale che ha portato ad un agevole codifica della stessa. L applicativo realizzato è stato sviluppato su piattaforma.net utilizzando il linguaggio vb.net. 1.3 l azienda Indirizzo Internet: BEDIN Shop Systems ha oltre 20 anni di esperienza nello sviluppo di software per i Punti di Vendita ed una capacità di innovazione riconosciuta a livello internazionale. Partner Microsoft dalla fondazione, è stata la prima Software House ad introdurre le tecnologie Windows e.net nel Retail ed è coautrice del white paper An overview of Software as a Service in Retail, che ha aperto la strada al software erogato da mega-datacenter su Internet ai Negozi, dove le casse devono funzionare senza interruzione anche in caso di guasti esterni. Prima del Premio Nazionale per l Innovazione ricevuto dalle mani del Presidente Giorgio Napolitano, l azienda ne aveva ricevuto uno da Confindustria per la collaborazione con l Università di Padova e nel Luglio 2010 è stata citata come esempio di innovazione nell uso del Cloud Computing ad un evento internazionale a Washington. 9 9 di 87

10 Luca Pasa CAPITOLO 1. INTRODUZIONE di 87

11 Capitolo 2 Cloud Computing Il cloud computing è un sistema che permette l utilizzo di risorse remote ed eterogenee, senza che l utente si accorga delle differenze, con benefici in termini di prestazioni e disponibilità. Si possono distinguere 3 principali tipi di cloud: Software as a service (SaaS): è un modello di distribuzione del software applicativo dove un produttore di software sviluppa, opera (direttamente o tramite terze parti) e gestisce un applicazione web che mette a disposizione dei propri clienti via internet. Platform as a service (PaaS): è la distribuzione di piattaforme di elaborazione come servizio. Gli elementi del PaaS permettono di sviluppare, testare, implementare e gestire le applicazioni aziendali senza i costi e la complessità associati all acquisto, la configurazione, l ottimizzazione e la gestione dell hardware e del software di base. Infrastructure as a Service (IaaS): è un modello che permette l utilizzo di risorse hardware in remoto. Questo tipo di Cloud è quasi un sinonimo di Grid Computing, ma con una caratteristica imprescindibile: le risorse vengono utilizzate su richiesta al momento in cui un cliente ne ha bisogno, non vengono assegnate a prescindere dal loro utilizzo effettivo. Il cloud computing porta con se molti vantaggi a livello di prestazioni, scalabilità, e costi. Ma soprattutto prevede un modello di sviluppo basato sul concetto della completa fallibilità di ogni singolo componente. Questo vuol dire che un infrastruttura di cloud deve essere in grado di assicurare la piena disponibilità dei suoi servizi anche in caso di problemi e guasti, rendendo minino o nullo l impatto dell evento sulla condizione di chi usufruisce del servizio stesso. 2.1 Costi del cloud computing Un concetto molto importante quando si parla dei costi di utilizzo del cloud, ed in particolare di Windows Azure Platform, è quello che in economia si definisce Capex vs Opex. L utilizzo di una piattaforma di cloud permette il passaggio da un modello economico di tipo Capex, ossia basato su investimenti anticipati, ad un modello Opex, che permette di pagare i soli servizi necessari per il tempo che vengono utilizzati. Questo comporta di evitare di dover affrontare spese iniziali, come ad esempio l acquisto di server e altre apparecchiature, andando invece ad avere una spesa basata su quando e cosa si utilizza. Oltre ad evitare spese iniziali si vanno anche ad evitare spese di eventuale manutenzione ed aggiornamento dell hardware, e si evitano rischi di sovradimensionare o sottodimensionare l hardware acquistato inizialmente. 11

12 Luca Pasa CAPITOLO 2. CLOUD COMPUTING Il Cloud offre infatti un forte versatilità per quanto riguarda l hardware utilizzabile grazie anche all auto-provisioning, che permette veloci variazioni sulle quantità hardware (quantità di storage, potenza di calcolo, ecc) richieste. Se ad esempio abbiamo necessità di disporre di più potenza di calcolo, a causa di una crescita dell azienda, basterà richiedere l utilizzo di uno o più core aggiuntivi. In caso contrario è facile poter ridurre la richiesta di hardware e quindi ridurre i costi. Questo grazie al fatto che si paga solo ciò che si usa. Un altro grande vantaggio è dato dal fatto che è possibile variare di poco la richiesta di hardware da utilizzare cosa non possibile in un modello Capex. Si pensi ad esempio di avere acquistato un server che può gestire n utenti, nel caso in cui avessimo necessità di servire n+1 utenti dovremmo acquistare un altro server, avendo due conseguenze: l aggiunta di un singolo utente ha avuto un costo molto elevato ed il nostro nuovo server è utilizzato solo in piccola parte. Inoltre l acquisto ha comportato un grosso rischio, infatti se un o più utenti non utilizzassero più il servizio da noi offerto, avremmo attrezzatura hardware inutilizzata, ma che abbiamo pagato e di cui non riusciamo ad ammortizzare i costi. L utilizzo di una piattaforma di cloud permette invece di aggiungere al bisogno una porzione di hardware per soddisfare le nostre nuove esigenze senza eccedere e pagare dell hardware che non si utilizza. Nel caso in cui non si avesse più necessità di quella porzione di hardware sarà sufficiente abbassare la richiesta, senza dovere quindi ammortizzare alcun costo ingiustificato. Si parla quindi di un modello di utilizzo e pagamento legato alla modalità economica SaaS pagando ciò che si utilizza, che oltre ad assicurare versatilità permette anche una forte prevedibilità della spesa, sia per chi sviluppa e fornisce l applicazione e che quindi può prevedere i costi, sia per il cliente che consuma l applicazione. Infatti, il modello economico del cloud porta le aziende che sviluppano servizi in esso a fornirli ai loro clienti utilizzando lo stesso modello economico. Tutto ciò porta ad un abbassamento dei rischi d impresa e quindi va a favorire le start-up. Un altro indubbio vantaggio offerto dall utilizzo di una piattaforma di cloud è l affidabilità e la disponibilità di servizio che offre. Infatti il cloud è progettato per rendere trasparenti eventuali guasti e problemi hardware. Questo comporta anche l eliminazione di eventuali costi di manutenzione e riparazione legati a guasti avvenuti in un server che potremmo aver acquistato se non utilizzassimo il cloud computing. Inoltre la forte disponibilità del servizio offerta protegge da eventuali perdite di denaro legate ad eventuali blocchi del servizio offerto da un azienda a i suoi clienti. L utilizzo di piattaforme di cloud porta anche vantaggi a livello di risparmio energetico. infatti l hardware è condiviso tra tutti gli utilizzatori di un piattaforma. Quando noi non utilizziamo l hardware, lo stesso verrà utilizzato da altre aziende o fornitori di servizi. Questo in un contesto di business, dove l utilizzo delle applicazioni avviene spesso per le otto ore lavorative, diventa una grossa fonte di risparmio energetico. 2.2 Cloud e green computing L utilizzo del paradigma del cloud computing oltre all aspetto puramente tecnologico, va a favorire anche il risparmio energetico, andando di fatto ad attuare politiche di green computing. Il green computing si riferisce a tecnologie informatiche ecologicamente sostenibili, che abbiano quindi effetti sull ambiente molto limitati o nulli. Il primo motivo per cui il cloud computing porta ad avere un risparmio energetico è dato dal riutilizzo di hardware. Infatti i server contenuti nei datacenter, che fanno parte della piattaforma di cloud, vengono utilizzati da più utenti che vanno quindi di 87

13 Luca Pasa 2.2. CLOUD E GREEN COMPUTING a condividere la piattaforma hardware. Sì pensi ad esempio alla situazione di un azienda media la quale opera per otto ore al giorno, e quindi sfrutta i servizi e l hardware, per una sola parte della giornata. Nelle restanti ore però l hardware non rimane inutilizzato (come invece accade utilizzando un server di proprietà o in affitto) ma verrà destinato ad un altro utilizzatore, portando così ad un abbattimento degli sprechi legati alla inattività. È poi da considerare il fatto che l utilizzo dei server presenti in un datacenter che implementa politiche di cloud computing è sempre molto elevato andando quindi a mantenere il server ad un livello di efficenza molto alto, cosa che invece non succede nei server personali dove tutto dipende dall utilizzo, che è legato alla singola entità richiedente. Anche la tipologia di server presenti in un datacenter segue precise caratteristiche, la prima tra tutte è di certo l efficenza. Altra importante caratteristica dell hardware è che deve essere di facile reperibilità e a poco costo in modo da ammortizzare eventuali guasti. Vengono inoltre preferiti molti server con buona potenza piuttosto che pochi server di potenza eccelsa, al fine di implementare più efficacemente politiche di scalabilità orizzontale e mantenere il costo dell hardware, e la sua eventuale sostituzione per guasti, vantaggioso a livello economico. Altro importante aspetto nel cloud computing è la collocazione dei datacenter in specifiche zone geografiche. Tali zone geografiche vengono scelte per vari motivi: condizioni climatiche favorevoli; vicinanza con dorsali che facilitano la connessione; vicinanza a fonti energetiche; legislatura favorevole per la sicurezza dei dati. Talvolta queste scelte portano importanti vantaggi, si pensi ad esempio come condizioni climatiche particolarmente fredde e ventose possano portare ad una sostanziale riduzione della necessità di utilizzare sistemi di climatizzazione o addirittura eliminarli. Un esempio in questo senso è il datacenter Microsoft di Dublino, uno dei datacenter in cui viene mantenuta la piattaforma di cloud Windows Azure e non solo. In questo caso è stato sfruttato fortemente il freddo clima irlandese andando a migliorare l efficenza dell impianto, riducendo l emissione di carbonio ed eliminando quasi la necessità di consumare acqua. Dal punto di vista della gestione del raffreddamento dei server è stato utilizzato il clima favorevole (con temperature che variano da -5 C a 27 C) insieme all innovativo air-side economization, messo appunto da Microsoft, che permette di eliminare la necessità di utilizzare impianti di climatizzazione rendendo sufficiente il ricircolo dell aria esterna per raffreddare quella interna al datacenter. Questo sistema ha portato a diminuire fortemente i consumi rispetto al classico approccio legato all utilizzo di sistemi di climatizzazione. In Figura 2.1 viene riportata un foto del datacenter Microsoft di Dublino di 87

14 Luca Pasa CAPITOLO 2. CLOUD COMPUTING Figura 2.1: Il datacenter Microsoft di Dublino di 87

15 Capitolo 3 Tecnologie utilizzate 3.1 Windows Comunication Fondation WCF (Windows cominication fondation) è un modello di programmazione unificato promosso da Microsoft che permette la creazione di applicazioni orientate ai servizi, rendendo possibile lo sviluppo di soluzioni sicure, affidabili con la possibilità di integrare piattaforme diverse ed interpolarsi con soluzioni già esistenti. La nascita di WCF è da imputare anche alla volontà di Microsoft di unificare tutte le tecnologie esistenti per creare tecnologie distribuite, ma anche alla volontà di creare una tecnologia capace di adattarsi ai cambiamenti, e quindi fortemente estensibile ed inoltre orientata all utilizzo delle tecnologie standard più diffuse (come ad esempio SOAP, WSDL, WS-*). Uno dei concetti che sta alla base della filosofia di sviluppo di soluzioni basate su WCF è il concetto di servizio. Un servizio può essere definito come una parte di codice con la quale si interagisce tramite messaggi. Esso è passivo, infatti un servizio si mette in attesa di messaggi entranti con la quale gli verrà richiesto di eseguire una o più operazioni, saranno quindi i client che andranno ad inizializzare il servizio e, tramite l utilizzo dei messaggi, a richiede l esecuzione di un operazione. Tutti i messaggi vengono ricevuti e spediti da endpoint. Un endpoint e costituito da: un address, il quale specifica dove dovranno essere inviati i messaggi. un binding, il quale specificherà come dovranno essere inviati i messaggi. un contract, il quale specificherà cosa conterrà un messaggio Ogni client che vuole accedere al servizio necessita di conoscere queste informazioni per poter comunicare con esso. Uno dei metodi utilizzati dai servizi per condividere tali informazioni con i client è l utilizzo di WSDL (Web service definition language). In questo ambito trova spazio il concetto di Software as a Service (SaaS), infatti WCF permette di implementare e sviluppare software che verrà fornito ai client come servizio accessibile tramite una rete. Solitamente ai client non è richiesto il pagamento per il possesso del software, ma viene invece pagato il suo utilizzo. Un servizio può esporre uno o più endpoint con i quali può comunicare con diversi client. WCF ha lo scopo di portare in primo piano i concetti dell architettura orientata ai servizi, e per fare ciò è stato creato il namespace System.ServiceModel il quale contiene una nuova libreria di classi che rende possibile l utilizzo del modello di programmazione conosciuto come WCF programming model. WCF oltre a permettere la creazione di servizi, permette anche di creare i client che gli andranno ad utilizzare. L utilizzo avviene sempre attraverso endpoint, i quali 15

16 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE risultano essere un concetto fondamentale per definire l infrastruttura propria dei prodotti WCF. Nell implementazione di un servizio WCF il primo passo è andare a creare il componente fondamentale: l endpoint. Andiamo quindi a descrivere endpoint andando a definire il contratto, l indirizzo ed il binding. Per descrivere il contratto si andranno ad utilizzare interfacce le quali tramite l utilizzo di appositi comandi andranno a segnalare quale parte di contratto riguarda il servizio e quale le operazioni. L implementazione di tale classe andrà a definire il comportamento del servizio relativo allo specifico endpoint. Verrano poi definiti l indirizzo ed il binding, e infine, tramite l infrastruttura di hosting offerta da WCF andremmo ad esporre il servizio rendendo quindi possibile agli eventuali client l interazione con esso. Anche nella creazione di un client l endpoint va a coprire un ruolo fondamentale, infatti il client dovrà conosce la descrizione dell endpoint(che può essere resa nota tramite WSDL ma non solo) per poter comunicare con esso. Una volta ottenuti questi dati il client potrà generare (anche dinamicamente tramite un tool messo a disposizione da WCF) i meccanismi necessari alla creazione di messaggi utili alla comunicazione con il servizio. I tre elementi di cui si compone un endpoint sono: l indirizzo (address): che conterrà l indirizzo alla quale il servizio risulta disponibile, e dove i client che lo vogliono utilizzare dovranno inviare i messaggi per richiedere l esecuzione di un lavoro. la definizione di quest ultimo può essere fatta sia da codice che mediante il file di configurazione (presente in tutte le applicazioni.net); binding: esso va a definire come il servizio comunica all esterno. in questo caso WCF mette a disposizione varie classi che vanno ad implementare vari protocolli di comunicazione. Anche in questo caso sarà possibile specificare tale informazione sia da codice che tramite file di configurazione; contratto: il più importante dei 3, specifica l insieme di funzionalità esposte dal servizio nonché la forma che i messaggi dovranno avere, i modi per modellare tale contratto sono molteplici, tra i più utilizzati c è la possibilità di utilizzare interfacce e classi, dalle quelli verrano estratte le funzionalità disponibili ed il formato dei messaggi. Perché tale estrapolazione di informazioni avvenga è necessario specificare tramite attributi quale significato hanno i costrutti sintattici contenuti nelle classi e interfacce. In.Net gli attributi hanno il principale scopo di collegare metadati a determinate parti del programma. Gli attributi principalmente utilizzati nella stesura di un servizio sono <ServiceContract> e <OperationContract>, il primo andrà ad indicare il contratto di un servizio WCF, mentre tramite il secondo si andranno a specificare quali funzionalità si vuole esporre. Per quanto riguarda una qualsiasi funzionalità sembra ovvio che saranno 2 i messaggi ad essa associati: uno riguardante la richiesta dell esecuzione di tale funzionalità, che verrà modellato in base alla lista dei parametri d ingresso, ed uno che riguarderà il risultato del invocazione che sarà modellato in base al valore di ritorno. Per quanto riguarda la tipologia di dati che verrano passati tramite i messaggi è importante tenere in considerazione che WCF è in grado di tradurre in maniera automatica solo i tipi.net predefiniti, sarà invece compito dello sviluppatore segnalare come tradurre i tipi non predefiniti sempre tramite l uso di opportuni attributi quali <DataContract> e <DataMember> i quali andranno a specificare rispettivamente, anche grazie ad alcune proprietà in essi contenute (modificabili dallo sviluppatore), le modalità di traduzione di un intera classe e di un singolo campo dati di 87

17 Luca Pasa 3.2. WCF E REST Come già detto per esporre un servizio è necessario utilizzare l infrastruttura di hosting offerta da WCF. Tale infrastruttura è offerta da WCF tramite gli oggetti ServiceHost e WebServiceHost. Ad ogni host possono venire aggiunti uno o più endpoint, che verranno così esposti verso i client. A seguito dell apertura dell host il servizio rimarrà in attesa di ricevere messaggi che andranno a scatenare l esecuzione di una o più operazioni. Figura 3.1: Comunicazione tra client e servizio in WCF. Molte delle operazioni necessarie per istanziare e consumare il servizio, grazie a WCF vengono eseguite in maniera trasparente all utente, in modo da rendere trasparente ad esso un parte importante della complessità che porta con se l utilizzo dell architettura SOA ed in particolare alla comunicazione con il servizio. Tale livello di astrazione è possibile grazie al Channel layer, un insieme di classi che vengono istanziate in maniera automatica in base alle scelte fatte dallo sviluppatore utilizzando i costrutti presenti nella libreria System.ServiceModel precedentemente citati. Le principali operazioni eseguite dal Chanel Layer riguardano le operazioni di serializzazione di messaggi, il trasposto degli stessi nel metodo definito dallo specifico endpoint e la scelta dell opportuna funzionalità da eseguire in base ai dati presenti nel messaggio (dispacing) 3.2 WCF e REST REST (Representational Transfer State) è un paradigma per la realizzazione di applicazioni e servizi web che permette la comunicazione e la manipolazione di risorse tramite metodi propri del protocollo http. Dal punto di vista dei servizi REST può essere utilizzato per creare software in cui i client possono effettuare richieste a servizi. Un servizio che utilizza architettura REST e detto RESTful, questi servizi sono più semplici e meno strutturati rispetto ai servizi basati su tecnologia RPC come ad esempio SOAP ma, contrariamente a quanto si possa pensare, negli ultimi tempi sono diventati più popolari dei loro più diretti rivali andando di fatto a contro quella che era stata la tendenza portata aventi dalla maggior parte dei fornitori di servizi fino a qualche anno fa. Le motivazioni di tale ritorno alla basi del protocollo http sono date dalla volontà di potersi interfacciare con client sempre meno complessi (come ad esempio i browser), inoltre l utilizzo di REST rende possibile l invio di dati tramite protocolli standard e meno complessi (ad esempio XML). Non è da sottovalutare la possibilità di poter di 87

18 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE accedere a servizi e dati tramite semplici url. I servizi RESTful ereditano molti dei vantaggi che porta con se la piattaforma Web, come ad esempio le caratteristiche di sicurezza in essa incluse, il controllo della cache, la compressione dei dati e scalabilità. In questo progetto la scelta di utilizzare l architettura REST è stata inoltre favorita dal fatto che si è interessati a poter gestire il servizio tramite feed (RSS o Atom). La creazione di servizi RESTful è supportata da WCF e anche in questo caso hanno un ruolo importante gli endpoint, in questo caso è importante capire quali sono le risorse che interessa rappresentare e quale sarà la loro rappresentazione e le uri associate a tali risorse, è infatti importante associare una URI relativa ad ogni risorsa che, associata alla URI rappresentante l indirizzo a cui è disponibile il servizio darà la possibilità di accedere alla risorsa. Oltre alle URI associate alla varie risorse è necessario associare un operazione base http (ed esempio GET, POST, PUT ecc.) tali metodi vanno a formare un interfaccia uniforme per effettuare l interazione con risorse nel web, infatti la quasi totalità di applicazioni e sistemi che sono presenti nel web possono capire tali metodi. Inoltre l utilizzo di questa interfaccia uniforme per la comunicazione rende le applicazioni stabili, in quanto le modifiche a questo metodo di comunicazioni avvengono molto raramente, e quindi difficilmente lo sviluppatore dovrà mettere mano a tale aspetto della sua applicazione. Per eseguire la creazione del servizio è necessario creare l interfaccia http del servizio al fine definire quali operazioni e quali dati verranno esposti da esso, ora il principale scopo sarà assegnare alla varie operazioni un URI e un metodo http.per eseguire tale operazione verrano utilizzati degli attributi <ServiceContract()> e <OperationContract()> la quale principale funzione sarà associare metodi http e parametri alle funzionalità esposte e per fare ciò verrano usati in collaborazione con gli attributi quali <WebGet> (per le operazioni GET) o <WebInvoke> (in cui è possibile definire il metodo http associato). All interno di quest ultimi attributi sarà inoltre possibile definire quali URI saranno associati alle operazioni esposte e quali parametri saranno ad essi associati. Tali attributi sono contenuti nel namespace System.ServiceModel.Web il quale contiene inoltre metodi e strutture le quali rendono più semplice la creazione di un buon servizio RESTful. È importante considerare anche il tipo di binding, che in questo caso sarà di tipo WebHttpBinding il quale assicura l utilizzo di tecnologie proprie della piattaforma web nella comunicazione. La principale differenza rispetto ad un servizio creato con un architettura di tipo RPC è nel client, infatti, nei servizi RESTful1 il client non necessità più di conoscere la descrizione del servizio per comunicare con esso, rendendo necessario comunicare, ad esempio tramite WSDL, tale descrizione, ed in seguito, in base ad essa (in maniera automatica) creare messaggi con una precisa struttura. Nei servizi RESTful WCF mette a disposizione un astrazione sul protocollo http. Per utilizzarla si necessita di un interfaccia all interno lato client contenente le definizioni delle funzionalità che si vogliono consumare precedute dagli attributi <WebGet> e/o <WebInvoke> corrispondenti. Fatto ciò è possibile creare un canale di comunicazione WCF tramite WebChannelFactory che si occuperà di aprire il canale di comunicazione gestendo le richieste in base a quanto definito tramite gli attributi. Quando saranno eseguite modifiche all interfaccia http delle operazioni esposte nel server, sarà necessario comunicare ai client tale modifica ed adeguarle le sue interfacce. Purtroppo non esistono strumenti per automatizzare questa operazione. Questo problema però non si presenta ovviamente se usiamo browers o altri client che utilizzano di default le web API per comunicare di 87

19 Luca Pasa 3.3. FEED 3.3 Feed I feed web sono unità di informazioni formattata secondo specifiche stabilite precedentemente, infatti essi risultano interoperabili ed aventi contenuto interscambiabile fra le diverse applicazioni o piattaforme. La distribuzione di questi contenuti web può avvenire tramite due principali formati: RSS e Atom. Entrambi sono basati sullo standard XML. Il formato Atom è il più recente tra i due, ed ora è disponibile nella sua versione 1.0. La sua giovane età è uno dei fattori che giustificano la minor diffusione rispetto alla concorrenza, e quindi anche una minore disponibilità di framework, parser e risorse che lo supportano. Sempre la recente creazione di questo formato non assicura la sua stabilità (ad esempio l attuale versione 1.0 non presenta retro-compatibilità con le precedenti). Il formato RSS (Really Simple Syndication) è sicuramente più maturo del suo diretto concorrente, ed inoltre esso si presenta come meno restrittivo, e quindi più versatile in presenza di contenuti che non siano semplicemente testo RSS definisce una struttura adatta a contenere un insieme di notizie o informazioni, ciascuna delle quali composta da vari campi. essendo esso un formato predefinito, un qualunque lettore RSS potrà presentare in una maniera omogenea i dati provenienti dalle fonti più diverse. Questo formato nasce all interno di netscape dove veniva utilizzato per gestire i contenuti del portale my netscape network, successivamente fu adottato dalle comunità di blogger, cosa che aiutò molto la sua affermazione, facendolo diventare oggi un standard di fatto per quanto riguarda l esportazione di contenuti web. Nel 2000 il W3C pubblicò la prima versione ufficiale di RSS : la 1.0. Contemporaneamente veniva pubblicata un versione più vicina alla versione adottata inizialmente da Netscape, denominata 0.91, successivamente evolutasi nella versione 0.92 e attualmente nella versione 2.0. Quest ultima risulta attualmente la più diffusa e, anche per questo motivo, è stata adottata per la realizzazione del progetto in esame. I feed rss sono facilmente fruibili da strumenti software chiamati aggregatori di feed o feed reader. Essi sono molto comuni e molte volte addirittura integrati nel browser. Essi per interpretare un feed rss ne eseguono il parser andando ad identificare i tag ed estraendo i valori utili alla visualizzazione. Questa operazione può essere facilmente implementata anche da entità client che rispondono ad un servizio che espone risorse tramite questa tecnologia. I servizi che utilizzano tale tecnologia per esporre i dati hanno inoltre alcuni importanti vantaggi. Il primo tra tutti è l utilizzo di un formato che risulta essere facilmente interpretabile da molte entità senza richiedere una approfondita conoscenza del servizio stesso, essendo ormai il formato RSS uno standard di fatto. L utilizzo di un linguaggio standardizzato, come XML, per esporre le proprie risorse rende le risorse più facilmente consumabili. La semplicità intrinseca del formato RSS rende possibile consumare il servizio anche per client molto semplici. Un feed RSS è realizzato utilizzando lo standard XML ed è quindi composto da alcuni tag e attributi, alcuni di essi riguardanti il contesto globale, altri locali. Per quanto riguarda l intero feed segnaliamo quelli richiesti come obbligatori: title, che conterrà il titolo del nostro feed; link, che conterrà l indirizzo del sito web corrispondente al feed; description, dove viene inserita la descrizione del servizio. Per quanto riguarda gli elementi che compongo il feed, le informazioni ad essi collegate sono contenute all interno del tag <item> il quale si compone di numerosi tag figli, tra i quali i più rilevanti (e utilizzati al fine del progetto) sono: di 87

20 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE title, contente il titolo del elemento; link, contente il link all elemento; description, dove è presente la descrizione dell elemento; pubdata, riportante la data di pubblicazione del elemento; enclosure, dove sono presenti gli elementi multimediali collegate all item. Si vuole fare notare che quanto appena descritto e valido per il formato RSS. Nel caso di utilizzo del formato Atom, in virtù della della più stringente e precisa rappresentazione delle informazioni, gli elementi obbligatori risultano essere in numero maggiore Feed e WCF I feed sono semplicemente dati XML esposti tramite un URI HTTP. ed è il lettore di feed responsabile dell esecuzione delle richieste tramite L uri per mantenere aggiornato il feed visualizzato dell utente. È indubbio che lo scenario che si presenta con l utilizzo di feed semplifica di molto l invio e la ricezione di dati, unito poi alla grossa diffusione dei feed reader ha portato a considerare l utilizzo di tale tecnologia non limitatamente all esposizione di dati provenienti da blog e simili, ma anche per l utilizzo in accoppiata con servizi e non solo. Quindi, la creazione di un servizio, in particolare di un servizio RESTful, propone l attrattiva di esporre tale servizio tramite feed rss o Atom (se il servizio è di sola lettura, altrimenti utilizzando il protocollo atompub se il servizio prevede anche attività di scrittura). WCF oltre a dare la possibilità di esporre servizi RESTful dà anche la possibilità di esporre feed, infatti creando un endpoint http-based sarà possibile esporre feed utilizzando entrambi i formati RSS e Atom. Per rendere l esposizione dei feed più agevole, WCF mette a disposizione un infrastruttura ad oggetti che rende possibile la creazione di tali elementi senza dover conoscere a fondo la loro struttura, rendendone di fatto trasparente la complessità. Tale infrastruttura mette inoltre a disposizione metodi che si occupano della traduzione dei nostri oggetti nel corrispondente formato richiesto (sia esso Atom o RSS), rendendo trasparenti allo sviluppatore anche future modifiche al formato stesso. Implementare un servizio che espone un feed richiede la creazione di un servizio RESTful il quale contenga un metodo che ritorni il feed nel formato desiderato. La gestione del feed avverrà tramite l utilizzo dei metodi e gli oggetti contenuti all interno del namespace System.ServiceModel.Syndication, il quale contiene in particolare l oggetto principale per la rappresentazione di un feed: SyndicationFeed. la struttura di tale oggetto è riportata in Figura 3.2. Questo oggetto ha lo scopo di implementare un feed generico (anche se il modello è in parte orientato verso l utilizzo dello standard Atom), nel quale è possibile impostare proprietà, che andranno a popolare alcuni tag propri della strutture del nostro feed, ed inoltre tramite una collezione di oggetti FeedItem è possibile impostare la collezione di item contenuta nel feed. A seguito della creazione di un feed generico è possibile utilizzare le funzioni GetRss20Formatter o Atom10FeedFormatter per ottenere il feed rispettivamente in formato RSS o Atom, e quindi renderlo disponibile per essere restituito tramite un servizio RESTful. Il namespace System.ServiceModel.Syndication contiene anche metodi per consumare un feed, infatti esso rende possibile la creazione di un oggetto SyndicationFeed, a partire dal codice XML che è possibile ottenere tramite una richiesta al servizio RESTful che espone un feed. L oggetto creato, rappresentante il feed, permette una di 87

21 Luca Pasa 3.3. FEED Figura 3.2: Struttura dell oggetto SyndicationFeed. semplice manipolazione dei dati rendendo possibile presentarli o processarli nella maniera desiderata di 87

22 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE 3.4 DirectShow DirectShow è un framework prodotto da Microsoft contente numerose API le quali permettono la gestione di file multimediali e degli stream audio e video. Il principale scopo è fornire un interfaccia comune per la gestione dei file multimediali in molti linguaggi di programmazione. Il framework in questione è basato sul concetto di filtro, che rende possibile aggiungere file multimediali su richiesta degli utenti o degli sviluppatori. Tale framework all interno del progetto è stato utilizzato per gestire l utilizzo di una webcam al fine di catturare le immagini che fanno parte delle informazioni esposte dal servizio che è stato implementato. Nello sviluppo del progetto si è in particolare utilizzato DirectShow.net, il quale è espressamente creato al fine di poter accedere alla funzionalità messe a disposizione del framework tramite applicazioni.net. DirectShow possiede un architettura modulare dove ogni operazione è eseguita tramite un oggetto COM che prende il nome di filtro. Directshow mette a disposizione un insieme di filtri preimpostati, me rende comunque possibile l estensione delle proprie funzionalità creandone di nuovi. L esecuzione di operazioni complesse richiede l utilizzo di più filtri collegati tra loro, tale connessione avviene anch essa tramite oggetti COM detti pin, i filtri usano i pin per spostare i dati da un filtro al successivo. Un insieme di filtri collegati tra loro è detto grafo di filtri. Un filtro può essere in 3 possibili stati: running, in questo stato vengono processati i dati multimediali che lo riguardano stop, il filtro non sta processando i dati pause, il filtro sta preparando i dati per passare allo stato di running Solitamente i filtri contenuti in uno stesso grafo passano da uno stato all altro contemporaneamente. I filtri contenuti in un grafo vengono controllati da un ulteriore oggetto COM : il filter graph manager il quale esegue molte operazioni tra le quali, coordinare il cambiamento di stato dei filtri contenuti nel grafo, creare uno stesso clock che verrà poi utilizzato da tutti i filtri, comunicare eventi all applicazione che sta usando il filter graph controllato e mettere a disposizione un metodo all applicazione per creare il grafo. Il media type è il sistema con cui è possibile descrivere i formati multimediali digitali, esso viene usato per descrivere i tipi gestiti dai vari filtri che sono contenuti in un grafo. I filtri connessi tra loro devono concordare sui loro media types, se questo non succede i 2 filtri non possono essere connessi. Ogni media type contiene informazioni in proposito alla categoria dei dati che rappresenta (Major type), il formato dei dati (Subtype) e un blocco di dati che definisco il formato in modo dettagliato (Format block). Per eseguire lo spostamento dei dati da un pin di output di un filtro ad un pin di input di un altro filtro può essere usato il metodo IMemInputPin.Receive, oppure tramite l allocazione in memoria dei dati che viene eseguita tramite l oggetto allocator, che andrà a creare un insieme di buffer che verrano riempiti e letti. Il pin che esegue la lettura per conoscere la posizione in memoria dei filtri può usare l oggetto media samples creato dall allocator allo scopo di gestire i buffer. Un componente hardware, per entrare a far parte di un grafo di direct show deve essere rappresentato tramite un filtro. Per farlo si utilizza un filtro wrapper messo a disposizione da DirectShow, il quale permette di gestire dispositivi di vario genere tramite i specifici filtri. Il filtro mette a disposizione un interfaccia la quale espone funzionalità per accedere alla diverse possibilità messe a disposizione dall hardware di 87

23 Luca Pasa 3.4. DIRECTSHOW rappresentato. Sempre il wrapper si occupa di tradurre le richieste fatte tramite l interfaccia in richieste fatte al driver del dispositivo utilizzato e viceversa di 87

24 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE 3.5 Task Parallel Library Task Parallel Library,(TPL) è un insieme di API contenute nel framework.net 4.0 le quali permettono di eseguire attività in parallelo, e quindi di implementare il concetto di parallel computing. Il principale vantaggio portato da Task Parallel Library è dato dal fatto di rendere possibile l ottimizzazione dell esecuzione di più task sia grazie al multihreading, sia grazie all esecuzione parallela, ossia la possibilità di eseguire uno o più task su diversi processori, andando ad ottimizzare al meglio l esecuzione sulle nuove piattaforme hardware multi-core. TPL va a scalare dinamicamente il grado di parallelismo tra le varie attività andando a ottimizzare l utilizzo di ogni processore disponibile. Infatti al momento della richiesta di esecuzione di un attività,.net va a controllare se nel Thread Pool ci sono dei posti liberi. In caso affermativo, apre uno o più thread al fine di lanciare le attività in parallelo, In caso contrario accoda le stesse. Questa Libreria è stata introdotta a partire dalla versione.net 4.0, ed ha anche il merito di unificare i numerosi sistemi di gestione del parallelismo presenti in tale framework. Uno dei principali concetti su cui TPL si basa è il concetto di task. A livello di codice, un task è un istanza della classe System.Threading.Tasks.Task, che mantiene un riferimento a un delegate, il quale poi esegue l effettivo lavoro da svolgere in modalità concorrente. Questo concetto differisce dal concetto di thread, centrale nel mondo del multithreading classico, infatti un thread può eseguire più task, ed ogni task può essere distribuito su più processori dando vita al concetto di programmazione parallela. TPL si basa principalmente sulle classi e sui metodi presenti nei namespace System. Threading e System.Threading.Tasks. Nella prima sono presenti le classi e le interfacce che rendono possibile la programmazione in multithreading, comprese le classi per la sincronizzazione dei vari thread. Nel secondo troviamo i tipi che rendono possibile astrarre la complessità nella scrittura di codice per l esecuzione di task in parallelo. Per inizializzare ed avviare un task esistono 2 metodologie: una implicita e l altra esplicita. Il metodo implicito prevede l utilizzo del metodo invoke, tale metodo riceve in input un array di oggetti System.action, Ogni oggetto dell array viene poi tradotto in un task che, se possibile, viene eseguito in parallelo. Per l inizializzazione delle System.action è possibile utilizzare le lambda expression, questo perché ogni oggetto System.action viene tradotto in un delegate che non restituisce valore e le lambda expression rappresentano un delegate anonimo che non restituisce valore. Un limite di tale metodo è il fatto che non permette di controllare i task, ai quali non permesso nemmeno restituire un valore. Questi 2 limiti possono essere risolti andando a creare in maniera esplicita un istanza della classe task. La creazione di un istanza di task avviene anch essa tramite il metodo invoke, ma non essendo esplicita non e possibile controllore tale entità. anche qui è possibile utilizzare una lambda expression oppure un delegate (che si occupa di eseguire le operazioni asincrone richieste) per costruire un oggetto task, in seguito è possibile avviare tale attività utilizzando il metodo Start. Per avere maggior controllo durante l esecuzione dei vari task è possibile usare la factory messa a disposizione da TPL: TaskFactory. Per quanto riguarda invece la possibilità di eseguire task in maniera parallela che però ritornino un valore è possibile utilizzare gli oggetti System.Threading.Tasks. Task(Of TResult) tramite i quali è possibile ottenere un valore del tipo specificato nella definizione dell oggetto stesso. L interazione con tali oggetti è la stessa che viene utilizzata con gli oggetti Task classici di 87

25 Luca Pasa 3.5. TASK PARALLEL LIBRARY Nell esecuzione dei task è possibile che una o più eccezioni si verifichino contemporaneamente, e molte volte non è facile capire da quale istruzione siano provocate. Per gestire tali casi.net mette a disposizione l eccezione AggregateException, nella quale vengono raggruppate tutte le eventuali eccezioni che si verificano durante l esecuzione di un attività su 2 o più thread o processori. Le eccezioni vengono collezionate all interno della proprietà InnerExceptions dove, scorrendo tale collezione, è possibile risalire alla causa che ha portato al sollevamento delle eccezioni contenute di 87

26 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE 3.6 System.Runtime.Caching Dalla versione 4.0 del framework.net sono stati introdotti meccanismi per implementare politiche di caching. Il namespace System.Runtime.Caching contiene tipi e metodi utili ad implementare tali sistemi. Gli oggetti qui contenuti danno la possibilità allo sviluppatore di gestire in maniera facile e trasparente i dati in una cache, inoltre permettono di mantenere un ottimo livello di controllo su quest ultima. L utilizzo di tale cache avviene tramite l istanziazione di un oggetto di tipo MemoryCache, il quale è un implementazione concreta della classe astratta ObjectCache. Dopo tale operazione è possibile configurare alcuni valori della cache come ad esempio: Name che contiene il nome della cache CacheMemoryLimit, che rappresenta la quantità di memoria nel computer, in byte, che può essere utilizzata dalla cache PhysicalMemoryLimit che definisce la percentuale di memoria fisica che la cache può utilizzare PollingInterval che rappresenta periodo massimo di tempo dopo il quale la cache aggiorna le statistiche relative alla memoria Tali caratteristiche sono configurabili sia attraverso il codice, al momento dell istanziazione della cache, sia a priori tramite il file di configurazione. Per popolare la cache vengono usati oggetti di tipo CacheItem i quali sono caratterizzati principalmente da 2 valori: una chiave (key) che conterrà un identificativo ai dati che si andranno ad inserire nella cache, e un valore (value) contenente i dati veri e propri. Ad ogni oggetto inserito in cache è possibile assegnare un oggetto CacheItemPolicy, che permette di controllare un set di dettagli di eliminazione e scadenza per una voce della cache specifica. Tali dettagli sono controllati tramite proprietà di tale oggetto, che poi verrà assegnato ad una specifica voce di cache al momento dell istanziazione del CacheItem stesso. Alcune delle principali proprietà utilizzabili sono: AbsoluteExpiration, che specifica un valore che indica se una voce della cache deve essere eliminata dopo una durata specificata. Priority, che specifica un impostazione di priorità utilizzata per stabilire se eliminare una voce della cache. SlidingExpiration contiene un valore indicante se deve essere eliminata una voce della cache se non vi è stato effettuato l accesso in un determinato intervallo di tempo. RemovedCallback ottiene o imposta un riferimento a un delegato CacheEntry- RemovedCallback chiamato dopo la rimozione di una voce dalla cache. In particolare RemovedCallback risulta comoda nella gestione delle voci in cache, infatti una peculiarità del sistema di caching è dato dal fatto che l eliminazione di una voce dalla cache è fatta in maniera completamente automatica, quindi senza richiedere la chiamata ad un metodo. Ad esempio si può immaginare di voler mantenere in memoria un certa quantità di dati che può essere settata tramite la proprietà dell oggetto ObjectCache CacheMemoryLimit. Il sistema di caching si preoccuperà di eliminare gli oggetti quando la loro mole supera il limite impostato di 87

27 Luca Pasa 3.6. SYSTEM.RUNTIME.CACHING Al momento dell eliminazione però è possibile essere informati dell evento, questo grazie alla RemovedCallback che ci permette di impostare un delegate nel quale è possibile ottenere la voce di cache eliminata ed eseguire le operazioni per gestire tale evenienza (ad esempio salvare l oggetto nella memoria di massa) di 87

28 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE 3.7 Windows Phone 7 Windows Phone 7 è il nuovo sistema operativo che Microsoft offre per l utilizzo su smartphone. Lo sviluppo di applicazioni avviene tramite l utilizzo della piattaforma Silverlight, utilizzando VB.NET o C# come linguaggio. Lo sviluppo di tali applicazioni deve tenere conto di alcune importanti linee guida, legata anche al ciclo di vità dell applicazione. Il ciclo di vita dell applicazione è regolato da un preciso modello d esecuzione che governa lo stato dell applicazione dal momento dell attivazione al suo spegnimento. Questo modello d esecuzione si pone lo scopo di mantenere l esperienza dell utente sempre veloce e reattiva. Bisogna tenere conto che Windows Phone 7 permette l esecuzione di un sola applicazione alla volta, ed il sistema operativo mette le applicazioni in stato dormiente quando essa non sono più in primo piano. Questo stato dormiente è detto tombstoning. Il sistema operativo permette però di far ripartire l applicazione ricreando lo stato precedentemente lasciato dall utente. I motivi per cui il sistema operativo si trovi nella situazione di dover mettere un applicazione in stato dormiente sono molteplici: ricezione di una chiamata; lo smartphone va in standby; l utente preme il bottone start o search; l applicazione richiede un operazione da parte di un altra applicazione esterna; Rigenerare la pagine a seguito del tombstoning porta a perseguire l obbiettivo di nascondere all utente che l applicazione è stata disattivata. Il sistema operativo mette a disposizione quattro eventi che permettono di gestire queste situazioni: Launching, Closing, Deactivated, e Activated. Questi eventi sono fortemente legati al ciclo di vita dell applicazione, in Figura 3.3 è riportata tale connessione. Figura 3.3: Ciclo di vita di un applicazione Windows phone 7. Questi eventi vengono sollevati in particolari momenti del ciclo di vita in particolari condizioni: di 87

29 Luca Pasa 3.7. WINDOWS PHONE 7 Launching: quando l applicazione viene avviata dall utente; Closing: quando l applicazione viene chiusa, ossia quando l utente preme il pulsante back ; Deativated: quando l applicazione viene disattivata e non chiusa; Activated: quando un applicazione dopo essere stata disattivata e messa in tombstoning viene riattivata tramite la pressione da parte dell utente del pulsante back. Per arrivare all obbiettivo di non far notare all utente che l applicazione è stata disattivata bisogna salvaguardare 2 tipi d informazione: page state: rappresenta lo stato grafico di una pagina dell applicazione. Viene utilizzato in quanto al rientro in un applicazione precedentemente disattivata viene visualizzata l ultima pagina che visibile al momento della disattivazione, è quindi importante fare in modo che al rientro la pagina risulti nello stesso stato in cui era stata lasciata precedentemente. Per eseguire il salvataggio dello stato della pagina vengono usati gli eventi OnNavigatedTo e OnNavigatedFrom che vengono sollevati rispettivamente quando si va a navigare nella pagina a cui l evento fa riferimento, e quando si lascia quella pagina. application state: rappresenta lo stato dell applicazione non legato ad un specifica pagina. Le informazione riguardanti l application state sono le informazioni globali (come ad esempio informazioni legate al loggin di un utente) e quindi utilizzate da più pagine dell applicazione. Quando un applicazione viene messa in tombstoning i dati per non essere persi devono essere salvati in maniera esplicita. A questo scopo il sistema operativo mette a disposizione una struttura dati di tipo dizionario che viene identificata con la proprietà PhoneApplicationService.State. Se l applicazione presenta dati che devono essere persistenti è possibile salvarli all interno del isolated storage, un area protetta di memoria posizionata nel disco del dispositivo, l equivalente del filesystem nei computer desktop. La velocità di caricamento dei dati da quest area di memoria può richiedere alcuni secondi, è quindi consigliabile utilizzarla solo per dati che richiedono di essere mantenuti per lungo tempo, o per oggetti non serializzabili. Come già riportato all inizio, lo sviluppo di applicazioni per Windows Phone 7 avviene utilizzando la piattaforma Silverlight. Quest ultimo per la creazione delle interfacce grafiche va ad utilizzare il linguaggio XAML. XAML è un linguaggio dichiarativo basato su XML, e come nel HTML gestisce gli elementi tramite attributi di 87

30 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE 3.8 Windows Azure platform Windows Azure Platform è una piattaforma che fornisce servizi di cloud computing ospitata all interno dei datacenter microsoft. Windows Azure Platform va inoltre a ridurre, nelle prime fasi, la necessità di acquisto di tecnologie, e rende possibile agli sviluppatori creare applicazioni che possono essere eseguite nel cloud in maniera semplice, sfruttando le loro conoscenze di sviluppo con.net Framework. Inoltre facilita la manutenzione e la gestione delle applicazioni fornendo un sistema on-demand per ospitare, scalare e gestire le stesse. L infrastruttura di gestione è automatizzata con una piattaforma pensata per assicurare un alta disponibilità e scalabilità dinamica in base alla necessità di utilizzo. Inoltre l ambiente di hosting è progettato per essere interoperabile e basato su standard, supportando numerosi protocolli internet come HTTP, REST, SOAP, e XML. Windows Azure Platform comprende diversi servizi per gli sviluppatori, tra i quali: Windows Azure: un sistema operativo per servizi cloud che viene utilizzato come ambiente di sviluppo, di hosting e gestione di servizi per Windows Azure Platform. Esso rende disponibile un sistema che permette di ospitare, eseguire, manipolare e rendere scalabili web application e servizi in internet all interno dei datacenter Microsoft. Windows Azure AppFabric: un insieme di servizi, fortemente scalabili, fondamentali nello sviluppo della maggior parte delle applicazione cloud-based e cloud-aware. Windows Azure AppFabric fornisce applicazioni con un interfaccia comune e semplice nella gestione, ricerca, ed esposizione di web service, dando così la possibilità agli sviluppatori di concentrarsi sulla logica dei loro servizi senza doversi preoccupare della gestione e dello sviluppo dell infrastruttura di cloud in cui essi operano. Windows SQL Azure: è un database relazionale (SQL Server) fornito come servizio su piattaforma Cloud. Esso si presenta come un servizio scalabile e assicura una alta disponibilità. L utilizzo di Windows SQL Azure permette di evitare l installazione di applicazioni, la configurazione e la gestione delle stesse, facilitando quindi l utilizzo delle applicazioni che richiedono l utilizzo di una base dati. In Figura 3.4 è riportata la struttura di Windows Azure Patform Windows Azure È il sistema operativo che funge da ambiente di sviluppo, hosting e controllo per windows Azure Platform. Windows Azure gestisce in automatico il bilanciamento di carico, delle risorse, ed il ciclo di vita dei servizi basandosi sulle scelte fatte dal gestore del servizio. Per esporre un servizio tramite Windows Azure è importante specificare la tecnologia del servizio e la sua configurazione, sarà però Windows Azure a gestire gli aggiornamenti e gli eventuali errori assicurando la disponibilità continua del servizio. Windows Azure si compone dei seguenti strumenti: Windows Azure Compute: Hosting Services: è l ambiente d esecuzione in cui viene gestito il codice di un applicazione o di un servizio. Esso è contenuto nell ambiente di hosting messo a disposizione da Windows azure, che si presenta scalabile e geograficamente distribuito tra diversi datacenter. Windows Azure Compute Service si compone di ruoli. Un ruolo si definisce come di 87

31 Luca Pasa 3.8. WINDOWS AZURE PLATFORM Figura 3.4: Struttura di Windows Azure Platform. un componente che può essere eseguito nell ambiente d esecuzione. È possibile che per ogni ruolo esistano una o più istanze. Sono presenti 3 tipi di ruoli: Web Role: è specializzato per applicazioni web e supporta IIS 7 e asp.net. La sua principale funzione è l interfacciamento verso i client, e quindi, si comporta come un componente front-end. worker role: il principale compito è eseguire lavori in background offrendo quindi il massimo del disaccoppiamento in termini di ricezione ed elaborazione del dato. Virtual Machine Role: offre la possibilità di creare localmente la propria Virtual Machine, o utilizzarne una già esistente, e poi pubblicare l intera macchina virtuale nell ambiente di cloud computing di Windows Azure. Questo ruolo si dimostra molto utile per poter migrare sull ambiente di cloud applicazioni monolitiche preesistenti, sviluppate ad esempio per windows server. Il servizio di host fornito permette tutte le possibili combinazione di questi ruoli, e anche l utilizzo di 2 o più ruoli dello stesso tipo. Windows Azure Storage Services: questi servizi sono forniti alla scopo di rendere dati persistenti. Essi sono accessibili da qualsiasi applicazione, anche se essa non è distribuita su windows Azure Platform. I Windows Azure Storage Services sono divisi in 3 principali categorie: Table Storage Services: forniscono uno storage strutturato per entità. Il Table Storage è costituito essenzialmente da colonne e righe. Il concetto di base è far persistere una o più entità del nostro dominio in una tabella. Ogni colonna corrisponde a una proprietà di quella entità e ogni riga a un istanza diversa. L approccio risulta efficace nel determinare il corretto funzionamento del meccanismo di scalabilità e di replica dei dati, aumentando decisamente il livello di affidabilità della piattaforma di storage di Windows Azure di 87

32 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE Blob Storage Services: Utili per persistere grosse quantità di dati non strutturati. I blob sono organizzati secondo una struttura gerarchica a tre livelli, che li suddivide per Account utente, Container e nome del blob. Queue Storage Services: La loro principale funzione è consentire la comunicazione, attraverso l accodamento di specifici messaggi, tra i vari servizi che compongono un applicazione (siano essi ubicati nel cloud o meno) e tra i Web Roles e i Worker Roles. Drive Storage Services: questo tipo di servizio va a simulare un drive NTFS che fornisce le funzionalità di un completo file system remoto. In realtà si tratta di un blob di grandi dimensioni opportunamente formattato Windows Azure appfabric Windows Azure appfabric fornisce una completa piattaforma di cloud middleware per sviluppare, implementare e gestire applicazioni su Windows Azure Platform. Essa permette di inalzare il livello d astrazione rendendo più agevole il lavoro degli sviluppatori sia in fase di sviluppo che in fase di manutenzione dell applicazione avvalendosi dei progressi del hardware sottostante e dell infrastruttura software. I servizi offerti da Windows Azure appfabric sono aperti e interpolabili, infatti supportano diversi linguaggi come ad esempio.net, java, PHP e Ruby. Inoltre Windows Azure appfabric fornisce agli sviluppatori una completa libreria di classi facilitando lo sviluppo di applicazioni orientate al cloud. Ovviamente tutti i servizi offerti da Windows Azure appfabric possono essere usati singolarmente o combinati fra loro. Oltre alla piattaforma middleware Windows Azure appfabric fornisce anche un ambiente di hosting per eseguire i propri componenti, come ad esempio servizi WCF. Questo servizio di hosting risulta quindi orientato alla scalabilità, diventando molto utile per lo strato business logic delle applicazione che si andranno ad implementare nel cloud. Tramite questa piattaforma middleware è possibile sviluppare e gestire applicazione che utilizzano diversi strati di applicativi e diversi ambienti come siano un sola entità. Windows Azure appfabric permette di implementare applicazioni che sfruttano il concetto della scalabilità orizzontale, ossia la possibilità di aggiungere risorse esterne ad un applicazione distribuita, applicando politiche di load balancing. Per fare ciò i componenti vengono clonati e distribuiti. Inoltre vengono applicate politiche per assicurare la massima disponibilità degli stessi. Windows Azure appfabric comprende 3 servizi che forniscono importanti funzionalità alla applicazioni Windows Azure: AppFabric Service Bus: Lo scopo di questo servizio è connettere applicazioni e dati locali che sono posti dietro a firewall e dispositivi NAT, ad applicazioni desktop o smart device senza dovere aprire porte nel firewall o aggiungere eccezioni ai dispositivi NAT. Inoltre l utilizzo di Service bus aumenta la sicurezza del servizio grazie anche all indirizzo che viene gestito tramite un sistema di namespace il quale risulta completamente indipendente dalla posizione geografica del servizio, non dando così alcuna informazione sulla destinazione finale della comunicazione. In Figura 3.5 è riportato lo schema di funzionamento di Windows Azure AppFabric Service Bus. AppFabric Access Control: è un sistema interoperabile per la gestione di autenticazione ed autorizzazioni di tipo claim-base per servizi web e REST. Esso è utilizzabile su ogni piattaforma, e permette di gestire in maniera facile l inserimento di nuovi client. Inoltre supporta numerosi protocolli quali OAuth, di 87

33 Luca Pasa 3.8. WINDOWS AZURE PLATFORM Figura 3.5: Service Bus WRAP (Web Resorce Authorization Protocol), SWT(Simple Web Token) e permette l integrazione con molti entity provider. AppFabric Caching Service: fornisce un sistema di caching distribuito che aiuta le applicazioni Windows azure a migliorare le proprie prestazioni e la propria scalabilità. Questo sistema va ad automatizzare le politiche di caching nel cloud, permettendo la configurazione della stessa sia da codice che da file di configurazione. Questo servizio si basa su un sistema di accesso alla cache tramite coppie di chiavi, e risulta utilizzabile anche in presenza di esecuzione concorrente. Tramite Service bus e access control è possibile costruire applicazioni capaci di interagire con client posizionati dietro firewall e dispositivi NAT, e capaci di implementare efficaci politiche di autenticazione e autorizzazione. Inoltre forniscono importanti elementi d infrastruttura che facilitano la comunicazione tra applicazioni. Nel realizzare applicazioni distribuite, capaci di comunicare attraverso internet, gli ostacoli che si incontrano sono parecchi. Le applicazioni eseguono su computer che sono all interno di reti locali solitamente protette da firewall e dispositivi NAT(Network Address Translation). Molte volte i client non sono computer ma smart device o cellulari. Molte volte i dati di cui si necessita sono all interno di server e sono incapsulati in formati non standardizzati. Molte applicazioni distribuite attualmente presenti nel mercato utilizzano metodi rudimentali per la comunicazione tra piattaforme diverse, andando fortemente a limitare il riutilizzo di codice. Allo scopo di risolvere queste ed altre problematiche possono essere utilizzati servizi come service bus e access control, i quali forniscono metodologie e strumenti per creare e manutenere applicazioni distribuite. Windows Azure AppFabric fornisce inoltre un ambiente che permette di creare soluzioni comprendenti applicazioni+servizi fortemente scalabili e sicure, capaci di comunicare attraverso il cloud come fossero un unica entità di 87

34 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE Windows Azure AppFabric Service Bus Windows Azure AppFabric Service Bus è un servizio pensato per l utilizzo da parte di sviluppatori, il quale permette lo sviluppo di applicazioni fortemente scalabili. Il primo scopo di Windows Azure AppFabric Service Bus è quello di ritrasmettere i messaggi attraverso il cloud ai servizi on-premises che solitamente eseguono protetti da firewall e sistemi NAT (Network Address Translation). Windows Azure AppFabric Service Bus va a sfruttare le funzionalità messe a disposizione da Windows Azure AppFabric Access Control per assicurare accessi sicuri agli endpoint tramite l utilizzo del modello di sicurezza claim-based. Queste due applicazioni insieme vanno a comporre una struttura di sviluppo richiesta dalla maggior parte delle applicazioni cloud, semplificando lo sviluppo e dando la possibilità allo sviluppatore di concentrarsi principalmente sulla logica della propria applicazione. Il motivo per cui questo servizio offerto da Windows Azure AppFabric si chiama Service Bus è dato dalla volontà di sottolineare le caratteristiche dell architettura sottostante. Le caratteristiche in questione sono molto comuni al giorno d oggi per quanto riguarda le varie produzioni che incarnano il pattern architetturale ESB ( Enterprise Service Bus). Questo pattern definisce un modello d interazione per applicazioni enterprise attraverso i comuni sistemi di comunicazione di messaggi o bus. Nella figura Figura 3.6 è riportata la struttura del pattern ESB: Figura 3.6: Pattern ESB. Il Pattern ESB prevede la presenza di un meccanismo di Federated Identity e controllo degli accessi, un service naming, un service regisry ed infine una messaging fabric che permette l utilizzo di diverse opzioni di comunicazione. Questo modello crea un livello d indirezione tra i vari servizi presenti nel bus e le applicazioni che consumano questi servizi. Inoltre aiuta a risolvere differenze tra i vari servizi per quanto riguarda la gestione delle identità, le convenzioni sui nomi ed il formato dei messaggi. Questo pattern è diventato popolare negli anni in quanto semplifica la gestione delle connessione multiple a servizi. Per fare ciò abilita l architettura publish/subscrive tramite la quale i client non si connettono direttamente al servizio, ma attraverso il bus, rendendo possibile l aggiunta e la rimozione di nodi in qualsiasi momento. L applicazione di questo pattern nel mondo internet e del cloud computing porta a dover considerare alcuni importanti aspetti, come ad esempio il fatto che i vari componenti che compongono ESP devono assicurare un ottima scalabilità ed un com di 87

35 Luca Pasa 3.8. WINDOWS AZURE PLATFORM portamento omogeneo. L implementazione della comunicazione bidirezionale tra un servizio ed un consumatore client, sia esso una applicazione desktop, una RIA o un applicazione web, deve prevedere il rischio che essi siano dietro un firewall e/o un meccanismo NAT. Per quanto riguarda la gestione dei problemi creati dai sistemi NAT nell implementazione di una comunicazione bidirezionale, si pensi alla difficoltà di tracciare la comunicazione dal momento che il richiedente potrebbe avere un indirizzo ip privato all interno della rete, e un indirizzo pubblico che risulta comune a tutta la rete. Un altro problema riguarda la sicurezza, si pensi infatti che la maggior parte delle applicazioni on-premises sono protette da strati e strati di firewall e altri strumenti di rete. Questo si rende necessario per prevenire le molteplici minacce che l utilizzo di internet porta con sè. Inoltre la maggior parte dei dispositivi connessi alla rete mantengono aperte varie porte in uscita sul firewall ma solo poche in entrata, le quali sono fondamentali per l inizio delle comunicazione di un nodo esterno con l applicazione situata dietro il firewall. Molte aziende per risolvere questo problema aprono alcune porte in entrata sul firewall, oppure usano soluzioni come l adozione DNS dinamici, mapping delle porte del sistema NAT, UPnP, che però sono fragili, difficili da gestire, e rischiose dal punto di vista della sicurezza. C è da considerare però che in molte applicazioni come ad esempio i software di instant messaging, o i giochi multyplayer sì è riusciti a risolvere questo tipo di problemi andando però a scrivere codice a basso livello che andasse ad interessare la logica della rete stessa, con lo scopo, quando possibile, di stabilire una connessione diretta, altrimenti sostituita da una indiretta utilizzando un servizio ripetitore dei messaggi. Questo ripetitore in Windows Azure AppFabric Service Bus è detto relay service. Figura 3.7: Schema Relay Service. All inizio della comunicazione il servizio andrà a contattare il relay service attraverso un porta d uscita andando a creare un socket di comunicazione bidirezionale collegato ad un indirizzo concordato. A questo punto il consumatore del servizio può contattare il servizio stesso mandando un messaggio al relay service il quale di 87

36 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE si occuperà di reindirizzarlo al servizio. Ciò fa sì che il client non sia costretto a stabilire un connessione diretta con il servizio. Windows Azure AppFabric Service Bus è una implementazione concreta del pattern ESB pensato per poter operare in internet. Una delle principali caratteristiche è la forte scalabilità offerta, inoltre esso è uno dei servizi che costituiscono WIndows Azure Plataform. Windows Azure AppFabric Service Bus implementa tutti i componenti propri del design pattern ESB, in particolare uno dei principali componenti che costituiscono il messaging fabric di Service Bus e un realy service capace di operare con molti protocolli di trasporto e standard Web service, come ad esempio SOAP, WS-* e REST. Esso è centralizzato ed implementa politiche di load-balance. Inoltre mette a disposizione numerose opzioni per la connessione e aiuta nella creazione di connessione diretta quando possibile. Windows Azure AppFabric Service Bus è utilizzabile a prescindere dalla piattaforma, ma è fortemente ottimizzato per l utilizzo tramite.net e WCF, sia dal punto di vista delle prestazione che dell usabilità.prevede inoltre la possibilità di accesso al proprio relay service sia attraverso interfacce REST che attraverso interfacce SOAP, rendendo così possibile il suo utilizzo a qualsiasi ambiante REST o SOAP. Sono presenti molti SDK pensati per l utilizzo di Service bus per l utilizzo con diverse piattaforme di sviluppo come ad esempio.net, Java e Ruby. Anche la scelta dell indirizzo del nostro servizio diventa un aspetto molto importante: si pensi ad esempio a come funzionano i DNS (Domain Name System), i quali vanno a mappare i domain name con indirizzi IP. Il problema principale è che i DNS riescono a gestire indirizzi IP pubblici, ma non riescono a gestire gli host che sono nascosti da dispositivi NAT, se non utilizzando altri servizi come i Dynamic DNS. Quindi si può intuire che il DNS non risulta una buona tecnologia in un contesto orientato ai servizi, in questo scenario è vantaggioso l utilizzo dei Service Bus Naming System il quale mappa i namespace dei vari servizi rendendo così necessario che essi siano univoci. Questo sistema crea, a partire dai namespace, delle URI che sono completamente indipendenti dall host. Le URI che vengono create seguiranno il seguente schema: [scheme]://[service-namespace].servicebus.windows.net/[name1]/[name2]... Il primo campo può essere uno dei protocolli che Service bus supporta come ad esempio http, https o sb. Nel secondo campo trova spazio il namespace del servizio che si andrà ad esporre. Tutto ciò che invece è presente a seguito dell indirizzo base (ossia i campi opzionali name1, name2 ecc.) sono nomi che sono assegnati dallo sviluppatore per identificare uno specifico endpoint. Tali endpoint non devono essere ubicati all interno dello stesso server, ma sarà compito di Service bus ed in particolare del relay service capire dove sono posizionati gli endpoint al momento della risoluzione dell indirizzo stesso. Per gestire la risoluzione di tali indirizzi Service bus utilizza il service registry. Ogni qual volta viene registrato un nuovo endpoint esso viene anche aggiunto nel registro, Il registro è consultabile all indirizzo base del servizio, dove viene esposto come feed atom 1.0. Perché ciò accada bisogna andare ad impostare il comportamento del endpoint tramite la proprietà DiscoveryMode presente nel ServiceRegistrySetting. Uno dei punti di forza di Service Bus è indubbiamente il Relay Service. Il Relay Service rende facile la creazione di soluzioni capaci di comunicare attraverso firewall e dispositivi NAT. Inoltre supporta diverse modalità di comunicazione tra cui la modalità peer-to-peer. Altro indubbio vantaggio è dato dal fatto che viene supportata sia la modalità di esposizione di tipo publish/subscrive sia la più efficiente (ma non sempre utilizzabile) modalità point-to-point. L utilizzo del relay service porta a delegare ad esso la responsabilità di gestire del di 87

37 Luca Pasa 3.8. WINDOWS AZURE PLATFORM transport-level. In questo modo il servizio non si deve più preoccupare di creare localmente un sistema per la gestione del trasporto dei messaggi, ma si affida al relay service il quale sì occuperà di andare a gestire i dettagli riguardanti il trasporto dei messaggi e la comunicazione. Sarà infatti il relay service che si occuperà di inoltrare al nostro servizio on-premises i messaggi in ingresso. Il realy service risiede nel cloud, ed anche per questo risulta un servizio scalabile. Sempre per questo motivo il nostro servizio on-premises dovrà stabilire una connessione con il realy service. In WCF questa operazione viene automatizzata tramite l utilizzo di uno dei realy binding. Infatti avviene una mappatura tramite relay binding di un nuovo oggetto transportbindingelement utilizzato da WCF per la creazione del canale di comunicazione il quale va ad integrarsi con service bus nel cloud. Durante la connessione avviene l autenticazione, viene specificato quale indirizzo deve assere monitorato per la ricezione dei messaggi e quale modalità di recezione viene utilizzata. Tramite i WCF relay bindings è possibile utilizzare molteplici opzioni riguardanti il trasporto ed il formato dei messaggi, rendendo questa tecnologia versatile ed utilizzabile come soluzione di molti problemi legati alla comunicazione via internet. Realy service richiede che siano aperte sul firewall solo poche porte in uscita. Tali porte sono in base alle caratteristiche di connessione che si vogliono utilizzare, ad esempio l utilizzo della connessione monodirezionali TCP utilizza la porta in uscita È importante sottolineare che non è necessario aprire nessuna porta in entrata e/o configurare in qualche modo il dispositivo NAT per poter utilizzare realy service. Se l ambiente in cui state lavorando è molto restrittivo, tanto da avere ogni porta in uscita bloccata ad eccezione delle porte utilizzate dal protocollo http e https sarà comunque possibile utilizzare relay service abilitando la speciale opzione di connessione Web socket la quale istanzierà la connessione al relay service utilizzando le porte definite per la comunicazione tramite http/https. Relay service va a nascondere i dettagli legati alla locazione del servizio andando così a proteggere lo stesso da potenziali attacchi, inoltre l utilizzo di Windows Azure AppFabric Access control va a rendere sicuro il meccanismo di autenticazione tramite l implementazione del paradigma di sicurezza claim-base, rendendo inoltre tale aspetto flessibile e di facile gestione. Da notare la forte separazione del relay service dall ambiente locale del servizio, esso infatti può essere paragonato ad un DMZ (Demilitarized Zone) che come il relay service gestisce tutto il traffico di rete esternamente al servizio, andando a filtrarlo prima che esso entri nell ambiente dove il nostro servizio è ubicato. Service bus diventa molto comodo da utilizzare se si vanno a creare servizi utilizzando WCF, infatti quest ultimo mette a disposizione diversi tipi di binding preimpostati, i quali hanno il merito di integrare in maniera semplice i servizi WCF e i client utilizzando il relay service. La maggior parte dei binding utilizzati da servizi WCF senza utilizzare service bus trovano un corrispettivo che va ad integrare quest ultimo. I binding offerti da service bus per l integrazione con WCF hanno caratteristiche molto simili ai corrispondenti binding WCF standard, e supportano buona parete delle loro caratteristiche, come ad esempio strutture di messaggi SOAP e protocolli WS-*. Di seguito è riportata la lista dei binding che possono essere usati con service bus: NetTcpRelayBinding NetOnewayRelayBinding NetEventRelayBinding BasicHttpRelayBinding di 87

38 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE WebHttpRelayBinding WS2007HttpRelayBinding Alcuni binding hanno caratteristiche comuni, come ad esempio gli ultimi tre citati, mentre altri sono creati specificatamente per l utilizzo con un particolare protocollo. Vengono ora riportate in maniera estesa tali caratteristiche: NetTcpRelayBinding questo binding è il più utilizzato nel contesto di trasmissione attraverso internet. Il TCP relay binding si pone l obiettivo di minimizzare l overhead (preoccupandosi meno delle perfomance e del throughput) sia per quanto riguarda il relay service, sia per quanto riguarda il servizio stesso. Il TCP relay binding supporta SOAP 1.2 over tcp ed utilizza un metodo di serializzazione binaria dei dati per assicurare una buona efficenza. Vengono supportate due modalità di connessione: Relayed: la comunicazione avviene sempre tramite realy service; Hybrid: la connessione inizialmente avviene tramite realy service, mentre il client ed il servizio negoziano una connessione diretta tra loro. Questa connessione diretta viene coordinata dal relay service. l algoritmo che porta a stabilire la connessione diretta è capace di eseguire tale connessione anche se le due parti sono nascoste dietro firewal e/o dispositivi NAT. Se la connessione diretta non può essere stabilita, si continuerà ad utilizzare la connessione tramite relay service. Se invece la connessione diretta viene stabilita, la connessione tramite relay service viene automaticamente aggiornata ad essa, andando ad eliminare il rischio di perdita di dati o pacchetti ed rendendola molto più veloce. Questa connessione dal punto di vista delle prestazioni è rapportabile ad una VPN (Virtual Private Network), delle quale pero non condivide la complessità nell installazione. NetOnewayRelayBinding: è l unico binding a supportare la connessione one-way per la quale è ottimizzato. Tale metodo permette al client di inviare messaggi ad un buffer che verrà mantenuto nel relay service, messaggi che mano a mano verrano poi inviati al servizio. Di default va ad utilizzare SOAP 1.2 over tcp, ma tale scelta può essere variata mediante configurazione. Per quanto riguarda il protocollo utilizzato questo binding richiede il protocollo sb. Utilizzando la configurazione di default di questo binding un servizio onpremises cerca di stabilire un connessione con il relay service, con l obiettivo di creare un socket bidirezionale. Durante la connessione avviene anche l autenticazione (tramite il token acquisito da access control), e viene specificato il nome del servizio che si utilizzerà all interno del relay service. Anche i client, utilizzando la configurazione standard, si autenticheranno al momento della connessione utilizzando il token ottenuto da access control. Una volta autenticato, il client può cominciare ad inviare i messaggi in modalità one-way al relay service che poi li reindirizzerà al servizio on-premises precedentemente collegato. La connessione può avvenire tramite protocollo TCP, ma se non possibile a causa delle corrispondenti porte non accessibili nel firewall, la connessione avviene tramite protocollo HTTP/HTTPS. NetEventRelayBinding: l implementazione dal punto di vista della connessione e della sicurezza è la stessa utilizzata nel NetOnewayRelayBinding, La principale di 87

39 Luca Pasa 3.8. WINDOWS AZURE PLATFORM differenza da quest ultimo è data dalla possibilità di registrare più servizi WCF con lo stesso indirizzo service bus. Quando un client invierà un messaggio il relay service inoltrerà lo stesso a tutti i servizi WCF collegati a quel indirizzo. HTTP Realy Bindings: in questa categoria rientrano BasicHttpRelayBinding, WebHttpRelayBinding e WS2007HttpRelayBinding. Questo tipo di binding viene utilizzato se non si vuole limitare ai soli client WCF l interazione con l endpoint del servizio, infatti i messaggi che il relay service và ad inoltrare saranno basati su HTTP. Mentre WebHttpRelayBinding e BasicHttpRelayBinding sono basati rispettivamente su HTTP/REST e SOAP, WS2007HttpRelayBinding supporta gli standard della famiglia WS-*, quindi i client dovranno supportare lo stesso standard WS-* che viene utilizzato dall endpoint. Tutti e 3 questi binding hanno un metodo d interazione con il relay service pressoché identico. Per prima cosa il servizio WCF va ad stabilire la connessione con il relay service tramite TCP o HTTP. Il client invierà messaggi all endpoint HTTP esposto tramite il relay service, in questo modo non è necessario che il client utilizzi WCF per comunicare con il servizio, qualsiasi client compatibile con HTTP/SOAP può comunicare con esso. Ogni qual volta arriva un messaggio dal client viene reindirizzato da Service bus al servizio dando anche indicazioni su come ricontattare il client per inoltrare la risposta tramite l HTTP socket. Nel progetto corrente viene utilizzato WebHttpRelayBinding in quanto si espone un servizio RESTful Windows azure AppFabric access control service Windows azure appfabric access control service è un sistema di gestione dell autenticazione e delle autorizzazioni basato su sicurezza claim-base. I sistemi di sicurezza claim-base permettono di nascondere al servizio i dettagli di autenticazione e autorizzazioni degli utenti. Per fare ciò si va ad utilizzare un entità di fiducia (relyng parties). Il relyng parties riceve una richiesta da un client che vuole accedere al servizio e restituisce un token contenente una o più claims. Un claims è un asserzione rilasciata da un entità per un altra entità nella quale vengono inviate informazione relative all utente che ha richiesto l accesso, come la sua identità e le sue autorizzazioni. Tale informazioni vengono recapitate al servizio il quale ha modo di verificare la veridicità del token e quindi autorizzare l accesso da parte dell utente. In questo modo il servizio non deve più preoccuparsi della gestione degli utenti, che verrà invece affidata ad un identity provider che verrà contattato dal relyng parties al fine di acquisire le informazioni necessarie per la creazione del token. Windows azure appfabric access control viene utilizzata da service bus per autenticare e autorizzare i client prima che essi possano collegarsi al relay service. la necessità di autenticazione per accedere al servizio può comunque essere disabilitata. L autenticazione di service bus può essere eseguita da qualsiasi identity provider di cui access control si fida. Sarà compito di quest ultimo produrre un token e i rispettivi claim richiesti da service bus per la gestione delle autorizzazioni. Access control può essere collegato a diversi entity provider contemporaneamente, andando di fatto ad agire come un autorità centralizzato di controllo degli accessi. Inoltre Access control mette a disposizione un proprio entity provider che può essere gestito tramite un apposita interfaccia messa a disposizione dallo stesso. Service bus è stato disegnato per l integrazione con access control, e questo comporta che service bus si aspetti dei precisi claim incapsulati nei token prodotti da access control, questo vale sia per i client che per i servizi. i principali claim sono: di 87

40 Luca Pasa CAPITOLO 3. TECNOLOGIE UTILIZZATE listen: che permette di creare un listener che permetta di ascoltare i messaggi nel realy service; send: che permette di inviare messaggi nel relay service; manage: che permette di gestire il namespace del servizio. Al momento della richiesta da parte di un client o di un servizio ad access control, che richiede l invio delle credenziali, per effettuare l autenticazione e/o ottenere autorizzazioni viene presa, da parte di quest ultimo, una decisione su quali autorizzazioni concedere. Tale scelta viene fatta in base al servizio al quale si tenta di accedere, e nel caso di valide credenziali, access control emetterà il relativo token contente le autorizzazioni a service bus. Al momento dell emissione access control va a firmare il token in modo che service bus possa appurare con certezza la sua provenienza. Quando un client manda un messaggio al relay service incapsulando insieme il token che certifica i permessi per eseguire quell azione, service bus per ragioni di sicurezza elimina il token dal messaggio prima di reindirizzarlo al servizio. La Figura 3.8 illustra tale comportamento. Figura 3.8: Interazione tra access control e service bus di 87

41 Capitolo 4 Descrizione del problema Il problema che questo progetto si propone di risolvere riguarda la creazione di un sistema software in grado di esporre immagini catturate da una webcam a più client. Si vuole che il servizio esponga immagini sotto forma di feed RSS, e che, per l accesso allo stesso non sia richiesta autenticazione. È inoltre richiesto che per l esposizione ed il consumo dei dati non sia necessario compiere alcuna operazione di tipo sistemistico, anche su terminali protetti da dispositivi firewall, Nat, e proxy. È necessario che i dati esposti godano di un buon grado di sicurezza, evitando quindi ad esempio esposizioni in DMZ. La soluzione deve tenere d occhio anche l aspetto economico, andando a prevedere un sistema software che minimizzi il TCO. Ogni immagine esposta deve essere riconducibile alla data e all ora in cui è stata catturata dalla webcam, inoltre le immagini devono rimanere raggiungibili anche a seguito della loro uscita dal feed, dovuta alla loro vecchiaia, rimanendo reperibili fino a quando l applicazione che le espone rimane in vita, evitando così problemi per i client che ne mantenessero un riferimento. Il feed deve esporre immagini ordinate per data e ora andando sempre ad esporre l immagine più aggiornata catturata dalla webcam. L applicazione che va ad esporre le immagini deve essere scalabile non risentendo quindi dell aumento delle richieste eseguite da un elevato numero di client. È necessario che l indirizzo scelto per l esposizione del feed RSS sia indipendente dalla locazione geografica della macchina ospitante l applicazione che esegue l esposizione delle immagini, e che tale indirizzo rimanga costante nel tempo. L applicazione che espone le immagini deve agire come un servizio, andando a permette un interazione con i client e permettere richieste parametrizzate al fine di poter restituire una partizione dei dati in base alla singola richiesta. Tale applicazione oltre ad esporre le immagini deve prevedere una finestra che mostri, sul dispositivo ospitante, un anteprima delle immagini catturate dalla webcam. Per quanto riguarda l interazione con la webcam è richiesta una finestra di configurazione della stessa, dove sia possibile selezionare quale dispositivo webcam utilizzare (nel caso di più dispositivi collegati) e la risoluzione dell immagine (tra quelle supportate dalla webcam). L applicazione deve prevedere la possibilità di fermare e far ripartire l acquisizione di immagine, e quindi l esposizione senza che l applicazione debba essere spenta e riavviata. Le immagini esposte devono poter essere consumate principalmente da tre tipi di client: Feed Reader; 41

42 Luca Pasa CAPITOLO 4. DESCRIZIONE DEL PROBLEMA Applicazione Desktop; Applicazione mobile. Nel caso dei feed reader le immagini devono essere esposte in base alla data e all ora a loro associata, devono essere visualizzate solo le più aggiornate, andando ad eseguire l aggiunta continua dell immagine più recente e l eliminazione della più anziana. Per quanto riguarda il formato del feed è richiesto che venga usato il formato RSS 2.0 basato su standard XML. L applicazione desktop deve collezionare le immagini esposte dal servizio e renderle visualizzabili all utente. È necessario che l interazione con il servizio e il download dei dati non comporti rallentamenti, all interfaccia utente. Deve essere gestita la casistica in cui il servizio non risultasse disponibile prima o durante l esecuzione. Si richiede che tale applicazione esponga due modalità di utilizzo: la prima che permette di navigare tra le immagini ottenute, la seconda in cui viene visualizzata sempre l immagine più aggiornata. L applicazione mobile deve poter essere eseguita su dispositivi windows phone 7. Anch essa deve collezionare le immagini ricevute dall applicazione che le espone. Anche in questo caso sono richiese due modalità di utilizzo: la prima che permetta la navigazione tra le immagini collezionate dall applicazione, mentre la seconda che permetta di visualizzare l immagine più recente ottenuta. L interazione con l applicazione che espone i dati ed il download degli stessi non deve comportare rallentamenti dell interfaccia utente. 4.1 Analisi Requisiti Di seguito vengono riportati i requisiti alla quale la soluzione al problema sopraesposto dovrà sottostare al fine di soddisfare le richieste che il problema stesso propone. Sono stati rilevati 3 principali componenti: il servizio, il quale ha il compito di catturare ed esporre le immagini tramite un feed; il client Desktop, che ha il compito di consumare i dati esposti dal servizio da un computer desktop; il client Mobile che mostra le immagini esposte dal servizio su un dispositivo Windows phone 7. I requisiti di seguito esposti sono divisi per componente, in quanto ogni componente risulta essere una applicazione distinta Servizio Il servizio ha il compito di comunicare con la webcam e ottenere le immagini, fatto ciò le va ad esporre tramite un feed rss 2.0. Di seguito vengono riportati i requisiti che tale applicazione deve avere: R_S_1: il sistema deve catturare immagini tramite l utilizzo di una webcam; R_S_1.1: il sistema permette di scegliere quale webcam utilizzare (nel caso vi sia la presenza di più webcam); R_S_1.2: il sistema permette di scegliere la risoluzioni delle immagini catturate in base alla risoluzioni supportare dalla webcam; di 87

43 Luca Pasa 4.1. ANALISI REQUISITI R_S_2 il sistema deve esporre le immagini acquisite; R_S_2.1: oltre alle immagini deve essere esposta anche la data e l ora in cui l immagine è stata catturata; R_S_2.2: l esposizione dei dati deve avvenire nella rete internet; R_S_3 le immagini acquisite devono essere esposte tramite feed; R_S_3.1: il feed esposto deve rispettare il formato RSS 2.0; R_S_4: per l accesso alle immagini esposte non è necessaria l autenticazione; R_S_5: l esposizione del servizio non deve richiedere alcun operazione sistemistica sul dispositivo ospitante; R_S_5.1: non deve essere necessario modificare in alcun modo le regole di un eventuali firewall; R_S_5.2: non deve essere necessario inserire alcuna nuova eccezione ad eventuali sistemi NAT; R_S_5.3: non deve essere necessario modificare alcuna impostazione di eventuali proxy; R_S_6: l indirizzo dove è esposto il feed deve essere indipendente dal dispositivo in cui è ospitato il servizio; R_S_7 ogni immagine esposta deve essere collegata alla data e all ora in cui è stata catturata; R_S_8: il feed esposto deve contenere un numero limitato di immagini al fine di mantenere la leggibilità dello stesso; R_S_9: le immagini devono rimanere reperibili anche a seguito dell eliminazione dal feed; R_S_9.1: le immagini devono rimanere reperibili fino a che il servizio rimane attivo; R_S_10: il feed deve essere aggiornato ogni qualvolta viene catturata una nuova immagine; R_S_11: l applicazione deve essere scalabile; R_S_12: il servizio deve esporre metodi che tramite una parametro permettano di ottenere una singola immagine o una insieme di immagini; R_S_13: l applicazione deve mostrare un anteprima di ogni immagine catturata; R_S_14: l applicazione deve permettere di bloccare e far ripartire successivamente la cattura e l esposizione delle immagini; R_S_15: il servizio esposto deve essere fortemente interoperabile; R_S_15.1: il servizio deve essere consumabile da un feed reader; R_S_15.2: il servizio esposto deve potere essere consumato da applicazioni desktop; R_S_15.3: il servizio esposto deve poter essere consumato da applicazioni mobile; di 87

44 Luca Pasa CAPITOLO 4. DESCRIZIONE DEL PROBLEMA R_S_15.4: il servizio deve poter essere consumato senza dover conoscere o utilizzare particolari tecnologie collegate alla realizzazione dello stesso; R_S_16: l applicazione deve preoccuparsi di non occupare troppa memoria; R_S_16.1:la memoria occupata dall applicazione non deve compromettere l utilizzabilità del dispositivo in cui viene eseguita; R_S_17: l applicazione deve permettere ai client di ottenere le sole immagini desiderate; R_S_17.1: l intervallo minimo tra un immagine resa disponibile e la successiva deve essere di un secondo Client Desktop L applicazione desktop va a recuperare i dati esposti dal servizio e li visualizzerà all utente mostrando l immagine e la data e l ora in cui l immagine è stata catturata. Di seguito vengono riportati i requisiti che tale applicazione deve avere: R_D_1: l applicazione deve eseguire in un ambiente desktop; R_D_2: l applicazione deve interfacciarsi con il servizio per ottenere i dati da visualizzare; R_D_3: l applicazione deve gestire il caso in cui il servizio risulti non disponibile all inizio o durante l esecuzione; R_D_4: l applicazione deve permettere la visualizzazione delle immagini; R_D_4.1: l applicazione deve visualizzare la data in cui è stata catturata l immagine; R_D_4.2: l applicazione deve visualizzare le immagine ordinate in base alla data in cui sono state catturate dalla webcam; R_D_5: l applicazione deve permettere all utente di navigare tra le immagini salvate; R_D_6: l applicazione deve aggiornare periodicamente la lista delle immagini, aggiungendo le più recenti; R_D_6.1: l applicazione deve eseguire l aggiornamento ad intervalli regolari; R_D_6.2: l applicazione, nel calcolo dell intervallo per l aggiornamento, deve tenere conto del tempo richiesto per il download dei dati; R_D_7: l applicazione deve prevedere due modalità di visualizzazione delle immagini; R_D_7.1: l applicazione deve rendere disponibile una modalità di visualizzazione dove l utente può scorrere tra le immagini attualmente presenti in memoria; R_D_7.2: l applicazione deve rendere disponibile una modalità di visualizzazione delle immagini dove viene visualizzata sempre l immagine più recente; di 87

45 Luca Pasa 4.1. ANALISI REQUISITI R_D_8: l applicazione deve mantenere in memoria non più un di numero massimo di immagini; R_D_8.1: il numero massimo di immagini deve assicurare che l applicazione non occupi più memoria del necessario; R_D_8.2: l applicazione deve mantenere in memoria un numero d immagini significativo; R_D_8.3: l applicazione, al raggiungimento della soglia del numero di immagini che deve mantenere, deve preoccuparsi di eliminare le meno recenti al momento dell arrivo di nuove immagini dal servizio; R_D_9: le interazioni con il servizio non devono in alcun modo rallentare o appesantire l interazione con l utente Client Mobile L applicazione client deve essere eseguire sul sistema operativo Windows phone 7. Essa si interfaccia con il servizio al fine di recuperare i dati e visualizzarli all utente. Di seguito vengono riportati i requisiti che tale applicazione deve rispettare: R_M_1: l applicazione deve eseguire su dispositivi Windows Phone 7; R_M_1.1: l applicazione deve essere sviluppata su piattaforma Silverlight; R_M_2: l applicazione deve interfacciarsi con il servizio per ottenere i dati da visualizzare; R_M_3: l applicazione deve mostrare i dati esposti dal servizio; R_M_3.1: l applicazione deve visualizzare le immagini esposte dal servizio; R_M_3.2: l applicazione deve visualizzare la data e l ora in cui l immagine è stata catturata dalle webcam; R_M_3.3: l applicazione deve visualizzare le immagini ordinate secondo la data è l ora in cui sono state catturate; R_M_4: l applicazione deve mantenere in memoria un numero consono di immagini; R_M_5: l applicazione deve aggiornare periodicamente le immagini in memoria; R_M_5.1: se si è raggiunto il numero massimo di immagini mantenibili in memoria l applicazione deve preoccuparsi di eliminare le immagini meno recenti; R_M_5.2: l aggiornamento va eseguito ad intervalli regolari; R_M_6: l applicazione deve prevedere due modalità di visualizzazione delle immagini; R_M_6.1: l applicazione deve rendere disponibile una modalità di visualizzazione dove l utente può scorrere tra le immagini attualmente presenti in memoria; R_M_6.2: l applicazione deve rendere disponibile una modalità di visualizzazione delle immagini dove viene visualizzata sempre l immagine più recente; di 87

46 Luca Pasa CAPITOLO 4. DESCRIZIONE DEL PROBLEMA R_M_7: le interazioni con il servizio non devono in alcun modo rallentare o appesantire l interazione con l utente; R_M_7.1: le interazioni con il servizio devono essere eseguite tutte on maniera asincrona; R_M_8: l applicazione deve gestire il caso in cui il servizio risulti non disponibile all inizio o durante dell esecuzione; R_M_9: l applicazione deve implementare politiche che permettano all applicazione di essere sospesa e successivamente riattivata; R_M_9.1: al momento della riattivazione l applicazione deve presentarsi graficamente come al momento della precedente chiusura di 87

47 Capitolo 5 Definizione Soluzione Dato il problema precedentemente esposto e i requisiti emersi in fase di analisi è stato scelto di andare a creare una soluzione che rispetti alcuni importanti principi: la soluzione è sviluppata su piattaforma.net; la soluzione deve minimizzare il TCO; la soluzione si compone di tre macro componenti: un servizio, un client desktop e un client windows phone 7; per la gestione e l esposizione del servizio ci si appoggia su Windows Azure AppFabric; il servizio è di tipo on-premise e la comunicazione con i client verrà gestita grazie a Windows Azure AppFabric service bus. Il servizio va ad esporre metodi per l acquisizione di un feed contente i link alle immagini scattate, la loro data e la loro descrizione, ed inoltre va ad esporre le immagini stesse ai quali i link fanno riferimento. Tale feed può essere letto dai client che, nel caso del client desktop e del client WP7, possono quindi ottenere una lista di riferimenti alla immagini disponibili e quindi decidere come gestire tali dati. L implementazione del servizio avviene tramite tecnologia WCF il quale permette di esporre un endpoint la cui comunicazione viene gestita tramite Windows Azure Service Bus permettendoci quindi di ospitare il servizio all interno di un qualsiasi computer. Per rendere il servizio interoperabile e consumabile da una vasta varietà di client si utilizza il protocollo REST, che non rende necessario l utilizzo di particolari tecnologie per accedere al servizio. In questo modo diventa consumabile da qualsiasi feed reader e anche da semplice browser. In figura Figura 5.1 è riportato uno schema riassuntivo della soluzione. 5.1 Vantaggi di Windows Azure AppFabric Service Bus La scelta che maggiormente influenza la soluzione proposta è di certo l utilizzo di Windows Azure AppFabric Service Bus per gestire la comunicazione tra i vari componenti. Le possibili soluzioni al problema sono molteplici, ad esempio l utilizzo di una VPN per il collegamento con i client. Soluzioni alternative come questa presentano svantaggi che Windows Azure AppFabric Service Bus permette di superare. L utilizzo di una VPN porta con sè alcuni importanti problemi. Il primo è sicuramente la necessità di andare ad effettuare installazioni di componenti esterni per 47

48 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE Figura 5.1: Schema riassuntivo soluzione. istanziare la VPN, sia all interno del dispositivo ospitante il servizio, sia all interno del dispositivo consumatore del servizio. Inoltre, a seguito dell installazione, sarà necessario eseguire delle configurazioni, anche a basso livello. Questo crea anche un ulteriore limitazione di utilizzo, tutti i software dovranno collegarsi attraverso la VPN creata (a meno di non avere più schede di rete). Tutti questi problemi con Windows Azure AppFabric Service Bus non si presentano, infatti non è necessario installare software diversi dal client che si vuole utilizzare per consumare il servizio, non è necessario eseguire alcuna configurazione, e quindi non va in alcun modo a modificare le impostazioni di connessione, non andando ad interferire con altre applicazioni che utilizzano la rete. Viene anche assicurata la sicurezza che offrono le VPN grazie anche a Windows Azure Access Control. Con Windows Azure AppFabric Service Bus è inoltre possibile anche evitare problemi riguardanti la configurazione della rete stessa, infatti non si necessita nè di modificare in alcun modo le impostazioni di eventuali dispositivi NAT nè di aggiungere eccezioni a firewall. Inoltre utilizzando Service Bus non dovremmo preoccuparci della posizione geografica del dispositivo che ospita il nostro servizio, in quanto Windows Azure AppFabric Service Bus crea in automatico un indirizzo che è completamente indipendente dal dispositivo che esegue l host del servizio e dalla sua posizione geografica. La scelta di creare un servizio RESTFul è data dal fatto di voler rendere l interazione con il servizio possibile alla quasi totalità dei client. L utilizzo del paradigma REST permette anche a client poco complessi di accedere al servizio, senza che ci sia necessità di utilizzare una particolare tecnologia. La possibilità, fornita dall architettura REST, di accedere al servizio tramite semplici URI permette di consumare il servizio anche tramite il solo browser. Vista la necessità, sorta in fase di analisi, di creare un servizio che potesse essere consumato da tre client diversi si è ritenuto opportuno creare un servizio fortemente interoperabile, e utilizzabile non solo dai client espressamente richiesti, ma anche da qualsiasi altra applicazione capace di interfacciarsi tramite il semplice protocollo HTTP. Tale scelta ha inoltre portato a creare client meno complessi e quindi più facili da sviluppare e mantenere. La scelta di usare Windows Azure AppFabric Service Bus è stata fatta per ottenere di 87

49 Luca Pasa5.1. VANTAGGI DI WINDOWS AZURE APPFABRIC SERVICE BUS benefici anche dal punto di vista economico. Uno dei maggiori vantaggi che vengono offerti è la possibilità di pagare in base a ciò che viene usato eliminando cosi la necessità di operare politiche di provisioning. Oltre quindi ad evitare i rischi di sovradimensionare, o ancora peggio di sottodimensionare le previsioni del numero di connessioni necessarie è anche possibile evitare costi iniziali, dovuti ad esempio all affitto o all acquisto di uno o più server Minimizzare il TCO Il TCO, ossia i costi totali legati al possesso dell applicazione, sono uno dei fattori più importanti al momento della commercializzazione di una soluzione software. L utilizzo di Windows Azure AppFabric Service Bus permette di minimizzare questi costi rendendo più attraente anche a livello commerciale la soluzione software. È inoltre da notare che l utilizzo di una piattaforma di cloud ed in particolare di Service Bus porta vantaggi in questo senso anche allo sviluppatore della soluzione. Il TCO è influenzato da vari fattori tra cui, ad esempio, i costi legati all acquisto dei componenti hardware o software e i costi operativi, legati all aggiornamento e alla manutenzione e all esercizio del software e del hardware. Per i client che andranno ad utilizzare il servizio esposto in questo senso i vantaggi offerti da Windows Azure AppFabric Service Bus sono notevoli. Service Bus permette di potersi interfacciare con il servizio senza bisogno di eseguire alcuna attività di tipo sistemistico o acquisto di software. L utilizzo di un servizio esposto con Service Bus non richiede infatti nessuna modifica a eventuali dispositivi NAT, Firewall o proxy. Modifiche ed interventi che hanno un costo, richiedono infatti l intervento di personale informatico. Inoltre è da considerare la sicurezza offerta da service bus, infatti l apertura di una porta su firewall può portare a rischi di intrusione e quindi di perdita o manomissione dei dati. Stesso concetto vale per l utilizzo di UPnP. Per salvaguardare la sicurezza si può pensare di utilizzare una connessione VPN, ma in questo caso oltre a costi di configurazione legati alla necessità di intervento da parte di personale informatico, vanno ad aggiungersi i costi legati all acquisto e all installazione di un software che permetta di implementare questa infrastruttura. Inoltre ne risentirebbe la flessibilità dell utilizzo dei dispositivi, che sarebbero legati all utilizzo della singola applicazione andando a bloccare la possibilità di altre connessioni alla rete. L utilizzo di Service Bus permette inoltre di non dover installare alcun software aggiuntivo e di non richiedere alcuna configurazione. Nel caso specifico l utilizzo di un servizio RESTFul va anche ad eliminare richieste di utilizzo di client che abbiano la possibilità di utilizzare particolari protocolli. È importante poi notare che l esposizione o l utilizzo del servizio qui studiato non ha alcuna ripercussione sulla rete utilizzata. La mancanza di hardware dedicato porta inoltre ad abbattere i costi di manutenzione e aggiornamento dello stesso. La mancanza della necessità di eseguire la configurazione del software durante il ciclo di vita dell applicazione, i risparmi legati alla mancanza di necessita di acquisto e configurazione di hardware, e la possibilità di non eseguire alcun operazione sistemistica ai fini di utilizzare l applicazione, hanno reso possibile la minimizzazione del TCO utilizzando Windows Azure AppFabric Service Bus Internet Of Thing Grazie a Windows Azure AppFabric Service Bus è inoltre possibile avvicinarsi ad un nuovo paradigma: Internet Of Thing. Internet Of Thing (o internet delle cose) si riferisce all estensione di internet al di 87

50 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE mondo degli oggetti e dei luoghi concreti. Secondo questo paradigma gli oggetti si rendono riconoscibili e acquistano intelligenza grazie al fatto di essere connessi alla rete e di poter comunicare dati su se stessi. Se ogni oggetto nel futuro avrà un accesso alla rete di certo ci sarà il problema dell esaurimento degli indirizzi IP. La particolare gestione degli indirizzi fatta da Service Bus è una soluzione a questo problema. Inoltre le possibilità offerte da Service Bus, che rendono possibile non operare interventi sistemistici, per l esposizione di dati o di servizi sono un importante incentivo alla realizzazione di questo paradigma. Sì immagini infatti la complessità che porterebbe la configurazione della comunicazione su dispositivi NAT, firewal e proxy per ogni singolo oggetto presente in un abitazione. Tramite Service Bus tale complessità viene eliminata. Avvicinandosi a questo paradigma si è deciso di far sì che sia il servizio stesso ad interfacciarsi con la webcam per l acquisizione dei dati, e non un applicazione staccata che utilizza il servizio al solo fine di esporli. In questo modo si è creato un sistema in cui il servizio stesso, unificato con la webcam, ha la capacità di esporre, e quindi potenzialmente comunicare, informazioni senza bisogno di intermediari di 87

51 Luca Pasa 5.2. IL SERVIZIO: IMAGEFABRIC 5.2 Il servizio: ImageFabric ImageFabric è il servizio che si occupa di ottenere ed esporre le informazioni che poi verrano consumate dai client. Esso ha quindi alcuni compiti fondamentali: interfacciarsi con la webcam al fine di recuperare le immagini; mantenere in memoria le informazioni ottenute e mantenerle aggiornate; configurazione e attivazione del servizio, e visualizzazione anteprima immagini; implementare un servizio che esponga funzionalità per ottenere il feed ed le immagini; gestione log di sistema. Per assolvere a queste necessità si sono create apposite classi. Vengono ora considerate le scelte fatte per singole funzionalità. La Figura 5.2 Mostra lo schema delle classi dell applicazione ImageFabric di 87

52 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE ServiceContract Singleton e Facade +_imistance : imagemanagement -_feedmgm : ImageFeed -_imagemgm : imagecontainer -_currentnelements : Integer -_maxelements : Integer -servicenamespace : String = "webcamprototype" imagemanagement -uribasefeed : Uri +maxelements() : Integer +feedmgm() : ImageFeed +imagemgm() : imagecontainer +currentnelements() : Integer +getistance() : imagemanagement +BaseFeedUrl() : Uri -New() -New(in nitem : Integer, in feedname : String, in feeddesc : String, in FeedUri : Uri, in imgtarget : Uri) +addelement(in img : Image) +getfeedrss() : Rss20FeedFormatter +getimagestream(in dt : Date) : Stream ImageFeed -_feed : SyndicationFeed -_generalimguri : Uri +feed() : SyndicationFeed +generalimguri() : Uri +New(in feedname : String, in feeddescription : String, in feeduri : Uri, in imgtargetluri : Uri) +addimg(in img : ImageItem) +deletelast() : Date +getrss() : Rss20FeedFormatter «call» «call» -_imgcache : ObjectCache ServiceImpl +getimg(in ts : String) : Stream +getfeed() : Rss20FeedFormatter ImgCoverter +imagetostream(in img : Image, in iformat : ImageFormat) : Stream +streamtoimage(in stream : Stream) : Image 1 «call» imagecontainer +New() +AddImageItem(in imgi : ImageItem) +getimagebydatetime(in dt : Date) : ImageItem #_RemoveImageFromCache(in arguments : CacheEntryRemovedArguments) -components : IContainer +bsdevices : BindingSource +bscapabilities : BindingSource +cmbinputdevice : ComboBox +Label1 : Label +Label2 : Label +cmbcapabilities : ComboBox +btnconf : Button -clodevices : BindingList -clocaps : BindingList #Dispose(in disposing : Boolean) -InitializeComponent() +CurrentDevice() : VideoDevice -DeviceAtPosition(in position : Integer) : VideoDevice +CurrentCapability() : VideoCapability -CapabilityAtPosition(in position : Integer) : VideoCapability -FrmConf_Load(in sender : Object, in e : EventArgs) +InitConf() -bsdevices_currentchanged(in sender : Object, in e : EventArgs) -btnconf_click(in sender : Object, in e : EventArgs) «call» «call» FrmConf «instance» «call» 1 1 -cograbber : Grabber FrmPreview -components : IContainer +BtnStart : Button +PibMain : PictureBox +tmrimage : Timer +BtnStop : Button +btnconf : Button -ClearInterval : TimeSpan = New TimeSpan(0, 4, 0) -ibb : ImageFactory -conf : FrmConf «call» -LastClear : Date = DateTime.Now #Dispose(in disposing : Boolean) -InitializeComponent() -FrmPreview_Load(in sender : Object, in e : EventArgs) -Timer1_Tick(in sender : Object, in e : EventArgs) -BtnStart_Click(in sender : Object, in e : EventArgs) -BtnStop_Click(in sender : Object, in e : EventArgs) -btnconf_click(in sender : Object, in e : EventArgs) ImageFactory +New(in CurrentDevice : VideoDevice, in CurrentCapability : VideoCapability) +getimage() : Image «call» Facade 1 DirectShow::Grabber «call» -_img : Image -_dtime : Date -_description : String ImageItem -_imgformat : ImageFormat +img() : Image +dtime() : Date +description() : String +imgformat() : ImageFormat +imgstream() : Stream +New(in image : Image, in iformat : ImageFormat, in dt : Date, in desc : String) «call» «call» Log -_log : Logger -_instance : Log +getinstance() : Log -New() +insertexceptionlog(in message : String) +insertwarninglog(in message : String) Singleton 1 1 Logging::Logger Figura 5.2: Schema delle classi di ImageFabric di 87

53 Luca Pasa 5.2. IL SERVIZIO: IMAGEFABRIC Salvataggio e Gestione dati I dati, che vengono acquisiti ad intervalli di tempo regolari, devono essere salvati e mantenuti aggiornati. I dati devono poi essere pronti per essere inviati ai client. Si è quindi deciso di mantenere due strutture dati differenti: una per mantenere le immagini, e una per mantenere il feed. La gestione di queste due strutture è stata poi unificata e semplificata da un componente di gestione che va a nasconderne tale complessità. Scendendo nello specifico le classi che concorrono a gestire tale informazioni sono cinque. La prima esigenza che si è trovati a dover risolvere per la gestione del servizio è stata la necessità di creare un componente che permettesse di incapsulare i dati acquisiti. A questo scopo è stata creata la classe ImageItem la quale contiene l immagine acquisita, la data e l ora in cui è stata scattata, una descrizione ed il formato in cui è codificata. Grazie a questa classe è stato possibile gestire collezioni di dati in maniera molto comoda. La gestione del feed avviene attraverso la classe ImageFeed. Per mantenere in memoria il feed ci si è affidati agli oggetti offerti dal namespace System.ServiceModel.Syndication. Il principale oggetto utilizzato è SyndicationFeed il quale permette di creare e gestire un feed. Nella classe viene inoltre mantenuto in memoria l URI generale delle immagini che il servizio va ad esporre. In questo modo è possibile creare un riferimento all immagine limitandosi a conoscere la data e l ora in cui sono state scattate (questo perché il servizio espone le immagini identificandole tramite la data e l ora in cui sono state scattate). La classe mette a disposizione i metodi per aggiungere un elemento al feed o per eliminare l elemento meno recente. Infine la classe permette di ottenere il feed attualmente in memoria in formato RSS 2.0. La classe ImageContainer ha lo scopo di mantenere in memoria le immagini catturate identificandole attraverso la data e l ora in cui sono state scattate. Inoltre, in fase di analisi è emersa la necessità di non occupare eccessivamente la memoria RAM, al fine di non rallentare o compromettere l esecuzione concorrente di altre applicazioni. A ciò si aggiunge la necessità di mantenere disponibili le immagini per tutta la durata dell esecuzione del servizio. I due requisiti vanno uno nella direzione opposta dell altro, infatti mantenere disponibili le immagini richiede l utilizzo di un importante fetta di memoria. Per trovare soluzione a questo problema si è utilizzato il namespace System.Runtime.Caching. Tale namespace mette a disposizione un struttura dati MemoryCache la quale ha la peculiarità di potere eliminare in maniera automatica gli oggetti meno recenti al superamento di un certo limite di memoria preimpostato attraverso file di configurazione. Al momento dell eliminazione viene inoltre sollevato un evento che oltre ad informare dell eliminazione di un oggetto lo restituisce. Tale funzione è stata utilizzata al fine di mantenere in memoria una mole di immagini tale da non creare problemi all esecuzione di altre applicazioni, e di poter comunque mantenere disponibile le immagini cancellate. Per fare ciò, quando l evento di cancellazione viene segnalato verrà eseguito il salvataggio dell immagine nella cartella temporanea del sistema operativo. Tale cartella risiede nella memoria di massa e quindi da la possibilità di mantenere le immagini in memoria senza doverle per forza mantenere in RAM. L oggetto MemoryCache ha anche un ulteriore peculiarità: esso gestisce oggetti che sono contrassegnati da una chiave per facilitarne la ricerca. Nel nostro caso è stato deciso di mantenere le immagini in memoria utilizzando come chiave la data e l ora della loro cattura. Nell eventuale momento dello spostamento in memoria di massa, a seguito della cancellazione dalla cache, è stato deciso di inserire tale dato all interno del nome dell immagine stessa, rendendo ricostruibile il nome del file in cui l immagine viene salvata e quindi facilitando la ricerca della stessa. La di 87

54 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE classe mette a disposizione i metodi per l inserimento e la lettura di immagini. È inoltre presente un metodo privato che si occupa dello spostamento delle immagini, al momento della cancellazione, nella memoria di massa. La creazione delle classi ImageContainer e ImageFeed ha portato a dover operare contemporaneamente su due classi per gestire gli elementi in memoria. Per questo motivo è stato deciso di creare una classe che implementi il design pattern Facade, e che quindi nasconda tale complessità e unifichi la gestione, rendendo trasparente la presenza delle due classi sottostanti. La classe creata è ImageManagement la quale crea due istanze: una della classe ImageContainer, e una della classe ImageFeed. All interno della classe ImageManagement viene definito il numero di elementi massimi che verrano esposti dal feed. Per assicurare la leggibilità del feed si è deciso di esporre al massimo 10 elementi. Sì e voluto assicurare che la gestione della memorizzazione fosse eseguita da un unica istanza di questa classe, a tale scopo si è fatto sì che la classe implementi il design pattern Singleton. Il principale metodo esposto da tale classe è la funzione d aggiunta che va a gestire l inserimento di un oggetto in entrambe le classi. Questa funzione va inoltre a controllare il numero di elementi feed attualmente salvati all interno dell istanza della classe ImageFeed. Nel caso in cui siano già presenti il numero massimo di elementi, il metodo si preoccupa di richiamare il metodo di eliminazione messo a disposizione dalla classe contente il feed e di inserire il nuovo elemento, preoccupandosi quindi di salvaguardare il non superamento della soglia di elementi massimi impostata. Altro importante metodo esposto riguarda la lettura delle immagini. Come detto in precedenza le immagini possono essere presenti sia nella memoria gestita dall istanza della classe ImageContainer, sia nella memoria di massa del nostro computer. Ovviamente questo scenario porta con sè un problema di ricerca dell immagine. Sì è quindi deciso di effettuare da prima una richiesta all istanza della classe ImageContainer, e in caso tale richiesta non portasse a risultati utili andare a cercare l immagine nella memoria di massa. L ordine di tali operazioni è dato dalle diversa velocità in lettura messe a disposizione dalle due tipologie di memoria. Vista la velocità relativamente bassa della memoria di massa si è cercato un metodo che non implicasse un ricerca sequenziale, ma che permettesse di ottenere (se possibile) l immagine facendo un unico accesso. Per fare ciò è stato sufficiente dare all immagine un nome ricostruibile a partire dai dati che vengono passati per ottenere l immagine, ossia la data e l ora in cui è stata catturata. Questo metodo ha un altra peculiarità: non ritorna un oggetto Image (con cui vengono solitamente rappresentate le immagini), ma uno Stream. Questa scelta è legata principalmente al fatto che le immagini devono essere inviate attraverso la rete, e di certo il formato Stream si presta meglio a tale scenario. Per eseguire la conversione da Stream a Image e viceversa è stata creata un apposita classe (ImageConverter), che espone i metodi statici utili ad eseguire la conversione Interfacciamento con dispositivo di acquisizione immagini L interazione con la webcam avviene attraverso un componente sviluppato dall azienda ospitante lo stage. Questo componente va a utilizzare la libreria DirectShow per interfacciarsi con la webcam. Il componente in questione permette per prima cosa di conoscere il dispositivo webcam connesso al computer, fornisce poi informazioni inerenti alle risoluzioni supportate dalla webcam. Tali informazioni sono state utilizzate per popolare alcune combo-box che verranno utilizzate per la configurazione del servizio. Il componente va inoltre a fornire due importanti funzioni: la possibilità di vedere un anteprima di ciò che la webcam sta vedendo e la possibilità di 87

55 Luca Pasa 5.2. IL SERVIZIO: IMAGEFABRIC di catturare dei fotogrammi. La seconda funzione è quella che viene utilizzata dal servizio. L utilizzo e stato incapsulato all interno di un classe: ImageFactory. Questa classe esegue due importanti azioni. La prima viene eseguita all interno del costruttore, ossia viene creato il collegamento con la webcam prescelta impostando la risoluzione delle immagini selezionata. Il costruttore quindi richiede due parametri di input per segnalare queste due scelte, che saranno rispettivamente di tipo BSS.Vortex.DirectShow.VideoDevice e BSS.Vortex.DirectShow.VideoCapability. La seconda azione eseguita e fatta all interno di un metodo che ha il compito di catturare le immagini dalla webcam e restituirle. Il metodo restituisce le immagine tramite oggetti di tipo Image. Questo metodo viene richiamato all interno della gestione di un evento Tick sollevato da un controllo System.Windows.Forms.Timer il quale viene avviato all attivazione del servizio e solleverà l evento citato ogni secondo. All interno della gestione dell evento l immagine viene salvata richiamando la funzione addelement della classe imagemanagement configurazione e attivazione del servizio, e visualizzazione anteprima immagini L attivazione del servizio avviene tramite la pressione del pulsante Start presente nel form che viene visualizzato all avvio dell applicazione (Figura 5.3). Tale form è gestito tramite la classe FrmPreview. Nel form, oltre al pulsante che permette di far partire il servizio è presente anche un bottone per metterlo in pausa e per eseguire la configurazione. È inoltre presente una PictureBox la quale mostra un anteprima dell immagine. All apertura dell applicazione il servizio va subito ad esporre i suoi metodi tramite la creazione di un WebServiceHost. Viene poi messo in attesa che un azione venga intrapresa dall utente tramite la pressione di uno dei tre pulsanti visualizzati. Alla pressione del tasto di avvio dell applicazione viene per prima cosa creata un istanza della classe ImageFactory. Viene poi fatto partire il Timer che dà inizio all acquisizione e al salvataggio delle immagini. Per quanto riguarda invece la configurazione, essa avviene tramite un form secondario (Figura 5.4) gestito dalla classe FrmConf. In tale form viene richiesto di selezionare la webcam da cui acquisire i dati e la risoluzione delle immagini acquisite. Le informazioni tra cui scegliere vengono fornite dal componente per l interazione con la webcam, di cui si è già precedentemente discusso. È possibile in qualunque momento mettere in pausa l acquisizione dei dati tramite il pulsante stop, esso fa in modo che il Timer fermi temporaneamente l acquisizione dei dati. Il servizio può essere riattivato premendo nuovamente il pulsante start di 87

56 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE Figura 5.3: Screen shoot di ImageFabric in funzione. Figura 5.4: Screen shoot della finestre di configurazione di ImageFabric di 87

57 Luca Pasa 5.2. IL SERVIZIO: IMAGEFABRIC Esposizione servizio Per l esposizione del servizio si è scelto di utilizzare WPF che ci assicura un ottima interoperabilità e un ottima integrazione con Winows Azure AppFabric ServiceBus. Sì è inoltre deciso di implementare un servizio RESTful questo per ottenere un alto grado di interoperabilità e per permette anche a client molto semplici, come ad esempio un browser, di poter accedere al servizio. Inoltre è cosi possibile accedere alla risorse esposte utilizzando semplici URI. Dal punto di vista dei client, consumare un servizio RESTFul, è molto più semplice ed economico, in quanto non richiede l utilizzo di particolari tecnologie, ma solo delle operazioni base del protocollo http. La scelta di utilizzare un servizio RESTFul è stata inoltre favorita dalla necessità di esporre un feed RSS. L utilizzo di WCF e REST ha portato ad adottare uno specifico modello di programmazione che richiede la creazione di specifiche classi ed interfacce. Per prima cosa è stata creata l interfaccia del servizio la quale contiene la segnatura dei metodi che il servizio espone. I metodi esposti sono due: un primo metodo che restituisce il feed in formato RSS 2.0, mentre il secondo restituisce uno Stream rappresentante singola immagine. Per rendere possibile l esposizione di tale endpoint con WCF l interfaccia è stata marcata con l attributo <ServiceContract()>, in questo modo si va a definire quella classe come il contratto del servizio. Mentre i metodi sono stati marcati con l attributo <OperationContract()> andando così a segnalare quale operazioni devono essere esposte. L utilizzo del paradigma REST ha inoltre portato alla necessità di collegare delle URI ad ogni operazione, per fare ciò si sono usati gli attributi <WebGet()>. Nel caso del metodo per la restituzione di un immagine è stata inoltre parametrizzata l URI, in modo che l ultimo elemento della stessa risulti essere la data e l ora dell immagine che si vuole ottenere. L implementazione dell interfaccia avviene tramite la classe ServiceImpl che va quindi ad implementare i due metodi definiti dell interfaccia: getfeed() e getimg(ts As String). Il primo di questi due metodi va a richiamare la funzione getfeedrss, messa a disposizione dalla classe singleton ImageManagment, grazie alla quale è possibile restituire il feed in formato RSS 2.0. il metodo getimg va invece a codificare il valore passato tramite la URI al fine di avere un formato data e ora valido. Va poi ad utilizzare questo valore come parametro passato al metodo getimagestream messo sempre a disposizione dalla classe singleton ImageManagment. Come spiegato precedentemente è stato scelto di utilizzare Windows Azure Appfabric Service Bus, e per questo è stato necessario accedere al portale di gestione di Windows Azure e creare un nuovo namespace per il servizio. In Figura 5.5 è visualizzato come si presentava il portale di gestione dopo la creazione del namespace. Per rendere possibile l esposizione del servizio è necessario impostare alcuni parametri di connessione ed impostazione all interno del file di configurazione dell applicazione: App.config. In questo file è per prima cosa presenta la scelta di utilizzare il binding webhttprelaybinding. Questo binding permette di creare servizi basati HTTP/REST e rende possibile esporre i servizi senza che i client si interfaccino direttamente con il servizio, grazie al relay service che espone un endpoint HTTP. In questo modo i client per interfacciarsi al servizio basta che sappiano utilizzare il protocollo HTTP. All interno della configurazione del webhttprelaybinding è stato aggiunto un importante opzione riguardante la necessita di autenticarsi da parte dei client. L opzione in questione è relayclientauthenticationtype presente nella gestione della sicurezza. A questa opzione è stato assegnato valore None, in questo modo i client non necessitano di autenticarsi per accedere al servizio. Sì è poi specificato il servizio da esporre e impostato il comportamento, a questo segue la configurazione del endpoint andando ad assegnare il binding precedentemente di 87

58 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE Figura 5.5: namespace. Portale di gestione Windows Azure Service Bus dopo la creazione del configurato. È stato poi configurato il comportamento dell endpoint, andando a specificare le credenziali shared secret necessarie all applicazione per poter esporre l endpoint. Tali credenziali sono state ottenute al momento della creazione e configurazione del namespace. Per completare l esposizione è stato istanziato in fine un oggetto WebServiceHost, il quale verrà creato ed aperto all avvio dell applicazione log Per assicurare una buona gestione delle possibili eccezioni ed errori che possono presentarsi in futuro durante l utilizzo dell applicazione, è stato deciso di creare un file di log nel quale registrate lo stacktrace delle eccezioni che vengono sollevate durante l esecuzione. Per fare ciò ci si è appoggiati alla libreria NSpring la quale offre un meccanismo semplice ed efficace per la gestioni del log, che va ad astrarre la complessità della creazione e gestione manuale di un file. Per garantire un utilizzo unificato delle funzioni di log è stata creata la classe Log, la quale implementa il design pattern singleton. Essa va inoltre a mettere a disposizione dei metodi che automatizzano l inserimento dei messaggi di log all interno del file. assicurando così che tutti i messaggi abbiano un formato comune. Per gestire l inserimento dei log è stato aggiunto all interno dei blocchi Try-catch, presenti in tutti i metodi, una chiamata al metodo di inserimento di un nuovo messaggio di log nel file. Il messaggio darà lo stacktrace dell errore. Sì è deciso di inserire lo stacktrace in quanto si ritiene molto importante al fine di poter risalire alla causa dell eccezione. L eventuale inserimento del solo messaggio generato dall eccezione, o addirittura del solo tipo di eccezione, non avrebbe dato informazioni abbastanza complete e significative coordinamento e gestione dei componenti Nella gestione delle varie funzioni esposte è stato necessario individuare un componente che coordinasse le varie operazione e quindi facesse cooperare in maniera ordinata i vari componenti. Il componente individuato ad eseguire tale scopo è la classe FrmPreview. La scelta è stata principalmente fatta sulla base della necessità di rispettare le scelte dell utente nell attivazione, configurazione e messa in pausa del servizio. L interazione viene gestita dalla classe FrmPreview. Inoltre, la volontà di di 87

59 Luca Pasa 5.2. IL SERVIZIO: IMAGEFABRIC mantenere fortemente separati la gestione dei dati, la gestione dell interazione con la webcam e l implementazione del servizio, hanno richiesto l utilizzo di un aggregatore di funzioni. È infatti la classe FrmPreview a coordinare le richieste ai vari comparti dell applicazione tramite l utilizzo di un Timer, il quale va a sollevare un evento all interno del quale avvengono le chiamate alle funzioni che permettono di eseguire l acquisizione e la memorizzazione dei dati di 87

60 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE 5.3 Il Client Desktop: ImageConsumer L applicazione client desktop permette di accedere e consumare il servizio. Per fare ciò l applicazione deve ottenere il feed nel quale sono collezionati i link alla varie immagini. Ognuno di questi link va a rappresentare la richiesta al servizio di una singola immagine. La scelta riguardante quali immagini andare effettivamente ad ottenere tra quelle esposte è fatta in base ai limiti imposti dalla velocità di connessione e dalla disponibilità di memoria. Questa applicazione vuole dare all utente la possibilità di visualizzare le immagini ottenute dal servizio e di navigare fra esse, vengono infatti mantenute in memoria le cento immagini più recenti ottenute dal servizio tra le quali l utente può scegliere quale visualizzare. Oppure è possibile attivare la modalità che permette di visualizzare sempre l ultima immagine ottenuta. Uno degli aspetti che si è voluto curare nella realizzazione del servizio assicurare che l interfaccia grafica non subisca rallentamenti durante il download di un immagine. Per questo ci si è preoccupati di andare ad utilizzare meccanismi per la gestione dell esecuzione parallela. Nella creazione di tale applicazione client sono state individuate alcune funzioni fondamentali che hanno portato alla necessità di creare determinati componenti e di effettuare determinate scelte architetturali: ricezione dati; gestione interazione con il servizio; gestione dei dati ricevuti; visualizzazione dei dati; gestione log di sistema. L applicazione client in questione è stata realizzata utilizzando il linguaggio Visual Basic.NET. È inoltre interessante notare che grazie all utilizzo di un servizio REST non è strettamente necessario utilizzare WCF per comunicare con esso. La gestione di tali funzionalità è eseguita tramite alcuni componenti che interagiscono tra loro tramite un preciso schema. I componenti in gioco sono i seguenti: Receiver: gestisce le richieste al servizio; ServiceManager: decide come e quando eseguire le richieste al servizio; DataManager: gestisce la memorizzazione dei dati; Interfaccia utente: mostra le immagini e gestisce l iterazione con l utente; Gestore di log: fornisce metodi per l inserimento di messaggi nel log dell applicazione. In Figura 5.6 viene riportato il diagramma delle classi dell applicazione ImageConsumer di 87

61 Luca Pasa 5.3. IL CLIENT DESKTOP: IMAGECONSUMER +receivenewimagedatalist(in imgafter : Date) : List -InverseDateOrder(in x : Date, in y : Date) : Integer +GetImagebyDate(in dtime : Date) : Image Receiver -BASE_SERVICE_URL : String = " «call» ImgCoverter Singleton «call» +imagetostream(in img : Image, in iformat : ImageFormat) : Stream +streamtoimage(in stream : Stream) : Image «call» «call» ServiceManager -_lastupdate : Date = DateTime.MinValue -_Timer : Timer -_servicemanager : ServiceManager +getinstance() : ServiceManager -New() -UpdateImageList() -getimgasync(in imgdate : Date, in NTime : Integer = 0) +StartUpdateImgs() -OnTimedEvent(in source : Object, in e : ElapsedEventArgs) «call» «call» 1 Log -log : Logger -instance : Log +getinstance() : Log -New() +insertexceptionlog(in message : String) +insertwarninglog(in message : String) Singleton «call» Logging::Logger «call» 1 ImageItem «call» Singleton * -_img : Image -_dtime : Date +img() : Image +dtime() : Date +New(in image : Image, in dt : Date) +CompareTo(in obj : Object) : Integer DataManager -_istance : DataManager -_imglist : List -_NumberOfItem : Integer = 100 -New() +getistance() : DataManager +getlist() : List -ImgItemInverseComparison(in x : ImageItem, in y : ImageItem) : Integer +add(in dt : Date, in img : Image) +ItemInserted(in sender : Object, in e : EventArgs) : EventHandler +OnAdd(in e : EventArgs) ComponentModel::Component L'evento che segnala l'inserimento di un oggetto sollevato da DataManager, viene catturato da FrmClient al fine di gestire in maniera efficente la visualizzazione dei dati. «call» IComparable FrmClient -components : IContainer +PibMain : PictureBox +sldimgnav : TrackBar +LblImgDate : Label +CkbUpdate : CheckBox -ImgItemList : List -lastupdate : Date -currentelement : ImageItem #Dispose(in disposing : Boolean) -InitializeComponent() -FrmClient_Disposed(in sender : Object, in e : EventArgs) -FrmClient_Load(in sender : Object, in e : EventArgs) +HandleNewItem(in sender : Object, in e : EventArgs) -sldimgnav_scroll(in sender : Object, in e : EventArgs) -changeimage(in img : Image, in dt : Date) Figura 5.6: Schema delle classi di ImageConsumer di 87

62 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE L interazione tra i componenti segue una precisa logica: il ServiceManager attende una richiesta da parte dell interfaccia utente per cominciare l interazione con il servizio, che avviene tramite l utilizzo dei metodi messi a disposizione dal Receiver. Al momento dell arrivo dei dati Servicemanager va ad immagazzinarli in memoria tramite l utilizzo del DataManager, il quale si preoccuperà di segnalare all interfaccia utente la presenza di un nuovo dato da visualizzare. In Figura 5.7 viene riportato lo schema che mostra come interagiscono tra loro questi componenti. ImageConsumer ImageFabric Receiver ServiceManager Interfaccia utente DataManager Evento D inserimento Nuovo dato Figura 5.7: Schema interazione tra componenti di ImageConsumer ricezione dati La ricezione dei dati esposti dal servizio richiede due principali operazioni: la ricezione del feed RSS e la ricezione delle singole immagini esposte. Queste funzioni sono implementate all interno della classe Receiver. Per quanto riguarda la prima operazione si va a accedere alla URI a cui è esposto il feed e si va leggere il codice XML che lo rappresenta. Tale codice viene codificato tramite l oggetto XmlReader, ed il risultato utilizzato per creare un oggetto SyndicationFeed. L utilizzo di un oggetto SyndicationFeed ci permette un facile e veloce accesso ai dati evitando così di eseguire un parsing manuale del XML. Per questo metodo si è inoltre ritenuto necessario dare la possibilità all utilizzatore di filtrare i dati che si vogliono ottenere. Il filtraggio avviene per data, dando la possibilità di ottenere informazioni strettamente successive ad una data e ora passate come parametro del metodo che permette la ricezione stessa. Un altra peculiarità di questo metodo è data dal fatto che il valore restituito è un lista di oggetti DateTime che rappresentano la data e l ora di acquisizione delle nuove immagini esposte dal servizio. Questo è possibile grazie al fatto che si è deciso di utilizzare la data e l ora di acquisizione come identificativi per le immagini. Questa scelta si ripercuote inoltre sul secondo metodo che esegue la ricezione, infatti esso richiede come parametro di input la data e l ora di acquisizione dell immagine che si di 87

63 Luca Pasa 5.3. IL CLIENT DESKTOP: IMAGECONSUMER desidera ottenere. Questo parametro viene utilizzato per andare a creare l URI che permette di effettuare la richiesta al servizio, l URI ha la seguente forma: e ora dell immagine richiesta] Creata tale URI possiamo eseguire un HttpWebRequest per ottenere i dati richiesti che ci saranno inviati come Stream, per farlo è però prima necessario impostare il metodo per la richiesta a Get. Appena ci arriverà la HttpWebResponse possiamo andare a convertire lo Stream nell immagine, e per farlo si utilizza le funzionalità messe a disposizione dalla classe ImageConverter. Questa classe fornisce due metodi statici che provvedono alla conversione da Stream a immagine e viceversa. In questi metodi possiamo notare come non ci sia traccia dell utilizzo di WCF, questo è stato possibile grazie all utilizzo di un servizio RESTFul, rendendo quindi possibile la creazione di client anche non utilizzando tecnologia microsoft. Inoltre ricordiamo che il servizio è esposto tramite l utilizzo di Windows Azure AppFabric Service Bus, ma come si può vedere nei metodi che si interfacciano con il servizio, non è presente alcuna riga di codice che dipenda dall utilizzo di questa tecnologia. Questo dimostra la trasparenza di questo servizio offerto dalla piattaforma Windows Azure del quale però si possono apprezzare i benefici: non è infatti stato necessario eseguire alcuna modifica ad impostazione di firewall o NAT per eseguire la connessione al nostro servizio ImageFabric gestione interazione con il servizio La gestione dell interazione con il servizio è affidata alla classe ServiceManager. In questa classe è definito quando e come eseguire le richieste al servizio e come gestire i dati ricevuti. Per assicurare che la gestione del servizio avvenga attraverso un unica istanza di questa classe è stato deciso di far in modo che implementi il design pattern Singleton. La classe prevede che essa venga avviata da un richiesta di attivazione dell interazione con il servizio e poi possa gestire autonomamente tale interazione andando a salvare i dati tramite il DataManager. Alla ricezione di tale richiesta, che avviene tramite il metodo StartUpdateImgs, viene creato un Timer il quale ogni cinque secondi solleva l evento Elapsed che è gestito dal metodo OnTimedEvent. In questo metodo vengono eseguite due operazioni: l aggiornamento dei dati e viene calcolato fra quanto tempo verrà eseguito il prossimo aggiornamento. Viene infatti tenuto conto del tempo richiesto per la ricezione dei dati, tempo che viene detratto dall intervallo dei cinque secondi, in modo da avere la massima regolarità nelle richieste ed avere piene indipendenza da eventuali problemi di velocità nella rete. Nel poco probabile caso che l invio dell immagine richieda più di cinque secondi ci si limiterà ad eseguire l aggiornamento cinque secondi dopo, andando così a saltare uno o più aggiornamenti previsti, al fine di non accodare inutilmente richieste, che nel lungo periodo potrebbero causare un blocco del sistema. Per quanto riguarda l aggiornamento dei dati viene utilizzato il metodo UpdateImageList. All interno di questo metodo si richiede per prima cosa al servizio (tramite il Receiver) la lista degli ultimi elementi esposti più aggiornati rispetto a quelli di cui si è già in possesso. Ricevuti tali dati si estrae la data e ora più recente, e si esegue la richiesta al servizio di tale immagine. La richiesta di un immagine può avere un peso importante, e quindi anche un costo a livello computazionale rilevante ai fini dell esecuzione, inoltre esiste la possibilità di voler eseguire la richiesta di due o più immagini, andando così a rendere molto costosa tale operazione. È per questo stato deciso di implementare questa operazione in maniera asincrona andando ad applicare di 87

64 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE il concetto del parallel computing. Per farlo è stato deciso di utilizzare la libreria Task Parallel la quale, oltre a rendere possibile l esecuzione di un applicazione in multi-threading, permette l ottimizzazione dell esecuzione di task anche su processori multicore. L applicazione di tale scelta all esecuzione della richiesta di immagini al servizio ha portato a dover affrontare alcune problematiche. Una di queste è stata la gestione di problemi di connessione o di temporanea impossibilità di ottenere i dati. In questo caso sì è deciso di tentare per tre volte, e in caso di fallimento di tutti e tre i tentativi, di gestire l errore. Il codice di richiesta è stato incapsulato all interno della funzione getimgasync nella quale oltre ad eseguire il tentativo di ottenere l immagine dal servizio va anche, in caso di successo, ad inserirla in memoria. Per farlo si va ad utilizzare le funzioni messe a disposizione dal DataManager gestione dei dati ricevuti La gestione dei dati viene eseguita tramite la classe DataManager. Questa classe si occupa del salvataggio in memoria dei dati, dell inserimento e della lettura degli stessi. Viene inoltre qui definito il numero massimo di dati mantenuti contemporaneamente. Si è deciso di mantenere in memoria non più di cento elementi, onde evitare sovraccarico di memoria. Gli elementi vengono mantenuti in una struttura dati di tipo ListOf(T). per incapsulare i vari elementi si è creata la classe ImageItem La quale mantiene in memoria le sole informazioni utili: l immagine e la data e l ora in cui l immagine è stata catturata. Questa classe va inoltre ad implementare l interfaccia IComparable che permette di eseguire confronti tra oggetti da essa definiti. Essendo che i confronti in questo caso vengono utilizzati per ordinare temporalmente i vari elementi, si è deciso di basare l implementazione di tale interfaccia sulla data e l ora salvate in modo da permettere un facile ordinamento temporale degli elementi ricevuti dal servizio. La classe DataManager comunica con altre 2 classi: con il ServiceManager che richiama i metodi per eseguire l inserimento degli elementi, e con l interfaccia utente (FrmClient) tramite un evento che segnala la disponibilità di nuovi dati. Nel primo caso il metodo che viene esposto allo scopo di inserire nuovi elementi è il metodo add. Questo metodo richiede come parametri d ingresso l immagine, la data e l ora in cui è stata catturata. Con questi dati va a creare un oggetto di tipo ImageItem ed inserirlo nella lista. Viene inoltre controllato che non venga superato il numero massimo di elementi che si è deciso di mantenere in memoria, nel caso ci si trovasse in questa situazione il metodo sì occuperebbe di eliminare l elemento meno recente presente nella lista. Alla fine di queste operazioni viene sollevato l evento ItemInserted per segnalare all interfaccia utente la presenza di nuovi dati da visualizzare. Tale evento viene definito all interno della classe, insieme al delegate che permette alla classe ricevente di gestirlo. L interfaccia grafica necessita anche di conoscere gli oggetti presenti in memoria, per questo è stata creata la funzione getlist che ritorna una copia ordinata per data (dalla più recente alla meno recente) della lista di elementi attualmente mantenuti in memoria. La scelta di eseguire l ordinamento al momento della restituzione dalla lista è data dal fatto di voler minimizzare il numero di operazioni di questo genere. Si ritiene infatti che il numero di inserimenti sia maggiore del numero di letture, anche in proiezione di sviluppi futuri dell applicazione che magari prevedano l interazione con più servizi. Visto l utilizzo di multithreading e parallel computing da parte del ServiceManager, si è ritenuto opportuno proteggere le operazioni eseguite sui dati all interno di questa classe tramite blocchi SyncLock. Il SyncLock garantisce che il blocco di istruzioni non venga eseguito da più thread contemporaneamente di 87

65 Luca Pasa 5.3. IL CLIENT DESKTOP: IMAGECONSUMER SyncLock impedisce infatti a ciascun thread di accedere al blocco durante l esecuzione di quest ultimo da parte di altri thread. SyncLock viene in genere utilizzato per evitare che i dati vengano aggiornati da più thread contemporaneamente. Se le istruzioni che modificano i dati devono essere completate senza interruzioni, è opportuno inserirle in un blocco SyncLock. Il SynckLock basa il suo funzionamento su un riferimento ad un oggetto detto lockobject del quale i vari thread vanno a prendere l accesso esclusivo, in questo caso tale oggetto è la lista di oggetti ImageItem ossia la struttura dati su cui vengono effettuate le operazioni. Si è voluto infine assicurare che la gestione e la memorizzazione dei dati avvenga sempre tramite la stessa istanza di questa classe, a questo scopo si è fatto im modo che DataManager implementi il design pattern Singleton visualizzazione dei dati La classe che gestisce la visualizzazione dei dati e gestisce le operazioni dell utente è FrmClient. Questa classe assolve il compito di visualizzare i dati all utente e gli permette una navigazione tra essi. Grazie a questa classe l utente può inoltre decidere quale modalità di visualizzazione usare: o la visualizzazione che permette di navigare tra le varie immagini, oppure la modalità che va a visualizzare sempre l immagine più recente. Il layout grafico è composto da una PictureBox nella quale viene visualizzata l immagine scelta, una label dove vengono visualizzate le informazioni legate all immagine, una Combobox che permette di selezionare quale modalità utilizzare e uno slider per navigare all interno della collezione d immagini. Il layout grafico e mostrato in Figura 5.8 Figura 5.8: Screen shoot di ImageConsumer in funzione. All attivazione dell applicazione viene subito richiamata la funzione StartUpdateImgs del ServiceManager che fa iniziare le richieste verso il servizio. Sempre al momen di 87

66 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE to dell inizializzazione viene configurato il metodo che va a raccogliere l evento ItemInserted sollevato dal DataManager. Quando viene inserito un nuovo elemento nel DataManager viene sollevato l evento ItemInserted, tale evento viene gestito dal metodo HandleNewItem nel quale trova spazio la gestione delle due modalità di visualizzazione. La gestione di un evento avviene attraverso un thread diverso dal thread grafico, che è l unico a poter eseguire modifiche all interfaccia grafica. Per questo sono state implementate politiche di marshalling in modo da riportare l esecuzione al thread grafico prima di eseguire modifiche all interfaccia. Infatti i controlli in Windows Form sono associati a un thread specifico e non sono thread-safe. Pertanto, se si chiama il metodo di un controllo da un thread diverso, è necessario utilizzare uno dei metodi Invoke del controllo per effettuare il marshalling della chiamata al thread adeguato. Per capire se è necessario o meno utilizzare uno dei metodi invoke si può utilizzare la proprietà Control.InvokeRequired che restituisce un booleano. Nel caso specifico viene valutata la proprietà Control.InvokeRequired relativa al form stesso, e in caso restituisca true viene utilizzato il comando Invoke, il quale permette di eseguire un delegato nel thread proprietario dell handle del form. Eseguito il marshalling è ora possibile andare ad eseguire le operazioni che porteranno all aggiornamento dell interfaccia grafica. Per prima cosa viene invocato il DataManager richiedendo una copia della lista degli elementi attualmente mantenuti in memoria. Ora è necessario differenziare la gestione delle due modalità di visualizzazione dei dati: modalità di visualizzazione dell elemento più recente: in questa modalità il cursore dello Slider punta sempre all elemento più recente, ed inoltre l elemento viene visualizzato nella Picture Box. Per questo motivo la prima operazione che viene fatta è il controllo se l immagine più recente presente nella nuova lista è più recente di quella attualmente visualizzata. In caso positivo si va ad aggiornare i dati visualizzati, altrimenti ci si limita ad aggiornare la lista di visualizzazione ed i limiti dimensionali dello Slider nel caso in cui gli elementi inseriti siano di più di quelli precedentemente visualizzati; navigazione tra gli elementi attualmente in memoria: in questa modalità al momento dell inserimento di nuovi elementi il cursore rimane sull elemento attualmente visualizzato. È quindi importante, in questa modalità, andare a ricalcolare la posizione del cursore dello Slider dopo l aggiornamento. Per farlo sì è utilizzata la funzione di ricerca all interno della lista la quale dato un elemento ne restituisce l indice. È però stato controllato il caso particolare in cui l elemento non è più presente nella lista perché eliminato in quanto troppo poco recente. In questo caso si è deciso di visualizzare l elemento temporalmente più vicino a quello precedentemente puntato, ossia il meno recente attualmente presente nella lista. Anche in questo caso vengono aggiornati i limiti dello Slider nel caso in cui il numero di elementi nell attuale lista risulti maggiore di quelli contenuti nella precedente. In questa classe è inoltre presente la gestione della navigazione dell utente all interno della lista dei dati. L utente effettua tale operazione utilizzando lo Slider, ad ogni movimento del cursore dello Slider cambierà la visualizzazione dei dati andando a modificare il contenuto della Picture box e della label che mostra le informazioni relative all immagine. Il cambiamento di questi due controlli Windows Form avviene sempre in contemporanea, ed i dati mostrati possono essere incapsulati in un oggetto di tipo ImageItem. Sì è per questo deciso di incapsulare tali operazioni di modifica, che vanno a variare l interfaccia grafica, in un metodo chiamato changeimage che di 87

67 Luca Pasa 5.3. IL CLIENT DESKTOP: IMAGECONSUMER richiede come parametri di input il valore dei dati da mostrare. In questo modo si è certi di poter mantenere coerenza tra l immagine mostrata nella Picture box e i relativi dati mostrati nella Label Gestione log di sistema Il sistema utilizzato per implementare la gestione del log è lo stesso utilizzato per l applicazione ImageFabric di 87

68 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE 5.4 Il Client Windows Phone 7: ImageWP7 Questa applicazione implementa un applicazione per smartphone dotati di sistema operativo Windows Phone 7, capace di consumare il servizio esposto dall applicazione ImageFabric. Questa applicazione deve quindi rendere possibile la connessione al servizio, la lettura e la codifica del feed RSS e la richiesta di singole immagini al servizio. Tutto questo avviene attraverso l interfacciamento con un servizio RESTFul. L applicazione quindi riceve i dati dal servizio, e li visualizza. Anch essa, come l applicazione client per desktop, rende disponibili due modalità di visualizzazione dei dati: una prima modalità dove l utente può navigare tra i dati attraverso uno slider, visualizzando l immagine selezionata, e una modalità in cui l applicazione visualizza sempre l immagine più recente. Sì è voluto inoltre assicurare una buona gestione del Tombstoning e della riattivazione dell applicazione, anche se si deve considerare che l applicazione è composta da un sola pagina e che la connessione al servizio va rinnovata ad ogni riattivazione dell applicazione. Le principali funzione che l applicazione che deve eseguire sono: connessione al servizio ricezione del feed; gestione delle informazioni ricavate dal feed e download delle immagini relative; salvataggio dei dati ricevuti; visualizzazione dei dati; gestione della disattivazione dell applicazione (Tombstoning). Per arrivare ad eseguire queste operazioni sono state create apposite classi, e vista la necessità di utilizzare operazioni asincrone per l utilizzo di connessioni al servizio, si è fatto un uso molto ampio della gestione degli eventi, anche per la comunicazione tra le varie classi e componenti. I componenti utilizzate per raggiungere gli scopi prefissati sono: Receiver: si occupa di andare ad ottenere e codificare i dati relativi al feed dal servizio esposto da ImageFabric; ServiceManager: seleziona ed ottiene le immagini a partire dai dati ottenuti dal feed; DataManager: gestisce il salvataggio in memoria dei dati incapsulandoli in oggetti di tipo ImageItem; GuiUpdate: crea un indirezione tra il codice e l interfaccia grafica permettendo di ben gestire anche le politiche di gestione del Tombstoning; MainPage: gestisce l interazione con l utente e coordina gli altri componenti dell applicazione; Interfaccia Utente: Scritta in linguaggio XAML è stata realizzata secondo le direttive e le best practises consigliate per lo sviluppo di applicazioni Windows phone 7. Viene qui implementata l interfaccia grafica della pagina tramite la quale l applicazione dialoga con l utente. In Figura 5.9 viene riportato il diagramma delle classi dell applicazione ImageWP di 87

69 Luca Pasa 5.4. IL CLIENT WINDOWS PHONE 7: IMAGEWP7 INotifyPropertyChanged GuiUpdate -_txbimgdatetext : String -_sldimagevalue : Double -_cbxautoupdateischecked : Boolean +txbimgdatetext() : String +sldimagevalue() : Double +cbxautoupdateischecked() : Boolean +PropertyChanged(in sender : Object, in e : PropertyChangedEventArgs) : PropertyChangedEventHandler -NotifyPropertyChanged(in propertyname : String) 1 1 DataManager -_istance : DataManager -_imglist : List -_NumberOfItem : Integer = 10 -New() +getistance() : DataManager +getlist() : List -ImgItemInverseComparison(in x : ImageItem, in y : ImageItem) : Integer +add(in dt : Date, in img : Stream) +ItemInserted(in sender : Object, in e : EventArgs) : EventHandler +OnAdd(in e : EventArgs) Singleton 1 «call» MainPage -lastupdate : Date = DateTime.MinValue -ImgList : List -currentelement : ImageItem -_guiupdate : GuiUpdate -_isnewpageinstance : Boolean = False -timer : Timer -LastElement : Date +New() #OnNavigatingFrom(in e : NavigatingCancelEventArgs) #OnNavigatedTo(in e : NavigationEventArgs) +TimerTick(in stateinfo : Object) -btnconnect_click(in sender : Object, in e : RoutedEventArgs) +HandleNewItem(in sender : Object, in e : EventArgs) -changeimg(in imgi : ImageItem) -changeimg(in img : WriteableBitmap, in dt : String) -sldimage_valuechanged(in sender : Object, in e : RoutedPropertyChangedEventArgs) +seterrtext(in err : String, in btnenable : Boolean) 1 1 * ImageItem -_dtime : Date -_imgbyte() : Byte +img() : Stream +imgbyte()() : Byte +dtime() : Date +New(in image : Stream, in dt : Date) +CompareTo(in obj : Object) : Integer IComparable «instance» ServiceManager -_instance : ServiceManager -BASE_SERVICE_URL : String = " +getinstance() : ServiceManager -New() +rssclient_itemsreceived(in client : Receiver, in items : List) +proxy_openreadcompleted(in sender : Object, in e : OpenReadCompletedEventArgs) Singleton Receiver -imgafter : Date -RSS_URL : String = " +ItemsReceived(in client : Receiver, in item : List) : ItemsReceivedDelegate +New(in dateafter : Date) +LoadItems() +ResponseCallback(in result : IAsyncResult) -InverseDateOrder(in x : Date, in y : Date) : Integer Figura 5.9: Schema delle classi di ImageWP di 87

70 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE L utilizzo degli eventi nella comunicazione tra i vari componenti è risultato molto utile, vista anche la necessità di eseguire tutte le operazioni di connessione alla rete in maniera asincrona, onde evitare rallentamenti dell interfaccia utente. Inoltre ha reso possibile l innesco di alcuni meccanismi nel momento esatto in cui un dato da processare diventa disponibile. Entrando nello specifico il primo momento in cui avviene comunicazione tra i componenti del sistema è quando l interfaccia grafica riceve dall utente la richiesta di connessione e tramite MainPage arriva fino al Receiver che va a richiedere i dati il servizio. Avviene qui l utilizzo di un evento per la comunicazione tra il Receiver e il ServiceManager, che lo avverte così della disponibilità dei dati. Il ServiceManager dopo aver processato i dati li passa al DataManager tramite l invocazione dei metodi resi disponibili dallo stesso. Il DataManager Si occupa del salvataggio del dato e di avvertire tramite un evento il MainPage che della disponibilità del nuovo dato che può quindi essere mostrato. Lo schema in Figura 5.10 mostra come avviene la comunicazione tra i vari componenti ImageFabric Receiver Evento disponibilità dati ServiceManager GuiUpdate MainPage Evento disponibilità nuovi dati DataManager ImageItem Interfaccia Grafica Figura 5.10: Schema interazione componenti di ImageWP Windows Phone 7 e servizi RESTFul Per contattare un servizio REST si utilizzano i metodi base HTTP (GET, POST, PUT, e DELETE), e le risorse sono identificate da URI. Windows Phone 7 fornisce un insieme di classi per chiamare un servizio REST, ma non supporta le caratteristiche di connettività offerte da Silverlight 4, Windows Phone 7 si limita a supportare Silverlight 3. Per eseguire una richiesta ad un servizio REST è possibile utilizzare o la classe WebClient oppure le classi HttpWebRequest/HttpWebResponse. Entrambe le scelte richiedono esecuzione asincrona, questo è dovuto anche alla volontà di non rallentare l interfaccia grafica durante la connessione ad un servizio di 87

71 Luca Pasa 5.4. IL CLIENT WINDOWS PHONE 7: IMAGEWP7 WebClient: Per utilizzarlo è sufficiente chiamare il metodo asincrono più appropriato (in base al tipo di richiesta e al tipo di risorsa) e gestire il corrispondente evento di completamento della richiesta. Alcuni metodi forniti da WebClient sono: DownloadStringAsync (GET); DownloadStringAsync (GET); UploadStringAsync (POST); OpenWriteAsync (POST); HttpWebRequest: Permette di avere più controllo sul messaggio della richiesta rispetto a WebClient, e permette di inviare richieste per metodi DELETE e PUT. Uno degli errori più frequenti quando si va ad interagire con un servizio è dato dall impossibilità di avere un connessione internet attiva nel dispositivo. Per questo in Windows Phone 7 mette a disposizione il metodo NetworkInformation.NetworkInterface.GetIsNetworkAvailable, utile da utilizzare prima della chiamata al servizio, il quale restituisce True solo nel caso di disponibilità di connessione ad internet Connessione al servizio ricezione del feed Connettersi al servizio, ottenere il feed ed estrarne le informazioni sono compiti affidati alla classe Receiver. Questa classe richiede, al momento dell istanziazione di dichiarare la data dopo la quale interessano i dati. Tale valore è mantenuto in un campo dati della classe e verrà utilizzato al momento dell interpretazione dei dati e della creazione della lista di dati da restituire. La classe mette a disposizione un metodo che va ad eseguire la richiesta al servizio. Per eseguire la richiesta è stato usato HttpWebRequest. Questa scelta è data dal fatto che i dati sono in formato RSS 2.0 e quindi si è preferito avere maggior controllo nell invio della richiesta rispetto all utilizzo di WebClient. Tale operazione avviene in maniera asincrona e quando è completata, e quindi i dati sono arrivati a destinazione, viene sollevato un evento gestito dal metodo ResponseCallback. In questo metodo vengo decodificati i dati, per farlo sono stati usati gli oggetti e i metodi messi a disposizione dalla classe System.ServiceModel.Syndication. Tale namespace, anche se non nativamente inserito all interno di quelli utilizzabili da Windows Phone 7 è compatibile con la piattaforma Silverlight e si è quindi deciso di utilizzarlo comunque. Questa scelta ha portato indubbi vantaggi andando ad evitare la necessità di eseguire manualmente il parsing del XML. Inoltre questa scelta permette di rendere l applicazione utilizzabile a prescindere dal formato del feed, rendendo trasparente tale differenza, e facendo sì che modifiche future al formato del feed non richiedano alcuna modifica all applicazione. I dati ricevuti in formato RSS 2.0 vengono incapsulati all interno di un oggetto SyndicationFeed e da questo vengono estratti i dati relativi alle immagini e creata una lista contente la data e l ora in cui le nuove immagini, successive alla data minima precedentemente impostata, sono state catturate. La lista prima di essere inviata viene ordinata in modo che le date più recenti siano posizionate in testa alla lista, in questo modo un download sequenziale di tutte le immagine in questo ordine porterebbe ad avere prima i dati più interessanti per l utente, e poi provvederebbe alle immagini meno recenti che sono meno interessanti per quest ultimo. Avviene qui la segnalazione dell acquisizione e il passaggio di tali dati al ServiceManager tramite il sollevamento dell evento ItemsReceived di 87

72 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE Gestione delle informazioni ricavate dal feed e download delle immagini relative La classe ServiceManager riceve le informazione ottenute e codificate dalla classe Receiver. Inoltre la classe Receiver sollevando l evento ItemsReceived richiama il metodo rssclient_itemsreceived della classe ServiceManager che lo gestisce. All interno di questo metodo si controlla che esista almeno un elemento sufficientemente recente e in tal caso lo recupera tramite l utilizzo di un oggetto WebClient. In questo caso il metodo esposto dal servizio restituisce uno Stream, è quindi stato possibile utilizzare il metodo OpenReadAsync per effettuare la richiesta. Questo metodo, al momento del completamento delle operazioni necessarie per ottenere i dati solleva l evento OpenReadCompleted, il quale è gestito dal metodo proxy_openreadcompleted della classe in questione. In questo metodo viene controllato che non siano avvenuti errori durante la connessione, e in questo caso viene richiamata la funzione d inserimento nuovi dati messa a disposizioni dal DataManager Salvataggio dei dati ricevuti Il salvataggio dei dati avviene tramite la classe DataManager. Questa classe si occupa di mantenere in memoria gli elementi. Vista la limitata memoria messa a disposizione dai dispositivi smartphone si è ritenuto opportuno limitare il numero di elementi mantenibili in memoria a dieci. I dati vengono mantenuti all interno di una struttura dati di tipo List(of). Gli elementi contenuti nella lista saranno di tipo ImageItem. ImageItem è la classe appositamente creata per incapsulare informazioni sugli elementi. Vengono quindi salvate la data e l ora in cui l immagine viene catturata, e l array di Byte che rappresenta l immagine. La scelta di mantenere in memoria un array di Byte invece dell immagine è data da due principali motivazioni, legati alla diversa piattaforma rispetto al client per desktop precedentemente sviluppato. La prima motivazione è legata al metodo utilizzato da Windows Phone 7 e Silverlight per gestire le immagini: non è infatti presente la classe Image e per la visualizzazione dell immagine a livello di interfaccia grafica vengono utilizzati oggetti BitmapImage che non sono serializzabili. Il secondo problema è legato proprio alla necessità di dover serializzare gli oggetti ImageItem, per salvare lo stato dell applicazione nella gestione delle politiche legate al Tombstoning. Inoltre l utilizzo di un array di Byte porta con se anche altre facilitazioni come la semplicità di conversione ad oggetto Stream che risulta importante sia in quanto il servizio ci fornisce oggetti Stream nel passaggio delle immagini, sia perché tramite oggetti di questo tipo è possibile creare oggetti BitmapImage utilizzati nell interfaccia utente per visualizzare le immagini. La conversione tra array di Byte e tipo Stream è eseguita in modo completamente trasparente all utilizzatore della classe in quanto essa è incapsulata nella proprietà che permette di gestire tale dato come fosse uno Stream. In questo modo si rende trasparente il fatto che viene salvato un array di Byte. La classe ImageItem va inoltre ad implementare l interfaccia IComparable che permette di rendere oggetti di tipo ImageItem comparabili tra loro. Sì è scelto che la comparazione di tali oggetti venga fatta rispetto alla data e l ora contenuta in essi. Per far sì che la classe risulti serializzabile si sono utilizzati gli attributi <DataContract ()> per la classe e <DataMember()> per i campi dati che si voglio serializzare. Visto l utilizzo di operazioni asincrone nella ricezione dei dati si è deciso di inserire il codice che va a manipolare la collezioni di elementi in memoria, all interno di blocchi SyncLock che assicurano l esecuzione esclusiva di operazioni sulla struttura dati in questione. Le operazioni per la gestione dei dati riguardano l inserimento di un nuovo di 87

73 Luca Pasa 5.4. IL CLIENT WINDOWS PHONE 7: IMAGEWP7 elemento nella lista e la possibilità di ottenere la stessa. Nel primo caso Il metodo va ad incapsulare le operazioni ottenute come parametri di input all interno di un oggetto di tipo ImageItem, e poi esegue l inserimento nella lista. Sì occupa inoltre di controllare se il numero massimo di elementi è già stato raggiunto e, in tal caso, esegue l eliminazione dell oggetto meno recente. Per quando riguarda il metodo che permette di ottenere la lista, sì è deciso di fare in modo che venga restituita una coppia della stessa. La motivazione di questa scelta è data dal fatto che non si vuole che i dati possano essere modificati senza controllo, o che ne vengano inseriti di nuovi, mentre la lista è utilizzata da altri componenti, portando così all inconsistenza del componente che la sta utilizzando, oppure nel caso peggiore dei dati stessi. Prima della restituzione, la lista viene ordinata secondo la data di acquisizione delle varie immagini. La scelta di eseguire l ordinamento al momento della restituzione è dato dalla volontà di rendere l applicazione aperta a sviluppi futuri che potrebbero portare all interfacciamento con più servizi. Infatti, in questo modo, l ordinamento avvene soltanto al momento della restituzione della lista, non andando quindi a riguardare le operazioni di inserimento, facendo sì che l eventuale aumento di inserimenti futuri non vada ad inficiare le funzionalità e le prestazione dell applicazione. La comunicazione dell inserimento di un nuovo elemento viene fatto all interfaccia grafica tramite l utilizzo di un evento. Tale evento viene qui definito insieme al delegato utile alla gestione dello stesso, e viene sollevato ogni qual volta un nuovo elemento viene inserito nella struttura dati. Per assicurare che la gestione del salvataggio in memoria dei dati avvenga tramite un unica istanza di questa classe sì è fatto in modo che DataManager implementi il design pattern Singleton Visualizzazione dei dati Per quando riguarda la visualizzazione dei dati all utente si è per prima cosa creata un interfaccia grafica utilizzando il linguaggio XAML. Tale interfaccia segue lo stile grafico consigliato per le applicazioni Windows Phone 7 mostrando in alto il nome dell applicazione e appena sotto il nome della pagina. Per quanto riguarda la gestione dell interazione con l utente è stato inserito un controllo di tipo Button per permettere all utente di connettersi al servizio. Alla sua destra è presente la checkbox che permette di selezionare la modalità di visualizzazione desiderata. Al di sotto di essi trovano spazio lo slider che permette all utente di navigare attraverso gli elementi attualmente in memoria. È poi stata inserita la label che dà informazioni temporali riguardanti l immagine visualizzata nel controllo Image sottostante. In Figura 5.11 è mostrata l interfaccia grafica in questione. La gestione delle funzionalità di questa interfaccia viene eseguita tramite la classe MainPage. Questa classe oltre a ciò implementa il coordinamento delle varie operazioni dando il via alla ricezione dei dati tramite il Receiver. Alla pressione del bottone che permette la connessione viene istanziato un oggetto Timer che ogni cinque secondi solleva un evento. Questo evento porta alla creazione di un oggetto Receiver e all utilizzo del metodo LoadItems() che permette l acquisizione dei dati. Quando l acquisizione del dato viene completata, ed il dato viene salvato il DataManager solleva un evento che viene catturato all interno della classe MainPage dal metodo HandleNewItem. In questo metodo per prima cosa viene aggiornata la lista degli elementi in memoria (di cui si tiene una copia all interno della classe corrente, per i motivi precedentemente indicati), e vengono poi gestite le casistiche richieste dalle due modalità di visualizzazione di 87

74 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE Figura 5.11: Screen shoot di ImageWP7 in funzione di 87

75 Luca Pasa 5.4. IL CLIENT WINDOWS PHONE 7: IMAGEWP7 Anche in questo caso bisogna gestire il fatto che la gestione dell evento è eseguita da un thread diverso da quello della gestione dell interfaccia grafica, e che l interfaccia grafica può essere gestita esclusivamente da quest ultimo thread. Si sono quindi applicate anche in questo caso politiche di marshaling tramite l utilizzo della metodo Dispatcher.BeginInvoke che permette di di far si che il thread in background deleghi l operazione all oggetto Dispatcher associato al thread dell interfaccia utente. All interno di questa operazione si è quindi gestito l interazione dell utente nelle due modalità andando quindi a controllare il valore della checkbox. Modalità di visualizzazione elemento più recente: in questo caso andiamo a vedere se l elemento più recente contenuto nella lista è più recente dell elemento attualmente visualizzato. In caso positivo andiamo ad aggiornare l interfaccia grafica con il nuovo elemento. Modalità di navigazione tra gli elementi: in questa modalità si controlla quale elemento è selezionato dall utente, e quindi dove è posizionato di conseguenza il puntatore dello Slider. Viene poi aggiornata la lista degli elementi visualizzati e riposizionato lo Slider in corrispondenza dell elemento che si sta ancora visualizzando. Se l elemento visualizzato prima dell aggiornamento non è più nella lista degli elementi salvati perché troppo poco recente, viene visualizzato l elemento attualmente in memoria avente data e ora più vicina a quello che si stava visualizzando. Il cambio di elemento visualizzato va a interessare più controlli dell interfaccia grafica che quindi vanno aggiornati. Tali operazioni di aggiornamento sono state quindi incapsulate in un unico metodo al quale viene passato un oggetto ImagItem oppure i dati singolarmente, e si occupa di andare a visualizzarli nell interfaccia grafica. In più questo metodo porta il vantaggio di applicare, se necessario, politiche di marshaling. È qui gestita anche la navigazione tra gli elementi tramite l evento riguardante lo spostamento dello Slider. In tale evento viene gestito l aggiornamento dei dati visualizzati dalla picture box e dalla label, in base alla posizione del cursore dello Slider. Per il cambiamento dei dati visualizzati viene usato il metodo appena esposto. È infine stato creato un metodo per la gestione della visualizzazione di eventuali errori nel processo di comunicazione con il servizio e visualizzazione dei dati. Tramite tale metodo è possibile visualizzare un messaggio d errore all utente e, in base alla reversibilità o meno dell errore, decidere se permettere altri tentavi di connessione al servizio Gestione della disattivazione dell applicazione Nel realizzare l applicazione per Widows Phone 7 sì è dovuto tener conto della possibilità che l applicazione venga messo in uno stato dormiente, per poi essere riattivata. Le linee guida proposte per lo sviluppo della applicazioni suggeriscono di rendere questa situazione il più possibile trasparente per l utenza. A questo proposito si sono dovute implementare politiche per il salvataggio dello stato della pagina e dell applicazione stessa. Si è anche dovuto tenere conto della casistica che si sta trattando. Una delle maggiori problematiche emerse in questo frangente è l impossibilità di mantenere la connessione attiva con il servizio dopo che l applicazione è stata disattivata. Questo comporta che, anche salvando lo stato dell applicazione nel momento in cui essa viene messa nello stato dormiente, al momento dell attivazione i dati visualizzati non saranno aggiornati. Si è comunque deciso i implementare tale operazione di gestione della disattivazione, trovandola interessante per le disattivazioni di breve periodo di 87

76 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE Per implementazione si è dovuto inserire del codice all interno della classe MainPage andando a gestire gli eventi OnNavigatingFrom e OnNavigatedTo dell unica pagina che compone l applicazione. Per prima cosa però si è andati a creare la variabili booleana _isnewpageinstance per segnalare se l applicazione è alla sua prima esecuzione oppure se è stata riattivata dallo stato dormiente. Nell evento OnNavigatingFrom è necessario salvare i dati prima che l applicazione venga disattivata. Il salvataggio avviene all interno dello State Dictionary messo a disposizione dal sistema operativo invocabile tramite l oggetto PhoneApplicatio.State che è di tipo IDictionary. In Questo oggetto è necessario salvare lo stato grafico della pagina e i dati relativi all applicazione: Dati relativi all applicazione: I dati dell applicazione interessanti per le prossime esecuzioni sono quelli contenuti nella lista di elementi ricevuti dal servizio e attualmente salvati in memoria. Per il salvataggio di questi dati all interno dello State Dictionary è necessario che siano serializzabili. È quindi stato necessario rendere gli oggetti ImageItem contenuti nella lista degli elementi serializzabili, ed è stato questo uno dei motivi per cui sì è deciso di rappresentare le immagini in essi contenute tramite array di Byte. Anche la scelta della struttura dati ha richiesto di scegliere un contenitore serializzabile, e si è quindi scelto un oggetto di tipo List(of). Salvando tutti i dati attualmente contenuti in memoria ha permesso, al rientro nell applicazione di utilizzare tutte le funzionalità fornite normalmente (ad esempio navigare tra i vari dati) senza dover attendere che la connessione venga ristabilita. Dati della pagina: Per il salvataggio dei dati relativi alla pagina, utili a ricreare la medesima interfaccia grafica al momento della riattivazione dell applicazione, si è deciso di creare una classe apposita alla quale collegare le proprietà dei controlli grafici che si intende conservare tramite binding. Tale classe è stata chiamata GuiUpdate, e contiene campi dati capaci di ospitare i valori delle proprietà che si vogliono mantenere nello State Dictionary. La classe implementa l interfaccia INotifyPropertyChanged che tramite l evento PropertyChanged permette di aggiornare automaticamente le proprietà collegate in base al valore dei campi dati della classe e viceversa. Per render la classe Serializzabile si sono inoltre usati gli attributi <DataContract()> per l intera classe e <DataMember()> per le proprietà che si vuole serializzare. Grazie alla classe GuiUpdate è stato possibile salvare tutti i dati che permettono di ristabilire l aspetto grafico dell applicazione in una sola istruzione e con un solo oggetto, inoltre automatizzando la raccolta di questi dati. Nell evento OnNavigatedTo per prima cosa si controlla se è il primo accesso alla pagina (e nel nostro caso, avendo una sola pagina anche all applicazione) oppure si tratta di una riattivazione, per fare questo controllo si utilizza la variabile booleana _isnewpageinstance. Se il controllo segnala che è una nuova istanza della pagina (e dell applicazione) l unica operazione da eseguire e la preparazione degli oggetti che andranno poi a contenere i dati che verranno salvati nello State Dictionary. Nel caso in cui invece ci si trovi di fronte ad una situazione in cui l applicazione è stata riattivata s va a leggere i dati dallo State Dictionary ed inserirli negli oggetti opportuni. Questo è sufficiente anche per la gestione dell interfaccia grafica, infatti essendo la classe GuiUpdate collegata ad essa ed implementando l interfaccia INotifyPropertyChanged, le modifiche all oggetto si ripercuotono automaticamente sull interfaccia grafica. È stato però necessario eseguire un ulteriore operazione riguardante la visualizzazione delle immagini, infatti è necessario reimpostare la proprietà source del controllo di 87

77 Luca Pasa 5.4. IL CLIENT WINDOWS PHONE 7: IMAGEWP7 grafico image, in quanto tale proprietà contiene oggetti non serializzabili e quindi non inseribili nella classe GuiUpdate e nello State Dictionary di 87

78 Luca Pasa CAPITOLO 5. DEFINIZIONE SOLUZIONE di 87

79 Capitolo 6 Conclusioni Il progetto ha richiesto la creazione di un applicazione prototipale per l invio d immagini catturate da una webcam, senza che sia necessario eseguire modifiche a sistemi NAT, proxy e firewall. Inoltre l applicazione realizzata ha dovuto minimizzare il TCO. Per far sì che questi vincoli siano rispettati è stato creato un servizio RESTful che si appoggia su Windows Azure AppFabric Service Bus per la comunicazione tra esso ed i client. Tale prototipo è stato realizzato per accertare la fattibilità di tale applicazione al fine di decidere se inserire o meno questa nuova funzionalità all interno del prodotto software akite. L attività di stage è stata divisa in due principali fasi: una prima fase di studio delle tecnologie necessarie per la realizzazione del progetto, e una seconda dove è stato analizzato il problema e realizzata la soluzione. La prima fase ha richiesto circa quattro settimane lavorative in cui lo stagista, affiancato dal tutor aziendale, ha appreso le tecnologie necessarie all esecuzione del progetto ed eseguito dei tutorial esemplificativi per meglio comprendere le stesse. La seconda fase ha avuto una durata di circa cinque settimane. All interno di queste cinque settimane si è per prima cosa eseguita un analisi del problema, che ha portato ad identificare quali requisiti fosse necessario soddisfare per creare una soluzione che risolvesse il problema. Vista la natura della soluzione, comprendente più applicazioni si è deciso di eseguire per ognuna di esse una fase di progettazione e codifica. Tali attività hanno richiesto il tempo previsto nel piano di lavoro. In Figura 6.1 viene riportato il diagramma di Gantt che segnala la durata effettiva delle attività eseguite all interno dell attività di stage. Figura 6.1: Diagramma di Gantt che illustra la durata effettiva dell attività di stage. Il progetto è stato completato con successo, andando a confermare la fattibilità dell applicazione. La soluzione ottenuta ha dimostrato di poter soddisfare tutti i requisiti espressi in fase di analisi. In particolare l utilizzo del paradigma REST per l esposizione del servizio ha dimostrato di rendere quest ultimo fortemente interoperabile e versatile, andando inoltre a dimostrare una grande facilità nel consumo dei dati esposti. 79