Università degli studi Roma Tre. Facoltà di Ingegneria INTEGRAZIONE DI UNA PIATTAFORMA IPTV IN UN ARCHITETTURA SOA

Transcript

1 Università degli studi Roma Tre Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Tesi di Laurea INTEGRAZIONE DI UNA PIATTAFORMA IPTV IN UN ARCHITETTURA SOA Candidata Sara Castellani Relatore Prof. Paolo Merialdo Correlatori Ing. Alessandro Balzarelli Prof. Alessandro Toscano Anno Accademico 2005/2006

2 Dedico questo lavoro al team di Microsoft e in particolare ad Alessandro Balzarelli che mi ha dato la possibilità di fare questa splendida esperienza, permettendomi di imparare molto, al mio relatore Paolo Merialdo che mi ha indirizzato e guidato nel momento della scelta e nel corso degli studi, a mamma e papà che mi hanno sempre sostenuto in ogni percorso che ho deciso d intraprendere vivendo con me ogni vittoria e sconfitta, al mio ragazzo che mi è stato vicino dall inizio alla fine incoraggiandomi nei momenti di sacrificio e delusione con il suo ottimismo e condividendo gioie ed entusiasmi, ed infine ai miei compagni di università che hanno alleviato il duro percorso universitario. Sara

3 SOMMARIO INTRODUZIONE 7 STRUTTURA DELLA TESI 10 PARTE I - LA PIATTAFORMA IPTV, ARCHITETTURE SOA, E TECNOLOGIE 13 1 LA PIATTAFORMA IPTV TENDENZA DELLE AZIENDE DI TELECOMUNICAZIONE TRIPLE PLAY DESCRIZIONE DEL SERVIZIO VIDEO: IPTV TECNOLOGIE ALTERNATIVE VANTAGGI DI IPTV LIMITAZIONI DI IPTV LIVE TV PAY-PER-VIEW VIDEO ON DEMAND APPLICAZIONI 24 2 IPTV EDITION: IMPLEMENTAZIONE MICROSOFT DI IPTV FLUSSO DEI CONTENUTI VIDEO ARCHITETTURA GENERALE ARCHITETTURA IPTVE LIVE TV Flusso funzionale VIDEO ON DEMAND 34 3 ARCHITETTURE SOA DEFINIZIONE CARATTERISTICHE FONDAMENTALI ELEMENTI PRINCIPALI DI SOA FRONTEND DELL APPLICAZIONE SERVIZI SERVICE REPOSITORY MODELLI D INTEGRAZIONE: SERVICE BUS E ENTERPRISE APPLICATION INTEGRATION 45

4 3.4 STANDARD PER ARCHITETTURE SOA WEB SERVICES SOAP (SIMPLE OBJECT ACCESS PROTOCOL) WSDL (WEB SERVICE DESCRIPTION LANGUAGE) ARCHITETTURA WS-* WS-ADDRESSING Endpoint reference Message information header WS-SECURITY Sicurezza dei messaggi 63 4 TECNOLOGIE E STRUMENTI CONNECTED SERVICES FRAMEWORK RETE DI SERVIZI DEFINIZIONE FUNZIONAMENTO ARCHITETTURA Sessione Service Logic Identity Manager IL FRAMEWORK.NET WINDOWS COMUNICATION FOUNDATION Modello di programmazione WINDOWS WORKFLOW FOUNDATION Schedulazione dei processi Servizio di persistenza 90 PARTE II PROGETTAZIONE E SVILUPPO DEI TEST, DELL ARCHITETTURA DI SIMULAZIONE DELL AMBIENTE IPTVE, E DEL COMPONENTE DI TRACING 92 5 IL CASE STUDY E LO SVILUPPO DEI TEST CATEGORIZZAZIONE DEI SERVIZI OSS E BSS ARCHITETTURA GENERALE DEL SOLUTION DESIGN SVILUPPO DEI TEST PER CP TEST PER VOD MANAGEMENT TEST PER EPG MANAGEMENT CONSIDERAZIONI METODOLOGICHE DEFINIZIONE E SVILUPPO DELL ARCHITETTURA SOA DI SPERIMENTAZIONE 105

5 6.1 SPECIFICHE DEL SISTEMA DEFINIZIONE DELL ARCHITETTURA INTERAZIONE TRA LE COMPONENTI CONFIGURAZIONE DELL INFRASTRUTTURA DELL AMBIENTE DI SVILUPPO CONFIGURAZIONE DELLE MACCHINE VIRTUALI ACTIVE DIRECTORY DOMAIN CONTROLLER PROGETTAZIONE E SVILUPPO DELLE COMPONENTI CLIENT SESSION OWNER SERVICE LOGIC VAS1 E VAS VARIAZIONI ARCHITETTURALI GESTIONE SINCRONA E ASINCRONA NELLA COMUNICAZIONE GESTIONE DELLA CONCORRENZA GESTIONE DEL SERVIZIO DELL IDENTITY MANAGEMENT IL COMPONENTE DI TRACING ANALISI DEI REQUISITI CASI D USO CASO D USO CASO D USO CASO D USO CASO D USO CASO D USO CASO D USO CASO D USO PROGETTAZIONE E IMPLEMENTAZIONE DEL COMPONENTE IL MODELLO DI COMUNICAZIONE DESCRIZIONE DEI LIVELLI APPLICATIVI GESTIONE DELLA PERSISTENZA GESTIONE DELL INTERFACCIA DIAGRAMMI D INTERAZIONE CONCLUSIONI APPENDICE IL FRAMEWORK.NET E C# CLI E CLR 165

6 9.3 PROCESSO DI COMPILAZIONE ED ESECUZIONE I LINGUAGGI COMPATIBILI CON IL FRAMEWORK.NET LA LIBRERIA DI CLASSI DEL FRAMEWORK.NET EVOLUZIONE DEL FRAMEWORK.NET 170 BIBLIOGRAFIA 172 GLOSSARIO 174 INDICE FIGURE 183

7 Introduzione 7 Introduzione Internet è divenuto il mezzo di trasmissione e di ricezione di informazioni più diffuso al mondo. Nel corso degli ultimi decenni la rete ha ampliato sempre più il suo spettro d azione, sia dal punto di vista della copertura geografica, che dal punto di vista della qualità del servizio fornito in termini di efficienza, affidabilità e sicurezza delle informazioni scambiate. Il miglioramento delle tecnologie di rete ha reso possibile il passaggio da un ambiente di semplice divulgazione di contenuti testuali ad un pianeta complesso in cui è possibile anche acquistare beni di prima necessità. L avanzamento tecnologico ha prodotto un incremento della fiducia da parte della popolazione di utenti nel mezzo trasmissivo. I fattori che hanno contribuito in maniera determinante in questo processo sono stati la crescita della sicurezza, affidabilità e disponibilità dei servizi forniti tramite Internet. In quest ottica si colloca lo slancio delle aziende negli investimenti nel settore di distribuzione di servizi online. Nascono, quindi, due tendenze parallele e concordanti: la tendenza ad ampliare la gamma di informazioni divulgate portando sulla rete contenuti multimediali come musica, video, e voce; e quella a facilitare e rendere maggior efficiente la collaborazione a livello aziendale vista come importante mezzo produttivo. Sfruttando la potenza fornita dall innovazione tecnologica è possibile comunicare con colleghi, amici, e clienti mediante conferenze, seminari e, negli ultimi tempi, vere e proprie telefonate. Internet è nato come sistema best effort ma il suddetto tipo di contenuti esige un certo livello di qualità. Il problema si presenta in questo periodo in cui le aziende di telecomunicazioni tendono ad unificare i servizi video, telefonia, e dati sfruttando solo la rete IP. In questa direzione si fa strada il concetto di IPTV come distribuzione dei contenuti televisivi tramite IP. Il lavoro di tesi si colloca nell ambito del progetto d integrazione di un infrastruttura di servizi informatici denominata Microsoft IPTV Edition (IPTVe) con i sistemi di OSS/BSS di Telecom Italia. Con essi si intendono i sistemi di ogni operatore di telecomunicazioni per la gestione dei processi operazionali Operational Support System (OSS) e dei processi di business Business Support System (BSS). Per erogare servizi TV over IP per il mercato consumer, Telecom Italia si è dotata del suddetto ambiente che fornisce servizi come Live TV per la trasmissione in televisione di eventi e performance simile alla normale TV, Video on Demand per la fruizione di contenuti video su richiesta, Electronic Program Guide per la fornitura di una guida elettronica ai programmi televisivi, etc. Al fine d integrare la soluzione IPTVe di Microsoft con i sistemi di Telecom Italia, nell ambito del progetto, è stato sviluppato un opportuno layer applicativo d interfaccia tra i due sistemi. Lo scenario risulta complesso e di grandi dimensioni per il numero di componenti coinvolti. Il lavoro svolto può essere suddiviso in due parti che hanno interessato punti di vista differenti: una prima parte orientata ad affrontare un aspetto più teorico, necessaria

8 Introduzione 8 a creare il background utile per sostenere la seconda, in cui lo slancio pratico e implementativo predomina. Inizialmente lo sforzo è stato concentrato sullo studio della nuova tecnologia proposta nel progetto, che suggerisce un idea del tutto nuova di televisione e introduce una serie di servizi associati che ne ampliano le funzionalità e i campi d applicazione. Con l infrastruttura di servizi IPTV è possibile, infatti, non solo semplicemente guardare la TV ma anche interagire con essa. L opportunità di fruire dei contenuti televisivi on demand introduce una vera rivoluzione nel modo di concepire la televisione, rispetto a quello tradizionale. Inoltre IPTV utilizza uno standard per la compressione più efficiente rispetto a quelli utilizzati per la tv satellitare, permettendo un miglioramento della qualità del servizio. Grazie al mezzo trasmissivo è possibile unificare più servizi in uno solo determinando una convergenza su un unica infrastruttura di telefonia, Internet, e televisione. Esaminati gli aspetti più importanti di questa tecnologia è stato interessante soffermarsi sulla sua implementazione con il sistema informatico Microsoft IPTVe. L analisi del suddetto sistema ha consentito di capire come i contenuti televisivi vengano prodotti e distribuiti attraverso il panorama di utenti sottoscrittori dei vari servizi. In particolare ci si è concentrati sul flusso di erogazione di servizi Video on demand (VoD) e Live TV. Il sistema d integrazione realizzato da Microsoft si basa su un architettura distribuita orientata ai servizi (SOA). Nel panorama del mercato attuale i servizi sono sempre più sviluppati da team afferenti a diverse aziende per la crescente tendenza alla distribuzione dei compiti, e alla decentralizzazione del controllo. Grazie all avvento di Internet e alla sua diffusione questa spinta verso la distribuzione si è accentuata ancora di più segnalando la necessità di creare archetipi di comunicazione che favoriscono quest approccio. Quest orientamento ha coinvolto anche lo sviluppo di software. Causa e conseguenza della distribuzione dei compiti va ricercata nell ampliamento dei contesti di applicazione dei sistemi informatici che abbracciano, ormai, quasi tutti gli aspetti della vita umana. In contesti così allargati risulta impensabile, sopratutto dal punto di vista della manutenzione, accentrare tanti aspetti diversi sotto un unica unità di controllo. In quest ottica è stato necessario analizzare gli aspetti concettuali che si nascondono dietro al sistema d integrazione. Lo studio delle architetture SOA ha determinato il necessario approfondimento del concetto di servizio, in particolare di Web Service, e degli standard e protocolli di comunicazione utilizzati in quest ambito, come SOAP, per lo scambio di messaggi, e WSDL. Siccome nel progetto sono stati trattati alcuni aspetti relativi alla sicurezza è stato necessario studiare l architettura WS-*, che si occupa di corredare i Web Service di tutte quelle funzionalità aggiuntive per la gestione di sicurezza e affidabilità della comunicazione. La parte teorica si è conclusa con lo studio delle tecnologie Microsoft, che si possono considerare implementazione degli standard studiati, utile per affrontare la fase di realizzazione successiva. Il Framework.NET, la sua ultima versione.net 3.0 con lo strumento per sviluppare servizi in ambienti distribuiti (Windows Comunication Foundation) e lo strumento di

9 Introduzione 9 gestione dei flussi i lavoro (Windows Workflow Foundation) sono stati al centro dell analisi insieme a Connected Services Framework 3.0 (CSF 3.0), framework per la connessione di servizi in ambienti distribuiti. La parte pratica è stata guidata, inizialmente, dalla richiesta di testare alcune parti critiche del sistema con l intento di prendere confidenza con le tecnologie e con la realtà d interesse. Nel contesto di sviluppo di software d integrazione tra i servizi di Telecom Italia e la piattaforma IPTVe è stato necessario monitorare gli effetti, sul sistema d integrazione, dei cambiamenti e variazioni provocati dai sistemi coinvolti. In questa direzione sono stati fatti dei test su alcune componenti del progetto, in particolare quella relativa alla gestione dei VoD e all EPG (Electronic Program Guide). Questa fase è stata condotta guidando lo sviluppo con gli aspetti teorici studiati riguardo alle tecniche e agli approcci al testing. In seguito l obiettivo da raggiungere è stato quello della creazione di un componente per il tracciamento d informazioni diagnostiche sul comportamento del sistema in fase di esercizio. Per lo sviluppo di tale componente è stata necessaria la realizzazione di un architettura SOA che simulasse le reali componenti del sistema IPTVe entro il quale inserire l elemento per il tracciamento dei messaggi. L opportunità di sviluppare questo sistema di sperimentazione ha reso possibile conoscere e mettere in pratica molte delle tecnologie utilizzate nel progetto d integrazione con la piattaforma IPTVe. Progettando e sviluppando, in scala minore, i processi che regolano l interazione tra le componenti del sistema reale è stato possibile capire in maniera approfondita come i flussi d informazione viaggino attraverso i partecipanti al sistema e come tali informazioni vengano modificate. Il sistema distribuito è composto da più servizi, sviluppati sia con CSF 3.0 sia con tecnologie appartenenti al Framework.NET 3.0, che cooperano tramite l utilizzo di un service bus. La realizzazione di questi servizi, e della loro interazione, ha richiesto, in aggiunta, la gestione di aspetti legati alla sicurezza dello scambio dei messaggi, e alla concorrenza di richieste. Disegnata e sviluppata l architettura d inserimento è stata affrontata la fase di analisi, progettazione e sviluppo del componente di Tracing, che verrà introdotto nel sistema d integrazione realizzato da Microsoft. Il principale requisito da soddisfare è stato quello di definire un servizio in grado d intercettare tutti i messaggi d interesse per il monitoraggio, configurandoli in maniera altamente dinamica, anche, a tempo di esecuzione della piattaforma. Non è, infatti, auspicabile pensare d interrompere il funzionamento dell intero sistema nel caso in cui si voglia aggiungere un ulteriore informazione da controllare. In secondo luogo, è stato richiesto che l elemento fosse riusabile in contesti e realtà d interesse molto diverse tra loro. Un applicazione con queste caratteristiche, infatti, una volta realizzata può essere inserita in qualsiasi ambiente distribuito orientato ai servizi. Per ottenere questo risultato l elemento è stato progettato in maniera da essere altamente coeso e poco accoppiato con le altre parti costituenti dell architettura.

10 Struttura della Tesi 10 Struttura della Tesi La tesi si articola in due parti. Parte Prima: La piattaforma IPTV, architetture SOA, e tecnologie Nel capitolo 1 saranno descritti i concetti fondamentali legati all IPTV per la comprensione del contesto d inserimento del progetto di tesi. In questo capitolo verrà anche affrontata la trattazione delle tecnologie necessarie alla fruizione dei servizi di TV over IP e i sottoservizi che lo compongono Live TV, Video on Demand, Pay Per View. L IPTV sarà messa a confronto con le altre tecnologie concorrenti evidenziandone vantaggi e limitazioni. Nel capitolo 2 sarà trattata la descrizione dell infrastruttura dei servizi informatici Microsoft IPTVe in termini dell architettura delle componenti, dei sistemi e sottosistemi che la compongono e di come essi interagiscono per fornire il servizio TV. Affrontate le caratteristiche distintive dei contesti IPTV e come la piattaforma Microsoft le ha realizzate con il sistema IPTVe, è importante definire i concetti base nel capitolo 3 che reggono l imponente struttura dell architettura distribuita sulla quale è realizzata la piattaforma. Nel capitolo saranno trattate le architetture orientate ai servizi (SOA), i loro elementi costituenti, gli standard e i protocolli che ne permettono la realizzazione (SOAP,WSDL) ponendo al centro dell analisi il concetto di servizio e in particolare di Web Service. Inoltre non saranno trascurate le tematiche relative alla definizione di specifiche come WS-Security e WS-Addressing che aggiungono ulteriori potenzialità ai Web Service fornendo sicurezza e affidabilità. Nel capitolo 4 saranno analizzati gli aspetti tecnologici relativi all applicazione dei concetti esposti nel capitolo 3. In particolare saranno esposte le tecnologie Microsoft, implementazione degli standard analizzati nel corso del lavoro, necessari per realizzare il sistema distribuito. Lo studio di alcuni framework di comunicazione come Connected Services Framework 3.0 e di parte del Framework.NET 3.0 sono stati propedeutici alla realizzazione del sistema. Questo capitolo ha l obiettivo di proporsi come ponte di collegamento tra i concetti, i modelli, i protocolli e gli standard descritti nel capitolo 2 che sono la base teorica, e l implementazione del sistema, descritta nei capitoli 6 e 6, fondata su questi concetti. Parte Seconda: Progettazione e sviluppo dei test, dell architettura di simulazione dell ambiente IPTVe, e del componente di Tracing

11 Struttura della Tesi 11 Nel capitolo 5 l obiettivo è quello di descrivere la fase iniziale del lavoro che si è concretizzata con lo sviluppo dei test per alcune componenti del sistema d integrazione. Per raggiungere questo intento occorre descrivere, in primis, il contesto e il sistema sul quale realizzare i test. In quest ottica si cercherà di illustrare le componenti custom costituenti il layer applicativo d integrazione tra la piattaforma IPTVe ed i sistemi Telecom Italia. In seguito si passerà all analisi del processo di testing rivolto a due componenti del sistema: VOD Management ed EPG Management. La trattazione proseguirà descrivendo le considerazioni fatte in questa fase e le scelte effettuate con riferimento alle tecniche e metodologie del testing del software. Nel capitolo 6 sarà descritta l analisi, la progettazione e l implementazione dell architettura SOA di simulazione del layer applicativo di integrazione tra i servizi OSS/BSS di Telecom Italia e l infrastruttura di servizi informatici IPTVe. Questa architettura di simulazione è stata sviluppata con l intento di creare un contesto simile a quello reale per ospitare il componente di Tracing adibito al tracciamento dei messaggi. Inizialmente si descriverà come è avvenuta la fase di analisi e definizione delle specifiche funzionali e dei vincoli d implementazione; poi si passerà alla descrizione dell architettura distribuita e della sua analogia con quella reale, considerando in seguito l interazione tra i costituenti architetturali. A questo punto, sarà utile spiegare come è avvenuta la configurazione infrastrutturale del sistema dal punto di vista software e hardware. Successivamente si focalizzerà l attenzione su ogni elemento di composizione dell architettura dal punto di vista sia progettuale che realizzativo. Nell ultimo paragrafo del capitolo saranno trattate una serie di questioni emerse durante lo sviluppo e una serie di considerazioni su alcune modifiche apportate al sistema originale descrivendo gli approcci adottati per gestirle. Tra queste, si citerà l esigenza di affrontare situazioni concorrenti, la necessità di utilizzare pattern di comunicazione asincroni in ambienti distribuiti, ed infine la gestione della sicurezza nello scambio dei messaggi tra i partecipanti al sistema. Nel capitolo 7 sarà effettuata una trattazione della fase di analisi, progettazione e implementazione del componente di Tracing utilizzato per il tracciamento d informazioni diagnostiche, mettendo in luce i requisiti da soddisfare e le difficoltà affrontate nella realizzazione. In prima istanza, saranno proposti i requisiti funzionali e non, accompagnati da una descrizione dei casi d uso per il componente. L attenzione sarà rivolta all analisi delle alternative tra i vari modelli di comunicazione con il resto del sistema, ricercando quello più adatto sulla base di riflessioni sui costi e i benefici. La trattazione si conclude descrivendo l implementazione dell applicazione dal punto di vista della distribuzione delle responsabilità tra le classi che la compongono, e definendo la sua interazione con le altre parti del sistema. Nel capitolo 8 si illustreranno le conclusioni sul lavoro svolto e delle riflessioni sulle nozioni studiate riassumendo quanto fatto nel corso del lavoro. L intento che vuole

12 Struttura della Tesi 12 perseguire questo capitolo conclusivo è quello di esprimere riflessioni personali sull esperienza affrontata.

13 Parte I - La piattaforma IPTV, Architetture SOA, e Tecnologie

14 La piattaforma IPTV 14 1 La piattaforma IPTV L obiettivo di questo capitolo è di fornire un quadro generale e un contesto d inserimento per comprendere i concetti base legati all IPTV. Illustrando molte delle tecnologie e dei protocolli utilizzati dai provider per fornire il servizio televisivo over IP si cerca di fornire al lettore le conoscenze necessarie per comprendere il resto del lavoro. In questo capitolo è fornita, oltre alla definizione di IPTV con la descrizione dei relativi servizi di Live Tv, Video on Demand e Pay-per-view, anche un analisi dei suoi benefici e delle sue limitazioni dando cenno anche alle tecnologie alternative e concorrenti nel campo televisivo. 1.1 Tendenza delle aziende di telecomunicazione Il business delle aziende di telecomunicazione si è progressivamente spostato dalla telefonia al traffico dati. I margini di guadagno della telefonia si sono, infatti, progressivamente assottigliati: basti pensare al fatto che il prezzo di una telefonata è rimasto pressoché invariato dai tempi dei gettoni telefonici e la copertura è ormai totale. Figura 1 Andamento dei costi per le chiamate urbane Ogni azienda di telecomunicazione si è quindi lanciata anche sul mercato degli ISP (internet service provider) e alla fornitura d accessi a banda larga. La crescente disponibilità di banda ha aperto la possibilità di offrire attraverso Internet nuovi servizi quali, ad esempio, la tv digitale. La prima azienda in Italia a sfruttare questa potenzialità è stata Fastweb, avvantaggiata dal fatto che la propria rete di distribuzione in fibra ottica permetteva una larghezza di banda irraggiungibile a quei tempi dagli altri operatori. Recentemente però in gran parte delle città è disponibile un collegamento sufficientemente veloce a supportare anche traffico multimediale. Altri operatori, in primis Telecom Italia con il servizio Rosso Alice, sono quindi subentrati nel mercato. Fastweb è stata la prima, però, anche a sfruttare la propria rete IP per fornire su un unica tecnologia tutti e tre i servizi: il cosiddetto triple-play.

15 La piattaforma IPTV Triple Play Triple play, letteralmente triplo gioco, è un termine di marketing che definisce la fornitura, su un unica rete IP dei seguenti servizi: Internet a banda larga. Televisione: Video on Demand (VOD) o Live Stream. Telefono (Voice over IP o VoIP). Triple play non richiede che il telefono e la TV usino Internet ( Voice over IP e IPTV), molti provider di servizi offrono anche il telefono in forma analogica. Sebbene i servizi TV su connessioni telefoniche molto spesso usino una forma di IPTV, che è più compatibile con le tecnologie DSL. I contenuti TV sono distribuiti generalmente utilizzando il formato MPEG-2 e ricevuti dagli utenti utilizzando un Set-top-box (STB) (illustrato in Figura 2) che permette il tuning (ossia la sintonizzazione) tra i canali disponibili e l accesso a contenuti on-demand e pay-per-view. Figura 2 Set-top-box Le telefonate sono invece instradate utilizzando sistemi VoIP : la voce è codificata, compressa e inviata in pacchetti su protocollo IP. Recentemente è possibile trovare citato anche il termine quadruple-play. Con questo termine, in aggiunta a questi tre servizi, viene considerato anche il traffico mobile per fornire wireless voce, dati e contenuti multimediali. Nonostante l entusiasmo spesso ostentato dalle compagnie di telecomunicazioni, il triple-play non aumenterà necessariamente il mercato della banda larga. Secondo alcuni studi, infatti, il vantaggio principale sarà la fidelizzazione dei clienti e quindi la diminuzione del tasso d abbandono per passare ad altri operatori. Un altra fonte di guadagno potrebbe essere inoltre trovata nella vendita di contenuti on-demand e pay-per-view, i ricavi in questo settore hanno infatti spinto Telecom Italia ad investire ancora su questo mercato e cercherà nel prossimo futuro di portare nelle case degli italiani un sistema di IPTV. Tuttavia, sebbene sia probabile che non ci sarà un drastico aumento dei clienti della banda larga, il passaggio al triple-play, almeno per quanto riguarda la telefonia, comporterà dei vantaggi in termini infrastrutturali.

16 La piattaforma IPTV 16 La differenza sostanziale sta nel passaggio dalla commutazione di circuito a quella di pacchetto: nella telefonia tradizionale, infatti, durante una conversazione vengono riservate risorse lungo tutto il percorso dal chiamante al ricevente. Le tecniche di commutazione e di trasmissione dei dati sono migliorate notevolmente da quando era un operatore a collegare fisicamente i cavi per mettere in comunicazione due telefoni, ma il principio rimane comunque il medesimo. Su una rete IP invece il medesimo canale può portare un numero elevato di conversazioni, dipendente dalle tecniche utilizzate e dalle caratteristiche della chiamata. Figura 3 Utilizzo banda canale/tempo PSTN Figura 4 Utilizzo banda canale/tempo VOIP L utilizzo di una rete basata su IP comporta un miglioramento nello sfruttamento delle risorse: la voce può essere compressa mediante diverse tecniche compensando in questo modo l overhead dovuto agli header IP. Il vero guadagno viene però dall utilizzo di tecniche di silence suppression. Si può affermare, infatti, che per la maggior parte del tempo uno solo dei due interlocutori parla: ciò comporta intuitivamente un risparmio fino al 50% dello sfruttamento del canale come illustrato in Figura 3 e in Figura Descrizione del Servizio Video: IPTV Quando si parla di IPTV (o TV over IP, cioè servizi video distribuiti attraverso una rete IP) si intendono generalmente diversi tipi di servizi. I prodotti commerciali attualmente sul mercato danno la possibilità di erogare quattro tipi di sotto servizi :

