Web Service: Metaweb e MSQ
Nella progettazione di un Web Service si è messi di fronte a differenti scelte tecnologiche; le giuste scelte possono assicurare una realizzazione ottimale dei servizi Web. I Web Service sono utilizzati quotidianamente per l’interazione fra differenti sistemi attraverso messaggi scambiati in rete; comunemente i Web Service sono utilizzati per mettere a disposizione di un’applicazione Web i dati in possesso di un’altra applicazione.
Nononsante la proposizione del protocollo SOAP, fortemente appoggiato dai colossi dell’informatica, e la nascita spontanea dell’architettura REST, si tende nella maggior parte dei casi a implementare varianti di queste due soluzioni definendo un protocollo che risponda appieno alle proprie esigenze.
E’ il caso di Metaweb e MSQ, rispettivamente web service e protocollo di interrogazione e scambio dati - entrambi in piena fase di sviluppo - realizzati da Metaweb Technologies per l’accesso ai propri servizi.
Dominio di interesse di Metaweb e MSQ
Metaweb Technologies fornirà servizi per lo storing e la manipolazione in remoto di strutture dati; si potranno definire proprie strutture dati da popolare con i propri dati oppure attingere a strutture definite centralmente e distribuite a pagamento o sotto altri termini si utilizzo.
Se il concetto di database web (dati strutturati accessibili attraverso la rete) è già stato affrontato in progetti quali Exhibit, DabbleDB e in qualche modo da Salesforce con Apex, è sicuramente intrigante il pensiero di poter accedere ad un ampio repository di informazioni strutturate liberamente utilizzabili.
Gli alpha-tester dei servizi Metaweb possono già accedere ad un Metaweb Server appositamente allestito e consultare e contribuire alla crescita di un database di contenuti utilizzabili liberamente. Il database è composto da insiemi di strutture dati e da una grosso mole di informazioni estratta principalmente da database liberi disponibili su internet come Wikipedia e MusicBrainz.
In questo scenario è possibile delineare le esigenze che stanno alla base delle scelte implementative del servizio; il Web Service Metaweb deve assicurare:
- Disponibilità continua delle informazioni
- Accessibilità del servizio tramite HTTP
- Trasmissione rapida di dati
Tramite MSQ deve essere possibile interagire con un Metaweb Server per:
- Conoscere le strutture dati esistenti - deve essere possibile operare programmaticamente in introspezione per conoscere la struttura dei dati e richiedere dati anche provenienti da differenti tipi e differenti ontologie
- Modellare le strutture dati - si deve poter definire nuove strutture dati, modificare quelle già esistenti ed indicare le relazioni che le legano
- Estrarre informazioni contenute nelle strutture dati esistenti - MSQ deve garantire la possibilità di esprimere queste interrogazioni
- Utilizzare le strutture dati come contenitore per le proprie informazioni
- Combinare informazioni contenuti in diverse strutture dati - MSQ deve dare la possibilità di combinare in modo efficace dati provenienti da strutture dati differenti
La soluzione Metaweb e MSQ
Di seguito sono elencate le scelte tecnologiche seguite per l’implementazione del servizio Metaweb.
- Paradigma RESTful - I Web Service esposti da un Metaweb Server sono accessibili tramite protocollo HTTP e sono congruenti alla definizione di Web Service REST; l’attenzione non è posta tanto nella interazione fra differenti sistemi quanto sull’accesso alle risorse. La soluzione appare naturale dal momento che Metaweb si prefigge di essere un repository intelligente
- Utilizzo di JSON per l’interscambio di dati strutturati - JSON (JavaScript Object Notation) è un formato di interscambio dati leggero nato per comunicare dati strutturati ai browser tramite Javascript; l’utilizzo di JSON al posto del formato XML assicura traffico ridotto nello scambio di dati e maggiore rapidità nella interpretazione del messaggio. La scelta dj JSON appare aderente alla necessità di trasmettere grossi moli di dati verso molti utenti
- Definizione del linguaggio MSQ - per l’interazione con il servizio Web è necessario utilizzare MSQ. MSQ è un linguaggio realizzato ad hoc codificato in JSON. La scrittura di istruzioni in formato JSON, lo stesso utilizzato per l’interscambio di dati strutturati, assicura chiarezza nel protocollo e nella implementazione dei futuri client
Utilizzo
Per per interagire con un Webmeta Server è sufficiente procedere ai seguenti passi:
- Costruire una o più query in linguaggio MSQ; inserire le query in un oggetto envelope mantenendo la sintassi JSON
- Operare un sanitize sulla stringa JSON rappresentate l’oggetto envelope in modo che sia possibile utilizzarlo come parametro di una richiesta GET HTTP
- Se necessario, autenticarsi con un messaggio HTTP POST al server che si vuole raggiungere; l’autenticazione viene tracciata con un ordinario cookie che deve essere conservato dal client. L’autenticazione avviene ad un URL dedicato
- Inviare al server una richiesta GET HTTP del tipo [url query]?queries=[oggetto envelope del punto 2]. La richiesta avviene ad un URL dedicato, differente rispetto alla URL di autenticazione
- Intercettare la risposta da parte del server nel frammento data del messaggio HTTP
- Controllare che il server abbia risposto con il codice HTTP 200
- Accedere alla struttura dati rappresentante le risposte alla query; ogni query ha una risposta indipendente dalle altre con un codice dedicato che indica se la query è andata a buon fine oppure no
- Estrarre il risultato di ogni query, rappresentato da una struttura dati JSON dedicata
Conclusioni
Nella progettazione di un Web Service si è messi di fronte a differenti scelte tecnologiche: tipologia di Web Service, formato di interscambio dati, protocollo per il dialogo fra client e server; la scelta della giusta combinazione può assicurare una realizzazione ottimale dei servizi Web.
Si sono analizzate le necessità di Metaweb Technologies e le scelte tecnologiche effettuate relativamente alla realizzazione dei propri Web Service.
Foto di iboy_daniel distribuita sotto Creative Common License
7 Agosto 2007
Categorie: Web Service, Ricerca
Articoli simili
- Database Sharding e MapReduce per lo scaling del data tier
- Rails 2.1 e ottimizzazione Active Record
- Leve, modalità e risultati dell'adozione di Ruby on Rails