Uno sguardo approfondito su JSON e XML, parte 3: XML e il futuro di JSON

Nella parte 2 di questo articolo, abbiamo esaminato più da vicino JSON come interscambio di dati e ne abbiamo valutato i punti di forza e di debolezza per le applicazioni semplici rispetto a quelle complesse. JSON si distingue come il formato leggibile dall'uomo più conciso e compatto, ma la sua semplicità di base può portare a implicazioni indesiderate se utilizzato per casi d'uso complessi. Con JSON come interscambio di dati, gli sviluppatori sono lasciati soli a implementare le funzionalità che mancano a JSON stesso, risultando in soluzioni accoppiate e non standard che cercano di colmare il divario. Per le soluzioni aziendali irremovibili nell'asserire un funzionamento privo di errori, l'uso di JSON può comportare modelli indesiderati che possono ostacolare la qualità del codice, la stabilità e la resilienza del sistema a future incognite. XML offre funzionalità per aiutare le applicazioni a mitigare questo rischio? È possibile ottenere le stesse funzionalità con JSON? Uno sguardo più da vicino all'XML poiché lo scambio di dati rivelerà i suoi punti di forza nella riduzione del rischio software e fornirà agli sviluppatori una migliore comprensione dei modelli che potrebbero aiutare a migliorare la qualità delle loro applicazioni.

Nella parte 3 di questo articolo, faremo:

1. Esplora XML come interscambio di dati e valuta i suoi punti di forza nel supportare requisiti complessi.
2. Discuti del futuro di JSON ed esplora soluzioni che portano i punti di forza di XML in JSON per consentire agli sviluppatori di creare software più stabile e più resistente a bug e futuri sconosciuti.

XML è facilmente etichettato come l'alternativa complessa e dettagliata a JSON. Il sito web w3schools.com, un popolare riferimento per gli standard web, offre solo 58 parole sull'argomento "Perché JSON è meglio di XML" ¹ . Una valutazione così semplicistica di JSON rispetto a XML è fuorviante, perché XML fornisce molto di più del semplice scambio di dati. In effetti, XML non è stato progettato solo per lo scambio di dati, ma piuttosto come linguaggio per specificare linguaggi di markup personalizzati per qualsiasi applicazione. Con la sua semantica rigorosa, XML ha definito uno standard per affermare l'integrità dei dati dei documenti XML, di qualsiasi sottolinguaggio XML. Molti sviluppatori ritengono che "XML non è riuscito ed è stato sostituito con JSON", ma questo non potrebbe essere più lontano dalla verità. Originariamente, XML doveva essere utilizzato per tutti i problemi di interoperabilità dei dati e fino ad oggi rimane "il formato più utilizzato al mondo per la rappresentazione e lo scambio di informazioni". ²

JSON è semplice e XML è potente

Nella parte 2 di questo articolo, abbiamo esplorato lo scambio di dati che coinvolge i contratti guidati dai consumatori (CDC), l'evoluzione del protocollo e la convalida dei messaggi. Con JSON come interscambio di dati, il nostro esempio, la Banca europea, è stato sfidato a fornire una soluzione a rischio ridotto per lo scambio di dati con i rivenditori. La banca desiderava modelli software che si traducessero in un basso accoppiamento, un'elevata incapsulazione e un'elevata resilienza alle incognite future. Con JSON come interscambio di dati, tuttavia, alla banca sono stati presentati modelli che risultavano nel contrario: basso incapsulamento, alto accoppiamento e una minore resilienza alle incognite future.

Rivisitiamo l'esempio della Banca europea e sostituiamo JSON come formato di scambio dati con XML. I seguenti messaggi XML sono equivalenti al messaggio JSON per ogni tipo di identificatore di conto: SWIFT, IBAN e ACH.

 <message xsi:type="swift" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>CTBAAU2S</code> </message> <message xsi:type="iban" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>DE91 1000 0000 0123 4567 89</code> </message> <message xsi:type="ach" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>379272957729384</code> <routing>021000021</routing> </message>

