Sviluppo di una piattaforma CMS Open-Source per la gestione del Podcasting

  2 
terminali multifunzione hanno incontrato una vasta diffusione sul mercato: navigatori 
satellitari, console portatili e telefonini, in grado di connettersi a Internet e di 
riprodurre musica e filmati, ne sono un esempio e costituiscono il riflesso, nella 
nostra quotidianità, della codifica in bit dell’informazione e dell’abilità degli 
sviluppatori, che hanno creato software di comunicazione in grado di sfruttare al 
meglio la banda disponibile. 
L’integrazione dei servizi, a sua volta, ha fatto scaturire una forte istanza per 
l’integrazione delle reti stesse e non è lontano il momento in cui ogni  PC collegato a 
Internet sarà facilmente raggiungibile anche da un telefono tradizionale, attraverso il 
protocollo ENUM. 
La convergenza nell’ambito delle telecomunicazioni è perciò totale. 
                        
Dal punto di vista dei contenuti offerti, però, la vera rivoluzione è iniziata 
contemporaneamente alla diffusione della banda larga ed alle offerte “flat” proposte 
dagli I.S.P. (e sarà completa nel nostro Paese se e quando sarà superato il fenomeno 
del Digital Divide, che vede una vasta area del territorio nazionale ancora non coperta 
dai moderni servizi di comunicazione): grazie alla quantità di banda messa a 
disposizione, gli stessi portali di informazione hanno potuto diversificare l’offerta dei 
contenuti, fornendo, oltre alle notizie, documenti in formato diverso (Word, Excel, 
PDF o di altro tipo), liberamente scaricabili e fruibili dall’utente nel momento che 
preferisce. Di contro, anche gli utenti della rete hanno potuto contribuire al traffico e 
allo scambio di informazioni, rendendo disponibili contenuti autoprodotti. C’è stato 
anche chi ha reso disponibili on-line file audio, contenenti le registrazioni di 
  3 
conferenze e seminari o di semplici monologhi creati “ad hoc” e destinati agli utenti 
interessati ai temi trattati dalla particolare community virtuale. 
E’ nato così il fenomeno del Podcasting, che ha incontrato una rapidissima diffusione: 
anche il portale FEDERICA, dell’Università di Napoli FEDERICO II, ad esempio, 
fornisce le registrazioni di conferenze e lezioni, oltre che slide e informazioni sui 
corsi, mettendo a disposizione degli studenti tutti i contenuti in formato diverso.  
 
Il termine “Podcast” è stato coniato dal giornalista Ben Hammersley, del quotidiano 
britannico “The Guardian”, che in un suo articolo del mese di Febbraio 2004 
(http://arts.guardian.co.uk/features/story/0,,1145758,00.html, intitolato “Audible 
Revolution”) cercava un termine adeguato per definire l’attività di chi pubblica in rete 
contenuti multimediali (audio e/o video) autoprodotti.  Il termine sarebbe derivato 
dall’unione di “iPod” (il celebre lettore multimediale prodotto da Apple) e di 
“Broadcast”, anche se alcuni opinionisti (forse intolleranti alla Mela) gli attribuiscono 
il significato di “Personal Option Digital casting”. 
In pratica, oggi il termine Podcast è usato per definire generalmente un file audio, 
video o multimediale, a contenuto tematico, che viene messo in rete dall’autore per 
essere successivamente scaricato e riprodotto da qualunque altro utente del Web. 
 
In questo scenario, sulla base dell’esperienza di tirocinio in piattaforme Open-Source, 
effettuata presso l’ITS di Napoli, ho voluto mettere a punto una soluzione che possa 
consentire agevolmente di pubblicare e  gestire  contenuti multimediali autoprodotti.  
Questa tesi costituisce il bilancio dell’attività svolta ed è articolata come segue:  
- descrizione formale dei workflow dal punto di vista generico; 
- tassonomia delle tipologie di workflow relative all’informazione e descrizione delle 
tecnologie oggi a disposizione per la pubblicazione e la gestione dei contenuti (CMS, 
ECM, WCM, ecc.); 
- scelta di un CMS, adatto all’ esigenza di multicanalità, oggi presentata dagli utenti 
delle moderne tecnologie di telecomunicazioni; 
- descrizione dell’ architettura del CMS utilizzato; 
estensione e personalizzazione del CMS, attraverso l’integrazione di un programma 
per la transcodifica multimediale, al fine di ottenere una piattaforma che permetta 
un’agile gestione dei contenuti multimediali e l’ottimizzazione degli stessi per i 
diversi canali di distribuzione. 
  4 
La piattaforma CMS scelta (Alfresco) è stata, perciò, integrata con l’applicativo 
FFMPEG, un tool opensource, in grado di operare la transcodifica tra molti dei 
diversi formati oggi a disposizione per la compressione degli stream multimediali, per 
realizzare l’architettura di applicazione mostrata in figura. 
 
