caccio’s blog

Giovedì scorso sono stato invitato ad assistere ad una presentazione organizzata da Rai presso la sede di Viale Mazzini a Roma in cui sono state illustrate le attività di sperimentazione della Direzione Strategie Tecnologiche e del Centro Ricerche di Torino in merito alla copertura dei giochi olimpici in HDTV e DVB-H.

In occasione dei giochi è stata allestita da Rai, con la collaborazione di altri partner tecnologici, un’articolata rete di telecomunicazioni che consente di riprendere molti eventi sportivi (fra cui le cerimonie di apertura e chiusura) in “alta definizione”, trasferirli (con codifica MPEG-4/H.264) tramite fibra ottica al Centro Ricerche Rai dove il segnale video viene criptato, processato e modulato (QPSK per la componente DVB-H e 64QAM per quella HDTV) per essere poi trasmesso nell’area di Torino (su un canale UHF del digitale terrestre) e verso i siti montani che ospitano i Giochi (tramite rete satellitare). Diversi impianti per la ricezione e la proiezione del segnale HDTV sono stati allestiti in vari siti, mentre per poter accedere ai servizi di TV Mobile era necessario disporre di uno dei Nokia 7710 equipaggiati con ricevitore Nokia SU-22 facenti parte del test pack predisposto da Rai.

Alcuni di questi esemplari sono stati mostrati anche Giovedì prima e dopo l’evento (le foto sotto riportate, per mia imperizia, non gli rendono onore) ed hanno suscitato un discreto interesse fra i partecipanti.

Lo smart-phone è equipaggiato con tutto il software necessario per eseguire l’applicazine DVB-H che consente, fra l’altro, di visualizzare il palinsesto di ciascun canale (EPG) e, con l’ausilio del player Real Video integrato, di vedere il progamma televisivo correntemente trasmesso dal canale scelto in un area di circa 2 pollici di diagonale.

La sperimentazione delle nuove tecnologie presentate, che ha coinvolto fra gli altri Tim e Vodafone, proseguirà nel corso del 2006 con un progetto (per cui sono stati stanziati 40 mln di euro) che prevede la copertura delle città di Torino, Milano, Roma e Napoli con l’istituzione di un nuovo MUX-C.

Qualche giorno fa un mio amico e collega, sapendo del mio specifico interesse professionale per la gestione di metadati in progetti di Business Intelligence, mi ha segnalato l’intervento di Marianne Faro (European information manager della Nike) alla Gartner Business Intelligence Summit in cui veniva presentata la nuova strategia di Nike per la Business Inteligence. Nell’intervento vengono evidenziate, fra l’altro, le difficoltà che Nike ha incontrato nell’analisi integrata dei dati provenienti da diverse strutture aziendali distribuite geograficamente; in particolare

parte della difficoltà sta nel come parti differenti del business usavano i termini in modi diversi per i rispettivi report. Nike sta quindi creando un dizionario comune dei termini, per standardizzarli.

Il caso vuole che proprio in questi giorni stia lavorando alla creazione di un Glossario di Metadati per un sistema di supporto decisionale (DSS) di un importante istituzione pubblica il cui scopo è quello di fornire definizioni condivise per i principali termini di business in uso presso l’amministrazione. Il DSS in questione è basato su un Data Warehouse a due livelli con molteplici Data Mart costruiti iterativamente nell’arco di diversi anni. Il progetto ha coinvolto bacini d’utenza distinti con un lessico solo parizialmente comune: a volte i medesimi termini sono utilizzati con significati differenti cui possono corrispondono regole di business differenti.

La costruzione di un glossario comune pone ora il problema di condividere le definizioni fra i diversi utenti. Per supportare questo processo si sta valutando l’ipotesi di predisporre un wiki ad uso interno, inizializzato con le voci comuni e le definizioni più diffuse, lasciando ai diversi utenti il compito di dettagliarle e correggerle. Questa modalità “collaborativa” per il raffinamento dell’analisi attraverso un coinvolgimento diretto degli utneti consentirebbe (a patto di riuscire a coinvolgere realmente gli utenti nel processo di revisione e correzione) di giungere ad una definizione condivisa dei processi, dei concetti e delle relative regole di business.

Naturalmente le informazioni raccolte dovranno comunque essere formalizzate attraverso un proceso di analisi per essere “tradotte” in specifiche funzionali, tuttavia tale processo di formalizzazione risulterebbe assai agevolato dalla disponibilità di una descrizione organica e coerente della così detta “realtà di interesse”.

Relativamente al coinvolgimento diretto degli utenti nella definizione delle regole di alimentazione di un data warehouse, alcuni spunti di riflessione interessanti sono offerti dall’articolo di Mark Rittman in cui (in maniera un po’ avveniristica/semplicistica) si propone la definizione di un ambiente di front-end, destinato all’utnete finale, per la definizione delle procedure di aliemntazione.

Parlando di web services sembra scontato il riferimento a standard tecnologici come SOAP, UDDI, ecc. Queste tecnologie costituiscono infatti al momento lo stato dell’arte nell’offerta standardizzata di servizi su web (e non solo); esistono piattaforme commerciali e open che consentono di realizzare web services con queste tecnologie sfruttando i più diffusi linguaggi del momento; così come ne esistono per semplificare il loro utilizzo lato client.

