Ytterligare momentum för Java Persistence Api

20 October 2007 // Johan Eltes

Java EEs vara eller inte vara debatteras flitigt. Eller rättare sagt behovet av en Enterprise Java specifikation i allmänhet och EJB som teknologi i synnerhet. Det råder dock inget tvivel om att EJB Persistence - en del av JavaEE 5-specifikationen - har luft under vingarna.

Den nya standardiseringen av API för lagring av domänobjekt i relationsdatabaser är en obligatorisk ingrediens i en EJB 3-implementation. Vid en första anblick kan det tyckas motsägelsefullt med kopplingen till EJB 3, med tanke på att Java Persistence API (JPA) är tänkt att standardisera alla de objektlagrings-api:er som Java-utvecklare idag använder (Hibernate, TopLink, JDO, Kodo etc). JPA är emellertid en fristående specifikation, som enbart har beroende till JavaSE 5 (dvs JDK 1.5).

I praktiken kan man m.a.o. använda JPA-standarden i varje applikation som ska köras på JavaSE 5. De flesta J2EE 1.4-baserade applikationsservrarna stödjer redan i dag JavaSE 5 (Weblogic 9, WebSphere 6.1 etc). Många transaktionella applikationer som inte använder EJB, är baserade på Spring-ramverket. Spring 2.0 kommer med integration av JPA.

Den senaste i raden av annonseringar relaterade till JPA kommer från Apache. För ett tag sedan köpte BEA persistens-produkten Kojo. BEA har anpassat Kojo till JPA-standarden och i samband med JavaOne 2006 släppt projektet till Apache under namnet “OpenJpa”. The Server Side rapporterade igår om ett sista “code drop” till Apache, som utgör en milstolpe i fullföljandet av leveransen.

Men vad betyder JPA för en utvecklingsavdelning? Det är väl rimligt att anta att JPA, kan förutspås ett stabilare och längre liv än enskilda persistens-ramverk så som Kojo, Hibernate och Toplink?

Framtida utvecklingsprojekt lär m.a.o. baseras på Java Persistence API, snarare än specifika API:er så som Hibernate. Men JPA är ju fortfarande bara en specifikation. Man måste välja en implementation. Den senaste versionen av Hibernate har stöd för JPA. Om vi väljer Hibernates JPA-implementation idag, kan vi då i en framtid byta till JPA-implementationen i WebSphere 7 (spekulation: WebSphere 7 är namnet på IBMs kommande implementation av JavaEE 5)? Eller till OpenJpa, som kommer att vara BEAs implementation av JPA i WebLogic 10?

Det finns flera aspekter på portabilitet mellan JPA-implementationer:

1. Programkod är inte allt. Varje produkt har sina specifika konfigurationsfiler. Hur mycket arbete innebär konverteringen av konfigurationsfiler?
2. Programkoden blir portabel, men är standarden och Suns kompatibilitetstester tillräckligt detaljerade för att säkra att beteendet i applikationen blir identiskt mellan två implementationer?

Fråga 1 ovan är rimligen kalkylerbar, utifrån en specifikt migreringsfall: Hur stor är t.ex. kostnaden för att konvertera från Hibernates konfigurationsfiler till OpenJpas dito? Mindre smoke-tester är förmodligen allt som behövs för att verifiera konverteringen.

Fråga 2 är sannolikt svårare att besvara. Baserat på erfarenheter av att använda persistensramverk, kan jag konstatera att varje projekt behöver tillgång till detaljerad kunskap om ramverkets inre liv, för att förstå orsak-verkan mellan programkod och applikationens beteende. Det gäller ofta kniviga beroenden mellan objektens tillstånd i databasen, objektens tillstånd i ramverkets cache, integritetsregler och transaktionsgränser. Vidare väljer olika ramverk olika strategier för SQL-generering. Med ramverk a får man bättre prestanda genom att välja en annan strategi för upplösning av arv, än med ramverk b. En migrering med bibehållen prestanda, skulle kunna framtvinga en ändring av databasens struktur. Men med en bred marknad, ökar ju sannolikheten att vi kan välja ett bättre ramverk och därmed förbättra applikationens svarstider, resursutnyttjande etc. Även här är förmodligen testautomation möjliggöraren. Med en ambitiös automatiserad testsvit för såväl funktionalitet som prestanda, skulle man kunna nå ytterligare värden av JPA, genom att kunna tillåta projekten göra taktiska val av implementationer.

Läs mer om JPA..