Lezione 19 - Il WWW: architettura ed elementi di successo

Il WWW

Con questa lezione si vuole effettuare un discorso conclusivo relativamente al corso e fornire anche alcuni elementi per completare il quadro relativo all’architettura del web. In particolare ci chiederemo: cosa determina il successo di un’applicazione sul web? Come si relaziona questo rispetto all’architettura?

In generale dobbiamo prima di tutto mettere in luce quali sono gli aspetti fondamentali e i punti di forza del web come architettura. Alla fine degli anni 80 - inizio degli anni 90, i cosiddetti concorrenti dell’architettura web erano una serie di applicazioni e di ambienti che avevano molte ma non tutte le caratteristiche tipiche del web. Proprio per questo motivo possiamo individuare gli elementi di forza che hanno contribuito al successo del web rispetto ai suoi concorrenti.
Primo fra tutti pensiamo ad FTP che è un protocollo di scambio di file che consente in modo molto efficiente di scambiarsi risorse (possiamo dire più efficiente rispetto ad HTTP) anche se rimane un ambiente che non ha interfaccia grafica e pertanto riservato a chi ha già esperienza in ambito tecnologico. La risorsa in questo ambiente è qualcosa di isolato, infatti non siamo capaci di creare ad esempio dei link. Le risorse sono essenzialmente dei file del file system di un host disponibile nella rete, obbligandoci di conseguenza a muoverci in quella struttura.

Esistevano però anche dei programmi che offrivano di più di quanto non facesse il servizio FTP, come ad esempio Gopher. Gopher è un meccanismo che consente di accedere ad alcuni file di testo che descrivono diversi tipi di risorse, tali che al loro interno sia possibile creare dei link ad altri server sulla rete i quali potranno contenere a loro volta file testuali o semplicemente altri link ad altri server. Si può notare come ciò che abbiamo appena descritto sia un meccanismo molto simile a quello del web in quanto troviamo la presenza di link e di file (pur risultando un meccanismo molto più rigido rispetto al web, in quanto non linkiamo una risorsa bensì un host). Nonostante, guardando alla diffusione iniziale di questo protocollo, esso partì con un buon margine di vantaggio rispetto al web, il suo successo si arrestò presto in quanto i creatori di questo protocollo decisero di mettere delle royalty sul suo utilizzo. Questo perché i creatori avevano la visione di questa architettura come un prodotto da sfruttare attraverso la vendita, mentre sappiamo bene che alcuni prodotti non hanno di per sé un valore, ma lo acquisiscono successivamente creando una rete. Il web nacque infatti in ambito accademico con la filosofia di essere libero e accessibile a tutti.

Esistevano anche una serie di tool concorrenti per descrivere ipertesti (infatti l’idea di base del web è un ambiente che permetta la definizione di ipertesti). Negli anni 80 erano già stati sviluppati un certo numero di strumenti per descrivere ipertesti, alcuni dei quali aventi già un’architettura client-server quindi già potenzialmente adeguati ad un ambiente distribuito. Questi strumenti rispetto al web erano però molto più complessi in quanto si basavano su una ben precisa teoria. Tale teoria richiedeva che lo strumento ipertestuale fosse uno strumento di lettura cognitivo in generale, in modo tale che l’utente fosse guidato nella lettura di un ipertesto, per evitare un sovraccarico cognitivo, per la necessità di dare una comprensione della sua posizione, di fornire degli strumenti di guida, di navigazione nel testo. Nonostante il web non avesse tutte queste caratteristiche, esso è riuscito a diventare un ambiente molto utilizzato e di successo.

È emblematico pensare che quando Tim Berners-Lee presentò il web, sia in ambiente informatico sia nelle conferenze in cui si discuteva della progettazione di ipertesti, ricevette delle forti critiche relativamente al fatto che era un modo troppo ingenuo di organizzare l’ipertesto. Dal lato opposto ciò che invece è emerso negli anni è che i punti di forza del web sono legati proprio alla sua semplicità, infatti il web si è imposto come un’architettura attraverso una semplificazione del protocollo (rispetto ad altri protocolli di rete è estremamente semplice) e rispetto anche della struttura ipertestuale di base. Sostanzialmente gli unici elementi facenti parte della struttura ipertestuale sono i link e le url. Questi due elementi hanno concesso al web di essere un’architettura dotata di ottima scalabilità (di cui si riparlerà più avanti) la quale ha avuto un peso molto maggiore rispetto ad esempio all’efficienza come protocollo, quindi l’efficienza di comunicazione (in termini ad esempio di banda consumata, persistenza della connessione …) e anche l’efficienza come ipertesto.

