Client/server-perikelen

Sinds die eenvoudige begindagen is het allemaal veel ingewikkelder geworden, eerst onder invloed van de relationele database en later door het Web. Het helpt ook al niet dat er geen eenduidige definities worden gebruikt.
De meest gebruikte zware client-architectuur is een slechte, uitgedacht door Novell, die daarna werd overgenomen door Microsoft. Netware en Lan Manager deelden gewoon een DOS-bestandsserver, een meervoudig single-userconcept, zonder de benodigde multi-userfunctionaliteit te implementeren. De volgende stap was er een in de goede richting - een gedeelde relationele database die via SQL werd benaderd. Er bleef echter nog steeds te veel gemeenschappelijke functionaliteit achter in de client. Het gebruik van gedeelde procedures in de Rdbms is een beter idee, maar jammer genoeg zijn er geen praktische standaarden en dus werden de toepassingen gekoppeld aan specifieke Rdbms-producten. De algemene, niet-specifieke remote procedure calls - op zich een prima idee - hadden ook te lijden onder het gebrek aan standaarden. Soap kan hierbij helpen, maar komt wel erg laat beschikbaar.
De beste client/serverarchitectuur voor bedrijfstoepassingen bestond uit de koppeling van bestaande 'transaction processing monitors' aan de bestaande transactietoepassingen, en deze aan te roepen vanaf een gui-client. IBM bevond zich in een goede positie met Cics, maar miste de boot door de de factostandaarden (Ethernet en TCP/IP) niet te ondersteunen; tegen de tijd dat de juiste Cics-client eindelijk werd vrijgegeven, was iedereen al bezig met Netware en - in mindere mate - met Unix. Het is ironisch dat een van de toonaangevende Web Application Servers van tegenwoordig, BEA's Web Logic, afstamt van de oude Unix TP monitor Tuxedo.
Hoewel Unix het goed deed in de ontwikkeling van client/servertoepassingen, met name Sun en HP, werd ook daar het potentiële succes niet helemaal gehaald. Een Unix-server, met Sybase, Oracle, et cetera, was (en is) een veel betere server dan een Windows- of Netwareserver. TCP/IP had van begin af aan de standaard kunnen zijn voor Lan's, waardoor de ellende van migratie van Novell- en Microsoft-protocollen was vermeden. Achteraf is het verbazingwekkend hoe goedgelovig de it-industrie was in de begindagen van pc's en Lan's.
Dankzij het Web ging iedereen, zowel gebruikers als leveranciers, de meerwaarde van het lichte clientmodel inzien. Hadden we nu allemaal toch maar aangedrongen op het met Java uitgebreide clientmodel, dan zouden we vandaag de dag minder problemen hebben. Microsoft haalde echter een goocheltruc uit met Active X, waardoor ontwikkelaars clientroutines gingen schrijven die alleen op een Windows-pc werkten. Daardoor werd de charme van specifieke Web browser terminals flink ondermijnd. IBM, Wyse en een aantal anderen boekten successen met deze terminals, waarvan de functionaliteit werd uitgebreid door middel van een Citrix-client, maar ze zijn er nooit zo ver mee gekomen als gewenst vanwege Active X en dus het gebrek aan toepassingen. IBM verergerde een en ander door deze terminals 'lichte clients' te noemen, waardoor er verwarring ontstond met een pc-client die alleen de presentatielogica draait.
En wat is dan een 'intelligente client'? Dat is wat we in de begindagen een lichte client noemden, maar met de mogelijkheid om de gebruikersinterface naar de logica heel geavanceerd te maken, zonder af te doen aan de waarde van een robuuste, gedeelde server die alle communicatie, bedrijfslogica, et cetera. afhandelt. Wellicht dat hiermee het verschil tussen een Web-browser en een pc-lichte client duidelijker wordt.< 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.