17 La piattaforma IPTV 17 Live tv Video on demand Pay per view Applicazioni IPTV (Internet Protocol Television) descrive un sistema dove la fruizione di contenuti in formato digitale è fornita utilizzando il protocollo di trasporto IP su un infrastruttura di rete con connessione a banda larga. IPTV è tipicamente erogato da un operatore broadband utilizzando una infrastruttura di rete chiusa. L approccio che definisce la fruizione del servizio tramite una rete chiusa è in contrasto con Internet Television che, invece, prevede l erogazione del servizio televisivo tramite la diffusione dei contenuti su Internet. L IPTV può essere utilizzata tramite due forme commerciali: free o basata su canone. Ci sono oltre canali IPTV free disponibili. Questo settore è in rapida crescita e le maggiori trasmittenti televisive a livello mondiale trasmettono il segnale su Internet. Questa forma di fruizione del servizio richiede solo una connessione alla rete e un dispositivo che ne consente l utilizzo (personal computer, ipod, telefono cellulare con abilitati i servizi 3G). Alla base del concetto di IPTV c è quello di televisione digitale. Essa è un sistema di telecomunicazione per la trasmissione e ricezione di video e suoni tramite segnali digitali, in contrapposizione al segnale analogico della televisione tradizionale. La televisione digitale usa la modulazione dei dati digitale, che richiede una decodifica del segnale tramite una televisione progettata appositamente o un ricevitore standard con un set-up box. Tale dispositivo, collegato alla televisione da una parte e alla sorgente dei segnali dall altra, trasforma il segnale in contenuti per poi essere visualizzati sul video. Per contenuto in tale contesto si intende video, audio, pagine web, giochi interattivi o altro. Ci sono diversi vantaggi della televisione digitale rispetto a quella analogica in termini sia di qualità che di prestazioni: Qualità: il segnale digitale ha la caratteristica di essere molto più "pulito" di quello analogico, grazie alla complessa tecnologia di soppressione del rumore e dei disturbi; questo fa sì che le immagini ricevute in digitale siano del tutto prive di "bande", "effetto neve", nebbia, colori sbagliati e quant'altro. Con la TV digitale, l'immagine o si vede o non si vede, non ci sono vie di mezzo; al massimo, in casi estremi di scarsa potenza del segnale ricevuto, si possono vedere immagini "a quadrettoni", perché i dati non vengono ricevuti bene, ma si tratta in genere di situazioni temporanee; Prestazioni: la migliore qualità dell'immagine non è l'unico vantaggio delle trasmissioni video digitali; un altro grosso vantaggio è la possibilità di trasmettere una maggior quantità di dati all'interno di ogni singola trasmissione. L'utilizzo del digitale permette, infatti, di ricevere sulla TV di

18 La piattaforma IPTV 18 casa, oltre alle immagini, anche sottotitoli (anche in diverse lingue, come ad esempio in inglese e in italiano), audio multicanale per impianti hometheatre, e testi informativi riguardanti i programmi (ad esempio ulteriori informazioni sul programma in onda, o su quelli che andranno in onda successivamente) tramite l EPG, Electronic Programming Guide, ossia Guida Elettronica alla Programmazione. A tutto questo si aggiunge, in taluni casi, l'interattività, che permette di personalizzare quanto ricevuto sul teleschermo: collegando il ricevitore (detto anche decoder) alla presa telefonica, è possibile inviare all'emittente segnali di ritorno, sulla base dei quali l'emittente cambia le immagini ricevute. Grazie a questo meccanismo, è possibile acquistare eventi come film in prima visione o partite di calcio, oppure collegarsi alla propria banca e visualizzare sulla televisione il proprio conto, o ancora effettuare votazioni e sondaggi in diretta; eccezion fatta per il pagamento on-line, queste possibilità (operazioni bancarie, votazioni, sondaggi) sono ancora in fase sperimentale e probabilmente verranno attivate in via definitiva in un prossimo futuro. I contenuti video in genere sono compressi in formato MPEG2 oppure MPEG4 diffusi attraverso l'ip Multicast in caso di Live TV o tramite IP Unicast in caso di Video On demand. IP Multicast è un metodo in cui l'informazione viene spedita a più computer contemporaneamente. Nei sistemi standard basati su IPTV, i principali protocolli usati sono: IGMP (Internet Group Management Protocol) versione 2 per la fruizione del servizio di Live TV; grazie a tale protocollo è possibile connettersi ai canali TV e cambiare canale. Questo protocollo, infatti, è usato per gestire membri di gruppi multicast che fanno uso di Internet Protocol. IGMP è solitamente usato per gestire contenuti video e giochi online poiché permette un uso più efficiente delle risorse. RTSP (Real Time Streaming Protocol) per la gestione dei VoD. RTSP è un protocollo sviluppato da IETF e pubblicato nel 1998 come RFC 2326, viene utilizzato per sistemi che gestiscono flussi di contenuti multimediali. Tale protocollo permette a un client di controllare, da remoto, un server di contenuti multimediali, fornendogli i comandi simili ai video-registratori o ai lettori dvd come play e pause. Solo ultimamente alle tecnologie di IPTV si sono affiancati sistemi di P2P-TV, in altre parole di condivisione dei flussi audiovisivi che, attraverso dei sistemi a cascata simili a quelli di Bittorrent (protocollo peer-to-peer che consente la distribuzione e la condivisione di file su Internet), permettono di replicare i contenuti tra gli utenti e permettere a tutti di ricevere agevolmente il segnale Tecnologie alternative La televisione è diffusa agli utenti attraverso reti per telecomunicazioni che possono utilizzare metodi di trasmissione diversi in differenti tratti della rete. In base al

19 La piattaforma IPTV 19 metodo di trasmissione utilizzato nel tratto di rete che raggiunge l'utente, la televisione si distingue, infatti, in televisione terrestre se il metodo di trasmissione è un insieme di onde radio emesse da trasmettitori posti sulla superficie terrestre; in televisione satellitare se il metodo di trasmissione è un insieme di onde radio emesse da trasmettitori posti su satelliti per telecomunicazioni geostazionari; in televisione via cavo se il metodo di trasmissione utilizza un cavo per telecomunicazioni. Correntemente, quindi, le tecnologie alternative all IPTV sono: TV Satellitare: è la televisione che giunge agli utenti per mezzo di onde radio emesse da trasmettitori posti su satelliti per telecomunicazioni geostazionari. La televisione satellitare, similmente alla televisione terrestre e diversamente dalla televisione via cavo, offre una copertura continua delle aree geografiche servite. Ciò significa che è ricevibile in un qualsiasi punto delle aree geografiche servite quindi anche in movimento all'interno di tali aree. Necessita forzatamente però, diversamente dalla televisione terrestre, di un'antenna di ingenti dimensioni, tali per cui non è possibile ricevere la televisione satellitare con televisori palmari. Esistono invece antenne particolari per la televisione satellitare specifiche per i mezzi mobili (automobili, pulman, barche, etc.). Difficilmente però sono usate con le automobili in quanto l'antenna necessaria solitamente non ha dimensioni inferiori ai 50 centimetri quadrati, quindi piuttosto ingombrante per un'automobile. Mentre la televisione terrestre e la televisione via cavo servono quasi sempre aree geografiche non eccedenti le nazioni, la televisione satellitare normalmente serve invece aree geografiche continentali. Con la televisione satellitare è possibile quindi ricevere molte televisioni di altre nazioni. A differenza della televisione terrestre però, tra l'antenna e il trasmettitore, non ci deve essere alcun tipo di ostacolo. Non è possibile quindi ricevere la televisione satellitare posizionando l'antenna all'interno di edifici come è possibile invece fare con la televisione terrestre. L'antenna necessaria per ricevere la televisione satellitare è chiamata antenna parabolica. La grandezza dell'antenna parabolica dipende dalla potenza del satellite puntato e dalla posizione geografica di ricezione. Per ricevere la televisione satellitare è necessario disporre di un televisore compatibile con gli standard televisivi delle televisioni satellitari che si vuole ricevere. Per quanto riguarda l'italia non sono molti i modelli di televisori compatibili con la televisione satellitare perché normalmente sono compatibili con la sola televisione terrestre. In alternativa sono disponibili set-top box contenenti l'elettronica per la compatibilità con tali standard. La televisione digitale satellitare è stata la prima televisione digitale a diffondersi in Italia, anche grazie all'avvento di grandi fornitori di televisione a pagamento come Tele + e Stream prima, e dal 2003 la sola SKY Italia. Oltre alle tv a pagamento (pay TV) si sono diffuse rapidamente un gran numero di

20 La piattaforma IPTV 20 emittenti gratuite, soprattutto tv locali e di televendita, ma anche tutte le principali emittenti nazionali e internazionali. TV digitale Terrestre: detta anche over-on-air, OTA o broadcast television, era il metodo tradizionale di trasmissione televisiva prima dell avvento del cavo della tv satellitare. In alcune regioni è largamente usato mentre in altre meno, questo sistema si basa sulla trasmissione di onde radio, solitamente non criptate (da quì deriva infatti il termine free-on-air television). Il digitale terrestre (anche noto con l'acronimo DTT, dall'inglese Digital Terrestrial Television) è una tecnologia che permette di ricevere sul televisore di casa trasmissioni televisive del livello qualitativo e prestazionale della TV satellitare, senza però dover ricorrere all'installazione dell'antenna parabolica, ma utilizzando l'impianto ricevente preesistente, affiancato da un decoder. In Europa è implementato impiegando gli standard definiti dal consorzio DVB, racchiusi sotto la denominazione DVB-T (Digital Video Broadcasting -Terrestrial). Tv via cavo: è la televisione che raggiunge gli utenti per mezzo di un cavo per le telecomunicazioni. Il limite principale della televisione via cavo è l'alto costo della cablatura e la necessità che sia pianificata a livello collettivo. In concreto può quindi nascere solo nell'ambito di un sistema di mezzi di telecomunicazioni (telefono, internet a banda larga, televisione) che giustifichi l'ampiezza degli investimenti Vantaggi di IPTV La piattaforma basata su IP offre significanti vantaggi, inclusa l abilità di integrare la televisione con altri servizi IP-based con accesso ad Internet ad alta velocità e VoIP. In una tipica rete TV o satellite, tutti i contenuti fluiscono costantemente verso ogni utente, e l utente cambia i contenuti sul set-up box. L utente può scegliere tra il materiale messo a disposizione dalla compagnia che fornisce il servizio, ma in ogni caso i contenuti fluiscono dentro casa dell utente anche se l utente non ne ha fatto esplicita richiesta. Una rete IP invece funziona diversamente. I contenuti rimangono nella rete, e solo quelli selezionati dall utente sono inviati in casa. Questo fa sì che la banda rimanga libera quando l utente non richiede il servizio. Si elencheranno, di seguito, i principali vantaggi: Interattività Una piattaforma basata su IP permette anche significative opportunità per rendere la TV un esperienza più interattiva e personalizzata. I fornitori del servizio potrebbero, per esempio, includere un EPG (Electronic Program Guide) guida ai programmi interattiva che permette agli spettatori di cercare contenuti per mezzo del titolo o del nome di un

21 La piattaforma IPTV 21 attore, di usufruire delle funzionalità così dette picture-in-picture che permette di cambiare canale senza lasciare il programma che si sta guardando. Gli spettatori, inoltre, potrebbero essere abilitati a trovare informazioni sullo stato dei giocatori mentre guardano una partita di calcio; oppure potrebbero essere in grado di accedere a foto o musica dal loro PC direttamente sulla televisione, o anche usare un telefono wireless per schedulare la registrazione del loro programma preferito o monitorare e controllare quali programmi vedere essendo fuori di casa, ad esempio con lo scopo di indurre i figli a vedere un documentario. VoD La possibilità di fruizione del servizio Video On Demand, la cui trattazione verrà approfondita nei successivi paragrafi. Compressione migliore IPTV usa uno standard di compressione più efficiente rispetto alla televisione digitale Free-to-Air. Per televisione Free-To-Air si intende la televisione che viene trasmessa senza appropriati sistemi di crittazione, per cui è possibile intercettare i contenuti che vengono mandati in onda con determinati ricevitori. Di solito quando si usa questo termine, si fa riferimento alla tv via satellite. Triple play Tradizionalmente la fruizione dei servizi di televisione, telefonia e Internet è garantita grazie alla sottoscrizione di contratti a tre diversi operatori. Attualmente gli operatori si stanno organizzando per iniziare a offrire tutti e tre i servizi su un unico filo. Convergenza di servizi Un altro vantaggio di una rete basata su IPTV è l opportunità d integrazione e convergenza. La convergenza di servizi implica l integrazione di servizi esistenti in modo tale da creare un nuovo servizio. Servizi basati su IP permettono di fornire ai consumatori l accesso ai contenuti in ogni momento e in ogni luogo attraverso la televisione, il pc e il telefono cellulare e d integrare servizi e contenuti per raggrupparli. IPTV elimina la necessità di un infrastruttura parallela per consegnare i servizi video live e non Limitazioni di IPTV IPTV, essendo basata su un protocollo IP, è sensibile alla perdita di pacchetti e ai ritardi se la connessione non è abbastanza veloce. Attualmente la maggior parte dei sistemi IPTV non hanno il supporto per HDTV (High Definition Television) che è un sistema di trasmissione televisiva con un

22 La piattaforma IPTV 22 alta risoluzione rispetto ai formati tradizionali, mentre altre televisioni digitali come DVB forniscono anche questo servizio. La tecnologia televisiva dell IPTV è in grado di fornire servizi come Video on demand, Pay-per-view e Live TV, tali servizi verranno descritti di seguito. 1.4 Live TV La live TV è il servizio che più assomiglia a quello della normale TV, infatti, con esso si intende la trasmissione in televisione di eventi e performance con un ritardo compreso tra zero e 15 secondi. Sono presenti diversi canali che corrispondo generalmente a diversi indirizzi multicast. Un utente, per visualizzare un certo canale, effettua la join al gruppo multicast corrispondente ed inizia così a ricevere i pacchetti relativi. L applicazione o il dispositivo utente attenderà quindi di ottenere il primo group of picture e inizierà la decodifica. Figura 5 Rete multicast: join di un nuovo utente I contenuti sono erogati a prescindere dal numero di utenti collegati al canale (al limite nessuno) e, se non vengono in qualche modo memorizzati, sono disponibili solo al momento dell erogazione stessa. 1.5 Pay-per-view Un video Pay-per-view (PPV) è un particolare contenuto presente su un canale live che è visualizzabile solo a pagamento. Al limite il contenuto può essere il canale stesso: in questo caso si parla di canale a pagamento. Classici esempi di contenuti pay-per-view sono una partita di calcio, un concerto, l anteprima di un nuovo film.

23 La piattaforma IPTV 23 L unica differenza tecnica da un normale canale live è nella gestione dei diritti di visualizzazione: mentre un canale free potrebbe essere erogato senza alcun tipo di protezione, per un contenuto a pagamento è necessario proteggere i contenuti dalla visualizzazione non autorizzata. A differenza della tecnologia Video on Demand, l'evento è trasmesso in maniera unitaria a tutti i sottoscrittori nello stesso momento. Per questo motivo la tecnologia PPV viene adotta per eventi in diretta. 1.6 Video on demand Il Video On Demand (VOD) è un servizio interattivo che permette di fruire, a pagamento o anche gratuitamente (finanziandosi ad esempio con la pubblicità), di un programma televisivo (documentario, serie TV, concerto, film, partita di calcio, etc.) in qualsiasi istante della giornata su richiesta dell'utente. Tale servizio può essere paragonato ad una sorta di video noleggio. Il video on demand rappresenta un vero e proprio stravolgimento del concetto stesso di televisione la quale è nata ed è diffusa prevalentemente tutt'oggi come fruizione di programmi televisivi senza possibilità immediata per l'utente di richiedere un specifico programma televisivo. Prima dell'avvento del video on demand, il palinsesto era stabilito dal provider televisivo e l'utente aveva solo la possibilità di scegliere tra i vari programmi televisivi messi a disposizione contemporaneamente dai vari provider televisivi. Con il video on demand è invece l'utente che definisce il palinsesto secondo i propri desideri e le proprie necessità, e non il provider televisivo come di norma. Le uniche limitazioni sono date dalla varietà dei programmi televisivi tra cui poter scegliere, cioè dalla ricchezza degli archivi dei programmi televisivi messi a disposizione dai provider televisivi. I gestori di IPTV mettono generalmente a disposizione un catalogo di contenuti, ad esempio film, video musicali o registrazioni di eventi sportivi, che possono essere visualizzati dal cliente su richiesta. Proprio per la sua caratteristica peculiare (quella di essere on demand ), un VoD non può essere erogato in multicast e necessita quindi di una comunicazione point to point tra un server che contiene il video e l utente. Inoltre il canale di trasmissione dei contenuti richiesti deve essere sufficientemente ampio per trasportare un segnale televisivo con qualità accettabile. I prodotti che permettono l erogazione di video on demand possono prevedere, per evitare di congestionare la rete, la presenza di local offices (in figura Video Hub Offices).

24 La piattaforma IPTV 24 Figura 6 Scalare per milioni di utenti La localizzazione dei contenuti può anche essere vantaggiosa per altri aspetti: si potrebbe ad esempio distribuire contenuti in una certa lingua dove ci sia una forte presenza di utenti di una particolare cultura (si pensi ad esempio ai quartieri di New York). Le modalità di trasmissione dati all'utente possono essere: Streaming: il device dell'utente riceve e decodifica i dati in tempo reale (in base al bitrate occorre una connessione a banda elevata e stabile); l'utente dopo aver richiesto il programma televisivo può fruirne immediatamente. Download Streaming: il device dell'utente inizia a decodificare i dati dopo che una parte è stata ricevuta; l'utente dopo aver richiesto il programma televisivo per fruirne deve attendere di riceverne una parte. Download: il device dell'utente inizia a decodificare i dati dopo che tutti sono stati ricevuti. L'utente dopo aver richiesto il programma televisivo per fruirne deve attendere di riceverlo tutto. In Italia il video on demand è fornito da TV di FASTWEB (via fibra ottica e ADSL) e da Alice Home TV (via ADSL), entrambi in tecnologia IPTV. 1.7 Applicazioni L utilizzo del protocollo IP e delle infrastrutture esistenti, sebbene potenziate, comporta un altro vantaggio nella TV: l interattività. I servizi applicativi spaziano dalla visualizzazione dello stato della propria bolletta telefonica alla possibilità di costruire il proprio telegiornale con le notizie d interesse, ai giochi on-line e alla possibilità di selezionare da quale angolazione vedere un azione in una partita di calcio. Per le applicazioni sono proposte dal mercato due soluzioni:

25 La piattaforma IPTV 25 Thick client: è possibile installare sul dispositivo di ricezione applicazioni anche complicate in grado di comunicare con appositi servizi. Thin client: la logica applicativa è localizzata su un server. Sul set top box (o comunque il dispositivo di ricezione) è mantenuta solo un interfaccia general purpose (come un browser).

26 IPTV Edition: implementazione Microsoft di IPTV 26 2 IPTV Edition: implementazione Microsoft di IPTV L analisi sulle tecnologie IPTV prosegue illustrando il prodotto realizzato da Microsoft per la fruizione di contenuti televisivi. Microsoft TV IPTV Edition (IPTV Edition) permette la consegna di live TV e video on demand sotto diverse infrastrutture di rete. È una piattaforma robusta che abilita i service provider a offrire servizi TV ai sottoscrittori come applicazioni RDP (Remote Desktop Protocol), EPG (Electronic Program Guide) e digital video recorder (DVR). In primis sarà analizzato il processo generale, per una qualsiasi architettura IPTV, che i contenuti devono seguire per essere forniti al cliente. Questo processo comprende una serie di passaggi affidati a vari sottosistemi con compiti specifici e coesi che fanno parte dell architettura generale di un sistema IPTV. Definita l architettura generale è possibile passare all analisi dell architettura di IPTVe in particolare all analisi dei sottosistemi di VoD e Live TV. 2.1 Flusso dei contenuti video Le linee guida per cercare un architettura comune per tutti i servizi di IPTV possono essere identificate analizzando il processo che i contenuti devono seguire. Figura 7 Processo per la distribuzione dei contenuti Prendendo come riferimento il flusso schematizzato in Figura 7, di seguito si descrivono brevemente tutti gli stadi. Raramente le aziende di telecomunicazioni (principali fornitori di servizi IPTV) creano autonomamente i contenuti che trasmettono, la fase di content creation si concretizza generalmente con l acquisizione degli stream da satellite o via cavo e la transcodifica di questi in un formato più adatto alla trasmissione. La fase di content management consiste nella configurazione di come il contenuto sarà fruibile. Si definiscono a questo livello: Le caratteristiche del contenuto: classificazione in fasce di protezione (per adulti, violento, per tutti, etc.), informazioni sulla produzione e sul cast, titolo, durata e, in generale, tutto quanto andrà mostrato nella guida elettronica. Caratteristiche dello stream: indirizzo multicast sul quale trasmettere, presenza di lingue alternative, sottotitoli, etc. Logiche di business: definizione di se e come il contenuto deve essere protetto, di possibili limitazioni geografiche alla distribuzione ed eventuali altre politiche su quali clienti possano visualizzare il contenuto.

27 IPTV Edition: implementazione Microsoft di IPTV 27 Una volta definite queste politiche, i dati devono essere modificati e diversi stream possono essere accorpati in una sorta di pacchetto per la distribuzione. Durante il content packaging vengono anche cifrati i contenuti (se necessario) e codificate le informazioni sui programmi per essere disponibili attraverso l EPG (Electronic Program Guide) quando presente. Una volta preparato il pacchetto lo si distribuisce. La fase di content distribution consiste nell invio dei contenuti agli eventuali local office e nell eventuale distribuzione delle chiavi necessarie per accedere ai contenuti. In questa fase del processo può anche essere inclusa l introduzione degli stream sulle reti geografiche (WAN e/o MAN). Gli stream devono poi essere introdotti sull access network, da dove possono raggiungere le case dei clienti. È a questo livello che è importante avere router in grado di supportare multicast e controllo di flusso ovvero l access control, le modalità per garantire qualità del servizio. In ogni casa, sempre più frequentemente, sono presenti più dispositivi che possono essere collegati a Internet. Generalmente è quindi presente un dispositivo che fa da gateway per l accesso e può essere a livello di singola abitazione o di palazzo. Questi dispositivi sono detti residential gateways e sono indicati come intermediary device nello schema. Un end device può essere un set top box collegato ad una TV o un normale pc.

28 IPTV Edition: implementazione Microsoft di IPTV Architettura generale Si identificano alcuni macroblocchi comuni alle soluzioni disponibili sul mercato. Figura 8 Macroblocchi di un architettura per l IPTV. Nelle successive sezioni si cercherà di analizzare in che modo ogni sotto-sistema interviene nella fornitura del servizio. Sottosistema di acquisizione Il sottosistema di acquisizione ha la responsabilità della fase di content creation, cioè l acquisizione e la transcodifica dei contenuti. Per la live TV, l acquisizione può avvenire utilizzando hardware dedicato. Generalmente l input è analogico, mentre l output è in formato MPEG-2 o, se generato via software, compresso con uno dei codec più comuni (DivX, WM9, ecc.). I VoD, invece, vengono generalmente già forniti in formato digitale e con qualche tipo di compressione. Molte soluzioni hanno comunque bisogno di una transcodifica per passare ad una compressione compatibile con i propri servizi. Questa transcodifica spesso avviene via software. Una volta generati sono immagazzinati in storage di dati sicuri, dove attendono nuove elaborazioni. Sottosistema di elaborazione Questo sottosistema è probabilmente quello che più varia da soluzione a soluzione. Si occupa delle fasi di content management e di content packaging. I contenuti, provenienti dal sistema di acquisizione, possono essere compressi e poi cifrati in base alla configurazione fornita dall operatore e da informazioni fornite dal content provider. Dovendo comprimere grosse quantità di dati, il sistema deve utilizzare un algoritmo di cifratura simmetrica e sostituire la chiave a intervalli predefiniti di tempo. Queste chiavi devono essere mantenute sullo storage in modo da poter essere distribuite in maniera sicura ai clienti autorizzati che richiedano la visione di un canale. Il numero di chiavi varia a seconda del sistema e della configurazione: può essere utilizzata una sola chiave per tutti i canali fino ad una chiave per ogni canale. Per comodità possono essere anche creati gruppi di canali e utilizzata una chiave per ogni gruppo. Il sistema, su richiesta del client (o in qualche altra modalità),

29 IPTV Edition: implementazione Microsoft di IPTV 29 controlla il tipo di abbonamento sottoscritto ed invia le chiavi necessarie per decifrare i gruppi di canali accessibili. A differenza del sottosistema precedente, le operazioni che questo stadio deve effettuare possono essere eseguite da hardware general purpose. Sottosistema di storage Nello storage sono mantenuti tutti i dati permanenti e, spesso, anche i dati transitori per i quali sia necessaria un certo grado di affidabilità. Questo sottosistema non ha la responsabilità di una fase in particolare, ma fornisce supporto a gran parte degli altri componenti. I servizi video mantengono generalmente su database i dati riguardanti la configurazione, le chiavi di sessione, i permessi concessi agli utenti e altri dati legati ai clienti (ad esempio il limite di credito). Sottosistema di distribuzione Questo sottosistema ha la responsabilità di tre fasi: content distribution, access network e access control. Esso è costituito dai backbone, dalla rete d accesso e dagli eventuali uffici localizzati. I backbone, costituiti da cavi in fibra ottica, sono ridondati con diverse modalità. I contenuti on-demand possono essere distribuiti negli uffici localizzati, più vicini ai clienti, per ridurre il traffico di rete. I local office, essendo il front-end in comunicazione diretta con i clienti, devono essere replicati per garantire centinaia di comunicazioni contemporanee; essi possono essere quindi sovradimensionati per garantire anche una buona tolleranza ai guasti. Sottosistema di ricezione e visualizzazione Questo sottosistema è costituito dai dispositivi di rete residenziali e dai set-top-box o computer che ricevono il segnale TV.

30 IPTV Edition: implementazione Microsoft di IPTV Architettura IPTVe L architettura di IPTVe segue essenzialmente lo schema illustrato in precedenza nella Figura 8. L architettura è costituita essenzialmente da tre macro-componenti: client, branches e backend, come mostrato nella figura sottostante. Branch A DServers Applications Subscribers in location A Super Headend Office Main live acquisition group VOD creation VOD distribution Branch B DServers Applications Subscribers in location B VOD distribution Local channels acquisition Backend Branches Clients Figura 9 Architettura a tre livelli di MS IPTV Nel backend sono collocati i sottosistemi d acquisizione ed elaborazione, mentre nei branch si trova il sistema di distribuzione, infrastrutture di rete escluse. Nei branch, per motivi d efficienza, è possibile collocare anche un sistema d acquisizione adibito, ad esempio, all acquisizione dei canali locali. Come si è visto nel paragrafo 1.3, i macro servizi erogati da un sistema di IPTV sono essenzialmente tre: contenuti live (PPV se a pagamento), video-on-demand e applicazioni. Nei prossimi paragrafi saranno illustrati i sottosistemi della piattaforma adibiti a fornire questi servizi.

