‘Electronic commerce’ over het Internet zal een grote impact op de thuismarkt hebben, waarbij zowel kansen als bedreigingen voor dienstenaanbieders ontstaan. Het eenvoudige invulformulier met een dynamisch back-end tussen een web-server en een conventioneel transactiesysteem zal relatief eenvoudig te bedienen zijn. Maar als de browser op het gebied van transactieverwerking echt moet concurreren met de PC en de domme terminal is er meer nodig.
Java is een voor de hand liggend vertrekpunt. Java is een objectgeoriënteerde programmeertaal, uitgevonden door Bill Joy van Sun Microsystems. In essentie komt Java overeen met ++, de object-kant van C++, maar zonder het procedurele deel van C++, dat afkomstig is van de technische taal C. Java heeft brede steun van de industrie gekregen en zal C++ zeker vervangen. Daar is iedereen bij gebaat, behalve de snelle C++-goeroes. Helaas zijn de klassebibliotheken van Java niet compatibel met die van C++, zodat het nog even zal duren voor Java-ontwikkelomgevingen echt volwassen zijn. Inmiddels zijn er al producten van Microsoft, Sun, Symantec en Borland.
Java speelt als ‘general-purpose’ taal een bijzondere rol in web-applicaties. Java-applets zijn objecten die zijn geschreven in een deelverzameling van Java, die alleen gebruik kan maken van een speciale klassebibliotheek; deze bibliotheek levert een gui-interface voor applicaties en is beperkt tot de functies van standaard-browsers.
Java-applets worden niet vertaald in machinecode, zoals met gewone applicaties het geval is. Een applet wordt vertaald naar een machine-onafhankelijk bytecode-formaat, ofwel een tekstbestand. Deze applets worden ingebed in Html-pagina’s, waar via URL’s naar wordt verwezen. De applets worden in de browser geladen en daar uitgevoerd. Dit lijkt op het model van de ‘dunne client’ in client/server-systemen, maar met één verschil: de client-code wordt niet vóór executie vanaf een lokale PC geladen, maar tijdens executie vanaf de server. De byte-code wordt geïnterpreteerd zodat hij machine-onafhankelijk is; een applet draait op alle browsers. Voorbeelden hiervan zijn Navigator, Internet Explorer en vergelijkbare producten voor Unix-werkstations met Risc-processoren. Ze draaien ook op computers zonder randapparatuur, intelligente terminals die door het leven gaan als network computers (NC’s). Dit is de grote kracht van Java; er is geen behoefte meer aan PC’s op de desktop, nu NC’s dezelfde functionaliteit bieden. Met NC’s vinden alle upgrades op de server plaats; dit beperkt de eigendomskosten enorm. Java-applicaties zullen volwassen worden en zo een heel nieuwe wereld van moderne component-applicaties openen. Component-applicaties bieden een goedkoper alternatief voor de verouderde kantoorsuites (Microsoft Office, Lotus Smartsuite en dergelijke). De potentiële kostenbesparing zal zo groot zijn, dat het niet de vraag is �f de NC de PC zal vervangen, maar wanneer en hoe.
Java-applets draaien zowel op een PC met browser als op een NC. Bedrijven met een belang in de PC proberen nu de goedkope NC-optie te saboteren door Java op te tuigen met PC-specifieke interfaces. De hoofdschuldige is het ergste virus aller tijden: Microsoft Activex, een taal die Java en de browser integreert met OLE en PC-applicaties. Het is eenvoudig: een Java-applicatie draait op PC’s en op NC’s; een Activex-applicatie draait alleen op PC’s. De noodzaak voor organisaties om zich in de toekomst bij het goedkopere NC-kamp aan te sluiten is onvermijdelijk; wie nu in de Activex-val trapt zal zich daar later uit moeten kopen. Omdat dit nog een jaar of vier zal duren, valt de schade te overzien; tegen die tijd zijn er weer nieuwe applicaties nodig, maar wees toch gewaarschuwd. En besef dat alle innovaties op Java gebaseerd zullen zijn.
Java is een krachtige uitbreiding van het dynamische concept dat is begonnen met Html-submit en -scripts. Java biedt echter volledige functionaliteit en de mogelijkheid om complete transactiesystemen te bouwen op een client/server-manier. Dit opwindende concept is nog lang niet volwassen: het moet grondig worden bestudeerd, er moeten pilots worden gestart, en enige voorzichtigheid is wel op zijn plaats. Eén probleem is nog maar gedeeltelijk opgelost: het concept van de toestand (‘state’). Een transactie kan bestaan uit verschillende deeltransacties die geaccumuleerd moeten worden; dit betekent dat de volgtijdige toestanden bijgehouden moeten worden. Een browser is echter toestandloos, zodat er voor transactie-applicaties een standaardmanier gevonden moet worden om toestanden bij te houden. Het tweede probleem is toegang tot de krachtige server-functies, vooral bij grote transactieservers zoals MVS (met Cics, IMS en dergelijke) en Unix met Tuxedo of Cics/6000. Dit kan met de technologie van vandaag worden gerealiseerd door berichten naar een web-server te sturen, direct naar bestaande transactiesystemen via CGI. Voor grotere systemen moet de performance hiervan in twijfel worden getrokken; voor eenvoudige huis-tuin-en-keukenapplicaties is het in orde.