Ciononostante, appresntandomi a disegnare un nuovo Web Service in stile 2.0 (vedi anche Ragionando sulle Web App 2.0), ho provato ad esaminare le soluzioni scelte da alcune delle realtà che stanno riscuotendo maggiore attenzione. Non è sempre detto che dietro ad un’idea di servizio vincente ci sia necessariamente un buon design, ma in questo caso ho trovato quanto meno istruttivo questo esame comparato.

I primi dubbi sono nati dall’analisi fatta sul caso Amazon. Amazon offre diversi servizi con una duplice interfaccia: SOAP e REST. Quest’ultimo è in realtà un protocollo incentrato più sul concetto di risorsa che su quello di servizio: in effetti il servizio offerto è quello di manipolazione delle risorse secondo quattro azioni standard (PUT, GET, POST, DELETE) assimilabili, in prima approssimazione, alle classiche CRUD. Bene, pare che l’85% degli utenti di questi servizi abbia scelto l’interfaccia di tipo REST. Il motivo fondamentale, che può essere percepito da chiunque si cimenti nello sviluppo di applicazioni che richiamino tali servizi, è nella semplicità di interazione che un interfaccia REST (o simil REST) offre.

La semplicità nell’utilizzo di un servizio può essere un elemento importante nella diffusione del servizio stesso, specie se questo è rivolto non tanto o non solo a team di ingegneri del software ma anche a volenterosi artisti del cut&paste che con poche righe di codice “rubate” qua e là riescono a integrare applicazioni vincenti. Per la cronaca Amazon offre i suoi servizi, fra l’altro, affinché vengano costruiti canali di vendita alternativi al sito Amazon che siano meno generalisti e riescano ad intercettare la domanda che a loro sfugge (naturalmente con profitto per tutte le parti).

Flickr è probabilmente una delle icone del Web 2.0. Non è il primo sito ad offrire la possibilità di pubblicare le proprie foto in rete, ma è forse il primo a concepire la condivisione di foto (e non solo) come un servizio. Flickr offre tre protocolli di interfaccia distinti per richiamare i propri servizi: SOAP, REST e XML-RPC; quest’ultimo è forse una delle prime modalità di realizzazione di un web service e si basa sulla codifica in XML di una chiamata a procedura remota. Inoltre Flickr può vantare un ampio campionario di API realizzate da terze parti per diversi ambienti di programmazione che si basano sempre sulle tre modalità di interfaccia proposte.

L’aspetto interessante è che qualunque sia il protocollo utilizzato per invocare il servizio, il risultato (una volta estratto dall’involucro SOAP o XML-RPC) è sempre una stringa di testo, e nella fattispecie testo XML. Ossia tutte le funzioni restituiscono porzioni di XML che rappresentano il risultato dell’invocazione del servizio indipendentemente dalle modalità di rappresentazione dei tipi di dato complessi previste da SOAP o XML-RPC. Anche SOAP o XML-RPC utilizzano XML per codificare i dati, oltretutto in maniera standardizzata in modo che “lato client” si possa accedere direttamente alle strutture dati restituite delegando il parsing dell’XML al middleware standard. Eppure l’utilità e la semplicità della scelta di Flickr risiede nel fatto che molte Web App si limitano ad invocare i servizi e a formattarne il risultato con CSS o XSLT, pertanto la rappresentazion del risultato in un XML lineare e strettamente calato sul dominio di business risulta essere la soluzione più pratica. Tale filosofia è ancora una volta quella intrinsecamente promossa dall’approccio REST (nella sua accezione più blanda di XML+HTTP).

Giusto per citare qualche altro caso diciamo che del.icio.us implementa unicamente un interfaccia di tipo REST (ancora in fase di sviluppo) mentre eBay, uno degli esempi più maturi, offre (similmente ad Amazon) sia SOAP che REST; Google offre unicamente un interfaccia SOAP canonica mentre molti motori di Blog (di diritto nel campionario del Web 2.0) utilizzano XML-RPC per la gestione dei trackback.

Questo post non vuole essere un invito ad abbandonare l’approccio formale e strutturato di SOAP, WSDL, BPEL, ecc. e il supporto degli ambienti per la costruzione e l’erogazione di web services che su tali standard si basano. Queste tecnologie sono probabilmente al momento le più idonee per la realizzazione di soluzioni “istituzionali” di tipo SOA. Tuttavia, nella realizzazione di servizi innovativi (2.0), rivolti direttamente ad un pubblico (di smanettoni) più ampio e il cui successo è legato anche ai contributi della community, altre soluzioni quali REST meritano di essere prese in considerazione, specie visti i casi di successo citati.

Anche il modello REST propone un approccio formalizzato all’organizzazione del servizio, ma come spesso succede in assenza di implementazioni di riferimento, ci sono diversi modi (più o meno fedeli) di applicarlo e anche i casi citati non sembrano aver interpretato a pieno l’impianto metodologico proposto da Roy Fielding.

