Exploring Seamless Integration: Jakarta Data and Jakarta Persistence in Jakarta EE 11 With Open Liberty

In the ever-evolving landscape of enterprise Java, the seamless interaction between various specifications plays a pivotal role in shaping the architecture of modern applications. One such integration that garnered significant attention is between Jakarta Data and Jakarta Persistence, the latest evolution of the former Java Persistence API (JPA). The integration of Jakarta Data and Jakarta Persistence brings forth a unified approach to handling data, making application development more efficient, flexible, and aligned with the demands of contemporary software design.

In this article, we embark on a journey to delve into the intricacies of integrating Jakarta Data and Jakarta Persistence within the Jakarta EE 11 framework. We’ll explore how this integration is a foundation for developing robust and scalable applications. To illustrate the concepts in action, we’ll leverage Open Liberty, an open-source application server that supports the latest Jakarta EE specifications.

Notably, Jakarta Data and Jakarta Persistence are central to Jakarta EE’s evolution, marking the newest specification target within the Jakarta EE 11 release. It signifies a significant step forward in enterprise Java, as these specifications collectively provide an integrated and streamlined approach to data management that aligns with the modern needs of developers and applications. So, let’s embark on this journey of discovery as we uncover the synergy between Jakarta Data and Jakarta Persistence and witness their implementation within the robust environment of Open Liberty.

Understanding Database Solutions: SQL, NoSQL, and NewSQL

In the world of data management, various database solutions have emerged to cater to the diverse needs of modern applications. These solutions can be broadly categorized into three main types: SQL, NoSQL, and NewSQL. Each database type has strengths, weaknesses, and use cases, shaping how developers approach data storage and retrieval. In this session, we’ll explore the differences between these database solutions and how the Jakarta Data specification simplifies integrating and handling these diverse options within a unified persistence layer.

Distinguishing Characteristics of Database Solutions

To better understand the differences between SQL, NoSQL, and NewSQL databases, let’s summarize their key characteristics in the following table:

Common Points and Jakarta Data’s Role

Despite their differences, SQL, NoSQL, and NewSQL databases share some common challenges for developers, such as managing various data models, integrating with different query languages, and ensuring adequate data persistence. 

As part of the Jakarta EE ecosystem, Jakarta Data aims to provide a standard API for data access and manipulation. It is a unifying layer that abstracts the intricacies of working with different database solutions. Here’s how Jakarta Data assists developers in handling various databases:

1. Unified API: Jakarta Data offers a consistent API that developers can use to interact with different database types, regardless of whether they use SQL, NoSQL, or NewSQL solutions. It simplifies development and reduces the need to learn and manage multiple data access APIs.
2. Query abstraction: With Jakarta Data, developers can uniformly write database queries, abstracting the differences in query languages between SQL, NoSQL, and NewSQL databases. It streamlines the development process and minimizes the learning curve for developers switching between database types.
3. Transaction management: Jakarta Data provides transaction management capabilities that ensure data consistency and integrity, even when dealing with databases with varying transaction support.

The Jakarta Data specification is pivotal in simplifying, integrating, and managing different database solutions within a Jakarta EE application. By offering a unified approach to data access, adaptive mapping, query abstraction, and transaction management, Jakarta Data empowers developers to focus on building robust and efficient applications without getting bogged down by the complexities of various database technologies.

Demonstrating Jakarta Data and Jakarta Persistence Integration With PostgreSQL

In this session, we will integrate Jakarta Data and Jakarta Persistence to work with a PostgreSQL database. We’ll cover setting up a PostgreSQL instance locally using Docker, generating a Maven project configuration, creating entity models with Jakarta Persistence annotations, implementing a repository with Beer-related queries, and developing a resource to interact with the database.

1. Setting Up PostgreSQL Locally

Before we dive into the integration, we need a PostgreSQL instance. You can run PostgreSQL locally using Docker with the following commands:

docker pull postgres:15.3
docker run -e POSTGRES_PASSWORD=openliberty -p 5432:5432 -d postgres

2. Generating Maven Project Configuration

You can generate the Maven project configuration from the MicroProfile Starter using Open Liberty. Make sure to use the beta version of the project configuration, as Open Liberty is compatible with it. You can check this pom.xml as a double check.

3. Creating Entity Models

Using Jakarta Persistence annotations, we’ll create two entity models: Beer and Address. The Beer entity will have a one-to-one relationship with the Address entity.

@Entity
@JsonbVisibility(FieldVisibilityStrategy.class)
public class Beer {
    // ... (other fields)

    @OneToOne(cascade = CascadeType.ALL)
    @JoinColumn(name = "address_id", referencedColumnName = "id")
    private Address address;
    // ... (other fields)
}

