1. Persistence Store
Project Proposal

2. Contents Introduction / Motivation Potential Consumers Scope
High Level Architecture
Software Architecture
API
Differences with MD-SAL

3. Introduction
Framework to implement persistence logic for query-able data.
Modeling data for persistence could be radically different for different data stores (or databases), but interacting with persistence layers is actually very similar.
This framework unifies the common tasks of persisting data so applications follow a systematic method to implement their persistence logic with well-defined abstractions and separation of concerns between business and persistence logic.

4. Motivation Aimed for query-able large data sets.
Support of non-model data: Time Series, Metrics, Historical Data, Aggregated Data, Audit Logs, Alerts, etc.
Allows plunging in different data store or database vendors and thus taking advantage of the different ways of storing data:
Data Integrity
Data Consistency
Clustering
High Performance
etc.

5. Potential Consumers AAA Project
Authentication, authorization and accounting services
AADS
Application Aware Data Store
TSDR
Time Series Data Repository

6. Scope
Provide an extensible and reusable software platform that includes:
Application programming interfaces (APIs).
Abstract implementations that allow plugging in a variety of object-store engines such as JPA, Cassandra, Mongo, HBase, etc.
JPA implementation support
A set of integration test tools.
In Scope:
Data Definition: defining, removing or updating data structures (Database tables or schema for example).
Data Maintenance: Inserting, updating or deleting data from existing data structures.
Data Retrieval: Querying existing data.
Out of Scope:
Data Control: Creating and monitoring database users, restricting access to data, and monitoring the data access performance.

7. High Level Architecture

8. Software Architecture
The consumer interacts with a persistence API which abstracts any type of data store or database.
Abstract implementations are provided for the supported data stores: In the illustration JPA (SQL) and Cassandra (NoSQL).
The framework is extended by adding implementations for other types of data stores.
It can be seen from the architecture that the business logic interacts with a persistence API which abstracts any type of data store or database. Partial implementations are provided for JPA and Cassandra which are relational and non-relational databases respectively (JPA is actually a specification but most practical implementations, like Hibernate, fully support relational databases), however the framework may be extended adding implementations for more types of data stores or databases.

9. API Advantages: Easy to Use, Hard to Misuse Consolidated Extensible
Favors Loosely Coupled Designs
Implementations Do Not Impact the API
Testable
Drawbacks:
Object Creation Overhead
DAO Creation Complexity Depends on the Implementation’s Abstractions
Schema Definition is Left to the Implementations and not Considered as part of the API