Nonostante l'immediata perdita dell'efficienza del conteggio dei byte grezzi, XML giustifica la sua verbosità supportando un ambito più ampio che circonda lo scambio di dati. Codificando i dati con JSON, siamo stati in grado di risolvere i requisiti immediati dell'interscambio di dati, ma nulla per supportare più varianti di messaggio o la loro convalida. Per affrontare l'ambito dei contratti guidati dai consumatori, gli sviluppatori dovrebbero implementare un codice personalizzato che risulterebbe in un accoppiamento logico tra il formato del messaggio, il suo contenuto e l'implementazione funzionale per la sua elaborazione. In alternativa, lo sviluppatore può scegliere di mettere insieme un puzzle di una raccolta di librerie e framework per soddisfare i requisiti più elevati. Entrambi gli approcci si traducono in una cipolla di livelli sopra lo scambio di dati che sono accoppiati direttamente all'applicazione. Codificando i dati con XML, invece, siamo in grado di risolvere molti spostamenti dei requisiti senza l'accoppiamento.

Gli equivalenti dei messaggi XML utilizzano due caratteristiche particolari dello standard XML: spazi dei nomi e tipi di istanza. L'attributo xmlns="urn:bank:message" specifica lo spazio dei nomi del messaggio e l'attributo "xsi:type" specifica il tipo di istanza, come "swift" , "iban" o "ach" . Questi due attributi sono standard XML che consentono a un elaboratore di messaggi di identificare il tipo del messaggio e di dereferenziare lo schema che definisce le regole di convalida.

Lo schema XML rappresenta la chiave di differenziazione tra JSON e XML. Con uno schema, uno sviluppatore può incapsulare la definizione normativa del formato del messaggio in un supporto separato dall'applicazione e definire vincoli di valore fornendo regole di convalida applicate dai processori XML. Uno schema di esempio per la Banca Europea (con namespace: xmlns="urn:bank:message" ), completo di descrittori di tipo e vincoli di valore, è il seguente documento XML Schema (XSD):

 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns="urn:bank:message" targetNamespace="urn:bank:message"> <xs:complexType name="format" abstract="true"/> <xs:complexType name="swift"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="iban"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="ach"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\w{1,17}"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="routing"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\d{9}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="message" type="format"/> </xs:schema>

Questo schema XML è logicamente equivalente alla isValid(message) della Parte 2. A prima vista, questo schema XML è considerevolmente più dettagliato di isValid(message) . La differenza fondamentale tra i due, tuttavia, è che isValid(message) è accoppiato all'applicazione e lo schema XML no. Lo schema XML è un linguaggio per esprimere vincoli sui documenti XML e ci sono diversi linguaggi di schema ampiamente utilizzati, i principali dei quali sono: definizioni di tipo di documento (DTD), Relax-NG, Schematron e definizioni di schema XML W3C (XSD ). ³ Per la Banca europea, lo schema XML fornisce una soluzione a rischio ridotto per requisiti di livello superiore senza l'accoppiamento.

Uno schema XML comporta un rischio software inferiore. Con XML, le regole per la convalida dei messaggi sono espresse in un linguaggio schema che è disgiunto e quindi non accoppiato all'applicazione. Poiché lo schema XML è completamente staccato dal sistema, il significato logico del formato del messaggio e l'implementazione funzionale per la sua elaborazione sono disaccoppiati. Lo schema XML fornisce alla Banca europea un livello incapsulato che è l'unico responsabile del contesto della convalida dei messaggi, della variabilità, del controllo delle versioni e altro ancora.

Lo schema XML rappresenta la definizione normativa del contratto guidato dal consumatore. Per la Banca europea, ciò fornisce un approccio di mitigazione del rischio per ridurre $\xi_0$ più vicino a 0. Poiché lo schema è disaccoppiato dalla banca e dal rivenditore, entrambe le parti possono utilizzarlo per convalidare e far rispettare il contratto.

Perché lo schema XML è così dettagliato?

La specifica dello schema XML fornisce agli sviluppatori un linguaggio per implementare modelli strutturali e logici utilizzati per definire e vincolare tutte le parti costituenti di qualsiasi documento XML. Con uno schema XML, gli sviluppatori sono in grado di incorporare un significato più profondo in ogni parte strutturale e logica di un documento XML. Ad esempio, lo schema XML consente:

