Atom Server: distribuire i dati con Atom
Pubblicato da Andrea Gumina su 3 Dicembre 2008
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:
—-><—-
Hai trovato questo post interessante? Segui il feed e commenta!
