Tra il codice e la realtà

Oggi ho provato ad utilizzare Yahoo Pipes: davvero impressionante!

Si tratta di un servizio che consente di aggregare, filtrare, generare feed partendo dalle più disparate fonti. E’ ad esempio possibile recuperare i feed dei principali quotidiani e filtrare gli articoli in base al fatto che contengano o meno alcune parole (o più in generale un’espressione regolare). Potentissima poi la possibilità di utilizzare come fonte una ricerca di google news (o blog search), sfruttandone tutte le potenzialità per ottenere un’inesauribile fonte personalizzata di new di qualità. Putroppo non è possibile utilizzare (direttamente) i risultati di una ricerca sul web (con google), ma è possibile avere a disposizione quelli di yahoo.

Tecnicamente le sorgenti possibili comprendono oltre ad rss e atom, anche XML, JSON, HTML, CSV, consentendo davvero di accedere a qualsiasi fonte disponibile sul web. L’unico limite è che le fonti non devono avere un file robots.txt che ne impedisca l’accesso.

Alle sorgenti è poi possibile applicare un gran numero di “operatori” che consentono di filtrare, dividere, unire, contare, troncare, verificare l’univocità, ordinare, etc, etc. in modo da ottenere davvero qualsiasi risultato si desideri.

Ma l’aspetto davvero straordinario del servizio è l’eccezionale tool grafico di generazione:

yahoo pipes edit

E’ un ambiente visuale estremamente semplice da utilizzare e allo stesso tempo potentissimo. Con qualche click è possibile selezionare le sorgenti, filtrarle unirle ed ottenere poi un feed che si può pubblicare con estrema semplicità.

Date un’occhiata al box qui a lato: trovate il feed che ho costruito per ottenere news simili ai contenuti di questo blog. In pochi minuti un risultato davvero eccellente!

In un ottimo articolo Kyle Brown, elenca tre “comuni” problemi che affliggono i Web Services basati su XML (SOAP o meno). Merita una lettura attenta perché non mette in evidenza  le meravigliose capacità di un qualche tool, libreria o linguaggio, ma collega a errori di principio nel design i disastri che si riesce a produrre anche in contesti abbastanza semplici e con strumenti tutto sommato ben conosciuti.

Il primo errore è davvero banale e non mette in evidenza nulla di “profondo”: gestire messaggi da parecchi megabyte, magari con dati binari (senza forse neppure accorgersene) è semplicemente una scelta da incapaci; non è certo un problema dell’XML.

Il secondo è invece molto più interessante, perché è davvero una forza che guida spesso il design: definire i servizi ad un livello esremamente basso (ad esempio a livello di ogni singola operazione SQL). Perché (come dice Brown) “[…]such low-level data services often fail.” ? A mio parere il discorso è molto generale: Un Web Service dovrebbe rappresentare un’interfaccia che maschera la complessità che si trova a monte, semplificandone l’utilizzo in base alle esigenze di chi si trova a valle. Purtroppo invece scrivere un XML o richiamare un servizio non è più facile che accedere direttamente ad un DB e scrivere l’SQL relativo, né maschera alcuna complessità o dettaglio implementativo se il contenuto informativo necessario a richiamarlo è in relazione biunivoca con l’SQL utilizzato. Introdurre un layer (o un’interfaccia per l’accesso di una qualche risorsa/servizio) deve essere motivato da concreti vantaggi nel contesto specifico e non è certo buono in astratto e in generale.

Il terzo problema è paradossale e viene fuori soprattutto con SOAP: siccome non è comodo né banale definire gli schema in modo completo e soprattutto non è facile modificarli, spesso alcuni servizi sono solo semi-definiti con una parte (spesso predominate) magari ancora in XML, ma non parte dello schema della richiesta. Questa situazione è spesso solo la spia del fatto che si è sbagliato nel definire le interfacce, che risultano complesse ed devono essere cambiate molto spesso, perché sono poste al livello sbagliato.

Ultima nota a livello generale: in programmazione qualcosa di inutile è quasi sempre dannoso, specie un’astrazione.

Se l’XML non vi è mai piaciuto e JSON non vi sembra una soluzione adeguata, Protobuf potrebbe essere la soluzione che aspettavate.

L’idea interessante è quella di generare delle classi (ad esempio in C++) che forniscono un accesso estremamente comodo attraverso setters e getters (anche se io avrei fatto una scelta diversa) e integrazione con le funzionalità del linguaggio (come gli stream di IO) e contemporaneamente estremamente efficiente in termini di parsing (realizzato infatti ad hoc per il singolo schema)  e memorizzazione (direttamente in strutture del linguaggio).

Da molti punti di vista un approccio di questo tipo è la soluzione ottimale nel caso in cui si abbia a che fare con dati con una struttura omogenea e nota a priori, la cui manipolazione ha un peso significativo per l’efficienza del sistema nel complesso.

Non sono un fan dell’XML, ma non posso non notare che una soluzione del genere è implementabile anche con XML (e viene nei fatti usata da tempo ad esempio da gSOAP), ma non con JSON che manca di uno standard di definizione degli schemi. Rispetto a XML però non so dire quali siano i vantaggi: semplicità nella generazione delle classi nel linguaggio scelto ? Efficienza nella rappresentazione dei dati (utile ad esempio per ridurre la banda in caso di trasmissione) ? Efficienza comunque nel parsing (anche se ad hoc per schema) ? Non saprei, presto per dirlo, ma se dovesse servirmi qualcosa del genere, darò sicuramente un’occhiata più approfondita a questa libreria.