1. Definizione dei vincoli di espressione regolare per le stringhe costituenti,
2. Definizione di intervalli e formati per i numeri costitutivi,
3. Definizione di elementi costitutivi e attributi obbligatori e facoltativi,
4. Definizione dei requisiti chiave e di riferimento in un documento, e molto altro ancora.

Con uno schema XML, un sistema può fare affidamento su validatori XML generici per affermare la validità di ciascun messaggio di input, riducendo intrinsecamente lo "spazio errore" $\xi_0$ più vicino a 0 e isolando automaticamente la logica aziendale da input errati.

Il rischio di sviluppo futuro

I sistemi possono utilizzare le caratteristiche intrinseche della specifica XML per ridurre il rischio di sviluppo futuro del software. Accordando un contratto normativo sotto forma di schema XML, i sistemi definiscono le regole ei vincoli per tutti gli oggetti e le proprietà (elementi e attributi, per XML) da scambiare. I sistemi sono quindi in grado di sfruttare l'ambito più ampio delle specifiche XML per affrontare la variabilità dei messaggi, il controllo delle versioni del protocollo e la convalida del contenuto. Ad esempio, gli spazi dei nomi XML forniscono ai messaggi XML le informazioni necessarie per:

1. Identifica la versione del messaggio.
2. Dereferenziare lo schema contrattuale normativo.
3. Convalida la correttezza di un documento.

Con l'ampia gamma di caratteristiche e capacità offerte dallo schema XML, la maggior parte dei complessi requisiti relativi allo scambio di dati possono essere risolti con lo stesso XML. Questo è ciò a cui si riferiva il dottor Charles Goldfarb quando disse "[XML è] il Santo Graal dell'informatica". ⁴

Lo schema XML aiuta le applicazioni a essere resilienti agli errori e malleabili alle modifiche future.

XML è una specifica ampiamente accettata e accuratamente controllata con innumerevoli librerie disponibili per tutte le piattaforme per facilitare l'elaborazione e la convalida dei documenti XML. Con XML come formato di scambio dei dati, uno sviluppatore è in grado di risolvere i requisiti immediati, nonché quelli relativi ai contratti guidati dai consumatori, alla variabilità dei messaggi, al controllo delle versioni dei protocolli e alla convalida dei contenuti. XML consente a uno sviluppatore di coprire il rischio di requisiti complessi e, soprattutto, di future incognite.

XML è molto più dello scambio di dati e può essere utilizzato per risolvere problemi molto più gravi rispetto a JSON. Se visto da questa prospettiva, l'ambito dell'XML copre una parte maggiore dell'onion, per cui molti dei livelli dell'onion sono contenuti nell'ambito dell'XML stesso.

Quando si sceglie il miglior formato di scambio di dati per un'applicazione, è solo il centro della cipolla a cui teniamo o è la cipolla nel suo insieme?

Le differenze fondamentali tra JSON e XML

XML offre molto di più dello scambio di dati e può essere utilizzato per risolvere problemi molto più gravi rispetto a JSON. L'ambito dei requisiti complessi relativi allo scambio di dati è soddisfatto da XML, consentendo ai sistemi di utilizzare librerie e framework conformi a uno standard, disaccoppiati dall'applicazione.

XML è una specifica che affronta l'ambito di requisiti complessi in base alla progettazione ed è uno standard definito dal W3C e supportato da tutti i fornitori di software e piattaforme linguistiche pertinenti. Utilizzando XML come scambio di dati, le applicazioni traggono automaticamente vantaggio da una riduzione sistematica del rischio software.

Il futuro di JSON

JSON è innegabilmente qui per restare. Con JavaScript come la piattaforma di sviluppo più utilizzata oggi, JSON è diventato il formato di scambio di dati più importante. Per piccoli progetti con bassa complessità, JSON è perfetto. Ma mentre ci sforziamo di creare applicazioni più grandi e migliori per il futuro, la complessità generale del nostro software è destinata ad aumentare. Con le potenti capacità di XML come esempio, diversi gruppi hanno cercato di inventare standard simili per JSON.