La nozione di standard

Chiaramente per comprendere il successo di un’applicazione che si propone come un’infrastruttura di rete, dobbiamo comprendere bene il concetto di standard e in generale di esternalità della rete. Tutti questi aspetti sostanzialmente affermano che la rete di per sé ha un valore molto forte e che lo standard è quello strumento che consente di evitare isole di connettività ma altresì di avere il modo di dare la possibilità alla rete di crescere perché chiunque conoscendo lo standard è in grado di contribuire alla dinamica, all’evoluzione e alla crescita della rete. Ovviamente lo standard può essere anche uno strumento di lock-in qualora sia una spinta verso la costruzione di quella che si chiama fidelizzazione forzata in quanto è chiaro che lo standard può diventare quello strumento con il quale si impedisce ai concorrenti di entrare sul mercato. Tutto ciò ha quindi una doppia valenza: da un lato può servire ad eliminare le isole di connettività, dall’altro può cercare eventualmente di crearle.

Definendo il tutto in modo più specifico, relativamente alle tecnologie dell’informazione, si può dire che lo standard impatta sull’interoperabilità (come sistemi diversi possano lavorare insieme) e sulla portabilità (il fatto che software diversi possano lavorare con architetture diverse con dati generati da programmi diversi). Questi due elementi possono essere pertanto considerati se vogliamo la traduzione del ruolo di uno standard in ambito tecnologico dell’obiettivo di eliminare le isole di connettività, ma per fare ciò dobbiamo però supportare l’interoperabilità e la portabilità dei dati ed eventualmente anche delle applicazioni.

Ma come prevale uno standard rispetto ad un altro?

Abbiamo richiamato una serie di casi storici, ad esempio l’imporsi di Windows come standard di sistema operativo, oppure un altro caso abbastanza famoso citato che è quello dell’imporsi del VHS rispetto al V8. Per il prevalere di uno standard non è importante solo la qualità, ma entrano in gioco anche una serie di aspetti relativi all’esternalità della rete. Ad esempio V8 era di maggiore qualità rispetto allo standard VHS, ma non si è imposto in quanto la rete di videoregistratori basati su VHS aveva creato un lock in.
Un altro esempio è l’Olivetti che aveva piazzato una grossa commessa ad AT&T e produceva il più potente computer al mondo e poi fallì perché sbagliò la sua politica di espansione puntando sul successo degli accessori dei suoi prodotti. Invece IBM investì molto sulla rapida evoluzione della tecnologia in quel settore e riuscì presto ad ottenere ottimi risultati e scalzare Olivetti dal mercato.
Si comprende bene che ci sono una serie di elementi che devono essere tenuti in considerazione e che sono legati alle prestazioni, al costo, ma più di tutto sono legati alla capacità del prodotto di essere il più possibile universale (richiamiamo ancora la nozione di scalabilità, anche se più ristretta).
Con queste premesse si può ora analizzare l’architettura del web, mettendo in luce alcuni elementi.

L’architettura del WWW

L’architettura del web è basata sostanzialmente su tre funzionalità che sono legate in qualche modo a tre standard a loro volta collegati al web. Il primo elemento molto importante è l’identificazione ovvero il fatto che ogni risorsa disponibile nel web deve poter essere identificata in modo standard. Questo significa che una risorsa ha un nome univoco e che il modo in cui questo nome è definito segue un particolare schema che è stato definito ed è conosciuto da chi decide di interagire in questo ambiente. Ciò permette ad una risorsa di essere un oggetto riconoscibile presente nella rete indipendentemente da qualsiasi altro elemento; ovviamente è chiaro che fisicamente ci deve essere un server che li rende disponibili, anche se esistono delle tecniche che consentono di superare il limite fisico dell’associazione stretta tra risorsa e un particolare host o servizio.

