Indice delle figure

Transcript

Indice delle figure

Indice
Indice
INDICE DELLE FIGURE...................................................................................................................3
SOMMARIO .........................................................................................................................................5
CAPITOLO 1 -
INTRODUZIONE ...............................................................................................7
CAPITOLO 2 -
ARCHITETTURA DI RETE ...........................................................................12
2.1
2.1.1
2.2
2.3
2.4
2.4.1
2.4.2
2.4.3
2.5
2.5.1
2.5.2
2.5.3
2.5.4
2.6
2.7
HOME NETWORK ................................................................................................................13
Il Set Top Box................................................................................................................14
RETE DI ACCESSO ...............................................................................................................16
RETE DI DISTRIBUZIONE METROPOLITANA .........................................................................17
CENTRO SERVIZI IPTV.......................................................................................................18
Caratteristiche generali ................................................................................................18
Load balancer ...............................................................................................................20
Firewall.........................................................................................................................26
OMP APPLICATION ENVIRONMENT ....................................................................................28
Web cache .....................................................................................................................29
Application Server ........................................................................................................30
Database Server............................................................................................................30
WebCAM Server............................................................................................................31
DHCP SERVER ..................................................................................................................33
CONTRIBUZIONE .................................................................................................................34
CAPITOLO 3 3.1
3.2
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.4
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.4.6
3.4.7
IL MODELLO E L’EROGAZIONE DEI SERVIZI......................................35
PROVISIONING E SELF PROVISIONING .................................................................................35
GESTIONE DELLA SICUREZZA..............................................................................................42
SERVIZIO BTV ...................................................................................................................46
Protocollo IGMP (Internet Group Management Protocol) ..........................................46
Distribuzione dei canali Multicast BTV nella rete........................................................50
Selezione e Visione dei canali Multicast BTV...............................................................55
Fruizione del servizio....................................................................................................56
Processo di ingestion ....................................................................................................60
SERVIZIO VOD...................................................................................................................61
Fruizione del Servizio: overview...................................................................................61
Il processo di Ingestion .................................................................................................66
Il formato XML CableLabs 1.1 .....................................................................................67
Pubblicazione dei contenuti (Ingestion)........................................................................71
Acquisto di un VOD ......................................................................................................75
Fruizione di un VOD.....................................................................................................77
XTV Server....................................................................................................................77
CAPITOLO 4 -
IL SOFTWARE DI INGESTION ....................................................................80
4.1
L’ANALISI DEI REQUISITI ...................................................................................................80
4.2
LA SPECIFICA DEI REQUISITI ...............................................................................................85
4.2.1
Modello dello scopo del sistema ...................................................................................85
4.2.2
Modello dei casi d’uso ..................................................................................................87
4.2.3
Modellazione delle attività............................................................................................97
4.2.4
Modellazione delle classi ............................................................................................103
4.3
LA PROGETTAZIONE .........................................................................................................106
4.3.1
Rielaborazione dei casi d’uso .....................................................................................106
1
Indice
4.3.2
La struttura delle classi progetto ................................................................................108
4.3.3
Il modello delle classi di progetto...............................................................................109
4.3.4
Diagrammi di collaborazione .....................................................................................113
4.3.5
Statechart Diagram.....................................................................................................120
4.3.6
Progetto della struttura dati .......................................................................................124
4.3.7
Il progetto dell’interfaccia utente ...............................................................................125
4.4
L’IMPLEMENTAZIONE .......................................................................................................130
4.4.1
Algoritmo generale .....................................................................................................131
4.4.2
La gestione della persistenza ......................................................................................133
4.4.3
Init del sistema ............................................................................................................134
4.4.4
La lettura dati checkInbox ..........................................................................................136
4.4.5
Il parsing dei metadati: checkMetadata .....................................................................136
4.4.6
La distribuzione in sottodirectory: moveAsset ............................................................137
4.4.7
Il gestore della coda....................................................................................................138
4.4.8
La pubblicazione nel database OMP ..........................................................................142
4.5
IL DEPLOYMENT ...............................................................................................................145
4.6
IL TESTING .......................................................................................................................145
CAPITOLO 5 -
CONCLUSONI................................................................................................148
BIBLIOGRAFIA ..............................................................................................................................150
ELENCO DI SIGLE ED ACRONIMI ............................................................................................153
2
Indice delle figure
Indice delle figure
Figura 1 - Architettura Generale ...........................................................................................................13
Figura 2 - Home Network.....................................................................................................................14
Figura 3 - Il STB AmiNET 110 AMINO..............................................................................................15
Figura 4 - Access Network ...................................................................................................................16
Figura 5 - Rete di distribuzione ............................................................................................................17
Figura 6 - Centro Servizi IPTV.............................................................................................................18
Figura 7 - Layout di rete .......................................................................................................................19
Figura 8 - Schema architetturale stadio esterno ....................................................................................21
Figura 9 - Virtual Server and Nodes - Network Map...........................................................................22
Figura 10 - Stralcio Schema architetturale LB3....................................................................................23
Figura 11 - Virtual Server e Pool..........................................................................................................25
Figura 12 - stralcio layout di rete comprendente i firewall ..................................................................26
Figura 13 - Firewall GUI e stralcio delle policy ...................................................................................28
Figura 14 - Environment applicativo della piattaforma ........................................................................29
Figura 15 - Componenti del tool Web Cam..........................................................................................31
Figura 16 - Rappresentazione logica delle connessioni ........................................................................33
Figura 17 - Colloquio di Provisioning ..................................................................................................35
Figura 18 - Assegnazione Indirizzo IP..................................................................................................37
Figura 19 - Self provisioning automatico (primo accesso dell’utente) .................................................41
Figura 20 - Richiesta servizio (accessi successivi al primo).................................................................42
Figura 21 - CA NDS: Distribuzione delle EMM ..................................................................................44
Figura 22 - Algorithm Based System - Distribuzione ECM .................................................................45
Figura 23 - Struttura dei messaggi IGMP .............................................................................................49
Figura 24 - StreamShaper .....................................................................................................................51
Figura 25 - BTV: StreamShaper in clear service ..................................................................................52
Figura 26 - BTV: Scrambled Service....................................................................................................53
Figura 27 - BTV: flusso ricevuto alla Home Network..........................................................................53
Figura 28 - BTV: Componenti dello StreamShaper..............................................................................54
Figura 29 - IGMP: Esempio di General Query .....................................................................................57
Figura 30 - IGMP: Messaggio di Membership Report .........................................................................58
Figura 31 - IGMP: Traccia di uno "zapping"........................................................................................59
Figura 32 - Fruizione di un contenuto VOD .........................................................................................62
Figura 33 - RTSP Redirect....................................................................................................................65
Figura 34 - Distriuzione attraverso Asset Distribution Interface (ADI)................................................67
Figura 35 - Diagramma UML per gli Assset ........................................................................................69
Figura 36 - Struttura dell'Asset CableLabs ...........................................................................................70
Figura 37 - Stralcio della specifica CableLas: Package ........................................................................71
Figura 38 - VOD Pre-Encryption..........................................................................................................74
Figura 39 - VOD Pre-Encryption in dettaglio.......................................................................................74
Figura 40 - Distribuzione dei file..........................................................................................................75
Figura 41 - Richiesta di Acquisto VOD................................................................................................76
Figura 42 - Preparazione VOD dopo acquisto ......................................................................................76
Figura 43 - Struttura di XTV Server .....................................................................................................77
Figura 44 - Esempio di colloquio di acquisto VOD..............................................................................78
Figura 45 - Scopo del sistema - Diagramma di contesto......................................................................86
Figura 46 - Component diagram ...........................................................................................................87
Figura 47 - Modello dei casi d'uso di business .....................................................................................88
Figura 48 - Casi d’uso...........................................................................................................................90
Figura 49 - Caso d'uso "Get Inbox" ......................................................................................................96
Figura 50 - Diagramma delle attività per il caso d'uso Check Inbox ....................................................98
3
Indice delle figure
Figura 51 - Diagramma di Attività per il caso d'uso "Publish Content" .............................................100
Figura 52 - Activity Diagram Pubblicazione VOD Insert...................................................................101
Figura 53 - Activity per Movie File_Update = False.........................................................................102
Figura 54 - Activity Diagram per la pubblicazione di soli metadati ...................................................102
Figura 55 - Diagramma delle classi ....................................................................................................105
Figura 56 - diagramma dei casi d'uso .................................................................................................107
Figura 57 - Package Classi del sistema...............................................................................................109
Figura 58 - Diagramma delle classi di progetto ..................................................................................111
Figura 59 - Pubblicazione manuale: Collaboration diagram...............................................................114
Figura 60 - Sequence diagram pubblicazione manuale.......................................................................116
Figura 61 - Pubblicazione automatica: diagramma di collaborazione ................................................117
Figura 62 - Sequence diagram ............................................................................................................119
Figura 63 - Ticket: Statechart diagram ...............................................................................................120
Figura 64 - Statechart con maggiore granularità.................................................................................121
Figura 65 - Diagramma esteso degli stati ticket..................................................................................122
Figura 66 - Gestione coda dei trasferimenti........................................................................................123
Figura 67 - Diagramma ER.................................................................................................................125
Figura 68 - Interfaccia utente: scheda Main Panel..............................................................................127
Figura 69 - Interfaccia utente: scheda Tools .......................................................................................128
Figura 70 - Interfaccia utente: scheda Service Group .........................................................................129
Figura 71 - Interfaccia utente: scheda Settings ...................................................................................129
Figura 72 - Interfaccia utente: scheda Log..........................................................................................130
Figura 73 - Algoritmo generale...........................................................................................................132
Figura 74 - Modello ad oggetti ADO - stralcio...................................................................................134
Figura 75 - Gestore della coda ............................................................................................................138
Figura 76 - Diagramma di deployment ...............................................................................................145
4
Sommario
Sommario
Questa tesi riporta un’esperienza di progetto di reti di calcolatori e di sviluppo
software svolta nell’ambito di un operatore di telecomunicazioni nazionale e relativa
ad una piattaforma nata per la distribuzione di servizi TV su reti IP su ADSL
(Asymmetric Digital Subscriber Line).
Avendo avuto la possibilità di partecipare al progetto fin dalle sue prime fasi, gli
aspetti affrontati sono molteplici e variegati. I servizi erogati sono Broadcast
TeleVision (BTV), Video On Demand (VOD), Pay Per View, Voice over IP (VoIP),
Fast Internet.
Questo lavoro ha richiesto alcuni periodi di lavoro in Belgio, in cui sono state
studiate questioni di configurazioni network, load balancing e gestione della
sicurezza a livello IP. Ma anche in UK, dove sono state affrontate problematiche di
livello applicativo relative sia all’acquisizione dei video da parte dei content provider
sia alla loro successiva trasformazione per essere poi erogati alla clientela.
Oltre a presentare la soluzione adottata in termini di architetture di rete e servizi,
vengono messe in rilievo alcune problematiche comuni alle piattaforme IPTV.
Per tale scopo sono stati separati e messi a fuoco i due principali servizi: VOD e
BTV. Per ognuno di questi sono stati affrontati gli aspetti di erogazione del servizio
con contenuti sia in chiaro (“clear service”) che sottoposti a encrypting (“scrambled
service”).
A seconda della tipologia di servizio, vengono coinvolti apparati e protocolli di rete
diversi. Infatti, relativamente ai servizi BTV, si fa ricorso a protocolli di Multicast e
tecniche di encrypting in linea, mentre per i servizi VOD si ricorre a protocolli
Unicast e si adotta un pre-processing che sottopone i contenuti prima ad encrypting e
poi alla diffusione verso server dislocati su tutto il territorio italiano.
5
Sommario
In questo processo si colloca un software, sviluppato nell’ambito di questo lavoro,
che facilita ed assiste tutte le fasi di preliminari alla pubblicazione di un content.
L’applicativo, dovendo comunicare con i diversi sistemi, interni ed esterni alla
piattaforma IPTV, è XML based, nel senso che tutte le comunicazioni tra gli enti
conivolti avvengono con protocolli e regole basati su questo linguaggio. Lo standard
“de facto”, adottato anche in questa piattaforma, è rappresentato dalla specifica XML
redatta dai tecnici dei laboratori CableLabs. Attraverso questo set di regole, infatti,
vengono inviati dati e informazioni di controllo che vengono interpretati, dando
luogo a corrispondenti azioni che si propagano dai content provider fino alla user
interface visualizzata sugli apparecchi TV nelle case dei clienti.
Il software rappresenta anche un utile strumento di workflow a disposizione degli
addetti ai lavori, che possono seguire i processi di pubblicazione e gestire eventuali e
particolari problematiche di disservizio. La reportistica fornita, e i log proposti a
diversi livelli di dettaglio, completano le funzionalità del prodotto che ormai è
indispensabile strumento che completa le attività di gestione della piattaforma.
6
Introduzione
Capitolo 1
Capitolo 1
Introduzione
Con servizi IPTV, si intende la distribuzione di flussi audio e video verso gli utenti
che sono raggiunti dal servizio ADSL e che sono quindi collegati ad una rete IP.
Il collegamento tra rete IP e televisore è ottenuto a mezzo di un apparecchio, detto
Set Top Box. Si tratta di un client IP dotato di particolari processori che trattano il
flusso in ingresso ed inviano il segnale video al televisore attraverso un comune cavo
audio video o SCART. Dal momento che i contenuti TV, prima di essere trasmessi
in rete, subiscono un processo di encrypting, I Set Top Box sono equipaggiati di una
smart card, attraverso la quale si realizza l’operazione di decrypting che consente la
fruibilità dei contenuti.
Fondamentalmente le tipologie di flussi video sono distinguibili in due categorie:

Broadcast TV (BTV)

Video on Demand (VOD)

Pay Per View (PPV)
Nel primo caso, il segnale video proviene tipicamente da un canale televisivo
broadcast. La piattaforma ha quindi il compito di sottoporlo alla codifica desiderata,
di trasformarlo con il processo di encrypting e di convogliarlo verso la rete IP che lo
distribuirà ai clienti in modalità Multicast.
7
Introduzione
Capitolo 1
Nel secondo caso, invece, è il cliente a scegliere il contenuto da vedere. Attraverso
il telecomando fornito a corredo del Set Top Box, infatti, accede ad un catalogo di
film dal quale è possibile acquistarne la visione. In tal caso, la piattaforma eroga un
flusso audio video in modalità unicast. Durante la visione il cliente ha a disposizione
i comandi interattivi di un comune videoregistratore (Pause, Rewind, Fast-Forward,
Stop). Il valore aggiunto che fornisce la piattaforma, rispetto al tradizionale modo di
concepire i servizi TV, risiede proprio nella libertà che ha il cliente nell’accesso ai
contenuti multimediali. È il cliente a scegliere cosa guardare e quando guardare.
Nel servizio PPV, l’utente, utilizzando un telecomando, interagisce con il STB per
visualizzare la programmazione TV. Alla scelta di un programma televisivo, la
piattaforma ne consente l’acquisto. Il costo del contenuto PPV sarà addebitato sul
conto telefonico del cliente ed una voce che confermerà l’avvenuto acquisto di un
contenuto in modalità PPV. Una volta acquisito il diritto alla visione del contenuto
PPV il cliente sarà avvertito quando il programma è in corso di inizio. A differenza
del servizio VOD, l’utente è ora tenuto a sincronizzarsi con l’evento che viene
trasmesso con modalità multicast. Allo scopo di agevolare la sincronizzazione con il
cliente, nell’ambito di alcuni giorni, l’evento viene proposto più volte. Anche per tale
ragione, questo servizio viene chiamato Near VOD (NVOD).
Naturalmente, affinché i clienti possano selezionare i vari contenuti tramite
telecomando, è necessario meccanismo che li visualizzi sul televisore, ovvero di una
GUI popolata con i vari contenuti disponibili. Per ottemperare a tale necessità, la
piattaforma dispone di un database che contiene tutte queste informazioni, dette
metadati, e di un sistema che le rende fruibili al Set Top Box. Tale sistema è
realizzato con un Web server che risponde dinamicamente alle richieste del STB che
è dotato di un comune Web browser.
Ma questi non sono gli unici servizi che una piattaforma di questo genere offre. In
generale, infatti, tali servizi si inseriscono nella cosiddetta offerta “Triple Play” per il
Cliente.
8
Introduzione
Capitolo 1
Il modello di questo servizio prevede di offrire al cliente, attraverso la piattaforma
trasmissiva ADSL, l’insieme dei servizi IPTV, di telefonia Voice over IP (VoIP) e di
accesso Internet.
Le prestazioni offerte sono in generale caratterizzate da una diversa priorità. In
particolare:
•
VoIP: alta priorità
•
IPTV: media priorità
•
Fast Internet: bassa priorità (servizio offerto in modalità best effort)
Il controllo di accesso da parte dell’utentza alla rete è effettuato mediante un
sofisticato sistema di controllo degli accessi, fornito da NDS, leader mondiale di
sistemi di protezione. Per prevenire la visione non autorizzata, anche qualora l’utente
abbia effettuato con successo l’accesso alla rete, è previsto un meccanismo di
autenticazione dell’utente e codifica dei contenuti detto Conditional Access. Questi
aspetti si differenziano a seconda della tipologia di servizio BTV o VOD e
impiegano meccanismi che verranno presentati in seguito. Naturalmente, è stata
prevista anche la possibilità di trasmettere video non soggetti a processo di
encrypting. È il caso dei canali cosiddetti “clear service”, ma anche dei trailer dei
film e dei messaggi promozionali.
La piattaforma di gestione è stata fornita ad un operatore di telefonia fissa che
intende lanciarsi sul mercato nazionale dei servizi televisivi. Il lavoro svolto si
colloca quindi sia nell’ambito della messa in opera dell’infrastruttura di rete che, nel
livello applicativo, con lo sviluppo del software descritto in questa tesi.
In particolare, il contributo al livello rete è stato nel seguire le attività di deployment
e testing dell’infrastuttura di rete stessa,
impegno che ha richiesto corsi di
formazione specialistici presso le strutture del fornitore della piattaforma, site in
9
Introduzione
Capitolo 1
Belgio (Anversa). La formazione è stata soprattutto orientata alla conoscenza dei
modi operativi e delle configurazioni di apparati di rete, quali video server, switch
IP, load balancer, firewall. Queste attività, pur non investendo direttamente il piano
applicativo è stata preziosa per l’apprendimento del funzionamento di diversi
apparati ed ha consentito l’approfondimento di problematiche che sono tornate utili
in momenti successivi, specie in fase di gestione delle anomalie del servizio.
Altra attività formativa è stata effettuata presso UK, dove sono stati approfonditi
aspetti relativi ai meccanismi di sicurezza, conditional access, ed alla struttura del
database della piattaforma.
Il carattere trasversale dell’attività formativa è stato il presupposto per lo sviluppo di
un software che svolge una integrazione tra sottosistemi della piattaforma e
l’ambiente esterno, costituito dai fornitori di contenuti, ovvero i content provider. Il
contributo, fornito dal software sviluppato in questo lavoro, si colloca infatti a
cavallo di due sistemi distinti, realizzando così una interfaccia tra essi.
Da un lato ci sono i content provider che forniscono i contenuti in chiaro. Dall’altra
parte c’è la piattaforma stessa che acquisisce il materiale costituito da video,
immagini e metadati, per renderlo fruibile. Il software garantisce che la parte dati,
ovvero i video contenuti multimediali veri e propri vengano eventualmente sottoposti
ad encrypting e poi distribuiti nei server che si occuperanno dello streaming. La parte
metadati di tale materiale dovrà invece popolare il database che gli utenti andranno a
consultare con il telecomando, per la fruizione dei video. Il processo descritto va
sotto il nome di “processo di ingestion” e la tesi ne riporta tutte le fasi.
È stata condotta una analisi dei requisiti secondo tecniche formali e con l’uso di
strumenti ormai tipici dell’ Ingegneria del Software. Le specifiche sono state studiate
e raffinare allo scopo di pervenire ad un modello che rappresentasse il sistema da
realizzare. A questo modello sono state applicati analisi approfondite tese ad
ottimizzare i flussi di lavoro. La specifica dei requisiti si è andata raffinando
10
Introduzione
Capitolo 1
trasformandosi in una specifica di progetto e da questo il “software di ingestion” che
rappresenta il punto di arrivo del lavoro svolto.
Il sistema realizzato è stato sottoposto a test di accettazione ed a stress test, poi
messo in esercizio, dove ormai è diventato un sistema “h24” ormai indispensabile
anello della catena di elementi che offre servizi.
11
Architettura di Rete
Capitolo 2
Capitolo 2
L’infrastruttura predisposta, comprensiva del centro servizi, della rete di
distribuzione a livello nazionale e a livello metropolitano, della rete d’accesso e
dell’home network, è stata progettata per essere idonea, come dimensionamento,
grado di diffusione, livelli di sicurezza e qualità del servizio, alla distribuzione del
segnale video agli utenti potenziali esistenti su tutto il territorio italiano.
L’offerta IPTV si rivolge all’utenza dotata di un collegamento ADSL con banda di
circa 3 Mbit/sec. Tale caratteristica è necessaria per poter fruire video con Transport
Stream (TS) pari Mbit/s. La codifica utilizzata, infatti, prevede l’adozione del
formato MPEG-2 con TS di 2750 Kb/s per il video ai quali si aggiungono 128kb/s
per l’audio. L’eventuale futura l’introduzione della codifica MPEG-4 consentirebbe
di utilizzare bit rate inferiori senza perdita di qualità. La piattaforma adottata impiega
un sistema per la gestione dell’accesso condizionato che differisce a seconda del
servizio richiesto dall’utente [4]. Per tale ragione, le problematiche di accesso
condizionato verranno descritte insieme ai servizi cui esse stesse sono legate.
La realizzazione e la distribuzione dei servizi descritti in precedenza è incentrata
sull’architettura End-To-End, descritta in Figura 1:
12
Capitolo 2
M edi a M a n a ger 5950
DB a nd Apps ser ver s
Sun Fi r eV240
S TB
unicast MW , dhcp, tftp
Th o m so n
ST610 &
D SL 1500
m tftp, LP, C G, PG
AA
SSAA
M
M
S TB
ASAM V5
igmp@ nt
M anag e m e nt NW
Th o m so n
ST610 &
D SL 1500
GE
Acce ntu r e
IP - GBE
O ptical Ring
(DW DM )
VO D & nP VR HP Cl u ster G 3
GE
O PB
BTV Hea dEnd T a nd ber g
SD I ?
Satellite dis h
S TB
A SI ?
QPSK ?
IR D 1..10
MPEG-2
encoders
1..10
IP encapsulator
1.. ?
Th o m so n
ST610 &
D SL 1500
AA
SSAA
M
M
GE
GE
igm p@ nt
Centro Servizi
Rete di
Distribuzione
S
STB
TB
ASAM V5
Rete
d'A ccesso
Th o m so n
ST610 &
D SL 1500
Hom e
Network
Figura 1 - Architettura Generale
Dal layout architetturale è possibile distinguere:

Rete d’accesso:

Rete di distribuzione

