Door de euforie rond Internet zijn de meeste PC’s nu voorzien van een webbrowser. Die verhoogt het nut van de PC met een orde van grootte; hij voegt een informatiedienst toe aan de gevestigde kantoortoepassingen en client/server-applicaties.
De browser biedt echter ook een consistent interface op basis van Html-standaarden en kan in theorie een migratiepad bieden van de PC naar de NC. Hieruit volgt dat het standaard browser-interface met succes in transactiesystemen is toe te passen. Dit geldt evenzeer voor openbare (Internet) als besloten (intranet)-applicaties. Tussen de applicaties zelf zullen grote verschillen bestaan, maar de gebruikte technologie zal sterk overeenkomen.
De trend van dikke naar dunne clients is een andere factor. De browser is een perfect voorbeeld van een dunne client. Dunne clients zijn trouwens ook met conventionele PC-programmeertechnieken te bouwen. De browser is een alternatief voor code die alleen onder Windows draait. Dergelijke code draait alleen op een PC met een Intel-processor en Windows 95 of Windows NT van Microsoft.
De tools voor het bouwen van dunne client/server-applicaties zijn nu redelijk uitgekristalliseerd. Er is een ruime keuze, van specialistische tools voor het partitioneren van code als Dynasty of Forte aan de ene kant, tot gevestigde vierde-generatietalen als Uniface aan de andere kant. Meer conventionele technieken sluiten aan op bestaande vaardigheden; ze maken gebruik van middleware voor ‘remote procedure call’ (rpc). Een simpele Visualbasic client die Cics- of Tuxedo-transacties op de server aanroept, zou voor de meeste organisaties voldoende moeten zijn. Na het ontwikkelen van de transactiemodules op de server is er niet veel verschil meer met oudere, op terminals gebaseerde technieken. De maniakale stormloop op dikke client-architecturen was vanaf het begin gedoemd te mislukken, omdat alles opnieuw moest worden uitgevonden en alle lessen uit het verleden werden genegeerd.
Er is een enorm nadeel verbonden aan het gebruik van browsers, vergeleken met een PC met rpc-middleware: er moeten weer nieuwe tools en nieuwe vaardigheden worden aangeleerd. Een simpel Html-programma kan dramatisch worden verbeterd door middel van dynamische technieken, waarbij een executeerbaar object tijdens ‘run-time’ wordt geladen. Java is daarbij een belangrijke techniek, die overdraagbaar is naar alle client-platforms. Microsoft combineert Java, Html en PC-code in iets dat Activex heet; ze hebben nu zelfs een eigen alternatief voor Java-applets op de markt gebracht, Dynamic Html. Hier schuilt een groot gevaar in, namelijk dat Java en Dhtml worden overschaduwd en we straks weer met dikke clients komen te zitten.
Het volgende probleem is dat de dunne Html-client, met of zonder Java- of Dhtml-extensies, moet worden geïntegreerd met transactiefuncties op de server. Bij echte ‘e-commerce’ Internet-applicaties zijn er uitgebreide faciliteiten nodig voor de beveiliging en de afwikkeling van transacties tussen de klant, de leverancier en de financiële instelling. Dit betekent een investering in Set (‘secure electronic transactions’) en in de vaardigheden die nodig zijn om met de Set-api’s nieuwe applicaties te bouwen. Voor interne applicaties zijn de eisen iets minder ingewikkeld, maar eenvoudig is het nog steeds niet. Er is een server nodig, waarmee meerdere browser-clients op transactiediensten zijn af te beelden.
De meest directe techniek om integratie te bewerkstelligen is het gebruik van een webserver voor de interactie met de browser, met specifieke api’s op de server die Html-pagina’s aanpassen. Html-pagina’s lijken in dit opzicht veel op oude terminal-schermen, zoals bij 3270 BMS in Cics of de schermafhandeling van Cobol runtime-systemen onder Unix. De gelijkenis tussen een browser en een domme terminal betekent overigens niet dat er geen nieuwe vaardigheden en tools nodig zijn!
Rond Java vinden interessante ontwikkelingen plaats: de virtuele Java-machine (jvm) in de browser. Hierbij hoort een interface dat voldoet aan de Corba-standaard (Iiop), zodat Java-applets toegang hebben tot Corba-objecten, en een verzameling uitbreidingen voor rpc-mechanismen zoals Cics en Tuxedo. In deze gevallen wordt de webserver uitsluitend gebruikt om basisschermen te ondersteunen en applets te laden. Html wordt niet gebruikt tijdens run-time, en de server wordt gepasseerd. Zulke ontwikkelingen leiden tot betere prestaties. Ondanks het gebruik van TCP/IP op het laagste niveau (‘sockets’) en Http-standaarden, zijn zulke oplossingen inherent leveranciersspecifiek, met uitzondering van Iiop. Deze ontwikkelingen moeten in de gaten worden gehouden, maar voor het moment lijkt het zeer verstandig om Html en een webserver te gebruiken.
Merk op dat de webserver in dit geval eigenlijk een ‘multi user terminal’-server is. Hieruit volgt dat er een applicatie moet komen om Html-code aan databases en legacy-applicaties te koppelen. De aanname dat Html-code één op één kan worden afgebeeld op SQL is naïef, al kunnen interfaces tussen Html en Odbc/Jdbc zeer nuttig zijn. Investeer dus in een ontwikkeltool, zodat de applicatie kan worden ontwikkeld voor een standaard interface (cgi) of voor specifieke, snelle api’s die met server-producten worden meegeleverd, zoals Iiapi, Nsapi en Active Server Pages.