Un’altro elemento fondamentale è l’interazione, ovvero un protocollo di interazione che sia il più semplice possibile, come ad esempio HTTP. Http è un protocollo veramente semplicissimo in quanto è basato sull’idea che:

1. viene effettuata una richiesta
2. richiedo una risorsa utilizzando un’URI per identificarla
3. chi possiede quella risorsa restituisce quella risorsa

Una risorsa può essere sostanzialmente qualsiasi cosa: un’immagine, un file audio, un file binario eccetera. Esiste però uno standard per descrivere degli ipertesti e sostanzialmente significa descrivere dei testi che sono lo strumento più semplice per l’interazione con l’agente umano. Essi infatti consentono al loro interno di richiamare con dei link (o ancore) altri testi in maniera molto semplice. Notiamo che è presente una completa indipendenza tra la struttura con cui è organizzata una risorsa all’interno dello spazio degli host (o del dominio dei nomi in cui è organizzato il web) e le ancore che posso utilizzare all’interno degli ipertesti. Un’ancora può richiamare qualsiasi struttura e qualsiasi risorsa e non ha nessun vincolo se non quello che si conosca la sua URI. Anche in questo caso il protocollo è il più semplice e il più flessibile.

L’HTML è il primo standard che fornisce queste caratteristiche, ha un formato di markup, permette l’utilizzo delle URI (che hanno un loro schema) e che permette di definire ad esempio il protocollo, l’autenticazione, l’host, la porta, il percorso all’interno dell’host o ancora fare una query con parametri oppure identificare un nodo all’interno di una risorsa. Lo schema è pertanto molto ricco perché permette di descrivere molteplici aspetti, è indipendente dal protocollo, segue uno spazio dei nomi gerarchico, anche se questa gerarchia non vincola l’uso delle URI ed è “opaco”. Opacità significa che non dipende dall’URI stessa definire la semantica della risorsa, ma un’URI semplicemente identifica una risorsa generica, di quale risorsa si tratti non è interesse dell’URI definirlo.
Lo standard delle URI distingue tra URI, URN e URL:

• URI è un semplice identificatore
• URL localizza una risorsa
• URN può essere inteso come un particolare schema della URI (tramite “URN:”) e ciò indica che l’URI viene utilizzato come spazio dei nomi ovvero come identificatore per descrivere una risorsa attraverso un namespace (questo è il modo prevalente di definire un’URN). Esiste un modo alternativo più rigoroso di definire l’URN ovvero una risorsa che ha caratteristiche di persistenza. Per esempio volendo definire un oggetto ben specifico come un libro attraverso lo standard DOI possiamo usare l’URN del DOI e questo identifica il libro come oggetto “astratto” e non come risorsa sul web.

Un altro aspetto da mettere in luce è l’ampia gamma di funzionalità che possono essere ricoperte da un’URI, come ad esempio:

• identificazione di risorse in generale (ad esempio all’interno di uno stesso documento)
• identificazione di immagini all’interno di un file html
• strumenti di query (nel momento in cui fornisco un’URI in una GET e fornisco parametri io sto facendo una vera e propria query)
• costruzione dei link all’interno di documenti HTML
• identificatore o schema che mi definisce lo spazio dei nomi per un particolare vocabolario XML o per un particolare doctype html
• potrebbe servire addirittura come identificatore per oggetti univoci, reali oppure concetti (si pensi al semantic web con metadati descritti come risorse web).

Per quanto riguarda HTTP è un protocollo che possiede le seguenti caratteristiche:

• è il più semplice possibile
• è generico e quindi indipendente dal formato dei dati
• è client-server quindi ha l’architettura più semplice che ci possa essere
• è privo di stato, sempre per rendere il più disaccoppiato possibile l’evoluzione dell’applicazione lato client e l’evoluzione dell’applicazione lato server

Da queste caratteristiche possiamo dire che nel protocollo HTTP abbiamo una serie di ruoli che possono essere svolti dalle applicazioni che lo utilizzano, i più comuni sono quelli di user-agent e di origin-server, infatti l’architettura è client-server, anche se sono presenti una serie di complicazioni dell’architettura che rendono il tutto più efficiente con proxy, gateway, strumenti di tunnelling ecc. Ci sono varie versioni di HTTP come possiamo vedere dalla Figura sottostante.