31 IPTV Edition: implementazione Microsoft di IPTV Live TV Il sottosistema Live TV è responsabile di acquisire servizi Live TV da varie sorgenti, processare il contenuto dei servizi, e distribuirli ai client IPTVe. Il sottosistema oltre a gestire i contenuti Live processa anche i contenuti PPV, per il fatto che, come spiegato in precedenza, essi non sono altro che servizi live a pagamento. Il sottosistema si basa su un modello che separa backend e branch, in modo tale che ogni branch richiede e distribuisce un sottoinsieme di servizi resi disponibili dal backend. Tale impostazione consente agli operatori che forniscono servizi di controllare maggiormente lo stato di distribuzione dei contenuti. Infatti l operatore può controllare: Quando un servizio Live TV è disponibile. Quale gruppo di acquisizione sul backend gestisce il servizio. Quali branch distribuiscono il servizio ai client. Il sottosistema di Live TV è composto di due sottosistemi: - Sottosistema di acquisizione Live TV: Responsabile di acquisire e processare i contenuti e di produrre stream Real-Time-Protocol (RTP). Si occupa di incapsulare pacchetti multicast UDP contenenti gli stream e di consegnarli al sottosistema di distribuzione e ai client. - Sottosistema di distribuzione Live TV: Responsabile della distribuzione unicast dei servizi Live ai client IPTVe, fornendo Instant Channel Change (ICC).

32 IPTV Edition: implementazione Microsoft di IPTV Flusso funzionale La Figura 10 illustra il flusso funzionale di un singolo servizio Live TV dal punto di acquisizione fino alla distribuzione ai client. Figura 10 Flusso funzionale di un singolo servizio Live TV 1. IPTVe è in grado di acquisire flussi video da encoder, schede d acquisizione, da file e da una qualsiasi fonte in grado di effettuare streaming in MPEG-2. Questi flussi sono catturati da un sottosistema di acquisizione che risiede sul backend. 2. Il sistema di acquisizione invia pacchetti multicast per ogni servizio Live TV su un unico indirizzo multicast e su un unica porta. I pacchetti sono ricevuti sia dal sottosistema di delivery che dai client IPTVe. 3. Il sottosistema di distribuzione Live TV consegna gli appropriati contenuti video ai client. Esso è allocato in modo tale da essere più vicino ai client e consentire così un ottimizzazione dell utilizzo delle risorse di rete. Se il servizio live TV è nella mappa di canali del client IPTVe e il sottoscrittore ha i diritti di accesso al servizio, il client è in grado di mostrare sullo schermo il contenuto nel momento in cui il sottoscrittore seleziona l appropriato canale. Tale sottosistema è stato introdotto per evitare che il sottosistema di acquisizione si sovraccarichi. 4. Se il client avverte una perdita di pacchetti, effettua la richiesta dei pacchetti persi al sottosistema di delivery. Questo è possibile perché i client sono a

33 IPTV Edition: implementazione Microsoft di IPTV 33 conoscenza di quale branch gestisce un certo canale (quest informazione è fruibile utilizzando una semplice chiamata ad un Web Service) e può indirizzare verso esso le richieste. Nel caso di richiesta di un particolare pacchetto di uno stream, per ovvi motivi, la risposta deve essere inviata in modalità unicast al solo dispositivo che ne ha effettuato la richiesta.

34 IPTV Edition: implementazione Microsoft di IPTV Video on Demand La Figura 11 illustra i passi ad alto livello necessari per importare, pubblicare, ed effettuare il deploy di contenuti Video on Demand con un sottosistema basato su un cluster per ogni branch. Figura 11 Flusso funzionale del sottosistema di VoD I contenuti video-on-demand sono generalmente gestiti dagli stessi content provider che ne definiscono anche, per alcuni aspetti, le politiche d accesso. Durante questo processo sono definiti parametri come la risoluzione, bit rate e qualità. I contenuti sono inviati in maniera sicura (non necessariamente via rete) con meccanismi tipo Virtual private Network (VPN) dai content provider ai gestori del servizio. I contenuti sono memorizzati nel VOD Backend. Attraverso il componente VOD Creator è possibile leggere o creare i metadati relativi ad ogni contenuto in cui sono definiti prezzo, durata, descrizione e quanto necessario per definire le regole di business. Il sottosistema di acquisizione dei VOD importa e processa i contenuti memorizzati in cartelle locali. Tale sistema si occupa poi di generare gli stream di fast forward e rewind per usufruire delle funzionalità corrispondenti sul client. I contenuti sono poi cifrati e salvati in file su uno storage predefinito. Questi file così ottenuti devono essere distribuiti ad uno o più cluster. Gli operatori di branch scelgono i contenuti da consegnare al sottosistema di delivery. Successivamente i VOD cluster sono responsabili della consegna dei contenuti. Se

35 IPTV Edition: implementazione Microsoft di IPTV 35 su un branch sono presenti più VOD Cluster i VOD possono essere distribuiti in numero diverso tenendo conto delle previsioni di accesso ad un certo video e alle statistiche raccolte. I sottoscrittori comprano e poi richiedono di vedere un contenuto VOD. Ogni richiesta dei client IPTVe al sottosistema VOD è autenticata per assicurare che solo client autorizzati stiano accedendo ai contenuti VOD.

36 Architetture SOA 36 3 Architetture SOA Nei capitoli precedenti è stata fatta una descrizione dei concetti fondamentali che caratterizzano una piattaforma IPTV e di come Microsoft li ha realizzati con il sistema IPTVe. Questo sistema distribuito è stato creato implementando i concetti base delle architetture orientate ai servizi grazie all utilizzo di tecnologie che li rendono applicabili. In questo capitolo si porrà l attenzione, quindi, sulla serie di concetti, nozioni e tecniche che sono alla base delle architetture SOA. Inizialmente si darà una definizione di cosa s intende per architettura orientata ai servizi; poi saranno illustrate le caratteristiche fondamentali di questa tipologia di architetture con riferimento all astrazione, al basso accoppiamento, all autonomia, e all interoperabilità che garantiscono. In seguito è importante analizzare gli elementi che costituiscono SOA per comprendere con maggior dettaglio come si articola e come vengono scambiate le informazioni al suo interno. In particolare si focalizzerà l attenzione sul concetto di servizio, centrale nell ambito di questo capitolo. Definiti i concetti principali su cui si fondano le architetture orientate ai servizi saranno presi in considerazioni gli standard e i protocolli che rendono possibile sviluppare servizi che interoperano in ambienti distribuiti. SOAP, WSDL, e Web Service sono i tre concetti da approfondire per poter apprezzare i vantaggi di queste architetture. SOAP permette di esporre le funzionalità dei Web Service agli utenti del Web, queste funzionalità sono descritte tramite WSDL permettendo agli utenti di costruire client per accedervi. Definite le fondamenta su cui si regge l architettura dei Web Service è importante illustrare come è possibile usufruire di funzionalità aggiuntive nell interoperazione tra servizi che consentano la gestione della sicurezza o dell affidabilità. Ad assolvere questi compiti è adibita l architettura WS-* attraverso la definizione di specifiche per estendere i messaggi SOAP che consentono di soddisfare queste necessità. 3.1 Definizione Prima di definire il concetto di architettura service oriented occorre dare un definizione di quello di architettura software. La letteratura in questo campo fornisce molte definizioni differenti l una dall altra. IEEE Standard indica che "Architecture is the organizational structure of a system. ; mentre Brass, Clements, and Kazman nel libro Software Architecture in Practice dicono che "The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them." Per gli obiettivi di questo lavoro si può definire un architettura software come un insieme di asserzioni che descrivono i componenti software e assegnano le funzionalità del sistema a queste componenti. Descrive la struttura tecnica, i vincoli,

37 Architetture SOA 37 e le caratteristiche dei componenti e le interfacce di essi. L architettura è un modello per il sistema e quindi un piano ad alto livello per la sua costruzione. Identificando il concetto di architettura software si sono create le basi fondamentali per capire cosa è un architettura orientata ai servizi, anche se manca un altro concetto importante, che sarà definito più avanti, quello di servizio. Esistono molteplici definizioni di SOA ma solo il gruppo OASIS (Organization for the Advancement of Structured Information Standards) ha fornito una definizione formale applicabile sia alla tecnologia che ai domini aziendali. Secondo l OASIS reference model SOA è : A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. Traducendo un paradigma per organizzare ed utilizzare capacità distribuite che possono essere sotto il controllo di diversi domini di potere. Essa fornisce un mezzo uniforme per offrire, scoprire, interagire con e usare capacità per produrre gli effetti desiderati consistenti con le precondizioni misurabili e le aspettative. In generale, entità (persone ed organizzazioni) creano capacità per risolvere o supportare soluzioni per i problemi che incontrano nel corso delle loro attività. È naturale pensare che i bisogni di una persona possano essere soddisfatti da capacità possedute da altri, o, nel mondo dei sistemi distribuiti, le richieste di un operatore di computer possano essere soddisfatte da un altro operatore che proviene da differenti organizzazioni. Non c è necessariamente una correlazione uno ad uno tra bisogni e capacità; ogni necessità per essere soddisfatta può richiedere di combinare numerose capacità mentre ogni singola capacità può soddisfare più di un singolo bisogno. L obiettivo perseguito da SOA è fornire un potente framework per sovrapporre bisogni e capacità e combinare capacità per soddisfare necessità. SOA esprime, quindi, una prospettiva di architettura software che definisce l'uso di servizi software tra loro disaccoppiati per supportare i requisiti dei processi di business degli utenti del software. Le risorse su una rete in ambiente SOA sono rese disponibili come servizi indipendenti che possono essere acceduti senza la conoscenza della loro implementazione sottostante. Un'architettura SOA non è legata ad una specifica tecnologia. Potrebbe essere implementata usando un vasto range di tecnologie come Web Services, CORBA, RPC. SOA può essere implementata evitando di utilizzare i protocolli citati in precedenza e, per esempio, potrebbe utilizzare un meccanismo basato su file system per comunicare dati conformemente alla specifica di un'interfaccia tra processi che aderiscono ai concetti SOA. Il concetto che c'è alla base è l'indipendenza dei servizi le cui interfacce possono essere chiamate in un modo standard per fornire i loro task, senza che il servizio

38 Architetture SOA 38 abbia conoscenze sull'applicazione chiamante, e senza che l'applicazione abbia bisogno di conoscere come il servizio attualmente processi i suoi task. SOA può anche essere vista come un architettura per lo sviluppo di sistemi informativi che rende possibile la creazione di applicazioni che sono costruite combinando il basso accoppiamento e l interoperabilità tra servizi. Concetti chiave sono basso accoppiamento e interoperabilità tra i servizi. Infatti, i servizi, in un architettura SOA, interoperano basandosi su una definizione formale (o un contratto, ad esempio, WSDL spiegato più avanti) che è indipendente da una specifica piattaforma e da ogni linguaggio di programmazione. La definizione di un interfaccia nasconde l implementazione del servizio che risulta invece essere specifica del linguaggio di programmazione. I sistemi basati su architetture SOA possono, pertanto essere indipendenti dalle piattaforme e tecnologie con le quali vengono sviluppati (come Java,.NET etc.). Servizi scritti in C#, ad esempio, girano sulla piattaforma.net, mentre quelli scritti in Java girano sulla piattaforma Java Enterprise Edition; entrambi possono essere consumati da un applicazione comune che li compone. Applicazioni che girano su entrambe le piattaforme possono anche usufruire di altri servizi che girano su ancora altri tipi di piattaforme come Web Service. SOA può supportare l integrazione e il consolidamento di attività con i complessi sistemi aziendali, ma non specifica o fornisce una metodologia o un framework per documentare capacità e servizi. Linguaggi ad alto livello come BPEL e specifiche come WS-CDL e WS-Coordination estendono il concetto di servizio esponendo metodi per la definizione di servizi e fornendo orchestrazioni di servizi a grana fine fino ad arrivare a servizi di business a grana più grossa che possono essere incorporati in workflow e processi di business. 3.2 Caratteristiche fondamentali Le caratteristiche principali di un architettura SOA sono le seguenti: - Astrazione: Una delle caratteristiche che tende ad evolvere naturalmente attraverso le applicazioni sviluppate con i principi di progettazione service-oriented è l astrazione. Le tipiche architetture orientate ai servizi introducono livelli di astrazione posizionando i servizi come unici punti di accesso a una varietà di risorse, nascondendo la logica di business ai servizi consumatori. Gli unici obiettivi su cui focalizzare l attenzione rimangono essere le funzionalità offerte delle interfacce dei servizi. E l astrazione dalla logica di business e dalla tecnologia che supporta il paradigma orientato ai servizi e promuove il basso accoppiamento spiegato nella sezione successiva. - Basso accoppiamento: Un beneficio chiave dovuto alla costruzione di architetture tecniche con servizi disaccoppiati fra di loro è la risultante indipendenza della logica di essi. I servizi richiedono solo la conoscenza l uno con l altro per comunicare permettendo loro di evolvere in maniera indipendente. Facendo un passo

39 Architetture SOA 39 indietro e guardando all azienda come ad un organizzazione nella sua interezza senza considerare la suddivisione in servizi, e applicando i principi service-oriented sia al modello di business che alla progettazione tecnica, i concetti di basso accoppiamento si amplificano. Il risultato è un ambiente che si modifica in linea con i cambiamenti di business e tecnologici apportati man mano. Questo quindi porta l azienda verso un agilità organizzativa. - Interoperabilità Inizialmente un applicazione può non avere il bisogno di un immediata integrazione, però è bene agire in fase di progettazione attuando dei principi che consentano ai servizi di promuovere in maniera naturale l interoperabilità. Costruendo un applicazione SOA fin dai primi passi, i servizi con un intrinseca interoperabilità sono potenziali candidati ad essere punti d integrazione. Incoraggiare questa caratteristica può alleviare significativamente i costi e gli sforzi di soddisfare i futuri requisiti di integrazione attraverso le applicazioni. - Autonomia: Il principio di autonomia nell ottica orientata ai servizi richiede che i servizi siano il più possibile indipendenti e auto contenuti nel rispetto del controllo che devono mantenere sulla logica di business che incapsulano. L autonomia si mette in opera anche a livello di messaggi poiché quelli scambiati tra i servizi sono sufficientemente intelligenti da controllare la modalità con la quale sono processati dai servizi riceventi. SOA espande questi principi promuovendo il concetto di autonomia attraverso le soluzioni ideate. Applicazioni composte di servizi autonomi, per esempio, possono essere viste come servizi che dipendono solo da sé stessi, che esercitano il proprio controllo all interno di ambienti integrati. Cambiamenti effettuati su un servizio non devono coinvolgere nessun altro. Ogni servizio in un sistema è istallato, gestito, e cresce indipendentemente dagli altri. L incapsulamento è il concetto chiave di questo punto: un servizio dovrebbe essere pronto ad essere riscritto senza determinare effetti negativi sui suoi consumatori. Quindi l autonomia a livello di servizio richiede servizi interscambiabili e debolmente accoppiati, mentre a livello tecnologico richiede indipendenza nell implementazione. Questo significa che la topologia di un sistema può evolvere nel tempo non essendo dettata da una singola autorità. - Confini espliciti: L orientazione ai servizi è basata su un modello di esplicito scambio di messaggi e quindi l attraversamento delle barriere è un azione esplicita, perché inviando messaggi da un organizzazione all altra (anche all interno di una stessa organizzazione) si oltrepassano i confini di propria appartenenza. A livello tecnologico i servizi interagiscono passando messaggi e questo richiede che le interfacce dei servizi siano esposte in maniera tale da essere accessibili da altri servizi. Osservando la questione in una prospettiva

40 Architetture SOA 40 aziendale, è ugualmente importante capire e definire i confini dell organizzazione e delle funzioni attribuite ai vari oggetti che compongono l organizzazione per identificare chiaramente le capacità. I servizi inseriti in un architettura service oriented non devono esporre la loro implementazione. Per esempio, considerando l interoperabilità tra Java EE e.net Framework per scambiare messaggi specifici di una piattaforma occorre definire un modello intermediario. Il contratto che definisce cosa si può ricevere e cosa si può inviare deve essere definito chiaramente in uno schema. Schemi e contratti si auspica che rimangano stabili nel tempo poiché introducendo cambiamenti su di essi questi interesserebbero anche i consumatori e questo è proprio quello che si vuole evitare. 3.3 Elementi principali di SOA A questo punto è possibile descrivere SOA dal punto di vista degli elementi che la compongono. Un architettura orientata ai servizi è un architettura software che è basata sui concetti chiave di frontend dell applicazione, servizio, service repository, e service bus. L intero concetto di SOA si focalizza sulla definizione di infrastruttura di business. Quando si usa il termine servizio, si ha in mente un servizio di business come ad esempio fare una prenotazione di un volo aereo. Questi servizi forniscono operazioni del tipo get reservation o cancel reservation. A differenza dei servizi di business, i servizi di infrastruttura tecnica, come ad esempio il servizio di persistenza o transazionale, forniscono operazioni tipo begin transaction, update data. Sebbene questo tipo di funzionalità tecniche sono molto utili quando si vogliono implementare delle operazioni di business è poco rilevante porre l attenzione su questo tipo di funzionalità dal punto di vista SOA. Più in generale la tecnologia non deve avere un grosso impatto sulla struttura ad alto livello di un applicazione o causare dipendenze tra le componenti. Attualmente, SOA deve disaccoppiare le applicazioni di business dai servizi tecnici e costruire aziende indipendenti da una specifica implementazione tecnica o da un infrastruttura. I frontend dell applicazione sono gli elementi attivi di SOA, quegli elementi che fanno scoprire il valore di SOA agli utenti finali. Tuttavia occorre tenere sempre presente che i servizi identificano la struttura di SOA. Sebbene questi possano spesso rimanere inalterati, i frontend delle applicazioni sono soggetti a cambiamenti, come lo sono i processi di business delle aziende. Conseguentemente, il ciclo di vita di un frontend per un applicazione è più breve rispetto a quello dei servizi che lo compongono. Ecco perché si guarda ai servizi come ad entità primarie di strategica importanza in un architettura service oriented.

41 Architetture SOA 41 Figura 12 I cicli di vita stimati di dati, servizi, frontend, e tecnologia sono differenti Frontend dell applicazione I frontend delle applicazioni sono i giocatori attivi di un architettura SOA. Inizializzano e controllano tutte le attività di un sistema. Ce ne sono di diversi tipi, come ad esempio un frontend con un interfaccia grafica, un applicazione Web o un client che interagisce direttamente con l utente finale, sebbene non tutte le applicazioni di frontend necessariamente interagiscano direttamente con l utente finale. Altri esempi sono programmi batch o processi long-living che invocano funzionalità periodicamente o come risultato di uno specifico evento. Tuttavia, è possibile che un frontend di un applicazione deleghi la maggior parte delle sue responsabilità per un processo di business ad uno o più servizi. In sostanza però è sempre un frontend che inizia un processo di business e riceve i risultati. I frontend delle applicazioni sono simili ai livelli più alti delle tradizionali applicazioni multilivello. Ci si potrebbe aspettare, di conseguenza, che i servizi ricoprano allora i livelli più bassi ma in realtà non è così. Nei successivi paragrafi si dimostrerà come i servizi hanno una struttura differente, che è caratterizzata da una suddivisione verticale Servizi Un servizio è un componente software che ricopre delle funzionalità distintive che tipicamente incapsula un concetto di business ad alto livello. E composto di diverse parti. - Contratto: Il contratto del servizio fornisce una specifica informale dell obiettivo, delle funzionalità, dei vincoli, e dell uso del servizio. La forma di questa specifica può variare, in dipendenza dal tipo di servizio. Un elemento non obbligatorio del contratto di un servizio è la definizione di un interfaccia formale basata su un linguaggio come IDL (usato in ambienti CORBA) o

42 Architetture SOA 42 WSDL (usato per la definizione di Web Service). Sebbene non sia obbligatoria, una definizione formale dell interfaccia del servizio aggiunge un beneficio significativo. Fornisce un ulteriore astrazione e indipendenza dalla tecnologia, includendo linguaggio di programmazione, middleware, protocollo di comunicazione, e ambiente di sviluppo. Nonostante questo è importante capire che un contratto per un servizio fornisce più informazioni che una semplice specifica formale. Il contratto può imporre una semantica dettagliata sulle funzionalità e i parametri che non possono essere specificate con IDL o WSDL. In realtà, molti progetti devono fare i conti con servizi che non forniscono una descrizione formale dell interfaccia. In questi casi, il servizio deve permettere accesso alle librerie o una descrizione tecnica molto dettagliata. - Interfaccia: Le funzionalità del servizio sono esposte dall interfaccia ai client che sono connessi al servizio tramite la rete. Sebbene la descrizione dell interfaccia è parte del contratto, l implementazione fisica dell interfaccia consiste di service stub, che sono incorporati nei client (che possono essere le applicazioni di frontend o altri servizi). - Implementazione: L implementazione del servizio fisicamente fornisce la logica di business richiesta e i dati appropriati. E la realizzazione tecnica che soddisfa il contratto dei servizi. L implementazione del servizio consiste in uno o più artefatti come programmi, dati di configurazione,e database. - Logica di business: La logica di business che è incapsulata da un servizio è parte della sua implementazione. E resa disponibile attraverso le interfacce. - Data: Un servizio può anche includere dati. Figura 13 Servizio

43 Architetture SOA 43 Come si vede nella Figura 13, i servizi non sono solo l incapsulamento di codice del primo strato più basso delle applicazioni. I servizi impongono una suddivisione verticale dell applicazione che definisce una struttura a grana grossa dell intero sistema, similmente alla progettazione del software orientata ai componenti. Mentre, dalla prospettiva del client, un servizio è un entità a scatola nera. E interessante porre una particolare attenzione nei confronti del concetto di servizio perché è alla base del concetto di SOA. Incapsulamento logica applicativa Risulta determinante capire questo concetto per la comprensione dell intero lavoro. Un servizio per mantenere la sua indipendenza incapsula la logica in differenti contesti. L interesse affrontato dal servizio può essere di piccole o grandi dimensioni. Oltre alle dimensioni delle funzionalità ricoperte da un servizio possono variare anche i contesti nei quali tali interessi si applicano. Per esempio, prendendo in considerazione una soluzione di automazione di un processo di business, questo è espresso tramite la logica che dice quali sono le azioni da eseguire per fornire la soluzione. La logica è decomposta in una serie di passi che eseguiti in un ordine stabilito, seguendo una serie di regole, forniscono il risultato desiderato. Come mostrato in Figura 14, quando si costruisce una soluzione consistente di servizi, ogni servizio incapsula un task fornito da un passo individuale o da un sotto processo compreso all interno dell insieme di passi da compiere. Figura 14 Un servizio può incapsulare vari tipi di logica Collegamento e comunicazione tra i servizi

44 Architetture SOA 44 Grazie a SOA i servizi possono essere usati da altri servizi o altri programmi. La relazione tra servizi è basata sulla consapevolezza che un servizio per interagire con un altro deve conoscerlo. Questa conoscenza tra i partecipanti è raggiunta tramite l utilizzo di una descrizione di essi. Tale descrizione è la forma più semplice che stabilisce il nome, i dati che si aspetta e quelli ritornati. Nella Figura 15 è illustrato come un servizio A è disponibile per un servizio B perché A è in possesso della descrizione di B. Figura 15 Comunicazione tra servizi in una SOA Dopo che i servizi si sono inviati messaggi in questo modo, lasciano il controllo di cosa successe all interno del servizio invocato in base a ciò che c è scritto sul messaggio inviato. I servizi che forniscono descrizione delle loro operazioni e comunicano tramite messaggi formano un architettura base. Quest architettura appare simile alle passate architetture distribuite che supportano messaging e separazione di interfacce dalla logica applicativa. Quella presa in esame si distingue nella progettazione delle sue tre componenti servizio, descrizione e messaggio. E qui che emerge il concetto di service orientation Service repository Un service repository fornisce delle facilitazioni per individuare i servizi e acquisire tutte le informazioni per usarli, particolarmente se questi devono essere rintracciati al di fuori del raggio temporale e funzionale del progetto che li ha creati. Sebbene la maggior parte delle informazioni è già parte del contratto del servizio, il service repository deve fornire informazioni aggiuntive, come ad esempio la locazione fisica, informazioni riguardo il provider, contatti personali, vincoli tecnici, caratteristiche di sicurezza, e disponibilità a livello di servizio. Ovviamente, un service repository, è un elemento utile di SOA. Tuttavia si può costruire un architettura orientata ai servizi e realizzare molti di questi benefici senza utilizzare un repository di servizi, questo diventa indispensabile a lungo termine. Se lo scopo di un servizio è quello di essere inserito solo in un progetto, o se il progetto ha pochi servizi, allora l architettura può fare a meno del repository. In realtà, nonostante, la maggior parte degli scenari aziendali sono caratterizzati da molti progetti concorrenti, e da una varietà di servizi.