Centro Servizi: costituisce l’Head-End a livello nazionale e ospita i
dispositivi BTV, i moduli della piattaforma IPTV quali VOD server, servizi
IP (DHCP, DNS,...) e AS (Application Server). Il Centro Servizi, dopo aver
acquisito i flussi audio/video e informazioni di programmazione, li
ridistribuisce opportunamente attraverso il backbone IP.
2.1 Home Network
La fornitura dei servizi IPTV implica la predisposizione di alcuni apparati a casa
cliente e la soluzione adottata per realizzare l’impianto domestico si basa sulla
tipologia di splitter distribuito, come descritto in Figura 2.
13
Capitolo 2
Rete Telecom
ADSL + POTS
NTR
(Borchia con POTS
Splitter distribuito)
Rete domestica
ADSL + POTS
POTS Splitter
POTS Splitter
ADSL+
POTS
AG
STB
Eth.
Eth.
Figura 2 - Home Network
Il doppino telefonico, proveniente dalla centrale è terminato, attraverso la borchia in
sede cliente, sull’Access Gateway (AG) ADSL.
Il STB è connesso all’AG attraverso un cavo UTP Cat. 5.
Il collegamento fra il STB ed il televisore è realizzato mediante un cavo SCART.
L’utilizzo di POTS Splitter separa le frequenze di fonia da quelle dati. Può essere
valutata anche la possibilità di connettere il STB all’ Access Gateway in modalità
wireless, il che comporterebbe l’introduzione dei moduli Wi-Fi sull’Access Gateway
e sul STB [4].
2.1.1 Il Set Top Box
IL STB utilizzato durante il lavoro è l’AmiNET110 di AMINO, mostrato in Figura 3.
14
Capitolo 2
Figura 3 - Il STB AmiNET 110 AMINO
Di seguito sono indicate le caratteristiche principali dell’apparato.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
La
OS: LINUX
Java Based
Browser: ANT Fresco
Supporto della release OMP utilizzata e certificazione NDS
Output: sono possibili le seguenti opzioni cavo per l’audio/video:
o Composito, RGB, S-Video, Stereo Audio
o PAL and NTSC
o formati 4:3 and 16:9
o Digital Audio via S/P-DIF
Input: 10/100BaseT Ethernet
USB 1.1
IR Remote Control ( gestione Set-Top e TV )
MPEG1 & 2 MP@ML at up to 10 Mbps
Grafica colori a 24 bit con alpha-blending e picture in graphics
Protocollo per ricezione canali: Multicast IPTV (IGMP control)
Protocollo DHCP per richiesta indirizzo IP
Multicast boot optino
Gestione da remoto e software upgrade da rete
Protezione Macrovision
piattaforma è dipendente dal particolare Set Top Box. Questo perché il firmware
dello stesso deve essere in grado di effettuare la navigazione delle EPG. Quelle
elencate, sono le caratteristiche minime richieste ad ogni Set Top Box che si intenda
usare [4].
15
Capitolo 2
2.2 Rete di accesso
La rete di accesso è costituita dai DSLAM (DSL Access Multiplexer) Alcatel
ASAM. E’ mostrata in Figura 4. L’interconnessione con Gb Ethernet degli ASAM
all’infrastruttura DWDM avviene direttamente tramite Gb Ethernet Feeder, attestati
sull’anello ottico per il trasporto del traffico verso il Centro Servizi.
Figura 4 - Access Network
La diversità dei servizi richiede la differenziazione delle caratteristiche di traffico
sulla rete d’accesso così da poter ottimizzarne il trasporto. In particolare, ad ogni
utenza sono stati associati due PVC, tramite i quali, l’Access Gateway è connesso
alle seguenti tipologie di traffico:
1. PVC 8/35 per High Speed Internet;
2. PVC 8/36 per IPTV
Il DSLAM ASAM è configurato per il supporto del Residential Bridging,
funzionalità che permette di associare i differenti PVC alle VLAN metropolitane
definite sull’anello DWDM. In particolare, sull’anello ottico è prevista la definizione
delle seguenti VLAN:
1. VLAN High Speed Internet: convoglia a livello metropolitano il traffico
High Speed Internet di tutti gli utenti;
2. VLAN VOD / BTV / Controllo convoglia a livello metropolitano il traffico
VOD, BTV e di controllo per di tutti gli utenti.
16
Capitolo 2
2.3 Rete di Distribuzione metropolitana
La rete di distribuzione a livello metropolitano, in Figura 5, è basata su tecnologia
Gigabit Ethernet. La gerarchia degli apparati utilizzati prevede un livello Metro, che
acquisisce i flussi Video provenienti dal Centro Servizi IPTV attraverso OPB, ed un
livello Feeder che distribuisce ai DSLAM il bouquet dei canali multicast. Il traffico
Video, che viaggia criptato su tutta l’infrastruttura di rete fra il Centro Servizi IPTV e
il STB, è segregato a livello logico da altri tipi di traffico che potrebbero essere
presenti in rete sulla rete di distribuzione metropolitana. La qualità del servizio è
garantita dalla priorità con cui sono marcati i pacchetti video inviati [4].
Figura 5 - Rete di distribuzione
Gli Edge Router costituiscono il confine tra il Centro Servizio IPTV e la rete esterna.
Si interfacciano, lato rete di distribuzione, con gli apparati Metro MAN GbE di
Roma [4].
17
Capitolo 2
2.4 Centro Servizi IPTV
Il Centro Servizi IPTV è costituito dagli apparati necessari al rilascio dei flussi video
da distribuire in rete, oltre a database, sistemi di bilanciamento del carico di lavoro.
Sono presenti anche firewall, nonché l’hardware ed il software di NDS che
garantiscono l’accesso condizionato.
L’insieme di tutte queste apparecchiature è collocato all’interno di una struttura
progettata per ospitare apparati che forniscono servizi di pubblica utilità, strategici,
quindi in grado di garantire adeguati livelli di sicurezza e di controllo [4].
2.4.1 Caratteristiche generali
Il Centro Servizi IPTV si basa sulla piattaforma di erogazione dei servizi video OMP
integrata, relativamente agli aspetti di security, con il Conditional Access (CA). La
Figura 6, ne descrive sinteticamente la struttura.
Figura 6 - Centro Servizi IPTV
18
Capitolo 2
I flussi video, già codificati al bit rate che deve essere distribuito in rete e provenienti
dalla rete di contribuzione, sono convogliati in ingresso a due Ethernet Switch. Da
questi, i flussi sono stati trasferiti agli encryptor [14] e agli IP encapsulator [13].
Le uscite degli encryptor sono nuovamente convogliate attraverso due ulteriori
switch collegati agli Edge Router, che quindi forniscono connettività verso la
piattaforma di rete utilizzata per la connessione con Il STB.
Nel centro servizi sono installati l’hardware ed il software della piattaforma IP TV
nonché i sistemi di DHCP per assegnazione degli indirizzi dinamici dei STB.
Tutte le macchine utilizzate sono in cluster per la gestione della ridondanza. La
protezione del Centro Sevizi IPTV è garantita dai Firewall (FW) e la distribuzione
del traffico dai Load Balancer (LB). La Figura 7 mostra la struttura dell’ head-end.
19
Switch 5
20
trunk
20
11
20
Switch 3
1.11
21
trunk
19
2.2
DHCP
OMP
DB
Web Caches
192.168.67.11
192.168,66.121
192.168.66.51
192.168.65.201
VIP 192.168.67.14 VIP 192.168.66.127 VIP 192.168.66.63 VIP 192.168.65.254
Vlan 130
Vlan 127
Vlan 126
Vlan 125
SC
192.168.67.37
VIP 192.168.67.38
Vlan 131
.3
1.16
sync
2.1
1.11
DHCP
OMP
DB
Web Caches
OVS
OMCM
192.168.67.12
192.168,66.122
192.168.66.52
192.168.65.202
192.168.66.182
192.168.66.252
VIP 192.168.67.14 VIP 192.168.66.127 VIP 192.168.66.63 VIP 192.168.65.254 VIP 192.168.66.191 VIP 192.168.66.254
Vlan 130
Vlan 127
Vlan 126
Vlan 125
Vlan 128
Vlan 129
.4
1.16
LB3
.129
Vlan 122
11
Switch 4
21
19
2.2
OVS
OMCM
SC
192.168.66.181
192.168.66.251
192.168.67.36
VIP 192.168.66.191 VIP 192.168.66.254 VIP 192.168.67.38
Vlan 128
Vlan 129
Vlan 131
2.1
.130
10.10.35.0/24
VIP .142
22
22
82.54.192.128/28
3
.131
.132
eth3
eth1
FW1
20
eth3
10.10.25.0/24
.10
.20
eth1
19
FW2
management
20
management
eth0
eth 2
eth 2
.147
Trunk
To
Switch 1
eth0
.148
1
1
82.54.192.144/28
Vlan 120
Vlan 120
VIP .158
21
Switch 1
Vlan 122
3
19
Trunk
To
Switch 2
Switch 6
Text
20
21
.146
.145
2.2
LB1
1.16
2.1
.1
sync
Switch 2
2.2
10.10.15.0/24
.2
LB2
1.16
2.1
.193
.194
.195
.196
VIP .206
Edge routers
Figura 7 - Layout di rete
19
82.54.192.192/28
Capitolo 2
2.4.2 Load balancer
Il load balancing viene introdotto per cercare assicurare variazione lineare dei tempi
di risposta al variare delle richieste. In altri termini, contribuisce alla scalabilità del
sistema. L’apparato adottato è il BIG IP 2400 prodotto dalla F5 Networks [15].
Sono stati introdotti due livelli di load balancing, a monte ed a valle dei firewall.
Chiameremo Stadio Esterno la coppia di load balancer che si interfaccia con gli edge
routers, quindi, lato utente (STB). Questo assicura la scalabilità verso i firewall.
Chiameremo Stadio Interno la coppia di load balancers che regola il flusso di
informazioni tra head-end (server) e i firewall. Questo assicura la scalabilità verso la
piattaforma.
Ad ogni stadio, i load balancers sono stati ridondati con tecnica di active/stand-by.
Per tale ragione, sono stati interconnessi tra loro ad ogni stadio per la condivisione
dello stato. Sono anche dotati di un indirizzo IP virtuale che fa sì che essi siano visti
come unica entità di load balancing.
Tutti i load balancer sono dotati di interfaccia ethernet e di indirizzo IP. Sono
configurabili via browser tramite protocollo HTTPS e via SSH.
I due load balancer, LB1 ed LB2, sono connessi attraverso due interfacce ethernet
all’ingresso dei firewall: una connessa verso il lato utente (via access router), l’altra
verso l’ingresso del sistema (attraverso il firewall).
Un’ulteriore interfaccia su ciascun load balancer viene utilizzata per scopi di
gestione. Inoltre, essi sono interconnessi per scambiare informazioni sullo stato. Un
indirizzo IP virtuale (VIP) viene utilizzato dai load balancer per rispondere agli
utenti. In altre parole, piuttosto che utilizzare l’indirizzo fisico di ogni singolo load
balancer, si è preferito virtualizzare la risorsa. Questo per assicurare che, a fronte di
un disservizio di un load balancer, si continui ad avere la possibilità di comunicare
con il sistema passando per l’altro load balancer. Analogamente, un altro VIP viene
utilizzato dai load balancer per rispondere al sistema. Ovvero, piuttosto che
connettersi direttamente all’indirizzo fisico di ogni singolo load balancer, il sistema
potrà comunicare con l’indirizzo virtuale. Questo per garantire che a fronte della
caduta del load balancer, il sistema potrà continuare a funzionare utilizzando l’altro
20
Capitolo 2
load balancer. È possibile, attraverso l’interfaccia di gestione via HTTPS, lanciare
una sessione di console basata su OpenSSH.
Figura 8 - Schema architetturale stadio esterno
La Figura 8 illustra quanto esposto.
La configurazione del Load Balancer 1 (LB1) prevede 4 interfacce corrispondenti ad
altrettante vlan:
•
FW_ext (vlan0): è esposta lato head-end
•
Admin (vlan1): destinata all’amministrazione
•
External (vlan2): è esposta lato utente
•
Sync_failover (vlan4): per la condivisione dello stato tra i 2 load
balancer
Nello stadio esterno, essendo le richieste dell’utenza uniformi per tipologia di
servizio invocato, non sono state adottate particolari regole di load balancing.
L’unica politica adottata è quella di round robin verso i firewall (82.54.192.147 e
.148). Per verificare la disponibilità dei firewall, viene eseguito un polling via ping.
In caso di mancata risposta di uno dei firewall, il pool di destinazione si restringe
all’unico rimasto disponibile. In Figura 9 è visibile la parte della GUI che mostra la
gestione della Network Map.
21
Capitolo 2
Figura 9 - Virtual Server and Nodes - Network Map
La configurazione del secondo Load Balancer (LB2) è identica a quella già
descritta per LB1. La GUI che consente l’amministrazione dei load balancer
prevede numerose funzioni, tra cui:
•
Implementazione di regole definibili dall’utente
•
NAT
•
Statistiche
•
Consultazione di Log con uso di filtri
Come accennato, lo stadio interno provvede alla scalabilità tra livello dei firewall e
lato head-end.
Ogni load balancer dispone di un’interfaccia di configurazione e management via
HTTPS e SSH. Anche a questo stadio, i load balancer sono interconnessi per
scambiare informazioni sullo stato. Sono ridondati in modalità active/stand-by.
Lo stadio interno utilizza un unico indirizzo VIP con il quale viene “visto” dal lato
head-end. Analoga configurazione è stata adottata per l’interfaccia verso i firewall.
22
Capitolo 2
Questo assicura che, a fronte di malfunzionamenti di uno dei load balancer, l’altro
entra in funzione senza provocare disservizio.
Figura 10 - Stralcio Schema architetturale LB3
Nella Figura 10, il load balancer LB4 è stato omesso in quanto simmetrico.
Analogamente a quanto accade per lo stadio esterno, anche qui, allo scopo di
verificare la disponibilità delle destinazioni, viene eseguito un polling su tutti gli
elementi dei pool. In caso di mancata risposta da parte di un host, questo viene
escluso dalla lista di possibili destinazioni, per poi ritornarvi quando si renderà
disponibile. Il polling è stato customizzato per ogni tipologia di servizio o protocollo.
Lo stadio di Load Balancing interno dispone di diverse interfacce atte a distribuire il
traffico su differenti VLAN.
Descrizione della configurazione delle VLAN
•
FW_int: (vlan0)
82.54.192.129
23
Verso
Capitolo 2
Firewall
•
82.54.192.142
VIP Switch
82.54.192.139
DNS
82.54.192.136
HTTP MTA
82.54.192.138
HTTP SKY
82.54.192.140
DHCP SKY
82.54.192.135
RTSP
82.54.192.137
NTP
admin: (vlan1)
192.168.65.153 interfaccia management LB3
192.168.65.156 VIP
•
sync_failover: (vlan2) Collegamento tra i due load balancer 10.10.35.3
LB3
10.10.35.4 LB4
•
int_WC: (vlan3) VLAN Web Cache
192.168.65.201 indirizzo interfaccia verso WC
192.168.65.254 VIP WC
•
int_DB: (vlan4) VLAN DB
192.168.66.51 indirizzo interfaccia verso il DB
192.168.66.62 VIP
•
int_OMP: (vlan5)
192.168.66.121 indirizzo interfaccia verso OMP
192.168.66.126 VIP
•
int_DHCP: (vlan6) VLAN DHCP
192.168.67.11 indirizzo interfaccia verso DHCP
192.168.67.30 VIP
24
•
Capitolo 2
int_SC: (vlan7) VLAN Service Control
192.168.67.36 indirizzo interfaccia verso SC
192.168.67.38 VIP
192.168.67.39
192.168.67.50
192.168.67.51
•
int_OVS: (vlan8) VLAN OVS
192.168.66.181 - indirizzo interfaccia verso OVS
192.168.66.190 – VIP
•
int_CMDM: (vlan9)
192.168.66.251 – indirizzo interfaccia verso CMDM/OVS/XTV-Enc
192.168.66.254 - VIP
192.168.66.250
Il load balancer dispone di Virtual Server. Questi rispondono alle richieste
provenienti dall’esterno e distribuiscono il traffico su appositi Pool con politica
round robin, come mostrato in Figura 11 :
Figura 11 - Virtual Server e Pool
25
Capitolo 2
Ad esempio, per il virtual server DNS, si ha
82.54.192.139:53
0 Pool: Pool_DNS
Ovvero, il traffico in ingresso verso 82.54.192.139:53 viene distribuito al Pool_DNS
e cioè verso gli indirizzi 192.168.66.101 e .102, con politica round robin, sulla porta
53.
La configurazione del Load balancer LB4 è identica a quella di LB3.
2.4.3 Firewall
La protezione della piattaforma è affidata a due firewall montati in configurazione
cluster. l firewall sono stati posizionati tra i due stadi di load balancing visti in
precedenza. In tal modo, il carico in ingresso al blocco firewall risulta bilanciato
dallo stadio esterno ed è possibile mantenere la scalabilità complessiva
semplicemente aggiungendo altri firewall in cluster, come mostra la Figura 12.
Figura 12 - stralcio layout di rete comprendente i firewall
I due firewall, FW1 ed FW2 sono connessi a:
•
stadio interno del load balancing (lato head-end, indirizzato con VIP
82.54.192.142)
26
Capitolo 2
VLAN 120: 82.54.192.128/28
FW1: 82.54.192.131
FW2: 82.54.192.132
•
stadio esterno di load balancing (lato utente, indirizzato con VIP
82.54.192.158)
VLAN 122: 82.54.192.144/28
FW1: 82.54.192.147
FW2: 82.54.192.148
•
interconnessione FW1 – FW2
VLAN 10.10.25.0/24
FW1: 10.10.25.10
FW2: 10.10.25.20
I firewall non proteggono gli streaming server per motivi di performance (essendo
costoso utilizzare firewall capaci di gestire centinaia di strem di molteplici Mbps
ciascuno). Comunque, la soluzione realizzata per questo progetto prevede che i video
server abbiano abilitati appropriati meccanismi di packet filter, in modo che solo le
porte RTSP risultino aperte per la comunicazione con i STB dei clienti, mentre le
altre porte risultino sbarrate.La configurazione del firewall è stata condotta definendo
Network, Nodi e Gruppi ed associando le relative policy. In questo modo, si
definiscono le action da adottare (accept / drop) quando un host / network / group
tenta di accedere ad un service loalizzato in una destination. La destination può
essere host/network/group. Naturalmente, l’host può essere anche identificato da un
VIP (virtual IP address).
Il sistema Firewall adottato è
il NG with Application Intelligence, prodotto
Checckpoint Software Technologies [16]. In Figura 13 e visibile una parte della
GUI.
27
Capitolo 2
Figura 13 - Firewall GUI e stralcio delle policy
2.5 OMP Application Environment
L’ambiente applicativo OMP [7] può essere rappresentato graficamente dalla Figura
14, che ne descrive un’implementazione a livello logico. È possibile riconoscere
blocchi già descritti in precedenza, quali load balancer e firewall, ma si nota la
presenza di altri elementi che andremo ad analizzare in questo paragrafo. In
particolare, si trovano:

Web Cache

Application Server

DataBase Server

Datastore
Gli altri elementi, OVS (Open Video Server) Central ed Edge verranno descritti in
seguito.
28
Capitolo 2
Content Files from
studio providers
OVS Edge
Distributed Servers
OVS Central
Content Library
OMP Server Cluster
IE6 web
browser
platform
App Server
for OMP
Manager
Oracle 9i
RAC
Load
balancers
Load
balancers
DataStore
OMP DB
Servers
OSS API
OMP
OMP ++ OMDM
OMDM ++ OVS
OVS
Schemas
Schemas installed
installed in
in one
one 9i
9i
RAC
RAC implementation
implementation for
for
resilient
storage
&
per
resilient storage & per
formant
formant subscriber
subscriber
transactions
transactions
Web Caches
OMP App
Servers
“Stateless”
“Stateless” App
App Servers
Servers field
field
user
user transactions
transactions related
related to
to
applications
applications and
and account
account
services,
using
clustering
for
services, using clustering for
scalability
scalability and
and highhighavailability
availability
Firewalls
Web
Web caches
caches
service
service user
user
requests
requests for
for
content
content which
which is
is
not
personalized
not personalized or
or
fast
fast changing
changing in
in
time
time (e.g.
(e.g. EPG,
EPG,
images,
images, VoD
VoD titles)
titles)
Firewalls
Firewalls filter
filter all
all
user
user requests
requests
which
which do
do not
not
comply
comply to
to the
the
applicable
rules
applicable rules
(telnet,
(telnet, access
access
to
to other
other hosts,
hosts,
...)
...)
Figura 14 - Environment applicativo della piattaforma
2.5.1 Web cache
I Web Cache sono sistemi software hanno lo scopo di contenere le pagine che più
frequentemente sono richieste da parte dei STB, riducendo così la quantità di
richieste che devono giungere fino agli Application Server .
Come per i firewall, l’impiego di web cache multiple offre ridondanza e scalabilità. I
load balancer assicurano che il totale carico dai STB utenti venga distribuito tra le
web cache disponibili.
In questa particolare architettura ciascun web cache è connesso con una singola
interfaccia ethernet su di una VLAN ridondata per ricevere e rispondere alle richieste
utente.
A fronte della rottura di un singolo web cache, il load balancer sposterebbe il traffico
direttamente dal web cache al server che è logicamente associato con il web server
non utilizzabile.
Una seconda interfaccia ethernet in ciascun web cache è connessa ad una VLAN
ridondata ed utilizzata come relay per le richieste di oggetti non memorizzabili da
parte degli application server.
29
Capitolo 2
Una terza interfaccia Ethernet presente sui web cache è utilizzata per scopi di
gestione.
Esiste una relazione uno-a-uno fra i web cache e gli application server. In altri
termini, il web cache 1 si collega all’application server 1, mentre il web cache 2 si
collega all’application server 2.
In caso di mancanza di servizio del web cache, il load balancer ruoterebbe il traffico
direttamente al corrispondente application server.
2.5.2 Application Server
L’Application Server utilizza il Middleware di OMP [7], ed è costituito dalle
applicazioni client-server della piattaforma IPTV e per organizzare i processi interni
alla piattaforma chiamati durante le diverse fasi del servizio.
Quando oggetti non memorizzabili in cache sono richiesti dai STB utenti, le web
cache effettuano richiesta agli application server.
Come per i firewall e le web cache, gli application server forniscono ridondanza e
scalabilità. Il carico totale dai STB utenti è distribuito tra i web application server
disponibili, passando per le web cache come intermediari logici.
2.5.3 Database Server
Il Database Server contiene le informazioni sui clienti presenti ed il Middleware di
OMP. Così come per i firewall, le web cache e gli application server, i database
server multipli forniscono ridondanza e scalabilità.
In questa particolare soluzione, i database server sono organizzati in un cluster.
Entrambi i database server sono connessi, attraverso una singola interfaccia Ethernet,
ad uno switch ridondato per ricevere e rispondere alle richieste provenienti dagli
application server. Il completo guasto di un singolo switch causerebbe la redirezione
di tutto il traffico sulla web cache ancora raggiungibile.
Inoltre entrambi i database server sono interconnessi da collegamenti Ethernet con
banda a 4 Gb/s, a supporto del cluster.
Un interfaccia Fast Ethernet aggiuntiva è fornita su ciascun database server per scopi
di gestione.
30
Capitolo 2
Lo storage array è interconnesso attraverso una coppia di canali in fibra ottica ai
database server.
2.5.4 WebCAM Server
Il WebCam server è un software per la gestione dei Customer Account. Mediante
tale tool si può attuare:
–
Account management and monitoring
–
Gestione dei Set Top Box
–
ECM Manager (per il conditional access)
–
Reporting
–
System configuration management
–
VOD New Entry
–
EPG Manager Control and Monitoring
–
SKYREP Control and Monitoring
La Figura 15 sintetizza l’architettura funzionale del tool:
Figura 15 - Componenti del tool Web Cam
Le funzionalità che tale strumento mette a disposizione sono molteplici, ma si
riportano le più significative.
Customer Maintenance
•
Create/Edit (Account/User/Inventory)
31
•
Edit subscription
•
VOD status
•
•
–
Verifica di cosa ha comprato/visto un cliente
–
Abilitare l’accesso a un VOD content
Pay per View status
–
Verifica di cosa ha comprato/visto un cliente
–
Abilitare l’accesso a un PPV event
BTV status
–
•
Capitolo 2
Verifica di cosa ha comprato un cliente
Billing status
Provisioning
•
Provisioning status (gestione utenze)
Set Top Box Maintenance
•
Edit/View configuration details
•
Firmware upgrade
•
Remote control (reboot, ping, etc.)
Report
•
VOD (by tile, by period)
•
Pay per View (by event, by period)
•
Subscriptions (by package, by period)
•
BTV (by event, by title)
•
Content provider report (by title, by bundle, etc.)
32
Capitolo 2
SC SERVERS¨ACCENTURE
Service Control
192.168.25.64/26
DATA CENTER
.111
R1
R2
vlan 131
192.168.67.16/27
OMP SERVERS
OMP1
vlan 131
192.168.67.42
DHCP Server
vlan 130
192.168.67.0/27
OMP2
vlan 131
192.168.67.43
SWITCH 4
WEBCAM
172.16.251.4/30
.6
.5
802.1Q
.2
.1
172.16.251.0/30
GE
.22
FTP SERVER
FTP1
vlan mgmt_server 123
192.168.65.98
16-port Sun
StorEdge
2 Gb FC Switch 1
vlan 126
192.168.66.0/26
Cluster
Sun
StorEdg
e 3510
FC
Array
6x73GB
ISDN
.3
802.1Q
TRUNK
16-port Sun
StorEdge
2 Gb FC Switch 2
10.10.35.0/24
.4
GE
802.1Q
SWITCH 3
DB CLUSTER OMP
FIREWALL-ACCENTURE
traffic flow of the ACN devices
Figura 16 - Rappresentazione logica delle connessioni
2.6 DHCP Server
Il DHCP Server assegna gli indirizzi IP che saranno utilizzati dai STB dei clienti una
volta che si siano presentati in rete [31]. È protetto dai Firewall di piattaforma in
modo da accettare solo richieste (DHCP Discovery e Request) provenienti dalle linee
dei STB su cui è stato fatto provisioning dei clienti IPTV.
Il DHCP Server assegna gli IP secondo un criterio geografico: ai STB di un
determinato DSLAM in rete sono assegnati indirizzi appartenenti alla medesima
subnet.
La Figura 16 riporta uno schema logica delle connessioni all’interno dell’head-end.
33
Capitolo 2
2.7 Contribuzione
Il segnale audio/video, prelevato dai broadcaster, viene encodato e incapsulato in IP,
per essere successivamente critptato, mediante uno stadio che viene comunemente
chiamato “di contribuzione”.
All’interno del Centro Servizi IPTV sono presenti tutti i sistemi di compressione,
transcondifica e scrambling dei flussi, provenienti dallo stadio di contribuzione, per
la distribuzione verso l’utenza finale.
La compressione, effettuata in conformità con lo standard MPEG-2, è implementata
con una soluzione composta da una batteria di encoder (uno per canale) in
ridondanza N+1 con commutazione automatica ed immediata sul backup in caso di
guasto [4].
La tecnologia scelta è allo stato dell’arte ed assicura un efficiente livello di
compressione associato alla migliore qualità video possibile per la banda disponibile.
Le caratteristiche delle varie componenti compresse facenti parte del segnale
trasmesso sono le seguenti e sono comunque modificabili.

larghezza di banda del canale IP di trasporto:3.5 Mbit/s

codifica video MPEG2 2750Kb/s

risoluzione video: 480x576

aspect ratio: 4/3

codifica audio 128Kb/s (+128 Kb/s opzionale)
34
Il modello e l’erogazione dei servizi
Capitolo 3
Capitolo 3
In questo capitolo vengono descritti in dettaglio i servizi della piattaforma. Viene
descritta la modalità di funzionamento dei servizi Provisioning e Self Provisioning
intendendo, con questi termini, rispettivamente le operazioni necessarie ad ottenere il
primo ed i successivi accessi alla piattaforma. Verrà illustrato il sistema di sicurezza
adottato e verranno descritti i servizi BTV e VOD, anche qui, con i dettagli relativi
alle rispettive problematiche in termini di sicurezza.
3.1 Provisioning e Self Provisioning
Prima di descrivere il flusso di dettaglio delle informazioni, vengono
sinteticamente, in Figura 17, gli apparati coinvolti durante questa fase.
Figura 17 - Colloquio di Provisioning
35
riportati
Capitolo 3
L’ architettura in figura mostra che sono stati utilizzati due PVC. Il primo (PVC1 –
VPI/VCI 8/36) per il traffico video, mentre il secondo (PVC2 – VPI/VCI 8/35) è
dedicato Fast Internet, VoIP.
La porta LAN utilizzata per raccogliere i flussi video è cablata sul PVC ATM 8/36.
Questa è configurata come
“DHCP transparent” [31] nel senso che il traffico
upstream dei messaggi DHCP (DHCP Discovery e DHCP Request) provenienti dal
STB non è intercettato dal DHCP Server dell’Access Gateway ma inoltrato verso il
DSLAM.
Per il servizio IPTV, il cliente utilizzerà, quindi, il PVC 8/36. Su questo PVC viaggia
sia il traffico multicast relativo ai canali di BTV, sia quello unicast relativo alla
fruizione di contenuti VOD. Infatti, la natura del servizio di tipo BTV (trasmissione
broadcast di tutti i canali disponibili), richiede il trasporto in rete mediante protocolli
multicast. Tutti i canali saranno, quindi, trasportati fino al singolo DSLAM.
All’accensione del Set Top Box, dopo il completamento delle procedure di
caricamento del software e attivazione, il STB stesso si sintonizza sul gruppo di
multicast relativo al primo canale BTV del pacchetto sottoscritto dal cliente.
Attraverso l’utilizzo del telecomando il cliente potrà quindi selezionare un ulteriore
canale o accedere alla Home Page del servizio IPTV.
Per permettere l’espletamento del servizio di IPTV si assume che i dati del cliente
siano caricati nella piattaforma OMP dagli operatori del Service Control (SC) all’atto
del primo accesso al servizio da parte dell’utente. Di seguito è descritto più in
dettaglio l’accesso dell’utente al servizio. Verranno distinti casi in cui si tratti di
primo accesso o di un accesso successivo.Gli apparati coinvolti in questo scambio di
messaggi sono

Set Top Box

DSLAM della rete di distribuzione

DHCP Server

Service Control (SC)

