Jakarta NoSQL: What You Need to Know
Jakarta EE picks up where Java EE 8 left off, but the roadmap going forward will be focused on modern innovations such as microservices, modularity, and NoSQL databases.
The Jakarta NoSQL specification simplifies integration between Java applications and NoSQL databases by providing a common API that works with different types of NoSQL databases and different vendors’ database versions.
To achieve this simplification, the spec has two layers:
- Communication API: This API provides the same capabilities as Java Database Connectivity (JDBC) provides to SQL. It has four specializations, one for each type of database — column, document, key-value, and graph. Each specialization is independent from the others, optional for database vendors, and has its own technology compatibility kit (TCK).
- Mapping API: This is the API developers should use to integrate their Java application into a database. It is based on Annotations and Contexts and Dependency Injection (CDI), and it preserves integration with other Jakarta EE technologies, such as Bean Validation.
Figure 1 shows the two Jakarta NoSQL layers, their relationship to one another, and to the four database types.
Figure 1: Jakarta NoSQL Layers in Context
Choosing a NoSQL Database
Vendor lock-in is one of the key factors Java developers must consider when choosing a NoSQL database. If you’re switching from one database to another, considerations also include the:
- Amount of time required to make the change
- Learning curve required to use a new API with the database
- Code that will be lost
- Persistence layer that needs to be replaced
Jakarta NoSQL avoids most of these issues through its Communication API. Jakarta NoSQL also provides template classes that apply the design pattern “template method” to database operations.
In addition, the Jakarta NoSQL Repository interface allows Java developers to create and extend interfaces, with implementation automatically provided by Jakarta NoSQL. This means the support method queries you build are automatically implemented for you.
Figure 2 shows four document NoSQL databases.
Figure 2: Four Document NoSQL Databases and Their Unique Syntax
Each code snippet shown in Figure 2 is doing the same thing — creating a document, a tuple with a name, and the information itself — with the same behavioral goal. But, each database uses a different class, method name, and so on. If you want to move your code from one database to another, you need to learn a new API and update all of the database code to the new database API code target.
With the Jakarta NoSQL Communication API, you can use driver databases that look like JDBC drivers to quickly and easily switch between NoSQL databases. This ability also makes it easier to learn about the software architecture of a new NoSQL database. Figure 3 illustrates the concept.
Figure 3: Common Jakarta NoSQL Code for Different Document Databases
Considerations for Converting a Jakarta NoSQL Application to Cloud Native
When it comes time to convert your Jakarta NoSQL application to cloud native, there are several factors to consider, including which best practices to follow to avoid mistakes and code smell.
As far as we know, there aren’t best practices related specifically to cloud native development. However, there are patterns from agile, microservices, and the twelve-factor app that are useful to follow to help ensure you develop a healthy, pain-free application.
I recommend familiarizing yourself with the aspects of the twelve-factor app, as well as the Manifesto for Agile Software Development and the concepts of continuous integration, continuous delivery, and domain-driven design.
The most well-known practices related to any application that includes cloud computing are inspired by Martin Fowler’s book, Patterns of Enterprise Application Architecture.
About the Author