45 Architetture SOA 45 Un repository di servizi può essere arbitrariamente semplice; ad un estremo potrebbe non richiedere alcuna tecnologia. Un programma batch di un servizio di stampa in un ufficio e accessibile da tutti i progetti è un valido esempio di service repository. Sebbene esistano modi migliori per fornire queste informazioni rinunciando alla semplicità. Spesso, si trovano dei database proprietari che contengono dati amministrativi formalizzati e contratti di servizi più o meno formali per ogni versione di un servizio. In alcuni casi, le compagnie sviluppano i loro strumenti che automaticamente generano la descrizione del servizio dalla definizione formale (per esempio, un generatore HTML che prende in input un WSDL, simile ad un generatore JavaDOC). Questo è particolarmente utile se la definizione formale del servizio è corredata da informazioni aggiuntive riguardo il servizio. Si noti che queste informazioni sono spesso molto differenti dalle meta-informazioni fornite per le API, come le classi Java. Questo è dovuto al ruolo diverso che gioca la definizione del servizio in SOA. I servizi, tipicamente, sono più a grana grossa, auto contenuti, e capaci di supportare differenti pattern di utilizzo. In particolare, i servizi, di solito, non sono linkati in librerie di codice ma sono collegati a runtime. Di seguito saranno illustrate le informazioni che potrebbero essere contenute in un service repository: Servizio, operazioni, segnature e parametri, nella forma di specifiche WSDL e definizioni di XML Schema. Proprietario del servizio. In un azienda i proprietari possono operare a livello di business (responsabili di questioni e richieste di cambiamenti sul livello funzionale), a livello di sviluppo, e a livello operazionale. Diritti di accesso, come informazioni riguardo alla lista di controllo degli accessi e ai meccanismi di sicurezza. Informazioni riguardo i parametri di performance e scalabilità del servizio, inclusi i tempi medi di risposta, e potenziali limitazioni sul throughput. Questi possono essere riassunti come parte di un generico SLA (Service Level Agreement). Proprietà transazionali del servizio e delle sue operazioni individuali Modelli d integrazione: Service Bus e Enterprise Application Integration In ambienti di business sempre più competitivi e dinamici l integrazione tra applicazioni conviventi nella stessa azienda ma diverse per obiettivi e tecnologie è diventata un esigenza sempre più pressante. Una sfida delle moderne organizzazioni consiste nel fornire ai loro lavoratori un accesso alle informazioni che sia in tempo reale, completo, e trasparente. Molte applicazioni ancora in uso oggi sono sviluppate usando tecnologie proprietarie e obsolete. Questi sistemi non facilitano la mobilità dell informazione da un applicazione all altra.

46 Architetture SOA 46 Esistono diversi approcci per integrare applicazioni di natura eterogenea in ambienti distribuiti, si prenderanno in esame di seguito sia l approccio SOA tramite l uso di un service bus che l approccio EAI. Enterprise Application Integration (EAI) cerca di alleviare questi problemi creando nuovi paradigmi per supportare le organizzazioni. EAI cerca di trascendere dal semplice obiettivo di collegare le applicazioni, spostandosi verso la riscoperta di nuovi e innovativi modi di usare le conoscenze relative all organizzazione per creare vantaggi alle imprese. Con un utilizzo appropriato dell architettura EAI, le organizzazioni si possono concentrare maggiormente sui loro obiettivi e sulla creazione di valore aggiunto piuttosto che sulla gestione del flusso di informazioni. EAI può essere usato per molteplici scopi: Integrazione di dati: assicurando la consistenza delle informazioni in sistemi multipli. Integrazione di processi: collegando processi di business attraverso le applicazioni. Indipendenza dei commercianti: estraendo politiche di business o regole da applicazioni e implementandole in sistemi EAI, così che anche se un applicazione di business è replicata con un applicazione di un altro fornitore, le regole di business non devono essere re implementate. Interfaccia unica: Un sistema EAI potrebbe avere la funzione di front-end di un cluster di applicazioni, fornendo un'unica interfaccia di accesso a queste applicazioni e evitando agli utenti di interagire con diverse applicazioni. Attualmente, ci sono diverse approcci di pensiero riguardo a quale sia la migliore infrastruttura, il migliore modello, e la migliore struttura standard di EAI. Tuttavia ci sono quattro elementi che sono riconosciuti essenziali nei diversi approcci per un architettura delle moderne applicazioni aziendali: 1. La necessità di avere un broker centralizzato che gestisce sicurezza, accesso, e comunicazione. Questo può essere realizzato attraverso dei server di integrazione. 2. Uso di un modello indipendente di dati basato su strutture dati standard. Sembra che XML sia diventato lo standard per ricoprire questa necessità. 3. Un connettore, un agente, un modello in cui ogni applicazione, o interfaccia possa costruire un singolo componente che dialoghi e comunichi con il broker centralizzato. 4. Un modello di sistema che definisce le API, il flusso di dati e le regole di partecipazione al sistema così che i componenti possano costruire interfacce standard. Un modello diverso di integrazione è quello proposto dall Enterprise Service Bus (ESB).

47 Architetture SOA 47 Questo approccio è in contrasto con l approccio centralizzato di EAI che vede al centro dell integrazione un broker che gestisce l interazione tra le applicazioni. ESB è descritto come un infrastruttura distribuita, come mostrato in Figura 16, in opposizione alle tecnologie broker, ispirate al modello hub-and-spoke. Soluzioni ispirate a questo modello centralizzano il controllo in unico elemento: informazioni di routing, nomi dei servizi, ed altre funzioni, come mostrato in Figura 17. Figura 16 Infrastruttura fisica di ESB Figura 17 Integrazione basata sul modello Hub-and-Spoke Nei pattern per l integrazione dei processi di e-business un ESB, è però classificato a volte come un tipo di bus, a volte come un tipo di hub. In pratica un hub potrebbe essere fisicamente distribuito su un insieme di hub connessi tra di loro così da produrre una variante descritta come un bus, come illustrato in Figura 18. Questa variante deve essere usata con degli adattatori che connettono i client con i protocolli e gli standard per il formato dei messaggi che sono in uso sul bus.

48 Architetture SOA 48 Figura 18 Variante di Hub: Bus La distinzione tra bus distribuito e hub-and-spoke centralizzato non è completamente esatta, infatti, si parla di centralizzazione del controllo e di distribuzione dell infrastruttura. All inizio o nel caso di implementazioni su piccola scala di soluzioni integrate, la struttura fisica può essere centralizzata, concentrata su un singolo cluster, o un hub. Tuttavia, nel momento in cui l applicazione evolve, l infrastruttura deve diventare fisicamente distribuita, come un bus, lasciando solo la centralizzazione del controllo. La relazione tra hub, bus, e ESB è mostrata nella figura sottostante. Hub: fornisce servizi di integrazione centralizzati da un punto di vista logico. Bus: un Hub che supporta un implementazione distribuita. ESB: Bus a livello Enterprise, utilizzato per la gestione della connessione tra tutti i servizi di un azienda.

49 Architetture SOA 49 Figura 19 L'ESB come infrastruttura distribuita con controllo centralizzato Compresa la differenza tra l approccio di EAI e quello di ESB, è utile contestualizzare l ESB nell ambito delle architetture orientate ai servizi. Per implementare un architettura orientata ai servizi, sia le applicazioni che l infrastruttura devono supportare i principi SOA. In pratica, ESB permette di implementare SOA fornendo l infrastruttura necessaria per garantire le capacità basilari di istradamento dei messaggi e trasporto delle richieste verso i corretti service provider. In questo contesto vediamo la centralità del concetto di Enterprise Service Bus sia nella definizione di modelli di integrazione sia nell ambito delle architetture orientate ai servizi. Nel prossimo capitolo saranno illustrate le tecnologie utilizzate nell ambito del progetto, tra di esse c è Connected Services Framework (CSF) che non è altro che un implementazione del modello Enterprise Service Bus per la realizzazione di architetture SOA. Uno strumento che si fonda sull applicazione dell approccio opposto di integrazione EAI è rappresentato da BizTalk Server. Occorre chiarire alcuni aspetti riguardo al service bus delineandone alcune caratteristiche basilari per facilitarne la comprensione. Un service bus connette tutti i partecipanti di un architettura orientata ai servizi. Se due partecipanti hanno bisogno di comunicare, per esempio, se un applicazione frontend ha bisogno di invocare alcune funzionalità di un servizio base questo è reso possibile tramite l utilizzo del service bus. Da questo punto di vista, il service bus è simile al concetto di software bus come è definito nel contesto di CORBA. Sebbene, differenze significative esistono tra i due concetti. Il service bus non è necessariamente composto da una singola tecnologia, ma piuttosto comprende una varietà di prodotti e concetti. E interessante sottolineare le seguenti caratteristiche: Connettività

50 Architetture SOA 50 Il primario obiettivo del service bus è interconnettere i partecipanti di una architettura SOA. Permette ai partecipanti di un architettura orientata ai servizi di invocare le funzionalità di tutti i servizi coinvolti. Eterogeneità di tecnologie Il service bus deve abbracciare una varietà di tecnologie differenti. La realtà di un azienda è caratterizzata da eterogeneità delle tecnologie. Conseguentemente, il service bus deve essere capace di connettere partecipanti che sono basati su diversi linguaggi di programmazione, sistemi operativi, o ambienti di sviluppo. Infatti, molto spesso all interno di un azienda cooperano diversi prodotti di middleware e protocolli di comunicazione, e tutti questi devono essere supportati dal service bus. Eterogeneità di modelli di comunicazione Similmente all eterogeneità di tecnologie, il service bus deve anche abbracciare una varietà di diversi concetti di comunicazione. Per la divergenza dei requisiti di differenti applicazioni, il service bus deve abilitare differenti modalità comunicative. Ovviamente deve quanto meno fornire le funzionalità base di comunicazione sincrona e asincrona come mostrato in Figura 20. Servizi tecnici Sebbene l obiettivo primario del service bus è la comunicazione, esso può in aggiunta fornire servizi come il logging, auditing, gestione della sicurezza, trasformazione dei messaggi, transazioni. Figura 20 Service bus fornisce vari modelli di comunicazione

51 Architetture SOA Standard per architetture SOA Riprendendo la distinzione fatta nel paragrafo un servizio in un architettura orientata ai servizi incapsula logica applicativa, si relaziona e si collega con gli altri partecipanti ed infine comunica con essi. Nella Figura 21 è mostrato come questi concetti sono mappati in relazione agli standard e protocolli utilizzati. Fondamenti SOA Come i servizi incapsulano logica applicativa Come si collegano Protocolli Service (Web service) Descrizione servizio (WSDL) Come comunicano Messaging (SOAP) Figura 21 Relazione tra fondamenti SOA e protocolli Nei prossimi tre paragrafi saranno descritti in maggior dettaglio gli standard mostrati nel lato destro della figura Web Services Negli ultimi anni, l imperativo di connettere persone, informazioni, e processi ha cambiato il modo di usare il software da sviluppare. Il successo dei sistemi di information technology richiede sempre di più interoperabilità tra le piattaforme e flessibilità dei servizi che possono facilmente evolvere nel tempo. Questo ha portato verso la prevalenza di XML come linguaggio universale per rappresentare e trasmettere dati strutturati indipendenti dai linguaggi di programmazione, dalle piattaforme software, e dall hardware. Costruiti sulla vasta accettazione di XML, i WS sono applicazioni che usano standard per il trasporto, la codifica delle informazioni e protocolli per lo scambio di informazioni. Con il vasto supporto fornito dai venditori, i WS abilitano i sistemi su ogni piattaforma a comunicare attraverso intranet aziendali, extranet, e attraverso Internet con il supporto per la sicurezza end-to-end, garantendo l affidabilità dei messaggi, rendendo disponibile la possibilità di fare transazioni distribuite, e altro. I Web Service sono basati su un insieme di standard che descrivono la sintassi e la semantica della comunicazione tra software: XML fornisce la sintassi comune per la rappresentazione dei dati; il Simple

52 Architetture SOA 52 Object Access Protocol (SOAP) fornisce la semantica per lo scambio di dati; e il Web Service Description Language (WSDL) fornisce un meccanismo per descrivere le capacità di un WS. Specifiche addizionali collettivamente denominate con il nome di architettura WS-*, definiscono funzionalità per la ricerca di WS, per la gestione degli eventi, allegati, sicurezza, affidabilità, transazioni. Esistono molteplici definizioni di XML Web Service, ma tutte queste hanno in comune tre fattori: I WS espongono funzionalità utili agli utenti del Web attraverso protocolli standard del Web. In molti casi, il protocollo usato è SOAP. I Web Service forniscono un modo di descrivere le loro interfacce abbastanza dettagliato da permettere all utente di costruire un applicazione client per parlare con essi. Questa descrizione è generalmente fornita in un documento XML chiamato WSDL. I Web Service sono registrati in modo tale che gli utenti possano trovarli facilmente. Questo è possibile grazie all utilizzo di Universal Discovery Description and Integration (UDDI). Per fare un esempio di immediata comprensione UDDI rappresenta le pagine gialle dei Web Service. Come le tradizionali pagine gialle, infatti, è possibile rintracciare una compagnia che offre i servizi di cui si ha bisogno, leggendo i servizi offerti e i contatti per maggiori informazioni. Un entry all interno di UDDI è un file XML che descrive i servizi offerti. Uno dei principali vantaggi dell architettura Web Service è che permette ai programmi scritti in differenti linguaggi di differenti piattaforme di comunicare con ogni altro in una modalità basata su standard. La prima differenza rispetto ad altre architetture che forniscono medesime opportunità, ad esempio, come CORBA è il fatto che SOAP è significativamente meno complesso rispetto ai precedenti approcci, così che la barriera di ingresso all implementazione di servizi standardcompliant è significativamente bassa. E possibile trovare una lista di implementazioni di SOAP che annovera 79 elementi, in cui si trovano implementazioni del protocollo fatte dalle maggiori compagnie di software, ma solo alcune di queste sono costruite e mantenute da un singolo sviluppatore. L altro significativo vantaggio che i WS hanno rispetto i precedenti è che lavorano con i protocolli standard sul Web XML, HTTP, e TCP/IP. Un significativo numero di compagnie già hanno un infrastruttura Web, e persone con conoscenza ed esperienza per mantenerla, così il costo dell ingresso dei WS è decisamente inferiore rispetto alle tecnologie precedenti. E stato definito un Web Service come un servizio software esposto sul Web attraverso SOAP, descritto con file WSDL e registrato in UDDI. I primi WS tendevano ad identificarsi in sorgenti di informazioni facilmente incorporabili nelle applicazioni. E facile immaginare un intera classe di applicazioni costruita per

53 Architetture SOA 53 analizzare e aggregare le informazioni d interesse e presentarle nella forma più adeguata. Esponendo le applicazioni esistenti come Web Service si permette agli utenti di costruire nuove, più potenti applicazioni che usano Web Service come blocchi di costruzione. Per esempio, un utente potrebbe sviluppare un applicazione per la gestione degli acquisti che automaticamente ottiene i prezzi di vendita dai venditori stessi, permettendo all utente di selezionare il venditore, di sottomettere l ordine e di tracciarne le spese di spedizione. L applicazione del venditore, in aggiunta per esporre i suoi servizi sul Web, potrebbe utilizzare i WS per verificare il credito del clienti, per addebitare il conto ai clienti e per organizzare le spese di spedizione con una compagnia di spedizioni. Nel futuro, alcuni dei più interessanti Web Service supporteranno applicazioni che usano il Web per fare cose che oggi non si possono fare. Per esempio, uno dei servizi che i WS potrebbero rendere possibile è un servizio di calendario. Se il dentista, piuttosto che il meccanico espongono i loro calendari attraverso i WS, si potrebbero schedulare gli appuntamenti direttamente on line o potrebbero schedulare appuntamenti o procedure di routine direttamente all interno del proprio calendario. Con un po d immaginazione, è possibile ideare migliaia di applicazioni del genere SOAP (Simple Object Access Protocol) SOAP è il protocollo di comunicazione per i WS. Descrivendo SOAP come protocollo di comunicazione, molte persone pensano a DCOM o CORBA e si chiedono cose tipo, Come fa SOAP ad attivare gli oggetti? oppure Quali servizi usa SOAP? Mentre un implementazione SOAP potrebbe probabilmente includere queste cose, lo standard SOAP non le specifica. SOAP, quindi, è una specifica che definisce il formato XML dei messaggi. Se si ha un frammento XML ben formato incluso in una coppia di elementi SOAP, si ha un messaggio SOAP. Ci sono altre parti delle specifiche SOAP che descrivono come rappresentare i dati dei programmi in XML e come utilizzare SOAP per fare Remote Procedure Call. La maggior parte delle implementazioni di SOAP supportano applicazioni RPC perché i programmatori che hanno usato applicazioni COM o CORBA capiscono lo stile RPC. SOAP però supporta anche applicazioni dove il messaggio SOAP è solo un involucro di un documento XML. Applicazioni SOAP del genere sono molto flessibili e molti Web Service nuovi traggono vantaggio da questa flessibilità per costruire servizi che potrebbero essere difficili da implementare con RPC. Gli autori originali ammettono che inizialmente la loro attenzione era focalizzata sull accesso agli oggetti ma poi, nel corso del tempo è divenuto auspicabile per SOAP servire un più ampio audience. In effetti, l obiettivo della specifica si è spostato rapidamente dagli oggetti verso un generalizzato framework di messaggi XML. Per questa ragione si voleva modificare l acronimo cercando di eliminare la lettera O, ma il nome era diventato talmente popolare che per evitare di fuorviare gli

54 Architetture SOA 54 sviluppatori si è mantenuto come era in origine. Oggi la definizione ufficiale dell ultima specifica SOAP 1.2, non menziona gli oggetti: SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. SOAP uses XML technologies to define an extensible messaging framework, which provides a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics. SOAP è protocollo leggero per scambiare informazioni strutturate in un ambiente decentralizzato e distribuito. SOAP usa tecnologie XML per definire un framework estendibile per la messaggistica, che fornisce un costrutto per i messaggi che devono essere scambiati su una varietà di protocolli sottostanti. Il framework è progettato per essere indipendente da ogni specifico modello di programmazione e da semantiche specifiche dell implementazione. SOAP definisce, quindi, un modo di muovere messaggi XML da un punto A ad un punto B come mostrato in figura. Figura 22 Scambio di messaggi SOAP Per fare ciò fornisce un framework di messaggistica basato su XML che è: 1. Estendibile. Se c è una cosa che il Web ci insegna è che la semplicità vince sempre sopra l efficienza o la purezza tecnica, e che quando è d interesse l interoperabilità, allora diventa un requisito assoluto. La semplicità, citata come prima parte dell acronimo S che sta per Simple, rimane uno dei principali obiettivi di progettazione come mostrato dalla mancanza in SOAP delle principali caratteristiche dei sistemi distribuiti come sicurezza, istradamento, affidabilità. SOAP definisce un framework di comunicazione che permette a determinate caratteristiche di essere aggiunte come estensioni di altri livelli. Microsoft, IBM, e altri dei principali venditori di software hanno lavorato attivamente per definire una suite comune di estensioni che aggiunge molte delle caratteristiche che gli sviluppatori si aspettano. L iniziativa è denominata Global Xml Web Service Architecture(GXA). Microsoft ha rilasciato un implementazioni di diverse specifiche di GXA chiamata Web Services Enhancements 3.0 (WSE 3.0).per Microsoft.NET

55 Architetture SOA Usabile su una varietà di protocolli di rete sottostanti. SOAP può essere usato su una diversità di protocolli come TCP, HTTP, SMTP,o anche MSMQ. Per mantenere l interoperabilità fornisce specifiche per definire legami con i protocolli citati e fornisce un esplicito legame per HTTP che è il più utilizzato. SOAP quindi è indipendente dal protocollo di comunicazione in cui viaggia il messaggio, così che ogni intermediario può scegliere in maniera trasparente differenti protocolli di comunicazione senza produrre effetti sul messaggio SOAP. 3. Indipendente dal modello di programmazione. SOAP si adatta ad ogni modello di programmazione. Definisce un modello per processare messaggi individuali one-way. In uno scambio complessivo è possibile però combinare messaggi multipli. Nella Figura 22 è illustrato un semplice messaggio one-way dove chi invia non riceve la risposta. Il ricevente, però potrebbe inviare la risposta indietro al mittente (Figura 23). Figura 23 Modello request \ response per SOAP etc.. SOAP fornisce diversi pattern di comunicazione: one-way, request-response, SOAP definisce un insieme di elementi XML per raggruppare i messaggi che sono trasportati da un sistema a un altro. I principali elementi sono: Envelope, Header, Body, e Fault. Figura 24 Struttura di un SOAP envelope L Envelope è sempre l elemento radice del messaggio SOAP. Questo rende semplice l identificazione del messaggio SOAP solo guardando quest elemento. Questo contiene un elemento opzionale Header seguito da un elemento obbligatorio Body. Il body rappresenta il payload del messaggio ossia il corpo ed è un generico contenitore di un numero di elementi che possono provenire da qualsiasi

56 Architetture SOA 56 namespace. In questo elemento vengono inseriti i dati che si devono inviare. Il framework di comunicazione definisce anche un altro elemento chiamato Fault per rappresentare gli errori, insieme al body quando le cose nella comunicazione non vanno come ci si aspettava. Questa è essenziale perché senza una rappresentazione standard degli errori, ogni applicazione ne avrebbe inventato una propria rendendo impossibile definire un infrastruttura per distinguere tra successo e fallimento. La caratteristica estendibilità del protocollo permette di aggiungere altri elementi all interno del messaggio a seconda di quali caratteristiche del protocollo si vogliono utilizzare. Ad esempio se il sistema gestisce dei meccanismi di sicurezza attraverso l uso di policy sarà necessario inserire all interno dell header, seguendo le specifiche dello standard, un altro elemento per la gestione di quest aspetto WSDL (Web Service Description Language) Un file WSDL è un file XML che descrive un insieme di messaggi SOAP e come questi messaggi debbano essere scambiati. WSDL è per SOAP quello che IDL è per CORBA o COM. Per capire l importanza di WSDL si immagini che si vuole richiamare un metodo SOAP fornito da un partner. Occorre chiedergli degli esempi di messaggi SOAP e scrivere di conseguenza l applicazione per produrre e consumare messaggi che siano simili a quelli forniti. WSDL specifica cosa esattamente può contenere un messaggio e come sarà fatto il messaggio di risposta con una notazione univoca. La notazione che i file WSDL usano per descrivere il formato dei messaggi è basata su un XML Schema standard. Ciò implica che è neutrale rispetto ad ogni linguaggio di programmazione e che essendo basato su standard va bene per descrivere le interfacce dei WS che sono accessibili da una varietà di piattaforme e di linguaggi. In aggiunta per descrivere il contenuto dei messaggi, WSDL definisce dove il servizio è disponibile e quale protocollo di comunicazione è utilizzato per dialogare con il servizio. Ciò significa che WSDL fornisce le informazioni richieste per scrivere un programma che lavori con un XML Web Service. Ci sono diversi strumenti disponibili per leggere file WSDL e generare il codice richiesto per comunicare con un XML Web Service. Alcuni dei principali strumenti sono in Microsoft Visual Studio.NET. WSDL gioca un ruolo fondamentale nell architettura dei Web service perché descrive il contratto completo per la comunicazione tra applicazioni. Sebbene ci siano altre tecniche per descrivere WS, il WS-I Basic Profile Version 1.0 impone l utilizzo di WSDL e XML Schema.

57 Architetture SOA 57 Figura 25 Tecnologie per WS-I Basic Profile 1.0 WS-I Basic Profile Version 1.0 è una raccolta di specifiche che restringono le sovrabbondanti capacità espressive di SOAP, individuando un set minimo di caratteristiche comunemente supportate dai provider di WS. Siccome WSDL è un linguaggio machine-readable, è possibile costruirvi infrastrutture e tool, come accennato in precedenza. Un WSDL file è un documento XML con un elemento radice facente parte del namespace Questo elemento può contenere diversi altri elementi. WSDL definisce servizi come estremi (endpoint) di una rete, o porte. In esso, la definizione astratta di endpoint e messaggio è separata dalla sua concreta realizzazione in rete. Questo permette di riusare le definizioni astratte: messages, sono descrizioni di dati che devono essere scambiati, port types collezioni astratte di operazioni. La specifica del protocollo concreto e del formato dei dati per un particolare port type costituisce un binding riusabile. Una porta è definita associando un indirizzo di rete con un binding riusabile, e una collezione di porte definisce un servizio. Di seguito si descrive come il documento WSDL usi i seguenti elementi nella definizione di servizio di rete: Types: un contenitore di definizioni di tipi di dati che usa alcuni tipi di sistema. Message: una definizione astratta e tipizzata dei dati che devono essere comunicati. Definisce un messaggio astratto che può fare da input o output di un operazione. Operation: una descrizione astratta di un azione supportata dal servizio. Port Type: un insieme astratto di operazioni supportate da uno o più endpoint. Definisce un gruppo di operazioni, anche chiamate interfacce in molti ambienti. Ad ogni port type deve essere assegnato un nome univoco per poter riferirsi ad esso in altre parti del documento WSDL. Un elemento port type contiene zero o più operazioni. Ogni operazione contiene una combinazione di elementi di input e output. Per esempio un elemento di input seguito da uno di output indica che quella operazione è di tipo request-

58 Architetture SOA 58 response, mentre la presenza del solo elemento di input indica un operazione di tipo one-way. Figura 26 Definizione di Port Type elemento di un file WSDL Binding: un protocollo concreto e una specifica di formato dati per una particolare port type. In pratica indica i dettagli concreti per usare un particolare port type con un protocollo dato. Contiene diversi elementi estendibili come un elemento operation per ogni operazione descritta nel port type. Port: un singolo endpoint definito come combinazione di un binding e di un indirizzo di rete. Service: una collezione di endpoint, o di porte, che espone un particolare binding. Figura 27 definizione dell'elemento service del WSDL E possibile dare ad ogni porta un nome ed assegnarle un binding. Poi per ogni porta, utilizzando l elemento extensibility è possibile definire i dettagli dell indirizzo specifico del binding. 3.5 Architettura WS-* E interessante descrivere quest architettura perché la maggior parte degli strumenti utilizzati nel progetto sviluppato e nel progetto di integrazione per l IPTV implementano alcuni elementi di WS-*. In particolare sono stati utilizzati gli standard relativi al messaging come WS-Addressing e quelli relativi alla gestione della sicurezza delle conversazioni tra i partecipanti WS-Security, che saranno illustrati nei due paragrafi successivi. Inoltre nell ambito di sviluppo di sistemi distribuiti è di fondamentale importanza definire degli standard di interoperabilità sia per le funzionalità base di scambio di messaggi tra i Web Service (SOAP,WSDL), sia per garantire sicurezza, affidabilità e gestione delle transazioni per i servizi eterogenei coinvolti all interno dell architettura.

