Wat biedt Java Enterprise Edition Versie 5?

De introductie van de langverwachte ‘vijfde’ editie van enterprise Java is een significante gebeurtenis in de geschiedenis van zowel Java als van Sun: de grootste ontwerpfouten uit het verleden moeten in deze editie worden rechtgezet.

We proberen één en ander te evalueren: wat is de impact van EE 5? Moeten we allemaal maar zo snel mogelijk overstappen naar dit nieuwe platform, of blijven we beter nog bij onze oude, vertrouwde versie 1.4?

Java EE 5 vereist Java 5, de laatste versie van de programmeertaal en virtuele machine – dit is onder andere nodig om het uitvoerige gebruik van annotaties te ondersteunen. Java 5 is op zich een significante aanpassing van de taal, de grootste zelfs sinds de invoering van Java ruim tien jaar geleden.

Metadata (annotaties)
Annotaties laten toe om installeer- en configuratie-instructies toe te voegen in de Java software zelf. In het verleden werd dit gedaan door systeemdocumentatie in één of meer XML-, HTML of tekstbestanden toe te voegen. Dit leidde al te vaak tot problemen qua onderhoudbaarheid (tekstbestanden werden niet mee aangepast als de software veranderde) en compatibiliteit (applicatieserverspecifieke leesproblemen waardoor de software niet werkte op alle platformen).

De ondersteuning van annotaties is zonder twijfel dé belangrijkste nieuwigheid in Java 5, zeker vanuit enterprise Java oogpunt. Met annotaties wordt het mogelijk vele, zoniet alle aspecten die in XML moesten worden beschreven voortaan in de Java-code zelf te plaatsen. Dit heeft als grote voordeel dat de ontwikkelomgeving kan controleren op inconsistenties, en ook dat de redundantie van bijkomende tekstbestanden wordt vermeden.

Concreet betekent dit dat er véél minder XML-bestanden nodig zijn in Java EE 5 (ze mogen nog wel bestaan, maar hoeven niet meer). Dit houdt voor de doorsneeapplicatie een significante besparing in qua configuratiekost. Een ander voordeel van annotaties is dat ze de rigiditeit van enterprise Java kunnen verlichten door meer vrijheid te geven aan de ontwikkelaars.

Daar waar vroeger strikte Java-naamgevingen nodig waren omwille van de ‘loodgieterij’ van de applicatieserver, is het nu vaker mogelijk vrij een naam te kiezen die dan wordt gedocumenteerd met annotaties. Zo weet de applicatieserver toch nog waarvoor iets dient, zelfs al heeft het niet de verwachte naam.

Nieuwe gebruikersinterface
Met Java server faces (JSF) heeft Java EE 5 er een nieuwe gebruikersinterface bij. Of beter gezegd: een nieuwe manier om de bestaande technologie gebaseerd op webpagina’s te implementeren. JSF is een complement voor de bestaande servlets en Java server pages (JSP).

De kracht van JSF zit hem in het beheer van de gebruikersinterface: JSF automatiseert het onthouden van welke toestand een gebruikerspagina heeft (zonder JSF moeten de programmeurs dit zelf voorzien). Dit resulteert in een bibliotheek van herbruikbare componenten voor web interfaces, zoals drukknoppen, keuzevelden, tekstvelden en dergelijke meer.

Wanneer iemand een keuzeveld aanvinkt, onthoudt JSF dit (langs de serverkant weliswaar); er wordt ook voor gezorgd dat de applicatie hierop makkelijker kan reageren. Dit maakt het programmeren van een web interface makkelijker – mits men de meerkost voor het leren van JSF wil betalen.

JSF is dus een leuke toevoeging langs de serverkant, maar op zich geen revolutie: de gebruikersinteracties worden nog steeds op de server beheerd, zoals voordien. Dit maakt het gebruiken van JSF-applicaties een ‘klik-en-wacht’-gebeuren, omdat de reactie telkens van de server moet komen (in een verse HTML-pagina). Langs de gebruikerskant (de browser) vinden we tegenwoordig ook initiatieven zoals AJAX en anderzijds ook Flex.

Deze technologieën werken niet puur op de server, maar wel in de browser zelf: zo ontstaat een meer interactieve ervaring omdat niet telkens een nieuwe pagina moet worden opgehaald via de webserver. Het valt nog af te wachten in welke mate deze alternatieven efficiënt te combineren zijn met JSF.

