Ondanks de browser-hype ben ik nog steeds van mening dat het gebruik van dunne clients de beste manier is om zelf applicaties te ontwikkelen. Op de server draait daarbij een conventionele tp-monitor, die gebruik maakt van herbruikbare componenten, bij voorkeur in Cobol.
Op de PC draait een programma, bijvoorbeeld in Visualbasic, dat de grafische user interface (gui) verzorgt. De client stuurt remote procedure calls (rpc) naar de server-componenten. Een van de voordelen van tp-monitors als Tuxedo, Cics of MTS is dat rpc eenvoudig kan worden geïmplementeerd, namelijk als api van de tp-monitor. Gui-ontwikkeltools dienen dit te ondersteunen.
Onder invloed van het Web is er een alternatief voor de Windows-interface opgestaan. Het is de browser-interface. Deze interface wordt soms aangeduid als een web user interface (wui). Wij noemen het liever een bui (browser user interface) om het te onderscheiden van de look-and-feel van de klassieke PC-gui.
De bui heeft dus een andere look-and-feel, maar is ook gebaseerd op een compleet andere technologie, die niet uitwisselbaar is met het simplistische client/server-model als boven beschreven.
Een gebruikelijke oplossing is om een applicatieserver te draaien die de client tijdens run-time ondersteunt en tegelijkertijd fungeert als interface naar de kernapplicaties. Omdat de applicatieserver is geprogrammeerd met tools die Java en OLE ondersteunen, valt er iets voor te zeggen om ook de kernapplicaties met deze tools te ontwikkelen en ze door middel van Odbc direct op de database aan te sluiten. Transactiediensten werken echter minder goed met een applicatieserver dan met een tp-monitor. Voor Ejb-systemen kun je Java combineren met een tp-monitor, maar dan wordt het allemaal erg ingewikkeld.
Aansluiten op een bestaande applicatie is iets anders dan het ontwikkelen van een nieuwe applicatie. Met enige moeite kan de code worden omgewerkt tot herbruikbare componenten, zoals Cics-transacties of Oracle stored procedures. Dit scheelt een hoop tijd en maakt continuïteit eenvoudiger. Met deze aanpak kan het systeem een groot aantal verschillende gebruikersinterfaces aan: oudere, karaktergeoriënteerde user interfaces, PC-gui’s en -bui’s.
Maar met een totaal nieuwe applicatie is het vreselijk veel werk om de server-componenten te implementeren; hetzelfde geldt voor de gui-componenten, de bui-componenten en de componenten van de applicatieserver.
Bij het upgraden van een bestaand systeem zullen bovendien nieuwe licentiekosten betaald moeten worden voor de nieuwe functies. Het is niet makkelijk uit te leggen dat er voor één systeem meerdere run-time licenties nodig zijn.
In de praktijk zijn er dan ook slechts twee keuzes: (1) ondersteun zowel bui-clients als bui-clients, of (2) ondersteun slechts een bui-interface. Het ontwikkelen van een puur gui-systeem is niet verstandig, omdat je daarmee voorbij gaat aan het potentieel van e-commerce.
De grote vraag is of een bui-interface ook aanvaardbaar is voor de eigen gebruikers, die op een lokaal netwerk zijn aangesloten. De bui-interface is veel minder luxe dan de gui-interface, omdat hij beperkt wordt door de functionaliteit van de browser. Uitbreidingen zoals ActiveX leiden weer tot support-problemen en draaien alleen op een PC; toekomstige client-systemen worden daarmee uitgesloten. Verfraaien van de bui met Java-applets lost de problemen ook niet op, omdat ontwerpers en ontwikkeltools steeds complexere interfaces construeren, met massa’s Java-applets die lang bezig zijn met laden. De bui-interface heeft nog een nadeel, namelijk dat de browser gestart moet worden voordat de applicatie kan worden gebruikt. Omdat de Windows-interface nog steeds gebruikt zal worden voor lokale applicaties, worden gebruikers opgezadeld met twee verschillende interfacestijlen, een gui voor de kantoorapplicaties en een bui voor de zakelijke applicaties. Dat vinden ze misschien niet leuk.
Totdat er een heel nieuwe generatie bui-applicaties is, met name een goede office suite, zie ik geen oplossing voor het dilemma van de twee interfaces. Wie nieuwe functionaliteit aan bestaande applicaties toevoegt, moet zich concentreren op het omsmeden van de oude code naar herbruikbare componenten, waarbij functionaliteit wordt toegevoegd met behulp van Java Beans op de applicatieserver. Ontwikkelaars van pakketten doen hetzelfde, maar ik vrees dat ze daarnaast nog steeds gui-versies zullen moeten uitbrengen.
De les die we leren van de eerste e-commerce applicaties en van de chaos in de wereld van de PC-pakketten is dat eenvoud een kenmerk van het ware is. Vereenvoudig die interfaces, maak ze niet complexer dan nodig. Ergonomie is vandaag de dag een groter probleem dan technologie.