La carenza fondamentale di JSON è la sua mancanza nel fornire uno standard generale per la descrizione normativa dei costituenti logici dei suoi documenti.

Schema JSON

Nel 2009, un gruppo ha avviato lo schema JSON ⁵ , che è un vocabolario per annotare e convalidare documenti JSON. Lo schema JSON utilizza la semantica JSON per definire un insieme di regole e vincoli per i componenti dei documenti JSON e diversi progetti su varie piattaforme hanno implementato librerie che supportano la specifica dello schema JSON. Sebbene non sia ancora uno standard ufficiale, il progetto dello schema JSON fornisce una soluzione per un ambito di requisiti simile alla specifica dello schema XML. Con il vocabolario dello schema JSON, gli sviluppatori possono definire le regole e i vincoli logici e strutturali dei documenti JSON. Lo schema può quindi essere utilizzato per facilitare l'elaborazione e la convalida di documenti JSON con librerie disaccoppiate dall'applicazione, riducendo così la necessità di codice non incapsulato da mischiare nell'applicazione. Con lo schema JSON, uno sviluppatore può scegliere JSON come formato del suo interscambio di dati e affrontare, in modo ridotto il rischio, i complessi requisiti non precedentemente affrontabili con il solo JSON.

Il progetto dello schema JSON è uno sforzo della comunità e, dopo un decennio di revisioni, rappresenta la specifica prevalente per gli schemi JSON. Sebbene non sia ancora uno standard, la popolarità del progetto dello schema JSON indica il livello di interesse per tale soluzione. Concettualmente, la specifica dello schema JSON assomiglia allo schema XML, ma un confronto tra i due rivela differenze tra i loro modelli, capacità e semantica. Ad esempio, sebbene il linguaggio definisca un'ampia gamma di proprietà per vincolare i limiti dei tipi di valore JSON, i suoi numerosi attributi consentono l'espressione di definizioni di schemi contraddittori.

Ad esempio, il seguente estratto definisce un tipo "object" che contiene tre proprietà: "number" , "street_name" e "street_type" .

 { "type": "object", "properties": { "number": { "type": "number" }, "street_name": { "type": "string" }, "street_type": { "type": "string", "enum": ["Street", "Avenue", "Boulevard"] } } }

La definizione di un tipo "object" accetta vincoli aggiuntivi, uno dei quali è "minProperties" . Modificando la definizione di tipo "object" sopra con un "minProperties": "4" , la definizione diventa priva di senso, perché solo tre proprietà sono definite in modo esplicito per l'oggetto.

Lo schema JSON ha un numero considerevolmente ampio e ampio di proprietà di vincolo, molte delle quali sono essenziali per confinare efficacemente i documenti JSON e molte delle quali si sovrappongono l'una all'altra. Con proprietà di vincolo che si sovrappongono nel significato, il vocabolario dello schema JSON presenta due famiglie di sfide:

1. Richiede una curva di apprendimento più elevata da parte degli sviluppatori, a causa dell'ampio vocabolario e delle sfumature insolite o non convenzionali nella sua semantica.
2. È più difficile da implementare per le librerie di convalida, portando a soluzioni che implementano le aree grigie in modo diverso, risultando in implementazioni incoerenti.

Il linguaggio dello schema XML di per sé non è completamente esente dal consentire l'espressione di definizioni contraddittorie, ma sono molto meno numerose e limitate. In effetti, la specifica dello schema XML è stata sviluppata prestando molta attenzione sia alla facilità d'uso per gli sviluppatori che alle librerie che implementano la specifica. Inoltre, il progetto dello schema JSON definisce solo la specifica del linguaggio dello schema, ma esistono molti progetti della community che implementano questa specifica.

Il validatore di schema JSON ⁶ è un progetto popolare che implementa un validatore di schema JSON per la piattaforma Java. Integrando questa libreria in un'applicazione Java, l'applicazione è in grado di affermare la conformità di tutti i documenti JSON scambiati. Altre implementazioni della specifica dello schema JSON sono disponibili per una varietà di piattaforme.