Nieuwe web services
In versie 1.4 van het enterprise platform waren web services iets te overhaast toegevoegd, zo leek het wel: het programmeermodel was niet helemaal in orde, de toegangswijze voor SOAP- en XML-berichten was redundant, nieuwere standaarden op het gebied van web services (zoals security) werden niet ondersteund en nog veel meer. Dit alles heeft ertoe geleid dat alternatieve oplossingen zoals bijvoorbeeld Apache Axis veel succes hebben gekend bij wie iets met web services wou doen.

Met deze nieuwe editie moeten de meeste van deze problemen van de baan zijn, in theorie althans. De voormalige JAX-RPCtechnologie werd vervangen door JAX-WS, een betere en meer consistente oplossing. Het ziet er in ieder geval veel beter uit: WS-addressing wordt ondersteund, de XML-toegang is verbeterd en het zou zelfs mogelijk zijn om asynchrone web services te hebben.
Dit laatste is vooral belangrijk in de echte wereld, waar services soms niet bereikbaar zijn. Asynchrone oplossingen laten toe om, gecombineerd met extra infrastructuur, tijdelijke systeemfouten op te vangen. Bovendien zorgen asynchrone oplossingen voor een efficiënter gebruik van de beschikbare apparatuur, doordat er minder gewacht moet worden op de resultaten van anderen.

Kortom, de nieuwe web services zien er dus al beter uit dan voordien. Het blijft nu wachten of dit een succes wordt, omdat ondertussen ook Apache met een gloednieuw alternatief is gekomen, met name Axis2. Het verschil tussen Axis en Axis2 is zo mogelijk nog groter en positiever dan het verschil tussen JAX-RPC en JAX-WS, en Axis2 ondersteunt vrijwel alles wat JAX-WS doet en misschien nog veel meer.

Vernieuwde EJB
Enterprise Java beans (of EJB) was het klassieke zwarte schaap van enterprise Java: de ontwikkelaars werden in een keurslijf gedwongen dat door de applicatieserver werd opgelegd. Het ontwerp van enterprise applicaties werd dus meer bepaald door de technische vereisten van de server dan door het toepassingsdomein zelf, wat vaak in een ramp resulteerde qua begrijpbaarheid, kost en onderhoud.

EJB 3.0, de huidige vernieuwing, doet een grote stap voorwaarts (en in de goede richting): het strakke keurslijf is grotendeels (maar niet helemaal) verdwenen, zodat het applicatieontwerp meer kan worden gestuurd door het toepassingsdomein dan door de techniek. De grootste beperking die nu overblijft is dat u nog altijd niet buiten de application server kan, terwijl de meeste functies van dit platform ondertussen achterhaald zijn of in een betere variant beschikbaar zijn zoals bijvoorbeeld Spring.
Nieuwe persistentie
De persistentie is eigenlijk een onderdeel van EJB, maar verdient een aparte paragraaf. Onder persistentie verstaan we het vertalen van Java-objecten naar de databanktabellen en omgekeerd. Met zogenaamde O/R (object-relationele) mapping technologie kan men dit proces automatiseren. In EJB was dit klassiek de rol van de zogenaamde entity beans.

Van alle Java-technologie is entity beans waarschijnlijk de meest verwenste. De hierboven vermelde gebreken van EJB in het algemeen werden door entity beans nog ten top gedreven.

Het gevolg is dat betere alternatieven zoals Hibernate, TopLink of JDO (Java Data Objects) een kans kregen om de O/R-markt te veroveren. De (lovenswaardige) reactie van Sun om deze externe partijen te betrekken bij het EJB 3.0-initiatief heeft ertoe geleid dat entity beans nu bijna niet meer te herkennen zijn: enterprise Java lijkt nu (eindelijk) een degelijke persistentie te ondersteunen.

Nieuwe xml-verwerkingsmogelijkheden
Naast alle bovenvermelde innovaties is er ook een nieuw model voor XML-verwerking beschikbaar (StAX, of Steaming API for XML). Dit belooft een efficiëntere verwerking van XML, wat onder andere bij web services zeer belangrijk is omdat web service (SOAP) berichten in XML zijn opgemaakt. Hoe sneller u die kan lezen, hoe performanter uw web service dus wordt.

Nieuwe services
De klassieke lijst van services die door de applicatieserver worden geboden is nu vervolledigd met web service security, een nieuwe standaard om op een beveiligde manier verschillende web service partijen met elkaar te laten communiceren. Dit is een eerste stap in de richting van betrouwbare web services, alhoewel de robuustheid van transacties nog niet is doorgedrongen tot enterprise Java: als verschillende services van elkaar afhangen en er gebeurt een fout of crash dan weet u eigenlijk niet waar u staat.