Ik ben op zoek naar een onderbouwde verklaring waarom XML en aanverwant XSL voor ieder ict-probleem als oplossing naar voren wordt geschoven. Wanneer kan ik de klant een compliment geven voor zijn keus voor XML?
De vergelijking met de magnetron in de jaren '80 is frappant. Toen werd de magnetron voor iedere kookklus naar voren geschoven inclusief de bijbehorende accessoires voor het bruinen van vlees, bakken van een ei, etc.
Momenteel zien we niet alleen XML en XSL in de web- en soa-wereld, maar leveren meer en meer bedrijven hun gegevens aan in XML-formaat voor massaverwerking. Niet omdat dit effectief en efficiënt is, maar omdat de bedrijfsarchitect XML heeft voorgeschreven als de bedrijfsstandaard. Ja, die architect die zelf nog nooit één regel code heeft geschreven of voor een projectdeadline wekenlang nachten en weekeinden heeft door moeten halen en ook geen rekening heeft gehouden met het feit dat de processorcapaciteit in nachtelijke uren voor alle batchprocessen al volledig gebruikt wordt.
Kortom, wanneer is XML wél een goede keus en wanneer niet?
Het feit dat iedereen het doet is niet genoeg voor mij. Dat tagging een goede keus kan zijn voor het web (html) kan ik in meegaan. Echter, volgens mij is XML het slechts denkbare formaat voor gegevensuitwisseling en interfaces. De hoeveelheid bytes die nodig zijn voor de tags is een veelvoud van de daadwerkelijke informatie. Het feit dat het gelezen kan worden door niet-ict-mensen is volgens mij een argument wat geen houd snijdt. Welke niet -ict'er leest een XML? XML is niet een standaard. Dat je een tag kunt beschrijven in een XSD geeft volgens mij niet meer voordelen dan een simpele binaire pointer/lengte-structuur terwijl deze laatste veel efficiënter is. Google bewijst dit met zijn Protocol Buffers en daarvoor was het Corba’s IOP. De benodigde processorcapaciteit voor het valideren en parsen van de XML maakt het tot CPU-intensieve en zeer langzame oplossing. Kortom, XML is niet gemakkelijk, goedkoop, simpel en robuust. XML is een hype en niet in overeenstemming met de realiteit, maar dit is niet de schuld van XML.
Ps. Ik hoef geen uitleg over XML, XSL, XSD ik ben op zoek naar onderbouwde verklaringen en geen lege claims.
Mooie benchmark app om XML / binaire transmissie te vergelijken: http://www.jamesward.com/census/
Freddie,
De grote voordelen van XML zitten voor mij in het feit dat XML niet aan een platform gebonden is en dus een simpel medium is om data over te zetten tussen heterogene systemen. Sterker nog, XML stelt zo weinig platformeisen dat je een service met XML communicatie kunt bouwen zonder precies je afnemers te kennen.
Je noemde JSON als een alternatief; dat kan ongetwijfeld wel. Maar als een van beide kanten van een communicatielijn niet een JavaScript engine is, zou ik er minimaal tweemaal over nadenken om JSON te gebruiken.
Belangrijk succes element van een standaard is dat deze breed gedragen wordt. Fundamenteel als het om uitwisseling gaat. Dat is XML nog als geen ander gelukt, dat kan je niet onderschatten. HTML is niet optimaal en schiet te kort met wat we tegenwoordig doen.
Dat iedereen het doet is juist essentieel voor het succes. Dat er technisch betere alternatieven zijn is mooi maar het zal breed gedragen moeten worden om succesvol te worden.
Veel alternatieven zijn binnen minder dan handbereik. XML heeft de basis gelegd voor een open en makkelijke manier van gegevens uitwisseling.
Grappig dat je Corba noemt, voorbeeld van een complex mechanisme en daardoor niet zo’n succes.
Freddie gooit de knuppel in het hoenderhok. En de kippen gaan tekeer…
Ik wil het vraagstuk wat generieker formuleren. Ik zie dan even af van losgeslagen bedrijfsarchitecten en de magnetron als panacee. De vragen zijn dan: welk probleem lost XML op, en welke nadelen heeft de oplossing. We beginnen met de nadelen. Freddie benadrukt het grote nadeel van XML: de payload ? de echte inhoud ? is qua omvang een fractie van de totale berichtomvang. Daarmee is meteen duidelijk dat XML niet effici?nt is. Dat is een nadeel wat men moet afwegen tegen de voordelen. En als iemand helemaal niet met dat nadeel kan leven dan is de oplossing in die situatie gewoon niet geschikt. Punt. Iemand die een magnetron aanschaft om een ei te bakken moet niet klagen dat het ei niet te vreten is en dat dus een magnetron een waardeloos product is. En als de marketingafdeling van de magnetronproducent het apparaat voor dit gebruik aanbeveelt moet die producent aangeklaagd worden. Elke oplossing kan men in de verkeerde situatie toepassen, maar dat maakt de oplossing alleen maar slecht in die situatie, niet in zijn algemeenheid. Ik volg daarmee de argumentatie van Marc van Grootel.
Zoals elke oplossing heeft XML ook voordelen. Het feit dat XML niet reeds na een paar jaar een zachte dood is gestorven maar zelfs een grote vlucht heeft genomen doet vermoeden dat men deze oplossing niet kan afdoen als een hype die iedereen maar toepast omdat alle anderen dat ook doen. En er is een voordeel; dat voordeel moet gezien worden in het licht van het probleem: de kwaliteit van berichtgegevens is slechts zeer moeizaam vooraf controleerbaar. Die kwaliteit is belangrijk want we weten dat hoe verder in de procesketen een fout wordt gevonden des te duurder het herstel is.
Het volgende is een re?el geval. Ik krijg gegevens aangeleverd in het CSV formaat. Voordat ik die gegevens ga verwerken wil ik er eerst zeker van zijn dat ze aan de kwaliteitseisen voldoen.
1.Staan de kolommen in de volgorde die is afgesproken.
2.Zijn alle kolommen aanwezig.
3.Hebben de kolommen de afgesproken naam.
4.Behoren de gegevens onder een kolomkop allemaal tot de categorie die de kolomkop duidt (en wat duidt de kolomkop inpnr ook al weer?).
5.Behoren de gegevens onder een kolomkop tot het afgesproken datatype (datum, getal, bedrag, string, enumeratiewaarde!)
6.Daar waar sprake is van 1:n situaties, is het aantal n dan volgens afspraak.
7.Zijn verplichte gegevens allemaal aanwezig.
8.Is het aantal rijen niet groter dan afgesproken.
9.Is de gekozen ?Character Encoding? conform afspraak.
Voor al deze controles moet ik code schrijven. Inderdaad, ik ben geen bedrijfsarchitect en heb me aan projectdeadlines te houden. Ik verwacht dat de leverancier van het bericht de kwaliteit ook controleert; maar omdat die op een ander platform werkt heeft die niets aan mijn code, dus die schrijft (hoop ik) ook code, gebaseerd op onze afspraak over de kwaliteitseisen. En verder ontvang ik natuurlijk niet berichten van slechts een type, maar van vele typen. Dus nog meer code. En verder ontvang ik van meer partijen berichten. Elke maakt (hoop ik) op zijn eigen platform code om het bericht vooraf te controleren. Ik hoop maar dat noch ik, noch mijn leveranciers ooit over hoeven te gaan naar een ander platform, want dan kunnen we weer opnieuw beginnen. Daar is natuurlijk geen geld voor, dus accepteren we de gegevens maar zonder kwaliteitscontrole vooraf; we zien wel wat er verderop in de keten gebeurt. Tenslotte is het onzichtbaar dat de gegevens kwaliteit ontberen…
Dit nu is het probleem wat XML oplost: het maakt kwaliteitcontrole mogelijk. Maar let op, het is niet de *vorm* van XML ? tags toevoegen volgens de voorschriften ? die het ‘m doet. Tags zijn een noodzakelijke voorwaarde om het bericht, de instance in goed Nederlands, te vergelijken met een berichtspecificatie waarin dezelfde tags genoemd worden en waarin in formele taal is weergegeven wat de kwaliteitseisen zijn. De berichtspecificatie krijgt gestalte in een XML Schema. De leverancier en ik downloaden beide een ‘XML engine’ die past op ons platform. Daarmee confronteren we elke instance met het schema. De XML engine vertelt ons waarin niet wordt voldaan aan de kwaliteitseisen.
Dat is heel wat code die niet meer nodig is. Dat levert besparingen op. Een deel daarvan gaat weer op aan het samenstellen van het best wel ingewikkelde XML Schema waarin we onze kwaliteitseisen vastleggen. Maar als we het goed doen kunnen we een XML Schema maken dat de kwaliteitseisen van diverse berichttypen bevat, en dan besparen we weer wat aan onderhoud.
Zonder extra inspanning levert de XML werkwijze ons nog meer voordelen op: 1) We hebben een instrument om de kwaliteitseisen waterdicht te formuleren, want laten we wel wezen: onze vorige afspraak stond bol van de dubbelzinnigheden. 2) we kunnen de instance ‘renderen’ met XSL stylesheets. Daardoor worden berichten met een ingewikkelde structuur voor mensenogen toegankelijk gemaakt. Kleuren en opmaak helpen bij het beoordelen van het bericht. 3) We lopen geen risico meer bij een wisseling van platform.
Pas de XML oplossing vooral *niet* toe in de situatie waarbij vijf miljoen berichten in tien minuten verwerkt moeten worden. Dan krijg je in ieder geval niet het nadeel; maar het voordeel ook niet natuurlijk.
Een opinie met 14 reacties, voor en tegen maar allen voorzien met goede argumenten. Dank voor alle reacties, ik hoop dat wij allen en de vele lezers er iets aan hebben bij de afweging wel of niet XML te gebruiken.
Freddie van Rijswijk vindt XML het slechts denkbare formaat voor gegevens uitwisseling en interfaces en vraagt zich af waarom iedereen er toch voor kiest.
Alle argumenten die in het artikel worden genoemd hebben eigenlijk betrekking op de “fysieke” ineffici?ntie van het XML formaat en dit valt inderdaad niet te ontkrachten. Ik ben het met de schrijver eens dat bij batchverwerking XML niet altijd een voor de hand liggende keuze is. Als er geen communicatie is met andere partijen kan het zelfs soms op sommige platformen een redelijk onzinnige keuze zijn.
De vele open en sluit tags maken het bestand vaak enorm groot. Door het bestand niet te formatteren (bij formatteren komt ieder element op een nieuwe regel en wordt ingesprongen voor nivo’s) kan wel iets ruimte worden gewonnen, soms 50%. Het parsen van XML is natuurlijk lang niet zo effici?nt als de verwerking van fixed-length records of pointer structuren. Als je vroeger op een IBM mainframe met Cobol een XML bestand ging parsen dan was hier nauwelijks ondersteuning voor. Later kreeg COBOL ingebouwde XML ondersteuning. In de tijd dat ik het gebruikte weliswaar nog zonder validatie en namespace support en met de eis dat de complete XML in geheugen moest worden geladen om te kunnen parsen. Tegenwoordig levert IBM z/OS XML system services en daarmee zijn eigenlijk alle beperkingen weggenomen. Het is een zeer effici?nte parser waarmee het ook mogelijk is om het cpu intensieve parsen uit te laten voeren op een soort hulp processor. Dit is goedkoper en houdt de hoofdcpu beschikaar voor andere processen.
De keuze voor XML is echter gebaseerd op andere zaken.
1. Bij het bouwen van een interface of service is het makkelijk om gegevens uitwisseling met de ander partij vast te leggen in een xml schema. Dit is eenduidiger en met meer detail dan een bestand- en record beschrijving in de traditionele vorm, waarbij iedereen zijn eigen manier van vastlegging koos. Het XML schema kan bovendien direct in de bouwfase ingezet worden zonder een vertaalslag te moeten maken. Met XML is de communicatie tussen programmeur, ontwerper en gebruiker een stuk makkelijker geworden; dat vergroot de slagingskans van een project.
Er zijn veel XML tools op de markt. Hierdoor kunnen van de XSD voorbeeld-bestanden of berichten worden gemaakt en de structuur kan ook grafisch worden getoond. Er is geen discussie of de geleverde in- of output wel goed is, omdat deze onafhankelijk van de overige programmatuur gevalideerd kan worden tegen een schema.
2. XML kan op een natuurlijke manier hi?rarchische structuren weergeven. Met andere formaten blijft dit toch altijd een beetje behelpen. Als je fixed-length records hebt draait het al snel uit op het maken van verschillende record-types met voorloop- en afsluitrecords. Structuren die met pointers werken zijn veel minder uitwisselbaar.
3. Ook voor herhalende groepen en “NULL” waarden geldt dat traditionele bestandformaten hier minder inzichtelijk mee omgaan.
4. XML bestanden kunnen gemakkelijker uitgebreid worden met extra informatie zonder dat de verwerkende programmatuur deze direct hoeft te verwerken. Hierdoor kunnen aanpassingen makkelijker worden doorgevoerd. Dit is niet mogelijk in een fixed-length bestand.
5. Tooling en standaarden bepalen vaak de keuze voor XML. Voor een programmeertaal als JAVA geldt dat het werken met XML enorm goed wordt ondersteund. Met behulp van een XML digester kunnen XML elementen en attributen direct naar java objecten worden gemapped. Als je nu een webservice maakt, kies je waarschijnlijk voor SOAP en dus voor XML.
6. De leesbaarheid van XML maakt de uitwisseling makkelijk. Maar ook in de testfase is het makkelijk. Zonder het tellen van posities of een hexadecimale editor is het mogelijk om bijvoorbeeld testbestandjes aan te maken. In het algemeen is XML onderhoudsvriendelijk.
Bovenstaande maakt duidelijk dat XML niet misschien het meest effici?nte formaat is. Maar XML is zeker simpel, robuust, gemakkelijk in de communicatie en de verwerking.
Ik weet waar Freddie geweest is, en zijn inspiratie vandaan heeft. Ik zit met zo’n geweldige implementatie, waarbij XML in de database opgeslagen wordt. Vervolgens wordt deze “bewerkt”.
Zowel opslagtechnisch (20GB/60k entries) als performance-technisch (10k records/uur) een disaster.
Als XML staat voor structuur, betekenis, generiek en ten slotte ook nog nieuw? en internet gerelateerd? dan wordt aan veel ingredienten voor een hype voldaan.
Het gesignaleerde probleem, heeft niets met XML te maken maar alles met de manier waarop we met ons vak bezig zijn. Andere voorbeelden zijn ‘relationeel(van het RDBMS)’ en recent SOA-ESB.
In ons vak – ik moet het helaas bekennen – zijn we nog maar nauwelijks in staat om de stap te maken van:
a. wat zou je er allemaal mee kunnen, naar
b. waar moet je het eigenlijk niet voor gebruiken, en
c. waar moet je het zeker niet voor gebruiken.
Het lijkt beschamend, maar waar wordt in welke cursus aan de startende XML-goeroe uitgelegd dat ‘een magnetron niet het goede hulpmiddel is om een nat huisdier te drogen’.
Elk nadeel ‘heb ze voordeel’ nadenken hierover geeft veel inzicht, vooral ook in je eigen vakmanschap.
Uitdaging: maak uit dit artikel en de talrijke reacties een a, b, c lijstje, inclusief korte motivatie
Genoeg stof voor een serie instructieve artikelen en een e-book.