YQL (Yahoo! Query Language): SQL per il mashup

YQL (Yahoo! Query Language) è un framework con cui creare mashups :

• Tabelle relazionali ad interfaccia dei servizi offerti da Yahoo! (Flickr, ricerca, ecc.)
• Tabelle relazionali “speciali” per dati e servizi esterni (HTML, RSS, Atom, CSV, ecc.)
• Linguaggio simile a SQL per interrogare, filtrare e combinare – join e subselect – pagine, feeds e dati  (disponibili nel framework, come appena detto, sotto forma di tabelle relazionali)
• URL per esporre – come XML o JSON – i risultati
• Meccanismo di autenticazione basato su OAuth

Il framework nasconde ogni complessità: riconciliazione semantica per riportare i contenuti ad una semantica comune, conversione XML delle sorgenti che non lo sono (ad esempio i CSV), XQuery per selezionare i tags desiderati e applicare i filtri, e conversione XML o JSON dei risultati.

Una breve guida ed una console ricca di esempi consentono di comprenderne in fretta le semplici modalità di utilizzo.

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

Atom Server: distribuire i dati con Atom

Basato su Apache Abdera e ispirato a Google Gdata, AtomServer gestisce base dati di elementi (Entry) Atom: organizzati in Collection (e queste in Workspace), possono essere ricercati con Open Search, aggiunti, cancellati e modificati con Atom Publishing Protocol (AtomPub) e consumati con Feed Atom.

Ogni Collection è esposta come Feed (sequenza di Entry, ciascuna con un proprio contenuto: testo, XML, binario in base64, ecc.) paginati secondo Feed Paging e costituiti in base alle indicazioni fornite nella richiesta: indice della Entry con cui cominciare e massimo numero di Entry da ritornare.

Ad ogni Entry è possibile associare una o più categorie e filtrare i Feed proprio sulla base di queste (anche combinandole con operatori booleani). Qualora sia possibile dedurre categorie dal contenuto dell’Entry, Atom Server le associa automaticamente, sgravando il client da questa incombenza.

Ogni Entry, in ciascuna Collection, ha un indice unico: assegnato al momento dell’inserimento è sostituito ad ogni modifica o cancellazione con uno superiore al maggiore tra quelli presenti in quel momento nella Collection. Le Entry modificate per ultime saranno quindi sempre posizionate al termine dei Feed in cui compaiono: seguendo i Feed dall’indice minore a quello maggiore, salvando quest’ultimo e richiedendo il successivo Feed (pagina) proprio a partire dall’indice appena salvato (sostituendolo di volta in volta con il nuovo maggiore), si avrà garanzia di sincronia con lo stato della base dati in quel momento.

Atom Server gestisce la concorrenza assegnando ad ogni Entry una versione: dovrà essere recuperata e ricomunicata con la modifica e quest’ultima andrà a buon fine solo se la versione non è cambiata a seguito di un’altra modifica, svolta probabilmente da qualcun altro. Benché AtomPub gestisca nativamente la concorrenza, gli autori hanno preferito questa strada proprietaria a favore della maggior semplicità d’implementazione.

Atom Server può essere posto al centro di un processo: ad ogni servizio coinvolto corrisponde uno stato d’ingresso e uno di uscita, ogni servizio filtra gli Entry categorizzati con quello d’ingresso, li tratta e li ripone nella base dati con lo stato (categoria) che corrisponde al filtro del successivo, e così via. In tal modo i servizi presenti possono essere tolti o spostati nella sequenza agendo sui filtri d’ingresso e sullo stato d’uscita di chi li precede. Nuovi servizi possono essere aggiunti agendo sui loro filtri d’ingresso e sullo stato d’uscita degli altri. Questa applicazione di Atom Server può essere equiparata all’utilizzo di code JMS e selettori per filtrare i messaggi: le differenze consistono nel protocollo (Http nel caso di Atom Server), nella quantità di traffico TCP (inferiore per Atom Server: ogni Feed veicola più Entry) e nella quantità di aggiornamenti da processare (tutti quelli accodati nel caso di JMS, forse meno nel caso di Atom Server, qualora le modifiche fossero più frequenti del pooling del Feed).

In futuro sarà possibile combinare Entry afferenti a Workspace diversi in un unico Feed ed eseguire massivamente operazioni in batch inviando un documento XML con le Entry e le operazioni da svolgere; la risposta sarà un Feed con l’elenco degli esiti. Questa scelta progettuale mi lascia però perplesso: sembra sincrona e ben poco RESTful (alla cui teoria gli autori aderiscono fermamente).

Atom Server è stato sviluppato per costituire un unico punto di distribuzione dei dati (più sorgenti e più consumatori, in tecnologie diverse, talvolta datate) ed è correntemente utilizzato sul network di Homeaway.com.

—-><—-

Materiale sull’argomento:

• InfoQ: AtomServer – The Power of Publishing for Data Distribution
• InfoQ: AtomServer – The Power of Publishing for Data Distribution – Part Two

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

Workflow con REST (REpresentational State Transfer)

Jim Webber, nella presentazione “A Couple of Ways to Skin an Internet-Scale Cat” tenuta al Qcon 2008 di Londra, discute, tra le altre cose, come realizzare un workflow con REST (o, meglio, con la sua implementazione più nota: HTTP).

La presentazione mostra la sequenza di richieste e risposte per ordinare, pagare, ottenere caffé e latte da Starbucks. Il workflow così ottenuto rispetta i vincoli che REST impone: in particolare l’interfaccia uniforme – le risorse sono identificate mediante URI, le operazioni possibili sono predeterminate, hanno semantica nota, indipendente dalle risorse, e le rappresentazioni in risposta contengono le possibili transizioni di stato (come link, annotati per indicare la semantica associata).

Il consumatore, quindi, non conosce a priori la sequenza, il servizio è l’unico a conoscerla; ritornando riferimenti (annotati) guida il consumatore. Supposto che le due parti si accordino preliminarmente sulla semantica e sulla “sintassi” di ogni possibile passo, il servizio potrà, in ogni momento, modificarne la sequenza (nell’ordine o nel numero) senza conseguenze per chi la consuma.

Questo approccio sembra meglio applicabile qualora il colloquio si svolga interamente con un’unica “giurisdizione” (entrati in un ufficio e dovendo trattare con un certo numero di impiegati secondo una sequenza non nota a priori, ciascuno di questi, dopo aver svolto il lavoro di propria competenza, indica il collega con cui proseguire) e serva interazione a passi intermedi (così da non poter essere celati dietro un unico punto di ingresso). Qualora il colloquio avvenga con più “giurisdizioni” sembra irrinunciabile, a meno di compromessi, un coordinatore esterno che smisti.

L’accordo, l’associazione e le annotazioni sulla semantica sembrano d’obbligo: con i link si riesce ad esprimere solo l’interrogazione della risorsa (GET con i parametri riportati dal link stesso nella query string); OPTIONS, da solo, potrebbe non tenere la logica di business separata da quella di comunicazione e non essere sufficiente (in base a quale semantica decidere se eseguire una POST, una PUT o una DELETE?).

Qualunque workflow è risolvibile con questo approccio (continuando a soddisfare i vincoli che REST impone)? Lo stato di una risorsa è sempre nella posizione di indicare operazioni da svolgere su un’altra (che non siano d’interrogazione)?

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!