In this talk, we will delve into the complexities of managing data in enterprise Java applications. Effective data management is crucial for maintaining the integrity, availability, and security of enterprise systems. Attendees will gain a deep understanding of various aspects related to data management, including data modeling, persistence frameworks, caching strategies, scalability, and data synchronization. Through real-world examples and best practices, this session aims to equip developers with the knowledge and tools necessary to efficiently handle data in their Java applications.

2. Managing Data in
Jakarta EE
Applications

3. Who am I?
Buhake Sindi
● Senior Full Stack Java Architect &
Engineer/Developer & Consultant
● Over 17+ years in Enterprise Java
development
● Founded Sindi Technologies (Pty) Ltd
● Founded Devoxx4Kids South Africa
(NPO)
● Jakarta EE Ambassador
● Blogger (DZone Core Member)
● Runner, Beat Maker, Podcaster?

4. Where can you find me?
https://linktr.ee/theEliteGentleman
buhake@gmail.com
www.sindi.co.za
X: @EliteGentleman
Also

5. Table of contents
Handling data in
the early days
Isolating data
from your
application
Repository
Pattern in
current Jakarta
EE release
Repository in
future release of
Jakarta EE
01 02
03 04

6. Table of contents
Demo
examples
Q&A
05
06

7. Handling data in
the early days…
01

8. Early days…
Monolithic architecture
Vendor-specific APIs
All components (presentation,
business & data access) were tightly
integrated into a single deployment
unit.
Early Java EE specifications were not
as standardized as today. App servers
provided their own specific APIs,
making applications tightly coupled to
the specific application server.

9. Enterprise Java
Beans (EJBs)
Early versions of EJBs (particularly EJB 2.x)
heavily depended on implementation of EJB
specific interfaces.
Entity Bean was introduced to represent
persistent data maintained in the database.
● Beans were defined to the persistence
management (BMP or CMP).
Difficult to maintain, less flexible &
portable (as it heavily relied on application
server implementation of EJBs)

10. Challenges…
Limited Separation of concerns
Limited Dependency Injection
Business logic, presentation and
data access were often mixed
Tight integration with JNDI. Also heavy
reliance of XML deployment descriptors
Tight coupling
Limited support for POJOs. Limited code
reusability. Difficulty in testing &
providing mocks.

11. Big shift to
Enterprise
Application
Architecture,
frameworks and
specifications

12. EAA and frameworks
Use of Plain-Old-Java-Objects (POJO),
Plain-Old-Java-Interfaces (POJI)
● Specification: Java Data Objects (JDO)
● Data Access Objects (DAO)
● Frameworks: iBatis/myBatis, TopLink,
jOOQ
● ORM: Hibernate
What’s your flavour? Thus, a needed
vendor-agnostic standardisation was
needed for EAA.

13. Advantages
Portability
Providing a level of
abstraction that is portable
across different data stores.
Consistent API
Standardized API for
interacting with DBs can
help simplify learning curve
for developers & bring
uniform coding style.
Testability
Using POJO, POJI & DI it’s
easier to write unit tests for
business logic.
Separation of
concerns
Isolation of data access
and persistence from
the business logic

14. Challenges
Performance
Overheads
Depending on specific
implementations and
configurations
Learning Curve
For developers who are new
to these concepts.
Boilerplate code
Implementation of various
framework may introduce
boilerplate code for CRUD
Limited industry
adoption
Various frameworks took
widespread adoptions
compared to other
frameworks

15. Further Challenges
Vendor focused
Some queries may result
in vendor specific
queries.
Lack of support
for NoSQL DBs
Debugging &
Profiling
Especially with
generated SQL queries
Tight coupling
E.g. change of DB
Schema

16. Isolating data from
your application
02

17. Purpose
To separate the data layer and
data access logic from the rest
of your application components.

18. Key aspects and principles
● Separation of concerns: Keep data access logic separate from the business logic.
● Testability: Make your data access logic easier to write unit test for your business
logic.
● Encapsulation: Hide the details of data storage and retrieval within data access layer.
● Abstraction: Make use of abstract classes and interfaces to define the contract
between the data access layer and the rest of the applications.
● Data Access Layer: Encapsulate all interactions with Data Access Logic.
● Interfaces for Data Access: Clean and well-defined contract for data access
operations (CRUD).
● Use of Design Pattern: DAO / Repository pattern to structure and isolate data access
logic.
● Dependency Injection: Business Logic should depend on Data Access Logic through
abstraction.
● ORM: Usage of JPA/Hibernate allows interactions through POJOs, while abstracting
database interactions.

