Jakarta NoSQL is a Java framework that streamlines the integration of Java applications with NoSQL databases.
The project has two layers that define communication with NoSQL databases through APIs. These are:
-
Mapping Layer: This layer is annotation-driven and uses technologies such as Jakarta Contexts and Dependency Injection and Jakarta Bean Validation, making it simple for developers to use. In the traditional RDBMS world, this layer may be compared to the Java Persistence API or object-relational mapping frameworks such as Hibernate.
-
Communication Layer: This layer contains four modules, one for each NoSQL database type: Key-Value, Column Family, Document and Graph. In the traditional the RDBMS world, this layer may be compared to the JDBC API.
This clearly helps to achieve very low application coupling with the underlying NoSQL technologies used in applications.
Jakarta NoSQL defines an API for each NoSQL database type. However, it uses the same annotations to map Java objects. Therefore, with just these annotations that look like JPA, there is support for more than twenty NoSQL databases.
@Entity
public class Deity {
@Id
private String id;
@Column
private String name;
@Column
private String power;
//...
}Vendor lock-in is one of the things any Java project needs to consider when choosing NoSQL databases. If there is a need to switch out a database, other considerations include: time spent on the change; the learning curve of a new database API; the code that will be lost; the persistence layer that needs to be replaced, etc. Jakarta NoSQL avoids most of these issues through the APIs of Communication and Mapping Layers.
Jakarta NoSQL also has template classes that apply the design pattern 'template method’ to databases operations. And the Repository interface allows Java developers to create and extend interfaces, with implementation automatically provided by a Jakarta NoSQL implementation: support method queries built by developers will automatically be implemented for them.
public interface DeityRepository extends Repository<Deity, String> {
Optional<Deity> findById(String id);
Optional<Deity> findByName(String name);
}SeContainer container = SeContainerInitializer.newInstance().initialize()
Service service = container.select(Service.class).get();
DeityRepository repository = service.getDeityRepository();
Deity diana = Deity.builder()
.withId("diana")
.withName("Diana")
.withPower("hunt")
.build();
repository.save(diana);
Optional<Deity> idResult = repository.findById("diana");
Optional<Deity> nameResult = repository.findByName("Diana");JPA is a good API for object-relational mapping and has established itself as a standard in the Java world defined in JSRs. It would be ideal to use the same API for both SQL and NoSQL, but there are behaviors in NoSQL that SQL does not cover, such as time to live and asynchronous operations. JPA was simply not designed to handle those features.
ColumnTemplate template = // instance;
Deity diana = Deity.builder()
.withId("diana")
.withName("Diana")
.withPower("hunt")
.build();
Duration ttl = Duration.ofSeconds(1);
template.insert(diana, ttl);Jakarta NoSQL is a fluent API for Java developers to more easily create queries that either retrieve or delete information in a Document database type, for example.
DocumentTemplate template = // instance; a template to document NoSQL operations
Deity diana = Deity.builder()
.withId("diana")
.withName("Diana")
.withPower("hunt")
.build();
template.insert(diana);// insert an entity
DocumentQuery query = select()
.from(Deity.class)
.where("name")
.eq("Diana")
.build(); // SELECT Deity WHERE name equals “Diana”
List<Deity> deities = template.select(query); // execute query
DocumentDeleteQuery delete = delete()
.from("deity").where("name")
.eq("Diana")
.build(); // delete query
template.delete(delete);The Communication Layer defines three new APIs: Key-Value, Document and Column Family. It does not have new Graph API, because a very good one already exists. Apache TinkerPop is a graph computing framework for both graph databases (OLTP) and graph analytic systems (OLAP). Using Apache TinkerPop as Communication API for Graph databases, the Mapping API has a tight integration with it.
Particular behavior matters. Even within the same type, each NoSQL database has a unique feature that may be a considerable factor when choosing one database over another. This ‘’feature’’ might make it easier to develop, make it more scaleable or consistent from a configuration standpoint, have the desired consistency level or search engine, etc. Some examples include: Cassandra and its Cassandra Query Language and consistency level; OrientDB with live queries; ArangoDB and its Arango Query Language; Couchbase with N1QL; etc. Each NoSQL database has a specific behavior and this behavior matters, so Jakarta NoSQL was designed to be extensible enough to capture these substantially different feature elements.
public interface PersonRepository extends CouchbaseRepository {
@N1QL("select * from Person")
List<Person> findAll();
@N1QL("select * from Person where name = $name")
List<Person> findByName(@Param("name") String name);
}
Person person = // instance;
CassandraTemplate template = //instance;
ConsistencyLevel level = ConsistencyLevel.THREE;
template.save(person, level);-
Simple APIs supporting all well-known NoSQL storage types - Column Family, Key-Value Pair, Graph and Document databases.
-
Use of Convention Over Configuration
-
Easy-to-implement API Specification and Technology Compatibility Kit (TCK) for NoSQL Vendors
-
The APIs focus is on simplicity and ease of use. Developers should only have to know a minimal set of artifacts to work with Jakarta NoSQL. The API is built on Java 8 features like Lambdas and Streams, and therefore fits perfectly with the functional features of Java 8+.