59 Architetture SOA 59 Come i Web Service rapidamente si sono espansi da quando sono stati lanciati sul mercato di pari passo è cresciuta la necessità di standard avanzati per governare la sicurezza, l affidabilità, e le transazioni. Microsoft ed altri venditori hanno risposto a questo bisogno autorizzando un insieme di specifiche riferite collettivamente come architettura WS-*. L obiettivo di queste specifiche è fornire un modello per le funzionalità avanzate conservando la semplicità dei Web Service. Il principale attributo dell architettura WS-* è la capacità di essere componibile. Questa caratteristica permette uno sviluppo incrementale delle soluzioni basate sui Web Service introducendo in maniera graduale i requisiti di cui si ha bisogno (come sicurezza, affidabilità, etc.). In isolamento ognuno di questi requisiti soddisfa un bisogno elementare. Insieme consentono di soddisfare funzionalità di alto livello richieste dalle applicazioni distribuite. Questo elimina la complessità e l overhead associato con le specifiche che cercano di fornire molteplici capacità o sono altamente accoppiate con altre specifiche. Questo, inoltre, permette agli sviluppatori di applicare solo la specifica funzionalità necessaria a risolvere il bisogno immediato. Come si presentano nuove esigenze, possono essere aggiunte nuove specifiche senza compromettere la compatibilità con le precedenti. Figura 28 Architettura WS-* L architettura illustrata nella Figura 28 compone tutte le specifiche per i Web Service per fornire protocolli interoperabili per sicurezza, affidabilità dei messaggi e transazioni in sistemi debolmente accoppiati. Queste specifiche sono costruite sulla base degli standard XML e SOAP WS-Addressing WS-Addressing è collocato all interno dell architettura WS-* nell ambito del blocco relativo al Messaging perché specifica un meccanismo grazie al quale i Web Service trasmettono informazioni relative all indirizzamento dei messaggi. Web Service Addressing definisce due costrutti interoperabili che trasmettono informazioni che sono tipicamente fornite dai protocolli di trasporto e dai sistemi di

60 Architetture SOA 60 messaging. Questi costrutti normalizzano questi fondamentali dati in un unico formato che può essere processato indipendentemente dal trasporto o dalla applicazione. I due costrutti sono endpoint reference, una struttura per comunicare un riferimento a un endpoint, e message information headers che permettono di associare informazioni di indirizzamento ad un particolare messaggio. Un endpoint è un entità referenziabile, un processore, o una risorsa a cui è possibile inviare messaggi. Endpoint reference trasmettono le informazioni necessarie per referenziare un endpoint rappresentato da un Web Service, e potrebbero essere utilizzati in diversi modi: sono adatti a trasmettere informazioni necessarie per l accesso a Web Service endpoint, ma sono anche validi per fornire indirizzi per un messaggio individuale inviato da e verso un Web Service. Per far fronte all ultimo caso questa specifica definisce una famiglia di intestazioni per esprimere le informazioni del messaggio, message information headers, che permette un indirizzamento uniforme dei messaggi indipendentemente dal protocollo sottostante. Questi header trasmettono caratteristiche del messaggio end-to-end inclusi gli indirizzi sorgente e destinazione degli estremi coinvolti nella comunicazione. Entrambi i costrutti definiti in WS-Addressing sono progettati per essere estensi e riusabili così che altre specifiche possano aggiungere endpoint reference e message information headers. La seguente figura illustra l uso del meccanismo in un messaggio SOAP 1.2 che deve essere inviato da a Figura 29 Esempio di un messaggio SOAP per l'uso di Ws-Addressing Le linee da (002) a (011) rappresentano l intestazione del messaggio SOAP in cui sono usati i meccanismi definiti nella specifica. Il body è rappresentato dalle linee che vanno dalla (012) alla (014). Le linee dalla (003) alla (010) contengono i blocchi relativi al message information header. In particolare le linee dalla (003) alla (005) specificano l identificativo del

61 Architetture SOA 61 messaggio, le linee dalla (006) alla (008) specificano l endpoint al quale rispondere al messaggio che deve essere inviato come un endpoint reference. La linea (009) specifica l indirizzo URI dell ultimo Web Service che ha ricevuto il messaggio. La linea (010) specifica l URI della Action. Quest ultima rappresenta l azione che deve essere svolta sul endpoint destinazione richiesta dal client Endpoint reference Endpoint reference è una struttura XML che incapsula informazioni utili per inviare un messaggio ad un Web Service. Questo include la destinazione del messaggio, e altri parametri necessari a instradare il messaggio verso la destinazione, e metadati opzionali (come WSDL o WS-Policy) relativi al servizio. Questa specifica introduce una descrizione di un nuovo tipo di elemento, l endpoint reference, con l intento di supportare un insieme di casi d uso dinamici non attualmente soddisfatti da WSDL1.1. In particolare, la specifica ha l intenzione di facilitare i seguenti scenari: Generazione dinamica e customizzazione delle descrizioni di endpoint. Identificazione e descrizione di istanze specifiche di un servizio che sono create come risultato di interazioni. Scambio di informazioni riguardo agli endpoint in maniera flessibile e dinamica in ambienti strettamente accoppiati in cui le parti condividono una serie di assunzioni comuni riguardo alle politiche e ai protocolli che sono usati nell interazione. Per supportare questi scenari, sono stati definiti meccanismi estendibili che permettono di descrivere e identificare dinamicamente endpoint e istanze di servizio. Lo standard WSDL 1.1 è un modello estendibile che non permette di usare elementi come i servizi e le porte per coprire questi scenari. Endpoint reference estendono logicamente il modello su cui si basa WSDL (es: porttypes, binding, etc.), ma non lo sostituiscono. Un endpoint reference consiste delle seguenti proprietà: [address]: indirizzo URI che identifica l endpoint. Potrebbe essere un indirizzo di rete o un indirizzo logico. [Reference properties] : può contenere un numero di proprietà individuali richieste per identificare l entità o la risorsa. [reference parameters]: può contenere un numero di parametri individuali che sono associati con l endpoint per facilitare una particolare interazione. [selected port type]: Il nome della porttype primaria dell endpoint. [service-port]: è il nome che identifica l elemento service del WSDL che contiene la definizione dell endpoint.

62 Architetture SOA 62 [policy]: un numero variabile di elementi che descrivono il comportamento, i requisiti e le capacità dell endpoint. Le policy possono essere incluse per facilitare il processo da parte dell applicazione che consuma il servizio, o perché esse vengono generate automaticamente Message information header Message information header aggiunge al messaggio una serie di proprietà che abilitano all identificazione degli estremi coinvolti nella comunicazione. Il pattern base di interazione fra servizi è one-way. In questo pattern una sorgente invia un messaggio ad una destinazione senza ulteriori definizioni. Request Reply è un altro pattern di interazione che consiste nell invio di un messaggio iniziale da parte dell endpoint sorgente (la richiesta) e dall invio da parte della destinazione della risposta, che può essere un messaggio di un applicazione o un messaggio di errore. Le proprietà di seguito supportano qualsiasi pattern di interazione: [destination]: l URI del destinatario del messaggio. [source endpoint]: riferimento all endpoint dal quale è originato il messaggio. [reply endpoint]/[fault endpoint]: un riferimento all endpoint che identifica il ricevente della risposta/messaggio di errore. [action]: un identificatore espresso con un URI della semantica del messaggio. [message id]: un URI che identifica in maniera univoca il messaggio nel tempo e nello spazio. [relationship]: una coppia di valori che identifica come questo messaggio è legato con un altro messaggio WS-Security La specifica Web Services Security fornisce un insieme di meccanismi per aiutare gli sviluppatori di Web Service a scambiare messaggi SOAP sicuri. In particolare WS-Security fornisce miglioramenti all esistente modello di messaging SOAP provvedendo maggiore qualità nella protezione attraverso l applicazione dell integrità del messaggio, confidenzialità del messaggio, e autenticazione del singolo messaggio. Questi meccanismi base possono essere combinati in vario modo per costruire un ampia varietà di modelli di sicurezza usando diverse tecnologie di crittografia. WS-Security fornisce anche un meccanismo general-purpose per associare token (contrassegni) di sicurezza con i messaggi. Sebbene non sia specificato il tipo di token di sicurezza che è richiesto da WS-Security, la specifica è progettata per essere estesa (per esempio può supportare diversi tipi di security token) per adattarsi a diverse tipologie di meccanismi di autenticazione e di autorizzazione. Per esempio, un endpoint che richiede un servizio potrebbe fornire la prova della sua

63 Architetture SOA 63 identità firmando il messaggio con un certificato. Un Web Service, ricevendo questo messaggio potrebbe determinare l affidabilità del richiedente sulla base delle credenziali fornite. In aggiunta, WS-Security descrive come codificare token di sicurezza binari e come inserirli nei messaggi SOAP. In particolare, la specifica descrive come codificare certificati X.509 e Kerberos ticket. Questi sono utilizzati attualmente dagli sviluppatori per aggiungere meccanismi di autenticazione per molte applicazioni Web. Con WS-Security, il dominio di questi meccanismi può essere esteso portando le informazioni sull autenticazione nella richiesta. Questa specifica include anche meccanismi di estensibilità che possono essere usati per descrivere le credenziali che sono incluse nel messaggio. WS-Security, quindi, risulta essere un blocco di costruzione che può essere aggiunto in congiunzione con altri protocolli per i Web Service per fornire un ampia gamma di requisiti di sicurezza. L integrità del messaggio è fornita grazie all utilizzo di XML Signature e token di sicurezza che assicurano che il messaggio sia originato dal giusto mittente e che non sia modificato durante la trasmissione. Similmente la confidenzialità del messaggio è realizzata grazie a XML Encryption e token di sicurezza per rendere confidenziali porzioni del messaggio SOAP. Il modello di messaging SOAP è basato su un framework estendibile e sulle specifiche SOAP che sono progettate per essere composte l una con l altra per fornire un ricco ambiente di messaging. Infatti, WS-Security non fornisce una soluzione completa di sicurezza ma può essere usata in congiunzione con altri protocolli e applicazioni specifici per i Web Service Sicurezza dei messaggi Prima di entrare nel dettaglio spiegando il concetto di security token, le sue implementazioni alternative, come questo contrassegno possa essere agganciato al messaggio, è utile definire alcuni concetti generali di sicurezza. In primo luogo è utile definire il concetto di autenticazione identificato come il processo tramite il quale un computer, un software o un utente, verifica la corretta o almeno presunta, identità di un altro computer, software, o utente che vuole comunicare attraverso una connessione. L autenticazione può essere garantita in tre modi: Certificati X.509 che sono dei documenti elettronici che associano l identità di una persona ad un chiave pubblica. Vengono emessi da un autorità di certificazione riconosciuta secondo standard internazionali (X.509) e vengono firmati con una chiave privata dell autorità. Username e password: essendo una forma di autenticazione molto semplice non è utilizzata in sistemi che richiedono privatezza e integrità. Autenticazione anonima

64 Architetture SOA 64 Dopo che una persona, un computer, o un programma sono identificati e autenticati con successo è possibile determinare a quali risorse possono accedere e quali azioni possono fare su di esse. Questo è chiamato autorizzazione. Il problema dell'autorizzazione è spesso identificato con quello dell'autenticazione: i protocolli di sicurezza standard, ad esempio, si basano su questo presupposto. Comunque, vi sono casi in cui questi due problemi vengono risolti con strategie differenti. Un esempio di tutti i giorni è la comune procedura di autenticazione che conosciamo come login. Un sistema di elaborazione, progettato per essere usato soltanto da utenti autorizzati, deve essere in grado di rilevare ed escludere i non autorizzati. L'accesso ad esso, dunque, viene garantito solo dopo aver eseguito con successo una procedura di autenticazione, di solito attraverso una username e una password personale. Altro concetto importante da definire in questo contesto è l integrità del messaggio. Per integrità di una certa risorsa si definisce quella proprietà per assicurare che i dati non siano modificati, o cancellati senza autorizzazione. Insito nel concetto di integrità vi è la possibilità di verificare con assoluta certezza se un dato o una informazione siano rimasti integri, ossia inalterati nel loro contenuto, durante la loro trasmissione e/o la loro memorizzazione. Un meccanismo che consente di assicurare l integrità di un messaggio è la firma digitale. Questa è un tipo di crittografia asimmetrica fondato su due algoritmi: uno per firmare il messaggio che coinvolge la chiave privata, ed un altro per verificare la firma tramite la chiave pubblica. L integrità viene garantita perché se un messaggio è firmato ogni cambiamento apportato invaliderà il processo di verifica della firma lato ricevente scartando il messaggio come non sicuro. Identificati questi concetti fondamentali della sicurezza informatica è possibile ora descrivere i mezzi con i quali viene garantita la sicurezza in WS-Security. I Security token sono dei contrassegni che consentono di fare delle asserzioni che possono essere associate alle firme digitali. Questo meccanismo permette al mittente di dimostrare la sua conoscenza delle chiavi descritte dal token. In aggiunta la definizione dell intestazione del messaggio SOAP fornisce un meccanismo per associare la firma con le asserzioni fatte nel security token. Occorre notare diverse cose, in primo luogo come il legame sia limitato al solo elemento compreso nella firma. In secondo luogo, si noti che questi meccanismi non specificano un particolare metodo di autenticazione; indicano semplicemente token che potrebbero essere legati ad un certo messaggio. Come ultima nota da fare c è il fatto che il ricevente del messaggio potrebbe fidarsi o meno del token fornito nel messaggio. I security token possono essere garantiti da un authority o meno. Un insieme di asserzioni che sono garantite da un authority è generalmente rappresentato come un security token firmato che è firmato digitalmente o tramite un algoritmo per la

65 Architetture SOA 65 crittografia protetto dall authority. Un certificato X.509, che stabilisce un legame tra l identità di uno e la sua chiave pubblica, è un esempio di un security token firmato. I token possono essere trasmessi nel messaggio direttamente, o indirettamente ricavati tramite il riferimento che il destinatario può usare per estrarre l asserzione dall authority specificata. Un altro aspetto del modello di sicurezza è come si articola la relazione di fiducia tra i due servizi che devono scambiarsi messaggi in modo sicuro. I security token si usano con un dominio fidato. Un dominio fidato può essere costituito attraverso un processo manuale, un accordo, o un implementazione di un insieme di regole basate su politiche di fiducia. Un asserzione non garantita da un autorità di certificazione può anche essere garantita se c è una relazione di fiducia tra le parti. Per esempio, l asserzione che il mittente è Bob è sufficiente per alcuni destinatari ad essere certi del fatto che chi origina il messaggio sia Bob, se il mittente e il destinatario usano una connessione con una sufficiente protezione e c è una relazione di fiducia tra di loro. Uno speciale tipo di asserzione non autorizzata è la prova di possesso Proof-of- Possession. Questa produce evidenza del fatto che un mittente possiede delle conoscenze che sono solo sue, o che sono verificabili da appropriati attori. Per esempio, uno username/password è un token che fa parte della categoria Proof-of- Possesion. In questo tipo di scenario, il ricevente prende la decisione se autenticare o meno l utente. Di seguito si farà un esempio che illustra l uso di security token, firme, e crittografia. Le righe dalla (003) alla (051) della Figura 30 contengono l intestazione del messaggio SOAP. Quelle dalla (004) alla (009) specificano le informazioni di istradamento del messaggio secondo WS-Routing, specifica che non è considerata in questo lavoro. Le linee di maggiore interesse sono quelle che vanno dalla (010) alla (050) che rappresentano il blocco dell header dedicato alla sicurezza <Security>. Questo contiene le informazioni relative alla sicurezza per il messaggio. All interno di questo blocco una parte,dalla (011) alla (013) specifica il security token che è associato al messaggio. In questo caso, è specificato un certificato X.509.

66 Architetture SOA 66 Figura 30 Esempio WS-Security linee (001)-(013) Dalla (014) alla (026) è specificata la chiave che è usata per criptare il corpo del messaggio. Dato che è una chiave simmetrica, è passata in una forma crittata. Infatti nella linea (015) si definisce l algoritmo usato per criptare la chiave. Le linee dalla (016) alla (018) specificano l identificatore della chiave usata per criptare la chiave simmetrica. Le linee (019)-(022) specificano l attuale forma criptata della chiave simmetrica. Le linee (023)-(025) identificano il blocco da criptare nel messaggio che usa questa chiave simmetrica. In questo caso è usato solo per criptare il corpo (wsu:id= enc1 ). Figura 31 Esempio WS-Security linee (014)-(026) Le linee dalla (027) alla (049) illustrate nella Figura 32 specificano la firma digitale. Dalla (031) alla (039) si identifica la parte del messaggio che deve essere firmata.

67 Architetture SOA 67 Le linee dalla(041) alla (043) indicano il valore attuale della firma; (044)-(048) indicano la chiave usata per la firma. Figura 32 Esempio WS-Security linee (027)-(051)

68 Architetture SOA 68 Nella figura sottostante è mostrata un illustrazione generale del formato del messaggio. Figura 33 Formato del messaggio SOAP con WS-Security All interno dell architettura di simulazione realizzata è stato usato solo un tipo di token di sicurezza, lo username token. Quindi di seguito illustrerò l utilizzo di questa tipologia di strumento per assicurare la sicurezza di un messaggio SOAP. Un possibile scenario in cui si possono applicare i concetti illustrati è quello che coinvolge due partecipanti alla comunicazione un Requestor ed un Web Service. La sicurezza è garantita sulla base dello scambio delle credenziali di sicurezza rappresentate da uno username token con l aggiunta di protocolli di trasporto sicuri. Figura 34 WS-Security con username/password Utilizzando TLS/SLL, protocolli che garantiscono la sicurezza dei messaggi trasportati attraverso Internet, è possibile stabilire un canale di comunicazione sicuro tra client e Web Service su una connessione http. Per stabilire questo canale vengono scambiate una coppia di chiavi, una volta effettuato lo scambio si ha la sicurezza che ogni informazione scambiata verrà letta solo dai partecipanti alla conversazione sicura. In questo modo è garantita l integrità del messaggio, l autenticazione invece, viene fornita grazie all invio da parte del requestor della coppia username password. Queste informazioni sono mantenute nell header del messaggio http. La variazione introdotta con l utilizzo del modello di messaging di SOAP permette di utilizzare Web Services Security con l esistente sicurezza fornita dal protocollo di trasporto. Il client apre una connessione con il Web Service utilizzando un canale di trasporto sicuro. Invia la sua richiesta e include il token di sicurezza che contiene username e

69 Architetture SOA 69 password. Il servizio autentica le informazioni, processa la richiesta, e ritorna il risultato. L esempio opera come segue: Il requestor apre una connessione con il Web Service usando un protocollo di trasporto sicuro come SSL. Il requestor costruisce un messaggio SOAP. Al suo interno include un elemento <UsernameToken> nel blocco dell intestazione destinato alla sicurezza. Questo elemento contiene la username e la password del requestor del servizio. La password può essere inviata in chiaro poiché il trasporto è sicuro. Il messaggio è inviato al servizio. Il servizio estrae l elemento <UsernameToken> e valida le credenziali. Fino a che la validazione non ha successo, il servizio processa il messaggio e ritorna il risultato. La seguente figura illustra un esempio di SOAP Envelope che è inviato dal requestor del servizio. Si noti come la parte d interesse relativa alla sicurezza è quella che va dalla riga (003) alla (008). Figura 35 SOAP Envelope con username token Lo username token è utilizzato anche quando il trasporto non fornisce protezione da attacchi e modifiche provenienti dall esterno, come ad esempio TCP/IP in chiaro, se la rete è considerata sicura dalle politiche di gestione. Ad esempio una intranet aziendale è considerata una rete fidata.

70 Tecnologie e strumenti 70 4 Tecnologie e strumenti Questo capitolo vuole essere un ponte di collegamento tra i concetti, i modelli, i protocolli e gli standard descritti nel capitolo precedente che sono la base teorica, e l implementazione del sistema, descritta nei capitoli 6 e 7, fondata su questi concetti. L obiettivo di questo capitolo è quello di fornire una descrizione del panorama di tecnologie utilizzate nell ambito della progettazione e sviluppo dell architettura di simulazione e del componente di tracing. Queste tecnologie da un lato rappresentano la concretizzazione dei modelli presentati nel capitolo 3 secondo l approccio adottato da Microsoft, e dall altro i basamenti con i quali costruire l architettura orientata ai servizi per la simulazione dell ambiente reale dell IPTV. 4.1 Connected Services Framework 3.0 Nel seguente paragrafo sarà illustrato Connected Services Framework 3.0 (CSF 3.0), un framework per la connessione di servizi in ambienti distribuiti progettati sulla base di architetture orientate ai servizi. CSF si fonda sui principi fondamentali di SOA che considera i servizi come entità autonome, favorendone il riuso e garantendo un basso accoppiamento tra di essi. Inoltre esso può essere visto come un implementazione del concetto di service bus presente nelle architetture service oriented; infatti, esso connette tutti i partecipanti di un ambiente distribuito fornendo funzionalità per la collaborazione e l interazione tra di essi. Proprio in questo si riconoscono gli obiettivi primari di CSF.

71 Tecnologie e strumenti Rete di servizi Da quando Internet Protocol (IP) ha creato le fondamenta del Web diventando il mezzo di comunicazione tra computer accettato globalmente, la proliferazione e la vasta adozione di Web Service ha creato le condizioni per sostenere un diverso ecosistema di servizi. L ecosistema è chiamato Services Network (rete di servizi). Figura 36 Services Network - Rete di servizi Nel caso della tradizionale rete IP, un ulteriore livello di controllo è richiesto per gestire l interazione tra i nodi, i collegamenti e i dati. Questo livello di controllo astrae la complessità della rete sottostante e gestisce le caratteristiche generali, come la volatilità dell ambiente, la diversità delle piattaforme, e il ripristino da fallimenti. Esempi di livelli di controllo di rete sono System Signalling 7 per le classiche compagnie telefoniche e IP Multimedia System (IMS) per ambienti multimediali. La rete di servizi è costituita da servizi debolmente accoppiati e risorse che operano in ambienti eterogenei, sono gestite da multipli domini amministrativi, e comunicano attraverso eventi asincroni. Questi diversi e complessi comportamenti ospitati nei servizi sono comparabili ai comportamenti dei domini di rete. Come risultato, si richiede un ulteriore livello di astrazione per controllare e governare questi comportamenti. Questo livello detto service network control layer (livello di controllo della rete di servizi) fornisce le seguenti funzionalità: Definisce e gestisce un contesto dinamico di collaborazione. Gestisce le identità attraverso domini amministrativi differenti. Gestisce le risorse esposte dai servizi. Rinforza le politiche tra domini eterogenei. Fornisce la consegna di servizi tolleranti ai guasti.

72 Tecnologie e strumenti 72 La Figura 37 mostra come, nello stesso modo in cui la rete IP ha bisogno di un livello di controllo di rete, anche una rete di servizi richiede un livello di controllo. Figura 37 Livello di controllo della rete di servizi CSF fornisce un ambiente di sviluppo e di esecuzione per la creazione rapida di servizi e per la loro aggregazione con la rete di servizi. Fornisce, inoltre, la mediazione necessaria, le funzionalità di broker, e le caratteristiche di negoziazione richieste per integrare servizi di diversi confini tecnologici e di business garantendo un basso accoppiamento. In questa rete composta di servizi, è inequivocabile il ruolo centrale assunto da essi. L avanzamento delle tecnologie per i sistemi distribuiti conduce verso una nuova descrizione e definizione dell elemento servizio che ultimamente è orientata verso uno specifico approccio per la loro progettazione, l istallazione, e l esecuzione. Tecnologie come i Web Service sono centrali nella definizione di livelli multipli di astrazione richiesti per disaccoppiare i sistemi perché facilitano la rapida consegna di servizi che soddisfano la domanda di esperienze innovative per gli utenti finali. Come anticipato l architettura dei Web Service definisce un framework per la definizione di Web Service di base. CSF 3.0 usa la piattaforma WSE 3.0 per fornire le funzionalità di messaging e di sicurezza definite rispettivamente, dalle specifiche WS-Addressing, da SOAP 1.1 e 1.2, e WS-Security 1.0 e 1.1. La piattaforma WSE 3.0 non è altro che un insieme di librerie del Framework.NET che consente di costruire Web Service usando gli ultimi protocolli definiti su di essi, incluso WS- Security, WS-SecureConversation, WS-Trust, e WS-Addressing. Permette di

73 Tecnologie e strumenti 73 aggiungere queste caratteristiche a tempo di progettazione usando codice o a tempo di istallazione usando dei file Definizione Microsoft Connected Services Framework (CSF) ospita un ambiente di sviluppo e un ambiente di esecuzione che permette di creare nuovi Web Service, aggiornare quelli esistenti, e aggregare servizi in un'unica applicazione distribuita. L obiettivo di CSF è realizzare una rapida integrazione tra Web Service, usando la minima quantità di codice scritto dagli sviluppatori, e riducendo o eliminando le dipendenze tra di essi. CSF aiuta, quindi, velocemente a sviluppare, istallare, e revisionare applicazioni composte da Web Service. Questo framework è corredato di una serie di componenti che aiutano lo sviluppatore per la gestione delle identità (Identity Management), gestione del profilo in termini di memorizzazione e integrazione del profilo (Profile Management), e ricerca di servizi. Il prodotto CSF è suddiviso in tre parti, il CSF Session Server, che include componenti che forniscono il tracciamento delle identità, service discovery, e gestione del profilo. Gli altri due elementi offerti sono lo Billing Standard Business Event (BSBE) e Order Handling Standard Business Event (OHSBE). Il primo è un Web Service che abilita la collaborazione tra i sistemi di business dell azienda e i Web Service esterni che permettono di comporre un applicazione che fornisce funzionalità di business in una specifica area. Il secondo invece è un Web Service che cattura le richieste da autorità esterne come ad esempio organizzazioni di Operation Support System (OSS) e Business Support System (BSS) il cui ruolo sarà descritto nel paragrafo 5.1. L OHSBE permette ai sistemi di gestire gli ordini, di inviare le richieste di ordine in maniera sicura, e di accodare queste richieste come richiesto. Come illustra la Figura 38, CSF fornisce un Session Management Server, e un insieme di servizi integrati per la gestione dell identità, gestione del profilo, e del catalogo di servizi. Il componente della sessione è gestito usando tre Web Service, il Session Web service, il SessionAdmin Web service, e il SessionManagerAdmin Web service. Questi Web service facilitano la ricezione dei messaggi da parte dei Web service partecipanti, creano e gestiscono il ciclo di vita di un oggetto Session. Per esempio, SessionManagerAdmin espone operazioni per creare una sessione, e quando riceve un messaggio di richiesta create session crea un contesto di collaborazione. Questo contesto è chiamato Sessione, identifica tutti i Web Service partecipanti che vorrebbero intervenire nel processamento di una richiesta, e istrada i messaggi da un partecipante a un altro. Il SessionAdmin controlla le proprietà di una sessione individuale. Il SessionManagerAdmin gestisce lo stato di tutte le sessioni.

