Over the last weeks I’ve worked on an example application that demonstrates how Java EE developers can get started with microservices. The application is a full end-to-end sample which includes a web application, business logic, authentication and now also persistence. It runs on Kubernetes and Istio and there are scripts to easily deploy it.
Get the cloud-native-starter code from GitHub.
Java Persistence API
In the example I use a full open source Java stack with OpenJ9, OpenJDK, Open Liberty and MicroProfile. In order to deploy the microservices to Kubernetes, I’ve created an image. Read my article Dockerizing Java MicroProfile Applications for details.
Open Liberty provides some pretty good guides. One guide is specifically about JPA: Accessing and persisting data in microservices. I don’t want to repeat everything here, but only highlight the changes I had to do to run this functionality in a container, rather than via a local Open Liberty installation.
Here is a short description of JPA:
JPA is a Java EE specification for representing relational database table data as Plain Old Java Objects (POJO). JPA simplifies object-relational mapping (ORM) by using annotations to map Java objects to tables in a relational database. In addition to providing an efficient API for performing CRUD operations, JPA also reduces the burden of having to write JDBC and SQL code when performing database operations and takes care of database vendor-specific differences.
Configuration of the Sample Application
The following diagram shows the simplied architecture of the cloud-native-starter example. A web application invokes through Ingress the Web-API service that implements a backend-for-frontend pattern. The Web-API service invokes the Articles service which stores data in a SQL database on the IBM Cloud. Obviously you can use any other SQL database instead.
In order to access the Db2 on the IBM Cloud, first the driver needs to be downloaded via Maven. Note that the driver does not go into the war files together with the business logic of the microservices, but it needs to be copied in a certain Open Liberty directory: /opt/ol/wlp/usr/shared/resources/jcc-11.1.4.4.jar
Next you need to define in server.xml information about the driver and the data source.
<server description="OpenLiberty Server">
<featureManager>
<feature>webProfile-8.0</feature>
<feature>microProfile-2.1</feature>
</featureManager>
<httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="8080" httpsPort="9443"/>
<library id="DB2JCCLib">
<fileset dir="${shared.resource.dir}" includes="jcc*.jar"/>
</library>
<dataSource id="articlejpadatasource"
jndiName="jdbc/articlejpadatasource">
<jdbcDriver libraryRef="DB2JCCLib" />
<properties.db2.jcc databaseName="BLUDB"
portNumber="50000"
serverName="DB2-SERVER"
user="DB2-USER"
password="DB2-PASSWORD" />
</dataSource>
</server>
Next the persistence unit needs to be define in persistence.xml.
The tricky part was for me to figure out the right location for this file. In order for all Maven versions to build it correctly I put it in ‘src/main/resources/META-INF/persistence.xml’. This produces an articles.war file with the internal structure ‘classes/META-INF/persistence.xml’.
<persistence version="2.2"
xmlns="http://xmlns.jcp.org/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence
http://xmlns.jcp.org/xml/ns/persistence/persistence_2_2.xsd">
<persistence-unit name="jpa-unit" transaction-type="JTA">
<jta-data-source>jdbc/articlejpadatasource</jta-data-source>
<properties>
<property name="eclipselink.ddl-generation" value="create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="both" />
</properties>
</persistence-unit>
</persistence>
Usage of JPA in Java
Once all the configuration has been done, writing the Java code is simple.
First you need to define the Java class which represents the entries in a table. Check out the code of ArticleEntity.java with the five columns id, title, url, author and creation date. As defined in persistence.xml this table is created automatically.
The CRUD operations for articles are defined in ArticleDao.java. The code is pretty straight forward. The only thing that confused me, was that I have to begin and commit transactions manually for the create operation. In the Open Liberty sample this was not necessary. I’m trying to find out what the difference is.
In JPADataAccess.java the logic is implemented to add and read articles. The ArticleDao is injected. Again, the code looks simple. The lesson that I learned here is, that dependency injection only seems to work when the upper layers that invoke this code use dependency injection and @ApplicationScoped as well.
How to run the Example
I’ve written scripts to create the SQL database and create the Articles service. Check out the documentation to run the sample yourself on Minikube or the IBM Cloud Kubernetes Service.
Once installed the OpenAPI API Explorer can be used to create a new article.
The table is displayed in the Db2 console.
The data in the table can be displayed in the console as well.
To learn more about microservices built with Java and MicroProfile, check out the cloud-native-starter repo.
Top comments (2)
Curious why would Open Liberty uses Eclipselink properties!Does one have to add Eclipselink ORM dependencies as well ?
If that's the case I would be happily using Eclipselink ORM as JPA vendor and which is more powerful with enterprise level features.
Any thoughts ?
"eclipselink.ddl-generation"
"eclipselink.ddl-generation.output-mode"
Okay! I think now I know the reason,IBM open sourced Open Liberty from Websphere Liberty profile server and they made Eclipselink as their default JPA provider.Hence the eclipselink props!