La versione più semplice del protocollo apre la connessione, invia una richiesta, riceve la risposta e chiude la connessione. È supportato solo il metodo get.
Con HTTP 1.0 abbiamo i metodi get, post, head e put, pertanto possiamo anche caricare dati sul server, mentre nella versione 1.1 è stata introdotta la possibilità di tenere aperta la connessione TCP/IP e questo rende un po’ più efficiente il protocollo; grazie al pipelining possiamo anche inviare richieste multiple anche se non fosse stata ancora ottenuta risposta. Questo è utile se un file HTML avesse al suo interno una serie di risorse, si inviano in questo modo tutte le richieste ad esempio relative alle immagini senza attendere ogni volta la richiesta successiva.
Per quanto riguarda l’autenticazione, è previsto un metodo molto semplice; nella 1.0 la password passa in chiaro mentre poi abbiamo una serie di evoluzioni, non tanto del protocollo, quanto dell’uso che si fa del protocollo attraverso una serie di metodologie per rendere più efficiente l’interazione, basandosi sempre sul paradigma client-server.
La prima e più famosa sono certamente i cookies che sono dei blocchi di testo con la caratteristica di opaticità quindi non hanno nessuna definizione semantica di dato, sono semplicemente stringhe di testo che hanno la funzione di rendere identificabile una certa interazione. Utilizzando i cookie il server può tenere memoria di alcuni elementi di stato che hanno preceduto l’interazione tra client e server. La cosa è completamente a carico del server, poiché esso invia i cookie e attribuisce loro un significato, l’unica cosa che è richiesta al client è di rinviarli.
Tra le tecnologie più recenti di miglioramento del protocollo base HTTP parliamo di Rich Internet Applications, le quali cercano di utilizzare la potenza di elaborazione lato client per diminuire il carico lato server e anche il numero di iterazioni richieste, Ajax è la più famosa di queste tecnologie.

In queste applicazioni avviene che, rispetto ad una interazione tradizionale, si costituisce un mediatore intermedio (per esempio un motore ajax) che ha il compito di ricevere le richieste inviate lato client e filtrarle decidendo quali è in grado di risolvere da solo e quali invece inviare lato server. Quindi sostanzialmente si mantiene a disposizione del motore, lato client una serie di dati che servono all’interazione più immediata come ad esempio la gestione dell’interfaccia, e questo migliora le prestazioni.
Questi esempi confermano che nell’evoluzione di nuove metodologie e tecnologie si è sempre comunque mantenuto lo schema client-server e senza stati. Chiaramente questo è influenzato anche da questioni di dipendenze storiche in quanto tutta una serie di strati nella rete si basano su questa architettura e un eventuale cambiamento le porterebbe ad essere sostanzialmente sconnesse.
L’ultimo standard di cui parleremo sono i formati di markup quale html come rappresentante tipico di questo standard. In questo caso non si tratta di uno standard rigido, la prova è che nella prima fase storica del web nella quale c’è stata la balcanizzazione del web, per cui browser diversi interpretavano in modo diverso l’html per cercare di costruire dei lock-in di standard per avvantaggiarsi rispetto al concorrente, HTTP non vincolava la risorsa in alcun modo. L’uso dei formati di markup rende in altre parole più semplice per il browser interpretare un formato di testo, infatti con il markup identifico quali sono gli elementi e soprattutto le ancore, i link. Ci sono state evoluzioni all’interno della gestione dei formati di markup: si è pensato che html potesse essere sostituito da XML, poi invece XML si è costruito una sua nicchia di uso specifica e particolare diversa dall’html. Successivamente è nato l’xhtml che sostanzialmente è html che segue la sintassi XML per rendere meno frammentato il web grazie alla sua struttura più rigida e l’interpretazione dello standard, quindi sostanzialmente per rendere più uniforme l’interpretazione da parte dei vari browser.