Il sistema di sicurezza per l’accesso condizionale (NDS Conditional Access)
36
Capitolo 3
Il SC è il sistema di gestione clienti che detiene le informazioni relative gli account e
svolge ruoli di Customer Relationship Management (CRM). Il Conditional Access
di NDS [11] verrà invece descritto nel prossimo paragrafo e, contestualmente ai
servizi VOD e BTV, ne verranno descritte le interazioni con la piattaforma IPTV.
STB
DSLAM
DHCP
Service Control
DHCP Discover
DHCP Disc. completo
Richiesta Verifica TK
DHCP Offer
Esito Check
Reject
{OR}
DHCP Request
DHCP Request
Update Network Presence
NP Updated
DHCP ACK
Figura 18 - Assegnazione Indirizzo IP
Vediamo le fasi nel dettaglio [4], riportate anche in Figura 18.
1. All’accensione il STB effettua una richiesta broadcast DHCP (DHCP
Discover) per ottenere dal DHCP Server l’inizializzazione dello stack IP
(assegnazione dell’indirizzo IP, della Subnet Mask, del Gateway e
dell’indirizzo IP del Server DNS).
2. Il DSLAM, a cui è connesso il CPE dell’utente e che funge da DHCP relay
agent, dopo aver ricevuto il pacchetto DHCP effettua le seguenti operazioni:
a. Aggiunge le informazioni dell’opzione 82 suboption 2 (DSLAM IP,
DSLAM MAC, Porta, Slot, VPI, VCI); le informazioni aggiunte
costituiranno la chiave tecnica (TK) da passare a Service Control. La
37
Capitolo 3
TK contiene le informazioni necessarie il riconoscimento della linea
cliente che richiede l’indirizzo IP.
b. Aggiorna il campo Relay IP Address nell’header;
c. Cambia l’IP sorgente del messaggio DHCP, ponendolo uguale
all’indirizzo IP dell’interfaccia su cui era stato ricevuto il messaggio;
d. Cambia l’IP di destinazione del messaggio DHCP, ponendolo uguale
all’indirizzo di unicast configurato per il DHCP server (situato
all’interno del Centro Servizi).
3. Quando il DHCP server riceve il pacchetto di DHCP DISCOVER, deve
interagire con il SC per stabilire se il STB è autorizzato ad accedere ai servizi.
A tal fine, controlla il campo option del pacchetto e cattura le informazioni
relative all’opzione 82 (DSLAM IP, DSLAM MAC, Porta, Slot, VPI, VCI) e
le invia al SC. Questi confronta i dati ricevuti con i corrispondenti campi
memorizzati nel proprio DB:
a. se il confronto ha esito negativo, il SC respinge la richiesta e invia un
messaggio di errore al DHCP server;
b. se il confronto ha esito positivo, il SC assegna i parametri di rete
(Subnet mask, Default gateway, DNS e Time Server) relativi alla TK
ricevuta.
4. Il pacchetto è inviato al DHCP Server, che aggiunge l’IP e le informazioni di
lease time e infine invia il pacchetto di DHCP OFFER al STB
5. Il STB riceve il pacchetto DHCP OFFER e risponde con un pacchetto
broadcast di DHCP REQUEST;
6. Il DSLAM, dopo aver ricevuto il pacchetto DHCP, esegue le seguenti
operazioni:
a. Aggiunge le informazioni dell’opzione 82 suboption 2 (DSLAM IP,
DSLAM MAC, Porta, Slot, VPI, VCI);
b. Aggiorna il campo Relay IP Address nell’header del DHCP;
c. Cambia l’IP sorgente del messaggio DHCP, ponendolo uguale
all’indirizzo IP dell’interfaccia su cui era stato ricevuto il messaggio;
38
Capitolo 3
d. Cambia l’IP di destinazione del messaggio DHCP, ponendolo uguale
all’indirizzo di unicast configurato per il DHCP server.
7. Il DHCP Server riceve il pacchetto di REQUEST, estrae le informazioni
relative all’opzione 82 e l’indirizzo IP richiesto e li invia al SC per aggiornare
la Network Presence (NP);
8. In questa fase, se il SC invia un messaggio di conferma (NP aggiornata), il
server invia un DHCP ACK al STB; altrimenti invia un pacchetto di DHCP
NACK. Le opzioni 60 e 43 del protocollo DHCP [32] contengono anche
l’indicazione del tipo di Client che ha effettuato la richiesta (es.
“Aminoaminet110”): in base all’analisi di questo campo il DHCP Server può
assegnare l’IP solo ai modelli di STB previsti da Telecom Italia.
Di seguito sono descritti in dettaglio le fasi del processo nei casi di prima attivazione
del servizio e nel caso di attivazioni successive.
Caso di prima attivazione
Se si tratta di una prima attivazione, i passi procedono come di seguito descritto. In
caso di accessi successivi al primo, i passi procedono come descritto nel paragrafo
successivo e sono descritti in Figura 19.
9. STB richiede la URL di accesso al servizio IPTV. In realtà quella che gli
verrà proposta, poiché si tratta della prima attivazione, sarà una pagina di
“sign-on page”.
10. OMP richiede l’autenticazione dell’utente attraverso il meccanismo HTTP
Digest (RCF 2617): OMP invia al STB una HTTP Response con codice 401
(Unauthorized).
11. STB invia una ulteriore HTTP Request (Digest RFC 2617) con i parametri
della smartcard (SCID) e STB ID (MAC address).
12. OMP inoltra la HTTP Request a NDS.
13. NDS CA autorizza la smartcard e invia un OK a OMP.
39
Capitolo 3
14. OMP controlla se il cliente si è già registrato in precedenza sulla piattaforma,
controllando lo user account e le informazioni utente nella piattaforma. In
questo caso è la prima volta che il cliente accede al servizio ed è invocato il
processo di registrazione. È stato ha realizzato un meccanismo che consente
alla piattaforma OMP di ottenere i dati per l’attivazione dell’utente (dati di
account, provisioning, etc.) direttamente da Service Control.
OMP richiede dunque al Service Control i dati relativi al Cliente.
15. Service Control invia tutti i dati del Cliente ottenuti durante la fase di preprovisioning.
16. OMP riceve queste informazioni, aggiunge un nuovo account nel sistema e
invia la “Welcome page” al STB per comunicare all’utente la corretta
registrazione.
17. L’utente preme il tasto OK per attivare il suo account in OMP.
18. OMP riceve la richiesta, attiva lo user account e notifica a NDS di attivare la
smartcard dell’utente.
19. NDS invia EMMs alla smartcard dell’utente.
20. Il STB richiede in HTTP la pagina di accesso al servizio IPTV con tutte le
componenti del framework ed i componenti della User Interface (HTML,
Javascript)
21. OMP invia al STB una HTTP Response con codice 401 (Unauthorized).
22. STB invia una HTTP Request con i parametri della smartcard (SC ID) e STB
ID (MAC Address).
23. OMP procede dunque all'invio della HTTP Request a NDS.
24. NDS autorizza l'utente e invia un OK a OMP.
25. OMP invia le pagine di framework e di applicazione al cliente.
40
Capitolo 3
Figura 19 - Self provisioning automatico (primo accesso dell’utente)
Di seguito, invece, è descritto il processo di connessione del STB, autenticazione e
risoluzione dei diritti nel caso di un accesso al servizio successivo al primo, da parte
dell’utente [4], [11].
Caso di attivazioni successive
9. Il STB richiede in http la pagina di accesso al servizio IPTV
10. OMP invia al STB una HTTP Response con codice 401 (Unauthorized).
11. STB invia una HTTP Request con i parametri della smart card (SCID) e
STBID (MAC Address).
41
Capitolo 3
12. OMP invia un messaggio HTTP Request a NDS.
13. NDS autorizza l'utente e invia un segnale di conferma ad OMP.
14. OMP controlla se il cliente si è già registrato in precedenza sulla piattaforma,
controllando lo user account e le informazioni utente nella piattaforma. Nel
caso che il cliente sia stato già registrato su OMP invia le pagine di
framework e di applicazione al cliente.
La Figura 20 riassume queste fasi. Per brevità, si omette la parte di assegnazione
dell’ indirizzo IP. Si assume cioè che il STB ne sia già provvisto.
STB
OMP
NDS CA
HTTP Request Home Page
HTTP Response Code 401
HTTP Request (SC ID + MAC)
Verify CA
OK
HTTP Home Page
Figura 20 - Richiesta servizio (accessi successivi al primo)
3.2 Gestione della sicurezza
Nei paragrafi precedenti si è parlato di Conditional Access NDS quale sistema per il
controllo degli accessi. In questo paragrafo vengono descritte le scelte ed i sistemi
adottati.
42
Capitolo 3
Il sistema NDS CA [11] implica l’utilizzo di una Smart Card (SC) inserita nel Set
Top Box. Tuttavia, il funzionamento si discosta da quello tradizionale dei sistemi di
encrypting. Il sistema NDS è stato progettato proprio per l’industria del broadcast.
Generalmente, i sistemi di conditional access sono basati sul principio della
condivisione, da parte di entrambe le parti, di chiave pubblica / privata. Proprio
questa concezione non si adatta bene al mondo della trasmissione broadcast. In
questo scenario, infatti, solo l’operatore ha l’interesse di mantenere la comunicazione
sicura. All’utente finale non ha interesse nel mantenere segreti i contenuti e, nella
peggiore delle ipotesi, si potrebbe trattare di soggetti intenti a cercare modi per
aggirare la sicurezza
I sistemi basati su chiavi richiedono la trasmissione di chiavi private, anche se in
forma encryptata, ma è proprio questa trasmissione che rappresenta un punto debole
nei sistemi broadcast. Il sistema alla base di NDS parte da un principio diverso. NDS
ha adottato un approccio basato su un algoritmo che non richiede la trasmissione di
“segreti”. Anzi, sia nell’head-end che nel STB esistono algoritmi in grado di ricavare
tali codici.
Inoltre, per i sistemi tradizionali basati sullo scambio di chiavi si possono generare
problemi di gestione della eventuale distribuzione di codici. In altri termini, la
spedizione di chiavi in grado di assicurare ai subscriber la corretta fruizione dei video
richiede una larghezza di banda abbastanza grande. L’approccio basato su algoritmi
memorizzati non si basa sulla diffusione delle chiavi e quindi c’è un evidente
risparmio di banda. Nei sistemi cosiddetti “Key-Based”, quindi, i “segreti” risiedono
nelle coppie public/private key [10].
In un sistema “Algorithm-based”, il “segreto” risiede in un algoritmo. Lo stesso
algoritmo risiede sia in head-end che nella smart card ed è lo stesso per tutti gli
utenti.
Nel sistema CA NDS, per quanto appena esposto, un singolo messaggio di
autorizzazione al servizio, detto Entitlement Management Message (EMM) [11] può
essere usato per autorizzare più utenti per più servizi secondo questo schema:
43
Capitolo 3
Figura 21 - CA NDS: Distribuzione delle EMM
Per il rinnovo delle EMM si segue il flusso illustrato in Figura 21:
1. Una EMM viene generata in head-end. I dati contenuti in tale messaggio sono
uno o più service ID dei programmi da autorizzare e i dettagli delle smart
card da autorizzare. Si ribasisce che nelle EMM non ci sono segreti.
2. La EMM viene firmata elettronicamente da un algoritmo che agisce
dall’head-end
3. La EMM viene distribuita in broadcast sulla rete
4. La smart card, alla ricezione della EMM, ne controlla la validità e quindi
verifica se lei è destinataria di tale messaggio. In caso affermativo, i codici
dei servizi autorizzati, vengono memorizzati nella smart card.
Una volta che le EMM sono state distribuite alle varie smart card, si segue il
seguente processo per la fruizione dei contenuti da parte degli utenti.
1. Lato head-end viene generato un messaggio di controllo di autorizzazione,
detto Entitlement Control Message (ECM). Questo racchiude il Service Id ed
un criterio di accesso (Access Criteria, AC) che contiene a sua volta
informazioni tipo parental control o altre policy che regolano l’accesso al
contenuto. L’ECM non contiene alcuna informazione che possa essere usata a
decriptare il contenuto.
44
Capitolo 3
2. La ECM viene elaborata dall’algoritmo che genera una control word (CW).
Questa, unitamente ad un algoritmo Digital Video Broadcasting-Common
Scrambling Algorithm” (DVB-CSA) è usata, lato head-end per encryptare il
content. Dopo questa operazione, la CW viene distrutta in quanto non più
necessaria.
3. La ECM viene firmata attraverso un algoritmo
4. La ECM viene distribuita in broadcast
5. IL STB che riceve l’ECM ne verifica la firma ed usa l’algoritmo CA NDS per
generare una Control Word.
6. La CW generata da tale algoritmo, lato STB, viene utilizzata con un
algoritmo DVB-CSA per decriptare il contenuto MPEG che può essere fruito.
La Figura 22 illustra il processo descritto.
Figura 22 - Algorithm Based System - Distribuzione ECM
45
Capitolo 3
3.3 Servizio BTV
Tale servizio si basa sulla distribuzione dei canali TV in modalità Multicast [3].
Prima di procedere alla descrizione del servizio è opportuno richiamare alcuni
concetti fondamentali del protocollo multicast utilizzato nella piattaforma.
3.3.1 Protocollo IGMP (Internet Group Management Protocol)
L'utilizzo del multicasting IP nelle reti TCP/IP viene definito come standard TCP/IP
nel documento RFC 1112 "Host Extensions for IP Multicasting" [33]. Oltre alla
definizione dell'indirizzo e delle estensioni host per la modalità di supporto del
multicasting da parte degli host IP, questa RFC definisce anche la prima versione del
protocollo IGMP (Internet Group Management Protocol). La seconda versione è
invece definita nella RFC 2236 "Internet Group Management Protocol (IGMP),
version 2" [1]. Etrambe le versioni forniscono un protocollo per lo scambio e
l'aggiornamento di informazioni sull'appartenenza degli host a gruppi multicast
specifici. Esiste anche la versione 3 del protocollo IGMP, descritta nel documento
RFC 3376 "Internet Group Management Protocol, version 3" [34], ma non
attualmente adottata dalla piattaforma. Con IGMP versione 3, gli host possono
richiedere di ricevere il traffico multicast proveniente da origini specifiche oppure da
qualsiasi origine escludendo un determinato insieme di origini [2].
3.3.1.1 Definizione del multicasting IP
Il traffico IP multicast viene inviato a un solo indirizzo ma viene elaborato da più
host. Il multicasting IP è simile alla sottoscrizione a un notiziario. Così come solo gli
abbonati ricevono il notiziario quando questo viene pubblicato, solo i computer host
che appartengono al gruppo multicast ricevono ed elaborano il traffico IP inviato
all'indirizzo riservato al gruppo [3]. L'insieme di host in ascolto su un indirizzo
multicast IP specifico viene definito gruppo multicast.
Di seguito sono riportati altri importanti aspetti del multicasting IP.

L'appartenenza al gruppo è dinamica, ovvero gli host possono entrare a far
parte del gruppo e abbandonarlo in qualsiasi momento.
46

Capitolo 3
Gli host entrano a far parte di gruppi multicast mediante l'invio di messaggi
IGMP.

I gruppi non sono limitati in quanto a dimensioni e, se i router di connessione
supportano la propagazione del traffico IP multicast e le informazioni
sull'appartenenza ai gruppi, i membri possono essere distribuiti su più reti IP.

Un host può inviare il traffico IP all'indirizzo IP del gruppo senza far parte
del gruppo corrispondente.
3.3.1.2 Assegnazione degli indirizzi multicast
Gli indirizzi multicast IP riservati e assegnati agli host appartengono all'intervallo di
indirizzi della classe D, da 224.0.0.0 a 239.255.255.255. La tabella riportata di
seguito presenta un elenco parziale degli indirizzi della Classe D più conosciuti
riservati per il multicasting IP e registrati presso la Internet Assigned Numbers
Authority (IANA).
Indirizzo
Descrizione
multicast IP
224.0.0.0
Indirizzo di base (riservato).
224.0.0.1
Indirizzo del gruppo multicast All Hosts che contiene tutti i sistemi
che si trovano sullo stesso segmento di rete.
224.0.0.2
Indirizzo del gruppo multicast All Routers che contiene tutti i router
presenti sullo stesso segmento di rete.
224.0.0.5
Indirizzo AllSPFRouters OSPF (Open Shortest Path First).
Utilizzato per inviare informazioni di routing OSPF a tutti i router
OSPF su un segmento di rete.
224.0.0.6
Indirizzo AllDRouters OSPF. Utilizzato per inviare informazioni di
routing OSPF ai router designati OSPF su un segmento di rete.
224.0.0.9
Indirizzo del gruppo RIP Ver. 2. Utilizzato per inviare informazioni
di routing RIP a tutti i router RIP versione 2 su un segmento di rete.
47
Capitolo 3
I singoli indirizzi IP all'interno dell'intervallo riservato alla classe D identificano
ciascun gruppo multicast. L'indirizzo IP riservato a ciascun gruppo viene condiviso
da tutti i membri host del gruppo in ascolto e riceve qualsiasi messaggio IP inviato
all'indirizzo IP del gruppo. Gli indirizzi multicast IP vengono associati a una serie
riservata di indirizzi multicast di controllo dell'accesso ai supporti.
3.3.1.3 Messaggi IGMP
Il protocollo IGMP viene utilizzato per scambiare informazioni sullo stato
dell'appartenenza al gruppo tra i router IP che supportano il multicasting e i membri
dei gruppi multicast. L'appartenenza a un gruppo multicast viene dichiarata dai
singoli host membri, mentre i router multicast eseguono periodicamente il polling
dello stato di appartenenza.
I tipi di messaggi IGMP sono descritti nella seguente tabella:
Tipo di messaggio Descrizione
IGMP
Dichiarazione di
Questo messaggio viene inviato quando un host entra a far parte
appartenenza al
di un gruppo multicast per dichiarare l'appartenenza a uno
gruppo di host
specifico gruppo di host. I messaggi IGMP di dichiarazione di
(Membership
appartenenza al gruppo di host vengono inviati anche in risposta
Report)
a una query di appartenenza inviata da un router. Con il
protocollo IGMP versione 3, nel messaggio di dichiarazione di
appartenenza l'host può richiedere di ricevere il traffico
multicast proveniente da origini specifiche oppure da qualsiasi
origine escludendo un determinato insieme di origini. I rapporti
specifici per origine impediscono ai router abilitati per multicast
di inviare il traffico multicast a una subnet in cui non è presente
alcun host in ascolto. Va però specificato che la piattaforma
adotta la vesione 2 di IGMP.
Query di
Viene
utilizzata
da
appartenenza al
periodicamente il polling di una rete per i membri del gruppo.
48
un
router
multicast
per
eseguire
Capitolo 3
Tipo di messaggio Descrizione
IGMP
gruppo di host
In una query di appartenenza il router può chiedere all'host di
(JOIN)
specificare le preferenze di ricezione del traffico multicast
proveniente da un determinato elenco di origini.
Abbandono del
Questo messaggio viene inviato da un host quando questo
gruppo (LEAVE)
abbandona un gruppo. A tale messaggio, il router reagirà con
una Query per verificare se ci sono ancora membri in tale
gruppo sul segmento di rete.
I messaggi IGMP vengono incapsulati e inviati all'interno dei datagrammi IP come
mostrato nella Figura 23.
Figura 23 - Struttura dei messaggi IGMP
In seguito verranno mostrati i dettagli della comunicazione basata sul protocollo
IGMP e verranno mostrate le tracce raccolte durante la fruizione del servizio. Nel
processo relativo al servizio TV Broadcast, si possono distinguere due componenti
principali, logicamente distinte e indipendenti:
a) Distribuzione dei canali Multicast BTV nella rete
b) Selezione e visione dei canali Multicast BTV da parte dell’utente
I canali multicast IP-BTV devono essere presenti sulla rete di distribuzione prima
che possano essere selezionati e instradati attraverso la rete fino al STB in qualsiasi
momento.
49
Capitolo 3
Si ribadisce che il controllo di accesso da parte dell’utente alla rete è stato effettuato
mediante verifica della chiave tecnica (TK) associata alla linea del sottoscrittore del
servizio. Per prevenire la visione non autorizzata, anche qualora l’utente abbia
effettuato con successo l’accesso alla rete, è previsto il meccanismo di autenticazione
dell’utente e codifica dei contenuti (Conditional Access).
3.3.2 Distribuzione dei canali Multicast BTV nella rete
I canali TV possono provenire da una varietà di sorgenti e in diversi formati. Questi
sono processati attraverso un insieme di apparati (Encoders, Multiplexer, ASI
Switches/Routers e StreamShapers) e successivamente inviati nel backbone della rete
di distribuzione come flussi IP multicast, utilizzando IGMP. In generale, i canali
sorgenti BTV, in formato analogico o digitale in banda base, sono inviati a
codificatori MPEG-2 real time, ciascuno dei quali produce un SPTS (Single Program
Transport Stream) codificato al Constant Bit Rate (CBR) stabilito per il susseguente
trasporto in rete.
L’insieme delle uscite degli encoder è inviato alle unità
StreamShaper, ingressi del processo di encrypting del segnale. Ciascuno
StreamShaper è configurato in modo tale che siano specificati, per ciascun canale, i
parametri del servizio, i parametri del flusso multicast IP e gli Static Access Criteria
(es. Parental Rating, ecc.) [13].
La protezione dei contenuti BTV è fornita attraverso un modello di sicurezza multilivello, che utilizza:

autenticazione degli utenti sulla piattaforma attraverso autenticazione
DIGEST HTTP [35]

invio cifrato di messaggi ECM
per accedere al contenuto codificato
(Conditional Access NDS)

controllo di accesso ai diritti per la decifrazione del contenuto attraverso
l’invio di particolari EMM (Entitlement Management Message).
Analizziamo con maggiore dettaglio le funzionalità di Encoder e StreamShaper.
50
Capitolo 3
3.3.2.1 Encoder
L’apparato scelto per l’encoding del flusso video è il Tandberg E5710 [17]. Si tratta
di un encoder MPEG-2 ottimizzato per sistemi multichannel ed anche per Single
Programme Transport Stream (SPTS). È dotato di una scheda con un encoder video
due encoder audio (dual standard MPEG-1 layer 2 / Dolby Digital).
L’alta qualità dell’encoding video è assicurata da algoritmi di riduzione di rumore ed
altri algoritmi, proprietari e standard, di compressione.
Il video viene può essere fornito in input in formato Serial Digital Interface (SDI)
oppure composito analogico (PAL/NTSC) . Le funzionalità audio sono molteplici e
supportano diversi bit rate e modalità di codifica. L’output dell’unità è un transport
stream multiplexato in formato DVB ASI.
Visto il suo ruolo di puro encoder, in questa trattazione non verranno approfondite le
funzionalità dello stesso, né le problematiche legate alle modalità di codifica dei
video.
3.3.2.2 StreamShaper (SSP)
Il ruolo dello StreamShaper, fornito dalla NDS [13], è lo streaming della BTV over
IP. Le attività dello streamshaper si possono riassumere in:

Ricezione del flusso video sorgente tramite interfaccia DVB-ASI in modalità
Multiple Programme Transport Stream (MPEG-2)

Trasmissione in multicast di Single Programme Transport Stream

Encryption real-time di streaming di tipo MPEG-2
Figura 24 - StreamShaper
51
Capitolo 3
Se si tratta di un servizio “in chiaro” (“clear service”), ovvero che non richieda
l’encrypting del contenuto MPEG-2, lo StreamShaper trasmette il flusso MPEG-2
incapsulato in Multicast IP su determinate porte. Tale flusso sarà ricevuto nella home
network dal STB che, inviando messaggi IGMP (Leave, Join) al M-Router, ovvero al
DSLAM, si associa ai diversi gruppi di multicast rendendo fruibile il video. Quanto
esposto è riportato in Figura 25:
Figura 25 - BTV: StreamShaper in clear service
Se trattasi di contenuti da sottoporre ad encrypting, lo StreamShaper opera in
“Scrambled Service” [13].
In queste ipotesi, è necessaria l’interazione con apparati che provvedono
all’encrypting. In fase di configurazione dello StreamShaper, l’operatore definisce
alcuni criteri di accesso ai contenuti (Access Criteria). Questi possono essere sia
caratteristiche del video che del modo di fruizione (es. parental control). Lo
streamShaper viene attivato. Alla ricezione del flusso video in ingresso, lo SSP
genera alcuni codici, detti “control word” e li usa per criptare i contenuti.
Successivamente, invia criteri di accesso e control word all’ECMG (ECM
Generator). Questo genera l’ECM e, con la control word, invia ad un host detto
“Secure Segnature Host” (SSH) per la firma della ECM. Successivamente, L’ SSH
restituisce una ECM firmata all’ECMG che restituisce allo SSP l’ECM firmata. A
52
Capitolo 3
questo punto, lo StreamShaper trasmette le ECM allo stesso IP multicast alla stessa
stregua di un contenuto, ma ad una porta incrementata di 1 [13].
Bisogna notare che lo SSP cambia le control word ad intervalli di tempo regolari,
detti “criptoperiod” e genera nuove ECM. Ticamente un criptoperiod vale circa 10
secondi.
In Figura 26 è riportato il flusso descritto.
Figura 26 - BTV: Scrambled Service
Una volta instradrato il flusso, questo viene ricevuto dal STB presente nella home
network (Figura 27):
Figura 27 - BTV: flusso ricevuto alla Home Network
Qui, infatti, il STB riceve sia le ECM che il content. Attraverso la Smart Card, viene
verificata la firma delle ECM e viene eseguito un check delle control word rispetto
alle informazioni memorizzate nella stessa. Se l’accesso è consentito, la Smart Card
53
Capitolo 3
genera la control word per decriptare il contenuto usandola insieme ad un algoritmo
DVS-CSA.
Nella documentazione elettronica a corredo della tesi, viene riportata una scheda
degli StreamShaper utilizzati, che include configurazione hardware e software.
Qui è interessante analizzare l’architettura dello StreamShaper onde capire meglio il
funzionamento. Dalla Figura 28 si osserva il layout dello SSP [13].
Figura 28 - BTV: Componenti dello StreamShaper
L’application Software alla base dello SSP è composto da

Web Browser GUI

StreamShaper Server Service

NDS SCS Service (SimulCrypt Synchroniser)

