Databaseserver of applicatieserver?

Het gebruik van Java-applicatieservers, zoals Bea’s WebLogic en IBM’s WebSphere, neemt toe. Voor het ontwikkelen van nieuwe administratieve systemen wordt steeds vaker gekozen voor een Java-applicatieserver draaiend op een SQL-databaseserver. Bij de bouw van dergelijke systemen worstelen veel ontwikkelaars met de vraag welk deel van de applicatie binnen de applicatie- en welk deel binnen de databaseserver hoort te worden geïmplementeerd? Bijvoorbeeld, wie voert de join uit: de applicatie- of de databaseserver? En wie controleert alle integriteitregels?

Een doorsnee administratief systeem bestaat uit drie lagen: de presentatielaag (ofwel de user-interface), de applicatielaag (daar waar de applicatie- ofwel bedrijfslogica draait) en de gegevensopslaglaag. Een applicatieserver is een module waarbinnen de applicatielaag geïmplementeerd kan worden en een databaseserver is verantwoordelijk voor alles wat met gegevensopslag en -raadpleging te maken heeft.

Het algemene advies is om integriteitregels zoveel mogelijk binnen de databaseserver te implementeren. Zeker over primaire- en refererende-sleutels behoort geen discussie te bestaan. Maar ook simpele controles, zoals een minimum en maximum waarde, een verzameling toegestane waarden en de waarde van de ene kolom moet groter zijn dan de andere, dienen door de databaseserver te worden gecontroleerd. Deze integriteitregels zijn eenvoudig met zogenaamde CHECK-regels te definiëren en zijn gestandaardiseerd en dus overdraagbaar.

Het grote voordeel van deze aanpak is dat alle integriteitregels dan gelden voor elke applicatie die de database benadert, dus ook voor een niet-Java-applicatie. Een ander voordeel betreft het onderhoud. Alle integriteitregels worden door de databaseserver in de catalogus geregistreerd en kunnen makkelijk worden bevraagd. Op simpele wijze kan hiermee worden bepaald welke integriteitregels er actueel zijn voor een bepaalde tabel.

Het is tevens aan te raden om diezelfde integriteitregels in de presentatielaag te controleren. Het kan voor gebruikers irritant zijn als ze eerst een heel scherm vol met gegevens invoeren om daarna pas op hun vingers te worden getikt. Het is gebruikersvriendelijker om direct foutieve waarden af te keuren.

Voor de complexere integriteitregels kunnen triggers gedefinieerd worden. Voor triggers geldt helaas wel dat de code niet honderd procent overdraagbaar is. Door echter vanuit de triggers stored procedures aan te roepen en deze in SQLJ te schrijven zal de overdraagbaarheid redelijk zijn. 

Een ander aspect betreft het raadplegen van tabellen. Uiteraard kan zelfs de moeilijkste vraag opgebroken worden in vele kleine SELECT-instructies. De applicatie zelf moet er dan wel voor zorgen dat uit de vele resultaten het werkelijke resultaat gedestilleerd wordt. Deze opzet zien we momenteel veel toegepast worden. Java-programmeurs hebben de neiging om zich bij het raadplegen van de gegevens te beperken tot zeer simpele zoekopdrachten. Kortom, de Java-programmeur creëert de joins zelf. De veelgebruikte argumenten zijn: de onbekendheid met de mogelijkheden van SQL en het gevreesde performanceverlies. 

Vele testen hebben echter uitgewezen dat de performance en schaalbaarheid van een SQL-databaseserver nadelig beïnvloed wordt, als de applicatie zelf de joins uitvoert. Op deze wijze wordt de databaseserver gedegradeerd tot veredeld bestandsysteem waarmee records één voor één kunnen worden opgehaald. Hiermee laten we alle technologie links liggen die onder andere IBM, Microsoft en Oracle in hun producten gestopt hebben. Een oneigenlijk gebruik zal leiden tot een inefficiënt gebruik.

Interessant is ook dat in de meeste Java-applicaties geen gebruik gemaakt wordt van object-relationele concepten, zoals geneste tabellen en tabeltypes. Deze concepten zijn juist toegevoegd voor programmeertalen met objectgeoriënteerde concepten. 

Het algemene advies is simpel: hol de taken van de databaseserver niet uit. Laat de databaseserver doen waarvoor hij bedoeld is en waarvoor deze geoptimaliseerd is. Dus zorg dat de Java-programmeurs op de hoogte zijn van de mogelijkheden van de databaseserver. Het kiezen van een alternatief op basis van te weinig kennis is nooit verstandig.