L’applicazione implementata sfrutta il supporto multiprotocollo di una particolare 
configurazione del CMS, affinché il web-server, che la ospita, possa interfacciarsi 
con diversi tipi di client, utilizzando FFMPEG per fornire, a questi ultimi, una 
versione del contenuto richiesto, ottimizzata per il particolare canale di distribuzione 
e per il particolare dispositivo di riproduzione. Il funzionamento, quindi, è basato su 
un flusso di lavoro automatico, gestito attraverso il CMS con delle “regole”, che 
definiscono le “azioni” da effettuare sui contenuti caricati nel file-system del server. 
L’integrazione in Alfresco del modulo FFMPEG è stata ottenuta mediante un wrapper 
Java che, opportunamente configurato attraverso la stesura di codice XML, consente  
di incapsulare in stringhe i comandi per la transcodifica e di passarli automaticamente 
a FFMPEG. La transcodifica, perciò, avviene in modo quasi del tutto trasparente sia 
per l’utente finale dei podcast, sia per gli utenti che caricano sul server i propri 
contenuti multimediali autoprodotti. Il codice xml per la customizzazione, inoltre, è 
stato testato con successo in ambiente Mac OS X e Windows ed è  stato scritto 
prevedendo la possibilità di configurazione del CMS anche in ambiente Linux. 
  5 
Capitolo 1 
La gestione dei contenuti 
 
1.1 Il workflow 
 
Tutti gli oggetti che ci circondano, nella vita pratica, sono il prodotto di una 
sequenza di operazioni svolte sull’oggetto stesso: il complesso sistema 
automatizzato di una moderna catena di montaggio ha assemblato l’automobile 
che guidiamo tutti i giorni; il braccialetto che portiamo al polso è il frutto del 
paziente lavoro di un artigiano; un gioco per PC viene ideato, scritto, 
programmato e testato. Tutto quello che abbiamo intorno, quindi, è l’output di un 
ciclo di produzione, che svolge una sequenza  più o meno elaborata di “azioni”, 
sulla materia prima di cui l’oggetto è costituito: questa catena  di operazioni è 
detta workflow (flusso di lavoro).    
Le operazioni che compongono un workflow possono essere ripetitive              
(o addirittura identiche per oggetti dello stesso tipo) ed è quindi conveniente 
programmarne il flusso, in modo che esso possa essere svolto automaticamente 
dalle macchine, velocizzando il lavoro ed incrementando efficienza e produttività. 
 
  
Fig. 1.1 – Una scena tratta dal film “Tempi Moderni”, di C. Chaplin 
  6 
 
 Nell’ambito del software, l’automazione più semplice di un workflow consiste in 
uno script che esegua automaticamente la sequenza di passi prestabilita sui dati in 
ingresso, producendo uno o più file di uscita; è così che è realizzato l’Automator 
di Apple, ad esempio, presente nei sistemi operativi Mac OS X 10.4.x: l’utente, in 
base alle sue esigenze, definisce il workflow tramite un’interfaccia grafica, che gli 
consente di creare lo script che sta alla base del funzionamento automatico, 
selezionando delle azioni e trascinandole nel diagramma di flusso. 
     
Spesso, tuttavia, per talune attività, il workflow non può essere azionato da una 
sola persona; le ragioni possono essere diverse: si richiedono competenze 
specifiche per alcuni passi del flusso, autorizzazioni… oppure è necessario poter 
lavorare con dei collaboratori dislocati in diverse postazioni di lavoro. Si pensi 
alla prima pagina di un quotidiano e al flusso di lavoro che la realizza:  gli articoli 
vengono scritti dagli autori, approvati dal responsabile della redazione, controllati 
dai correttori di bozze, intestati dai titolisti, incolonnati dagli impaginatori… 
subiscono, insomma, un processo abbastanza elaborato, nel quale intervengono 
diverse persone con competenze specifiche. In questi casi, si parla di flussi 
strutturati  e workflow distribuito.     
Quanto detto vale, ovviamente, anche per i contenuti multimediali, che passano 
attraverso un workflow prima di divenire fruibili per l’utente finale cui sono 
destinati. Si pensi al popolarissimo Youtube: ogni filmato inviato al server dagli 
utenti registrati - che sono sparsi per il globo - viene prima revisionato ed 
approvato per la pubblicazione, poi, tramite una ricodifica, ottimizzato per il  web 
e, infine, indicizzato per essere visionato dagli utenti. 
 
