Enterprise Java: Van J2EE 1.4 via Struts, Spring en Hibernate naar Java EE 5

De complexiteit van J2EE 1.4

Het leek allemaal zo mooi, de programmeurs konden zich focussen op de business functionaliteit, en de applicatie server zorgt voor al deze enterprise services. Hierdoor zou het bouwen van een enterprise Java applicatie relatief simpel moeten zijn.

De praktijk bleek anders. Hoewel de J2EE specifi catie vele voordelen bood, zoals een standaard voor enterprise Java applicaties dat resulteerde in verschillende applicatie servers van zeer hoge kwaliteit, zat er altijd één groot nadeel aan J2EE: J2EE is complex. De J2EE specifi catie wordt elke 2 à 3 jaar vernieuwd, maar al die jaren is de complexiteit niet minder geworden. Eén van de belangrijkste redenen hiervoor was de manier hoe de J2EE standaard tot stand kwam.

Eerst werd de J2EE specifi catie bedacht, vervolgens werden er applicatie servers gebouwd die deze J2EE specifi catie implementeerden, en vervolgens mochten de programmeurs enterprise Java applicaties bouwen die in een J2EE applicatie server draaien. In de praktijk bleek dat een aantal zaken in de J2EE standaard eigenlijk veel te complex waren.

Deze aanpak is ervoor verantwoordelijk geweest dat we al die jaren met een veel te complexe enterprise Java standaard hebben gewerkt. Men heeft lang gedacht dat men deze complexiteit kon wegnemen door allerlei mooie wizards te bouwen in de ontwikkel tools, en dat de complexiteit verborgen kon worden door de ontwikkel tools. In de praktijk blijkt dat een ontwikkelaar het merendeel van de tijd bezig is met de details in XML, HTML, SQL en Java code en maar heel weinig tijd bezig is met een wizard van de ontwikkel tool.

De opkomst van open source frameworks

Precies hetzelfde gebeurde met het open source Spring framework. De J2EE 1.4 standaard bevat de EJB 2.1 standaard voor het implementeren van de business logica laag. Er zijn vele applicaties gebouwd met EJB’s, maar EJB’s hebben altijd één groot probleem gehad: Ze waren veel te complex. Het Spring framework lost deze complexiteit op, en met Spring kun je op een simpele manier hetzelfde doen als wat je op een complexe manier met EJB’s kunt doen.

Als we naar de database laag kijken dan zien we hetzelfde patroon. De J2EE 1.4 standaard bevat EJB 2.1 entity beans en JDBC voor database acces. Hoewel de ideeën achter EJB entity beans goed waren, was de implementatie veel te complex. Vanuit de open source wereld kwam het Hibernate framework die net als EJB entity beans transparante persistentie biedt, maar dan op een veel simpeler manier.

Het patroon dat we dus steeds zien is dat de enterprise Java standaard niet compleet of te complex is, en dat open source frameworks deze problemen in de standaard oplossen. Er wordt nu ook algemeen erkend dat de enterprise Java standaard altijd gaten zal bevatten die door open source frameworks worden opgelost. Het is dus nu heel normaal dat je open source frameworks samen met de J2EE standaard gebruikt voor bedrijfskritische applicaties.

De waarde van de nieuwe Java EE 5 standaard.

EJB 3.0 is een grote vooruitgang. Men heeft nu eerst gekeken wat goed werkt in de praktijk, zoals Spring en Hibernate, en daar heeft men de EJB standaard op gebaseerd. Alleen heeft de EJB 3.0 standaard een paar problemen:

1. Het Spring framework is veel krachtiger dan de EJB 3.0 standaard, en EJB 3.0 biedt niets extra’s t.o.v. Spring

2. Het Hibrnate framework is veel krachtiger van de JPA standaard, en JPA biedt niets extra’s t.o.v. Hibernate. De JPA standaard is een subset van de Hibernate functionaliteit.

3. EJB 3.0 is gebaseerd op Java 5, en werkt niet op Java 1.4. Je hebt dus een Java EE 5 applicatie server nodig, en daar zijn er op dit moment,bijna 2 jaar na het uitkomen van de Java EE 5 standaard, nog maar erg weinig van. Zo zit bijvoorbeeld IBM Websphere nog op J2EE 1.4 en is de Java EE 5 applicatie server van JBoss nog in beta versie.

Hierdoor zien we de meeste enterprise Java projecten op dit moment Spring en Hibernate gebruiken en niet EJB 3.0. We zien ook dat deze open source frameworks steeds meer ondersteund worden door de applicatie server vendors. Eigenlijk zijn frameworks als Struts, Spring en Hibernate standaarden op zich geworden.

Heeft de Java EE 5 standaard dan geen waarde meer? Naar mijn mening wel, alleen is de waarde een stuk minder geworden dan een aantal jaren geleden. De JSF standaard is wel degelijk een grote vooruitgang t.o.v. Struts. JSF staat het toe om herbruikbare (3rd party) UI componenten te gebruiken voor het web. Dit kunnen bijvoorbeeld een multiselect tabel of een kalender component zijn, waar de meeste complexiteit in het component zit, en de programmeur deze complexiteit niet zelf hoeft te implementeren.

Maar we zien dat ook de JSF standaard bepaalde gaten en complexiteit bevat, en zoals verwacht vullen open source frameworks als Seam en Spring WebFlow deze gaten weer op. En zo blijven we bezig en is het eind nog lang niet in zicht.

Rene de Jong (rene@ictintelligence.nl) is zelfstandig adviseur en docent op het gebied van enterprise Java architectuur.