Come si può notare dallo schema nella Figura qui sopra, l’evoluzione del web ha visto una partenza in cui c’era un semplicissimo protocollo client-server in cui i client chiedevano le risorse che erano mantenute lato server. Il protocollo si è poi evoluto, senza però mai cambiare questa idea di base. Si pensi ad esempio al meccanismo delle CGI, alla gestione di applicazioni lato server e poi l’ulteriore evoluzione con l’affiancamento di basi di dati interrogabili lato server, le quali però hanno anche creato un fenomeno interessante chiamato “deep web” che sostanzialmente è indice del fatto che una parte di dati presenti sulla rete di fatto non siano accessibili attraverso gli standard del WWW ovvero attraverso la descrizione con URI. Se ho dei dati in un database, questi possono generare pagine html diverse generando un disaccoppiamento tra risorse e URI.
Esiste un modo corretto e uno non corretto di utilizzare il protocollo secondo uno standard dell’architettura web. Ad esempio per google quasi qualsiasi cosa può essere trasformata in una URI, ovvero una richiesta a google o uno dei suoi servizi ha un suo corrispondente come URI, quindi come schema e insieme di parametri. Ciò significa che qualsiasi stato di un interazione può essere rappresentato da un identificatore e questo permette a questo stato di essere riutilizzato da altre risorse che lo possono linkare. Ci sono invece alcuni dati profondi che non sono descrivibili con un’URI.

Architetture REST

Esiste un tipo di architetture chiamato REST (Resource Stateless Transfer Architectures) che sono un insieme di architetture che tentano di codificare quelli che sono stati i principi di successo del web e che inizialmente si erano proposti come dei principi architetturali, anche se non così chiaramente specificati e definiti. Il web si era evoluto con tali principi ma nessuno, fino a quando è stata proposta la nozione REST, si era occupato di dare una definizione precisa di quella che era l’architettura del web anche perché ce ne erano diverse. Pur essendoci la principale client-server, ovviamente ci sono delle varianti in base ai cookie, proxy, database e tutto ciò che si può inserire in html. Pertanto le architetture REST propongono di dare una definizione di un’architettura che abbia la caratteristica di essere scalabile (in questo caso significa capacità di essere riutilizzata).
I principi delle architetture REST sono:

• eliminare la concezione di stato, ovvero tutti gli stati devono essere resi in modo astratto nella nozione di risorsa, la quale nozione è l’unico strumento che abbiamo che deve descrivere i dati dell’applicazione, come devono essere usati … ecc.
• tutte le varie possibile manifestazioni di un’applicazione devono essere rese con la nozione di risorsa
• le risorse devono poter essere riferite attraverso un indicatore univoco e linkabile. Questo permette che le risorse possano condividere un’interfaccia uniforme, in altre parole qualsiasi risorsa può essere scambiata attraverso un’interfaccia che utilizzi sempre gli stessi metodi. Questo dimostra che esiste un insieme definito di metodi ed operazioni che vengono utilizzate e un insieme definito di tipi di dato. Pensiamo al web, abbiamo una serie di metodi molto semplici quali get, post e head che sono i metodi standard. Poi abbiamo appunto un insieme definito di tipi di dato: nel momento in cui io scambio una risorsa posso eventualmente dire qualcosa sul tipo di dato, se è un file html, testo o immagine e ovviamente questi tipi di dati devono essere a loro volta standard e condivisi.
• Infine il protocollo deve essere client server e senza stati e può essere ottimizzato attraverso meccanismi di cache e di layer diversi da definire.

Quindi in qualche modo questi principi vanno a delineare quelle che sono le caratteristiche che hanno reso il web scalabile. Possiamo effettuare successivamente un confronto con altri tipi di architetture come ad esempio quelle orientate ai servizi. Sostanzialmente quando si parla di architetture SOA (Service-oriented architecture) dobbiamo pensare al fatto che i nodi di tale rete si scambiano sia risorse, sia metodi. Una risorsa deve quindi rendere pubblici i metodi che sono necessari per accedere al servizio che qualcuno vuole mettere a disposizione, in modo tale che altri possano poi utilizzare questi metodi per richiedere tali servizi. Un servizio di un oggetto reso disponibile all’interno di un’architettura SOA può essere invocato solo attraverso quei metodi che sono stati specificati per quel servizio e questo ci riporta immediatamente in un caso di interfaccia non uniforme poiché è necessario per l’appunto conoscere i metodi relativi ad un certo servizio.

