Aanvankelijk was Java bedacht voor het koppelen en eventueel besturen van consumentenapparaten. De opkomst van het web wijzigde die bestemming in het weergeven van multimedia onafhankelijk van computerplatform. Nu, anno 1999, zet deze programmeertaal annex platform zijn opmars verder door naar de achterkant van het computerspectrum: servers. Een blik op heden en toekomst, als vervolg op een eerder artikel over de ontstaansgeschiedenis van Java.
Het heeft even geduurd, maar Sun Microsystems’ Java begint nu echt door de puberteit te raken en richting volwassenheid te groeien. Volgens diverse analisten en technische testen weet Java sinds dit jaar pas de lat te halen voor bedrijfskritische toepassingen. Vorig jaar kwam het platform nog niet tegemoet aan de hoge eisen voor prestatieniveau en betrouwbaarheid die dergelijk gebruik met zich meebrengt. Dat was onder meer te wijten aan een wirwar van databank-drivers die kwalitatief onder de maat waren, alsook aan diverse uitvoeringen van de Java virtual machine (Jvm) die tekortschoten op prestatiegebied.
Maar in juni was daar de specificatie voor de Enterprise Edition van Java 2 (eigenlijk versie 1.2). Sun presenteerde dit nieuws op de Java One-conferentie in San Francisco. Daar onthulde het bedrijf dat het Java heeft opgedeeld in drie categorieën, elk met specifieke functionaliteit en eigenschappen voor dat deelterrein. Het platform bestaat voortaan uit de bedrijfszware Enterprise Edition, de reeds bestaande Standard Edition en de ingebedde Micro Edition. Deze nieuwe opzet en de begeleidende richtlijnen vormen een grote stap voorwaarts in de richting van Java-gebruik voor zware, serieuze – uiteindelijk zelfs wel bedrijfskritische – toepassingen. Vooral ontwikkelaars die Java willen aanwenden voor serversoftware die toegang tot applicaties biedt (applicatieservers), kunnen voordeel halen uit deze bedrijfseditie van Java 2.
Hotspot-technologie
De nieuwe versie van het algehele Java-platform biedt volgens testen van Sun een prestatieverbetering van twintig procent ten opzichte van de voorgaande Java Developers Kit 1.1.7. Daarnaast is Java 2 opgebouwd uit modules waardoor bijvoorbeeld de Java virtual machine (Jvm), die zorgt voor de uitvoering van Java-programma’s, vervangen kan worden door een nieuwe, snellere uitvoering. Die vervanger hoeft zelfs niet eens per se van Sun afkomstig te zijn, zolang die maar conformeert aan de testen en richtlijnen van dat bedrijf.
De recent vrijgegeven Hotspot-technologie biedt die mogelijkheid om de Jvm te vervangen door een nieuwe, snellere ‘motor’. Hotspot moet het prestatieniveau van Java-code oppeppen naar dat van het platformgebonden C++. Java is namelijk al sinds het ontstaan onderhevig aan kritiek vanwege een te grote omvang en een te laag prestatieniveau. Sun werkt – net zoals andere Java-supporters – al minstens zo lang aan het optimaliseren van het platform. "Het prestatieniveau is één van die dingen waar je nooit klaar mee bent. Er is geen enkel systeem op deze planeet dat ooit echt af is wat betreft het prestatieniveau. Maar wat we nu halen met Java2 is behoorlijk goed. Veel mensen voeren benchmark-testen uit met server-applicaties en wij zitten nu met Java in hetzelfde bereik als C- en C++-programma’s", zegt Java-schepper James Gosling. "Eén van de voortdurende problemen waar we mee worstelen is de vraag naar nieuwe mogelijkheden; mensen vragen ons om dit en dat in Java te stoppen. Dat leidt tot een lastige paradox: hoe meer je hebt, hoe meer je krijgt. Programma’s en onderdelen worden groot, omvangrijk. En dat vertaalt zich meestal in prestatieproblemen."
Een langverwachte mijlpaal in dat traject werd, eveneens in juni dit jaar, eindelijk bereikt; Sun lanceerde de Hotspot Performance Engine, een opgevoerde Jvm die al beloofd was voor eind 1997. Critici stellen dat dit uitstel Sun zal opbreken doordat Hotspot nu niet meer zo revolutionair is. De leverancier zelf denkt daar vanzelfsprekend anders over en ontkent dit. Tegelijkertijd werkt Sun hard aan Hotspot 2.0 die dit jaar nog moet uitkomen en die forse snelheidswinst belooft voor met name servertoepassingen. "Optimalisatie is vaak gericht op een specifieke situatie. De huidige Java Hotspot-technologie is bedoeld om vooral server-applicaties te versnellen. De soort van verfijning die je daarvoor gebruikt, verschilt nogal van wat je zou doen voor andere soorten toepassingen", aldus Gosling. Ondertussen zitten andere Java-leveranciers ook niet stil en vergroten zij het vermogen van hun Jvm’s.
Sun erkent dat er nog steeds veel te verbeteren valt, maar bezweert dit jaar de ‘prestatie-kwestie’ uit de wereld te helpen. Daarna moeten de Java-evangelisten nog de perceptie van die kwestie uit de weg ruimen, wat waarschijnlijk aanzienlijk langer zal duren. Voor een deel vallen de klachten over omvang en prestatie weg naarmate de tijd verstrijkt en daarmee het vermogen van de hardware toeneemt. In de tussentijd moet Java het nog altijd hebben van het fijn-afstellen van de software.
Versplintering?
Dat werk moet nu wel gestroomlijnd kunnen gebeuren doordat het platform in rustiger vaarwater is gekomen. De afgelopen twee jaar waren vooral het toneel van tumult en angst rondom Java. De taal leek te versplinteren doordat softwareleveranciers niet wilden of konden wachten op Sun om veelgevraagde verbeteringen in Java door te voeren. Dus begonnen zij de programmeertaal uit te rusten met eigen uitbreidingen. Voor specifieke doeleinden (denk aan apparaten met ingebedde chips), voor bepaalde platformen (mogelijkheden die besturingssysteem-eigen), en voor wat al niet. Sun deed zijn best deze verwildering tegen te gaan, zonder tegelijkertijd de touwtjes al te strak in handen te nemen. Het bedrijf wil ‘zijn’ product namelijk tot industrie-standaard laten verheffen, zowel in de praktijk (door wijdverbreid gebruik) als officieel. Die laatstgenoemde ‘erkenning’ wil Sun bereiken middels instanties als de ISO (International Standards Organisation) en de Ecma (European Computer Manufactures Association).
Aan de andere kant is Sun ook enigszins verantwoordelijk voor de wildgroei aan Java-ondersteuning. Het bedrijf bracht vorig jaar de specificatie voor Enterprise Java Beans (Ejb) uit zonder zelf de technologie in een zogenoemde referentie-implementatie te tonen. Een dergelijk testprogramma moet bewijzen dat de technologie werkt, en biedt tegelijkertijd een houvast voor compatibiliteitstesten die de interoperabiliteit van Java-applicaties moeten garanderen. Door het ontbreken van een dergelijk voorbeeld moesten softwareleveranciers elk op eigen houtje uitvogelen hoe het ingewikkelde programmeerwerk aan Ejb’s het geheel kan laten functioneren. De inmiddels verschenen Ejb 1.1-specificatie moet veel van deze problemen oplossen, mits softwarebedrijven zich correct aanpassen aan die richtlijnen. Het wachten is echter op de vervolmaking die Ejb 2.0 belooft. Eind volgend jaar moet die er komen.
Gecontroleerd versus open
Al met al moet Sun toch waken voor het al te dicht tegen de borst houden en controleren van de Java-technologie. Een standaard dient immers in enige mate open te zijn, zo predikt Sun in overeenstemming met de consensus in de IT-industrie. Aan de andere kant kan een technologie natuurlijk ook gestandaardiseerd worden door dominantie in de markt; als iedereen het gebruikt, is het de facto een standaard. Sun oefent dus zachtjes druk uit om het platform op koers te houden. Dit is vooral van belang omdat Java tegenwoordig actief is op het terrein van serverapplicaties. Ontwikkelaars en klanten hebben daar tot op heden moeten worstelen met een ware toren van Babel, die is ontstaan doordat leveranciers van applicatieservers over hun eigen voeten struikelden om Java te ondersteunen in hun software. Maar dan wel elk op een eigen manier. Deels was die taalverwarring een noodzakelijk kwaad, dat als hoger doel heeft het verbinden van Java met oudere, gesloten talen en applicaties. Bedrijven zijn nog altijd zeer terughoudend wat betreft het uit-de-deur-doen van oudere systemen. Vooral als die al jaren hun werk goed doen, kritische gegevens en applicaties bevatten en bovendien een enorme investering vertegenwoordigen.
Java krijgt in zijn bedrijfsuitvoering nu meer gewicht, hetgeen te danken is aan een toename in de breedte. Nee, Java wordt niet zozeer vet, maar biedt meer mogelijkheden voor de broodnodige samenwerking met verschillende soorten programmacode. Dit moet eveneens de overstap van een licht model applicatieserver naar een zwaardere uitvoering makkelijker maken. Zo’n migratie is heden ten dage moeilijk zo niet onmogelijk doordat de verschillende leveranciers niet geneigd zijn al te veel toenadering te zoeken tot hun concurrenten. Dat is zowel een technologie- als een egokwestie. Een grotere mate van compatibiliteit zou er namelijk toe kunnen leiden dat de software van de ene leverancier uitwisselbaar is met die van de andere. De softwarefabrikanten moeten er nu dus voor zorgen dat hun programmatuur anders is wat betreft functionaliteit, niet qua taal of koppelingen. Zo heeft Java 2 Enterprise geen voorzieningen voor zaken als beheer, schaalbaarheid en fouten-opvang. Op die gebieden is er dus zeker nog ruimte voor verbeteringen en dus differentiatie.
Vooruitdenken
Pessimisten vrezen dat deze gang van zaken nog steeds de deur open houdt voor versplintering. Sun denkt nu echter wat meer stappen vooruit; de richtlijnen voor Java’s nieuwe bedrijfsversie zijn uitgebreider en beslaan ook die elementen die het platform bijeen moeten houden. Sun verwacht de uiteindelijke specificatie van Java 2 Enterprise eind dit jaar uitgewerkt te hebben. De proefversie die sinds vorige maand uit is, omvat echter al een slordige honderdvijftig pagina’s die behoorlijk in detail gaan. Veel softwareproducenten zijn dus al aan de slag gegaan met dit lijvige pakket. Immers, door het ontwikkelwerk nu alvast bij te sturen is het later aanpassen van producten te voorkomen.
Tegenwoordig is het speelveld van Java nog grotendeels internet. Volgens onderzoek van onderzoeksbureaus als Gartner Group en IDC is dat wereldwijde netwerk de bestemming voor bijna de helft (48 procent) van alle Java-implementaties. Een geheel andere soort toepassingen wordt gebruikt voor intranet (37 procent) en extranet (19 procent). Slechts een minderheid (4 procent) van alle bedrijven zet dezelfde Java-applicaties in voor zowel internet als gesloten netwerken (intra- en extranetten). De meeste organisatie zijn begonnen met Java in te zetten in de vorm van applets (kleine programma’s) die functioneren via internet. Applets vinden echter steeds meer hun bestemming op privé-netwerken. Daar valt immers meer gelijkheid te verwachten bijvoorbeeld op hert gebied van browserversies. Verschillende browsers en verschillende versies kunnen Java-applets verkeerd weergeven, dit ondanks de belofte van ‘write once, run anywhere’.
Toekomst
Op termijn moeten ook deze rimpels gladgestreken zijn. Gartner voorspelt dat tegen het jaar 2002 meer dan 90 procent van alle computers in de Verenigde Staten, zowel desktops als servers, is uitgerust met een Java virtual machine (Jvm). In de komende jaren zal er een verschuiving plaatsvinden in het doel waarvoor Java gebruikt zal worden, aldus analist Daryl Plummer van Gartner. Programmeurs zullen Java steeds minder gebruiken voor het ontwikkelen van client-applicaties en juist meer voor server-applicaties. "Daarbij is er tevens een gang van eenvoudige naar meer bedrijfskritische toepassingen. Serverside-ontwikkelaars kiezen in toenemende mate voor Java-applicaties en servlets vanwege de mogelijkheden om complexe, uitwisselbare componenten met bedrijfslogica te maken die ook nog eenvoudig te onderhouden zijn", voorspelt Plummer.
"Die overgang van client- naar serverside Java vertegenwoordigt de volgende, hogere fase van Java-gebruik. Applicatie-ontwikkelaars moeten zich dan ook object-technologie en gedistribueerd programmeren eigen maken. Tot 2001 zullen pure Java-applicaties nog beperkt zijn in de mate van transactie-ondersteuning die zij bieden voor zwaar bedrijfsgebruik. Maar toch zullen die programma’s een bedrijfskritische bijdrage leveren in meer dan 60 procent van de gebruikte software", meent Plummer. Tegen 2004 bereikt Java pas een volwassen leeftijd voor ‘enterprise’-gebruik, aldus Gartner.
Minder grip
Terwijl de populariteit van Java groeit, vermindert Sun langzaam de dominante greep op ‘zijn’ technologie. Het deels vrijgeven van de broncode is één van de stappen in deze versoepeling. Tegelijkertijd vergroten andere bedrijven hun steun aan en investeringen in het platform. Zo overtreft de Java-betrokkenheid van IBM inmiddels al de investeringen van Sun in dat platform. IBM werkt al sinds 1995 aan het omvangrijke San Francisco-project, een raamwerk voor software-ontwikkeling dat bedrijfstoepassingen op basis van Java mogelijk moet maken. Het achterliggende idee is dat leveranciers zich kunnen concentreren op het applicatiedeelgebied waar zij uitblinken, waarna gebruikers een compleet bedrijfsautomatiseringssysteem kunnen samenstellen uit de componenten die elke leverancier aanlevert. Bovendien moeten die objecten gelijke aanspreekpunten (interfaces) en gebruiksmethodieken hebben, waardoor ze – in theorie – volledig uitwisselbaar zijn. De meer dan driehonderd softwareleveranciers die nu meewerken, dienen zich dus in extreme mate toe te leggen op het bieden van ultieme functionaliteit. Anders steekt de gebruiker simpelweg de module van een concurrerend bedrijf in zijn bedrijfssysteem.
IBM voorspelt dat er tegen het jaar 2001 meer dan 1500 applicaties van onafhankelijke software-ontwikkelaars zullen bestaan die zijn gebaseerd op het San Francisco-raamwerk. Rond 2002 zal Java gebruikt worden voor de ontwikkeling van zeventig procent van alle bedrijfslogica. Volgens het onderzoeksbureau Patricia Seybold Group heeft San Francisco nu al de industriebrede inzet van Java op serverniveau met twaalf tot achttien maanden versneld. Het project heeft vorig jaar echter wel forse vertraging opgelopen doordat het geen ondersteuning bevatte voor de Enterprise Java Beans-technologie (Ejb) van Sun. Ironisch genoeg heeft IBM juist een grote bijdrage geleverd aan de ontwikkeling van de Ejb-specificatie. Die technologie speelt een grote rol in de server-verovering van Java. Ejb kan code van oudere systemen in een capsule opnemen waardoor het kan communiceren met modernere omgevingen. Eigen onderzoek van IBM heeft uitgewezen dat negentig procent van de bedrijven tenminste drie verschillende serverplatformen in huis heeft. Het platform-overkoepelende bereik van Java kan daar dus een groot voordeel bieden. Zo schat onderzoeksbureau Forrester dat vijfenzeventig procent van alle bedrijven Java gebruikt op serverniveau en dat dat binnen twee jaar tegen de honderd procent aanligt. Collega-marktanalist Gartner denkt dat Java aan de serverkant dit jaar nog belangrijker zal worden dan Java aan de clientkant. Toch zal het nog wel even duren voordat Java op enterprise-niveau is beland; er zijn immers nog vele andere al dan niet concurrerende technologieën, zowel bestaand en gevestigd als nieuw en in de mode.
Java-gebruik per industriesector | |
Financieel (banken, verzekeringen) | 37 procent |
Hoger onderwijs | 19 procent |
Distributie/verkoop (winkelketens) | 11 procent |
Onderzoek (laboratoria) | 7 procent |
Gezondheidszorg | 7 procent |
Transport | 7 procent |
Productie (fabrieken) | 4 procent |
Uitgeverijen | 4 procent |
Nutsbedrijven (electriciteit) | 4 procent |
Java-gebruik per applicatietype | |
Zelf-service, leningsberekeningen | 30 procent |
Kwaliteitscontrole, volgsystemen | 15 procent |
Zelf-service, bankrekeningtransacties | 7 procent |
Invoer van bestellingen | 7 procent |
Analysesoftware (beslissingsondersteunend) | 7 procent |
Catalogi, online winkelen | 4 procent |
Overige zelf-service diensten | 30 procent |
Vooral de behoeften van de financiële sector worden goed ingevuld door Java, meent Gartner. Financiële dienstverleners richten zich in wezen niet op kleine marktsegmenten en zullen dus de belofte ‘één keer schrijven, overal draaien’ van Java-software aantrekkelijk vinden. Daarnaast zijn ook de mogelijkheden voor aanpassing en hergebruik sterke aantrekkingsfactoren, aldus Gartner (Bron: Gartner Group, april 1999).