@Entity
@JsonbVisibility(FieldVisibilityStrategy.class)
public class Address {
    // ... (fields)
}

4. BeerRepository Creation

Create the BeerRepository interface, which extends PageableRepository<Beer, String>. Define query methods that fetch beers based on various criteria.

@Repository
public interface BeerRepository extends PageableRepository<Beer, String> {
    Page<Beer> findByHopOrderByName(String hop, Pageable pageable);
    Page<Beer> findByMaltOrderByName(String malt, Pageable pageable);
    Page<Beer> findByMaltAndHopOrderByName(String malt, String hop, Pageable pageable);
}

5. BeerResource Implementation

Develop the BeerResource class that interacts with the repository and handles API requests. The repository handles query implementations based on conventions.

@ApplicationScoped
@Path("beers")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class BeerResource {
    private final BeerRepository repository;

    @Inject
    public BeerResource(BeerRepository repository) {
        this.repository = repository;
    }

    @GET
    public List<Beer> findByAll(@BeanParam BeerParam param) {
        // Handle different query scenarios
    }

    @POST
    public void create(Beer beer) {
        this.repository.save(beer);
    }

    @DELETE
    @Path("{id}")
    public void deleteById(@PathParam("id") String id) {
        this.repository.deleteById(id);
    }

    @Path("random")
    @POST
    public void random() {
        // Generate and save random beer data
    }
}

6. Testing API with cURL Commands

You can now test the API using cURL commands to interact with the resources you’ve implemented.

With these steps, we’ve demonstrated how to integrate Jakarta Data and Jakarta Persistence to work seamlessly with PostgreSQL. The Jakarta Data specification facilitates easy interaction with different database solutions, abstracting complexities and enabling developers to focus on building robust applications without worrying about the intricacies of various database technologies.

Get All Beers:

curl -X GET "http://localhost:9080/beers" -H "accept: application/json"

Get Beers by Hop:

curl -X GET "http://localhost:9080/beers?hop=yourHop" -H "accept: application/json"

Get Beers by Malt:

curl -X GET "http://localhost:9080/beers?malt=yourMalt" -H "accept: application/json"

Get Beers by Malt and Hop:

curl -X GET "http://localhost:9080/beers?malt=yourMalt&hop=yourHop" -H "accept: application/json"

Create a Beer:

curl -X POST "http://localhost:9080/beers" -H "accept: application/json" -H "Content-Type: application/json" -d '{
  "name": "Beer Name",
  "style": "Style",
  "hop": "Hop",
  "yeast": "Yeast",
  "malt": "Malt",
  "user": "User"
}'

Delete a Beer by ID:

curl -X DELETE "http://localhost:9080/beers/yourBeerId" -H "accept: application/json"

Generate Random Beers:

curl -X POST "http://localhost:9080/beers/random" -H "accept: application/json"

Conclusion

In this comprehensive article, we embarked on a journey to explore the integration between Jakarta Data and Jakarta Persistence, showcasing their seamless interaction within the Jakarta EE 11 framework using Open Liberty. We delved into the differences between various database solutions, including SQL, NoSQL, and NewSQL, highlighting developers' challenges when handling different data models, query languages, and persistence mechanisms. This set the stage for understanding the significance of Jakarta Data and Jakarta Persistence in simplifying these complexities.

We started by setting up a PostgreSQL instance using Docker. Then we illustrated the step-by-step process of integrating Jakarta Data and Jakarta Persistence within the Jakarta EE ecosystem. From generating a Maven project configuration to modeling entity relationships using Jakarta Persistence annotations and finally implementing a repository and resource for data manipulation, we demonstrated the practical aspects of utilizing Jakarta Data and Jakarta Persistence in a real-world scenario.

The Jakarta Data specification proved a pivotal enabler, offering a standardized data access and manipulation API. By abstracting the nuances of different database solutions, Jakarta Data empowers developers to seamlessly switch between SQL, NoSQL, and NewSQL databases without learning multiple data access APIs. The ease of query abstraction, adaptive mapping, and transaction management showcased the benefits of using Jakarta Data, allowing developers to focus on building robust and efficient applications.

In closing, the integration between Jakarta Data and Jakarta Persistence represents a significant advancement in the Jakarta EE ecosystem, providing developers with a unified and streamlined approach to data management. As technology landscapes continue to evolve, Jakarta Data and Jakarta Persistence stand as pillars, ensuring that the challenges of data persistence and access are met with a consistent and efficient solution. With the tools and insights provided in this article, developers are well-equipped to embrace the potential of Jakarta Data and Jakarta Persistence as they continue to shape the future of enterprise Java application development.

References

• Source code
• Jakarta Data Repo
• Jakarta Data Spec