SNMP Agent
Ci soffermiamo sul servizio server. È lui il componente core ed è reso servizio di
Windows. È responsabile dell’invio degli “access criteria” allo SCS e da questo
54
Capitolo 3
riceve indietro le ECM che poi usa per encriptare lo stream selezionato per la
protezione.
Altro componente importante è lo SCS (SimulCrypt Synchroniser). Anch’esso opera
come servizio windows. In un sistema che lavora con questo processo, vengono
utilizzate due control word: la SCW (SymulCrypt CW) e la CW tradizionale. Il delta
tra le due CW viene aggiunto alle ECM. Quindi la SCW può essere ricavata dalla
CW rigenerata dal STB e leggendo il delta dalla ECM.
Il SimulCrypt Synchroniser riceve quindi le ECM dallo StreamShaper Server ogni
“criptoperiod” (10 secondi). Calcola il delta e comunica con il generatore di ECM
(ECMG)
per far scrivere il delta nella ECM. Se il servizio SCS dovesse
interrompersi o cessare, lo SSP continuerebbe a svolgere il suo lavoro ma le ECM
non cambierebbero [13].
La configurazione in campo è stata ridondata. Questo perché se lo SSP dovesse
arrestarsi, si avrebbe l’interruzione del servizio. Per tale ragione, gli SSP vengono
monitorati, attraverso la rete di management, tramite SNMP. Anche L’ECMG viene
sottoposto a tale controllo. Alcuni StreamShaper sono quindi posti in stand-by e tutti
contengono la configurazione completa del servizio BTV. Al verificarsi di un
failover, il software di controllo (MaxView, un SMNP Manager) attiva
automaticamente uno degli StreamShaper in stand by, ordinando a questo di caricare
la configurazione dello StreamShaper fuori servizio.
Come accennato, le uscite provenienti dai diversi StreamShaper, vengono aggregate
da switch e inviate alla rete di distribuzione. I contenuti sono così disponibili in rete
per la selezione e l’instradamento verso gli utenti finali.
3.3.3 Selezione e Visione dei canali Multicast BTV
L’ end user può visualizzare i canali BTV a lui disponibili sullo schermo TV, che
mostra una pagina HTML detta EPG (Electronic Program Guide).
55
Capitolo 3
Ad ogni utente può essere associato un pacchetto di canali BTV. La generazione
della EPG è effettuata a mezzo di una richiesta al database di OMP che contiene,
appunto, il profilo utente.
Come vedremo nei paragrafi successivi, il cliente finale può, attraverso la
navigazione sulla EPG, richiedere di vedere il programma desiderato selezionando lo
stesso sulle pagine dell’EPG.
3.3.4 Fruizione del servizio
In generale, le fasi in cui si articola la fruizione del servizio sono le seguenti:
1. connessione del STB alla piattaforma
2. autenticazione
3. scarico sul STB dei diritti relativi alla sottoscrizione del singolo
Cliente
4. scarico sul STB delle chiavi di decrypting per l’accesso condizionato
5. popolazione della EPG con i dati relativi alla sottoscrizione BTV del
cliente
6. visione del primo canale della lista dei canali abilitati
7. visione/zapping
L’intero bouquet di canali è disponibile al DSLAM. Al momento della connessione il
STB si unisce al gruppo di multicast relativo al primo canale fra quelli abilitati. Una
volta che il primo canale sia stato ricevuto è possibile fare zapping (IGMP v2 fra
STB e DSLAM).
Riguardo al punto 5, va sottolineato che le EPG vengono popolate con i dati presenti
nelle tabelle di OMP. Tali tabelle, a loro volta, riportano la programmazione fornita
dai content provider a mezzo di file XML [8] conformi ad una ben precisa specifica
[6]. Nel paragrafo relativo al servizio VOD, verrà analizzata questa specifica e quindi
forniti ulteriori dettagli sul colloquio XML based con i content provider.
Vediamo nel dettaglio un esempio di comunicazione, unitamente alle tracce raccolte
con il software “Ethereal”.
La RFC 2236 [1] descrive i dettagli del protocollo. I router multicast usano il
protocollo IGMP per apprendere se hanno membri collegati alla loro rete fisica. Un
56
Capitolo 3
router multicast detiene una lista di appartenenze ai gruppi per ogni rete, insieme con
un timer di appartenenza. La RFC 2236 specifica però che non è necessario
mantenere una lista di tutti i membri di un gruppo. Basta la presenza di almeno un
membro.
Va detto che un router multicast può assumere due ruoli: Querier o Non-Querier.
Generalmente c’è sempre un Querier per ogni rete fisica. Tutti i router multicast
cominciano la loro attività come Querier su ogni rete alla quale sono collegati. Se
però un router riceve un messaggio di Query da un altro router avente deve diventare
un Non-Querier su quella rete. Se un router non riceve alcun messaggio di Query
entro un determinato intervallo di tempo detto “Other Querier Present Interval”, esso
assume il ruolo di Querier. I Router inviano periodicamente, ovvero ogni “Query
Interval”, un messaggio detto “General Query” su ogni rete alla quale sono connessi
in qualità di Querier, allo scopo di ottenere informazioni di appartenenza ai gruppi.
Tipicamente, per questioni di affidabilità, vengono inviati più messaggi di Query
successivi, molto vicini tra loro in termini temporali. Le “General Query” sono
inviate al gruppo multicast di tutti gli host (224.0.0.1), hanno un indirizzo 0.0.0.0 ed
hanno un Max Response Time pari al “Query Response Interval” [1].
In Figura 29, è riportato un esempio di questo tipo di messaggio, tracciato con
Ethereal.
Figura 29 - IGMP: Esempio di General Query
Alla ricezione di un messaggio “General Query”, un host setta un timer per ogni
gruppo cui appartiene (sull’interfaccia dalla quale ha ricevuto il messaggio. Ogni
timer ha un valore differente e scelto a caso nell’intervallo (0, Max Response Time].
57
Capitolo 3
Fatto analogo accade alla ricezione di un messaggio “Group-Specific Query”. Alla
scadenza di tali timer, l’host invia una messaggio di
“Membership Report” al
gruppo, settando il TTL del protocollo IP ad 1. Questo messaggio conferma,
appunto, l’appartenenza al gruppo. La Figura 30 mostra quanto esposto.
Figura 30 - IGMP: Messaggio di Membership Report
Quando un host vuole associarsi ad un gruppo di multicast, invia un messaggio “non
sollecitato” di Membership Report (anche detto “Join”), settando l’indirizzo del
destinatario pari a quello del gruppo di multicast che desidera. Infatti potrebbe
essere il primo membro di quel gruppo sulla rete. Per una maggiore affidabilità, la
RFC 2236 [1] suggerisce di inviare tale messaggio un paio di volte, a piccolo
intervalli di tempo l’uno dall’altro. Ed è proprio ciò che è stato previsto nella
piattaforma IPTV.
Quando un host desidera lasciare un gruppo di multicast, lancia un messaggio “Leave
Group” a tutti i router. Il querier accetta tale messaggio e, allo scopo di verificare se
ci sono altri host interessati all’appartenenza a tale gruppo, manda una query al
gruppo. Tale query riporta un tempo detto "Last Member Query Interval”. Se,
trascorso tale tempo, non viene ricevuto nessun report, il router assume che non ci
sono più membri nel gruppo di multicast in oggetto.
In Figura 31, viene mostrata la traccia di uno “zapping” che genera una sequenza di
messaggi “Leave” e “Join”. Prima che un utente possa accedere ai canali BTV,
questo deve essere registrato e aver sottoscritto almeno uno dei pacchetti BTV
offerti. Come già accennato, durante la fase di autenticazione OMP recupera dal DB
le informazioni relative al cliente e al servizio sottoscritto. In particolare si verifica se
il cliente ha sottoscritto almeno uno tra i pacchetti disponibili con il servizio BTV ed
ha quindi i diritti di accedere all’applicazione.
58
Capitolo 3
Figura 31 - IGMP: Traccia di uno "zapping"
In base a queste informazioni il cliente accederà ai canali BTV facenti parte del
pacchetto sottoscritto e visualizzerà sulla EPG i dati relativi alla sua sottoscrizione.
All’interno della Home Page sono disponibili le informazioni relative al solo bundle
di servizio sottoscritto dal cliente. In particolare la pagina dell’EPG e della short
EPG sono popolate con le informazioni dei soli canali autorizzati per quel cliente. I
passi previsti dalla procedura di caricamento delle informazioni sono [13]:
1. nella fase di autenticazione con la coppia STB-ID SC-ID si recuperano dal
DB di OMP le informazioni relative al bundle di servizio attivato per il
cliente che ha acceso il STB
2. le informazioni contenute nel database, relative al pacchetto sottoscritto, sono
scaricate all’interno del framework di OMP
3. In base ai dati cliente contenuti si popola la pagina dell’EPG (quindi solo con
i canali sottoscritti).
Una volta che è stata ottenuta la lista dei canali BTV sottoscritti ed è stata
visualizzata sul STB/TV, l’utente finale può navigare tra le informazioni e
selezionare il canale da visualizzare. Per ciascun canale BTV disponibile, è presente
anche l’informazione della URL del gruppo multicast utilizzato per trasportare il
contenuto e il flusso ECM associato (vedi descrizione CA successiva). All’interno
della Home Page sono disponibili le informazioni relative al solo bundle di servizio
sottoscritto dal cliente. In particolare la pagina dell’EPG e della short EPG sono
popolate con le informazioni dei soli canali autorizzati per quel cliente .
59
Capitolo 3
3.3.5 Processo di ingestion
Il processo di ingestion è il meccanismo attraverso il quale i content provider
forniscono alla piattaforma le indicazioni relative alla programmazione televisiva. Lo
scambio di queste informazioni, dette metadati, avviene attraverso l’acquisizione, da
parte di OMP, di file XML [8] opportunamente confezionati dai content provider.
Queste informazioni, per ogni evento live, riportano principalmente:

ID evento

Data ed ora dell’evento,

Canale

Content Provider

Categoria Evento

LoadMode
Oltre a quelli elencati, vengono forniti anche altri attributi che hanno principalmente
lo scopo di popolare le EPG in opportuni formati.
Vediamo un esempio di metadati.
<epgdata>
<Event>
<EventId>3687</EventId>
<EventType>PPV</EventType>
<ServiceId>CLC6</ServiceId>
<StartTime>2005-10-16 14:30</StartTime>
<EndTime>2005-10-16 17:15</EndTime>
<Category>Calcio-Dirette</Category>
<AgeRating>R00</AgeRating>
<Title>Palermo-Chievo</Title>
<Country></Country>
<Duration>5400</Duration>
<ShortDescription> </ShortDescription>
<LongDescription> </LongDescription>
<Year>2005</Year>
<LoadMode>insert</LoadMode>
<Provider>Serie A</Provider>
</event>
</epgdata>
Questi metadati riportano la programmazione di un evento sportivo. Il tag LoadMode
indica la modalità di caricamento dei dati. Può assumere i valori “insert” o “update”.
In questo caso, il valore “insert” indica che si tratta di una nuova programmazione.
Se il valore fosse stato uguale a “update”, era richiesta una correzione di una
60
Capitolo 3
programmazione già esistente. Il nodo ServiceID riporta invece l’identificativo del
canale sul quale dovrà avvenire la trasmissione. Questo valore deve essere presente
nella tabella dei canali di broadcast gestiti dalla piattaforma. Il “CLC6” è quindi uno
dei canali esistenti, configurato a livello di Encoder, StreamShaper e dichiarato in
OMP in cui è registrato l’indirizzo IP di multicast che verrà usato per trasmettere il
video. Le altre informazioni andranno a popolare le EPG. Sono stati omessi altri tag
che contribuiscono al posizionamento dell’evento nel listing dei canali.
La struttura dei file XML [8] può variare in base agli accordi con i diversi content
provider. Nel capitolo relativo al software che si occupa dell’ ingestion verranno
approfonditi questi aspetti.
3.4 Servizio VOD
ll servizio VOD offre la possibilità, per il cliente, di usufruire di un contenuto
audiovisivo di proprio interesse da un catalogo on-line e di poter procedere alla
visione non appena completata la procedura di autorizzazione al pagamento. Il
contenuto viene con l’utilizzo del protocollo RTSP [18]. Durante la visione, il cliente
ha a disposizione i comandi interattivi di un comune videoregistratore (Pause,
Rewind, Fast-Forward, Stop).
3.4.1 Fruizione del Servizio: overview
Di seguito, i passi che descrivono la modalità di fruizione del servizio. In prima
istanza, vengono trascurati gli aspetti relativi all’interazione con il sistema di accesso
condizionato, che verranno mostrati successivamente [12].
1. L’utente, autorizzato al servizio richiede il catalogo dei contenuti VOD
selezionando la voce opportuna dal menù del televisore.
2. L’Application Server OMP genera una lista di contenuti VOD a partire dai
metadati memorizzati nel suo database e restituisce il catalogo di contenuti
VOD all’utente.
3. L’utente seleziona un film all’interno del catalogo e la richiesta è inviata
all’Application Server.
61
Capitolo 3
4. L’application Server restituisce, al STB, il nome del film e l’indirizzo di rete
del video server dal quale il film può essere visto, sotto forma di URL. Per
aumentare la sicurezza del sistema, la URL che l’application server restituisce
contiene un ticket che abilita il client a passare i test di sicurezza presentati
dal server.
5. Il client inoltra quindi la richiesta del contenuto (ovvero la URL) al video
server (OVS).
6. OVS riceve la richiesta video, si assicura che vi siano risorse sufficienti per
servire la richiesta video e recupera il contenuto dalla memoria di massa.
7. OVS invia il contenuto richiesto al cliente. Il STB riceve lo stream video e lo
visualizza sulla TV
Tali passi sono descritti in Figura 32.
Figura 32 - Fruizione di un contenuto VOD
Il server RTSP posizionato in head-end gestisce le risorse del VOD server ed alloca
le risorse necessarie ad istituire una sessione RTSP. In generale, un server RTSP può
risiedere anche fuori dell’head-end. Anzi, questa è la configurazione tipica. Per tale
62
Capitolo 3
ragione, infatti, è necessario che OVS, alla richiesta di RTSP play, risponda con un
messaggio RTSP Redirect verso un opportuno server di streaming.
Questo meccanismo di Redirect si basa su una logica molto semplice [19].
Brevemente, OMP fornisce al STB l’URL RTSP. Come visto in precedenza, OVS
intercetta la richiesta ed analizza l’indirizzo IP del STB. Quindi, con una certa logica,
“decide” quale video server debba soddisfare la richiesta.
OVS è infatti dotato di un database (Oracle 9i) nel quale sono registrati tutti i
contenuti presenti e dove è collocata una tabella di routing. La tabella ha la seguente
struttura:
Field
Type
Constraint/Note
ID
Sequence
Primary key
LOWER
VARCHAR2(32)
Lowest IP address in the subnet
HIGHER
VARCHAR2(32)
Highest IP address in the subnet
LENGTH
NUMBER
Lunghezza della parte LOWER
and HIGHER dell’indirizzo IP
PRIMARY
VARCHAR2(32)
il pattern di un nome per la
selezione di un nodo su un cluster
primario. Es: ‘ROMA’
SECONDARY
VARCHAR2(32)
il pattern di un nome per la
selezione di un nodo su un cluster
primario. Es: ‘MILANO’
CONTENT_TYPE
VARCHAR2(16)
Tipo di Content: es. ‘Alledges,
Pills, Catalogo’.
DESCRIPTION
VARCHAR2(64)
Description.
Si assume che, per poter soddisfare un certo numero elevato di richieste, un Edge
Server sia montato in configurazione cluster e che contenga un certo numero di nodi.
Si perviene all’individuazione del server RTSP attraverso una logica che potremmo
definire “a due passi”. Nel primo passo, si identificano due nomi del cluster: uno
viene detto primary e l’altro secondary. Quest’ultimo verrebbe invocato qualora il
primo non sia disponibile. La tabella di cui sopra richiede che venga adottata una
convenzione sui nomi dei server RTSP del tipo: <nome cluster>_<numero_nodo>.
Ad esempio, se il cluster di Roma ha 4 gateway RTSP, i 4 nomi dei nodi potrebbero
63
Capitolo 3
essere: roma_nodo1, roma_nodo2, roma_nodo3, roma_nodo4. Inoltre, nei campi
Primary e Secondary si dovrebbero usare i valori <nome_cluster>, nel nostro
esempio, ‘roma’. Vediamo meglio la logica. Supponiamo che la tabella di routing sia
popolata come segue [19]:
id
Lower
higher
length
primary
secondary
content_type
1
1.1.0.0
1.1.10.255
24
Milano
modena
Pills
2
1.1.11.0
1.1.20.255
24
Roma
modena
Pills
3
1.1.1.1
1.1.1.1
32
modena
modena
Pills
descrip
tion
Lo pseudo codice SQL seguente indica come l’algoritmo di redirect seleziona la
parte iniziale dei nomi cluster primary e secondary basandosi sull’IP del STB, sul
content_type e sulla definizione della subnet:
cursor c_best is
select id, primary, secondary from ROUTING where
stb_ip >= lower AND
stb_ip <= higher AND
request_content_type = “pills”
ORDER BY length desc;
Accedendo con un valore IP STB = 1.1.1.1 si otterrebbero 2 id: 1 e 3. Questo
significa che
“modena” verrà scelto come primari (id1)
e
“modena” come
secondary (id 3).
Per il valore STB IP = 1.1.1.5 si avrà che il record con id = 1, “milano”, sarà il
primary, mentre “modena” sarà secondary.
Per il valore STB 1.1.11.15 si avrà che record con id = 2, “roma”, sarà il primary,
mentre “modena” verrà eletto quale secondary.
Ottenuti così i nomi dei cluster eletti, bisognerà selezionare i due gateway RTSP che
hanno nomi che soddisfano il matching con quelli trovati. All’uopo, nel database di
OVS, esiste una tabella “HOST” che contiene tutti i nomi dei gateway RTSP con il
rispettivo stato di disponibilità. La scelta dovrà anche rispettare queste regole:
1. I gateway RTSP primari dovranno avere la priorità su quelli secondari
2. Lo stato del gateway deve essere disponibile
3. Lo stato richiesto deve essere “on-line”
4. A parità di priorità, dovrà essere scelto il gateway con carico minore.
64
Capitolo 3
5. Non bisognerà superare il numero massimo di licenze consentito per ogni
cluster, ovvero, non si può superare la capacità di trasmissione.
Questa logica di business consente di poter effettuare manutenzione su un nodo
semplicemente variando il suo stato nella tabella “HOST”. Esiste comunque un
processo che periodicamente verifica lo stato di un nodo ed eventualmente lo
aggiorna riportandolo in questa tabella.
Il meccanismo di redirect, in Figura 33, si presta alla scalabilità della soluzione:
aggiungendo più nodi o cluster, comporterà semplicemente l’aggiornamento di due
tabelle.
Figura 33 - RTSP Redirect
A latere di questo meccanismo, va detto che l’OVS, che opera questa selezione ed il
conseguente redirect, viene detto OVS Central. In realtà, per ottenere un livello di
affidabilità elevato, sono stati utilizzati due OVS Central. A monte di questa coppia,
come si è visto nel capitolo che descriveva l’architettura, è posta la coppia di Load
Balancer. Questi sono stati configurati in modo da intercettare le richieste del STB e
smistarle verso uno degli OVS Central.
65
Capitolo 3
3.4.2 Il processo di Ingestion
In realtà, prima di rendere un contenuto VOD disponibile all’utente finale, sono
necessarie alcune operazioni che possiamo riassumere in:

Ricezione, da parte di un content provider, del contenuto in chiaro da
pubblicare

Pre-Encryption del contenuto

Invio del contenuto Encryptato verso gli edge video server

Inserimento dei dati del contenuto (Es. Titolo, genere, attori,…) nel database
OMP che poi, consultato, mostrerà il nuovo contenuto nel listing delle EPG
L’insieme delle operazioni elencate viene detto Processo di Ingestion. La ricezione di
un contenuto comporta l’ingresso in piattaforma di alcuni file. L’intero pacchetto di
file viene detto “Asset Package”. I componenti di questo pacchetto verranno
anch’essi detti “Asset” ma con la specifica del loro tipo. Si ha quindi che un Asset
Package è composto a sua volta da

un Asset di tipo “Content” rappresentato da un file con codifica MPEG-2 che
contiene il video

un asset di tipo “Preview” rappresentato da un file con codifica MPEG-2 che
contiene il trailer

uno o più asset di tipo “Box Cover” costituiti da uno o più file JPG o GIF che
rappresentano le locandine che dovranno apparire nelle EPG

Un file XML [8] che contiene le informazioni su tutti gli asset (dette
“metadati”), oltre ad indicazioni utili per il popolamento delle EPG. Questo
file XML è basato su un formato detto “CableLabs 1.1” [9], introdotto dalla
CableLabs, e che rappresenta uno standard “de facto” per lo scambio di
informazioni nelle piattaforme IPTV.
Il processo di ricezione di un pacchetto asset è seriale, nel senso che il content
provider fornisce tutti i singoli asset in sequenza e, la ricezione del file XML, indica
la conclusione del trasferimento del pacchetto.
66
Capitolo 3
Oltre ai dati relativi all’asset, il formato XML Cable Labs [9] specificare alcune linee
guida riguardo alle modalità con le quali i content dovrebbero essere trattati dalle
piattaforme IPTV. Nel seguente paragrafo vengono analizzate le informazioni che
esso contiene.
3.4.3 Il formato XML CableLabs 1.1
La specifica del formato XML adottato si deve alla Cable Television Laboratories
Inc. [9]. In questo paragrafo, ne viene descritta solo la parte che serve strettamente
alla comprensione del processo di ingestion, rimandando ogni dettaglio alla
documentazione elettronica fornita in allegato a questa trattazione.
Un file XML descrive le informazioni relative ai VOD. Non descrive quindi il
metodo di distribuzione degli stessi.
La struttura di tale file è conforme alla specifica “Asset Distribution Interface” (ADI)
[5]. Questa definisce sostanzialmente il formato dei messaggi di distribuzione degli
asset tra i vati operatori ed i sottosistemi.
Figura 34 - Distriuzione attraverso Asset Distribution Interface (ADI)
In altre parole, il contenuto video, così come i metadati, sono inviati da un provider
ad un Asset Management System (AMS, entità che detiene e gestisce il ciclo di vita
di un asset). Inoltre tale interfaccia è dotata di un meccanismo che blocca
aggiornamenti che possono essere applicati prima della distribuzione degli asset.
Questi “blocchi” evitano la sovra scrittura di metadati e content, aggiungendo nuovi
asset “figli” a quelli ricevuti n precedenza. Evitano, cioè, la cancellazione di un asset.
Alla base di questa struttura c’è il “Package”. Si tratta di un costrutto usato nel
processo di distribuzione di un asset. Una volta ricevuto, la relazione tra il package e
gli asset consegnati non ha un significato strutturale, ma può essere mantenuta per
ragioni di implementazione del processo. Il package gode di un suo “contesto” che
67
Capitolo 3
può risultare utile per operazioni di accounting, reposting e post processing. I
package ADI vengono processati nell’ordine in cui vengono ricevuti, anche se non è
detto che l’ordine con il quale i pacchetti vengono spediti sia conservato alla
ricezione. Questo, a causa delle diverse dimensioni dei file che possono essere
notevolmente diverse. Secondo l’interfaccia ADI, un asset rappresenta un
contenitore, per ogni oggetto, necessario all’implementazione di un servizio. Può
quindi comprendere file video, audio, immagini, script, file di configurazione, testi e
addirittura pagine HTML. Oltre a questi contenuti “brutali”, anche i metadati sono
parte di un oggetto asset. Descrivono infatti le caratteristiche dello stesso. Gli asset
possono avere una natura ricorsiva. In altre parole, possono contenere asset che ne
possono contenere altri ancora. Si nota quindi che gli asset possono essere usati per
contenere content di tipo arbitrario, a scopi di controllo e tracciabilità nella
distribuzione degli stessi.
Sotto queste ipotesi, si può affermare che un’ applicazione è un tipo di asset. In tal
caso, la fruizione di un asset è quindi un’applicazione che esegue l’applicazione.
Allo scopo di evitare frammentazione, gli asset sono contenuti in una singola
directory nell’ambiente di distribuzione. È importante evitare quindi la separazione
tra gli asset di tipo “content” e quelli relativi ai metadati.
Si assume quindi che:

Un Asset metadata descrive il tipo di content contenuto nell’asset

Un Asset può contenere il content od un riferimento ad esso

Un asset potrebbe essere privo di content

Il “Content” è ogni insieme arbitrario di bit

Un Asset è sempre dotato di un numero di versione

Un Asset può contenere zero o più asset
I Metadati sono invece informazioni raggruppate a seconda dell’uso che ne viene
fatto, ovvero confezionate ad hoc per il processo che le dovrà consumare. Possibili
gruppi sono:

Asset Management System

Delivery system (ad esempio video server)
68
Capitolo 3

Application (ad esempio MOD)

Operational Support System

Business Support System (sistemi di pagamento o billing)
Gli Asset sono univocamente identificati dalla combinazione dell’identificativo del
content provider (Provider_ID) e da un identificativo dell’asset stesso (Asset_ID).
Entrambi questi attributi sono campi della definizione ADI.
Ogni content provider assegna questi identificativi prima del delivery degli asset. Si
tratta quindi di informazioni che devono rimanere persistenti nell’intero ciclo di vita
degli asset in quanto possono essere usati per referenziare gli asset stessi per
eventuali operazioni, ad esempio di delete o di update dei content.
In Figura 35 un diagramma della relazione tra metadati, asset e content [9].
Figura 35 - Diagramma UML per gli Assset
Come già accennato, i metadati descrivono le caratteristiche di un asset inerenti al
contesto dell’asset stesso, quali formato, durata, dimensione o metodo di encoding. I
valori dei metadati sono definiti alla creazione dell’asset e non cambiano durante il
ciclo di vita dell’asset stesso. Un metadato consiste di una coppia parola chiave –
valore. Queste coppie sono quindi definite al momento della creazione dell’asset.
Queste informazioni sono descritte in XML quindi possono essere lette da routine di
parsing in modo molto agevole. Questa metodologia consente una facile estensione
tramite aggiunta di nuove coppie tag - valore. Prescindendo dal tipo di metadata,
queste informazioni devono essere fornite all’interno dell’elemento asset.
69
Capitolo 3
Il formato CableLabs è conforme alla specifica ADI appena presentata e richiede
una struttura dell’asset come quella mostrata in Figura 36:
Figura 36 - Struttura dell'Asset CableLabs
Questo tipo di Package descrive il contenuto VOD ed i metadati per ogni asset, tutti,
a loro volta, parte di un asset di tipo “title”. I nomi ed i valori di metadati di livello
package sono descritti in questa sezione, mentre l’esatto formato, ai fini della
propagazione delle informazioni, è quello definito dall’interfaccia ADI allegata alla
documentazione elettronica. Le informazioni di tipo generale sono indicate con
“AMS” e sono quindi posizionate a livello package.
I metadati sono visti come applicazione di tipo “MOD” (Media On Demand), anche
se in realtà, nella piattaforma, si tratta di Video On Demand (VOD).
In Figura 37, si riporta solo uno stralcio della specifica [9], rimandando, per maggiori
dettagli, alla documentazione elettronica allegata
70
Capitolo 3
Figura 37 - Stralcio della specifica CableLas: Package
Gli asset contenuti nell’asset Title, già mostrati in precedenza, riportano invece
informazioni legate al video (titolo, descrizione, attori, regista…).
3.4.4 Pubblicazione dei contenuti (Ingestion)
Gli asset package arrivano alla piattaforma, come già descritto, corredati di
documento XML con tutti i metadati. Questi file hanno una struttura dedicata ai
71
Capitolo 3
VOD e quindi sono diversi da quelli che vengono usati per popolare le EPG dei
programmi BTV. In questo paragrafo, l’attenzione viene rivolta a quei tag che
prescrivono le modalità di gestione degli asset stessi. Questi sono:

ServiceGroupID: il gestore della piattaforma, basandosi su studi di marketing
che analizzano le preferenze del pubblico, decide il livello di domanda dei
contenuti stessi. Contenuti molto desiderati vengono distribuiti su tutti gli
edge server disponibili mentre, contenuti poco richiesti sono disponibili per lo
streaming RTSP solo da certi edge server. Esiste anche una categoria di
content che viene richiesta molto solo per alcuni giorni per poi presentare
audience prossima allo zero. È il caso delle news, telegiornali, registrazioni di
eventi sportivi. Per questa ragione, gli asset vengono distribuiti a 3 possibili
destinazioni identificate dal valore del tag in esame. Tali valori sono
rispettivamente:

•
Alledeges
•
Catalogo
•
Pills
Encrypting: indica se il contenuto è da sottoporre ad encrypting. Assume
valori Y/N.

LoadMode: è un’informazione a livello package. Indica se il package in
arrivo rappresenta un nuovo contenuto, sostituisce un contenuto esistente
oppure ne ordina la cancellazione dalla piattaforma. Per tale ragione assume
uno dei valori “insert”, “update”, “unpublish”.

File_Update: è sempre presente a livello asset. Assume valori True/False e, se
True, indica e richiede la pubblicazione dell’asset.
Da quanto esposto, si comprende che, prima di passare alla pubblicazione di un
package, è necessaria un’operazione di analisi di tali tag onde decidere quali sono le
metodologie di pubblicazione. È importante premettere che il primo tag che viene
analizzato è <Encrypting>.
72
Capitolo 3
Prima di esaminare la fase di pubblicazione, osserviamo il sistema di encrypting ed i
suoi componenti:
•
XTV Encryptor (XTVE): è un software composto da due moduli: XTV
Encryptor e XTV Publisher. Si tratta di un applicativo Windows e consente,
all’operatore, di selezionare il file da sottoporre ad encrypting, di specificare
un identificativo per il file criptato (detto CRID) e di definire alcune opzioni
dette “access criteria”. Ritorna il file MPEG-2 criptato. Usa l’ ECM
Generator per generare codici detti Server ECM (SECM). Genera altresì
metadati in XML (file con estensione .clp e .phy) per l’XTV Server. Da
queste informazioni si può immaginar che l’engine di encrypting sia lo stesso
dello StreamShaper. In effetti è proprio così. XTV Publisher attende la
creazione dei file da parte di XTV Encryptor e immediatamente li manda al
content management system e all’ XTV Server. XTV Encryptor è installato
su piattaforma Windows 2000 Professional con IIS.
•
XTV Server: genera alcuni ticket quando i VOD sono richiesti dalla home
network (end user). Invia i SECM al VG Bridge per la conversione in PECM
e poi invia questi ultimi alla piattaforma OVA per la trasmissione al STB.
Risiede su piattaforma Clustered HP-UX server ed è basato su DB Oracle ed
Application Server Web Logic.
Elencati così gli attori e le loro responsabilità, si passa ad analizzare la fase di
encrypting che viene effettuata prima di pubblicare il contenuto.Tale operazione
viene detta di pre-encrypting) [14], [12].
Richiedeun intervento manuale. L’operatore seleziona il file MPEG-2, sceglie alcune
opzioni dette “access criteria” e lancia la trasformazione, il cui output è un file
MPEG-2 criptato e accompagnato da altri metadati. Il software incaricato di questa
elaborazione è XTV Encryptor (XTVE) [14] e, all’interno della piattaforma, viene
identificato sul PC che lo ospita. I file sono inviati dal Content Management System
e ricevuti dal XTVE via FTP, come mostrato in Figura 38.
73
Capitolo 3
Figura 38 - VOD Pre-Encryption
Le fasi di encryption sono simili a quanto visto per il servizio BTV.
Il software XTVE genera un codice, detto “control word” e lo invia, con gli access
criteria, all’ ECM Generator. Quest’ ultimo genera le ECM e le invia al Secure
Signature Host (SSH) per farle “firmare” e le restituisce, firmate, all’encryptor..
XTVE procede quindi con l’encrypting cambiando la Control Word ogni intervallo
di tempo detto “crypto period” e tipicamente dell’ordine di 10 minuti. Se l’ECM non
è disponibile, l’operazione di encryption viene abortita.
In Figura 39 è illustrato quanto appena esposto.
Figura 39 - VOD Pre-Encryption in dettaglio
Al termine delle operazioni, XTV Encryptor genera tre file in un supporto di
memoria di massa temporanea. Si tratta del file .mpg del contenuto criptato,
accompagnato da due file contenenti metadati del “Physical Content” e “Clip
74
Capitolo 3
Metadata”, aventi estensione rispettivamente .clp e .phy. Il primo descrive il VOD
acquistabile che potrebbe essere richiesto da OVA. Il secondo, invece, descrive gli
attributi, es. access criteria del file MPEG e le informazioni riguardo al suo
encrypting. Questi file sono validati tramite uno schema XML che risiede sull’XTV
Server e che viene indirizzato tramite una variabile che risiede nel registro del
sistema operativo.
Il “Publisher”, un processo di XTV Encryptor, attiva il Media Asset Manager, un
altro processo che si occupa del trasferimento di questi file verso XTV Server e
restituisce il file .mpg criptato al Content Management System memorizzandolo in
una memoria di massa. Da questa posizione, il file MPEG-2 criptato viene inviato,
via FTP verso gli edge server in accordo a quanto specificato nei metadati dell’asset
package. Alla fine dell’operazione di trasferimento file, XTV Encryptor libera la
memoria di massa temporanea. Queste attività sono Figura 40:
Figura 40 - Distribuzione dei file
3.4.5 Acquisto di un VOD
Seguiamo ora il funzionamento dell’acquisto di un VOD da parte di un utente [12].
All’uopo, si introduce un nuovo attore, il VG Bridge. È un processo che riceve le
SECM e Card id dal XTV Server e le converte in PECM. Quindi comunica con SSH
per ottenere PECM firmate. Il dialogo con XTV server avviene SOAP / XML. La
75
Capitolo 3
sua piattaforma è Windows 2000 Server con IIS. La richiesta di acquisto VOD parte
dalla home network (STB) e giunge ad OVA. Quest’ultimo genera la richiesta un
cartellino, detto ticket. In questa richiesta è contenuto un identificativo del VOD
acquistato ed un codice che descrive la smart card inserita nel STB. Tale ticket
quindi generato da XTV Server e l’identificativo del ticket viene restituito al OVA
(Figura 41).
Figura 41 - Richiesta di Acquisto VOD
XTV Server invia quindi le SECM del content e l’identificativo della smart card al
Video Guard Bridge che genera le ECM personalizzate (PECM) e le manda al SSH
per la firma. Poi le restituisce all’ XTV Server, dove verranno mantenute in memoria
fino a quando richiesto. XTV Server registra tutte le PECM necessarie alla fruizione
del contenuto fino alla fine. Il flusso esposto viene mostrato in Figura 42.
Figura 42 - Preparazione VOD dopo acquisto
76
Capitolo 3
3.4.6 Fruizione di un VOD
Con uno schema analogo a quello della figura 40, dal STB viene inviata la domanda
di fruizione del video (Play Out). Si assume che l’acquisto sia già andato a buon fine.
OVA, alla ricezione del messaggio dal STB, genera un cartellino che identifica
richiesta (ticket), apre una comunicazione con XTV Server ed invia a quest’ultimo
l’identificativo del cartellino e contestualmente richiede la lista delle PECM [12].
XTV Server manda ad OVA l’intero set di PECM. OVA manda tutte le PECM al
STB prima del play.
3.4.7 XTV Server
In questo paragrafo viene analizzato più in dettaglio l’architettura di XTV Server .
[12]. Questo, può essere scomposto logicamente in tre parti (Figura 43):

Front: riceve le richieste di ticket da OVA e riceve le PECM per la gestione
degli stessi.

Back: invia le SECM al VG Bridge per la personalizzazione, e le registra

Content Import: valida e memorizza i metadati ricevuti dall’XTV Encryptor
Tra le parti Front e Back esiste una coda di messaggi. Questa consente alle due parti
di operare a distinte velocità, assicurando che le risposte ad OVA siano sempre
disponibili. Content Import è un task che lavora con bassa priorità ed effettua un
polling periodico per verificare se ci sono nuovi dati in arrivo.
Figura 43 - Struttura di XTV Server
77
Capitolo 3
XTV Server gestisce tre directory: Inbox, Processed, Error. Nella prima vengono
ricevuti i file per essere processati. Nella seconda, XTVS sposta i file e li marca con
un time stamp quando sono validati e registrati con successo. Infine, in Error
vengono spostati i metadati quado la loro validazione fallisce. Anche questi sono
accompagnati da un time stamp.
Si precisa che un ticket rappresenta l’acquisto di un VOD e quindi individua l’utente
ed il CRID, ovvero l’identificativo del contenuto.
Un file clip (.clp) lega gli Access Criteria ai metadati del file phy per mezzo del
CRID.
Un file physical (.phy) mappa un insieme di SECM ad un file MPEG presente su un
VOD server.
Da quanto esposto si evince che la relazione tra un CRID ed i suoi ticket è di tipo
1:n, mentre la relazione tra un clip e i metadati di tipo physical è di tipo 1:1. Il
colloquio dettagliato è mostrato nella seguente figura.
Figura 44 - Esempio di colloquio di acquisto VOD
In Figura 44, sono mostrati i dati che OVA fornisce alla richiesta ticket

