Enterprise-applicaties hebben vaak te maken met operaties zoals het verzamelen, verwerken, transformeren en rapporteren van een grote hoeveelheid gegevens. Deze gegevens worden doorgaans opgeslagen op een databaseserver op een bepaalde locatie en op aanvraag opgehaald. De applicatie is verantwoordelijk voor het verwerken van de gegevens uit de database en uiteindelijk presenteren voor klantconsumptie. Maar de fijne kneepjes van het verminderen van de gegevensuitwisseling tussen verschillende architecturen is de echte uitdaging waarmee ontwikkelaars worden geconfronteerd. De kern van het probleem ligt in het versoepelen van de gecompliceerde relatie van gegevensverplaatsing tussen de code die wordt gebruikt om de applicatie te ontwikkelen en het opslagmodel dat wordt gebruikt voor gegevenspersistentie. Kortom, het idee is om een mechanisme te creëren voor naadloze interactie tussen twee onverzettelijke modellen:het objectgeoriënteerde karakter van de Java-taal en het relationele databasemodel.
Basis-API's voor databases
Het Java-platform heeft al standaard API's om met databasesystemen te werken in de vorm van JDBC API's. Deze API's werken uitstekend met de database en bieden de middelen die nodig zijn om gemakkelijk vanuit de Java-taal met de database te communiceren. Maar het probleem is dat Java een objectgeoriënteerde taal is. De JDBC biedt kern-API's voor database-interactie en is niet gericht op het transformeren van de rij- en kolomstructuur van de databasetabel in een entiteitsklasse. Daarom wordt gezocht naar een laag API die boven de JDBC API werkt. De persistentie-API, of JPA, verzacht twee architectonisch verschillende modellen met als doel de soepelheid van de werking te benutten. De API helpt bij het weergeven van een databaserelatietabel als een POJO en kan op dezelfde manier worden behandeld door de hele Java-code. De kern JDBC API werkt op de achtergrond om de fijne kneepjes van communicatie en databaseverbinding aan te pakken, terwijl JPA de transacties mogelijk maakt volgens de objectgeoriënteerde code van de Java-taal. Het in kaart brengen van gegevens tussen relationele database en Java is echter geen gemakkelijke taak.
Ondersteuning voor Java-persistentie
In een typische relationele database wordt informatie opgeslagen in een rij- en kolomstructuur. De uitwisseling van gegevens tussen een databasesysteem en het objectmodel van de Java-toepassing is moeilijk omdat Java een enkele entiteit aanwijst als een klasse die wordt aangegeven door een reeks eigenschappen en bewerkingen die erop worden toegepast. Daarom moet een Java-programmeur, om een gedragsafwijking tussen de twee verschillende architecturen aan te passen, veel regels code schrijven. Deze regels code helpen de rij- en kolomgegevens van de databasetabel om te zetten in Java-objecten. Maar vaak worden deze coderegels te repetitief, waardoor de broncode vol staat met standaardcodes. Dit is onwenselijk en in strijd met het objectgeoriënteerde basisprincipe van herbruikbaarheid. Hoewel slimme codes veel van de tegenslagen kunnen verzachten, is het geen gemakkelijke oplossing. De opkomst van oplossingen van derden is een verademing bij het in kaart brengen van databasegegevens in Java-objecten, maar ze waren niet standaard. De implementatie van elke leverancier verschilde aanzienlijk van de andere. Dit alles betekent dat de situatie een standaard persistentie-API-bibliotheek vereiste van het Java-platform zelf. Dit leidde tot de introductie van Java Persistence API (JPA), vooral om de kloof te overbruggen tussen het objectgeoriënteerde domeinmodel van Java en het databasesysteem.
Eigen oplossingen
Begrijp dat object-relationele oplossingen al geruime tijd bestaan, zelfs vóór de geboorte van de Java-taal zelf. Zo begon het TopLink-product van Oracle eigenlijk met Smalltalk en stapte later over op Java. Tegenwoordig maakt het deel uit van de OracleAS-, WebLogic- en OC4J-servers. In feite waren de twee meest populaire persistentie-API's Oracle's TopLink, een propriëtaire standaard in het commerciële domein, en Hibernate in het open source community-domein. Later werd Hibernate populairder en beïnvloedde het sterk de oprichting van de standaard JPA-bibliotheek.
Datamappers
Een data mapper is in feite een architectonisch patroon voorgesteld door Martin Fowler in zijn boek Patterns of Enterprise Application Architecture , 2003. Het biedt een gedeeltelijke manier om het object-relationele probleem aan te pakken. De mapper helpt bij het creëren van een strategie die valt in de categorie tussen gewone JDBC en een volledig functionele oplossing voor relationele objecttoewijzing. Hier maken applicatieontwikkelaars een onbewerkte SQL-string om databasetabellen toe te wijzen aan Java-objecten met behulp van de data mapper-methode. Er is een populair raamwerk dat gebruikmaakt van deze techniek van mapping tussen SQL-database en Java-object, genaamd Apache iBatis. Het Apache iBatis-project is nu inactief verklaard. De oorspronkelijke makers van Apache iBatis hebben het project echter overgedragen aan MyBatis en wordt actief ontwikkeld.
In tegenstelling tot andere object-relationele probleemoplossingen die gebruik maken van het datamappers-framework zoals MyBatis, kunnen we volledige controle hebben over SQL-transacties met de database. Het is een lichtgewicht oplossing en heeft niet de overhead van een volledig ORM-framework. Maar er is een probleem met datamappers. Wijzigingen in het objectmodel hebben gevolgen voor het datamodel. Als gevolg daarvan moeten er direct belangrijke wijzigingen in de SQL-instructies worden aangebracht. Het minimalistische karakter van het framework helpt ontwikkelaars om nieuwe veranderingen en aanpassingen door te voeren naar behoefte. Datamappers zijn met name handig in een situatie waarin we een minimaal raamwerk, expliciete SQL-verwerking en meer controle nodig hebben voor het aanpassen van ontwikkelaars.
JDBC
De JDBC (Java Database Connectivity) is een Java-specifieke versie van de ODBC-specificatie (Object Database Connectivity) van Microsoft. De ODBC is een standaard voor het verbinden van elke relationele database vanuit elke taal of platform. JDBC biedt vergelijkbare abstractie met betrekking tot de Java-taal. JDBC gebruikt SQL voor interactie met de database. Ontwikkelaars moeten DDL- of DML-query's schrijven volgens de syntactische specificatie van de backend-database, maar ze verwerken met behulp van het Java-programmeermodel. Er is een nauwe koppeling tussen de Java-bron en de SQL-statements. We kunnen onze toevlucht nemen tot onbewerkte SQL-statements en deze naar behoefte statisch manipuleren. Vanwege het statische karakter is het moeilijk om wijzigingen op te nemen. Bovendien verschillen SQL-dialecten van databaseleverancier tot database. JDBC is vast verbonden met de database en niet met het objectmodel van de Java-taal. Daarom voelt het al snel omslachtig om mee te werken, vooral wanneer de database-interactie van de Java-broncode toeneemt. JDBC is echter de primaire ondersteuning voor databasepersistentie in Java en vormt de basis voor frameworks op hoog niveau.
EJB
De Enterprise Java Bean (EJB) met J2EE bracht enkele nieuwe veranderingen in de arena van Java-persistentie in de vorm van de entiteitsboon. Het idee was om ontwikkelaars te isoleren van direct ingrijpen in de fijne kneepjes van databasepersistentie. Het introduceerde een interface-gebaseerde aanpak. Er is een gespecialiseerde bean-compiler om de implementatie te genereren voor persistentie, transactiebeheer en delegatie van bedrijfslogica. Er werden gespecialiseerde XML-implementatiedescriptors gebruikt om de entiteitbeans te configureren. Het probleem is dat EJB, in plaats van dingen te vereenvoudigen, veel complexiteit heeft ingebouwd. Als gevolg hiervan verloor het, ondanks talrijke latere verbeteringen, zoals de introductie van Enterprise JavaBeans Query Language (EJB QL), al snel aan populariteit.
Java-gegevensobject
De JDO (Java Data Object) probeerde het probleem van het EJB-persistentiemodel aan te pakken. Het biedt een API voor transparante persistentie en is ontworpen om te werken met EJB en J2EE. JDO is een product dat sterk wordt beïnvloed en ondersteund door objectgeoriënteerde databases. Persistentie-objecten zijn gewone Java-objecten waarvoor geen ontwikkelaar een speciale klasse of interface hoeft te implementeren. Objectpersistentiespecificaties worden doorgaans gedefinieerd in een XML-metabestand. De ondersteunde querytalen zijn objectgeoriënteerd van aard. Ondanks de vele goede eigenschappen kon de JDO-specificatie niet veel acceptatie krijgen bij de ontwikkelaarsgemeenschap.
Java Persistence API
Er waren een aantal propriëtaire persistentiekaders, zowel in het commerciële domein als in het open source-domein. Frameworks zoals Hibernate en TopLink leken goed aan de applicatiebehoefte te voldoen. Als gevolg hiervan werd Hibernate gekozen als primaire basis voor het maken van een standaard persistentiemodel genaamd JPA.
JPA is een standaard lichtgewicht Java-persistentieraamwerk dat helpt bij het maken van relationele toewijzing van objecten met behulp van POJO. JPA helpt ook om persistentie te integreren in een schaalbare bedrijfstoepassing. Het is gemakkelijk te gebruiken omdat er slechts een klein aantal klassen is die moeten worden blootgesteld aan een toepassing die geïnteresseerd is in het gebruik van het JPA-persistentiemodel. Het gebruik van een POJO is misschien wel het meest intrigerende aspect van JPA. Het betekent dat er niets bijzonders aan het object is; dat maakt het houdbaar. De object-relationele mapping is metadata gedreven. Dit kan worden gedaan door intern binnen de code of extern annotaties te gebruiken. door XML te gebruiken.
De persistente API's van JPA bestaan als een aparte laag van het persistente object. De bedrijfslogica roept meestal de API aan en geeft het persistente object door om erop te werken. Hoewel de applicatie op de hoogte is van de persistente API, is het persistente object, zijnde POJO, zich totaal niet bewust van zijn persistentievermogen.
Conclusie
Dit artikel gaf een overzicht van enkele van de propriëtaire oplossingen die beschikbaar waren vóór de introductie van JPA, zoals data mapper, JDBC en EJB. Het idee is om inzicht te geven in wat leidde tot de oprichting van JPA, en een beetje over de hardnekkige techniek van zijn voorganger. Blijf kijken; volgende artikelen gaan dieper in op meer specifieke aspecten van de JPA API.