Jakarta Data Is Simplifying Data Integration for Java Enterprise Applications

Software is such a crucial component of our everyday lives that many of us forget it was once a new and limited technology. In the earliest days of software development, it was the province of specialists. Today, software is everywhere and inextricably embedded into every aspect of our personal and working lives. 

The same is rapidly becoming true of data. Every modern enterprise is trying to figure out how best to gather, sort, analyse, and monetise the data it collects, whether it’s a retailer figuring out how to market the right products to the right customers or healthcare operations tracking metrics around patient recovery times and medication expenditures. 

But figuring this out isn’t necessarily an easy process. Developing enterprise applications for data management can be complex and cumbersome, demanding that developers learn the ins and outs of the APIs of multiple SQL and NoSQL databases. This is why we’re developing the Jakarta Data specification for Jakarta EE. 

Support Flexible Codebase Use Without Sacrificing Interoperability

There is a plethora of database options supported by Jakarta EE, each with its own strengths: 

• Relational databases are an excellent choice to sort out complex relationships within and between structured data. 
• NoSQL databases better support unstructured data. 
• NewSQL databases offer many of the strengths of both. 

This diversity of options has led to the proliferation of individual microservices within a single software stack leveraging different database technologies, known as polyglot persistence. While this has numerous benefits for making enterprise applications more effective, it places considerable strain on developers. Each database has its own API that developers need to understand to use it. 

This is where Jakarta Data comes in. By elevating the persistence layer in Jakarta EE (Figure 1), it provides developers the ability to develop and use polyglot persistence applications using a single, vendor neutral API. This greatly simplifies the process of both developing and using these applications, as developers only need to work with one API rather than several. 

Figure 1: Jakarta Data specification integration in persistence layer

Crucially, developers are also able to explore these integrations from a single interface, rather than having to toggle between different databases. This simplifies how they use and develop applications that leverage different databases, enhancing the flexibility and effectiveness of those applications without adding additional work complexity. 

First Version Will Offer Basic Capabilities

The Jakarta Data specification project is still a new project, though we’re planning to have a release available this year. 

The focus is currently on ensuring that the specification has all the basic capabilities and functionality it needs. One of the main ones we’re working on is the implementation of the repository pattern. The idea here is that because Jakarta Data is ultimately meant to help developers build and use enterprise applications, it must be able to get as close as possible to domain-specific language. For example, if you’re developing an application for a winery, you need to be able to recognise terms like “wine,” “order,” or “buy.” 

What the repository pattern provides is an abstraction you can use to explore the database. It also provides support for pagination. As a result, it becomes much easier to insert and retrieve information. You can search via domain-specific language, allowing you to make specific adjustments to your code that are domain-relevant more easily while also making them easier to find later. And pagination simplifies the presentation of the information, making it easier to interpret accurately. 

The first release of Jakarta Data will include support for three repository servers, including a basic repository with the basic capability outlined above, and a CRUD repository, which provides several capabilities, such as a custom repository interface, allowing you to create your own domain language through annotations. 

Enhanced Capabilities and Interaction With Persistence Layer to Come

This is just the beginning. Making use of the diversity of the persistence layer is the most crucial element of achieving the Jakarta Data project’s goal of a fully data-driven design approach. 

As such, there’s plenty already in the works for future versions of the Jakarta Data specification. The focus is mainly going to be on quality-of-life improvements and enhancements to the core functionality that Jakarta Data will launch with. The overall goal is to ensure that the Jakarta Data specification provides a single interface capable of connecting to and managing every database necessary for the full management of polyglot persistence. Developers will only need to know the API for Jakarta Data and will be able to access the full spectrum of utilities every different database type offers. 

Goal to Launch With Jakarta EE 11

We’re hoping to be able to launch Jakarta Data with the release of Jakarta EE 11, which is expected by the end of Q2. This means that we’re mostly finished with the basic layout of the specification itself. 

But Jakarta Data still has a lot of untapped potential to be developed. It has the potential to be able to greatly simplify the lives of developers while coding within a persistence layer. They’ll be able to make their code more flexible and more easily harness, interpret, and use data generated within their organisation. 

We encourage the community to get involved. Sign up for the mailing list to keep up to date on the project. Have a look at the GitHub page and see which issues are there and maybe create one on your own. And join us on Twitter, Facebook, LinkedIn, and YouTube to give us your feedback.