CASID: identifica il CYTA della Smart Card ed è richiesto per la
generazione delle PECM
78
Capitolo 3

Card #: Richiesto per la generazione delle PECM per il subscriber.

CRID: Consente a XTV Server d selezionare SECM e Access Criteria da
mandare al CA Bridge.

Handle: un numero univoco che verrà usato da OVA per il successivo
ottenimento delle PECM
Va notato che la generazione dei ticket è triggerata dalla richiesta di OVA all’ XTVS
Front. XTVS ritorna immediatamente l’handle e pone, nello stesso tempo il ticket
nella coda da Front a Back. Quando un ticket raggiunge la testa della coda, XTVS
procede con la generazione delle PECM. All’uopo, XTVS seleziona gli access
criteria per il CRID dal database, seleziona i vari codici e costruisce una richiesta per
un modulo, detto CA Bridge (CAB) che costruisce le PECM e le memorizza nel
database di XTVS. Queste verranno poi fornite ad OVA in risposta al ticket [12].
79
Il software di ingestion
Capitolo 4
Capitolo 4
Al centro dell’architettura e dei servizi descritti nei capitoli precedenti si pone il
software di ingestion. Il suo ruolo principale è quello di integrare diversi sistemi e
dare continuità al quello che si può definire come il ciclo di vita degli asset.
Di seguito verranno analizzati i requisiti di business dell’applicazione per poi
generare casi d’uso intesi come specifica dei requisiti stessi. Successivamente
verranno elencate le attività di ogni singolo caso d’uso e verranno mostrati altri
diagrammi che condurranno all’implementazione del codice. Il linguaggio che verrà
usato per modellare il sistema sarà prevalentemente UML.
4.1 L’analisi dei requisiti
I requisiti sono stati raccolti principalmente tramite interviste con il committente e
con l’acquisizione di documenti che descrivono le interfacce verso altri sistemi già
esistenti. Il sistema riceverà delle informazioni in ingresso (Asset Package) sotto
forma di file, dovrà eseguire le azioni necessarie a pubblicare gli stessi e produrre
informazioni in uscita. Gli Asset Package vengono forniti da un ente esterno, il
Digital Asset Manager (DAM). Come già accennato, questi Asset Package sono
costituiti da:

Metadati: un file XML contenente tutte le informazioni ed i riferimenti agli
altri file componenti

Movie Asset: un file Video con codifica MPEG-2

Trailer Asset: un file video con codifica MPEG-2 e di durata max 3 minuti
80

Capitolo 4
Cover Asset: uno o due file immagine con codifica JPEG o GIF
Nel caso di metadati contenenti informazioni sulla programmazione di eventi
multicast, l’asset package è costituito dal solo file XML. Le informazioni fornite dal
DAM devono essere rese fruibili ai subscriber che risiedono nella home network e
che interagiscono con la piattaforma attraverso il Set Top Box. Per consentire la
fruizione dei video è quindi necessario:

Popolare il database OMP con i metadati presenti nell’asset package

Caricare i contenuti MPEG-2 sui video server
Per ottemperare a queste responsabilità, gli asset package devono essere analizzati in
quanto potrebbero pervenire dati corrotti.
Se i dati che vengono ricevuti superano un controllo di validità, questi devono essere
presi in carico e, a parità di caratteristiche e nel rispetto dei vincoli di precedenza su
metadati dello stesso asset, i contenuti devono essere pubblicati secondo l’ordine con
il quale vengono ricevuti. Il controllo di validità dei metadati si limiterà alla
validazione del file XML nel senso che bisognerà verificare che questo sia conforme
alla specifica fornita dal committente e già presentata nel capitolo 3.
Le strutture dati sulle quali registrare la pubblicazione dei contenuti sono assegnate e
sono le tabelle del database OMP. La parte dello schema di OMP coinvolta nella
pubblicazione dei contenuti è parte integrante della specifica e riporta tabelle, vincoli
di integrità referenziale e tutte le informazioni necessarie per consentire al sistema il
corretto popolamento delle tabelle stesse. Questo implica che gli input e gli output
sono elementi già definiti e frutto essi stessi di un processo sviluppo software. Non
consentono ambiguità in quanto la loro specifica è formale, le strutture dati già
esistenti e al momento popolate manualmente tramite interfacce utente appartenenti
ad altri sistemi.
La responsabilità del sistema software è quella di trasferire, ove presenti e ove
possibile, i contenuti (file MPEG, JPEG, GIF) verso gli edge server e di completare
81
Capitolo 4
la pubblicazione mediante inserimento dei metadati, contenuti nel file XML, nel
database di OMP. Questa ultima operazione renderà possibile la fruizione da parte
dei subscriber che vedranno gli asset comparire nelle proprie EPG. Queste, si ricorda,
vengono popolate tramite lettura di informazioni che risiedono in opportune tabelle
di OMP, dalla struttura assegnata.
Altra responsabilità del sistema da sviluppare è quella di effettuare operazioni di
update o cancellazione dei dati degli asset. Tale operazione può investire sia i
metadati (es. correzione del nome di un attore) che i gli asset di tipo Movie, Preview
e Cover (es. sostituzione del contenuto MPEG oppure della locandina). Anche in
questo caso, è il DAM a richiedere tale operazione mediante invio di eventuali
contenuti da sostituire accompagnati sempre da un file XML valorizzato con gli
opportuni metadati. Secondo la specifica fornita, è infatti presente un attributo, detto
LoadMode, che può assumere i tre possibili valori: “insert”, “update”, “unpublish”.
Attraverso l’opportuna attribuzione di tale valore, il DAM richiederà le
corrispondenti operazioni desiderate. Si precisa, però, che non è detto che operazioni
di update richiedano anche sostituzione dei content. Questo è dunque anche il caso in
cui il DAM richiede la cancellazione di un contenuto sia dal database che dagli Edge
Server. Pertanto, in tali casi, viene fornito il solo file XML. Da qui il fatto che il file
XML è l’unico elemento che il DAM deve obbligatoriamente inviare per sollecitare
qualsiasi operazione tra quelle previste. I file che rappresentano i content sono
opzionali. La presenza degli stessi è riportata nel file XML tramite l’utilizzo di un
riferimento al contenuto e di un attributo che indicherà se sarà necessario trattarlo o
meno.
Da quanto esposto si nota che gli asset in arrivo possono essere classificati in

Asset immediatamente pubblicabili

Asset pubblicabili solo dopo aver trasferito i file di content verso i server che
li dovranno ospitare
I primi corrispondono evidentemente agli asset package costituiti dai soli metadati.
82
Capitolo 4
I secondi, invece, richiedono operazioni di trasferimento file. Per tale ragione,
seguono un flusso diverso. Però, una volta completato questo flusso, si possono
accomunare ai primi.
L’ordine con cui devono essere pubblicati gli asset packages deve corrispondere a
quello di arrivo. In altre parole, se due o più asset hanno tutti i requisiti per essere
pubblicati immediatamente, viene scelto quello arrivato prima.
Un asset package entra nel dominio del sistema attraverso una memoria di massa
accessibile contemporaneamente dal DAM e dal sistema, ovvero una directory di un
disco condiviso, chiamata “inbox”.
I package ricevuti dovranno poi essere distribuiti in opportune sottodirectory, a
seconda della tipologia e dei valori contenuti nei file XML. In particolare, i contenuti
VOD da sottoporre ad encrypting devono essere trattati da un software esterno, detto
XTV-Encryptor e fornito dal committente, che li restituirà nuovamente al sistema
sotto forma di file MPEG-2 encrypted. Il sistema software dovrà notificare
all’utilizzatore che un asset necessita di essere sottoposto ad encrypting.
L’utilizzatore dovrà poi eseguire manualmente questa operazione usando
l’interfaccia di XTV-Encryptor e verificarne il successo.
Al termine di questa
operazione, dovrà avvenire il trasferimento del file MPEG-2 encrypted verso gli edge
video server. Il sistema software si dovrà occupare del successivo inoltro verso questi
e, al termine del trasferimento, attuerà la scrittura nelle tabelle del database OMP.
Tutte le operazioni descritte devono essere monitorate da un operatore che attiva i
flussi di lavorazione quando vengono ricevuti i file XML dal DAM.
Il software deve essere dotato di funzionalità accessorie, dette Tools. Queste
consentono all’operatore l’accesso diretto in lettura e scrittura nelle tabelle di OMP,
allo scopo di verificare ed eventualmente modificare eventuali dati degli asset o di
effettuare semplici report.
Il software dovrà tenere traccia di tutte le operazioni relative alla pubblicazione. Ove
possibile, queste tracce dovranno essere raccolte in maniera automatica. Le
operazioni manuali infatti, richiedono all’utente di aggiornare manualmente lo stato
di avanzamento della pubblicazione degli asset.
83
È il caso del sistema XTV
Capitolo 4
Encryptor. Questo, infatti, dispone di interfaccia verso altri sistemi software e quindi
notifica al solo operatore il messaggio di termine delle operazioni. Per tale motivo,
l’inizio del trasferimento content verso gli edge deve avvenire necessariamente con
l’ausilio dell’operatore.
Il DAM intende avere visibilità sullo stato dei processi di pubblicazione attuati dal
sistema software. Per tale ragione, di tali requisiti, fanno parte le seguenti regole:

Tutti gli asset presi in carico dal sistema devono essere rimossi dalla directory
“inbox”

Tutti gli asset che richiedono encrypting del video, devono essere inseriti
nella directory “encrypting”, di “inbox” (\inbox\encrypting).

Tutti gli asset che hanno terminato la fase di encrypting o, che non la
richiedono affatto, devono essere trasferiti in una directory di “inbox” detta
“pubblicare” (\inbox\pubblicare).

Tutti gli asset che sono stati pubblicati, vengono trasferiti in una directory di
“inbox” chiamata “pubblicati” (\inbox\pubblicati).

Tutti gli asset che non sono, per qualsiasi ragione, compatibili con la
specifica vista nel capitolo precedente, vengono scartati, ovvero trasferiti
nella cartella “errori” (\inbox\errori).
Con l’adozione di queste regole, si ha che:

“pubblicare” contiene – e quindi rappresenta - la coda degli asset pronti per la
pubblicazione

“encrypting” contiene – e quindi rappresenta – la coda dei video da sottoporre
ad encrypting

“pubblicati” contiene – e quindi rappresenta – l’insieme degli asset pubblicati

“errori” contiene – e quindi rappresenta – l’insieme degli asset scartati
Accedendo a queste directory, il DAM ha subito il polso della situazione e può
modificare il carico di lavoro fornito al sistema.
Il committente ha altresì specificato alcuni requisiti generici relativi all’interfaccia
utente: interfaccia grafica con una singola finestra e con una cartella a più schede che
84
Capitolo 4
possa contenere gli elementi necessari all’operatore (bottoni etc). L’ambiguità degli
stessi ha portato all’accordo verso un prototipo di GUI che verrà sottoposto al
committente e raffinato in uno o più passi fino alla convalida definitiva.
Un vincolo aggiuntivo è stato fornito sulla scelta del linguaggio da utilizzare durante
la fase di implementazione. Si tratta di Microsoft Visual Basic ver. 6.0 sp.6. La
ragione di ciò sta nel fatto che il committente possiede conoscenze specifiche di
questo linguaggo e, avendo diritto di possesso del codice sorgente, sarà in grado di
apportare autonomamente, ed a suo esclusivo carico, eventuali variazioni al prodotto
software. Tutti i documenti di progetto, da quelli di analisi a quelli di
implementazione, codice sorgente e strutture dati, saranno parte integrante del
prodotto software e per questo saranno consegnati al committente.
Quanto appena descritto, accompagnato dai documenti di specifica dei metadati e del
database OMP rappresenta l’elenco dei requisiti forniti dal committente.
4.2 La specifica dei requisiti
Dall’analisi dei requisiti appare chiara la missione del sistema da sviluppare, ovvero i
requisiti di business dello stesso. Verranno definiti modello dello scopo del sistema,
il modello dei casi d’uso, la modellazione delle attività e dello stato. Dopodichè si
passerà alla modellazione delle classi e delle interazioni.
4.2.1 Modello dello scopo del sistema
La domanda a cui si vuole rispondere non è semplice perché il sistema è una parte di
un ambiente più esteso, una parte dell’insieme di sistemi che costituiscono
l’ambiente stesso. I sistemi collaborano scambiandosi informazioni e invocando
servizi . A questo punto, è necessario conoscere il contesto nel quale il sistema opera.
[20]. È necessario conoscere le entità esterne, ovvero altri sistemi, organizzazioni,
persone, etc. che attendono alcuni servizi o che forniscono servizi al sistema. Tali
servizi si traducono in flussi di dati da e per il sistema. Lo scopo del sistema, di
conseguenza, può essere determinato attraverso l’identificazione delle entità esterne
e dei flussi di ingresso / uscita tra esse ed il sistema stesso. La ricerca di queste
informazioni ha richiesto lo studio approfondito dei metodologie di lavoro adottate
85
Capitolo 4
nella piattaforma IPTV. Tutto sommato, non è stato complesso identificare i requisiti
in quanto le interviste sono state effettuate a persone con elevato background tecnico
ed esperienza nella gestione dei cicli di vita del software. Per tale ragione, la fase di
analisi e specifica dei requisiti si confondono e le fasi successive del ciclo di vita del
software risultano più agevoli.
Il linguaggio adottato per la descrizione del modello sarà UML [22]. Questo però, in
certe circostanze, non fornisce un buon livello grafico per definire lo scopo del
sistema. Di conseguenza, lo storico Diagramma di Contesto dei DFD è spesso usato
per portare a termine tale compito [20]. Del resto, l’applicativo da realizzare anche
in questa fase primordiale viene percepito come un qualcosa che somiglierà ad una
gestione di workflow. La Figura 45 mostra il diagramma di contesto per
l’applicazione in esame:
Figura 45 - Scopo del sistema - Diagramma di contesto
Questo flusso dati può essere tradotto in una vista statica che indica quali sono i
componenti e le dipendenza tra gli stessi.
86
Capitolo 4
In altre parole è possibile tracciare un component diagram (Figura 46)nel quale è
visibile lo scenario.
Figura 46 - Component diagram
Il component DAM rappresenta l’ente che fornisce i dati in input. XMLDAM è il
sistema in fase di realizzazione mentre IPTV indica l’omonima piattaforma che
include gli Edge video server e il database di OMP.
4.2.2 Modello dei casi d’uso
Dopo aver definito lo scopo del sistema, si passa alla definizione dei casi d’uso di
business. Successivamente, si provvederà all’analisi dei casi d’uso che scaturiranno
da questo e si procederà con un maggiore livello di dettaglio. Per il momento, si
tratta di definire le sole “caratteristiche del sistema”. Tale caratterizzazione avviene
tramite definizione di un diagramma dei casi d’uso di business, il cui aspetto centrale
è l’architettura dei processi. Il diagramma, in,Figura 47, fornisce una “vista a volo di
uccello” del comportamento desiderato del sistema [20].
Le descrizioni per ciascun caso d’uso sono ben concise ed orientate al business.
87
Capitolo 4
Figura 47 - Modello dei casi d'uso di business
Si nota che gli attori di tale modello differiscono in generale dalle entità esterne del
diagramma di contesto per il modo in cui gli attori stessi interagiscono con il sistema.
Infatti, le linee di comunicazione tra attori e casi d’uso non sono solo flussi di dati
ma rappresentano anche flusso di eventi e di risposte dai casi d’uso. Vediamo infatti
che gli attori individuati sono:

XMLDAM User: è l’operatore che interagisce con il sistema attivando le
elaborazioni

XTV Encryptor Operator: è l’attore che riceve un flusso dati (video da
sottoporre ad encrypting), li processa e restituisce i video in versione
encrypted. È necessario precisare che sarebbe meglio modellare questo attore
come un sistema esterno in quanto non interagisce direttamente con il
sistema, ma la sua attività è comunque necessaria al completamento del caso
d’uso Prepare MPEG-2 Content. Comunque, essendo questo un caso d’uso a
livello di business, è possibile includerlo in quanto completa la visione dello
scenario.
Gli attori interagiscono con i seguenti casi d’uso di business:
88

Capitolo 4
Get Asset Package: il Digital Asset Manager ha fornito gli asset package da
pubblicare e quindi XMLDAM User li prende in carico

Prepare MPEG-2 Content: XMLDAM User seleziona ed invia i content da
sottoporre ad encrypting verso XTV Encryptor. Poi si occupa del successivo
trasferimento verso gli edge server.

Encrypt MPEG-2: XTV Encryptor operator prende in carico i content da
sottoporre ad ecrypting e li restituisce, in versione a XMLDAM Encryptor.

Publish Metadati: lo user pubblica i metadati dei packages in OMP. Questi
metadati andranno a popolare le EPG per il Set Top Box
Attraverso questi casi d’uso si sono definiti i punti di partenza dei requisiti funzionali
del software. Questi diventeranno la base dei casi d’uso della specifica dei requisiti.
Ed è in questa fase che i casi d’uso sono identificati e specificati con maggiore
dettaglio. Da questo diagramma, teso ad identificare le sole caratteristiche rilevanti
del software, sono state nascoste altre funzionalità accessorie in quanto, a questo
livello della trattazione non si è interessati a tutti i dettagli. Le descrizioni iniziali
verranno estese per comprendere sotto-processi e processi alternativi. In prima
approssimazione, utilizzando quindi la metodologia UML [22], si costruisce seguente
diagramma .
89
Capitolo 4
XML DAM
Get Inbox
Publish Asset
<<include>>
Encrypt Conten
XTV-Encrypt
Operator
XMLDAM Use
Clean Shelf
VOD Manageme
Figura 48 - Casi d’uso
Dalla Figura 48 si evince la schematizzazione iniziale dell’analisi dei requisiti.
Si ritrovano gli attori del sistema:

DAM: è il sistema esterno che fornisce in input gli asset package da
processare.

User: è l’operatore che interagisce con l’interfaccia del sistema e comanda le
azioni da svolgere. Per questo viene anche detto “operatore”

XTV Encryptor: È il sistema esterno che si occupa dell’encrypting dei file
MPEG-2. Riceve in input il un file MPEG-2 e ne restituisce una versione
encrypted. Anche qui si precisa
che questo attore non interagisce
direttamente con il sistema, ma la sua attività è comunque necessaria al
completamento del caso d’uso Publish Asset.
90
Capitolo 4
Da una prima analisi sono stati identificati i casi d’uso che vengono riportati qui di
seguito. Si noti che il caso d’uso Encrypt content, qui riportato per la completezza
dello scenario, fa parte di un sistema esterno. Dato che si sta modellando l’aspetto
business del sistema, può essere mantenuto per una migliore comprensione dello
stesso.
Caso D’uso
Get Inbox
Breve
il DAM fornisce gli asset package in \inbox mentre lo
Descrizione
User controlla periodicamente se questa directory li
contiene
Attori
XMLDAM User
Precondizioni
Il DAM ha prodotto uno o più asset package e li ha
forniti al sistema scrivendoli nella cartella \inbox
Flusso
L’user esegue il controllo della cartella \inbox. I
Principale
metadati vengono analizzati e, se conformi alla
specifica, vengono spostati in una opportuna directory,
in accordo alle regole fornite dal DAM. In tal caso gli
asset sono assunti quali input per il sistema.
Flussi
Se nella directory \inbox non è presente alcun asset
Alternativi
package, nulla viene preso in carico dal sistema.
Se vengono rilevati asset package con metadati non
conformi alla specifica condivisa, vengono spostati in
una opportuna directory \inbox\errors quindi vengono
rigettati dal sistema.
Post Condizioni
Gli asset package eventualmente presenti in INBOX e
conformi alla specifica, vengono spostati in una
sottodirectory di \inbox per la successiva lavorazione.
Il diario delle attività viene aggiornato di conseguenza.
91
Capitolo 4
Caso D’uso
Publish Asset
Breve
Lo XMLDAM User processa gli asset pronti per la
Descrizione
pubblicazione, ovvero tutti gli asset che si trovano
nella cartella \inbox\pubblicare
Attori
XMLDAM User
Precondizioni
Un asset package, già stato fornito in carico al sistema
dal caso d’uso “Get Inbox”, è presente nella directory
\inbox\pubblicare. Esso è quindi valido e disponibile
per essere trattato.
Flusso
Lo XMLDAM User raccoglie gli asset package
Principale
disponibili nell’ordine in cui sono stati forniti al
sistema. Questi costituiscono coda di job che viene
gestita con politica FIFO e gli asset vengono avviati
alla pubblicazione. A seconda dei valori assunti dai
metadati, la pubblicazione può percorrere flussi di
lavorazione alternativi.
Flussi
Tutti gli asset che non richiedono il trasferimento di
Alternativi
content verso gli edge server (es. EPG oppure update
di
soli
metadati)
possono
essere
gestiti
automaticamente e quindi ritenuti pronti per l’
immediata pubblicazione.
Se nei metadati viene richiesto anche il trasferimento
dei file content verso i video server, allora questo
verrà inserito in una opportuna coda di trasferimento
file. Il job assumerà così uno stato tale da rispecchiare
la fase di in corso. Dopodichè altri asset possono
essere estratti dalla coda dei job fino allo svuotamento
della coda stessa.
92
Post Condizioni
Capitolo 4
L’asset package è pubblicato o è in pubblicazione e
l’operazione viene riportata nel diario delle attività
Caso D’uso
Encrypt Content
Breve
È
Descrizione
Operator, che permette di produrre la versione
l’operazione,
effettuata
dall’XTV
Encryptor
“encrypted” del file MPEG-2. Questa verrà
poi
restituita allo XMLDAM User he provvede a portare a
termine il processo di pubblicazione.
Attori
XTV-Encryptor Operator
Precondizioni
L’asset è un VOD i cui metadati richiedono
l’operazione di Encrypting
Flusso
XMLDAM User seleziona i file MPEG-2 da
Principale
encriptare e li invia all’ XTV-Encryptor Operator che
provvede all’inserimento del file nella propria coda di
all’encrypting. XMLDAM User è tenuto a verificare
manualmente che XTV Encryptor abbia terminato
l’elaborazione, a prendere nota dello stato di
terminazione ed a trasferire questa informazione al
sistema.
Flussi
Se
Alternativi
dall’encryptor, questo viene scartato. Lo user è tenuto
a
un
file
rigettare
classificandolo
MPEG-2
viene
ritenuto
manualmente
come
errato
l’asset
e
invalido
package
spostandolo
in
\inbox\errori.
Post Condizioni
XTV Encryptor ha fornito il file MPEG-2 encriptato
oppure ha fornito un messaggio di errore. Lo
XMLDAM User ha registrato l’esito delle operazioni
93
Capitolo 4
e, attraverso apposita interfaccia, ha aggiornato lo
stato di pubblicazione dell’asset.
Caso D’uso
VOD Unpublish
Breve Descrizione
Descrive l’operazione di cancellazione
di un asset
package.
Attori
XMLDAM User
Precondizioni
È stato ricevuto un asset package con attributi tali da
richiedere la cancellazione.
Flusso Principale
L’asset referenziato dai metadati viene rimosso dal
database e dai video server.
Flussi Alternativi
Se nei metadati viene referenziato un asset non
esistente nel database, questo viene spostato in una
memoria di massa privata dedicata agli asset scartati.
Post Condizioni
L’asset non è più presente nel database. L’operazione
viene automaticamente viene registrata nel log delle
attività
Caso D’uso
VOD Management
Breve
Questo caso d’uso racchiude piccole funzionalità di
Descrizione
sistema, quali quelle di accesso diretto al database di OMP
per controlli, update diretti senza necessità di file XML,
reportistica e ricerche sui VOD.
Attori
XMLDAM User
94
Precondizioni
Capitolo 4
Lo user è connesso al database degli asset. È richiesto
l’aggiornamento o la consultazione di delle informazioni
relative ad uno o più VOD. In particolare, può essere
richiesto l’elenco dei VOD presenti nel database di OMP.
Tale attività non è sollecitata dalla ricezione di un asset
package.
Flusso
L’aggiornamento manuale di un VOD richiede la
Principale
conoscenza di una informazione per la sua individuazione
senza ambiguità. Una volta selezionato il VOD da
aggiornare,
lo
user
può
modificare
tutte
le
sue
informazioni.
Flussi
Se viene richiesto un report dei VOD inseriti, lo user
Alternativi
produce semplicemente invocando una apposita funzione
dalla user-interface.
Post
Viene prodotto un elenco di VOD corrispondenti alla
Condizioni
selezione dello user
Caso D’uso
Clean Shelf
Breve
Con questa operazione si intende cancellare il credito
Descrizione
di VOD disponibili al subscriber. Oppure si vuole
sottrarre un VOD dalla shelf di tutti i subscriber.
Attori
XMLDAM User
Precondizioni
È disponibile il MAC-Address del Set Top Box del
subscriber oppure l’id del VOD da rimuovere dalla
Shelf utenti.
Flusso
Viene eseguito un accesso alle strutture dati di OMP
95
Capitolo 4
Principale
per l’operazione di delete
Flussi
Se il MAC-Address del Set Top Box del subscriber
Alternativi
non viene trovato, oppure se l’ID del VOD non è
valido, non viene eseguita nessuna operazione
Post
XMLDAM User riceve una notifica dell’esito delle
Condizioni
operazioni
I casi d’uso analizzati rappresentano, rispetto ai casi d’uso di business, un secondo
livello di dettaglio. Iterando tale tecnica, possono essere analizzati ad un livello di
approfondimento maggiore.
Ad esempio, con riferimento ai casi d’uso “Get Inbox”, è possibile specificare
ulteriori elementi di dettaglio che vengono mostrati nella in Figura 49.
check Inbox
<<include>>
<<include>>
XMLDAM Use
Distribute Content
Parse XML
Figura 49 - Caso d'uso "Get Inbox"
In questa analisi, infatti, risultano evidenti nuovi casi d’uso. Si nota che “Get Inbox”
si traduce in altri casi d’uso di dettaglio che XMLDAM User deve eseguire. Dal
diagramma
appare
chiaro
che
queste
informazioni
semanticamente, all’esposizione di singoli task.
96
sono
molto
vicine,
Capitolo 4
Inoltre, sebbene non si siano eseguite iterazioni approfondite dell’analisi dei casi
d’uso, appare già evidente la natura transazionale della missione del sistema. Per tale
ragione, piuttosto che approfondire i casi d’uso, in questa fase del progetto, risulta
più conveniente riportare la loro descrizione utilizzando i diagrammi delle attività. Il
rischio sarebbe quello di indicare, oltre al “cosa” anche il “come” tali operazioni
devono essere eseguite. Si preferisce quindi demandare questo tipo di attività alla
fase di progettazione.
Questo discorso, nell’ambito di questo applicativo, è di carattere generale. Per tale
ragione si omettono casi d’uso più approfonditi in quanto non fornirebbero il valore
aggiunto atteso.
4.2.3 Modellazione delle attività
Il modello delle attività permette di rappresentare graficamente il flusso di eventi di
un caso d’uso. Questa modellazione colma quindi il vuoto tra una rappresentazione
di alto livello del comportamento del sistema, ovvero con i modelli dei casi d’uso, e
la sua rappresentazione a più basso livello, fornita dai modelli di interazione, ovvero
diagrammi di sequenza e collaborazione [21]. Il diagramma delle attività mostra i
passi di una computazione. Ogni passo è uno stato in cui si esegue qualcosa. Per tale
motivo i passi di computazione vengono anche chiamati “stati di attività”. Il flusso di
controllo da un’attività alla seguente rappresenta la transizione [20].
I modelli delle attività rappresentano quindi un punto di vista interno del sistema.
Il punto di partenza della modellazione di attività è quindi il caso d’uso. È proprio
nelle asserzioni dei flussi principali ed alternativi di quest’ultimo che vanno
individuate le attività.
4.2.3.1 Caso d’uso “Get inbox”
Il caso d’uso “Get inbox” è descritto in dettaglio nel diagramma delle attività che
segue (Figura 50). Dalle asserzioni di contenute nei flussi, sono stati identificati e
raffinati gli stati.
Le attività cominciano quando l’attore XMLDAM User esegue il controllo della
directory condivisa per la presa in carico degli Asset Package. Se questi non esistono
97
Capitolo 4
content nella directory \inbox, l’esecuzione delle attività termina. Altrimenti, i
metadati vengono sottoposti a parsing ed al controllo di validità. Tale fase, come da
requisiti, dovrà verificare:

correttezza sintattica del file XML