74 Tecnologie e strumenti 74 Figura 38 Connected Services Framework CSF fornisce anche servizi di gestione che permettono di realizzare specifici task importanti per costruire un applicazione distribuita. Questi servizi includono il tracciamento e la gestione dell identità, il service discovery, e la gestione dei profili e sono forniti da componenti principali di CSF chiamate core components: Il Service Catalog memorizza le informazioni riguardo i WS partecipanti che sono stati registrati in UDDI per l applicazione distribuita sviluppata. Queste includono l Uri del WS, il suo nome, credenziali e tipi di autenticazione, ed eventuali documenti di policy associati al WS. In pratica è un interfaccia di accesso ai servizi di UDDI. L Identity Manager traccia le identità degli utenti e fornisce una gestione single-sign on. Il componente della Service Logic, che si deve sviluppare, definisce le regole di business che si vogliono applicare quando si processano le richieste nella propria applicazione CSF. Profile Management traccia informazioni sul profilo degli utenti e dei partecipanti che sono connessi alle applicazioni distribuite utilizzando un database Resource Definition Framework (RDF). Ognuna di queste componenti ha un interfaccia che permette di accedere alle informazioni che memorizza.

75 Tecnologie e strumenti 75 L interazione tra i Web Service partecipanti e CSF è simile a quella che c è tra i computer connessi ad un hub in uno schema a stella, come mostrato nella figura seguente. Figura 39 Interazione tra i core components in CSF In CSF, il componente della Session è l hub e i partecipanti sono gli utenti e i Web Service. I componenti principali di CSF, eccetto per la Session, agiscono anch essi come Web Service partecipanti di un contesto di collaborazione Funzionamento CSF fornisce un infrastruttura attraverso la quale tutti i Web Service inclusi nel proprio ambiente distribuito possano comunicare. Questo è permesso tramite l utilizzo di una serie di componenti, ognuna delle quali espone Web Service sviluppati con WSE 3.0 che sono in grado di inviare e ricevere messaggi SOAP. E possibile scegliere di inviare questi messaggi in maniera sincrona, o asincrona anche se la natura delle applicazioni distribuite fa della seconda la miglior scelta in molti casi. Quando un applicazione CSF riceve un messaggio di richiesta, compie una serie di task necessari a creare un manifesto della sessione che contiene le informazioni riguardo a tutti i Web Service che dovranno essere inclusi nella richiesta. In seguito invia il messaggio contenente il manifesto verso la piattaforma CSF per iniziare un contesto di collaborazione per la richiesta, chiamato sessione. E possibile anche rintracciare una sessione esistente invece di crearne una nuova. La sessione usa le informazioni che gli sono state passate nel manifesto per istradare i messaggi correttamente ai WS che partecipano al processamento della richiesta. La sessione poi diventa il punto centrale di comunicazione attraverso cui i Web Service passano i messaggi.

76 Tecnologie e strumenti 76 Un altra importante parte di un applicazione CSF è la Service Logic, che è un WS che viene sviluppato per definire la logica di business per l applicazione. Dopo che una sessione è stata creata per processare una determinata richiesta, la service logic controlla quando inviare particolari messaggi a specifici Web Service coinvolti. Il contenuto dei messaggi inviati tra i partecipanti ad una sessione dipende dalla specifica applicazione, ma può includere notifiche di errore, messaggi di stato, messaggi di completamento di un processo, che la service logic invia ai WS che interagiscono con CSF. La service logic può inviare messaggi verso o ricevere messaggi da qualsiasi WS coinvolto nella conversazione. Riguardo ai mittenti e ai destinatari di questi messaggi, entrambi devono istradare i messaggi attraverso la sessione. La service logic guida il processo di richiesta fino a che la richiesta è stata completata con successo o è fallita. CSF provvede anche due componenti identity management e profile management che sono coinvolte in ogni richiesta. L identity manager non solo gestisce utenti, organizzazioni, e ruoli per CSF, maa fornisce anche autenticazione e autorizzazione Architettura Il classico modello OSI definisce uno stack di sette livelli nel quale il livello di applicazione è visto come un singolo livello. Con l evoluzione delle tecnologie dei Web Service, la proliferazione e l aggregazione dei servizi, il livello di applicazione è diventato sempre più distribuito e per questo richiede la definizione di un suo stack a parte. Mentre lo stack per un singolo servizio è ben definito, quello che descrive il comportamento di una moltitudine di servizi è spesso limitato all organizzazione di essi. Quest orchestrazione non necessariamente copre tutti gli attributi richiesti per gestire l aggregazione di servizi basata sulla collaborazione. Occorre inserire il livello di collaborazione per affrontare questa natura dinamica degli ambienti composti da una rete di servizi e per differenziare l aggregazione di servizi dal comportamento di questa aggregazione. La figura seguente mostra come il livello di applicazione sia suddiviso in diversi sottolivelli. Gli ultimi tre livelli si occupano di un singolo servizio, mentre i primi due della collaborazione tra più servizi.

77 Tecnologie e strumenti 77 Figura 40 Modello OSI con stack per le applicazioni distribuite L astrazione dei processi di business e delle orchestrazioni dai servizi partecipanti, tramite il livello di collaborazione, crea alcune nuove opportunità per i servizi. Questo livello intercetta i messaggi da e verso i partecipanti isolando i processi da essi. Lo scopo fondamentale di CSF è proprio quello di abilitare questo livello. Di seguito saranno illustrate le caratteristiche principali fornite da ogni livello. Livello di trasporto: Si occupa dei vari livelli di trasporto che devono essere usati per trasportare un messaggio da un punto ad un altro. Livello dei messaggi: In questo livello sono utilizzati XML e sue varianti. SOAP è la specifica che viene utilizzata per definire un envelope usato per inviare un messaggio da un estremo ad un altro. Livello dei servizi: Definisce l insieme di funzioni che sono richieste per creare servizi sicuri, affidabili, e transazionali. Un insieme di specifiche definiscono i comportanti standard per i servizi che vogliono fornire questa tipologia di funzionalità. Livello di collaborazione: Rappresenta un gruppo di partecipanti in un contesto definito. Si occupa dei servizi da un punto di vista di vincoli amministrativi, di rete, e di sicurezza. La collaborazione non include la gestione del sequenziamento, e dello stato delle interazioni tra i componenti. Livello di orchestrazione: Si riferisce alla service logic che gestisce la composizione di vari servizi e realizza un nuovo insieme di funzionalità. L orchestrazione gestisce il sequenziamento, le traduzioni semantiche, le traduzioni del formato dei messaggi, e la gestione dello stato a seconda

78 Tecnologie e strumenti 78 delle richieste dei partecipanti nel contesto di collaborazione in questo caso nella sessione Sessione Tutte le applicazioni costruite utilizzando Microsoft CSF si fondano sul concetto si sessione per fornire il contesto per i messaggi scambiati tra i servizi connessi e per gestire la sicurezza tra questi servizi. Il componente della Session ha un importante ruolo in CSF. Tutti i messaggi che sono inviati usando CSF passano attraverso il Session Web Service, che li istrada verso le appropriate destinazioni. Questo componente contiene tre WS: Session, SessionAdmin,e SessionManagerAdmin. Ognuno di questi servizi ha un ruolo specifico nella gestione del ciclo di vita di una sessione e nel controllo dell istradamento dei messaggi. Il Session Web Service istrada i messaggi e gestisce la sicurezza. Le applicazioni gli inviano i messaggi, esso li istrada nella corretta direzione e applica le appropriate politiche di sicurezza che sono richieste per quell applicazione.e possibile usarlo anche per ibernare una sessione, questo è utile quando si sa che una sessione sarà inattiva per un lungo periodo di tempo. Ibernandola è possibile recuperare memoria e altre risorse che si stavano utilizzando. La sessione verrà riesumata automaticamente dal Session WS nel momento in cui un partecipante invierà il prossimo messaggio verso la sessione. L obiettivo del SessionManagerAdmin è quello di gestire il ciclo di vita di una sessione, fornendo azioni che si possono usare per controllarla. Tra di esse sono comprese le funzionalità che abilitano a creare e terminare una sessione, e a cercare una sessione sulla base di alcuni criteri. Ogni sessione è identificata dal suo id univoco, che è generato da questo servizio al momento della creazione. Infine il servizio SessionAdmin è usato per controllare le proprietà di una sessione individuale. Quindi ad esempio per modificare la tabella di istradamento di una sessione, e per aggiungervi partecipanti. Le applicazioni distribuite che sono sviluppate usando CSF usano il componente della Sessione per creare sessioni per il processamento di una richiesta. Queste sessioni forniscono un contesto di collaborazione per i messaggi che i Web Service partecipanti si scambiano. Il ruolo che la Sessione assume all interno delle conversazione è centrale nell ambito delle comunicazioni perché processa ogni messaggio uscente da un determinato partecipante. Prima di creare una sessione, l applicazione deve creare un manifesto per la sessione che contiene le informazioni riguardo ai partecipanti dell applicazione distribuita e riguardo i messaggi che devono essere inviati tra di essi. Ad ogni sessione è associato un manifesto. Questo non è altro che un file XML, definito a tempo di progettazione, ma che può essere esteso dinamicamente a runtime.

79 Tecnologie e strumenti 79 Per ogni richiesta ricevuta dall applicazione distribuita, la sessione fornisce determinati task di collaborazione: Tiene traccia di tutti i partecipanti di una sessione. Instrada i messaggi tra i partecipanti. Fornisce un contesto per le collaborazioni che abbraccia lo scambio di molti messaggi tra i partecipanti. Permette l esecuzione della Service Logic che definisce un flusso per lo scambio di informazioni tra i partecipanti. Assicura che tutte le interazioni tra i partecipanti avvengano in modo sicuro. Implementa l isolamento tra differenti sessioni. Invia appropriati messaggi di notifica dello stato delle conversazioni Service Logic Il componente della Service Logic è un Web Service che fornisce la logica di business per organizzare un applicazione composta da servizi. Le core component di CSF(Session, Identity Manager, Profile Manager, Service Catalog) forniscono un contesto di collaborazione attraverso cui i Web Service possono essere aggregati. CSF fa questo fornendo un framework per la consegna dei messaggi, la gestione delle identità, l autenticazione, e la ricerca di servizi nell ambito di reti di servizi. La Service Logic fornisce le regole e i passi sequenziali per definire l interazione tra i WS. Questo componente fornisce un organizzazione per i servizi che partecipano alla collaborazione. Il seguente diagramma mostra il ruolo giocato dalla Service Logic in un applicazione di servizi che gira nella piattaforma CSF. Figura 41 Ruolo della Service Logic in un'applicazione distribuita

80 Tecnologie e strumenti 80 In questo diagramma, la Service Logic gestisce le informazioni di stato per un applicazione complessa ed invia i messaggi attraverso la sessione verso i partecipanti basandosi sul corrente stato del processo di business. Questi WS possono inviare i messaggi di risposta alla sessione che poi li inoltra alla Service Logic. A seconda dello stato del processo, questi messaggi possono provocare l invio di messaggi di errore, o una transizione di stato, oppure l inizio di un altro processo di business. La Service Logic si comporterà di conseguenza inviando nuovi messaggi alla sessione, o verso uno specifico partecipante, oppure iniziando un nuovo processo di business (aggiungendo un altra Service Logic all applicazione). Il ciclo continua fino a che il processo di business non è completato. Questo componente contiene la logica che modella i processi di business che un servizio composto da più WS fornisce. Si possono usare diversi motori di orchestrazione per implementarla come ad esempio Microsoft BizTalk, o moduli C# come Windows Workflow Foundation framework per la definizione di flussi di lavoro. Una service logic ben fatta afferma i principali concetti SOA di autonomia dei servizi perché incapsula la logica e concilia le dipendenze tra le risorse che sono gestite da altri servizi nel contesto di collaborazione. Questo facilita la riusabilità dei servizi e aiuta a creare servizi componibili che possono essere usati attraverso applicazioni costituite da servizi multipli. Per esempio si consideri il caso di servizi composti che gestiscono un inventario e automaticamente riordinano stock di prodotti presso diversi fornitori, ognuno dei quali presenta un differente contratto verso il cliente. Invece di implementare un sistema di inventario con un insieme di interfacce che abilitano a creare e tracciare ordini per ogni servizio fornitore, si può progettare una service logic che contiene la logica necessaria per soddisfare gli ordini con differenti fornitori. In questo scenario, il servizio d inventario può inviare un messaggio standard alla service logic che contiene i dettagli della richiesta di ordine, includendo il fornitore al quale deve essere inoltrato l ordine. La service logic gestisce i dettagli riguardanti il singolo ordine da fare ad ogni fornitore, magari invocando service logic specializzate a processare l ordine associato ad ogni fornitore. Può poi ritornare un insieme standard di risultati al servizio d inventario sulla base dell output degli ordini. Quindi, la service logic, in questo esempio, ha disaccoppiato completamente il servizio dell inventario dai dettagli dell interazione con i servizi individuali dei fornitori. In questo scenario, nel caso di aggiunta di nuovi fornitori invece di gestire il cambiamento a livello di inventario è possibile semplicemente aggiungere una nuova service logic per gestire gli ordini associati con quel fornitore Identity Manager Il componente dell Identity Manager fornisce servizi di gestione dell identità per i Web Service che operano in ambienti di servizi distribuiti in cui è abilitato CSF. Esso fornisce funzionalità per creare un utente, fornire delle risorse, e controllare gli

81 Tecnologie e strumenti 81 accessi a queste risorse usando servizi sottostanti come Active Directory di Windows Server L Identity Manager supporta anche le funzionalità del singlesign on fornendo un magazzino di dati criptati contenenti le credenziali degli utenti. I servizi che operano nell ambiente CSF spesso gestiscono una o più risorse che forniscono agli utenti o ad altri servizi. Questi servizi devono fornire le risorse che gestiscono solo ad entità autorizzate che possono accedervi. L Identity Manager fornisce funzionalità per la creazione di utenti e gruppi, per la definizione di privilegi e diritti di accesso agli utenti aggiungendoli ad appropriati gruppi e unità di organizzazione. I servizi in un ambiente distribuito devono spesso presentare diverse credenziali a seconda delle applicazioni (o servizi) che vogliono usare. Per esempio, un Web Service che opera all interno dei confini aziendali potrebbe usare funzionalità fornite da un servizio che è ospitato da un altra compagnia; per accedere a questo servizio esterno normalmente occorre presentare altre credenziali chiamate secondarie. Queste sono diverse dalle credenziali che il servizio usa all interno dell azienda. Per memorizzare le secondary credential viene utilizzato Microsoft Enterprise Single Sign on. La Session gestisce le credenziali secondarie per i suoi partecipanti attraverso il concetto di persona participant, che è, un partecipante a vantaggio del quale viene compiuto tutto il lavoro all interno della sessione. E possibile aggiungere l Identity manager come un persona participant nella sessione e poi configurare gli altri partecipanti ad usare le credenziali secondarie per l autenticazione a livello di messaggio o di trasporto, o per entrambe. La Session ottiene dall Identity Manager le credenziali secondarie, che sono poi agganciate al messaggio che è inviato verso il partecipante. Una descrizione più dettagliata di come utilizzare questo componente della piattaforma CSF è affrontata nel paragrafo in cui viene descritto come questo componente è stato utilizzato nell ambito del progetto sviluppato.

82 Tecnologie e strumenti Il Framework.NET 3.0 In questo paragrafo saranno descritti due componenti in particolare che fanno parte del Framework.NET 3.0. Prima di passare alla loro descrizione occorre definire cosa si intende per Framework.NET 3.0. Formalmente chiamato WinFX, questo framework include un nuovo insieme di librerie che si aggiungono a quelle che fanno parte della versione precedente del framework.net, che sono pensate per Windows Vista e Windows Server Longhorn. E disponibile anche una versione per Windows XP e Windows Server Dal punto di vista architetturale non ci sono variazioni rispetto al Framework.NET 2.0 infatti esso include il Common Language Runtime della versione precedente. Figura 42 Architettura del.net 3.0 Il Framework.NET 3.0 consiste di quattro nuovi componenti: Windows Presentation Foundation (WPF): il suo code-name è Avalon. E un sottosistema unificato di presentazione per Windows. Consiste di un motore per la presentazione e di un insieme di classi che permettono di creare applicazioni visualmente sorprendenti e ricche. Il nuovo sottosistema di gestione dell interfaccia grafica è basato su XML e grafica vettoriale. Windows Comunication Foundation (WCF): il suo code-name è Indigo. E un sistema di messaging orientato ai servizi che consente ai programmi di interoperare localmente e da remoto in maniera simile ai Web Service. Nel successivo paragrafo sarà analizzato con maggiore dettaglio.

83 Tecnologie e strumenti 83 Windows Workflow Foundation (WF): è la nuova piattaforma di sviluppo di flussi di lavoro costruita sul Framework.NET. Anche questo strumento sarà trattato nei successivi paragrafi. Windows Card Space (WCS): code-name InfoCard, creato per la gestione di identità virtuali sicure per una nuova gestione dei propri account virtuali e l autenticazione su web. Si potranno creare Infocard personali in cui i dati saranno dichiarati dall utente Windows Comunication Foundation La globale accettazione dei Web Service, che include la definizione di protocolli standard per la comunicazione tra applicazioni, ha cambiato il modo di sviluppare software. Questi cambiamenti si riflettono inevitabilmente negli strumenti che si utilizzano per il loro sviluppo. Windows Comunication Foundation introduce in questo senso un approccio per sviluppare servizi di ambienti distribuiti, fornendo un ampia interoperabilità e un supporto diretto per l approccio service oriented. Il modello di programmazione su cui si basa consente di sviluppare in maniera facile e veloce applicazioni per ambienti distribuiti, ed è per questa ragione che è stato scelto per sviluppare un servizio del sistema distribuito. In realtà ad esso è stato affidato il compito di ricoprire le funzionalità necessarie per far interoperare il servizio sviluppato con WCF con gli altri servizi sviluppati con strumenti differenti. Il servizio, infatti, è stato inserito all interno di un architettura service oriented sviluppata tramite CSF 3.0. Le caratteristiche del modello di servizi che permette di sviluppare si mappano sui concetti base dei Web Service, includendo la possibilità di gestire la sicurezza e l affidabilità nella comunicazione. Si integra bene con le tecnologie Microsoft per i sistemi distribuiti esistenti come ASP.NET Web Service, e Web Services Enhancements. Tramite un esempio concreto si cercherà di esprimere la potenza di questo strumento. Si prenda in considerazione uno scenario in cui occorre sviluppare un applicazione che esponga determinati servizi che devono essere usufruiti da un altra applicazione client facente parte di un organizzazione diversa. I client del servizio possono essere sviluppati con tecnologie diverse, ad esempio costruiti su un server J2EE residente su una piattaforma UNIX. Si supponga che il servizio da fornire, ad esempio, sia un servizio per gestire gli abbonamenti dei clienti alla visione di determinati contenuti video tramite l IPTVe. In questo caso l abbonamento può essere sottoscritto sia tramite un operatore telefonico, che supponiamo sviluppato tramite tecnologia WCF, che tramite il set-up box direttamente da casa dell utente. In quest ultimo caso, quindi, oltre all interoperabilità che occorre garantire, bisogna far sì che il servizio fornisca una risposta in tempi ragionevoli garantendo alte performance. Altro requisito da gestire consiste nella gestione della sicurezza che occorre verificare attraverso applicazioni basate su Windows, ma anche con sistemi sviluppati con J2EE che girano su piattaforme diverse. Non si

84 Tecnologie e strumenti 84 vuole, infatti, che qualsiasi utente possa accedere ai contenuti relativi ad un certo abbonamento ma solo colui che ha sottoscritto l abbonamento. In questo scenario così complesso, sviluppando il servizio con WCF, si riuscirebbe a coprire tutti i requisiti richiesti: Poiché WCF comunica usando Web Services, l interoperabilità con altre piattaforme che supportino SOAP, come ad esempio J2EE, è garantita. WCF, inoltre può anche essere esteso per comunicare con Web Service usando messaggi non basati su SOAP. Per permettere performance ottimali tra applicazioni sviluppate con WCF, questo strumento fornisce una codifica dei messaggi in formato binario in modo tale da rendere più veloce il processamento del messaggio. Poiché WCF supporta un vasto insieme di specifiche WS-*, può gestire facilmente requisiti di sicurezza, affidabilità, e transazioni nella comunicazione con qualsiasi piattaforma basta che anch essa supporti le stesse specifiche. L applicazione sviluppata in WCF che è stata inserita nel progetto, è stata progettata per entrare a far parte di un architettura distribuita sviluppata con CSF. Siccome WCF implementa un maggior numero di specifiche di WS-*, rispetto a CSF, questo determina un restringimento delle funzionalità del framework poiché le specifiche non implementate da CSF nel momento dell interoperazione non possono essere applicate ai messaggi SOAP. Nell interoperazione, quindi, si perdono alcune funzionalità, in particolare WSE, che rappresenta l insieme di librerie che CSF usa per implementare i protocolli WS-*, implementa WS-Security, WS-Addressing, WS- Trust e Ws-SecureConversation; mentre WCF implementa le seguenti specifiche raggruppate per funzionalità: Messaging: SOAP, Ws-Addressing e Message Transmission Optimization Mechanism (MTOM) che definisce un formato ottimizzato di trasmissione per i messaggi SOAP. Metadata: WSDL, WS-Policy che fornisce specifiche per aspetti dinamici del comportamento dei servizi che non possono essere espressi in WSDL. WS- MetadataExchange permette direttamente ad un client di richiedere informazioni descrittive riguardo ad un servizio, come ad esempio le sue policy. Sicurezza: WS-Security, WS-SecureConversation, WS-Trust, e WS- Federation forniscono autenticazione, integrità e altre caratteristiche di sicurezza. Affidabilità: WS-Reliable Messaging per l affidabilità del messaggio. Transazioni: WS-Coordination, WS-Atomic Transaction.

85 Tecnologie e strumenti 85 Quindi l interoperabilità con tecnologie di altre piattaforme è garantita dal fatto che WCF si basa sui meccanismi di comunicazione standard fondati su SOAP, Web Service, e specifiche WS-*. Il principale obiettivo di WCF è infatti quello di unificare in un unico modello di programmazione tutte le tecnologie presenti sul mercato, utilizzando lo stesso codice qualsiasi modalità di trasporto (HTTP, HTTPS, TCP e MSQM). Attualmente, infatti, il panorama è complesso ed esistono diverse tecnologie per creare applicazioni distribuite, ad esempio i Web Service quando si hanno esigenze di interoperabilità, Remoting per la comunicazione di sistemi.net per avere un forte controllo, oppure JAXR (Java API for XML Registries) per l implementazione di Web Service. Sia in ambienti.net, che J2EE, ogni tecnologia ha un suo modello di programmazione e necessita di conoscenze specifiche da parte degli sviluppatori. Di seguito sarà illustrato il modello di programmazione su cui si basa WCF Modello di programmazione WCF è fondato sulla comunicazione basata sui messaggi e su qualsiasi cosa che possa essere modellata come un messaggio che può essere rappresentato in maniera uniforme. Nel modello occorre distinguere tra client e service. I client iniziano la comunicazione e i service sono le applicazioni che aspettano che un client li interpelli. Il concetto centrale oltre a quello di messaggio è quello di endpoint. Un Endpoint rappresenta la porta attraverso la quale un servizio comunica con il resto del mondo. Un applicazione espone uno o più endpoint, un client genera un endpoint compatibile con quello del servizio per potervi comunicare. Un endpoint, quindi, descrive in maniera standard dove i messaggi devono essere inviati, come devono essere inviati, e cosa devono contenere o quanto meno in che forma. Un servizio può esporre queste informazioni come metadati che il client può processare per comunicare. Gli endpoint sono costituiti da tre parti: Address: L address identifica il DOVE del servizio WCF. E l indirizzo al quale il servizio risponde. L indirizzo è composto da un Uri, un Identity e una lista di Headers. In fase di definizione di un Address, l informazione principale è l URI che corrisponde all indirizzo fisico del servizio. Binding: I Binding descrivono COME un endpoint comunica verso l esterno. Permettono di ottenere un modello unico di programmazione senza che quest ultimo si occupi dell infrastruttura di trasporto. Per ottenere ciò, bisogna specificare il metodo di trasporto utilizzato; il formato di codifica utilizzato; i requisiti sulla sicurezza, sulla sessione e sulle transazioni; Inoltre si occupano di quello che avviene tra il momento in cui il servizio spedisce

86 Tecnologie e strumenti 86 logicamente il messaggio ed il momento in cui viene fisicamente messo in rete. In questo lasso di tempo vengono eseguiti numerosi passi che seguono una precisa pipeline di cui i binding sono responsabili. Durante l esecuzione della pipeline il messaggio deve attraversare due layer: - Behavior Layer: si occupa delle trasformazioni che deve subire un messaggio. In questo layer vengono trasformate le informazioni contenute nelle istanze di una classe nel formato XML aderente a SOAP. - Channel Layer: si occupa dell instradamento verso il canale fisico di trasporto. E in questa fase che si istanzia il canale (HTTP, HTTPS, TCP o MSMQ) su cui viaggeranno le informazioni. La gestione dei Binding può essere interamente gestita in fase di configurazione nei file identificati dal CLR come.config. Contract: rappresentano l interfaccia software che il servizio pubblica. I contratti non stabiliscono solo quali operazioni si possono invocare su un servizio, ma anche come e quali dati si possono inviare. Ne esistono tre tipologie: - Service Contract viene usato per definire tutti i metodi che possono essere eseguiti dal servizio. Un servizio ne può avere anche più di uno. Descrivendo le operazioni richiamabili dal client che il servizio fornisce, mappa l interfaccia e i metodi del servizio in una descrizione indipendente dalla piattaforma. Converte le informazioni da CLR in specifiche WSDL; - Data Contract: Descrive la struttura dei dati da inviare. Se si vuole passare dei dati che sono diversi da un semplice tipo, occorre definire un data contract. Permette di definire il formato esterno delle informazioni passate grazie alle operazioni del servizio mappandole dal CLR in un XML Schema; - Message Contract: Descrive la struttura del messaggio. Permette di controllare precisamente la distribuzione delle informazioni nel Body e nell Header. Viene usato per personalizzare i messaggi scambiati dalle entità coinvolte nella comunicazione per controllarne l interoperabilità, incontrando le richieste sulla struttura dei messaggi SOAP fatte dagli altri sistemi. Quando si parla di servizi, ci sono sempre due entità: una è il servizio che, una volta avviato, rimane in attesa di essere invocato; l altra è il client che invia messaggi al servizio. Il client può essere una qualsiasi applicazione anche non scritta con il Framework.NET. Per poter invocare un servizio, il client deve conoscere l interfaccia di

