In het verleden heb ik vaak IBM bekritiseerd vanwege het uitblijven van ‘slanke Cics-clients’ die het gebruik van 3270 terminal applicaties op pc-clients en grafische gebruiker interfaces mogelijk maken.
Big Blue is echter niet de enige boosdoener. Ook Digital Equipment (DEC), in die tijd nog een geduchte concurrent, heeft nooit de moeite genomen om zijn VAX/VMS-systemen te gebruiken als servers voor pc’s. Hetzelfde verwijt geldt voor Unix-systemen. Unix was in feite een logische keus als beste systeem voor netwerkservers en pc-clients. Hierdoor zouden er ruime mogelijkheden zijn wat betreft hardware, schaalbaarheid en een mix van lage kosten, legacy en Ascii terminal-applicaties met pc-clients. Het was dé weg om een evolutionair in plaats van revolutionair pad te bewandelen.
In plaats van zelf de pc/lan-markt te promoten gaven terminalspecialisten als HP, Sun en andere deze weg. In eerste instantie aan Novell met Netware, dat weer opzij werd gezet door Windows NT. Daardoor slaagde Microsoft erin de markt te controleren en, ondanks alle tekortkomingen, direct met Unix te concurreren.
Netware was een eenvoudige bestandsserver (overigens een basiselement van Unix) en totaal ongeschikt voor de rol van databaseserver, laat staan applicatieserver. Ontwikkelaars werden daardoor gedwongen te improviseren en applicaties te ontwikkelen op ‘zware client’-architectuur. Geen enkele ervaren ontwikkelaar zou deze fout ooit hebben gemaakt. Bovendien konden ze geen gui-interface maken. Het gevolg was dat gui-gereedschappen overheersten en werden uitgebreid met mogelijkheden om applicatielogica te coderen voor de pc. Veel van deze toepassingen draaiden databasebeheersoftware op de client, maar deelden alleen de simpelste bestanden. Normaliter werden deze vervangen door toepassingen die een universele relationele database deelden.
Helaas is dit niet genoeg, maar altijd nog beter dan bestanden delen. Het delen van bedrijfslogica op een server is noodzakelijk. Dat is vaak genoeg bewezen in oudere, op een host gebaseerde, applicaties. Alle ervaring uit het verleden werd gewoon weggegooid.
Het ergste moest echter nog komen. Een ‘zware client’-toepassing eist een client-programma om de interface tussen bedrijfslogica en toegang tot de database in één programma te realiseren. Dit zou kunnen werken voor een simpele toepassing, maar de pc-fanatici richtten zich op het ontwikkelen van bedrijfskritische applicaties. Waar zijn experts in gebruikersinterfaces, bedrijfsregels en database-ontwerp te vinden?
Nergens, want ze bestaan niet. Ontwikkelen van grote applicaties is puur teamwerk. Het is wel mogelijk om delen van ‘zware client’-software toe te schrijven aan specifieke leden van het ontwikkelteam, maar dat is onnodig moeilijk. Bij een ‘slanke client’-architectuur ligt dat anders. Daar zijn de benodigde vaardigheden verdeeld en is Pietje of Jantje snel gevonden.
Het ontwikkelen van applicaties in zware client architectuur is dus moeilijk en onnodig complex. De problemen bij implementatie zijn daardoor nog groter. Hoe kan de code getuned worden? Hoe ga je te werk bij netwerkoverbelasting? Hoe vind je fouten?
Het kan niet erger, denkt u. Sorry, het kan wel erger. We zijn nu namelijk aangeland bij de fase dat ‘zware client’-programma’s, meestal geschreven in Visual Basic of C, vragen om onderhoud. Er zullen namelijk in de code onvermijdelijk wijzigingen moeten worden aangebracht. De oorspronkelijke ontwikkelaars zijn echter niet meer te vinden. Als je ze vindt, is het maar de vraag of zij genoeg kennis in huis hebben om het probleem alsnog op te oplossen.
Als u dus dacht dat mainframeprogramma’s een ‘legacy’ probleem zin, vergeet dat dan. Die problemen zijn triviaal vergeleken met de ‘legacy-nachtmerrie’ die ‘zware client’-applicaties teweeg brengen.< BR>
Martin Healey, pionier ontwikkeling van op Intel gebaseerde computers en c/s-architectuur. Directeur van een aantal it-bedrijven en professor aan de Universiteit van Wales.