Per la Banca europea, utilizziamo lo schema JSON per implementare uno schema per i messaggi JSON con identificatori di account.

 { "$schema": "http://json-schema.org/draft-07/schema#", "definitions": { "swift": { "type": "object", "properties": { "type": { "type": "string", "pattern": "swift" }, "code": { "type": "string", "pattern": "(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}" }, "required": ["type", "code"] } }, "iban": { "type": "object", "properties": { "type": { "type": "string", "pattern": "iban" }, "code": { "type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{0,2}" }, "required": ["type", "code"] } }, "ach": { "type": "object", "properties": { "type": { "type": "string", "pattern": "ach" }, "code": { "type": "string", "pattern": "\\w{1,17}" }, "routing": { "type": "string", "pattern": "\\d{9}" }, "required": ["type", "code", "routing"] } } } }

Questo schema JSON definisce i 3 tipi di oggetto: "swift" , "iban" e "ach" . Specifica i modelli di espressioni regolari per affermare che le informazioni sull'account non sono valide e dichiara "type" e "code" come proprietà richieste per ogni tipo, oltre a "routing" come proprietà richiesta per il tipo "ach" . Con questo schema JSON, la Banca europea può convalidare il proprio input JSON per affermare che il contenuto del messaggio è corretto per ogni interazione.

Lo schema JSON offre molte funzionalità di XML a JSON, ma è ancora un lavoro in corso. Sebbene sia un'ottima soluzione che può essere utilizzata per coprire il rischio software, la specifica dello schema JSON non è perfetta. A causa dell'evoluzione informale della sua lingua, la lingua si è evoluta in una direzione che omette caratteristiche probabilmente importanti e contiene modelli di espressione strutturali e logici che sono confusi e non convenzionali. Ad esempio, al linguaggio dello schema manca la capacità di definire tipi astratti, il che può portare gli sviluppatori a implementare soluzioni alternative complicate che si traducono in un rischio software associato. ⁷

Il progetto dello schema JSON ha apportato un contributo inestimabile ai concetti alla base di un linguaggio dello schema per JSON. Nonostante le carenze nella chiarezza della sua semantica, il linguaggio dello schema JSON è una soluzione versatile che porta molte funzionalità di XML in JSON.

Per uno sguardo più da vicino alla specifica dello schema JSON, fare riferimento a Comprensione dello schema JSON.

JSONx

Nel 2014, un altro gruppo ha avviato il progetto JSONx, che sfrutta direttamente XML per fornire una soluzione altrettanto potente per JSON. Il progetto JSONx è stato creato specificamente per l'azienda e definisce il linguaggio JSON Schema Definition (JSD), che è modellato strettamente sulla specifica dello schema XML. Utilizzando lo schema XML come modello, il JSD definisce modelli strutturali e logici che hanno una stretta somiglianza con il linguaggio di definizione dello schema XML.

Per l'esempio della Banca europea, utilizziamo il linguaggio JSD per implementare uno schema per i messaggi JSON con identificatori di account.

 { "jx:ns": "http://www.jsonx.org/schema-0.3.jsd", "jx:schemaLocation": "http://www.jsonx.org/schema-0.3.jsd http://www.jsonx.org/schema-0.3.jsd", "message": { "jx:type": "object", "abstract": true }, "swift": { "jx:type": "object", "extends": "message", "properties": { "type": { "jx:type": "string", "pattern": "swift", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?", "nullable": false, "use": "required" } } }, "iban": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "iban", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?[\\d]{0,2}", "nullable": false } } }, "ach": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "ach", "nullable": false }, "code": { "jx:type": "string", "pattern": "\\w{1,17}", "nullable": false }, "routing": { "jx:type": "string", "pattern": "\\d{9}", "nullable": false } } } }