87 Tecnologie e strumenti 87 comunicazione che in WCF è il contratto, quindi, analogamente a quanto avviene ora per i Web Service, è necessario creare un proxy che si interfacci al servizio. WCF integra un tool, chiamato SvcUtil.exe, che permette di creare automaticamente sia il proxy, che il file di configurazione che il client può utilizzare per la connessione. Anche il client comunica con il servizio esponendo un Endpoint, di conseguenza, le informazioni da pubblicare sono le stesse del servizio: l Address, il Binding ed il Contract. I primi due corrispondono ai dati dell endpoint utilizzato dal servizio, mentre il contratto corrisponde alla classe automaticamente generata nel proxy. I passi fondamentali per la creazione di un client sono due: si crea un istanza del proxy; si invoca il metodo. Figura 43 Interazione tra client e service in WCF Anche per il client, qualunque sia il protocollo, i behavior e altro ancora, sarà sempre compito di WCF eseguire la pipeline che porta alle trasformazioni e all invio fisico del messaggio e viceversa alla ricezione della risposta, ripercorrendo la pipeline al contrario.

88 Tecnologie e strumenti Windows Workflow Foundation Windows Workflow Foundation (WF) è un componente importante dell ultima generazione del Framework.NET, chiamato WinFX. E ampliamente disponibile verso tutti i sistemi Windows da XP a Vista passando per Windows Server E possibile individuare alcuni obiettivi chiave di questa tecnologia: - Fornire un singolo motore di esecuzione di flussi per tutte le applicazioni costruite sulla piattaforma Windows. - Supportare un ampia gamma di scenari di applicazione dai flussi incentrati sull intervento umano a quelli strutturati incentrati sulle applicazioni. - Abilitare lo sviluppo di componenti riusabili. WF è principalmente un motore e un framework, non è un prodotto completamente caratterizzato per uno scenario specifico, ma ne supporta diversi; può esprimere processi aziendali relativi a determinate operazioni da eseguire. Occorre in principio chiarire il concetto di workflow. Con esso si intende una rappresentazione logica costituita da passaggi, volta a descrivere un processo reale. In pratica, è un schematizzazione ad alto livello che aiuta a modellare un problema dettagliandone i passi necessari per risolverlo. Modellando alcuni processi aziendali è possibile individuare delle logiche comuni simile tra loro che si ripetono. La conseguenza è che queste similitudini creano ripetizioni di codice spesso simile producendo applicativi poco mantenibile nel tempo. E possibile estrarre da questi procedimenti dei pattern comuni e creare dei modelli condivisi da tutte le applicazioni per rappresentare questi processi. WF permette di fare ciò grazie all utilizzo di un concetto base per la rappresentazione dei vari passi di un workflow l Activity. Con questo termine si intende un attività da eseguire durante il flusso di lavoro. Esistono diverse tipologie di workflow e diverse tipologie di activity che permettono di ricoprire una vasta gamma di scenari applicativi. I workflow possono essere essenzialmente di due tipi state machine e sequencial. Lo stile sequenziale consiste di un insieme di operazioni che devono essere eseguite in sequenza, è generalmente usato per modellare un processo che deve eseguire sempre le stesse operazioni in maniera ripetitiva. Lo stile a stati, invece, viene utilizzato nel caso in cui l esecuzione di una sequenza di operazioni può essere raggruppata in stati e la transizione da uno stato all altro è determinata da un evento. La tipologia delle attività che compongono un workflow variano a seconda della tipologia di quest ultimo. Infatti nel caso di state machine workflow le attività che si dovranno utilizzare per comporre il flusso saranno di diversa tipologia rispetto al caso di quello sequenziale: attività che rappresentano lo stato, la transizione da uno stato ad un altro e attività per la gestione degli eventi generati dall esterno. Nel caso sequenziale invece le attività avranno una connotazione diversa, in primo luogo dovranno essere eseguite in ordine una dopo l altra a differenza del flusso a

89 Tecnologie e strumenti 89 stati in cui l ordine non è prefissato ma dipende dall ordine con cui vengono generati gli eventi esterni, e poi saranno attività composte da altre generalmente di tipo condizionale. Un esempio tipico di attività usata in un flusso sequenziale è la ListenActivity che contiene almeno due attività figlie; ognuna delle quali deve essere un EventDrivenActivity usata per la gestione degli eventi provenienti da altri processi. Questa attività è generalmente usata per gestire un flusso che aspetta la generazione di eventi per continuare la propria esecuzione, e una volta verificato l evento atteso smette di rimanere in ascolto. Questa tipologia è stata ampliamente utilizzata nel progetto perché permette di modellare situazioni di attesa del compimento di una particolare operazione da parte di un Web Service esterno. Questo comportamento coincide al caso in cui la Service Logic deve attendere il risultato dell esecuzione di una funzione esposta da un determinato Web Service per poter continuare la sua esecuzione. Dalle righe precedenti emerge che è possibile creare un canale di comunicazione tra il flusso di lavoro, in realtà tra il processo che ospita il flusso di lavoro, e un altro processo. La comunicazione può essere bidirezionale, sia il workflow può richiamare metodi definiti in un interfaccia implementata da una certa classe, sia questa classe può generare eventi che sollecitino il flusso. Per la gestione dell invocazione di metodi esterni al workflow si definiscono CallExternalMethodActivity, ma il metodo esterno richiamato per essere accessibile deve essere compreso in un interfaccia di comunicazione che deve essere implementata da entrambi i processi che vogliono dialogare. Altro aspetto importante del modello di programmazione definito da WF, è la possibilità di usufruire di una serie di servizi per la gestione della schedulazione delle istanze dei workflow, della persistenza di quest ultime, e delle transazioni Schedulazione dei processi Tutte le istanze di workflow create vengono mantenute in un motore runtime chiamato Workflow Runtime engine. Un istanza di workflow viene ospitata da un processo che può essere un applicazione basata su form, un Windows Service, un Web site, o un Web Service. Per eseguire un workflow è necessario crearne un istanza da far girare all interno del runtime. Lo sviluppatore dovrà inizializzare la classe WorkflowRuntime, avviarla e terminarla: la classe espone i metodi StartRuntime e StopRuntime a questo scopo. Ogni istanza del motore di runtime gira in-process rispetto al processo che la ospita: è possibile ospitare più runtime all interno dello stesso Application Domain.Net e ogni runtime engine può gestire più istanze (cioè più workflow in esecuzione). Dietro le quinte, per default, viene usato il servizio DefaultSchedulerService che lavora in asincrono fornendo una coda che accoglie le istanze da eseguire: in pratica quando si avvia una istanza di workflow, questa viene accodata nello scheduler;

90 Tecnologie e strumenti 90 quest ultimo recupera un thread dal thread pool dell host che ospita il runtime ed esegue il workflow. È possibile configurare, tramite la proprietà MaxSimultaneousWorkflow il numero massimo di thread utilizzabili dallo scheduler, che corrisponde al numero di istanze di workflow che possono girare contemporaneamente. Le richieste accodate vengono processate nel momento in cui si rende disponibile un thread. Utilizzando lo scheduler di default il thread che avvia il workflow viene liberato immediatamente ed eventuali eventi del workflow stesso vengono ricevuti su un thread secondario. È possibile modificare questo comportamento usando, al posto del DefaultSchedulerService, il servizio ManualWorkflowSchedulerService: tramite questo scheduler il workflow gira in sincrono con il thread che lo esegue; lo sviluppatore dovrà avviare manualmente il workflow tramite RunWorkflow. In pratica il thread che avvia l esecuzione del workflow viene usato per far girare il workflow. Lo scheduler manuale consente anche ad una applicazione Asp.Net di mantenere un numero di thread identico fra istanze di workflow in esecuzione e thread usati dal motore di Asp.Net per esaudire le richieste correnti sui workflow. In generale è bene far girare i workflow in asincrono per ovvi motivi (la modalità di default) e ricorrere allo scheduler manuale solo nei casi in cui la strada del flusso asincrono non è percorribile Servizio di persistenza Alcuni processi di business hanno bisogno di lunghi periodi di tempo per essere eseguiti (si parla anche di mesi o anni). In tali casi questi processi per la maggior parte del tempo non sono attivi perché, ad esempio, stanno aspettando un input da altri utenti o da altri sistemi e quindi occorre prevedere un meccanismo che consenta di liberare le risorse per eseguire altre attività. Risulta impraticabile mantenere questi processi in memoria, ma occorre permettere la scalabilità del sistema permettendo di spostare questi processi dalla memoria virtuale verso un mezzo persistente di memorizzazione. In pratica questo servizio consente di salvare lo stato del workflow in alcuni punti della sua esecuzione, e di ripristinarlo quando richiesto. WF fornisce di default un servizio di persistenza chiamato SQLStatePersistenceService, anche se il modello estendibile su cui si basa WF fornisce agli sviluppatori un ampio insieme di opzioni per la gestione della persistenza inclusa la possibilità di creare il proprio servizio di persistenza. E possibile configurare il workflow runtime engine in modo tale da usare il servizio di persistenza nel momento in cui un workflow non è occupato, consentendo di liberare risorse ed aumentando la scalabilità dell applicativo. Si noti che esiste una relazione inversamente proporzionale tra performance e scalabilità: nel momento in cui si liberano risorse dalla memoria virtuale per processare un maggior numero di richieste, favorendo, quindi, la scalabilità, le performance diminuiscono. Nel caso in cui il processamento di una richiesta necessita l utilizzo di un istanza di workflow che

91 Tecnologie e strumenti 91 era stata precedentemente caricata sul DB, il tempo necessario per esaudire tale richiesta è più ampio poiché include i tempi di connessione e accesso al DB.

92 Parte II Progettazione e sviluppo dei test, dell architettura di simulazione dell ambiente IPTVe, e del componente di Tracing

93 Il case study e lo sviluppo dei test 93 5 Il case study e lo sviluppo dei test Nella prima fase del lavoro è stata analizzata la proposta di soluzione effettuata da Microsoft, questo è stato necessario per poter realizzare uno studio del contesto e della realtà d interesse. Nella soluzione si identifica l obiettivo di integrazione che è determinante nella successiva fase di realizzazione. Telecom Italia per ricoprire l esigenza di erogare servizi di TV per il mercato consumer, si è dotata di un infrastruttura di servizi informatici IPTVe di produzione Microsoft. In seguito è nata la necessità di integrare la soluzione IPTVe di Microsoft con i sistemi OSS\BSS di Telecom Italia. Per far questo si è dovuto sviluppare un opportuno layer applicativo di interfaccia tra i due sistemi. Tale integrazione è stata effettuata per passi successivi. I passi che sono stati identificati sono indicati con il nome di: CP0 CP0* CP1 CP2 Ancora prima di passare alla descrizione dello strato di integrazione si illustreranno brevemente i sistemi OSS\BSS perché si ritiene fondamentale acquisire queste conoscenze per poter comprendere la fase di integrazione. Di seguito si cercherà di illustrare i componenti custom costituenti il layer applicativo di integrazione tra la piattaforma ed i sistemi Telecom Italia. Poi si passerà all analisi del processo di testing, effettuato in questo contesto, rivolto a due componenti del sistema: VOD Management ed EPG Management. Saranno dettagliate le considerazioni fatte in questa fase e le scelte effettuate con riferimento alle tecniche e metodologie del testing del software. 5.1 Categorizzazione dei servizi OSS e BSS I servizi Operational Support System (OSS) e Business Support System (BSS) sono i servizi che tutte le compagnie telefoniche hanno. Gli Operational Support Systems (OSS), sistemi per il supporto alle operazioni, sono tutti quei sistemi che vengono utilizzati dalle aziende fornitrici di servizi di comunicazione, per il funzionamento delle reti. Con il termine OSS molto frequentemente si intende sistemi di rete che si occupano insieme alle reti di telecomunicazioni di supportare processi come la manutenzione dell inventario di rete, la fornitura di servizi, la configurazione dei componenti di rete e la gestione dei guasti. Nei tempi passati, le attività OSS erano svolte principalmente da operatori che si scambiavano materiale cartaceo. Successivamente al 1985 si introdussero sistemi informatici (o applicazioni software) che automatizzarono gran parte di queste attività. Ad ogni modo questi sistemi erano isolati tra di loro (si parla spesso di Silos

94 Il case study e lo sviluppo dei test 94 applicativi, ossia di applicazioni verticali che non hanno modo di comunicare tra di esse). Ad esempio, si consideri il caso di un cliente che richiede l'attivazione di una nuova linea telefonica. Il sistema di ordinazione raccoglie i dati dell'utente e della sua richiesta, ma non è in grado di configurare la rete per la realizzazione del servizio. Questa operazione veniva svolta manualmente da un operatore umano che trascriveva le informazioni da un sistema all'altro, con l'inefficienza che ne conseguiva. Negli ultimi anni ci si è dunque focalizzati sulla creazione di interfacce automatizzate tra le applicazioni OSS. A grandi linee si può affermare che l'integrazione tra i sistemi OSS in maniera economica e semplice rimane l'obbiettivo fondamentale delle grandi aziende di telecomunicazione. I Business Support System (BSS), sistemi per il supporto al business, invece sono i componenti che un operatore telefonico usa per fare operazioni di business. Si occupano di supporto a processi come la gestioni degli ordini, il processamento degli acquisti e la collezione dei pagamenti. Il termine BSS non si limita solo agli operatori telefonici che offrono servizi di telefonia ma si applica a fornitori di servizi in tutti i settori come i provider di utility. Classiche tipologie di attività che fanno parte dei servizi BSS sono quelle che devono essere fatte, ad esempio, per prendere un ordine di un cliente, oppure quelle necessarie per la gestione dei dati relativi agli ordini, o agli acquisiti. I BSS sono fortemente collegati agli OSS nello svolgimento dei processi di business definiti all interno di un azienda di telecomunicazioni. Le piattaforme OSS e BSS sono legate al bisogno di supportare vari servizi end-to-end. Ogni area ha i suoi dati e responsabilità di fornire determinati servizi. Il ruolo dei sistemi di supporto al business all interno delle compagnie che forniscono servizi è di ricoprire quattro aree principali: - Gestione dei prodotti: Supporta la vendita e la gestione dei prodotti, delle offerte e pacchetti commerciali rivolti verso i clienti. La gestione dei prodotti generalmente include politiche di sconto, programmi di gestione appropriata dei prezzi e di fedeltà dei clienti. - Gestione dei clienti: Può coinvolgere anche la gestione dei requisiti per la coordinazione dei partner. - Gestione dei profitti: E l attenzione dei sistemi BSS verso la gestione degli acquisiti e dei pagamenti che coinvolge la combinazione dei servizi OSS, prodotti e offerte. La gestione dei profitti supporta OSS Order Provisioning che è il sistema che si occupa della gestione degli account e degli ordini.

95 Il case study e lo sviluppo dei test 95 - Gestione della soddisfazione del cliente. I servizi OSS\BSS forniti da Telecom Italia per l integrazione con la piattaforma IPTVe sono una serie di Web service che vengono utilizzati per effettuare determinate operazioni. I OSS Web service forniscono le funzionalità relative alla gestione dell acquisizione e distribuzione di servizi Live TV, Video on Demand e applicazioni RDP. I BSS Web service, invece, forniscono funzionalità per la gestione degli acquisti, la gestione dei pacchetti di servizi, degli utenti e degli account e dei dettagli di un offerta come il prezzo, la durata e le tasse.

96 Il case study e lo sviluppo dei test Architettura generale del solution design Compresi i concetti generali relativi ai sistemi OSS\BSS, è possibile a questo punto capire come essi si integrino all interno della piattaforma IPTV. Nella Figura 44 è illustrata l architettura generale della soluzione proposta nella fase Cp1. Figura 44 Architettura generale per la fase CP1 Segue una breve descrizione dei componenti dell architettura che sono di interesse per questa tesi. Prima di tutto è possibile classificare le macro componenti illustrate nel grafico sulla base della funzione che hanno nell ambito della piattaforma: - Sistemi esterni: SC, DAM, Applications, PSSC, UAB, FET. - Prodotti: IPTV BUS, IPTVe Platform, STB, OSS/BSS Web service, IPTV Adapter, Billing SBE. - Componenti custom sviluppate: Epg, Vod, Els, IPTVe SBE, IPTV Service Logic. IPTVe: piattaforma Microsoft IPTVe responsabile della erogazione dei servizi Live, VOD e PPV. IPTVe OSS/BSS web service: API esposte dalla piattaforma IPTVe tramite web service ed attraverso le quali è possibile l integrazione dei sistemi di back end. STB (Set-Top-Box): Client IPTVe presente a casa dei clienti fruitori dei servizi erogati dalla piattaforma IPTVe.

97 Il case study e lo sviluppo dei test 97 EPG: componente della IPTVe Shell demandata al caricamento dell Electronic Program Guide (EPG) nella piattaforma IPTVe. VOD: componente della IPTVe Shell demandata alla gestione dei Video On Demand nella piattaforma IPTVe. ELS: componente di estensione della piattaforma IPTVe Shell demandata alla gestione dei meccanismi di logon dei STB. IPTVe Bus: basato su Microsoft CSF 3.0 rappresenta il mezzo attraverso il quale tutte le componenti comunicano tra di loro. Il meccanismo di comunicazione imposto del bus è basato su scambio di messaggi SOAP ed il preferibile uso dei protocolli WS Addressing e WS Security. IPTVe Adapter: componente di Microsoft CSF 3.0 che espone un subset delle API OSS/BSS di piattaforma adeguandoli agli standard WS Addressing e WS Security. IPTVe SBE Adapter: componente propria della IPTVe Shell, rappresenta un gestore dei principali eventi di business pubblicati sul IPTVe Bus. IPTVe Service Logic: Componente propria della IPTVe Shell atta a coordinare le operazioni invocate sull IPTVe Adapter che realizzano i metodi esposti dallo IPTVe SBE Adapter. Billing SBE: componente di Microsoft CSF 3.0 per il trasferimento affidabile attraverso l IPTVe Bus degli eventi di billing (acquisto) occorsi sulla piattaforma IPTVe. IPTVe DR: futura piattaforma di disaster recovery. Service Control: piattaforma di Telecom Italia responsabile dell associazione IP address/cli (customer Line Identifier). E interfacciata dal modulo ELS. PSSC: piattaforma Telecom Italia responsabile di inoltrare sul IPTVe Bus le richieste di provisioning. UAB: piattaforma di Telecom Italia responsabile del mantenimento del profilo utente. DAM: sistema Telecom Italia da cui provengono i VOD e le EPG inserite nella piattaforma IPTVe. FET : piattaforma di Telecom Italia a cui sono demandati, tra gli altri, i seguenti compiti: - mantenimento del catalogo generale. - interfacciamento dei sistemi di BSS. - inoltrare sul IPTVe Bus le richieste di provisioning dei servizi. IPTVe Shell: è lo strato integrativo, noto anche come Integration Layer, che realizza l interfacciamento della piattaforma IPTVe ai sistemi OSS/BSS di Telecom Italia.

98 Il case study e lo sviluppo dei test 98 In questa sede non è interessante entrare nel dettaglio della descrizione dell intero sistema, ma l intento di questa sezione vuole essere quello di fornire una descrizione del contesto in cui sono inseriti gli elementi VOD ed EPG su cui sono stati effettuati i test. In seguito, nel paragrafo 6.2, sarà descritta l interazione tra le parti dell architettura per dimostrare l analogia di questo con il sistema sviluppato. 5.3 Sviluppo dei Test per Cp0 Il progetto IPTV è un progetto di vaste dimensioni, con un architettura composta da molti elementi e di conseguenza per implementare tutte le componenti si è definita una collaborazione tra diverse società. A questo punto Microsoft non ha ricoperto tutto il processo di progettazione, sviluppo e implementazione del software, ma ha affidato in outsourcing parte del lavoro. In questo scenario complesso di collaborazione tra gruppi di lavoro, si è verificata l esigenza di compiere dei test sulle componenti dell architettura sviluppate, per localizzare eventuali errori, anomalie o malfunzionamenti del sistema. Il fondamentale obiettivo dello sviluppo di questi test è stato quello di individuare l origine e la causa dei comportamenti differenti da quanto ci si aspettava dalle specifiche del sistema. Tali anomalie sono generate da cambiamenti nel comportamento del sistema in seguito alla modifica di partecipanti al sistema sviluppati da altri gruppi di lavoro, o da cambiamenti provenienti dai OSS/BSS Web Service situati sul backend o sul branch di riferimento. Questa prima fase di test, nel ambito del lavoro svolto, ha avuto l intento di prendere dimestichezza con le tecnologie e strumenti utilizzati, e di prendere confidenza con la realtà d interesse del progetto. L obiettivo dei test è stato essenzialmente quello di monitorare il comportamento di due componenti sviluppate dal team di Microsoft. La prima è la componente che si occupa della gestione dei VOD (Video on Demand); la seconda è quella componente per la gestione dell EPG (Electronic Program Guide). 5.4 Test per VOD Management I VOD come descritto nel paragrafo 1.6 sono contenuti video che vengono forniti su esplicita richiesta del cliente. Il flusso VOD Management ha come scopo la pubblicazione, l aggiornamento e la rimozione dei Video on Demand (VOD) dalla piattaforma IPTVe. E basato su una soluzione sviluppata con Microsoft BizTalk 2006 Server e grazie all ausilio di alcune Componenti Helper sviluppate utilizzando il Framework.NET 2.0, necessarie per l accesso alla base dati di Integrazione e ai Web Service di piattaforma IPTVe. Operazioni supportate Le operazioni supportate dal sistema sono: Insert di un nuovo VOD Update di Metadati o dei Contenuti media

99 Il case study e lo sviluppo dei test 99 Delete di un VOD esistente L operazione di insert permette di importare un nuovo VOD nella piattaforma IPTVe e renderlo disponibile per l acquisto agli utenti al prezzo determinato dai dati provenienti in ingresso dal DAM. L operazione di update dei Metadati permette di aggiornare le informazioni riguardanti la descrizione, la categoria e quindi il prezzo suggerito agli utenti di un VOD già presente nella Piattaforma IPTVe. L operazione di update dei Media permette di modificare il contenuto del VOD (Movie, Poster e Trailer), di aggiornare la descrizione, la categoria, il prezzo come specificato nei metadati del DAM. L operazione di Delete di un VOD permette di eliminare dalla piattaforma i contenuti e dati relativi. Ognuna di queste operazioni prevede che vengano contattati determinati Web Service della piattaforma Telecom Italia. Questi WS, a seconda dell operazione da eseguire, possono far parte del gruppo relativo ai OSS Web service oppure quello relativo ai BSS Web Service. In ognuno dei casi l obiettivo è quello di verificare in maniera automatica che l operazione vada a buon fine. L esigenza prevalente è stata, quindi, quella di semplicità di gestione della verifica dell esito delle operazioni. In quest ottica la decisione progettuale effettuata è stata quella di definire una applicazione Windows form con un interfaccia molto semplice che si occupasse di effettuare le opportune verifiche. I test sono stati improntati in modo tale da dare la possibilità all utente di poter scegliere tra le tre operazioni da testare (inserimento, aggiornamento, cancellazione). Test dell inserimento di un VOD Il test di questa operazione è stato articolato in modo tale da eseguire il componente del VOD Management dandogli come input un asset VOD, così sono chiamati i file che specificano i metadati di riferimento per uno specifico VOD. L applicazione che compie l inserimento dell asset all interno della piattaforma nel momento in cui termina restituisce in output un file che indica se l operazione è andata a buon fine. A seconda dell esito dell operazione il file viene salvato in due cartelle una per le operazioni terminate con successo (OKFolder) e una per le operazioni terminate con esito negativo (KOFolder). Di conseguenza la prima verifica da fare era quella di controllare se l asset VOD che si era appena cercato di inserire, individuato con un identificativo univoco, fosse presente nella cartella OKFolder, o alternativamente nella KOFolder.

100 Il case study e lo sviluppo dei test 100 Per effettuare questo controllo è stata utilizzata una classe del Framework.NET 2.0 della libreria System.IO.FileSystem che offre la possibilità di ispezionare la tipologia di operazioni (scrittura, lettura, modifica) che vengono eseguite su una data cartella. Controllato ciò, ancora non si aveva la certezza che l asset fosse stato inserito correttamente nella piattaforma. Per accertarsi dell inserimento occorreva fare delle verifiche ulteriori contattando i Web Service della piattaforma. Ad esempio ciascun VOD che può essere inserito può aderire ad un determinato gruppo di appartenenza. Questi gruppi identificano quali sottoscrittori hanno i permessi di visionare il contenuto multimediale che sta per essere inserito associato a quell asset. Quindi se si inserisce un sottoscrittore in un determinato gruppo, e poi si inserisce un asset VOD in quel gruppo, il sottoscrittore, una volta terminato l inserimento, deve essere in grado di vedere il video associato a quell asset. In questo caso, si doveva verificare che l asset inserito fosse stato immesso nel gruppo giusto. Test dell aggiornamento di un VOD I test sull operazione di update di un asset VOD sono analoghi a quelli per l inserimento. La metodologia applicata è simile: si sollecita il componente dandogli in input un asset VOD e poi se ne osserva l esito. Inoltre le informazioni di interesse da verificare a fronte di un aggiornamento sono anch esse analoghe e riguardano prevalentemente la verifica dell appartenenza ai gruppi dei sottoscrittori. Siccome un VOD è composto dal suo contenuto multimediale (il video che viene visualizzato sul client IPTVe) e da una serie di metadati associati ad esso che sono rappresentati nel file di asset, l aggiornamento può quindi coinvolgere sia l una informazione che l altra. Nel caso di aggiornamento dei metadati associati, è possibile aggiornare il prezzo, la categoria di appartenenza (che rappresenta ad esempio il genere del contenuto televisivo), la cost category, etc. A seconda dell informazione aggiornata, la verifica della correttezza dell operazione può essere fatta: Sia interrogando i Web Service: per la tipologia delle informazioni coinvolte che sono prevalentemente dettagli sulla gestione delle offerte i Web service sono BSS. Sia interrogando direttamente il data base nel quale vengono storicizzate tutte le informazioni sui VOD inseriti. Test della cancellazione di un VOD Per la verifica della cancellazione di un asset, occorre accertarsi che l asset non compaia tra gli asset inseriti nella piattaforma. Ciò può essere fatto interrogando gli OSS Web Service che risiedono sul branch. In aggiunta è possibile anche rivolgersi al data base di storicizzazione di queste informazioni. 5.5 Test per EPG Management Nel caso dei test rivolti al componente dell EPG lo scenario è differente.