Un web service è un’interfaccia che descrive una collezione di operazioni accessibili attraverso una rete mediante messaggistica XML (potrebbe anche non essere XML) e mediante un protocollo che permetta di scambiare i metodi e quindi utilizzare poi questi ultimi per effettuare delle interrogazioni.
Sappiamo che uno degli obiettivi di questa architettura è quello di supportare l’interoperabilità tra processi diversi e quindi tra servizi. Si parla di servizi in quanto non andiamo a fornire tanto risorse o oggetti, quando piuttosto vogliamo fornire anche una capacità computazionale, in altre parole la capacità di processare un dato. Viene quindi fornita un’interfaccia software che ha la caratteristica di essere pubblica, accessibile attraverso il web. Questa è proprio la caratteristica principale dell’architettura SOA e che la caratterizza rispetto ad un’altra.
Ci sono tre funzioni principali:

1. la funzione di trasporto, che è un formato che permette di descrivere come vengono scambiati i metodi, le interrogazioni
2. una funzione di descrizione che permette di descrivere il servizio eventualmente anche specificare elementi contrattuali legati al servizio come capacità di carico, numero di interrogazioni possibili ecc.
3. un meccanismo di scoperta che permetta di identificare i servizi sulla rete, sostanzialmente un registro dove è possibile cercare vari servizi i quali sono descritti in termini generici, in modo più specifico poi in termini di parametri utilizzati, di input e output e la posizione in cui andare a reperirli.

Viene tipicamente utilizzato SOAP come protocollo di trasporto e WSDL come strumento di descrizione del web service. Ci sono vari livelli di astrazione:

• un’interfaccia più astratta che descrive le funzionalità, il tipo di servizio offerto
• il cosiddetto binding, che descrive come si realizza il collegamento tra interfaccia e protocolli
• un’implementazione che descrive se effettivamente esiste una porta disponibile per utilizzare quel servizio (un punto di accesso)
• un protocollo UDDI per gestire la scoperta di vari servizi all’interno del registro e l’interrogazione dello stesso. Sostanzialmente fornisce informazioni relativamente al tipo di servizio offerto, il provider che lo fornisce e magari tale servizio può essere anche catalogato rispetto a vari parametri. Ovviamente ci sono anche altri standard ma UDDI è il più famoso.

Quindi possiamo dire che l’architettura SOAP, rispetto ai principi di massima scalabilità di un ambiente distribuito (riassunti nei principi delle REST), non ha interfacce uniformi bensì interfacce che dipendono dai servizi stessi. Per accedere ad un servizio devo conoscere i metodi che servono per invocarlo! Infatti, se guardiamo al successo che hanno avuto queste architetture, esse sono state utilizzate quasi esclusivamente come strumenti di gestione dell’interoperabilità, ma all’interno di organizzazioni nelle quali esiste un controllo centralizzato, quindi all’interno di una stessa azienda che possiede mainframe diversi, applicativi diversi che devono interagire o all’interno di federazioni e collaborazioni tra aziende (sempre nelle quali c’è un controllo centralizzato). Una tra le altre funzionalità per cui questo standard è stato proposto, ovvero creare un mercato dei servizi nel web quindi in qualche modo un mercato della capacità computazionale, non è stata invece soddisfatta, perché effettivamente il fatto di cercare un servizio attraverso un registro, capire se quei parametri che il servizio mette a disposizione possano essere mappati sulla mia applicazione e svolgere il tutto in modo automatico, non è poi così semplice. Di conseguenza un vero e proprio mercato dei servizi sul web non ha funzionato, proprio perché c’è un elemento di scalabilità frenato dal fatto che per usare una risorsa è necessario conoscerne l’interfaccia.

Il web 2.0 e gli strumenti di MASHup