consistenza delle informazioni contenute nel file XML
Se il controllo dei metadati termina con esito negativo, il package viene scartato
tramite uno spostamento dello stesso nella directory \inbox\errori. Se tale controllo
ha esito positivo, l’Asset Package viene assunto quale input.
Read Inbox Content
[is empty]
[not empty]
Parse Content
[not valid]
Validation Check
Move Asset in errori
[valid]
Move Asset in Encrypting
[Encrypting needed]
[Encrypting
not needed]
Move Asset in Pubblicare
Write into the Log
Figura 50 - Diagramma delle attività per il caso d'uso Check Inbox
Gli asset in ingresso al sistema verranno considerati come nuovi job che il sistema
dovrà processare. Il sistema dovrà tenere traccia di questa coda unitamente alle altre
98
Capitolo 4
informazioni che dovranno essere utilizzate per la selezione dei job da processare. I
requisiti del committente indicano esplicitamente che gli asset dovranno essere
processati secondo l’ordine di arrivo.
Si precisa che la presa in carico di un nuovo job, ovvero il suo inserimento in coda,
implica il trasferimento del pacchetto in una opportuna sottodirectory in una coda di
asset da lavorare. In particolare, se nei metadati è indicato, a mezzo del valore
assegnato all’attributo “Encrypting”, che il content deve essere sottoposto ad
encrypting, allora il pacchetto dovrà essere spostato nella directory \inbox\encrypting
che contiene tutti gli asset che l’XTV-Operator dovrà processare secondo quanto
descritto in [14]. Questa directory rappresenta quindi una coda di job in ingresso
all’Encryptor che la consumerà con politica FIFO.
Dopo l’analisi dei metadati, e dopo lo spostamento degli asset nelle sottodirectory
richieste, il sistema è tenuto a mantenere una traccia di quanto accaduto, riportando i
risultati dell’elaborazione nel log di sistema. Lo stato dei job dovrà essere
conservato.
4.2.3.2 Il caso d’uso “Publish Content”
L’asset package viene sottoposto ad un check onde raccogliere i metadati che
indicano quale flusso di lavoro deve essere seguito. Appare chiaro che la logica del
sistema viene guidata dall’esterno tramite queste informazioni.
Il primo controllo avviene sulla tipologia di XML. Se la struttura è CableLabs 1.1 [9]
compliant, si è in presenza di VOD. Altrimenti si è in presenza di EPG. In tal caso,
non è richiesta alcuna operazione di file transfer ed è possibile inviare il contenuto
verso il database OMP.
Il caso d’uso “Publish Content” è più articolato in quanto richiede diverse azioni. È
riportato in Figura 51.
99
Capitolo 4
Figura 51 - Diagramma di Attività per il caso d'uso "Publish Content"
Se i metadati si riferiscono ad un VOD asset, bisogna analizzare altri tag che
definiscono in maniera non ambigua il tipo di processo da applicare. I metadati che
interessano sono riportati nella seguente tabella, che mostra lo stato da assegnare ai
job in dipendenza degli stessi.
Encrypting File_Update Operation to perform
Directory
STATE
N
Yes
FTP to edges
Pubblicare
In transfer
Y
Yes
Encrypting, ftp to edges
Encrypting
In transfer
Pubblicare
Write to DB
Don’t care No
100
Capitolo 4
A questi stati vanno aggiunti vincoli di priorità: nell’ambito dello stesso VOD / EPG,
si ha che:

Il primo asset package da pubblicare è quello che ha l’attributo LoadMode
che assume valore “INSERT”.

Può esistere un solo package che ha l’attributo LoadMode che assume valore
“INSERT”.

Se vengono ricevuti due package con attributo LoadMode che assume valore
diverso da “INSERT”, devono i metadati devono essere pubblicati sempre in
ordine FIFO.
Per tale ragione è opportuno modellare questi requisiti con uno activity diagram
(Figura 52) in cui sono visibili tutte le fasi della pubblicazione:
[Get Inbox]
[Encryption=Y]
[Encryption = N]
Wait for
CoverTransfer
[Transfer
Assets]
[Encrypted]
In Encrypting
On Edges
Wait for
TrailerTransfer
Encrypted
Write into the database
Wait for
Movie Transfer
Figura 52 - Activity Diagram Pubblicazione VOD Insert
Dal diagramma si nota che il tag Encryption definisce il prossimo stato. Se
Encryption =Y allora l’asset viene spostato nella cartella “encrypting” ove viene
preso in carico da XTV Encryptor. Una volta trattato dall’Encryptor, il movie è
pronto per il trasferimento. A questo punto tutti i content vengono trasferiti verso gli
edge server. Al termine del trasferimento, sarà possibile effettuare l’operazione di
scrittura sul database, dopodichè il VOD sarà pubblicato. Tale diagramma viene
percorso quando i metadati indicano:
101
Capitolo 4

Loadmode = Insert

Loadmode = Update, File_Update= True per tutti i content asset (movie,
trailer, cover)
Se File_Update = False per qualche content asset, il diagramma si modifica, non
dovendo più richiedere la sincronizzazione sulla fine del file transfer per l’asset che
manca. Infatti, nel caso di

Loadmode=Update

File_Update(Cover)=File_Update(Preview)=True,File_Update(Movie)=False
non si è più sensibile al valore di Encryption e si ha quanto riportato in Figura 53:
Figura 53 - Activity per Movie File_Update = False
In ultimo, viene riportato il diagramma delle attività (Figura 54) per la pubblicazione
di un asset package composto dal solo file XML e che quindi non richiede affatto il
trasferimento dei content. È il caso di asset di soli metadati per EPG e di VOD con
Loadmode=”update” e che non richiedono la modifica dei content.
Figura 54 - Activity Diagram per la pubblicazione di soli metadati
102
Capitolo 4
4.2.4 Modellazione delle classi
I concetti di fin qui discussi consentono di passare ad esaminare il modello statico
del sistema. La specifica dello stato del sistema fornisce, infatti, una vista statica
dello stesso. Il compito principale della modellazione statica è definire le classi per il
dominio applicativo, i loro attributi e le loro relazioni [20].
Il sistema in esame non contiene un database, nel senso che non è nella propria
responsabilità la persistenza di informazioni. Infatti, gli asset package sono
consegnati al sistema già persistenti, ovvero tramite memoria di massa. Inoltre il
sistema dovrà lavorare come un driver, ovvero scrivere su strutture dati che sono
parte di un sistema esterno. Il diagramma delle classi che ci si aspetta sarà dunque
incentrato su classi di controllo e potranno comparire classi di tipo entità di supporto
alla persistenza delle informazioni indispensabili alle classi di controllo stesse.
Il processo utilizzato nell’individuazione delle classi segue un approccio
probabilmente differente in diversi momenti. Tutto sommato il criterio comune
potrebbe considerarsi quello guidato dai casi d’uso [21].
Sono state quindi individuate le classi ritenute rilevanti e, per ognuna di esse, è stato
riportato l’elenco di attributi e l’elenco delle operazioni. La specifica di queste ultime
ha avuto, quale punto di partenza, la specifica fornita con i diagrammi di attività.
È possibile notare che la ricerca degli attributi avviene in parallelo alla ricerca delle
classi e può esserne considerato quale “effetto collaterale”. Ciò non significa che la
ricerca degli attributi sia cosa semplice. Al contrario, è un processo complesso ed
altamente iterativo. Nei modelli iniziali di specifica, infatti, si definiscono gli
attributi essenziali alla comprensione degli stati in cui si possono trovare gli oggetti
della classe. Altri attributi possono essere temporaneamente ignorati, facendo
attenzione che tali informazioni non vadano perdute. Per tale ragione, nel diagramma
che in Figura 55, sono stati mostrati i soli attributi che vengono implicati dai
requisiti. Tutte queste omissioni possono essere poi inserite nelle successive
iterazioni.
A questo livello, dunque, le classi sono quelle che si percepiscono a livello business
sono:
103

Capitolo 4
AssetPackage: la classe rappresenta le informazioni che sono fornite in imput
e che il sistema deve trattare. È dotata di attributi direttamente legati alla
specifica CableLabs che però nel diagramma sono stati omessi in quanto non
rilevanti a questo livello del processo.

EPG: è rappresentata come una specializzazione dell’asset package.
Corrisponde ad un dato in input che popola in OMP i dati relativi agli eventi
da trasmettere in multicast. Gli attributi rilevanti a questo livello dell’analisi
sono il chennelID, startDate ed endDate e rappresentano rispettivamente il
canale su cui trasmettere il programma, la data ed ora di inizio e fine della
trasmissione

VOD: è la seconda tipologia di asset package. Come da specifica CableLab
1.1 vista nel capitolo precedente, contiene uno o più content che poi si
specializzeranno in movie, preview e cover content. Anche questa
informazione è stata omessa a questo livello dell’analisi.

ServiceGroup: nel sistema vengono modellati insiemi di video server quali
destinazioni dei video content.

AssetManager: corrisponde alla classe di controllo del sistema. Racchiude,
infatti, tutte le funzionalità e le responsabilità del software.
Sono state omesse anche le classi delle entità persistenti di OMP perché non fanno
parte del dominio del sistema. Si ribadisce che il software di ingestion, nei confronti
del database, è da intendersi come un driver che lancia operazioni di lettura e
scrittura verso il database di OMP.
Il cuore del diagramma delle classi è rappresentato dalla classe Asset Manager. Si
tratta di una classe di controllo che contiene una serie di operazioni che servono alla
gestione del flusso di lavoro. Le sue operazioni pubbliche sono start e stop. L’unico
attributo esposto è isActive che assume un valore booleano in cui “True” indica che
il manager è stato attivato.
104
Capitolo 4
AssetManager
+isActive:boolean
<<handle>>
ServiceGroup
+serviceGroupId:strin
+start:boolean
<<send>> <<constructor>>
+stop:boolean
+createSG:int
-checkInbox:boolean
+updateSG:void
-checkMetadata:boolea
+deleteSG:void
-askForEncrypt:void
+sendToSGs:void
-moveAsset:boolean
-log:void
1
AssetPackage
1..*
+assetID:int
+fileName:string
+loadmode:string
+dateCreated:date
EdgeServer
+destinationIP:string
+port:string
+login:string
+password:string
+path:string
EPG
VOD
+dateEnd:date
+dateStart:date
+channel:string
+title:string
<<constructor>>
+createVS:int
+updateVS:void
+deleteVS:void
+startTransfer:int
1
1..
Content
+contentType:string
+fileName:string
+fileUpdate:boolean
Figura 55 - Diagramma delle classi
Al suo interno, assetManager eseguirà le operazioni come indicato nel diagramma
delle attività. Allo scopo però di una definizione migliore dello scenario, si ricorre
proprio al sequence diagram visto in precedenza.
L’insieme di questi diagrammi, resi a tale livello di astrazione, fornisce un modello
descrittivo della specifica dei requisiti. I progettisti che, nelle fasi successive del
processo, raccoglieranno tale documentazione, avranno in input tutte le indicazioni
105
Capitolo 4
su “cosa” il sistema deve fare. Le informazioni prodotte fino a questo punto saranno
approfondite nella successiva fase di design [30].
4.3 La progettazione
In questa fase vengono approfondite le tematiche viste ad un più alto livello di
dettaglio. I modelli che verranno presentati mostreranno un’architettura di sistema ed
i suoi comportamenti interni. Nell’ottica di uno sviluppo iterativo ed incrementale, i
modelli d’analisi sono successivamente elaborati con aggiunta di dettagli tecnici e
considerazioni hardware / software attraverso il modello d’analisi diventa un modello
di progetto. La distinzione tra analisi e progetto non è netta. Gran parte della
discussione vista nel paragrafo precedente potrebbe essere classificata come progetto
piuttosto che analisi.
Il progetto architetturale comprende decisioni sulle strategie di soluzione per i
componenti del sistema.
4.3.1 Rielaborazione dei casi d’uso
I casi d’uso visti nella fase di analisi possono essere ridiscussi e riorganizzati. In
questa fase si ha un occhio puntato alla successiva fase di implementazione [20].
Si analizza ora il nuovo diagramma dei casi d’uso (Figura 56). Rispetto all’analogo
grafico di livello superiore, si notano alcune differenze che verranno presto
giustificate. La pubblicazione rappresenta la missione principale del software.
Tuttavia, le modalità operative della sua gestione cambiano a seconda del tipo di
asset package da pubblicare. Infatti, dalla specifica si apprende che, in presenza di
content video da sottoporre ad encrypting, è richiesta l’interazione con un sistema
esterno non dotato di interfaccia. Se l’asset da pubblicare non dovesse richiedere
l’utilizzo dell’ XTV-Encryptor [14], la fase di pubblicazione può essere progettata in
modo che diventi automatica. Di qui i due casi d’uso “manual publish” e “automatic
publish”.
106
Capitolo 4
publish
Manual Publish
Automatic publish
<<include>>
get inbox
XMLDAM
User
get Encrypt Content
<<include>>
<<include>>
Send to database
Transfer Files
Figura 56 - diagramma dei casi d'uso
La descrizione di questi casi d’uso verrà fornita più avanti da altre viste che UML
prevede nella descrizione del modello: i collaboration diagram e sequence diagram.
Vanno sottolineate le profonde differenze con il corrispondente diagramma della fase
di analisi dei requisiti. Questa, infatti, vedeva l’XTV Encryptor come attore ma, in
realtà, essp non è parte del dominio del sistema. A tale scopo, si è introdotto il caso
d’uso “get Encrypted content” che meglio ridefinisce l’esigenza di usare un ente
esterno. Come sarà mostrato più avanti, il sistema potrà segnalare la necessità di una
107
Capitolo 4
operazione esterna ma, non essendo questa sotto il proprio controllo, è lasciata la
cura della stessa all’operatore. Questi, al termine delle operazioni di encrypting, sarà
tenuto a fornire nuovamente l’input al sistema, questa volta in formato MPEG-2
encrypted. Quanto esposto verrà mostrato sul diagramma di collaborazione che
“realizzerà” il caso d’uso. Gli altri casi d’uso descrivono operazioni già viste nella
fase dei requisiti e per questo, in questa sede, omesse in quanto fornirebbero uno
scarso valore aggiunto. I diagrammi che seguono saranno abbastanza esaustivi, al
punto da consentire la successiva fase di implementazione.
4.3.2 La struttura delle classi progetto
Un modello disegnato in una prospettiva concettuale, che quindi riflette i requisiti del
dominio del problema in oggetto, è costituito da classi appartenenti al dominio stesso
e da classi derivanti da un’analisi approfondita . Il progetto è stato quindi realizzato
partendo dal materiale prodotto nella fase iniziale di raccolta delle informazioni. I
diagrammi prodotti in un’ottica di specifica o di implementazione riflettono il
progetto o l’implementazione che si ha in mente e possono appoggiarsi alle classi di
un modello concettuale. Nel caso specifico, le classi prodotte in fase di analisi
vengono completate con altre classi che hanno responsabilità di controllo. Il progetto
è stato impostato con un approccio “Boundary-Control-Entity”, ovvero frontiera,
controllo, entità. Una classe boundary descrive gli oggetti che rappresentano
l’interfaccia tra un attore ed il sistema. Una classe control descrive gli oggetti che
percepiscono gli eventi generati dall’utente e controllano l’esecuzione di un processo
di business. Una classe entità, descrive gli oggetti che rappresentano la semantica del
sistema delle entità nel dominio applicativo [20].
I package in Figura 57 separano idealmente le classi del sistema secondo la loro
responsabilità. Nel package <<entity>> troviamo le classi che rappresentano gli
oggetti persistenti . Nel package <<control>> troviamo le classi dotate delle
operazioni di controllo. Non a caso, sono quelle che non espongono attributi legati
alla persistenza, ma al loro stato di attività. In ultimo, il package <<boundary>>
comprende le classi che dovranno servire per la costruzione della GUI e
comprendono form, bottoni, ed altri oggetti che servono all’interazione con l’attore.
108
Capitolo 4
Figura 57 - Package Classi del sistema
4.3.3 Il modello delle classi di progetto
In questo paragrafo viene messo a fuoco il progetto del package <<control>> ed
<<entity>>. La fase di analisi ha indicato le classi e le loro responsabilità. Questi
concetti qui vengono ripresi per il design del sistema.
La soluzione adottata modella il problema con il seguente ragionamento. L’ingresso
di un asset package nel sistema provoca l’apertura di un “ticket” che deve essere
portato in uscita al sistema dopo aver subito le operazioni che sono richieste
dall’esterno tramite i metadati contenuti nel package stesso.
Questo ticket gode dunque di un ciclo di vita proprio attraverso le varie fasi di
lavorazione. La sua evoluzione viene controllata da alcune classi che si occupano
della propria gestione. Rispetto al diagramma visto in sede di analisi, dunque, sono
state introdotte le seguenti classi (Figura 58):

Ticket: è la classe che gestisce il ciclo di vita dell’asset package di cui viene
richiesta la pubblicazione. Le operazioni che tale classe implementa sono:
109
Capitolo 4
1. createTicket: è il cotruttore e ritorna un ID per il ticket
2. changeState: consente, se invocato, il cambiamento dello stato del
ticket da parte del chiamante.
3. closeTicket: effettua la chiusura del ticket.
I suoi attributi consentono la gestione da parte delle classi di controllo e
vengono settati in fase di creazione.

MovieQueueManager: è la classe di controllo che si occupa della gestione
della coda di movie content da pubblicare. I suoi metodi sono
1. push, che consente l’inserimento in coda
2. pop: consente l’estrazione dalla coda
3. transferToEdge (privato) che costituisce l’operazione principale della
coda.

PublicationQueueManager: è la classe di controllo che si occupa della
gestione della pubblicazione di preview e cover content. Inoltre, attraverso le
sue operazioni, si fa carico della scrittura dei metadati verso il database. Le
sue operazioni sono:
1. start / stop che attivano la gestione automatica dell’estrazione degli
elementi per sottoporli al processo previsto.
2. push che consente l’inserimento dei ticket in coda
I metodi privati effettuano le operazioni sui ticket:
1. transferPreview: invia i preview content verso i service group
2. sqlExecute: crea ed esegue lo statement SQL per la scrittura verso il
database. Si occupa altresì della connessione verso il database

Log: è la classe attraverso la quale i vari processi possono registrare la loro
attività. L’unica operazione esposta è “write” che consente la scrittura
nell’apposita struttura dati

Tool: è una classe di controllo che racchiude le funzionalità accessorie
richieste dalla specifica dei requisiti, quali la creazione di report e l’update di
un VOD. In entrambi i casi c’è un’interazione diretta tra <<boundary>> e
sistema esterno. Pertanto questa classe è stata nascosta dalla Figura 58.
110
Capitolo 4
VOD
Cover
+title:string
1
1..2
+file_update:boolean
+aspectRatio:string
1
1
1
Ticket
Preview
+tickedID:int
+creationDate:int
+loadMode:string
+previewFileUpdate:boolea
+movieFileUpdate:boolean
+coverFileUpdate:boolean
1
+coverContent:string
+previewContent:string
+movieContent:String
+state:string
+fileUpdate:boolean
+title:string
1
AssetPackage
EPG
+assetID:int
+fileName:string
+loadmode:string
+dateCreated:date
+dateEnd:date
+dateStart:date
+channel:string
1
Movie
<<constructor>>
+createTicket:int
+changeState:void
+closeTicket:void
+file_update:boolean
+encrypting:boolean
<<use>>
<<handle>>
<<handle>>
AssetManager
MovieQueueManage
+isActive:boolean
PublicationQueueManag
<<send>>
+isActive:boolean
+isActive:boolean
<<send>>
-previewTransfer:void
-coverTransfer:void
+start:boolean
+stop:boolean
+push:boolean
-sqlExecute:boolean
-log:void
+start:boolean
+stop:boolean
-checkInbox:boolean
-checkMetadata:boolea
-askForEncrypt:void
-moveAsset:boolean
-log:void
+push:boolean
+pop:boolean
-transferToEdge:void
<<send>>
<<write>>
<<write>>
<<send>>
<<write>>
Log
ServiceGroup
+writeLog:void
<<constructor>>
+createSG:int
+updateSG:void
+deleteSG:void
+sendToSGs:void
EdgeServer
1
1..* +destinationIP:string
+port:string
+login:string
+password:string
+path:string
<<constructor>>
+createVS:int
+updateVS:void
+deleteVS:void
+startTransfer:int
Figura 58 - Diagramma delle classi di progetto
111
Capitolo 4
La necessità di introdurre due distinte classi per la gestione di code è presto
giustificata. Con riferimento a quanto esposto in fase di analisi, quando sono stati
presentati i diagrammi delle attività, appare evidente che processo di ingestion dei
VOD può essere ottimizzato. Infatti, un VOD con LoadMode = “update”, che non
richieda encrypting del movie content, e quindi il trasferimento dello stesso verso gli
edge, potrebbe essere processato prima di un asset package che, pur essendo arrivato
cronologicamente prima,
richieda anche l’uso dell’XTV-Encryptor. La coda di
quest’ultimo, infatti, potrebbe costituire il collo di bottiglia dell’intero processo di
pubblicazione dei VOD. Basti pensare che, generalmente, il solo processo di
encryption richiede circa 20 minuti, mentre la pubblicazione di un
asset che
contenga solo cover e preview può durare circa un paio di minuti. L’idea è quindi
quella di utilizzare code separate per le tipologie di processo. Visto che i tempi di
pubblicazione dei VOD senza movie asset sono paragonabili a quelli delle EPG, è
conveniente modellare le attività del processo usando due le code di job
PublishQueueManager e MovieQueueManager che gestiscono rispettivamente:

Asset di tipo EPG e VOD senza movie content

