Persistence Store Project Proposal

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

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.

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.

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

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.

High Level Architecture

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.

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