Bij ieder serieus IT project speelt data uitwisseling een belangrijke rol. Zeker in CMS projecten, zoals Drupal, maar eigenlijk in ieder project waar data bewerking, data verwerking, data uitwisseling en data opslag een rol speelt.
De natuurlijke neiging is om voor een uitwisselingsprobleem een XSD (XML Schema Definition Language) te ontwerpen, om structuur vast te leggen voor de XML bericht semantiek tussen verschillende services. XML staat voor Extensible Markup Language.
Aangezien Drupal grotendeels OO is opgezet ligt het voor de hand om XML te kiezen als standaard om data integratie in Drupal 8 verder vorm te geven. Vanuit de afgelopen DrupalCon conferenties is namelijk duidelijk aangegeven dat het meer dan wenselijk is om Drupal als centrale data integratie hub voor de toekomst te willen positioneren. Vooral natuurlijk binnen grote instellingen en bedrijven waar vele interne en externe data bronnen moeten worden uitgewisseld. En alle data centraal benaderbaar via het Drupal CMS is natuurlijk gewoon een mooie visie!
Vereist is dan wel een beter inzicht in hoe integratie tussen Drupal eigen services, maar vooral tussen externe services gestandaardiseerd moeten worden.
Er zijn veel vergelijkingen gedaan tussen XML, JSON en YAML de afgelopen jaren. JSON staat voor JavaScript Object Notation en is een zeer efficiënte taal om data uitwisseling te standaardiseren. YAML staat voor “YAML Ain’t Markup Language” , maar de afkorting stond ooit voor “Yet Another Markup Language”. YAML is ontwikkeld als beter alternatief voor XML.
Tegenwoordig is gelukkig voor veel architecten duidelijk dat XML niet altijd de beste keus is voor data uitwisseling. Echter vanuit wetenschappelijke hoek, ofwel herhaalbaal objectief onderzoek zijn er helaas weinig deugdelijke resultaten beschikbaar. Op vele blogs en lectuur weet natuurlijk iedereen wat het beste is. Helaas is de werkelijkheid complex, aangezien de keus grotendeels afhangt van de volgende context afhankelijkheden:
- Data sets
- Kennis binnen een organisatie
- Gewenste niveau van flexibiliteit op data sets
- Volwassenheid op SOA en OO denken en doen
- Performance eisen
- Integratie eisen en toekomstige integratie mogelijkheden
- Implementatie taal (zoals C, C++, C#, java, perl, python, javascript, .net, tcl, php, lisp)
In onderstaande tabel zijn enkele elementen vergeleken:
Natuurlijk ontbreken in deze vergelijking het daadwerkelijke data uitwisselingsprobleem. Maar ook beveiligingsaspecten dienen niet onderschat te worden. Beveiliging gaat over data, de wijze waarop data getransporteerd wordt en de parsing van de data. XML is door ontwikkeld met vele beveiligingsextensies voor beveiliging van data objecten tot doorgegeven van authenticatie tokens via een XML structuur. YAML en JSON beveiligingsaspecten liggen meer op het vlak van parsing, waarbij JSON vaak een iets ander risico profiel heeft, aangezien de neiging bestaat om JSON te parsen via een Javascript parser.
JSON is primair ontwikkeld als effectieve en simpele manier om data uitwisseling mogelijk te maken. Veel JSON structuren gaan door parsers en JSON is niet geoptimaliseerd voor mensen om direct structuur te kunnen doorzien. JSON ondersteund goed een simpele hiërarchie die is opgebouwd vanuit associatieve arrays of lijsten. natuurlijk bestaan er ook bij JSON extensies voor het omgaan met object referenties.
YAML is ontwikkeld vanuit oogpunt van menselijke leesbaarheid en uitbreidbaarheid. YAML is dan ook goed voor mensen leesbaar, mede door de verplichte witruimtes in regels om structuur aan te geven. YAML ondersteund default object referenties en relationele structuren. Dit maakt het mogelijk om in YAML net als in XML eenvoudig cyclische datastructuren met diepe hiërarchie vast te leggen.
YAML is geen XML, maar kent door de efficiëntere structuur wel een aantal grote voordelen boven XML. Door de explosie van XML en XML gebaseerde standaarden de afgelopen 10 jaar is het logisch dat om redenen van effectiviteit en performance YAML en JSON meer en meer gebruikt worden.
Zeker bij geavanceerde event driven message driven architectuuroplossingen, waarbij miljoenen berichten in korte tijd verwerkt en doorgestuurd moeten worden is XML door de overhead vaak te kostbaar. Wat wijsheid is voor data integratie blijft echter afhangen het exacte probleem wat moet worden opgelost. Maar gezien de hoeveelheid parsers die XML naar YAML of JSON naar XML en YAML kunnen omzetten is een keus ook weer relatief.