A prima vista, lo schema JSD è simile nell'espressione allo schema JSON. Una differenza, tuttavia, è la semantica concisa del JSD rispetto allo schema JSON. In particolare per questo esempio, JSD inserisce la proprietà "use": "required" nella definizione specificata, mentre lo schema JSON associa questa proprietà all'oggetto padre, richiedendo che il nome dei valori corrisponda al nome della definizione della proprietà. Il vincolo "use": "required" è specificato solo sulla proprietà "code" dell'oggetto "swift" e omesso dagli altri perché "use": "required" è il valore di default. Il linguaggio JSD è stato progettato tenendo in stretta considerazione tutte queste sfumature e offre una soluzione pulita e intuitiva per l'espressione di schemi JSON.

Fin dall'inizio, una proprietà distintiva del progetto JSONx è il suo intento principale di fornire chiarezza e utilità agli sviluppatori. Per raggiungere questo obiettivo, una potente caratteristica di JSD è la sua convertibilità in JSDx: il linguaggio JSD può essere espresso in file JSON oltre che in file XML. Entrambi i moduli sono traducibili uno a uno e offrono agli sviluppatori la possibilità di utilizzare strumenti di modifica XML avanzati per aiutare nella creazione di documenti JSD da convalidare in tempo reale e privi di errori.

Lo schema JSD di cui sopra può essere espresso nella seguente forma JSDx:

 <schema xmlns="http://www.jsonx.org/schema-0.3.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jsonx.org/schema-0.3.xsd http://www.jsonx.org/schema-0.3.xsd"> <object name="swift"> <property name="code" xsi:type="string" pattern="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?" nullable="false" use="required"/> </object> <object name="iban"> <property name="code" xsi:type="string" pattern="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}" nullable="false"/> </object> <object name="ach"> <property name="code" xsi:type="string" pattern="\w{1,17}" nullable="false"/> <property name="routing" xsi:type="string" pattern="\d{9}" nullable="false"/> </object> </schema>

Il modulo JSDx di JSD è potente perché fornisce una specifica chiara, autoconvalida e a rischio ridotto per la definizione di schemi JSON.

Il linguaggio JSD è progettato per affrontare i problemi di definizioni contraddittorie e si basa su modelli standard per l'espressione dei vincoli. Progettate in stretta somiglianza con il linguaggio XSD (XML Schema Definition), le dichiarazioni di tipo JSD e le definizioni dei vincoli hanno una stretta somiglianza con strutture equivalenti in XML. La specifica JSD(x) fornisce una soluzione completa per la definizione di vincoli strutturali e logici, ed è autodescrittiva, fornendo una definizione normativa del linguaggio JSD(x) espresso nel linguaggio JSD(x) stesso. Per uno sguardo più da vicino alla specifica JSD(x), fare riferimento a JSON Schema Definition Language.

Oltre al linguaggio JSD(x), il progetto JSONx fornisce implementazioni di riferimento di processori e validatori JSD(x), nonché un'API di associazione di classi e un generatore di codice per la piattaforma Java. Con l'API di associazione e il generatore, uno sviluppatore può utilizzare uno schema JSD(x) per generare automaticamente classi per le definizioni degli oggetti nello schema desiderato, che possono essere utilizzate per analizzare e effettuare il marshalling di documenti JSON conformi allo schema. Le classi generate forniscono un'associazione fortemente tipizzata tra lo schema e la piattaforma Java, che rappresenta l'utilizzo, i vincoli e le relazioni specificati nello schema. Con collegamenti fortemente tipizzati allo schema, l'applicazione riduce ulteriormente il rischio software relativo a modifiche future che potrebbero causare incompatibilità.

Sfruttando il compilatore Java, i binding fortemente tipizzati individuano le incompatibilità con gli errori in fase di compilazione, riducendo di fatto il rischio di bug relativi all'elaborazione dei messaggi vicino a zero. Questo modello di progettazione consente agli sviluppatori di implementare modifiche e risolvere le incompatibilità in modo rapido e sicuro, non dovendo fare affidamento sul runtime per trovare bug o casi di errore e soprattutto non dovendo fare affidamento sugli utenti per inciampare nei bug stessi. L'API di collegamento è implementata con annotazioni Java, che consentono a qualsiasi classe di essere associata a uno schema JSD(x) con tipi forti, ma in modo leggero. Le funzionalità di binding e generazione di codice fortemente tipizzate di JSONx supportano l'intero ambito della specifica JSD(x), progettata specificamente per soddisfare gli standard elevati per le soluzioni aziendali.