19. The Repository pattern
Meets all aspects and principles of data
isolation:
● Data Access Layer.
● Interfaces for Data Access.
● Use of design pattern (also, caching
with strategy pattern?);
● Provides abstraction and loose-
coupling between data access and
rest of your application.

20. Data
Support many data stores
Support of DI
Relational DBs (JDBC, JPA, Hibernate
Session), NoSQL (MongoDB, Redis,
Cassandra)
Through CDI extensions
Query Methods
Via @Query or Criteria APIs
Repository abstraction
Via interfaces: JpaRepository (for JPA),
CassandraRepository (Cassandra), etc.

21. Repository Pattern
in current Jakarta
EE release
03

22. Key aspects
Injectable
With Jakarta CDI @Inject
Testable
Either with jUnit, Mockito, Testcontainers, etc.
Abstractable
Encapsulate Data Access Layer & still
integrate with ORM / JPA, JDBC, etc.
Repository abstraction
Via Repository interface(s)

23. Deltaspike Data
Support many data stores
Support of DI
JPA centric and relational databases.
No NoSQL support.
Through CDI extensions
Query Methods
Via @Query module (with JPQL
queries)
Repository abstraction
Via @Repository annotation on repository
interface (that extends EntityRepository)

24. Custom
approach
Best of both Spring Data and Deltaspike Data approach

25. Domain object
(I) Entity
(I) IdentifiableEntity<ID>
(A) JPAEntity<ID>
(I) CreatedTimestamp
(I) LastModifiedTimestamp
(I) SoftDeletedTimestamp

26. Domain Entity
Domain objects represent the entities or
business objects in the application's
domain. The repository is responsible for
persisting and retrieving these domain
objects. The use of domain objects
ensures that the data access layer
aligns with the application's business
logic.

28. Repository
(I) DataRepository<E>
(I) CrudRepository<E, ID> (I) SpecificationRepository
(I) MicrostreamRepository
(I) JPARepository
(I) Specification<E>
(I) CassandraRepository
(A) AbstractJPARepository

29. The repository pattern is the design pattern, used in software development to create an
abstraction layer between the application’s business logic and the data access code responsible for
interacting with the database or other data sources.
Here’s key component we’ve implemented for our Repository Pattern:
• Repository interface: At the core of the Repository pattern is the interface that defines a
sets of methods for interacting with the data. Each interface abstracts away the data and is
defined for the specific domain entity.
• Super interface: DataRepository
• Sub interface: CrudRepository – Common database operations.
Repository key components

33. • Concrete Repository implementation: The repository interface
is implemented by a concrete class that provides that actual
implementation of that data access logic. This class interacts
with the underlying data store to execute the defined
operations.
Repository key components

36. Making CDI injectable
@Repository annotation
A CDI Stereotype annotation that
makes the class a CDI bean when CDI
is available.
The repository implementation must
be made available via the
@jakarta.inject.Inject annotation.

39. 1. Stateless repository: Can inherit state & transactions from
business services (EJB 3.x)
2. Reduced boilerplate code: Abstract classes have implemented
all common database operations.
3. Entity association: E.g., JPARepository is strongly linked to
JPAEntity
Other features

40. 1. Repository interface allows us to create mock implementations
to be used for testing.
2. Suitable for jUnit, Mockito tests.
Testing

41. Repository in
future release
of Jakarta EE
04

42. Jakarta Data
Jakarta Data defines core APIs
for the Jakarta EE platform
allowing applications and
other Jakarta EE components
to explore the benefits of easy
access to data technologies
such as relational and non-
relational databases, cloud-
based data services, and so
on.

43. Goals:
1. Increase productivity performing common database operations.
2. Rich Object Mapping integrated.
3. Define Repositories.
Still under development:
1. Release will support Jakarta EE 11
2. Specification: https://jakarta.ee/specifications/data/1.0/data-
1.0.0-m1
Jakarta Data 1.0

44. Features:
1. @Repository
2. @Query
3. @Insert, @Update, @Delete
4. @Lifecycle
5. Stateless Repository
6. Built-in interfaces
Jakarta Data 1.0

45. Currently:
1. In beta on OpenLiberty Beta (23.0.0.12-beta)
2. Include data-1.0 as feature in server.xml
Jakarta Data 1.0

47. Demo
examples
05

48. Q&A

49. Thank you!
Do you have any questions?
buhake@gmail.com
www.sindi.co.za