XML hoort niet thuis in de database
Auteur: Rick F. van der Lans
Geschreven: november 2001
Gepubliceerd in: CM Corporate.Net, nummer 174

Als we over de Europese snelwegen rijden en links en rechts om ons heen kijken, zien we regelmatig van die halfafgemaakte bouwwerken. Ik denk dan aan pilaren waarop een brug zou moeten rusten, ontboste grond waar een nieuwe weg aangelegd zou worden of een bouwwerk waarvan het doel ons geheel ontgaat. Het zijn de eerste stuiptrekkingen van projecten waarvan bij aanvang gedacht werd dat ze noodzakelijk waren. Echter, door herziene inzichten of door veranderende omstandigheden werd vroegtijdig besloten om het project te staken.
Zo zijn we alweer enkele jaren bezig met het integreren van XML (eXtensible Markup Language) binnen databases. Voor velen lijkt dit nog steeds een goed idee. Als we onze gegevens in de vorm van XML-documenten moeten aanleveren - of wij krijgen ze als XML-documenten binnen - wat is er dan makkelijker dan die XML-documenten ook in de database op te slaan? En wel op een wijze waarbij de XML-structuur bewaard blijft.
Leveranciers als IBM, Microsoft, Oracle en Sybase zijn alle hard bezig om de ondersteuning van XML binnen hun relationele databaseservers te verbeteren. Hiervan zagen we de eerste implementaties al een tijd geleden en nu is de periode voor hun tweede versies aangebroken. Bij deze producten ligt de nadruk op de integratie tussen XML en relationeel. Vandaar dat hun producten als XML-enabled geclassificeerd worden. Andere leveranciers, zoals eXcelon, Ipedo, Tamino en X-Hive, hebben gekozen voor het ontwikkelen van specialistische XML-databaseservers. Deze worden in de literatuur native-XML databaseservers genoemd.
De vraag die iedereen zich stelt, is: 'Wat is beter, XML-enabled of native-XML?' Maar de vraag zou eigenlijk moeten luiden: 'Moeten we de XML-structuur wel in de database opslaan, of hoort zij daar geheel niet thuis?'
Klassiek delen we een applicatie op in drie lagen: de presentatielogica, de applicatielogica en de databaselogica. Vele malen hebben we reeds geleerd dat we in onze systemen deze drie zo strikt mogelijk gescheiden moeten houden. We horen bijvoorbeeld de presentatie- en applicatielogica niet te sterk onderling te verbinden. Het toevoegen van een nieuwe of andere presentatielaag geeft dan problemen. Bijvoorbeeld, met de komst van client/server-technologie zijn wer overgestapt van character-based naar GUI-based applicaties en bemerkten we dat dat alleen elegant kon, als de presentatie- en applicatielaag gescheiden ontwikkeld waren. Een vergelijkbare situatie deed zich voor bij de overgang naar Internet-applicaties met hun HTML-gedreven interface.
De juiste vraag wordt dus: "In welke laag behoort XML nu eigenlijk thuis?" XML is een taal voor gegevensuitwisseling, dus tot welke laag behoort gegevensuitwisseling? Het antwoord op deze vraag is simpel: de presentatielaag. Een presentatielaag wordt aan een applicatie toegevoegd zodat de menselijke gebruiker en de applicatielogica onderling kunnen communiceren. Applicaties die aan gegevensuitwisseling doen, communiceren weliswaar niet met een menselijke gebruiker, maar met een 'softwarematige' gebruiker, namelijk een andere applicatie. De gegevensuitwisseling vervangt dan gewoon de grafische presentatielaag.
Als we de bovenstaande lessen toepassen, kunnen we de volgende conclusies trekken. Als we XML inderdaad voor gegevensuitwisseling inzetten, moeten we dus in de presentatielaag gebruiken en nergens anders. We horen XML dus niet te strak met de applicatielaag te integreren - en zeker niet met de databaselaag! Maar dat is nu precies wat we aan het doen zijn.
Het nut en het voordeel van het implementeren van XML in de databaseserver is wel duidelijk: het maakt het leven van de ontwikkelaar eenvoudiger. Dat was ook altijd de reden waarom we de presentatie- en applicatielagen combineerden: dat was lekker simpel voor de ontwikkelaar. Maar wat als we later beslissen om diezelfde gegevens via een ander formaat uit te wisselen? Dan zitten we direct met een probleem. We moeten dan eerst de gegevens in XML-formaat uit de database halen en vervolgens omzetten naar het geschikte formaat. Allemaal onnodige handelingen.
In de afgelopen jaren hebben we al heel wat XML-technologie aan de databaseserver toegevoegd. De pilaren ofwel de halfafgemaakte projecten staan reeds langs de kant van de weg. Maar wat wordt nu de toekomst? Vertellen we onze kinderen later, met een schamper lachje rond de mond, waarom we dat ooit gebouwd hebben? Dat het een tijdelijke geestelijke dwaling was, en dat we net op tijd tot inzicht waren gekomen? Of gaan we hiermee door en realiseren we ons over vijf jaar dat we een serieuze denkfout gemaakt hebben? Ik ben benieuwd.