Il framework JSONx è stato creato per soluzioni aziendali e offre un elevato standard di qualità e utilità per sistemi complessi, nonché facilità d'uso e convalida degli errori in fase di modifica per gli sviluppatori.

Il motore di collegamento, il processore e il validatore JSD(x) riportano una copertura del test dell'87%, consentendo agli sviluppatori Java di integrare con sicurezza il framework per associare gli schemi JSD(x) alle loro applicazioni Java e codificare, decodificare e convalidare i documenti JSON. Per uno sguardo più da vicino al framework JSONx per Java, fare riferimento a Framework JSONx per Java.

Conclusione

Con uno sguardo più approfondito alla storia delle tendenze web e software negli ultimi anni, possiamo vedere una stretta relazione tra la proliferazione di JavaScript e la popolarità di JSON. Molti articoli e post di blog offrono una prospettiva limitata quando si confronta JSON e XML, portando i lettori a scartare XML come obsoleto e lasciando molti all'oscuro delle potenti capacità che potrebbero aiutarli a migliorare l'architettura del proprio software, la resilienza del proprio software al cambiamento e la qualità generale e stabilità del software nel suo complesso. Con una valutazione più approfondita dei punti di forza e di debolezza di ogni standard, gli sviluppatori possono essere autorizzati a prendere decisioni migliori per i loro progetti.

Come la "catastrofe della divergenza" con l'HTML che ha portato all'invenzione dell'XML, un effetto simile si ottiene in complesse basi di codice che si basano su JSON per lo scambio di dati. La specifica JSON non incapsula le funzionalità immediate che circondano lo scambio di dati, che può portare alla frammentazione della logica nei livelli superiori dell'applicazione. Con XML, tuttavia, gli sviluppatori sono in grado di spingere la complessità che circonda lo scambio di dati ai livelli inferiori dell'applicazione, ottenendo la possibilità di rilevare i bug nelle prime fasi del ciclo di vita dell'applicazione. Soprattutto per i linguaggi compilati, in combinazione con un framework di associazione, le architetture che si basano sull'associazione XML possono ridurre il potenziale di errore relativo ai dati vicino a zero. Per l'azienda, sono queste potenti capacità nella riduzione sistematica del rischio software che rendono XML il "Santo Graal dell'informatica".

JSON è qui per restare e diversi progetti stanno guadagnando slancio per offrire le potenti funzionalità di XML a JSON. Il progetto dello schema JSON offre una specifica dello schema sviluppata dalla comunità che è cresciuta organicamente per supportare un'ampia gamma di attributi e modelli dichiarativi per descrivere e vincolare i documenti JSON. Il progetto JSONx fornisce un linguaggio dello schema di livello aziendale progettato in stretta somiglianza con il linguaggio di definizione dello schema XML e offre sia i formati JSON che XML per la specifica dei documenti dello schema JSON. Con queste specifiche e framework, gli sviluppatori sono in grado di ridurre il rischio software correlato ai requisiti di livello superiore relativi all'interscambio di dati, come i contratti guidati dai consumatori, il controllo delle versioni del protocollo, la convalida dei contenuti e altro ancora.

Le funzionalità avanzate di XML sono state progettate per mitigare il rischio software correlato ai linguaggi di markup. I casi d'uso con JSON non sono diversi e un linguaggio schema è una soluzione collaudata e collaudata per coprire sistematicamente l'ampia gamma di rischi software che circondano lo scambio di dati.

Riferimenti

1. JSON e XML (w3schools.com, dicembre 2016)

2. Il successo mondiale che è XML (W3C, luglio 2018)

3. W3C - Che cos'è uno schema XML? (W3C, ottobre 2009)

4. Internet: un'enciclopedia storica. Cronologia, Volume 3, p. 130 (ABC-CLIO, 2005)

5. Schema JSON (luglio 2008)

6. Validatore di schemi JSON (GitHub)

7. Schema Json e sottoclassi (Horne, marzo 2016)