Wie gebruik maakt van de interactie tussen een browser en een web-server en daarna een interface ontwikkelt om de web-server via cgi (common gateway interface) aan andere systemen te koppelen, heeft een vertrekpunt om transactie-applicaties te bouwen die met een browser te benaderen zijn. De prestaties kunnen echter te wensen overlaten. Met Java-applets zijn zulke faciliteiten eenvoudig te verbeteren.
Het bouwen van Java-applets vereist specifieke vaardigheden. Voor het koppelen van web-sites aan bestaande systemen zijn weer andere vaardigheden nodig. Het basis-interface cgi wordt door alle web-servers ondersteund. Cgi is een primitief interface; programmeurs moeten zowel Html als de desbetreffende applicaties in de vingers hebben.
Er verschijnt dus een groeiende verzameling middleware-producten op de markt; dit zijn software-ontwikkelingstools die aan de ene kant Html en aan de andere kant een heel scala aan oudere systemen ondersteunen.
Het cgi-interface wordt in feite buiten de web-server om geïmplementeerd; hierdoor ontstaat een zekere prestatie-overhead. De normale browsers hebben leveranciersspecifieke, interne api’s. De prestaties worden hierdoor stukken beter, maar deze oplossing heeft als nadeel dat een fout in de applicatie de hele web-server kan platgooien. Het is daarom het beste om de ontwikkeling te laten plaatsvinden op basis van cgi en pas gebruik te maken van specifieke, interne interfaces als de applicatie stabiel gebleken is. Hieruit volgt ook dat de programmeertool cgi moet ondersteunen, alsmede de drie belangrijkste uitbreidingen: Nsapi voor Netscape-servers, Isapi voor Microsoft IIS en Icapi voor IBM’s MVS Internet Connection.
Oorspronkelijk kon het cgi-interface alleen met scripttaaltjes worden geprogrammeerd, zoals Perl en – in IBM-omgevingen – Rexx. Amazon van Intelligent Environment is een interessant product en een relevante ontwikkelomgeving. Amazon gebruikt IE’s AM client/server 4GL als basis en biedt zo toegang tot tal van diensten (Cics, IMS, SQL databases en dergelijke). Amazon werkt echter met Html in plaats van met de oorspronkelijke gui. De applicatie draait op een PC met NT, maakt gebruik van conventionele client/server-technieken en kan worden opgeschaald door meerdere parallelle servers toe te voegen. Het staat nu wel vast dat Java zich zal ontwikkelen tot een algemeen toepasbare ontwikkelomgeving voor servers, ook op mainframes.
Alle belangrijke transactiesystemen hebben toevoegingen aangekondigd om de cgi web-interfaces te ondersteunen. Cics, IMS, DB2, Tuxedo, SQL Server en Lotus Notes zijn nu allemaal voorzien van web-extensies. Ze hebben hun eigen scripttaal waarmee de brug tussen Html en bestaande software kan worden geslagen. Dit zijn geen transparante interfaces; er moeten programma’s voor worden ontwikkeld, applicaties en gegevens voor worden geanalyseerd en specifieke Html-eisen voor worden opgesteld. Het voordeel van een middleware-benadering als Amazon is dat het de kernsystemen via standaard-interfaces toegankelijk maakt, en niet via web-extensies.
Java-applets voor PC en NC zijn momenteel sterk gericht op gui-interfaces voor de eindgebruiker; ze maken gebruik van conventionele Html- en Http-diensten voor de browser. Java-applets kunnen echter ook code bevatten om andere browser-diensten te bieden dan toetsenbord, muis en beeldscherm. Het is belangrijk dat deze nieuwe diensten worden gedefinieerd als standaarden, die uniform in browser-software worden geïmplementeerd. Ze mogen geen marketing-wapens in de handen van Netscape en Microsoft worden. De Java-industrie is zich hier goed van bewust; er zijn al standaarden in ontwikkeling. Laten we hopen dat ze ook worden afgedwongen.
Er zijn enkele extensies aan de client-kant, die een virtuele Java-machine zou kunnen ondersteunen. Omdat de browser de TCP/IP-transportlaag gebruikt, kan Java direct bij de sockets-api, een primitief communicatie-interface, waardoor elke TCP/IP-server kan worden bereikt. Het tweede concept is een SQL-functie, zodat een relationele database via het netwerk kan worden aangesproken. Dit heet Java Database Connect (Jdbc) en is gebaseerd op Odbc. Helaas gaat dit weer terug naar het model van de dikke client, met veel te veel code in de Java-applets. Deze architectuur is verantwoordelijk voor het hoge aantal mislukte client/server-projecten. De meest avontuurlijke benadering is het integreren van Java-applets met een volledig gedistribueerde object-omgeving (Corba). Sun heeft de Java Object Environment (JOE) voorgesteld om browsers met Corba-applicaties te kunnen laten samenwerken. Er zijn een paar specifieke voorstellen die een direct pad van de browser naar de server bieden, zoals Marimba’s Castanet. Een andere interessante variant is ondersteuning voor een standaard RPC-interface (remote procedure call) zoals DCE’s RPC, of, in sterkere mate, Cics- of Tuxedo-clients. Een variant hierop is een eenvoudige uitbreiding van de browser die procedure-calls naar de server stuurt om een multi-user Cics client-functie te kunnen bieden. Op die manier wordt de Html-overhead op de server natuurlijk vermeden. Deze ontwikkelingen moeten snel volwassen worden om het gevaar van Activex het hoofd te kunnen bieden.