Analizziamo ora invece il web 2.0 e in particolare gli strumenti di MASHup che negli ultimi anni hanno subito un grande aumento del loro utilizzo. Utilizzare uno strumento di MASHup significa sostanzialmente costruire una pagina web utilizzando delle API che interrogando servizi ottenendo così risorse provenienti da locazioni diverse dell web. Queste API definiscono in qualche modo l’interfaccia ai vari servizi, alcuni dei quali, rispetto ad altri servizi e risorse nel web, possono essere di tipo REST mentre altri possono non esserlo. Per esempio RSS è tipicamente di tipo REST poiché utilizzo le URI per descrivere le risorse (tutto rispetta lo standard W3C). Tramite RSS vengono descritte news e aggiornamenti di risorse web utilizzando XML e utilizzando delle URI; il modo per interrogare un file RSS è sostanzialmente molto vicino dall’essere uguale all’interrogazione di qualsiasi altra risorsa del web. Interfacce non REST sono invece, ad esempio, le varie API di Google. Se guardiamo al fenomeno del MASHup nel web effettivamente questo ha avuto un certo successo poiché, dal punto di vista tecnologico, il web 2.0 si fonda sostanzialmente su questo approccio. D’altra parte dovremmo notare che vengono usate spesso API proprietarie (es. google) ma nonostante ciò, questo tipo di approccio ha dimostrato essere scalabile e, pur non essendo formalmente conforme ai principi REST, riesce a funzionare come standard grazie al fatto che quando nascono servizi di buona qualità, di fatto quel servizio diventa uno standard. Si creano pertanto dei monopoli e la scalabilità è sostenuta dal fatto che, volendo utilizzare un certo tipo di risorsa come flickr o twitter ad esempio, si va ad identificare un servizio ben specifico che, pure avendo le proprie API proprietarie, è ormai accettato da tutti come standard. Chiaramente il fatto di usare API proprietarie rispetto a standard come RSS fornisce chiaramente più espressività e più potere di calcolo ma limita leggermente anche la capacità di diffusione, anche se questo limite viene superato dal costituirsi di monopoli all’interno del web.

Il Web semantico

L’ultimo tipo di architettura che analizzeremo è quella del web semantico, un tipo di proposta che ha avuto successo solo in ambito accademico e che si propone di descrivere le risorse nel web attraverso dei metadati. I metadati in qualche modo si occupano di descrivere dei domini, dei particolari ambiti attraverso delle semplici teorie logiche (chiamate anche ontologie) che consentono di descrivere le risorse in modo più approfondito e quindi di descriverne la semantica. Avendo a disposizione delle teorie logiche, è anche possibile effettuare del “reasoning”, ovvero delle piccole deduzioni su questi metadati. Sostanzialmente immaginiamo di avere varie ontologie che appartengono a domini diversi; tutte queste descrizioni sono state create in modo indipendente ma posso anche collegarle fra loro e fare anche del reasoning per cui posso anche ad esempio capire che se una certa persona è nata a Parigi allora è francese e deduzioni simili.

Dal punto di vista degli standard utilizzati il web semantico sarebbe tutto REST (RESTful) perché si utilizzano standard W3C, quindi qualsiasi metadato che vediamo è descritto attraverso un’URI, ogni dominio ha una propria URI che serve a definire il namespace dei vari metadati, concetti espressi ecc. Di conseguenza ogni risorsa o meglio ogni metadato è descritto utilizzando i principi REST! Nonostante ciò il web semantico non ha avuto successo come strumento pur essendo utilizzato in ambiti ben specifici dove si ha un controllo centralizzato. Si pensi ad esempio all’ambito medico, dove effettivamente il dominio a disposizione è complesso: il fatto avere a disposizione una teoria logica che descriva le varie dipendenze ad esempio tra sintomi e malattie, tra i vari organi, tra farmaci e malattie, dei controeffetti ecc. può aiutare effettivamente nell’interrogazione della base di dati, nella sua espansione da sorgenti che vengono da fonti diverse. Il motivo dello scarso successo del web semantico può essere riscontrato nel fatto che pur usando standard che sono adeguati ai principi REST, in realtà viene violato il principio di indipendenza delle risorse. Per capire questo concetto pensiamo a questo esempio: pensiamo di avere due risorse qualsiasi, A e B (possono essere ad esempio dei documenti) e che successivamente vengono associati a dei metadati. Essi supponiamo che indichino ad esempio che un documento tratta di musica e l’altro tratta di luoghi geografici. Quando viene creata l’associazione tra A e alfa (metadato) e B e beta (metadato), per garantire la compatibilità è necessario creare una mappatura tra i metadati alfa e beta, altrimenti lo sforzo iniziale per associare alfa e beta non ha portato nessun vantaggio aggiuntivo quindi come si vede nella Figura. È presente l’insieme dei metadati blu, verdi e rossi però per collegarli c’è la necessità di sapere che quello che qui viene chiamato autore può essere la stessa persona che viene specificata nell’altro dominio. Questo richiede però uno sforzo ulteriore che non consente ad una risorsa, una volta creata, di vivere indipendentemente poiché senza questo sforzo ulteriore il valore di tale risorse andrebbe perso, ed ecco quindi violata la scalabilità!

