Het oorspronkelijke idee achter Java was een gemeenschappelijke, objectgeoriënteerde programmeertaal die was gekoppeld aan een interpreter, de Java Virtual Machine (JVM). Op deze manier zou elk Java-object consistent kunnen worden uitgevoerd op elke computer die een JVM ondersteunde.
De eerste JVM’s waren ingebed in web-browsers. De Java-objecten, die een vast, uitwisselbaar bytecode-formaat hadden, werden applets genoemd. Ze waren gemakkelijk overdraagbaar te maken, omdat ze alleen werden gebruikt om web-schermen te verfraaien. Dit betekende dat alleen de gui-functie ondersteund hoefde te worden.
De volgende stap was de interactie tussen Java-applets en een server. Hiervoor was een of andere ‘remote procedure call’ (RPC) nodig, maar dan op basis van objectmethoden en niet op basis van procedurele methoden zoals Dole of RPC. De JVM werd uitgebreid met Remote Method Invocation (RMI), een goede standaard voor de lange termijn. Toch is er behoefte aan krachtiger technieken om methoden op afstand aan te kunnen roepen; denk aan een interface met systemen die voldoen aan de Corba-normen. Dit interface is er, en het heet Inter-Internet ORB Protocol (IIOP). IIOP stelt Java-applets in staat Corba-servers te gebruiken.
Dit is allemaal prachtig, maar het Web en Java zijn sleutelcomponenten voor het ontwikkelen van bedrijfskritische transactiesystemen, ofwel e-commerce. Een ontwikkelaar kan ervoor kiezen de client zo schoon mogelijk te houden, waarbij de web-server is gekoppeld aan een transactiesysteem met behulp van CGI. Dit is een trage API, zodat er nu specifieke oplossingen van Microsoft, Netscape en IBM zijn. Andere ontwikkelaars gebruiken de JVM om primitieve protocollen aan te spreken, zoals sockets en Http zonder Html. Het begint een beetje verwarrend te worden.
Microsoft maakt de zaken met opzet nog complexer dan ze al zijn. Microsofts JVM is ingebed in Internet Explorer en geïntegreerd met Ole, zodat Java-applets kunnen samenwerken met conventionele Windows Ole-clients. Het hele Java-concept is hiermee ondergraven, tenminste op de client!
Een Java-applet is een eenzame entiteit. Om applicaties op basis van componenten te kunnen ontwikkelen zijn Java Beans ontwikkeld. Op basis van een consistente container-architectuur kunnen Beans onafhankelijk van elkaar worden ontwikkeld en tijdens run-time worden gecombineerd. Dit is een object-uitbreiding van de VBX- en OCX-architectuur die in Windows wordt toegepast met Visual Basic en Ole.
Nu de libraries van Beans steeds groter worden om nog betere client-applicaties voor grafische userinterfaces te kunnen bouwen, is er ook een trend om het JVM-concept op de server te implementeren. Dit komt dan in de plaats van CGI of Microsofts Active Server Page (ASP).
De behoeften aan de server-kant verschillen sterk van die aan de client-kant. De client-code is gui-georiënteerd en single-user; de server-code ondersteunt beveiliging, transacties en query-services, is multi-user en heeft geen boodschap aan gui-programma’s. Dit heeft geleid tot de introductie van de term ‘servlets’ voor applets die op de server draaien. De principes zijn hetzelfde, maar de JVM’s zijn verschillend. De meeste JVM’s op de client zijn ingebed in de browser, terwijl de JVM op de server deel moet uitmaken van het besturingssysteem. Speciale Java Beans, Enterprise Java Beans genaamd, zijn essentieel op de server, omdat de software daar juist draait om server-functies te gebruiken. Een hemelsbreed verschil met een browser-applet.
Bovenaan de lijst met server-JVM’s staan de Beans voor database-toegang (Jdbc) en transactiediensten. Voor het laatste geval is er een nieuwe Java-standaard gedefinieerd, die belangrijke transactiediensten als begin/end, rollback, commit, beveiliging en dergelijke biedt. Specifieke Beans vertalen deze API, die wordt gebruikt door de Java-programmeur, weer naar Cics, Tuxedo en waarschijnlijk MTS. Geïmplementeerd op uiteenlopende besturingssystemen als OS/2, NT, Unix, OS/400 en MVS biedt deze standaard een werkelijk overdraagbaar platform.
De syntax van Java is beter gestructureerd dan Visual Basic of C++, maar veel uitgebreider is het niet. In tegenstelling tot Cobol en 4GL’s is Java niet echt rijk aan bouwstenen voor het ontwikkelen van commerciële gegevensverwerkende applicaties. Java lijkt in dit opzicht op VB en C++. Sommige nieuwe transactiesystemen staan op zichzelf, maar de meeste moeten samenwerken met bestaande omgevingen. Dit is de troefkaart van IBM. Door gebruik te maken van Enterprise Java Beans in combinatie met de Cics Bean en de MVS JVM kunnen nieuwe Java-servlets worden ontwikkeld, die samenwerken met gui-applets op de client en bestaande Cics/Cobol-transacties in de backend. Op deze manier bieden Java-servlets een geavanceerde, moderne, programmeerbare middleware-laag voor het gebruiken van legacy-applicaties in moderne omgevingen.
Op den duur zal de syntax van Java verbeterd worden, en ik verwacht dat er binnenkort compilers op de markt zullen komen voor servers. Hierdoor wordt Java een gewone programmeertaal – en dan is het gedaan met de portabiliteit. Java Beans en servlets zijn een stap in de goede richting; de voortdurende ontwikkeling van Enterprise Java Beans is de moeite waard om in de gaten te houden.
