Die Jakarta NoSQL Spezifikation hat das Ziel den Zugriff auf NoSQL-Datenbanken zu vereinheitlichen. Wollte man bisher bspw. eine MongoDB in seine Enterprise-Anwendung integrieren, musste man den proprietären Client dazu verwenden. Dieser arbeitete mit den entsprechenden Datentypen der MongoDB und den entsprechenden Zugriffsmechanismen. Damit verbunden ist immer eine Einarbeitung in die entsprechenden Eigenheiten eines solchen Clients.
Jakarta NoSQL liegt nun in einer ersten produktiven Version vor und wird voraussichtlich mit dem nächsten Jakarta EE 11 Release im nächsten Jahr veröffentlicht. In diesem Blogbeitrag möchte ich ein einfaches Beispiel für die Anbindung an eine dokumentenorientierte NoSQL-Datenbank beschreiben.
Document API
Wie üblich im Persistenzumfeld starten wir mit einer Entität:
@Entity
public class Customer {
@Id
private long id;
@Column
private String name;
@Column
private String street;
@Column
private String postcode;
@Column
private String city;
}
Der Zugriff auf die Datenbank kann nun entweder über eine Template-Klasse (DocumentTemplate) erfolgen. Oder es kann auf Basis der Jakarta Data Spezifikation ein Repository-Ansatz für den Zugriff gewählt werden.
Jakarta Data
Mit der Jakarta Data Spezifikation wurde ein vereinheitlichter Zugriff auf unterschiedliche Datenquellen definiert. Damit ist es möglich eine Implementierung auf Basis eines Interfaces automatisch generieren zu lassen.
@Repository
public interface CustomerRepository extends CrudRepository<Customer, Long> {
public List<Customer> findByName(String name);
}
Das CrudRepository-Interface definiert dabei die grundlegenden Zugriffsmethoden. Alle weiteren Methoden kann ich über eine entsprechende Namenskonvention ebenfalls automatisch implementieren lassen.
Die Verwendung kann dann einfach über eine DI an gewünschter Stelle erfolgen:
@Inject
CustomerRepository customerRepository;
...
customerRepository.findByName("Horst");
Fazit
Die Kombination von Jakarta NoSQL und Jakarta Data ermöglicht den einfachen Einsatz von NoSQL-Datenbanken in Enterprise-Anwendungen. Über die Vereinheitlichung der NoSQL-Persistenzschicht und der Daten-Zugriffsschicht ist eine herstellerunabhängige Nutzung von NoSQL möglich.
Das Beispiel befindet sich in unserem Github-Repository.
