"In tegenstelling tot wat Martin Healey schijnt te denken, is de keuze tussen lichte- en zware client niet gegeven door het onderscheid tussen één-gebruiker- en bedrijfstoepassingen", reageert Gerard op Healeys column (Computable, 12 december 2003).
Uiteraard is de basisveronderstelling voor alle programmatuur dat deze door professionele ontwikkelaars wordt gebouwd. Een kenmerk van professionele ontwikkelaars is dat ze zelf nadenken over de structuur van hun programma, en deze optimaliseren voor de gewenste functionaliteit binnen de context van de te gebruiken omgeving.
Het sterk leunen op ‘de huidige trend’, de definitie van ‘een echte browser-client’, of het propageren van specifieke producten als standaardoplossing is juist geen kenmerk van de professionele ontwikkelaar, maar volgens mij eerder tekenend voor de enthousiaste amateur. Daarnaast is het noemen van de bekende beheernachtmerrie als reden om voor een lichte client te kiezen (om daarmee de behoefte aan beheer te verminderen) een vorm van het paard achter de wagen spannen.
Puinruimen
Als we al deze zaken stuk voor stuk onze aandacht schenken, zien we het volgende. De problemen met beheer worden in eerste instantie veroorzaakt door de volstrekt inadequate wijze waarop het pc-platform, en dan specifiek de systeemsoftware daarop, mogelijkheden voor beheer heeft geïmplementeerd. De huidige problemen met het beheer van pc’s worden onder meer veroorzaakt door de sterke neiging van Windows (en van IE) om deze omgeving te vervuilen zonder goede mogelijkheden voor gestructureerd puinruimen.
Er liggen twee wegen open om hier wat aan te doen: het volledig vermijden van overmatig gebruik van de mogelijkheden van het platform (altijd kiezen voor lichte client) of het kiezen van een in dit opzicht beter geoutilleerd platform. De eerste keuze is de gemakkelijke, maar minder structurele. De tweede keuze is structureel beter, maar moeilijker uit te voeren: het betekent voorbijgaan aan het op dit punt inherent onvoldoende gekwalificeerde Windows-platform. Voor de goede orde, een keuze voor de betere structuur impliceert niet automatisch een keuze voor lichte client.
De ‘echte browser client’ bestaat niet. De suggestie als zou door het gebruik van Java-procedures de problemen met specifieke pc-instructies tot het verleden behoren is volkomen verkeerd. In alle gevallen praten we over opdrachten die bedoeld zijn voor een specifieke versie van het doelplatform. Intel 80×86-instructies kunnen alleen worden gebruikt op een Intel 80×86 platform, Java-instructies kunnen alleen worden gebruikt op een Java platform. Wel is Java op dit moment als emulatie van de virtuele Java-machine beschikbaar op een aantal verschillende hardwareplatformen, waaronder de Intel-gebaseerde pc. Echter, de verschillende in omloop zijnde versies van Java maken dit geen probleemloos gebeuren. In feite zijn de pc-instructies bijna meer standaard dan de Java-instructies.
Basisprobleem
Het basisprobleem waarvan hier sprake is ligt in een gebrek aan standaardisatie. Bij volledige standaardisatie zou het probleem niet bestaan. Dit is dan wel afgezien van de vraag of volledige standaardisatie wenselijk is. Standaardisatie beperkt al snel de flexibiliteit, en heeft dus grote nadelen als bij volledige invoering.
In de huidige situatie zou het een goede oplossing zijn om alle noodzakelijke procedures beschikbaar te hebben in verschillende versies, functioneel aan elkaar gelijk maar specifiek gericht op één verwerkingsplatform, en verder te accepteren dat niet ondersteunde platformen domweg niet worden ondersteund: ze vallen buiten de standaard set van voor de doelgroep ondersteunde platformen.
Door een juiste inzet van hogere programmeertalen is een dergelijke constructie in principe heel goed te gebruiken. Als iemand zou beweren dat Java hiervoor een prachtige mogelijkheid biedt, heeft deze persoon volgens mij volledig gelijk, maar de mogelijkheden zijn niet tot Java beperkt. Zelfs ‘ouderwetse’ talen als Cobol kunnen in dit opzicht prima voldoen. Wel heeft Java in dit opzicht een voordeel door de ruimere beschikbaarheid van mogelijkheden voor jit-compilatie.
Licht of zwaar
Dan de keuze tussen ‘licht’ en ‘zwaar’. Deze keuze is niet eenduidig op voorhand te bepalen, maar wordt voor iedere stap in de noodzakelijke programmalogica bepaald door de afweging tussen functioneel noodzakelijke onderlinge communicatie en beschikbare verwerkingscapaciteit en functionaliteit. Een professioneel ontwerper zal een programma structureren volgens de principes van maximale cohesie en minimale koppeling. Voor elk van de in dit ontwerp voorkomende blokken functionaliteit moet de keuze worden gemaakt van de optimale verwerkingslocatie. In het ideale (en meest flexibele) geval wordt deze keuze pas gemaakt in executietijd, en speelt het actuele doelplatform een duidelijke rol in de keuze. In de praktijk is het, met de huidige stand van de techniek, nog niet goed mogelijk om dergelijke keuzes uit te stellen tot de executie. De keuze ligt dan, tenminste voor een gedeelte, in het ontwerp vast.
Gebruik van Citrix vermindert het probleem niet op een structurele manier. De hoeveelheid beheer wordt namelijk niet werkelijk verminderd. Het enige wat wordt bereikt is een vermindering van de inspanning die voor het beheer nodig is, doordat alle inspanning gericht is op één systeem. De complexiteit van het beheer, en daar liggen de werkelijke problemen, blijft volledig hetzelfde. Healey geeft zelf al aan dat Citrix de problemen die hij aankaart niet zal verminderen als hij zegt dat de Citrix-client officieel niet als een ‘lichte client’ mag worden gezien, maar integendeel een Windows-display-client is.
Het inzetten van Citrix kan desalniettemin een goede keuze zijn binnen het totale ontwerp, als de randvoorwaarden aangeven dat een Windows-platform voor de eindgebruiker noodzakelijk is, de eindgebruiker zich fysiek op afstand van de server bevindt en het beheer flexibeler moet worden ingericht dan mogelijk is met op afstand beheerde Windows-systemen.
Nadenken
Het inzetten van Citrix is geen panacee voor de problemen die de it tegenkomt. Het uitdragen van dergelijke ‘oplossingen’ zorgt er juist voor dat, zoals Healey zelf al zegt, "de it het prettig lijkt te vinden steeds opnieuw in de problemen te komen".
Om de problemen te boven te komen is vooral discipline nodig. Dat klinkt niet leuk in een tijd waarin ‘vrijheid, blijheid’ nogal eens de toon aangeeft, maar zolang iedereen maar wat kan aanrommelen, blijven er steeds nieuwe problemen opdoemen.
De nodige discipline begint bij het verantwoordelijke management, en loopt door tot en met ontwerpers, ontwikkelaars en beheerders. Het belangrijkste aspect van deze discipline is blijven nadenken (over technisch verantwoorde oplossingen enerzijds, maar een zakelijk verantwoord financieel plaatje daarvan anderzijds), in plaats van zonder nadenken achter de nieuwste hype aanlopen.
Gerard Witter