Critical Mass

Esiste una famiglia di teorie chiamate teorie della critical mass che si interessano dal punto di vista sociologico di capire quali sono le caratteristiche del successo di azioni collettive. Ci sono tre elementi che sono definiti come caratteristici di una qualsiasi azione collettiva:

1. Il primo è il costo dell’azione individuale, ovvero quanto costa intraprendere una determinata azione; l’abbiamo analizzato parlando del tipo di evoluzione che ha una rete e il quale è legato a un fenomeno di invarianza di scala, determinato semplicemente dal fatto che ci sono risorse che sono più attrattive di altre. L’attrattività di un elemento nasce semplicemente dalla sua presenza. All’interno di queste teorie si parla di capacità attrattiva, di fitness di un nodo. Quando invece parliamo di impostazione di una risorsa dal punto di vista della comunicazione di successo, uno degli elementi chiave era chiaramente non richiedere un costo eccessivo di attenzione, di capacità cognitiva per il nostro destinatario. Abbiamo visto in ambito economico come il fatto di dover sostenere dei costi per cambiare atteggiamento di consumo di un prodotto, questo è tipicamente un freno che viene utilizzato per creare situazioni di monopolio, di fidelizzazione forzata.
2. L’altro elemento è legato alla funzione di produzione che in questo ambito viene chiamata funzione di produzione, la quale può essere crescente o decrescente e che non è nient’altro che ciò che noi abbiamo spesso chiamato feedback positivo o negativo secondo quanto già formulato nelle teorie della cibernetica alla fine del dopoguerra e nelle teorie dei sistemi complessi. È chiaro che essere in grado di agganciare un sistema di feedback positivo o negativo cambia anche il risultato dell’azione.
3. Un ultimo elemento è legato all’eterogeneità dei gruppi (vedi evoluzione delle reti). È chiaro che se in una rete nella quale le distanze tra i vari nodi non sono troppo ampie, le informazioni viaggiano più rapidamente. Di conseguenza se esistono dei gruppi molto frammentati, con pochi collegamenti fra di loro, ecco che sarà più difficile diffondersi per un’azione collettiva o un messaggio. Invece la capacità di un messaggio di viaggiare su gruppi sociali eterogenei fra loro, ma che riescono comunque tutti a percepire questo messaggio, è maggiore e il messaggio ha di fatto una possibilità di successo molto più ampia. Questo è molto evidente ad esempio in ambito politico, soprattutto sulla media distanza, si nota bene come le forze politiche che riescono a proporre dei messaggi che sono attrattivi per gruppi eterogenei della società o magari all’interno del loro stesso elettorato, riescono ad avere più successo rispetto ai messaggi che vanno a colpire un gruppo specifico o a creare un’antipatia o avversione rispetto ad un altro gruppo (nel momento in cui vai a colpire un target, stai però creando un problema in un altro target).

Si può dire che quanto abbiamo visto rispetto ad un’architettura (tecnologica) di comunicazione vada ad incidere soprattutto su questo elemento, ovvero il costo dell’azione; quando parlavamo di scalabilità e di capacità di una risorsa di essere indipendente rispetto ad altri elementi dell’architettura, sostanzialmente parlavamo della capacità della risorsa di poter essere riutilizzata senza dover impiegare costi aggiuntivi nella rielaborazione. I principi sono gli stessi che sono stati analizzati per le architetture REST anche se questi andrebbero leggermente ampliati alla luce dell’esempio visto. Si vanno ad identificare dei principi tecnologici necessari per costruire degli oggetti che possano essere riutilizzati e che quindi abbiano quantomeno il primo elemento necessario al successo di una comunicazione che è quello appunto di non richiedere costi aggiuntivi nell’uso del messaggio. Si pensi alla storia di Hotmail, il cui successo è nato grazie a quella piccola pubblicità che risiede nelle mail che invio, e al fatto che comunque l’idea di questa pubblicità che non comporta alcun costo usufruisce del servizio è solo un piccolo rumore che più di tanto non da fastidio, e non implica costi aggiuntivi soprattutto.