Un’automazione efficiente del workflow (come pure la banda a disposizione per lo 
streaming) riveste, quindi, un ruolo cruciale per il buon funzionamento di un 
portale. Esaminiamo, perciò, più da vicino, gli aspetti legati all’automazione di un 
workflow. 
 
 
 
 
  7 
 1.2 Modello di un workflow 
 
I problemi da affrontare nella definizione di un workflow distribuito includono 
l’identificazione dei passi nel processo, degli individui chiave e degli eventi che 
ad essi vanno notificati, nonché dei dati necessari per ogni passo del processo e di 
chi deve curare ogni passo della sequenza di azioni. Un modo efficace di 
rappresentare un workflow, molto utilizzato nell’automazione industriale, può 
essere una Rete di Petri, detta anche rete P/T (Posto/Transizione), che descrive 
matematicamente un sistema distribuito discreto, mediante un grafo orientato 
bipartito (per certi versi, simile ai diagrammi degli automi a stati finiti, ma più 
potente, perché riesce a rappresentare infiniti stati con un numero finito di nodi): 
una rete P/T contiene posti, transizioni e archi diretti (vedi fig.1.2); posti e 
transizioni sono anche detti nodi; gli archi possono essere solo tra nodi di tipo 
diverso (ovvero tra posti e transizioni e non tra posti e posti o transizioni e 
transizioni). Una descrizione formale delle Reti di Petri esula dagli scopi di questo 
lavoro (per un approfondimento si rimanda a [Chiba04], a [FePi02] e a [Fe02]), 
ma è utile aggiungere qualche altro elemento su di esse, per poterne comprendere 
il funzionamento e l’evoluzione. 
 
 
Fig. 1.2 –  Esempio di una Rete P/T con legenda dei simboli 
                  
 
In una rete P/T (vedi [Netdoc1]):  
-il posto da cui un arco parte, per finire in una transizione, è detto posto di input per 
quella transizione;  
-il posto in cui un arco arriva, partendo da una transizione, è detto posto di output 
per quella transizione;  
  8 
-un posto può essere di input per una transizione e di output per un’altra;  
-in riferimento ad un nodo N, l’insieme dei nodi, dai quali parte un arco che arriva 
ad N, è detto “preset” del nodo N; l’insieme dei nodi, ai quali arriva un arco che 
parte da N, è detto “postset” del nodo N (vedi fig. 1.3); 
 
                      
                    Fig. 1.3 – Preset e postset di un nodo in una rete P/T 
 
-poiché una relazione di flusso, rappresentata da un arco, connette posti a 
transizioni  (o viceversa) e non posti a posti o transizioni a transizioni, il preset ed 
il postset di un posto sono composti da sole transizioni, mentre il preset ed il 
postset di una transizione sono costituiti soltanto da posti; 
-lo stato della rete è detto “marcatura”; 
-l’evoluzione della rete (in generale non deterministica)  dipende dagli scatti delle 
transizioni abilitate; una transizione è abilitata quando tutti i posti del suo preset 
contengono un numero di token almeno pari al peso dell’arco che li connette alla 
transizione (in fig. 1.3, la transizione T1 è abilitata, mentre la T4 non lo è); 
  9 
-lo scatto di una transizione provoca la rimozione dei token da tutti i posti del suo 
preset e l’aggiunta ad ogni nodo del suo postset di un numero di token almeno pari 
al peso degli archi che la collegano a tali posti (vedi fig. 1.4);  
-lo scatto delle transizioni provoca un “flusso” di token, ma non è bene pensare che 
i token “attraversino” le transizioni (come si sarebbe portati a fare); è più corretto 
pensare che, allo scatto di una transizione, i token tolti dai posti di preset 
scompaiano e nuovi token vengano creati nei nodi di postset (nella situazione 
d’arrivo, infatti, possono essere presenti più token che nella situazione di partenza); 
 
 
 
Fig. 1.4 – Evoluzione in seguito allo scatto di una transizione 
                    
-l’evoluzione è non-deterministica, poiché, in una certa marcatura, possono essere 
diverse le transizioni abilitate allo scatto; nel caso di una rete P/T standard, scatta 
soltanto una a caso delle possibili transizioni abilitate, ma esistono convenzioni 
diverse. 
Prendiamo ora in considerazione lo schema riportato in fig. 1.5, dove sono 
rappresentate due transizioni: le transizioni t1 e t2  si dicono in sequenza, poiché, 
con t1 abilitata e t2 non abilitata, lo scatto di t1 abilita t2; in casi come questo, il 
modello di workflow è notevolmente meno complicato che nei casi in cui sono 
previsti processi concorrenti o situazioni di conflitto, che intervengono a 
complicare notevolente l’analisi e la descrizione di modelli relativi ad effettivi 
processi di produzione. Per questo motivo, l’analisi di modelli complessi è 
effettuata con l’ausilio di un calcolatore e di software specifico.