101 Il case study e lo sviluppo dei test 101 L EPG Management consente di importare, all interno della piattaforma IPTV Edition, le informazioni sui servizi e sulla programmazione di tutti i canali live trasmessi. Il modulo, sviluppato utilizzando BizTalk2006, riceve un file xml in formato Global Listings (GLF) e attiva il processo di inserimento del suddetto file all interno della piattaforma. L esito del processo di inserimento (Eseguito o Non eseguito) viene notificato dal componente tramite l invio di una . Possiamo riassumere il funzionamento dell EPG Management in 4 fasi: Prelievo del file Validazione del file (opzionale) Processo di inserimento Notifica esito In questo contesto i test si sono occupati di verificare la presenza di determinati file all interno di determinate cartelle. Analogamente per il componente del VOD Management anche per l EPG per testarne il corretto funzionamento è stata avviata l esecuzione dandogli in input un file in formato GLF come accennato sopra e successivamente ne è stato osservato l output su opportune cartelle di notifica. I test sono stati effettuati modificando determinati valori di input (i più significativi) sul file e verificando che il componente a fronte delle modifiche si comportasse in maniera conforme a quanto ci si aspettava dalle specifiche. La scelta dei valori da modificare è avvenuta in base ai criteri di validazione che il sistema adottava sul file. 5.6 Considerazioni metodologiche Prima di effettuare i test dei componenti, è stata approfondita la teoria del testing, e di conseguenza sono state fatte delle scelte sulla base di questa analisi. Si descriverà brevemente la definizione di testing, e poi si passerà ad un analisi delle varie metodologie e tecniche. Testing: Attività mirante alla scoperta di eventuali malfunzionamenti del prodotto software dovuti a guasti (anomalie difetti faults bugs - bachi) tramite l esecuzione del codice stesso, fornendogli opportuni dati in ingresso (analisi dinamica). È possibile classificare le tipologie di test che si possono effettuare sulla base della loro granularità. Esistono test a livello di modulo (unit test) o a livello di sistema. Unit test Quando si costruisce un'automobile, non si ci si limita a costruire e ad assemblare i pezzi e alla fine girare la chiave per vedere se tutto funziona. Questo per tre motivi:

102 Il case study e lo sviluppo dei test Alcuni difetti producono malfunzionamenti solo dopo un utilizzo prolungato, ma sono facilmente identificabili esaminando i singoli pezzi prima dell'assemblaggio. - Se dopo aver girato la chiave la macchina non si accende, risulta molto difficile capire qual è il difetto. - Se dopo aver girato la chiave la macchina non si accende, risulta molto costoso smontare la macchina, sostituire il pezzo difettoso e rimontarla. Ragionamenti analoghi valgono per il software. Pertanto, come i singoli pezzi di un macchina vengono sottoposti al controllo di qualità prima dell'assemblaggio, così è opportuno collaudare separatamente le singole componenti di un sistema software. Le componenti collaudabili di un sistema software prendono il nome di "moduli" o "unità", per cui si parla di "collaudo di modulo" (in inglese, si usa l'espressione "unit testing"). Un modulo può avere una granularità variabile da una singola routine, a un insieme di alcune decine di routine, a un sottosistema comprendente migliaia di routine. Nella programmazione orientata agli oggetti la tipica componente da collaudare è la classe, mentre nella programmazione orientata ai servizi la tipica componente da collaudare risulta essere il servizio. Test di sistema Anche se i singoli moduli sono corretti, il sistema ottenuto integrandoli potrebbe non esserlo. Pertanto è sempre necessario collaudare il sistema completo. Per collaudare un sistema completo si deve utilizzare il software in modo il più possibile simile a come verrà utilizzato nella normale operatività, ma con le seguenti differenze: Per il software interattivo, la normale operatività consiste in una persona che interagisce con il software. Questo si ottiene con il collaudo manuale, che è sempre utile, ma ha vari svantaggi. Il collaudo automatizzato di un programma interattivo è difficile da ottenere, se non rinunciando a parte del concetto di normale operatività. Nella normale operatività di un sistema software, per ogni singola installazione del sistema, l'utilizzo segue un certo andamento ripetitivo. Siccome nel collaudo si deve simulare il maggior numero possibile di situazioni, normalmente si rinuncia alla ripetitività tipica delle situazioni reali, e invece si simulano utilizzi molto variegati. Si illustrerà, di seguito, un ulteriore classificazione delle tecniche con le quali è possibile sviluppare i test. White box testing Il collaudo effettuato richiamando direttamente le routine del software da collaudare, viene detto "collaudo a scatola bianca" (in inglese, "white box testing"). Per poter eseguire il collaudo a scatola bianca, il collaudatore deve poter leggere la documentazione delle routine esportate dai moduli, se non addirittura il codice sorgente. Si tratta di un collaudo automatizzato, e

103 Il case study e lo sviluppo dei test 103 tipicamente è utilizzato per il collaudo di modulo, in quanto i singoli moduli non sarebbero altrimenti singolarmente accessibili al collaudatore. Le routine di collaudo a scatola bianca possono essere scritte nello stesso linguaggio con cui è stata scritta l'applicazione, oppure con un altro linguaggio in grado di interfacciarsi con il primo. Il collaudo a scatola bianca, siccome richiede l'interfacciamento con le singole routine, può essere effettuato solamente da un programmatore, anche se non necessariamente un membro del gruppo che ha sviluppato il software da collaudare. Normalmente è effettuato comunque da un membro dell'organizzazione che sviluppa il software. Un vantaggio del collaudo a scatola bianca è che permette di sondare dettagliatamente tutte le casistiche che possono presentarsi. Un ulteriore vantaggio è che l'automazione è più facile ed efficiente, ed inoltre è più facile il debugging, cioè passare dal malfunzionamento alla correzione del difetto, in quanto la segnalazione del malfunzionamento normalmente indica il punto del codice e i valori delle variabili per cui il malfunzionamento si è manifestato. Black box testing Il collaudo effettuato accedendo al software solamente tramite l'interfaccia utente, oppure tramite interfacce di comunicazione tra processi, viene detto "collaudo a scatola nera" (in inglese, "black box testing"). Può essere manuale oppure automatizzato, e tipicamente è utilizzato per il collaudo di sistema, in quanto per collaudare l'intero sistema normalmente non è necessario richiamare singole routine. Se si tratta di un collaudo automatizzato, le routine di collaudo sono prevalentemente scritte in un linguaggio di livello più alto del linguaggio con cui è stata scritta l'applicazione, a volte in un linguaggio progettato appositamente per il collaudo. Il software da collaudare e il software di collaudo costituiscono processi distinti comunicanti. Per il collaudo a scatola nera manuale non è richiesta l'opera di un programmatore, e per quello automatizzato è sufficiente un programmatore con modeste competenze. Spesso il collaudo a scatola nera è effettuato da persone che non fanno parte dell'organizzazione che sviluppa il software; Un esempio di una tecnica di collaudo a scatola nera automatizzata consiste nel registrare l'interazione dell'utente in un file, e poi ripetere la registrazione simulando il comportamento dell'utente. Un vantaggio del collaudo a scatola nera sta, nei casi in cui il codice sorgente e la documentazione di progetto sono segreti industriali, nel fatto che tale collaudo può essere effettuato anche da persone esterne all'azienda.

104 Il case study e lo sviluppo dei test 104 Un altro vantaggio sta nel fatto che per tale tipo di collaudo non sono necessari programmatori esperti e che conoscano gli aspetti interni del software da collaudare. Pertanto, si possono trovare molti più collaudatori, senza dover investire nell'addestramento. Nel caso dei test per Cp0 i test sviluppati si avvicinano di più alla classificazione dei test di sistema, infatti per l obiettivo che ha guidato lo sviluppo dei test gli unit test erano troppo dettagliati. In realtà però la tipologia di testing scelta è un intersezione tra le due illustrate: non sono unit test perché non testano tutti i metodi funzionali di una classe, ma al tempo stesso sono scritti da un programmatore che ha accesso al codice da testare e in parte ne testano alcune funzionalità. Si possono definire unit test fissando e ridefinendo il concetto di unità da testare; invece di identificarla in una classe si può identificarla in una componente di un sistema più complesso (VOD Management, EPG Management). Analogamente alle tipologie di test anche per quanto riguarda le tecniche utilizzate per il collaudo, quella adottata è una via di mezzo tra collaudo a scatola bianca e quello a scatola nera. Simula il comportamento di un client del sistema eseguendo metodi esposti dal componente quindi si avvicina di più al collaudo a scatola nera. Ma per trovare maggiori analogie si dovrebbe ridefinire il concetto di sistema limitandolo a quello di componente di un sistema. Inoltre si discosta da tale tecnica, avvicinandosi al contrario a quella a scatola bianca per via del fatto che lo sviluppatore è interno all organizzazione e doveva avere conoscenze tecniche specifiche per invocare le funzionalità del sistema. Inoltre facendo ricerche nella letteratura del testing è stata trovata un altra classificazione che aggiunge altre tre categorie: test di integrazione - mirato alla correttezza delle interfacce. test di accettazione - imposto dal cliente, verifica che il comportamento del programma sia conforme a quanto scritto sulle specifiche. test di regressione - verifica che non si siano introdotti errori in versioni successive. In base a quest ultima classificazione l attività svolta si può riconoscere nell ultima categoria di test. Infatti lo spirito con il quale sono stati fatti i test sul componente di VOD Management e sull EPG è stato quello di poter verificare la correttezza anche a fronte di cambiamenti introdotti da versioni successive di altri componenti coinvolti.

105 Definizione e sviluppo dell architettura SOA di sperimentazione Definizione e sviluppo dell architettura SOA di sperimentazione Il processo che ha portato alla progettazione e allo sviluppo del componente di tracing ha attraversato una prima fase di comprensione del contesto in cui esso doveva essere inserito. Le ragioni che hanno portato alla definizione di un architettura distribuita orientata ai servizi (SOA) sono state principalmente due. In primo luogo la necessità di simulare l ambiente reale nel quale l elemento sarebbe stato inserito ossia il layer di integrazione tra i servizi OSS\BSS di Telecom Italia e l infrastruttura di servizi informatici IPTVe; la definizione e lo sviluppo dell ambiente di sperimentazione sono stati guidati, in secondo luogo, dall esigenza di comprendere i meccanismi che regolano il funzionamento delle tecnologie applicate all interno del progetto. La realizzazione, in scala minore, dell architettura della soluzione di integrazione progettata da Microsoft ha dato modo di capire in maniera approfondita come i flussi di informazioni viaggino attraverso i partecipanti al sistema e come tali informazioni vengano modificate. Di seguito descriverò ad alto livello il procedimento che ha guidato fase per fase la realizzazione dell intero sistema; inizialmente verranno illustrate le specifiche del sistema, poi come è stata definita l architettura tenendo presenti le linee guida imposte dall architettura reale; in seguito si passerà ad illustrare come i vari membri del sistema interagiscano tra di loro. Verranno poi descritti l analogia e il collegamento dell architettura di sperimentazione con il layer d integrazione con la piattaforma IPTV. A questo punto verrà posta l attenzione sulla fase di progettazione e sviluppo di ogni elemento dal punto di vista delle scelte tecnologiche effettuate e successivamente su come è stato configurato l ambiente di sviluppo e come sono state distribuite le componenti dell architettura sulle macchine disponibili. 6.1 Specifiche del sistema I requisisti che deve soddisfare il sistema sono i seguenti: Requisiti funzionali Il sistema nasce con l obiettivo di simulare in piccola scala l interazione tra le componenti del sistema d integrazione sviluppato da Microsoft tra i servizi OSS\BSS di Telecom Italia e la piattaforma IPTVe. Inoltre la definizione di questo sistema di simulazione è necessaria per l inserimento del componente di tracing; in più grazie all implementazione del sistema distribuito è stato possibile sperimentare in concreto le tecnologie utilizzate nel progetto di integrazione della piattaforma IPTV con i servizi OSS/BSS di Telecom Italia. In questo contesto, quindi, i servizi coinvolti nell architettura devono ricoprire dei ruoli funzionali di sperimentazione e di conseguenza è d interesse superfluo cosa effettivamente offrano sul piano operazionale. In sostanza le

106 Definizione e sviluppo dell architettura SOA di sperimentazione 106 operazioni che espongono sono di poco interesse per l obiettivo finale del sistema, a differenza invece della modalità con la quale cooperano. Si deve disegnare un sistema distribuito orientato ai servizi che consiste di vari elementi: un client, un Session Owner, una Service Logic, un Tracing Component e due servizi VAS1 e VAS2. Tutti questi elementi devono essere i partecipanti a una sessione CSF. Tale framework, come spiegato nei capitoli precedenti, è quello che si occupa dell interazione e comunicazione tra servizi in architetture SOA. Il client si occupa di richiedere un determinato servizio fornito dal sistema. Nel caso in questione non è fondamentale né il servizio richiesto, né la tipologia delle operazioni da svolgere per soddisfare la richiesta. Il vincolo sta nella modalità con cui il servizio viene erogato; per soddisfare la richiesta, in analogia a quanto succede sulla piattaforma IPTVe, si devono coinvolgere due o più servizi (VAS1 e VAS2) e il flusso che regola la modalità con cui si ottiene una risposta da restituire al client deve essere orchestrato tramite una Service Logic. Come descritto sopra la fornitura del servizio si svolge nell ambito di una sessione CSF. La richiesta effettuata dal client deve essere processata da un componente chiamato Session Owner perché ha il compito di gestire l interazione con la Session di CSF. Esso crea una sessione con i partecipanti prestabiliti, e una volta ricevuta la conferma dell avvenuta creazione della sessione da parte della Session manda un messaggio alla Service Logic, altro partecipante alla conversazione. Tale richiesta determina l avvio di un processo che avrà termine solo quando il flusso di attività che è definito all interno della Service Logic non sarà giunto al termine. Quando esso sarà terminato, la Service Logic si occuperà di contattare il Session Owner per comunicargli il risultato delle operazioni. Di conseguenza tale componente si occuperà di inviare alla Session di CSF la richiesta di terminazione della sessione e di notificare il risultato al client. La Service Logic, componente con il compito di orchestrare l interazione tra i servizi coinvolti nel dialogo, ricevuta la richiesta dal Session Owner dà inizio ad un workflow che determina in che ordine contattare i vari servizi. Da adesso in poi è la Service Logic che si occuperà di spedire i messaggi SOAP contenenti le operazioni necessarie per soddisfare la richiesta del client. In questo caso, la richiesta del client contiene due numeri interi, i servizi contattati consentono di fare dei calcoli matematici, e la risposta consiste del risultato dei calcoli eseguiti sui valori ricevuti in input. Requisiti d implementazione Il vincolo più stringente per quanto riguarda gli istrumenti tecnologici da impiegare impone l utilizzo di CSF 3.0 (Connected Services Framework).

107 Definizione e sviluppo dell architettura SOA di sperimentazione 107 L architettura è SOA e quindi deve essere composta da un service bus che è implementato da CSF 3.0. I servizi che partecipano alla comunicazione e che si devono scambiare informazioni possono essere di vario tipo. La scelta di utilizzare CSF impone un vincolo sui protocolli di comunicazione usati tra i servizi; infatti è necessario adottare gli standard che regolano lo scambio di messaggi tra Web Service di conseguenza tali messaggi devono essere implementati con il protocollo SOAP e viaggiano su protocollo applicativo HTTP. CSF fornisce un insieme di componenti ognuna delle quali espone Web Service che sono implementati con Microsoft Web Service Enhancements (WSE) 3.0. Questo fa sì che essi siano in grado di fornire tutte le funzionalità esposte dagli ultimi protocolli sui Web Service, inclusi WS-Security, WS- SecureConversation, WS-Trust, e WS-Addressing. A questo punto qualsiasi tecnologia che consenta lo scambio di messaggi con i vincoli visti sopra è accettabile. Più in generale qualsiasi servizio che dialoghi tramite il protocollo SOAP e che implementi i protocolli WS-* può partecipare alle conversazioni anche se non è in grado di supportare tutte le funzionalità avanzate fornite da WSE 3.0. In breve, i servizi possono essere implementati con qualsiasi tecnologia che permetta la partecipazione ad una sessione CSF: CSFService, implementati con le librerie di CSF, WCFService implementati con le librerie esposte dal framework Windows Comunication Foundation, SOAPService semplici servizi sviluppati con le librerie di WSE 3.0. E importante notare che, grazie alla potenza del framework CSF si poteva pensare di far comunicare servizi implementati con tecnologie come BizTalk Server 2006 grazie all utilizzo di un adapter oppure tecnologie residenti su piattaforme diverse rispetto a Microsoft come Java.

108 Definizione e sviluppo dell architettura SOA di sperimentazione Definizione dell architettura La Figura 45 illustra l architettura del sistema e le connessioni tra i vari componenti. La definizione dell architettura deriva dalle linee guida fornite dall architettura del solution design del progetto dell IPTV in cui si documenta la progettazione del sistema. E per tale ragione che gli elementi del sistema verranno descritti con riferimento all architettura reale in Figura 46, cercando di far comprendere al lettore l analogia tra i due sistemi. Celeste Componenti Client Session Owner Service Logic custom Rosa Connessioni Grigio Prodotti CSF 3.0 Service bus Tracing component VAS1 VAS2 DB Figura 45 Architettura SOA del sistema simulato

109 Definizione e sviluppo dell architettura SOA di sperimentazione 109 Figura 46 Mappatura dell'architettura simulata sulla piattaforma IPTVe I componenti presenti devono essere: Client: nel sistema distribuito ce ne può essere uno o più di uno. Questo ha il ruolo di richiedere l erogazione di un servizio rivolgendosi direttamente al Session Owner. Il client verrà notificato dal Session Owner quando il sistema avrà terminato la sua esecuzione con il risultato richiesto. Il servizio richiesto nel sistema di simulazione è l esecuzione di due operazioni matematiche in sequenza addizione e moltiplicazione. Ricercando l analogia nell architettura IPTV, il servizio erogato può essere identificato nel flusso di gestione di un account; Il flusso di gestione account rappresenta l insieme di azioni eseguite al fine di completare le attività di Creazione, Rimozione, Attivazione, Disattivazione Account sulla piattaforma. Sorgente per questo tipo di flussi sono la piattaforma PSSC e FET. In particolare a PSSC è demandato il compito di inviare le richieste di creazione dell account e modifica dello stato di questo, nonché la variazione dei servizi associati. Alla piattaforma FET è demandato l invio delle richieste di modifica dei contenuti fruibili da parte dell account. Quindi il Client può essere identificato nella piattaforma PSSC, per l analogo ruolo ricoperto. Session Owner

110 Definizione e sviluppo dell architettura SOA di sperimentazione 110 Ha il compito di ricevere dal client le richieste di avvio del sistema e di richiedere la creazione della Sessione con i partecipanti prestabiliti. Deve conoscere tutti i partecipanti alla comunicazione che sono registrati tramite un URI all interno del file Manifest.xml necessario per la creazione della sessione. Deve essere un servizio il cui hosting deve essere fatto in IIS (Microsoft Internet Information Service) per consentire di essere acceduto tramite Internet. Ha il compito di creare una sessione CSF, di richiedere l esecuzione della Service Logic, e poi di notificare il client del risultato al termine dell esecuzione della Service Logic con la chiusura della sessione. Tale elemento può essere identificato nel progetto IPTV nel componente IPTVe SBE. Esso infatti, nel processo di creazione di un account nella piattaforma, assume lo stesso ruolo che ha il Session Owner. E colui che riceve le richieste dalla piattaforma PSSC (Client nel sistema simulato), che si occupa della gestione della sessione CSF. Inoltre si prende in carico di contattare la IPTVe Service Logic, e di notificare PSSC al termine dell esecuzione della IPTVe Service Logic. Service Logic Ha il compito di orchestrare lo scambio di messaggi tra i partecipanti alla comunicazione per fornire il servizio completo richiesto. Ha l obiettivo di definire come le informazioni debbano fluire tra i servizi che devono svolgere le operazioni per fornire la risposta al client. I servizi esibiscono uno l operazione della moltiplicazione e l altro della somma. La Service Logic è definita sulla base dell ordine con cui devono essere richiamati i servizi. Tale componente nell architettura IPTVe è riconosciuta nell IPTVe Service Logic che si occupa di coordinare le operazioni per la creazione di un account. Questo elemento viene sollecitato dall IPTVe SBE analogamente a quanto avviene sulla piattaforma di simulazione dal Session Owner. La service logic ha il compito di eseguire, uno per volta, la sequenza di task indicati in una lista. Ciascuno step corrisponde ad una chiamata dell adapter IPTVe ed alla ricezione della corrispondente risposta. Value-Added-Service (VAS): uno o di più Sono i servizi che espongono operazioni specifiche verso l esterno. Per l obiettivo che si è posto questo sistema non è rilevante che tipo di operazioni implementino i servizi. Essi hanno lo scopo di simulare macro componenti con funzioni articolate che partecipano all architettura IPTVe.

111 Definizione e sviluppo dell architettura SOA di sperimentazione 111 Nel caso specifico sono stati definiti due Value Added Service, uno che espone l operazione aritmetica della moltiplicazione (VAS2) e un altro che espone l operazione di somma (VAS1). I ruoli ricoperti dal VAS1, e dal VAS2 possono essere ricercati in due servizi forniti nella piattaforma. L IPTVe Service Logic nell organizzare le varie azioni da svolgere richiede servizi all IPTV Adapter ed esso fornisce le risposte necessarie, quindi questo potrebbe posto in analogia al VAS1. L IPTVe Adapter ha la funzione di rendere disponibili sul IPTV Bus tutti i servizi forniti dai Web service OSS\BSS. Il VAS2 potrebbe essere, ad esempio, il servizio di Disaster Recovery contattato dall IPTVe Service Logic. Tracing Component: Questo componente deve essere un partecipante alla sessione con il compito di tracciare i messaggi scambiati tra i partecipanti. Lo scopo diagnostico a cui è adibito è utile in un architettura complessa e articolata per cercare di capire in che stato si trovano le componenti in un certo istante. In sistemi di grandi dimensioni, e non solo, è utile sapere se ci sono stati errori nella comunicazione e da dove sono stati generati i messaggi di fault. Questo componente deve essere un servizio implementato con le librerie di CSF e deve essere configurato in maniera tale da essere altamente disaccoppiato dal sistema nel quale deve essere inserito. Questa caratteristica è fondamentale per garantire la riusabilità del componente in contesti tra loro molto eterogenei. Inoltre deve garantire la storicizzazione delle informazioni intercettate tramite l utilizzo di un DB. 6.3 Interazione tra le componenti Di seguito nella Figura 47 si illustrerà il diagramma che descrive l interazione tra i moduli e successivamente nella Figura 48 il flusso di creazione di un account nella piattaforma.

112 Definizione e sviluppo dell architettura SOA di sperimentazione 112 Dynamic Session Client Session Session Mngr Session Owner Service Logic VAS2 VAS1 Start Action Create Session Create Session Create Session Response Orchestrate Orchestrate Add(int, int) Add(int, int) response Add(int, int) Add(int, int) response Multiply(int, int) Multiply(int, int) Multiply(int, int) response Multiply(int, int) response Orchestrate Response Orchestrate Response rmv Session rmv Session Remove Session Completed Start Action Response EXTERNAL BUS INTEGRATION LAYER PLATFORM Figura 47 Diagramma di interazione del sistema di sperimentazione Come si può notare osservando le due figure inserite in questo paragrafo, esiste una forte analogia tra l interazione degli elementi coinvolti nei due sistemi. La relazione tra le componenti è stata ampliamente descritta nel paragrafo precedente, ora si deve limitare il campo di osservazione alla cooperazione. Da notare come a differenza della specificità delle operazioni coinvolte di addizione e di moltiplicazione, Add(int, int) e Multiply(int, int), la struttura dei diagrammi sia esattamente la stessa. Nel sistema reale le azioni da svolgere per creare un account sono specificate nella task list indicata con il nome di Action List. Queste operazioni sono poi eseguite nel giusto ordine dall IPTVe Service Logic con l esecuzione dei comandi Cmd1 fino a Cmdn.

113 Definizione e sviluppo dell architettura SOA di sperimentazione 113 Un ulteriore differenza è da ricercare nell introduzione di una sessione aggiuntiva statica che permette il dialogo tra PSSC\FET e IPTVe SBE. Nel sistema simulato invece è stato scelto di non conservare questa caratteristica, perché non rilevante ai fini della realizzazione del sistema. L introduzione del componente di Tracing e la descrizione della sua collaborazione con le altre parti del sistema verrà descritta più avanti. Dynamic Session PSSC/FET Provisioning Session (S1) Session Mngr IPTV SBE IPTV SL Tracing Component IPTV Adapter <Account Action> <Acount Action> <Acount Action> Action --> Action List Create Session Create Session Create Session Response Orchestrate Orchestrate Cmd1 Cmd1 response Cmd1 Cmd1 response Cmd n Cmd n response Cmd n Cmd n response Orchestrate Response Orchestrate Response rmv Session (S1) rmv Session (S1) Remove Session (S1) Completed <Action Response> <Action Response> <Action Response> EXTERNAL BUS INTEGRATION LAYER PLATFORM Figura 48 Diagramma di interazione per l operazione di creazione di un account

114 Definizione e sviluppo dell architettura SOA di sperimentazione Configurazione dell infrastruttura dell ambiente di sviluppo Nella Figura 49 è mostrata la rete creata per l ambiente di sviluppo. Figura 49 Rete dell'ambiente di sperimentazione I calcolatori partecipanti sono tre: due macchine virtuali ed una fisica. L allocazione di risorse fisiche disponibili sulle macchine virtuali è stata decisa sulla base dei ruoli che tali macchine dovevano ricoprire. Alla macchina Server02 è stato attribuito il ruolo di Domain Controller (DC) e quello di DNS, il Server03 è stato configurato per fare il join al dominio amministrato dal Domain Controller. I concetti associati verranno descritti nei paragrafi successivi. Non ci sono vincoli sulla collocazione delle varie componenti dell architettura sulle risorse fisiche. Il client, i servizi VAS1 e VAS2, il Session Owner, e il Tracing Component sono stati allocati sul Server03 e la Service Logic è stata collocata sul Server01. Da notare che non c era niente in contrario a ridistribuire i servizi sulle macchine in un altro modo. La macchina Server01: Caratteristiche Hardware: Intel Pentium M 1.6GHz. Memoria Ram 570 MB. Hard disk configurabile dinamicamente; Dimensione massima: 16GB; dimensione corrente: 1,6GB. Scheda di rete: indirizzo di rete eth Caratteristiche software: