De eerste euforie over PC-clients voor transactieapplicaties heeft geleid tot de dominantie van het dikke clientmodel. De applicatie draait hierbij op een client-PC en heeft toegang tot een gemeenschappelijke relationele database via een lokaal netwerk. SQL en de noodzakelijke api’s worden hierbij ondersteund door Odbc of vergelijkbare mechanismen.
Het dikke client-programma implementeert dus zowel het grafische interface als de applicatiecode. Op dit punt hadden het gezonde verstand en de ervaring moeten zegevieren en had er een pas op de plaats gemaakt moeten worden. Maar nee. Daar kwam Visual Basic, met fantastische faciliteiten voor het ontwerpen van grafische interfaces. De ontwikkelaar kon een gui tekenen en daarbij code definiëren die moest worden uitgevoerd als er een event werd gedetecteerd (lees: op een knop werd gedrukt enzovoort). Tot zover alles goed. Helaas kon ook de programmacode in datzelfde Visual Basic worden geschreven, en wel door dezelfde programmeur die het gui-interface schreef. Nog erger was dat deze code Odbc moest activeren, waarvoor kennis van SQL en de tabelstructuur van de serverdatabase nodig was.
Al deze code – gui, applicatielogica en databasecode – werd in één Visual Basic-programma gestopt. Het potentiële probleem zat verborgen in de beschikbaarheid van componenten om de gui te ontwerpen. Deze waren zo goed dat gebruikers reuze onder de indruk waren van de flitsende applicaties die razendsnel door een gui-whizzkid in elkaar gedraaid werden – een heel andere benadering dan de klassieke aanpak van de oude automatiseringsafdeling.
Maar wie zijn dan die genieën die alles weten van user interfaces, applicatielogica en databases? Wel, die bestaan niet. Dus ontwierp men prachtige interfaces, maar maakte men een potje van de applicatiecode. Daarna kwamen de professionals erbij. Deze konden het probleem omzeilen door energie in de Visual Basic-programma’s te stoppen. Er verscheen een professionele ontwikkelomgeving waarbij programmeurs in teams konden werken en zowaar ook nog enige controle over de broncode hadden. Hadden we alles maar weggegooid en waren we maar opnieuw begonnen.
Nu pas komen de echte problemen op ons af. Het is onderhoudstijd! De programma’s zijn nu twee tot drie jaar oud en moeten geactualiseerd worden. Monolithische code is al zeer moeilijk te onderhouden als het gaat om een Cobol-programma met eenvoudige interfaces. Door de complexiteit van het gui-interface en zijn nauwe verbondenheid met de applicatielogica enerzijds en de rampzalige syntax van Visual Basic anderzijds heeft deze taal een nachtmerrie op onderhoudsgebied veroorzaakt.
We hebben maar één keus: het dikke clientmodel moet plaats maken voor het dunne clientmodel. In dit geval maakt het niet uit of deze client een browser is (met Html, of opgetuigd met Java-applets) of een PC met VB; waar het om gaat is dat het interface van de applicatielogica wordt gescheiden. Dit is geen technische, maar een organisatorische kwestie. Met het dunne clientmodel kunnen specialisten zich op de gui concentreren, terwijl andere specialisten zich op de logica en database-integratie kunnen storten.
De gui-programmeur kan nu werken met hogere functies die door de server worden geboden. Hij of zij hoeft geen kennis meer te hebben van databases en dergelijke. In dit geval is VB een praktisch hulpmiddel, omdat de taal erg sterk is in presentatie, hierbij geholpen door een rijke verzameling OCX-controls. Daarnaast kan de opbouw van zo’n VB-programma simpel blijven: het roept procedures aan met behulp van RPC-mechanismen zoals DCE en client-interfaces voor TP-monitors zoals Cics, Tuxedo en MTS.
Door de presentatiecode te scheiden van de applicatiecode zijn de eisen die aan de server worden gesteld niet veel anders dan bij huidige conventionele TP-systemen. Herbetreedbaarheid van code (voor multi-user ondersteuning), beveiliging, foutherstel en schaalbaarheid zijn geen nieuwe concepten; ze worden in TP-applicaties al jaren toegepast.
Nu komt de Luddite (*) in mij boven: ik denk dat we beter af zijn met oude Cobol-programma’s in combinatie met een TP-monitor. Geen oude monolithische Cobol-programma’s, maar goed ontworpen, modulaire routines. Een voordeel van het millenniumprobleem is dat er een hele nieuwe generatie Cobol-programmeurs wordt gekweekt.
C++ zal vanuit de Unix-wereld een sterke greep op de serverkant blijven houden; specialistische vaardigheden voor Oracle (PL/SQL) zullen zeer in trek raken. Microsoft propageert Visual Basic voor de server, maar organisaties zullen toch niet zo wanhopig zijn – of is er werkelijk zo’n tekort aan echte programmeurs?
Verrassend genoeg proberen Sun en IBM nu, met steun van Oracle, om Java op de server te krijgen. Voor applets in browser-clients is Java de beste keus, maar de gedachte dat Java op de server net zulke diensten kan bewijzen als Cobol lijkt wat al te optimistisch. Dit gevoel wordt versterkt door de opkomst van zeer krachtige codegeneratoren zoals APS, Netron en Dynasty, die worden ondersteund door uitmuntende ontwerptools – op basis van het klassieke 3GL servermodel.
(*) Luddite: lid van een groep arbeiders die van 1811-1816 in Engeland protesteerden tegen mechanisering door schade toe te brengen aan fabrieken en machines – vert.
