Enterprise Java De stand van zaken

Door Ulas Onder, Jan Quartel, Chris de Vreeze

Het enterprise applicatie ontwikkelparadigma in Java verandert snel. Eind jaren ?90, toen het allemaal begon voor Java, had men niet kunnen raden waar ontwikkelaars en architecten vandaag de dag mee bezig zouden zijn.

In dit artikel zoomen we in op de geschiedenis van J2EE, voornamelijk over het meest belangrijke aspect van de gehele specificatie, de Enterprise Java Bean (EJB). Vervolgens hebben we het over een overzicht van de evolutie van enterprise applicatie ontwikkeling. Tevens wordt dieper ingegaan op het EJB 3 persistentie. Als laatste wordt het ontstaan van Spring behandeld en de aansluiting op EJB 3 persistentie toegelicht.

Korte geschiedenis van EJB als componentenmodel

In september 2001 ziet EJB 2.0 het licht met nieuwe features, als onderdeel van J2EE 1.3: EJB Query Language, entity bean relaties, local interfaces, abstract getters en setters zijn de grootste aanpassingen aan het componentenmodel. Hiermee geniet EJB de hoogste populariteit tot nu toe in het bedrijfsleven. De opvolger EJB 2.1, onderdeel van J2EE 1.4 (april 2004), werd echter geen doorbraak in de geschiedenis van Java EE: de introductie van de timer service, XSD validatie voor deployment descriptors en een licht aangepaste Query Language was niet voldoende om dit als een grote verandering te zien.

Inmiddels is EJB 3.0 geïntroduceerd met een totaal andere componentenarchitectuur: eenvoud is het sleutelwoord. Voordelen zijn dat er zijn geen life-cycle callback methoden meer die geïmplementeerd moeten worden en geen onnodig zware deployment descriptors meer. Alles waar de ontwikkelaar zich druk over dient te maken is in één plaats terug te vinden, de code zelf.

Nieuwste model: EJB 3.0

Als voorbeeld kijken wij naar een session bean. Voordat EJB 3.0 er was, moest een session bean in de deployment descriptor met een XML element binnen een ander element expliciet worden gedeclareerd. Dit was omslachtig en het beheer van al deze afzonderlijke bestanden, dat door andere rollen en vaak andere personen werd gedaan, was lastig. Nu annoteert men gewoon een Plain Old Java Object (POJO) als @Stateless of @Stateful om het type session bean aan te geven. Ditzelfde geldt ook voor de entity bean. Deze annoteert men met @Entity en men hoeft alleen de tabel en de primary key aan te geven.

Web Services verbeteringen

EJB 3.0 Persistentie, de Java Persistence API

Een typische Java webapplicatie (met of zonder EJBs) kent twee soorten objecten: value object classes (data, geen business logica), en applicatielogica componenten (business logica, nauwelijks data). De methoden van de applicatielogica componenten hebben value objects als parameters en return waarden. Als dit wordt vertaald naar het gebruik van JPA, dan zijn de value objects JPA entities, en de applicatielogica componenten gebruiken de JPA EntityManager om deze entities te persisteren en op te halen. Applicatielogica kan als EJB 3 session bean gerealiseerd zijn, maar ook als Spring POJO, waarover later meer. Enkele van de vele annotatietypes in de JPA zijn:
? @Entity, waarmee aangegeven wordt dat de class een JPA entity class voorstelt.
? Annotatietypes als @Table, @Column, @JoinTable, waarmee de mapping tussen Java en database vergaand getuned kan worden.
? Primary key annotaties zoals @Id.
? Annotatietypes zoals @ManyToOne, waarmee multi-valued (collection) fields worden gemapt op relaties tussen tabellen.
? @Inheritance, waarmee Java inheritance wordt gemapt op tabellen. Meerdere tabelstrategieën zijn mogelijk om inheritance in de database te realiseren. Nog steeds kan metadata worden geconfigureerd in de orm.xml file in plaats van annotaties, waarbij de orm.xml leidend is.

De JPA heeft een aantal aantrekkelijke aspecten. Zo probeert de JPA niet Java op relationele databases te laten lijken of andersom, maar respecteert het de verschillen tussen beide werelden. Het bevat de annotaties om ook in complexe gevallen tussen beide paradigma?s te mappen. Zonder de annotaties blijft de Java code ?natuurlijk?. Bovendien, of de database nu leidend is of de geannoteerde Java code, de JPA is in beide gevallen bruikbaar.

De JPA heeft een querytaal die sterk op SQL is gebaseerd, maar op entities werkt in plaats van database records. Zoals te verwachten van een echte O/R mapper gaat deze querytaal prima om met Java polymorfisme. Merk op dat waar nodig, nog steeds native SQL kan worden gebruikt.

JPA werk wordt uitgevoerd met de EntityManager. Deze wordt verkregen in een Java SE omgeving programmatisch, door deze via een EntityManagerFactory aan te laten maken. In een enterprise container is veel minder programmeerwerk nodig. Veronderstel een EJB 3 session bean waarin men de JPA gebruikt. Dan annoteert men een EntityManager veld met de @PersistenceContext annotatie. Het instantiëren van dit veld wordt door de (Java EE 5) container gedaan, niet door de programmeur. Dit staat bekend als dependency injection, een principe dat zeer bekend is geworden door Spring. Niet de applicatie vraagt het veld op, maar de container zorgt ervoor dat tijdig een EntityManager instantie wordt geïnjecteerd. Dit is een vorm van inversion of control.

Enkele van de operaties op een EntityManager zijn: persist, find en createQuery. Na constructie van een entity is deze nog in de toestand new. Pas na een persist aanroep gaat deze over in toestand managed. Daarnaast bestaan toestanden detached en removed. Het is zaak om altijd goed te beseffen in welke toestand een entity zich bevindt. Zo kan een entity in toestand detached vrij gemanipuleerd en uitgewisseld worden zonder effect op de database.

HintTech