Interoperabilità dei dati: i Web Services ASMX e i DataSets

Nell’interrogare i Web Services scritti in ASP (ASMX Web Services), che internamente utilizzano gli ADO RecordSet, da un client Java (o comunque in altri linguaggi non “Microsoft-compliant“), si possono avere dei noti problemi di interoperabilità.

L’utilizzo dei DataSet di ADO.NET è alquanto diffuso sui sistemi Windows, vista la certa flessibilità e velocità nella presentazione delle informazioni recuperate da un database. Si possono aggirare i problemi di interoperabilità utilizzando i DataSet tipizzati  (Typed DataSet) in combinazione con definizioni personalizzate dei WSDL (Web Services Description Language), come spiegato nell’ottimo tutorial che ho preso come riferimento: Web Services and DataSet.

 

Livelli di interoperabilità. Aggiorniamoci con un pò di teoria: la capacità di elaborare i dati, indipendentemente da dove essi provengano, costituisce il livello più primitivo di interoperabilità (definita ” interoperabilità dei dati “). Lo standard XML 1.0 è stato specificamente sviluppato per facilitare appunto tale interoperabilità. Dati serializzati in XML 1.0 possono essere facilmente estratti e manipolati su qualsiasi piattaforma, usando qualsiasi linguaggio di programmazione per cui esista un processore di XML. Per raggiungere l’interoperabilità dei dati occorre esporre da ambo le parti (server e client) uno strato di XML API.

 

DataInteroperabilityInXML

 

L’utilizzo di XML per la distribuzione di Web Services semplifica, dunque, l’interoperabilità tra sistemi distribuiti eterogenei e i Web Services stessi potrebbero essere implementati e consumati utilizzando direttamente le XML API. Tale approccio offre il pieno controllo nell’elaborazione dei messaggi, ma richiede un grosso overhead nell’implementazione dell’infrastruttura comune di Web Services. Lavorare su uno strato di XML API (sia sul client che sul server), è abbastanza oneroso. Tuttavia, framework come Microsoft ASP.NET automatizzano la traduzione tra documenti XML e istanze di oggetti in fase di esecuzione (WebMethod framework) e aiutano lo sviluppatore a lavorare su oggetti anziché su output XML.

Toolkit Interoperability

Se lato client, volessimo usare Java e, in particolare, il toolkit Axis di Apache per “consumare” il Web Service (WSDL2Java), potremmo pensare di generare automaticamente le classi a partire dalle definizioni dell’XML Schema, senza scendere ad un livello inferiore di API XML. L’idea è quella di passare ad un successivo livello di interoperabilità, costituito da un “ToolKit interoperability”: sia sul client che sul server gli oggetti verranno serializzati-deserializzati automaticamente a partire da XML (lo strato di API XML diventerebbe per noi trasparente).

 

Il problema dei DataSet. Il DataSet è un tipo polimorfo, la cui attuale struttura non è determinata fino alla fase di esecuzione (finchè il DataSet stesso non viene riempito con i dati). In fase di progettazione, quando lo sviluppatore Java lancia il WSDL2Java di Axis, non si hanno abbastanza informazioni nella definizione dello schema per poter mappare i tag XML su proprietà di un oggetto POJO. Axis, non sapendo il tipo dell’oggetto, non riuscirà a deserializzare e l’unico modo per lo sviluppatore Java è quello di consumare il servizio web utilizzando le API DOM.

Utilizzare i Typed Datasets. Probabilmente il modo più semplice per aggirare il precedente problema è di non utilizzare i DataSet generici negli ASMX Web Services. I Dataset tipizzati (Typed Dataset) sono classi che derivano da Datasets ed espongono membri fortemente tipizzati che rappresentano una vista specifica di dati. A differenza dei DataSet generici, i DataSet tipizzati sono vincolati ad una struttura specifica, ad una definizione dello schema XML, specificata in fase di progettazione. È possibile generare automaticamente DataSet tipizzati dalla definizioni di schema XML utilizzando il comando xsd.exe o il built-in designer di Visual Studio ®. NET.

Lato Axis, quando provederete a generare gli stub, vi troverete magicamente gli oggetti o gli array di Java POJO, su cui potete lavorare in modo sicuramente più agevole che non parsando l’XML.

La parte operativa la potete tranquillamente vedere sul tutorial che vi ho precedentemente segnalato: http://msdn.microsoft.com/en-us/magazine/cc188755.aspx

Ecco di seguito un pò di link utili agli sviluppatori Java per la generazione degli stub client in AXIS:

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2013/07/06/i-web-services-asmx-e-i-datasets/.

[NO-SQL] Il Teorema di CAP e il No-SQL data model

Volendo continuare la serie sulla “filosofia” NO-SQL e sulle prerogative per cui è necessaria (vedi l’articolo riportato su questo blog, “NO-SQL e introduzione a MongoDB“), estrapolo qui le motivazioni e le caratteristiche lette negli articoli riportati su BigDataNERD:

Perché NO-SQL?

Per poter rispondere alla domanda occorre esaminare il “teorema di CAP” e ricordare che un concetto fondamentale degli RDBMS è quello delle “ACID transactions” (A=Atomicity, C=Consistency, I=Isolation, D=Durability)

  • A come Atomicità. La transazione è indivisibile, ossia o tutti gli statements che la compongono vengono applicati ad un database o nessuno.
  • C come Consistenza. Il database deve rimanere in uno stato consistente prima e dopo l’esecuzione di una transazione, quindi non devono verificarsi contraddizioni (inconsistency) tra i dati archiviati nel DB.
  • I come Isolamento. Quando transazioni multiple vengono eseguite da uno o più utenti simultaneamente, una transazione non vede gli effetti delle altre transazioni concorrenti.
  • D come Durabilità. Quando una transazione è stata completata (con un commit), i suoi cambiamenti diventano persistenti, ossia non vengono più persi.

I più comuni e diffusi RDBMS supportano le transazioni ACID e i principi su esposti sembrerebbero bastare. Ma dov’è il problema?

Nell’era del Web 2.0, le applicazioni devono lavorare su bilioni e trilioni di dati ogni giorno e la scalabilità è un concetto che in tale ambito ricopre un ruolo importantissimo. Per questo motivo i database hanno bisogno di essere distribuiti sulla rete per realizzare una scalabilità orizzontale. Esaminiamo qui il concetto di “CAP theorem” per valutare le caratteristiche di un siffatto sistema di storage distribuito dei dati.

Il teorema di CAP fu teorizzato da Eric Brewer nel 2000 (C=Consistency, A=Availability, P=Partition-Tolerance). Per maggiori informazioni si veda il seguente articolo: ACID vs. BASE il Teorema di CAP (di Stefano Pedone).

Nell’ambito di un sistema di storage distribuito, i 3 principi hanno la seguente definizione:

Consistency: se viene scritto un dato in un nodo e viene letto da un altro nodo in un sistema distribuito, il sistema ritornerà l’ultimo valore scritto (quello consistente).

Availability: Ogni nodo di un sistema distribuito deve sempre rispondere ad una query a meno che non sia indisponibile.

Partition-Tolerance: è la capacità di un sistema di essere tollerante ad una aggiunta o una rimozione di un nodo nel sistema distribuito (partizionamento) o alla perdita di messaggi sulla rete.

Secondo la teoria CAP, è impossibile garantire tutti e tre i principi del teorema di CAP. Infatti, si consideri un sistema distribuito e si supponga di aggiornare un dato su un nodo 1 e di leggerlo da un nodo 2, si verificheranno le seguenti conseguenze:

  1. Il nodo 2 deve ritornare l’ultima “miglior” versione del dato (quella consistente) per non violare il principio della Consistenza
  2. Si potrebbe attendere la propagazione del dato modificato nel nodo 2 e, quest’ultimo, potrebbe mettersi in attesa della versione più aggiornata, ma, in un sistema distribuito, si ha un’alta possibilità di perdita del messaggio di aggiornamento e il nodo 2 potrebbe attenderlo a lungo. Così non risponderebbe alle query (indisponibilità), violando il principio dell’Availability
  3. Se volessimo garantire sia la Consistency che l’Availability, non dovremmo partizionare la rete, violando il principio del Partition-Tolerance

Le web applications progettate in ottica Web 2.0, caratterizzate da architetture altamente scalabili e profondamente distribuite con politiche di prossimità geografica, puntano in maniera forte sulla garanzia di alte prestazioni ed estrema disponibilità dei dati. Si trovano quindi ad essere altamente scalabili e partizionate. La filosofia NO-SQL è sbilanciata verso la ridondanza dei nodi e la scalabilità.

Di seguito, si riporta una tabella dei maggiori database NO-SQL del momento:

Il NoSQL data model può essere implementato seguendo differenti approcci a seconda delle strutture dati con cui si rappresentano i record di dato.

  • Famiglie di colonne o “wide column store” (come Cassandra e HBase): le informazioni sono memorizzate in colonne, in coppie chiave/valore. Tipicamente sono usati nell’ambito della memorizzazione distribuita dei dati;
  • Document Store (come CouchDB, MongoDB): le informazioni sono organizzate in “Document“, rappresentati in XML, JSON o BSON, e l’accesso ai dati avviene attraverso API che interrogano veri e propri dizionari. Sono molto usati nello sviluppo di attuali web applications;
  • Key/Value Store (come Membase, Redis): la struttura dati di memorizzazione è una Hash Table (coppia chiave-valore). Indicate per sistemi di caching o Hash Table distribuite;
  • Graph Data Store (come Neo4J, InfoGrid, OrientDB). Il modello di programmazione è il grafo e l’accesso ad archi e nodi avviene attraverso algoritmi di ricerca su grafo. Tipicamente si usano nei social network.