Ragionando sui validi spunti forniti da Stid in merito al confronto (inevitabile) fra Desktop e Web Apps, la prima impressione che ho avuto è che le Web App 2.0 soffrano già di un complesso di inferiorità e di competizione con le sorelle maggiori (almeno in termini di età/maturità); i più illuminati sostenitori delle Web App 2.0 si sciherano a favore di un minimalismo funzionalista che contraddistingue le interfacce leggere, eleganti ed efficaci delle nuove applicazioni: caratteristica questa che, se risultasse vincente, non è comunque fuori dalla portata delle più tradizionali applicazioni Desktop.

Dal punto di vista tecnologico le Web App si presentano, in virtù del comune denominatore rappresentato dalle tecnologie web-oriented, come un sistema idealmente cross-platform (ossia in grado di girare in ambienti eterogenei: PC con Windows o MacOS, set-top-box interattivi, ecc.) e quindi in grado di risolvere i problemi di compatibilità fra ambienti eterogenei e ridurre i costi unitari di sviluppo (nessun porting fra piattaforme differenti, bacino di utenza più ampio, diffusione maggiore della tecnologia e conseguente incremento dell’offerta e della qualità di sviluppatori di web app 2.0 sul mercato, ecc.). Del resto Java ha già dimostrato, con i doverosi distinguo, come questa sia una promessa tecnologicamente onorabile.

Credo che il ruolo principale che le Web App stiano giocando in questo sviluppo del Web 2.0 sia soprattutto quello di fornire un’interfaccia utente di rapida realizzazione e di altrettanto rapida diffusione, senza barriere tecnologiche all’accesso, che consenta di promuovere efficacemente i servizi Web 2.0. L’innovazione infatti non è tanto da ricercare nelle tecnologie, nella portabilità, nella leggerezza, ecc. quanto piuttosto nella capacità di condividere e distribuire un servizio centralizzato che possa essere integrato in ambienti e soluzioni differenti.

E’ il servizio stesso che presenta gli elementi di innovazione caratteristici della seconda era Internet:

• gestione (di parte) delle proprie informazioni affidata all’esterno del computer personale;
• desiderio di pubblicare e condividere (parte) dei propri contenuti (immagini, pensieri, musica, ecc.) con altri membri della comunità Internet;
• capacità di interagire e integrarsi con i contenuti pubblicati da altri (commenti, feedback, ecc.);
• classificazione semantica dei contenuti (mediante metatag);
• capacità di accedere al servizio sotto forme diverse (qui entrano in gioco fra le varie forme anche le Web App 2.0);
• … (non pretendo di essere stato esaustivo)

Il Servizio 2.0 pervade l’ambiente operativo dell’utente attraverso differenti canali distributivi (feed, Web App, plug-in per applicazioni Desktop, plug-in per piattaforme di Blog, ecc.) tutti supportati da un set pubblico di API attravrso cui il servizio viene effettivamente pubblicato sulla rete.

Pertanto non credo sia prevedibile (né a breve né a medio termine) la sostituzione di una tipologia di applicazione (Desktop) con l’altra (Web App); credo piuttosto che si tratti di progettare sempre di più le applicazioni affinché siano in grado di accettare contributi funzionali da servizi esterni e contemporaneamente promuovere e adottare gli standard che facilitano tale processo di integrazione.

Il lavoro (spesso sotterraneo) di allestimento del blog continua. Oggi inauguro la sezione STUFF in cui cercherò di raccogliere e organizzare tutto il materiale da me preparato e cui faccio riferimento nei post del blog. Al momento tale sezione è divisa in quattro aree per tipologia di contenuti:

• la prima area è dedicata a documenti tecnici, pubblicazioni, presentazioni, ecc.;
• un’altra raccoglie i link più recenti a siti da me visitati e ritenuti degni di interesse;
• la terza consente di accedere ad album fotografici condivisi in rete;
• la quarta (e per ora ultima) è dedicata ai podcast (musicali e non).

In futuro aggiungerò un area per il software distribuito tramite il sito.

Questa sezione vuole essere il punto di riferimento per la pubblicazione di contenuti di natura diversa rispetto ai post di un blog e che tipicamente richiedono una modalità di fruizione differente da quella del blog stesso (anche se naturalmente possono essere referenziati da qualunque post).

Al momento l’area DOCS raccoglie alcune mie vecchie pubblicazioni e presentazioni su temi di data mining e strumenti di supporto decisionale per il marketing strategico; l’area LINKS contiene un elenco dei preferiti gestito da del.icio.us, integrato nel blog attraverso una versione hackerata del plug-in di Tom Gilbert; l’area PHOTOS contiene un solo photo album (sto ancora testando il plug-in per Flickr che sto scrivendo per la pubblicazione delle foto nel blog – naturalmente i plug-in esistenti non mi andavano bene); l’area PODCAST ha al momento un solo canale dedicato alle ultime produzioni dei Dionea, il progetto musicale cui partecipo dai tempi del liceo; in futuro vorrei ampliare quest’area introducendo anche dei canali non musicali e gestendo la loro pubblicazione con una piattaforma dedicata integrabile in modalità Web 2.0.