Asset dotati di movie content
All’interno di ciascuna coda vengono rispettate le precedenze imposte dall’ordine di
arrivo. I job che escono dalla coda MovieQueue, vengono poi inseriti nella
PublicationQueue per la fase finale della pubblicazione che si occuperà del
trasferimento dell’eventuale cover e dell’eventuale preview content. Al termine dei
trasferimenti verrà costruito l’opportuno statement SQL che completerà il ciclo di
vita del ticket con la scrittura nel database. Va esplicitamente notato che non è
necessario predisporre una coda in ingresso al sistema. Infatti, dal momento che gli
asset package vengono forniti attraverso la condivisione tra DAM e sistema di una
memoria condivisa, il sistema stesso sceglierà dal disco l’asset package più anziano
attraverso un check sulla data di creazione dello stesso, attuando così una politica
LIFO senza necessità ulteriori strutture dati. Ulteriori dettagli saranno più chiari nei
modelli che esprimeranno una vista dinamica del sistema.
112
Capitolo 4
4.3.4 Diagrammi di collaborazione
La fase di progetto ha messo in evidenza la necessità di aggiungere un vincolo alla
politica di estrazione di un job dalla coda dei package senza asset. Infatti, non
essendo stato specificato dal DAM nessun vincolo temporale tra l’invio di package
successivi relativi allo stesso VOD, potrebbe accadere di ricevere un package, che
richieda il solo update dei metadati mentre, nella coda di encrypting o di transfer dei
movie, sia già presente un package che deve operare sullo stesso VOD.
In tal caso, il package che si trova nella coda dei job costituiti dai soli metadati, non
può essere estratto fino a quando un altro package dello stesso VOD, che sia arrivato
prima, risiede nelle code riservate ai movie.
Questa politica basata su tali relazioni di precedenza equivale a dire che, ogni VOD
in ingresso al sistema crea, virtualmente, una propria coda nella quale dovranno
essere inseriti eventuali package che si riferiscono allo stesso VOD. Tali code VOD
vengono gestite con politica LIFO. Tutti gli altri VOD che non richiedono
trasferimento content possono essere inseriti nella coda di scrittura del database. Con
questa
politica,
vengono
soddisfatti
i
requisiti
del
committente
e
contemporaneamente viene ottimizzato il tempo medio di lavorazione dei job.
Il diagramma di collaborazione, in Figura 59, illustra l’insieme delle azioni che il
sistema deve svolgere per portare a pubblicazione un asset package dotato di movie
content da sottoporre ad encrypting.
Lo user, attraverso la GUI, lancia un messaggio di attivazione all’asset manager.
Questa circostanza scatena la sequenza di eventi che viene riportata.
113
Capitolo 4
am:AssetManager
1.1.1.1.2: push(ticketID):boolean
mqm:MovieQueueManag
1.1: checkMetadata():boolean
1.1.1: moveAsset():boolean
1.1.1.1: createTicket():int
1.1.1.1.3:[Encrypting=Y] //notifyEncryptionRequest 4.1: sendToSGs(movieContent):void
1: checkInbox():boolean
2:[encryptionPerformed] pop(ticketID):boolean
4: transferToEdge(movieContent):void
1.1.1.1.1: ticketID:=createTicket():int
1.1.1.1.4: changeState(waitForEncrypt):void
encrypting
must be
performed
from
external
system
sg:ServiceGrou
4.1.1:*[for eaches in sg] startTransfer(movieContent):
5.1.1.2.1: startTransfer(previewContent):int
es:EdgeServe
<<actor>>
XMLDAM Use
5: push(ticketID):boolean
3: changeState(ticketID):void
5.1.1.2: sendToSGs(previewContent):void
t:Ticket
5.1.1.1: closeTicket():void dqm:PublicationQueueManag
5.1:*[while dqm.isEmpty=False and isActive=True] sqlExecute(int,string):boolean
5.1.1:[coverFileUpdate = True] coverTransfer(converContent):void
Figura 59 - Pubblicazione manuale: Collaboration diagram
1. am (oggetto, istanza della classe assetManager) comincia il proprio processo
automatico eseguendo un checkInbox. Tale operazione raccoglierà, se
presente, l’asset package più “anziano” presente nella directory inbox
2. am, tramite il metodo checkMetadata, esegue il controllo dei metadati
presenti nel file XML del package. Se sono errati, li scarta spostandoli nella
sottodirectory “errori” altrimenti continua il processo.
114
Capitolo 4
3. am sposta l’asset package nella directory “pubblicare”, con il metodo
moveAsset.
4. am crea un oggetto t della classe Ticket e ne valorizza tutti gli attributi
avendo letto i corrispondenti metadati nel file XML.
5. se i metadati relativi all’asset movie indicano FileUpdate=True ed
Encryption=Y, allora am inserisce il ticket nella coda mqm
6. lo user viene notificato del fatto che è richiesta un’operazione di encripting
manuale
7. lo user esegue il pop dalla coda
8. lo user cambia lo stato del ticket indicando il nuovo stato (in encrypting) e
provvede alla trasformazione del file MPEG-2
9. a encrypting terminato, lo user provvede a cambiare nuovamente lo stato del
ticket (in transfer) e avvia il trasferimento verso il serviceGroup sg.
10. sg provvederà al trasferimento verso tutti gli edge server es.
11. al termine del file transfer, lo user sposterà il ticket nella coda
PublicationQueueManager.
12. quando il ticket verrà processato, verranno eventualmente trasferiti gli asset
cover se presenti (cover FileUpdate=True)
13. successivamente, verrà eventualmente trasferito l’asset preview se presente
(preview FileUpdate=True)
14. alla fine dei trasferimenti file, viene creato lo statement SQL, aperta la
connessione verso il database di OMP e quindi avviene la scrittura nello
stesso.
15. il ticket viene chiuso e la fase di pubblicazione si è conclusa.
Nel caso particolare esaminato, si può osservare la sequenza di operazioni cha ha
luogo quando Encryption=Y, movie FileUpdate=True, cover FileUpdate=True,
preview FileUpdate=True. La presenza di messaggi sottoposti a condizione rende lo
scenario adattabile ad altri valori.
115
Capitolo 4
Si noti che la coda gestite da PublicationQueueManager esegue una iterazione tale
che processa sempre eventuali ticket in coda.
Nella seguente Figura 60, è possibile osservare anche il sequence diagram
corrispondente a tale scenario. Le etichette dell’illustrazione risulteranno poco
leggibili, per questo si rimanda alla documentazione elettronica allegata. Rimane la
possibilità di seguire il flusso temporale dei messaggi.
am
AssetManager
mqm
MovieQueueManage
dqm
DatabaseQueueManage
sg
ServiceGroup
es
EdgeServer
XMLDAM Use
1: checkInbox():boolean
1.1: checkMetadata():boolean
t
1.1.1: moveAsset():boolean
1.1.1.1.1:
Ticket ticketID:=createTicket():int 1.1.1.1: createTicket():int
1.1.1.1.2: push(ticketID):boolean
encrypting
must be
1.1.1.1.3:[Encrypting=Y] //notifyEncryptionRequest
performed
from
1.1.1.1.4: changeState(waitForEncrypt):void
external
system
2:[encryptionPerformed] pop(ticketID):boolean
3: changeState(ticketID):void
4: transferToEdge(movieContent):void
4.1: sendToSGs(movieContent):void
4.1.1:*[for eaches in sg] startTransfer(movieContent):
5: push(ticketID):boolean
5.1.1.1: closeTicket():void
5.1:*[while dqm.isEmpty=False and isActive=True] sqlExecute(int,strin...
5.1.1:[coverFileUpdate = True] coverTransfer(converContent):void
5.1.1.2: sendToSGs(previewContent):void
5.1.1.2.1: startTransfer(previewContent):int
Figura 60 - Sequence diagram pubblicazione manuale
Viene ora presentato un altro scenario in cui non è richiesta interazione da parte
dell’utente, a meno dell’avvio della pubblicazione. In tal caso infatti, si ha che il
valore movie FileUpdate=False e quindi non è richiesta l’interazione con il sistema
di encription. Segue il relativo diagramma di collaborazione in Figura 61
116
Capitolo 4
1: start():boolean
am:AssetManag
<<actor>>
XMLDamUser
1.2.1.1: ticketID:=createTicket():int
1.2.1.2:[Encrypting=N] changeState(ticketID):void
t:Ticket
1.2: checkInbox():boolean
1.2.1: checkMetadata():boolean
1.2.1.3:[Encrypting=N] push(ticketID):boolean
1.1: start():boolean
2.3: closeTicket(ticketID):void
dqm:PublicationQueueMan
2:*[while isActive=true][if isEmpty = false]
2.2:[coverFileUpdate = True] coverTransfer(coverName):v
2.2.1: sqlExecute(ticketID, loadmode):boolean
es:EdgeServe
2.1:[previewFileUpdate=True] sendToSGs(PrevieFileName):
2.1.1:*[for each es in sg] startTransfer(previewContent):int
sg:ServiceGrou
Figura 61 - Pubblicazione automatica: diagramma di collaborazione
La seguente sequenza di operazioni descrive meglio lo scenario.
1. am (oggetto, istanza della classe assetManager) comincia il proprio processo
automatico eseguendo un checkInbox. Tale operazione raccoglierà, se
presente, l’asset package più “anziano” presente nella directory inbox
117
Capitolo 4
2. am, tramite il metodo checkMetadata, esegue il controllo dei metadati
presenti nel file XML del package. Se sono errati, li scarta spostandoli nella
sottodirectory “errori” altrimenti continua il processo.
3. am sposta l’asset package nella directory “pubblicare”, con il metodo
moveAsset.
4. am crea un oggetto t della classe Ticket e ne valorizza tutti gli attributi
avendo letto i corrispondenti metadati nel file XML.
5. am,
sposta il ticket nella coda PublicationQueueManager attraverso
un’operazione di push
6. quando il ticket verrà processato, verranno eventualmente trasferiti gli asset
cover se presenti (cover FileUpdate=True)
7. successivamente, verrà eventualmente trasferito l’asset preview se presente
(preview FileUpdate=True)
8. alla fine dei trasferimenti file, viene creato lo statement SQL, aperta la
connessione verso il database di OMP e quindi avviene la scrittura nello
stesso.
9. il ticket viene chiuso e la fase di pubblicazione si è conclusa.
Va sottolineata una relazione di precedenza tra due asset con ticket attivo che si
riferiscono
allo
stesso
VOD:
devono
essere
processati,
nella
coda
PublicationQueueManager secondo l’ordine di timestamp di creazione del ticket. In
altre parole, deve essere processato sempre prima il più anziano. Tale vincolo
assicura la consistenza dei dati e impedisce che asset package con loadmode=update
(che tipicamente non richiedono encrypting) possano essere processati prima di
quelli con loadmode=insert.
Entrambi I diagrammi riportano uno scenario molto simile. Del resto tutti I possibili
scenari si riferiscono alla combinazione degli attributi cosiddetti di “controllo”
contenuti nei metadati. Come si è visto, sono questi a modificare le interazioni
richiesti all’XMLDAM User e quindi a richiedere che venga fornito il file MPEG-2
in versione encrypted.
118
Capitolo 4
Si fa notare che anche se l’XTV-Encryptor fosse stato dotato di una interfaccia tale
da consentirne il controllo dal sistema in esame, il beneficio della duplice coda
sarebbe rimasto un fatto concreto. L’implementazione di queste due code, implica,
nei confronti dei dati in input, una politica che somiglia al classico Shortest Job First
(SJF) in cui però i task “shortest” sono considerati quelli che non necessitano di
encrypting. Comunque, si ribadisce
che deve essere rispettata la precedenza
cronologica per ticket “in vita” che abbiano un riferimento allo stesso asset.
In Figura 62, si riporta il sequence diagram dello scenario appena descritto.
am
AssetManage
dqm
PublicationQueueManag
sg
ServiceGroup
es
EdgeServer
XMLDamUser
1: start():boolean
1.1: start():boolean
t
Ticket
1.2: checkInbox():boolean
1.2.1.1: ticketID:=createTicket():int
1.2.1: checkMetadata():boolean
1.2.1.2:[Encrypting=N] changeState(ticketID):void
1.2.1.3:[Encrypting=N] push(ticketID):boolean
2.1:[previewFileUpdate=True]
sendToSGs(PrevieFileName):void
2:*[while isActive=true][if isEmpty
= false]
2.1.1:*[for each es in sg] startTransfer(previewCont
2.2:[coverFileUpdate = True] coverTransfer(coverName):void
2.2.1: sqlExecute(ticketID, loadmode):boolean
2.3: closeTicket(ticketID):void
Figura 62 - Sequence diagram
Con questi diagrammi che mostrano il modello dinamico del progetto si è già vicini
alla possibilità di passare all’implementazione.
Tutto sommato, vanno prima definite le strutture dati tese a supportare le classi di
controllo.
119
Capitolo 4
4.3.5 Statechart Diagram
Come già riportato in precedenza, la modellazione del problema attraverso un ticket
che evolve nel suo ciclo di vita, bene si presta ad una rappresentazione tramite
diagrammi di stato. Anzi, questi sono stati la base di partenza per la corretta gestione
del sistema. Con riferimento ai VOD, che richiedono encrypting e pubblicazione
sugli edge server, sono stati analizzi i possibili stati che un ticket può assumere. La
corrispondenza tra lo stato di un ticket e quello di un asset in pubblicazione è
naturalmente di tipo 1:1. A seconda del ciclo di vita, in prima istanza, possono essere
individuati i seguenti stati.
1. creato
2. con movie content in encrypting
3. con movie content in trasferimento verso video server
4. in pubblicazione
questi stati possono essere modellati nel semplice diagramma in Figura 63:
Figura 63 - Ticket: Statechart diagram
Va sottolineato che l’attore ha la possibilità di arrestare il processo di ingestion.
Questa operazione, una volta invocata, potrebbe creare problemi di inconsistenza
sullo stato per i ticket che in quel momento si trovano in una transizione di stato.
L’utente ha la possibilità di
120
Capitolo 4
1. evitare il push di nuovi ticket nelle code e lasciare terminare quelli
attualmente in elaborazione
2. abortire tutte le elaborazioni in corso
nel secondo caso, i ticket dovranno tornare allo stato precedente, ed abortire la
transazione in cordo Per evitare ambiguità, si può aumentare la granularità,
introducendo nuovi stati. Avendo due code, il caso peggiore prevede che,
nell’eventualità di un segnale di “stop” inviato dall’utente, entrambe le code stiano
processando un ticket. Per la coda dei trasferimenti movie verso i service group, è
stato aggiunto uno stato di attesa. Il ticket in trasferimento viene bloccato ed il suo
stato deve ritornare in attesa. Analogamente, per la coda di pubblicazione, la
transazione viene bloccata, viene eseguito il rollback dell’operazione di scrittura
verso il database di OMP ed il ticket riprende lo stato “wait for publication”. Il
nuovo diagramma è riportato in Figura 64.
user encrypts[FileUpdate=True,
Encryption=Y]
inEncrypting
user transfers[ecrypted]
waitForTransfer
assetManager pushes into
pub_queue[FileUpdate=True,
Encryption=Y]
abort transfer start transfer
waitForPublication
inTransfer
user pushes[transferred on service
group]
start publication
abort publication
inPublication
Figura 64 - Statechart con maggiore granularità
Naturalmente, gli asset di tipo EPG andranno direttamente nello stato
waitForPublication e simile sorta subiranno gli asset con package privo di content.
121
Capitolo 4
Queste considerazioni possono essere quindi ulteriormente raffinate e proposte in un
nuovo diagramma che comprende anche gli altri casi.
Si possono distinguere diversi casi che vengono rappresentati in Figura 65.
[MovieFileUpd=True,
Encryption=True]
waitForEncrypting
Open
[manual]
closed
In encrypting
[MovieFileUpd=True,
Encryption=False]
InPublication
[manual]
Encrypted
[EPG or Metadata Update]
waitForPublication
In transfer
waitForTransfer
Figura 65 - Diagramma esteso degli stati ticket
Per questioni di leggibilità, da questo schema sono stati omessi i casi in cui una
transizione di stato dovesse fallire. In tal caso, come già visto, lo stato del ticket torna
a quello precedente. Se esistono ticket che si riferiscono a uguali Asset ID, entrano in
gioco i vincoli di precedenza. In tali ipotesi, dovrà essere processato il ticket più
anziano e tutti gli altri conserveranno il loro stato. È bene notare che questa
competizione può avere luogo solo se almeno uno dei ticket si trova nello stato
waitForPublication. Infatti, per costruzione, se due ticket chiedono uguali
operazioni, queste saranno serializzate lungo lo stesso percorso. Il sorpasso implica
che il ticket più giovane sarà costretto ad aspettare, nello stato waitForPublication
e che i predecessori vengano tutti pubblicati prima.
122
Capitolo 4
Allo scopo di ottimizzare i tempi di attesa, è stato previsto un meccanismo che renda
possibile
il
trasferimento
dei
video
content
verso
più
service
group
contemporaneamente. Questo aspetto degrada ovviamente le prestazioni di rete, per
tale ragione, si è cercato un compromesso tra due aspetti
1. rendere fruibile un asset package in tempi brevi per consentire il controllo di
fruibilità dello stesso (che richiede la visione dell’intero VOD)
2. ottimizzare i tempi di attesa nella coda dei trasferimenti
L’idea è stata quella di stabilire un tetto per il numero massimo di trasferimenti in
parallelo. Quindi, il passaggio dallo stato waitingForTransfer a quello inTrasfer passa
attraverso un controllo su tale numero.
concurrentTransfer
less or eq then
maxTransferAllowed
[true]
[False]
inTransfer
waitForTransfer
update
concurrentTrasnfer
ServiceGroup Transfe
next ticket
waitForPublication
Figura 66 - Gestione coda dei trasferimenti
Le transizioni degli stati sono evidentemente dipendenti dal numero di trasferimenti
in corso. Si nota (Figura 66) che l’operazione di Fork crea un processo che si
occuperà del trasferimento verso i service group.
123
Capitolo 4
4.3.6 Progetto della struttura dati
La struttura dati di cui necessitano le classi di controllo è estremamente semplice. La
scarsa complessità del modello porta direttamente alla struttura dati, in quanto non è
necessario passare per il modello concettuale del database. La trasformazione
richiesta per il passaggio dal diagramma delle classi in uno schema relazionale si
riduce essenzialmente alla trasformazione delle classi entità in tabelle relazionali. Nel
caso in esame, le classi entità sono “Ticket”, “serviceGroup” e “VideoServer”,
“Log”. Queste classi, rappresentando tipi di dati atomici, sono “mappabili”
direttamente in tabelle.
Per ottemperare, dunque, alle responsabilità del sistema è necessaria una tabella che
contenga i ticket che il sistema riceve in ingresso. È stata prevista anche una tabella
che memorizzi le variazioni che avvengono sullo stato di ogni ticket, onde poter
ricostruire la storia di una pubblicazione. E quindi vengono create le tabelle Ticket
e ticketStory. La prima contiene tutte le informazioni relative all’asset package e che
ne determineranno il tipo di ciclo di vita (movie/preview/content FileUpdate,
loadmode, encryption, stato corrente, ed altri attributi). La seconda riporterà la chiave
esterna verso ticket, il timestamp di cambio stato e lo stato abbandonato.
I possibili stati di un ticket sono memorizzati in una apposita tabella “stati”. Un ticket
è quindi vincolato ad assumere uno di questi valori. Per tale ragione è presente, in
“ticket” un campo che è chiave esterna verso la chiave primaria della tabella “stati”.
Per la gestione dei service group e video server, le uniche informazioni da registrare
sono quelle che consentono il file transfer a tutto il gruppo di server. Due tabelle,
“serviceGroup” e
“videoServer”, sono poste rispettivamente in relazione 1:n e
rispondono pienamente all’esigenza. La prima riporta un identificativo (chiave
primaria) e la descrizione del serviceGroup, mentre la seconda riporterà la chiave
esterna per la relazione verso serviceGroup.
per ogni edge, le informazioni
necessarie ad espletare il trasferimento file.
Infine, la persistenza dei dati relativi al diario delle operazioni non è affidata al
database. Tali informazioni verranno scritte un un file testo.
124
Capitolo 4
Dal diagramma è stata nascosta la tabella che conterrà le informazioni di supporto
alle operazioni di trasferimento file.
In Figura 67, viene mostrato il diagramma ER [24] della struttura dati.
Figura 67 - Diagramma ER
Ricapitolando, è evidente che le due code risiedono fisicamente nella stessa struttura
dati. I gestori delle code processano ticket che si trovano in un certo stato, come
definito dallo statechart diagram e pertanto accedono alla stessa tabella. Questi
dettagli verranno analizzati nel paragrafo riservato all’implementazione.
4.3.7 Il progetto dell’interfaccia utente
Il committente ha richiesto una interfaccia intuitiva e semplice da usare. Del resto,
l’interazione che il sistema richiede è molto limitata.
La definizione della GUI, a differenza del resto del progetto, ha seguito un approccio
prototipale. Sono stati definiti, in fase di analisi, alcuni prototipi e sottoposti al
committente. Questi hanno subito alcune trasformazioni che hanno prodotto
un’interfaccia conforme a quanto richiesto dal committente. Il principio
125
Capitolo 4
fondamentale è che l’utente ha il controllo del sistema mentre questo controlla
l’integrità, la correttezza e la sicurezza dei dati. Il sistema è governato da eventi
(messaggi) ai quali gli oggetti reagiscono [20].
In questa ottica, i messaggi che l’utente invia al sistema si trasformano in eventi
raccolti dall’interfaccia. Da questa sono poi invocate le operazioni di controllo che
hanno la responsabilità della gestione del sistema. Talvolta queste accedono alle
strutture dati e quindi, a loro volta, invocano operazioni che agiscono sulla
persistenza degli oggetti.
Nel caso specifico, sono stati previsti:

un form unico che contenga tutti gli stumenti di interazione

una cartella a schede o “tabstrip” che metta a disposizione più schede, ognuna
orientata alla gestione di un problema specifico, ovvero:
1. una scheda che fornisca, al colpo d’occhio, l’esatta situazione di
pubblicazione in corso. Attraverso questa scheda l’utente ha la possibilità
di avviare e fermare l’intero processo. Sono altresì previsti opportuni
bottoni che consentono di cambiare manualmente lo stato di un ticket.
Questa operazione si rende necessaria a causa dell’interazione non
controllabile, con l’XTV Encryptor.
2. Una scheda che consenta di effettuare le operazioni classificate come
Tools
3. Una scheda che consenta di gestire i service group e i rispettivi video
server.
4. Una scheda che contenga le informazioni della configurazione del
sistema, quali, ad esempio, i parametri per la connessione a database, il
livello di log ed altri.
5. Una scheda che consenta la lettura facilitata del log e la sua gestione
L’interfaccia utente si presenta come mostrato in Figura 68.
126
Capitolo 4
Figura 68 - Interfaccia utente: scheda Main Panel
Si può subito notare l’uso di un browser a riga. L’utente può scorrere verso l’alto o
verso il basso usando la barra di scorrimento verticale o i tasti cursore. Il browser è
interno alla cartella a schede ed impegna la prima scheda, chiamata “main panel”.
Nella parte destra si può osservare una zona che contiene i comandi principali a
disposizione dell’utente:

Start Asset Manager: avvia la gestione secondo quanto visto in precedenza

Stop Asset Manager: arresta la gestione.

Change ticket State: consente di cambiare manualmente lo stato di un ticket.
Si voleva effettuare un controllo per limitare tale possibilità agli stati che
coinvolgono la pubblicazione manuale, ma l’utente, sperimentando il
prototipo, ha richiesto la libera facoltà di cambiare lo stato ticket. Ovviamente
tali operazioni si riflettono nel database.

Stats: riporta la lunghezza delle code in tempo reale.
Ciccando due volte su un rigo ticket, viene mostrato il contenuto dell’asset package
relativo ai metadati.
La seconda scheda, in Figura 69, riporta invece i bottoni per la generazione dei report
e dell’operazione di azzeramento user shelf, descritta nelle fasi precedenti. Anche
127
Capitolo 4
qui, la selezione del tipo di report è guidata tramite radio-button e l’output è fornito n
un file xml su disco. Inoltre sono presenti le funzionalità di ricerca nel database di
OMP e di update dei VOD. La ricerca avviene per assetID, titolo e FileID (nome file
dei metadati XML)
Figura 69 - Interfaccia utente: scheda Tools
La terza scheda, in Figura 70, riporta invece la gestione dei serviceGrup e video
Server. È dotata di un browser di riga nel quale è possibile editare, aggiungere o
cancellare record. È mostrata in Figura 71.
Subito dopo viene mostrata anche la quarta scheda. È relativa alle impostazioni di
base del programma, quali informazioni per la connessione al database, dimensione
soglia per la rotazione dei log ed intervallo temporale di polling sul disco condiviso
per la raccolta dei nuovi asset packages in arrivo. E’mostrata in Figura 72Figura 71.
128
Capitolo 4
Figura 70 - Interfaccia utente: scheda Service Group
Figura 71 - Interfaccia utente: scheda Settings
129
Capitolo 4
L’ultima scheda del software di ingestion, in Figura 72, è quella relativa alla
visualizzazione del log. Ci sono due bottoni che consentono di ricaricare il log
mostrano le sole righe con messaggi di errore oppure il log completo. È possibile
anche bypassare l’operazione di rotazione automatica del log ciccando sull’apposito
bottone “rotate Log”.
Figura 72 - Interfaccia utente: scheda Log
Questa scheda chiude la sezione dedicata all’interfaccia utente.
4.4 L’implementazione
Durante questa fase vengono acquisiti tutti gli artefatti delle fasi precedenti e viene
dato luogo alla stesura del codice. Nel rispetto del vincolo imposto dal committente,
però, il linguaggio di programmazione scelto è Microsoft Visual Basic 6.0 sp 6 [25].
Tale linguaggio non è orientato agli oggetti, pur contemplando alcuni tipi di strutture
che, entro certi limiti, forniscono i costrutti per creare classi. Questa limitazione
implica l’adozione di un modello di programmazione procedurale. Tutto sommato,
per limitare la frattura tra la fase di progettazione e quella di sviluppo si è usato il
concetto di modulo Visual Basic quale sostituto di una classe.
130
Capitolo 4
È stato quindi sviluppato un modulo VB che agisce come classe <<control>> e ne
contiene tutte le operazioni così come sono state definite nella fase di progetto.
Verranno ora esaminate le operazioni VB (procedure e function) previste dal layer di
progetto. La struttura dati delle code è implementata con lo schema fisico del
database. In altre parole, la tabella Ticket, che è stata vista nella fase di progetto del
database, e contiene tutti i ticket, ha un campo che contiene lo stato del ticket. Tutti i
record con stato waitingForPublish rappresentano gli elementi della coda di
pubblicazione. In particolare l’unico ticket con stato InPublishing rappresenta la
testa della coda e quindi l’elemento che il sistema sta processando. Analogamente,
tutti i record con lo stato ticket = waitingForTransfer rappresentano gli elementi
della coda di trasferimento file e quello con stato pari a inTransfer è quello oggetto
del trasferimento. Lo spostamento di un ticket da una coda all’altra avviene
esclusivamente variando il valore del suo stato.
Fatta questa premessa, si descrive l’algoritmo generale implementato.
4.4.1 Algoritmo generale
Da quanto visto nelle fasi precedenti, il software di ingestion ha essenzialmente un
funzionamento iterativo: tutti i ticket vengono presi in carico e vengono portati alla
pubblicazione attraverso una sequenza di operazioni che si può distinguere
essenzialmente in due tipologie. Pubblicazione totalmente automatica, ovvero che
non prevede interazione con XMLDAM user, e pubblicazione assistita, cioè quella
che richiede encrypting e quindi l’intervento manuale per la transizione di stato.
Possiamo quindi tracciare un diagramma delle attività che mostra i passi elaborativi.
Il diagramma (Figura 73) si riferisce al caso in cui la directory inbox contiene nuovi
Asset Package. Le transizioni di stato di un ticket possono essere automatiche o
meno, in dipendenza dai metadati presenti nel file XML. Nella precedente figura è
riportato tale diagramma. Le varie attività che compaiono nel diagramma
corrispondono ai metodi della classe asset manager che si sono definiti in fase di
progettazione.
A
livello
implementativo,
questi
sono
stati
tradotti
in
function/procedure (a seconda che restituiscano un valore o meno), scritte in Visual
Basic.6.0 sp 6 [25].
131
Capitolo 4
Figura 73 - Algoritmo generale
La seguente tabella riporta le corrispondenze tra azioni i metodi della classe
AssetManager e le function scritte Visual Basic 6.0.
Classe.Metodo
Procedura
AssetManager.checkInbox
checkInbox
AssetManager.checkMetadata
checkMetadata
AssetManager.moveAsset
moveAsset
ServiceGroup.sendToSGs
132
sendToSGs
Capitolo 4
I passi elaborativi elencati richiedono comunque due aspetti che vengono
approfonditi nei prossimi paragrafi. Si tratta della gestione della persistenza per la
struttura dati ticket e della necessità di una classe che consenta di leggere i dati
contenuti nei file XML.
Inoltre l’attività “handle Ticket” racchiude le funzionalità che consentono la gestione
del cambiamento di stato, ovvero dei trasferimenti file e della scrittura verso il
database di OMP. Tutti i ticket che sono pubblicabili automaticamente, ovvero senza
interazione con XMLDAM User, sono processati e portati fino allo stato finale.
L’algoritmo continua fino a quando questi non esistono più. In questo stato si è in
presenza di code vuote oppure code che contengono ticket la cui transizione è
necessariamente manuale. In tal caso, il sistema attende un certo intervallo di tempo
(definibile dall’utente) e poi processa nuovamente \inbox e le code. Quindi se,
durante lo stato di attesa, XMLDAM User dovesse aggiornare lo stato di un ticket e
portarlo in uno stato gestibile autonomamente dal sistema, questo lo tratterà nel
prossimo ciclo. Se la directory \inbox dovesse risultare priva di nuovi Asset Package,
il sistema va nello stato di attesa e, al termine della sospensione vi esce per tornare ad
eseguire checkInbox.
L’algoritmo continua fino alla ricezione di un eventuale segnale di stop inviato
dall’utente.
4.4.2 La gestione della persistenza
L’accesso alla struttura dati è stato implementato usando le classi ADO, messe a
disposizione da Microsoft, per la gestione della persistenza. Tale modello prevede
una gerarchia di oggetti che consentono l’accesso al database, alla tabella ed al
singolo campo. ADO è infatti l'interfaccia più usata per accedere ai database sotto
Windows. In Figura 74, viene proposto uno stralcio del suo modello ad oggetti.
133
Capitolo 4
Figura 74 - Modello ad oggetti ADO - stralcio
L’oggetto Connection consente di stabilire una connessione con la "sorgente dati" e
fornisce un meccanismo per inizializzare il collegamento, eseguire query ed
utilizzare le transazioni sul sottostante database.
Il Provider che viene utilizzato per la connessione con il database è
Microsoft.Jet.OLEDB.4.0. Il metodo Open dell’oggetto Connection consente di
stabilire la connessione con il database. Prima di stabilire una connessione,
l’applicazione imposta la Stringa di Connessione, specificando i parametri necessari.
Il RecordSet è l’oggetto che fornisce i metodi per manipolare ed accedere ai risultati
di una query o di una Stored Procedure. Esso infatti fornisce i metodi necessari per
aggiungere,
ad aggiornare, cancellare e scorrere i record che compongono il
RecordSet stesso.
4.4.3 Init del sistema
Il sistema è progettato in modo che il form della GUI corrisponda a quello di avvio.
Al caricamento di tale form, vengono letti i parametri di configurazione che
risiedono nel file config.txt che risiede nella directory di installazione del
programma. Tali informazioni sono relative ai parametri di connessione con il
134
Capitolo 4
database, quelli per la rotazione dei log e quelli per definire l’intervallo di scansione
della directory \inbox. Queste informazioni vengono mostrate in appositi TextBox
presenti nella scheda “Settings” della GUI. La procedure che esegue l’init si chiama
“leggiConfig”. Inoltre, viene aperto il file di log e mostrato nel ListBox presente
nella scheda “Log” della GUI. La procedura che esegue questa operazione si chiama
LogRefresh ed è possibile richiamarla anche dalla GUI, tramite apposito bottone
nella stessa scheda. Altra operazione che viene eseguita all’avvio del sistema
software è la lettura dei ticket eventualmente presenti nella struttura dati. Questi
verranno mostrarti nel browser di riga. Il codice in carico di questa operazione è il
seguente:
1. Set connA = New ADODB.Connection
2. connA.ConnectionString =
"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & VB.App.Path
& "\xmldam.mdb"
3. connA.Mode = adModeShareDenyNone
4. connA.CursorLocation = adUseClient
5. connA.open
6. Set rs1 = New ADODB.Recordset
7. rs1.open "select assetId, DataArrivo, DescrizioneStato as
Stato, Loadmode, iif(movieFileUpdate=True,'Y','N') as
MovieFileUpd,iif(encrypting=True,'Y','N') as Encr,
ticket.idstato from ticket, stati where stati.idstato =
ticket.idstato order by dataArrivo asc", connA,
adOpenDynamic, adLockOptimistic
8. Set Me.DataGrid1.DataSource = rs1
9. DataGrid1.Refresh
Alla riga 1 viene istanziato l’oggetto Connection. Poi vengono settate le proprietà di
accesso e la connessione viene aperta alla riga 5. Alla riga 7 viene istanziato il
RecordSet che verrà popolato con una operazione di select effettuata sulle tabelle
ticket e stati. Si notano, nella select, alcune operazioni che convertono i valori
booleani True/False in Y,N comprensibili all’operatore. Una volta effettuato
l’accesso alla tabella, il recordset viene messo in collegamento (binding) con
l’oggetto DataGrid e i ticket vengono mostrati nell’apposito browser di riga (righe 8
e 9). Il sistema è ora pronto a ricevere lo “start” dall’utente che avvierà l’algoritmo
generale.
135
Capitolo 4
4.4.4 La lettura dati checkInbox
La procedura in esame ha il compito di leggere la directory inbox e rilevare
l’eventuale presenza di file XML che rappresentano i metadati.
Per rilevare i file si è usato un oggetto della GUI, il FileListBox la cui proprietà
pattern è impostata a come segue:
frmXMLDAM.File1.pattern = “*.xml”
Se vengono trovati file XML, ovvero se
frmXMLDAM.File1.ListCount > 0
questi vengono ordinati secondo la loro data di creazione e poi sottoposti a parsing,
altrimenti la procedura termina. Questo fatto è evidenziato nell’algoritmo generale.
4.4.5 Il parsing dei metadati: checkMetadata
È l’operazione che consente l’esplorazione dei file XLM. Il suo scopo, nell’ambito
del sistema, è duplice. Infatti i metadati vanno consultati in due distinte circostanze:
1. Alla prima apertura del package per l’ inserimento nella tabella dei ticket
2. All’atto della pubblicazione, allo scopo di leggere i valori che dovranno
popolare le tabelle del database di OMP
Un file XML ha una struttura ad albero che si presta facilmente ad una ispezione per
mezzo di un semplice algoritmo ricorsivo. È proprio la strada che viene adottata. In
aiuto, vengono le classi Microsoft per l’accesso al documento XML. Segue uno
stralcio del codice:
1. Set mioFile = New MSXML2.DOMDocument30
2. Set fs = New Scripting.FileSystemObject
3. caricato = mioFile.Load(NomeFileCompleto)
4. If Not caricato Then
5.
scrivilog (NomeFile & " non leggibile - ERROR")
6.
return false
7. End If
8. tipofile = UCase(mioFile.childNodes(0).nodeName)
9. If tipofile = "EPGDATA" Then
10.
esploraEPG mioFile.childNodes(0).childNodes(0), numletti,
arrayvalori, arraynomi
11.Else
12.
esplorando mioFile.childNodes(1), numletti, arrayvalori,
arraynomi
13.End If
136
Capitolo 4
Alla riga 1 viene creato un oggetto DOMDocument30 della classe Microsoft MSXML2.
Il nome ad esso attribuito è “mioFile”. Se il caricamento dello stesso, operato a
mezzo del metodo Load, va a buon fine, la variabile booleana caricato assumerà
valore True ed il file ritenuto valido, almeno a livello XML. Viceversa, il file sarà
scartato. Esistono due categorie di metadati, EPG e VOD, e poiché è possibile
individuare la differenza in base al primo tag, alla riga 8 viene letto il valore e quindi
invocata la procedura di parsing appropriata (righe 10 e 12). I nomi degli attributi, ed
i loro valori, verranno restituiti in due array: arrayNomi ed arrayValori.
Dopodichè, questi valori sono scritti in un RecordSet che generato a tempo di
esecuzione, con visibilità tale da essere accessibile da tutte le function / procedure
del modulo di controllo.
4.4.6 La distribuzione in sottodirectory: moveAsset
A seconda dei metadati letti, gli asset package verranno spostati nelle opportune
sottodirectory come da specifica. I tag assunti sono quelli che decideranno lo stato
successivo del ticket
1. movieUp = CBool(rsAssetG("movie_File_Update"))
2. Encr = IIf(rsAssetG("MOVIE_ENCRYPTION") = "Y", True, False)
3. loadMode = UCase(rsAssetG("package_loadmode"))
Quindi una serie di test condizionali deciderà la destinazione, su disco, degli asset
package:
1. if Encr = True And movieUp = True Then dest = dest & "\CRIPTARE"
2. If Encr = False Then dest = dest & "\PUBBLICARE"
3. spostafile1 dest
Successivamente, verrà eseguito lo spostamento di tutti i file compresi nel package e
il RecordSet verrà reso persistente attraverso la scrittura nella tabella ticket. Lo stato
iniziale è open.
137
Capitolo 4
4.4.7 Il gestore della coda
Si è detto che, alla scadenza del timer impostato dall’utente, viene eseguito
l’algoritmo generale descritto in precedenza. La seconda parte dell’algoritmo, è
rappresentata in Figura 75.
Apertura tabella ticke
Leggi stato
verifica
che non sia
in progress
[precedenza not OK]
[ok]
[inProgress]
verifica che siano
soddisfatti i vincoli di
precedenza su ugual
asset ID
[ok]
esegue azione
verifica numero max
di processi
concorrenti
[max thread = true]
Aggiorna Stato
next ticket
[eof = false]
[eof=true]
Figura 75 - Gestore della coda
138
Capitolo 4
L’algoritmo, che rappresenta il blocco “handle ticket” dell’algoritmo generale, si
basa sull’analisi degli stati vista in fase di progetto e che qui viene affrontata con
maggiore dettaglio nell’ottica, appunto, dell’implementazione. Dapprima si procede
con l’apertura della tabella dei ticket. Per convenienza, la tabella è ordinata per data
di arrivo. In tal modo viene garantito il fatto che gli asset saranno processati secondo
l’ordine di arrivo.
Viene processato il primo record della tabella e ne viene analizzato il suo stato.
Potrebbe trattarsi di un ticket che è stato già estratto ed è in encrypting, oppure si
trova in trasferimento movie content verso gli edge server. In tal caso, viene scartato.
Inoltre, se nella tabella ticket esistono altri ticket con lo stesso assetID, allora viene
verificato che non esistono altri ticket che abbiano la precedenza rispetto a questo.
Per tale ragione, è necessario verificare che quello in esame sia il più anziano,
altrimenti deve essere lasciato in stato di attesa. Se questi due controlli vengono
superati, allora il ticket deve essere trattato. Quanto esposto è stato mostrato in
precedenza attraverso i diagrammi di stato e delle attività.
Si analizza ora uno stralcio del codice.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Private Function gestoreCoda()
Dim rs2 As ADODB.Recordset
Set rs2 = New ADODB.Recordset
rs1.MoveFirst
While Not rs1.EOF
stato = rs1("idStato")
Select Case stato
Case Is = 1 ' open
If rs1("movieFileUpdate") = True And rs1("Encrypting")
= True Then
10.
rs1("idstato") = 7 ' waitForEncrypting
11.
ElseIf rs1("movieFileUpdate") = True And
rs1("Encrypting") = False Then
12.
rs1("idStato") = 8 ' waitForTransfer
13.
ElseIf rs1("movieFileUpdate") = False Then
14.
rs1("idStato") = 9 ' wait for publication
15.
End if
16.
Case Is = 2 ' close
17.
Case Is = 3, 4, 5, 6, 7 ' stati manuali e di attesa
18.
' noop
19.
Case Is = 8 ' wait for transfer
20.
If concurrentTransfers < maxTransferAllowed Then
21.
rs1("idStato") = 4 ' in transfer
22.
sendToSGs rs1("assetID"), rs1("serviceGroupID")
23.
End If
24.
Case Is = 9 ' wait for publication
139
Capitolo 4
25.
rs2.open "Select DataArrivo from ticket where
assetid=" & rs1("AssetID") & " order By ASC DataArrivo ",
conn, adOpenDynamic, adLockReadOnly
26.
If rs2("dataArrivo") >= rs1("dataArrivo") Then
If rs1("cover1FileUpdate") = True Then
27.
28.
coverTransfer rs1("cover1Content")
29.
End If
30.
If rs1("cover2FileUpdate") = True Then
31.
coverransfer rs1("cover2Content")
End If
32.
33.
If rs1("previewFileUpdate") = True Then
34.
previewTransfer rs1("previewContent")
35.
End If
36.
If executeSQL = True Then rs1("idStato") = 2
37.
End IF
38.
End Select
39.
rs1.Update
40.
moveFile rs1(“assetid”), stato, idstato
41.
rs1.MoveNext
42.
Wend
43.
End Function
Viene aperta la tabella ticket tramite il RecordSet rs1 e comincia la sua scansione
(riga 5). Si raccoglie lo stato del ticket e lo si analizza con un costrutto Select Case
(riga 7). Se lo stato è open ci sono tre possibilità per lo stato successivo. Vengono
analizzate e settate, in accordo con il diagramma degli stati.
Un asset può essere spedito verso i service group solo se il numero massimo di
trasferimenti in parallelo non è stato superato. Tale valore è memorizzato nelle
impostazioni del programma ed è un parametro ottenuto attraverso un’analisi delle
prestazioni generali della rete, condotta direttamente dal committente. Nel caso in cui
questo
numero
dovesse
essere
raggiunto,
l’asset
viene
mantenuto
in
waitingForTransfer e non potrà cambiare stato (righe 20-23). Questo significa che
il gestore della coda potrà avere la possibilità di processare fino a
maxTransfersAllowed sessioni di trasferimento contemporanee.
Dal momento che il Visual Basic ha un modello “single thread”, per lanciare più
sessioni parallele di file transfer, si è fatto ricorso ad una routine che viene invocata
attraverso la shell. Questa ha la possibilità di accedere alla tabella dei ticket per
variarne lo stato e quindi per segnalare il proprio successo o insuccesso. Ogni
attivazione di questo modulo, comporta la variazione dello stato ticket, che viene
posto al valore inTransfer, e la scrittura di un record in una tabella: in ogni riga
140
Capitolo 4
viene riportato il nome del file, un timestamp dell’inizio del trasferimento, l’assetId
del package ed il service group di destinazione. Subito dopo viene invocata la routine
che si occupa dell’effettivo trasferimento file, via FTP, verso ogni edge server che
appartiene al service group. Il numero di righe rappresenta il numero di trasferimenti
in corso verso i service group e vale concurrentTransfers. Al termine del
trasferimento verso tutti gli edge che fanno parte dello stesso service group, la
routine rimuove la riga che aveva creato e, di conseguenza, concurrentTransfers
viene decrementato. La routine che si occupa dei trasferimenti scrive nel log tutte le
operazione ed è in grado di intercettare errori.
Ricapitolando, prima di lanciare la scrittura verso il database, si verifica la relazione
di precedenza con eventuali altri assetId uguali in coda (righe 25 e 26), poi si valuta
la necessità di inviare preview / cover content eventuali (righe 27-35) ed infine si
costruisce lo statement SQL che verrà lanciato verso il database. Se tutte le
operazioni avranno esito positivo, lo stato verrà aggiornato. Il trasferimento del
trailer (riga 34) si appoggia alla procedura di invio ai service group, ma in maniera
sequenziale. Le ridotte dimensioni di questo tipo di file comportano un tempo di
trasferimento inferiore al minuto e, pertanto, non c’è stata la necessità di dover
attuare ottimizzazioni. Il trasferimento delle locandine (righe 28 e 31) è demandato
ad un’apposita routine e dura un paio di secondi.
Dopo aver processato il ticket, se le circostanze lo richiedono, l’intero asset package
viene spostato dalla procedura moveAsset che richiede assetId, lo stato precedente
e quello attuale (riga 40). Ad esempio, se il ticket proviene dallo stato
waitForPublication e raggiunge lo stato closed, tutti i suoi file vengono spostati in
\inbox\pubblicati.
L’algoritmo riprenderà in maniera automatica alla scadenza del timer. A proposito di
questo intervallo di tempo, questo è stato implementato con il controllo Timer di
Visual Basic 6.0 che consente di impostare un ritardo e, all’evento Timer, viene
lanciato il gestore della coda, come mostra il seguente codice:
141
1.
2.
3.
4.
5.
6.
7.
8.
9.
Capitolo 4
Private Sub Timer1_Timer()
On Error GoTo ErrGestore
Timer1.Enabled = False
gestoreCoda
Timer1.Enabled = True
Exit Sub
ErrGestore:
scrivilog err.Description
End Sub
Si nota che (riga 3) il timer viene disabilitato e poi riattivato alla fine della gestione
della routine. Se infatti dovessero presentarsi numerosi asset, questi potrebbero
richiedere un tempo maggiore dell’intervallo stabilito. Ciò farebbe scattare il timer
mentre altre operazioni sono in corso. Questo potrebbe essere un evento con effetti
indesiderati non prevedibili. Per tale ragione si è scelta questa soluzione.
4.4.8 La pubblicazione nel database OMP
La function executeSQL in ultimo, è stata sviluppata per la costruzione dello
statement SQL e della sua esecuzione. I possibili comandi SQL possono essere:

INSERT into OVA_VOD_CONTENT (…) Values (…);

UPDATE OVA_VOD_CONTENT

DELETE FROM OVA_VOD_CONTENT where …;
set <nome_campo> = <valore_campo>, …;
I campi ed i loro valori vengono ricavati del file XML. Ancora una volta è richiesta
la classe Microsoft che consente il parsing di tali file. Analogamente a quanto visto
per la prima operazione di parsing, che accadeva alla prima apertura del package,
anche qui il file XML viene caricato con il metodo Load.
Successivamente, però, l’intero albero viene visitato con un algoritmo ricorsivo. Tale
scelta si è rivelata valida in quanto si è totalmente svincolati dalle regole di
composizione dei file XML. Se infatti la specifica per i VOD è ben definita e
conforme al formato CableLabs, le EPG sono suscettibili di future variazioni che
dipendono da accordi con eventuali nuovi content provider. Altro aspetto positivo è
che le stesse routine sono in grado di leggere qualsiasi file XML e riportarlo in un
recordset. L’algoritmo ricorsivo è mostrato qui di seguito
142
Capitolo 4
1.Public Sub esploranodo(ByVal nodo As MSXML2.IXMLDOMNode,
ByRef progressivo As Integer, ByRef arrayvalori, ByRef
arraynomi)
2. progressivo = progressivo + 1
3. Nome = UCase(nodo.nodeName)
4. Valo = nodo.nodeTypedValue
5. arraynomi(progressivo) = Nome
6. arrayvalori(progressivo) = Valo
7. For a = 0 To nodo.Attributes.length - 1
8.
progressivo = progressivo + 1
9.
Nome = nodo.Attributes(a).nodeName
10.
Valo = nodo.Attributes(a).nodeValue
1
prefisso
=
nodo.parentNode.firstChild.Attributes.
getNamedItem(“Asset_Class").nodeValue
12.
arraynomi(progressivo) = prefisso & "_" & Nome
13.
arrayvalori(progressivo) = Valo
14. Next a
15. If nodo.hasChildNodes Then
16.
For i = 0 To nodo.childNodes.length - 1
17.
esploranodo nodo.childNodes(i), progressivo,
arrayvalori, arraynomi
18.
Next i
19. End If
20.End Sub
Durante l’ispezione, viene generata una coppia di array, arraynomi ed
arrayvalori, in cui allo stesso indice sono inseriti rispettivamente il nome attributo
ed il proprio valore, letti dal file XML. Gli array sono parametri condivisi dalle
istanze che si generano nella ricorsione. Per questo sono passati per riferimento. Per
ogni nodo, vengono raccolte queste coppie (righe 3-6) e tutti gli eventuali attributi
(righe 7-14). Se un nodo ha nodi figli, si attiva una chiamata ricorsiva (riga 17). I
dati così raccolti vengono immagazzinati in un recorset per ottenere una gestione che
abbia il nome attributo come puntatore. Tale recorset appare come una tabella i cui
nomi dei campi e valori, sono rispettivamente i valori assunti dagli array di uguale
indice, come mostra il seguente estratto dal codice:
1.For i = 1 To UBound(arrn) Step 1
2. campoesiste = False
3. If arrn(i) <> "" Then
4.
For nc = 0 To (rsAsset.fields.Count - 1) Step 1
5.
If UCase(arrn(i))= UCase(rsAsset.fields(nc).Name) Then
6.
campoesiste = True
7.
Exit For
8.
End If
9.
Next nc
10.
If Not campoesiste Then rsAsset.fields.Append arrn(i),
adLongVarChar, 254
11. End If
12.Next i
143
Capitolo 4
La necessità di verificare l’esistenza di un campo prima della sua creazione (righe 49) è dovuta al fatto che si possono parsare file XML di struttura diversa ma che
hanno uguali nomi di attributo. In tal caso, il recorset sarà costruito dall’unione dei
nomi di nodi e attributi letti dalle varie tipologie di XML.
Alcune di queste informazioni sono sottoposte ad un controllo di validità. Ad
esempio, secondo la specifica CableLabs, alcuni dati devono essere necessariamente
presenti e devono necessariamente assumere un certo insieme di valori. Se questi
controlli vanno a buon fine, allora può essere creato il comando SQL che dovrà
essere eseguito.
La scelta del tipo di comando è indicata dal campo LoadMode, sempre presente in
ogni file XML, che può assumere rispettivamente i valori “insert”, “update”,
“unpublish”, come era già stato detto in fase di specifica. Viene quindi aperta una
connessione al database di OMP e lo statement eseguito.
Lo stralcio di codice mostra quanto esposto. Si noti la differenza di driver utilizzato
nella stringa di connessione (riga 3) in quanto cambia la fonte dati che adesso è
Oracle.
1. Dim cmdUpdate As ADODB.Command
2. Set cmdUpdate = New ADODB.Command
3. cmdString = "DRIVER={ORACLE IN ORAHOME92};UID=" & strUser &
";PWD="
&
strPass
&
";DBQ="
&
strDBQ
&
";DBA=W;APA=T;FEN=T;QTO=T;FRC=10;FDL=10;LOB=T;RST=T;FRL=F;MTS=
F;CSR=F;PFC=10;TLO=O;"
4. cmdUpdate.CommandText = cmdString
5. cmdUpdate.ActiveConnection = connDB1
6. DoEvents
7. connDB1.BeginTrans
8. cmdUpdate.Execute
9. connDB1.CommitTrans
Si noti che il comando viene eseguito tramite un oggetto Command ed il metodo
Execute (riga 7). Inoltre, viene aperta una transazione che verrà “committata” se il
metodo Execute non fallisce. Se fallisce, infatti, l’errore verrà intercettato
dall’apposita routine di gestione errori e la function restituirà il valore False che
impedirà la chiusura del ticket.
In tutte le routine è stata prevista una gestione degli errori e la conseguente scrittura
nel log file. Si rimanda al codice ed alla documentazione interna allegata.
144
Capitolo 4
4.5 Il Deployment
L’insediamento dell’applicativo si è rivelato è estremamente semplice. Infatti,
Microsoft mette a disposizione del linguaggio VB un
software, Visual Studio
Installer [28], che consente di creare pacchetti di installazione compatti. Una volta
creato, il pacchetto di installazione consta di un unico file eseguibile con estensione
MSI. Comunque, allo scopo di consentire l’apertura della connessione verso il
database OMP, è necessario installare anche il software Oracle 9i Client [27].
Il diagramma di deployment, in Figura 76, mostra i nodi coinvolti. Il nodo
XMLDAM rappresenta la macchina, con sistema operativo Microsoft Windows 2000
Server, sul quale è stato installato l’applicativo. Gli altri nodi completano lo scenario
e rappresentano il database server Oracle 9i [27] e il disco condiviso per lo scambio
degli asset. È visibile anche il nodo XTV Encryptor.
Inbox
XMLDAM
Oracle Server
<<library>>
Oracle Client
XTV-Encryptor
<<application>
XMLDAM
Figura 76 - Diagramma di deployment
4.6 Il Testing
Le attività di testing si sono mosse su due livelli differenti. La prima aveva
l’obiettivo di assicurare la corretta esecuzione a livello unit ed integrazione tra le
varie procedure. Non ha coinvolto il committente. La seconda è stata interamente
145
Capitolo 4
definita con il committente che ha proposto un proprio piano di testing. Questo ha
avuto come scopo la simulazione di inserimento di un certo numero di asset package.
Gli asset package sono stati scelti secondo criteri che potevano assicurare un criterio
di copertura dei dati in input. Sono state stabilite classi di equivalenza per i dati di
input e quindi identificati casi di test [23]. Fermi restando i dati di input, si è notato
che la sequenza con la quale questi venivano forniti costituiva di per sé un nuovo
caso di test. Per questo sono state individuate anche classi di equivalenza orientate
alla dinamica con cui il sistema veniva chiamato a trattare i vari job.
I possibili cammini del software di ingestion sono quindi dipendenti dalle
combinazioni dei metadati di controllo e dalla sequenza con cui sono inviati.
L’ambiente di test replica quello di produzione, tranne che per il fatto che il sistema
si interfaccia verso un diverso schema di database. Ma questo, ovviamente, non lede
le generalità del test stesso. Sono stati previsti test di tutti i casi d’uso. Per ogni test
case definito è stata compilata una scheda di cui si riporta un esempio del template:
Test Case Template
Test Case Title
EPG update
Customer
Requirement
Test Date
Pubblicazione metadati EPG
Owner
Mario Rossi – Telecom
Assignee
Francesco Sferlazza – Alcatel Italia
Input
Caso con loadmode =’update’
Steps
12/01/2006
1. l’asset package viene fornito al sistema nella directory
\inbox
2. XMLDAM User avvia lo start del processo
Expected Results
L’asset package deve essere spostato nella directory
\inbox\pubblicare
A video deve potersi seguire l’evoluzione del ticket
Nei log devono essere riportate le tracce percorse dal ticket in
termini di cambiamento di stato.
Le EPG si popolano correttamente nel database OMP
Results
Non si sono verificati problemi. Gli update delle schede sono stati
eseguiti correttamente. Test “fallito”. Ok in produzione.
Suggestion
Nessuno
146
Capitolo 4
Oltre ai test opportunamente ritagliati per coprire i possibili casi di input relativi ai
metadati di controllo, si è cercato di produrre un numero elevato di asset package da
sottoporre al software di ingestion. Il committente ha preparato circa 2000 asset
package in una settimana, con lo scopo di effettuare uno stress test che potesse dare
indicazioni sulle performance onde regolare, empiricamente, eventuali parametri del
sistema globale (es. connessioni di rete, velocità di accesso disco condiviso etc.).
Alcuni aspetti sono tutt’ora oggetto di studio.
147
Conclusoni
Capitolo 5
Capitolo 5
Conclusoni
Il software sviluppato incontra le esigenze del committente. È stato installato in
ambiente di produzione e, dai log, sono stati letti messaggi di errore che erano
prevalentemente dovuti ad errori nei metadati. Questo ha suggerito di introdurre
nuovi controlli di validità degli stessi ma, il modo in cui il software stesso è stato
progettato, ha agevolato la gestione del cambiamento. Questi aspetti ne hanno
migliorato la robustezza ed affidabilità rendendo, al committente, una percezione di
robustezza del sistema sviluppato. Tutto sommato, il sistema stesso è suscettibile di
numerosi cambiamenti che potrebbero avvenire nei sistemi esterni.
Il primo riguarda la possibilità di avere un nuovo sistema XTV-Encryptor che
esponga un’interfaccia SOAP (Simple Object Access Protocol). In tal modo, il
sistema potrebbe essere in grado di comunicare la richiesta di encrypting ed
aggiornare autonomamente lo stato dei ticket. L’effetto di una simile possibilità
sarebbe quello di evitare che il sistema stesso possa richiedere interazione con
l’utilizzatore. E questo implica miglioramenti e semplificazioni all’interfaccia
grafica che verrebbe sparire numerosi controlli. Il sistema diventerebbe molto simile
ad un processore di lavori batch . Questi aspetti sono stati annunciati dal committente
durante le interviste raccolte in fase di raccolta dei requisiti e sono stati debitamente
tenuti in conto nella fase di progettazione, in cui si sono mantenuti bassi livelli di
accoppiamento tra i moduli del sistema.
Un altro aspetto che potrebbe variare è la modalità di trasferimento dei contenuti
verso gli edge video server. La modalità attuale è basata su protocollo FTP. Ma è
148
Conclusoni
Capitolo 5
anche vero che, dato che il servizio è in sperimentazione, ci sono solo due
ServiceGroup attivi. Nei prossimi due mesi sono previsti 21 nuovi siti che dovranno
diventare 50 entro la fine del 2006. Questi numeri hanno spinto il committente
all’adeguamento della rete, con l’introduzione di router multicast. L’idea è infatti
quella di adottare il protocollo Multicast FTP che consentirebbe l’eliminazione del
collo di bottiglia dato dal massimo numero di trasferimenti attualmente possibili.
Naturalmente, l’impatto di eventuali cambiamenti dovrà essere valutato e
formalmente inserito nel ciclo di vita del software.
Una ultima necessità, al momento, è quella della gestione della ridondanza,
attualmente non prevista. Dal momento che tutti i sistemi sono “h24”, ovvero sempre
attivi, una caduta del software di ingestion, o dell’hardware che lo ospita,
provocherebbero il blocco delle attività di pubblicazione. Anche gli interventi di
manutenzione causerebbero discontinuità del servizio. L’idea è di effettuare il
deployment in produzione di una istanza “gemella”, su hardware separato, ed
aggiungere un meccanismo di tipo active – stand-by
disponibilità del sistema stesso.
che assicuri elevata
Altri aspetti del software potrebbero essere
migliorati ma, allo stato attuale, sono state soddisfatte le aspettative del cliente.
L’esperienza accumulata durante questo lavoro è stata notevole. La crescita
professionale, ma anche sul piano umano, maturata con l’interazione con diverse
persone e ruoli in Italia, UK e Belgio è stata considerevole. E questi sono forse gli
aspetti che rimarranno più scolpiti e costituiranno un patrimonio personale di cui
ogni professionista avrà bisogno nella sua carriera.
149
Bibliografia
Bibliografia
[1] Fenner, W., IETF RFC 2236 Internet Group Management Protocol, Version
2, November 1997.
[2] M. Banikazemi, IP Multicasting: Concepts, Algorithms, and Protocols URL
http://www.cis.ohio-state.edu/~jain/cis788-97/ip_multicast/index.htm
[3] Giorgio Ventre e Simon Pietro Romano – Il Multicasting in internet GV/RC/TCP-IP - Dipartimento di Informatica e Sistemistica, Università di
Napoli Federico II
[4] Fabrizio Farina – IVoA IPTV platform - Università degli Studi di Salerno,
2005
[5] CableLabs® Asset Distribution Interface Specification Version 1.1, MD-SPADI1.1-I03-040107, January 7, 2004
[6] CableLabs® Video-on-Demand Content Encoding Profiles Specification,
MD-SP-VOD-CEP-I01-040107, January 7, 2004
[7] Alcatel 5950 Open Media Platform, Release 2.1 – Installation and
configuration guide, October, 2004
[8] W3C Extensible Markup Language (XML) 1.0 (Second Edition) URL
http://www.w3c.org
[9] CableLabs® Video-On-Demand Content Specification Version 1.1 - MD-SPVOD-CONTENT1.1-I03-040107
[10] Algorithm- vs Key-based CA Systems, NDS VideoGuard Security, Doc No:
TSS-T524B, Release: B, Date: 13 March 2003
[11] Synamedia Training Sign-on, authentication & entitlement management,
Geoff Bowles, 2004
[12]
Synamedia Training Video on Demand, Geoff Bowles, 2004
[13]
Synamedia Training Broadcast TV, Geoff Bowles, 2004
[14] Synamedia System Architectural & Functional Design: Pre-Encryption
of VOD Content – Part 1, Part 2, Part 3, Colin Harvey, 17/02/2004
150
Bibliografia
[15] F5 Network – Big IP 2400 Application Traffic Management URL
http://www.f5.com/products/bigip/ltm/2400.html
[16] Check Point SecurePlatform NG with Application Intelligence (R55)
URL http://www.checkpoint.com/support/technical/documents/docs_r55.html
[17] Tandberg Television, E5710 MPEG-2 Encoder - URL
http://www.tandbergtv.com/public/site/Primary/productdocs57/E5710_v11.pdf
[18] Schulzrinne, et. al.IETF RFC 2326 Real Time Streaming Protocol, April
1998
[19] Andrey Kisel, Telecom Italia Redirector, Functional Specification
Revision AX02, Jan 2006
[20] Leszek A-Maciaszek - Sviluppo di sistemi informativi con UML – Addison
Wesley, 2002
[21]
Simon Bennet, John Skelton, Len Lunn – UML – McGraw-Hill, 2002
[22] J. Rumbaugh, I. Jacobson, G. Booch - The Unified Modeling Language
User Guide - Addison Wesley Longman, Computer & Engineering Publishing
Group
[23] R. S. Pressman - Principi di Ingegneria del Software - quarta edizione - Mc
Graw Hill Libri Italia
[24]
Atzeni, Ceri, Paraboschi, Torlone – Basi di dati – McGraw Hill, 1999
[25]
Microsoft® – Visual Basic 6 –URL http://msdn.microsoft.com/vbasic/
[26] Microsoft® - Data Access Components (MDAC) ADO URL
http://msdn.microsoft.com/data/mdac/
[27] Oracle® Database 9i
http://www.oracle.com/technology/software/products/oracle9i/index.html
[28] Microsoft® Visual Studio Installer
http://msdn.microsoft.com/library/en-us/msi/setup/about_windows_installer.asp
[29] Matt Curland - Visual Basic 6 Techiche di programmazione avanzata,
Addison Wesley
[30]
C. Ghezzi, ed Altri - Ingegneria del Software - Mondadori Informatica
151
Bibliografia
[31] R.Droms, IETF RFC 2131 Dynamic Host Configuration Protocol, March
1997
[32] R.Droms, IETF RFC 2132 DHCP Options and BOOTP Vendors
Extensions, March 1997
[33] S.Deering, IETF RFC 1112 Host Extensions for IP Multicasting, August
1989
[34] S.Deering et al. IETF RFC 3376 Internet Group Management Protocol,
Version 3, October 2002
[35] J. Franks et al. IETF RFC 2617 HTTP Authentication: Basic and Digest
Access Authentication, June 1999
152
Elenco di sigle ed acronimi
ADI
Asset Distribution Interface
ADO
ActiveX Data Objects
ADSL
Asymmetric Digital Subscriber Line
AG
Access Gateway
AMS
Asset Management System
ASI
Asynchronous Serial Interface
ATM
Asynchronous Transfer Mode
BTV
Broadcast TeleVision
CA
Conditional Access
CL
CabeLabs
CPE
Customer Permises Equipment
CW
Control Word
DHCP
Dynamic Host Configuration Protocol
DNS
Domain Name System
DSLAM
Digital Subscriber Line Access Multiplexer
DVB
Digital Video Broadcasting
DWDM
Dense Wavelength Division Multiplexing
ECM
Entitlement Control Message
ECMG
Entitlement Control Message Generator
EMM
Entitlement Management Message
153
ER
Entity Relationship
FTP
File Transfer Protocol
FW
Firewall
GIF
Graphics Interchange Format
GUI
Graphical User Interface
HTTP
Hyper Text Transfer Protocol
IEEE
Institute of Electrical and Electronic Engineers
IETF
Internet Engineering Task Force
IGMP
Internet Group Management Protocol
IP
Internet Protocol
JPEG
Joint Photographic Experts Group
LAN
Local Area Network
MPEG
Moving Picture Experts Group
MPTS
Multiple Programme Transport Stream
NVOD
Near Video on Demand
OMP
Open Media Platform
OPB
Optical Packet Backbone
OSPF
Open Shortest Path First
OVS
Open Video Server
PECM
Personal Entitlement Control Message
POTS
Plain Old Telephone Service
PPV
Pay Per View
RFC
Request For Comment
154
RTSP
Real Time Streaming Protocol
SC
Service Control
SDI
Serial Digital Interface
SECM
Signed Entitlement Control Message
SOAP
Simple Object Access Protocol
SPTS
Single Programme Transport Streams
SSH
Secure Shell ed anche Secure Segnature Host (in encrypting)
SSP
Stream Shaker
STB
Set Top Box
STS
Single Transport Stream
TCP
Transmission Control Protocol
TS
Transport Stream
TTL
Time To Live
UI
User Interface
UML
Unified Modeling Language
URL
Uniform Resource Locator
VB
Visual Basic
VCI
Virtual Channel Identifier
VLAN
Virtual Local Area Network
VOD
Video On Demand
VoIP
Voice over Internet Protocol
VPI
Virtual Path Identifier
XML
Extensible Markup Language
155