KRAD Data Layer A Data Access and Persistence

KRAD Data Layer A Data Access and Persistence Architecture for KRAD Eric Westfall February 2013

Introducing the krad-data module ( Encapsulate ) and Simplify

What we have today KRAD still using KNS data and persistence architecture Originally written for OJB Overly complex!

But is it really that

YES! That’s more than 10 services that all support our current data and persistence layer in KRAD.

The current abstraction is leaky

Take all those services and throw them in the trash! Because we can do it with just one!

Data. Object. Service Focus on what the KRAD framework needs to get it’s job done. Basic CRUD Metadata Data Validation

Keep It Simple ! An attempt to create the ultimate generalpurpose abstraction on top of any ORM or persistence technology would be doomed to failure.

Instead, we need to push the complexity down. Application code can still use ORM-specific APIs if need arises.

Hold On! What is all this nonsense? JPA Roolz! I thought we were just adding JPA support?

Yes, but first we need to fix our foundation!

Otherwise…

…and it wouldn’t hurt to plan for the future a bit.

But let’s be honest…

However… There already use cases within our community for non-traditional data stores Example: OLE Document Store The future is now

Data from Anywhere By keeping things simple, we open up the possibility to interface with nearly any backend data store or persistence technology OJB JPA JDBC Spring-Data No. SQL Web Services

Architecture

Data. Object. Service Design • find. Matching • save • delete • validate • get. Data. Dictionary

Flexible Data Types

Data. Object. Type<T> public class Data. Object. Type<T> { public static <T> Data. Object. Type<T> create( Class<T> data. Object. Class, String discriminator) {. . . } public static <T> Data. Object. Type<T> for. Class( Class<T> data. Object. Class) {. . . } // discriminator is null. . . } public interface Data. Object. Service { <T> T find(Data. Object. Type<T> type, Object id); <T> T find(Class<T> type, Object id); // for convenience. . . }

Example of a Static Data Type Data. Object. Service dos =. . . ; Data. Object. Type<Account> account. Type = Data. Object. Type. for. Class(Account. class); Account acct = dos. find(account. Type, “ 123”); System. out. println(acct. get. Nbr()); // prints “ 123”

Example of a Dynamic Data Type Data. Object. Service dos =. . . ; Data. Object. Type<Json> json. Account. Type = Data. Object. Type. create(Json. class, “account”); Json account. Json = new Json(json. Account. Type, “{ ‘nbr’ : ‘ 123’, . . . }”); dos. save(account. Json); // assume we have implemented save Json json = dos. find(json. Account. Type, “ 123”); json. get. Type(). equals(json. Account. Type); // true System. out. println(json. get. Json()); // { ‘nbr’ : ‘ 123’, . . . }

Working with Dynamic Types Allows for a flexible design that could facilitate tasks on the roadmap such as rewriting e. Doc. Lite to use KRAD Metadata would need to be available for these dynamic types as well Properties could also be accessed in a syntax similar to Java (dot-notation) with pluggable property accessors for dynamic types.

Provider Framework An SPI will be used to allow for custom data providers Can be registered with a Provider. Registry or loaded via a Module. Configuration Three different types of providers: Persistence. Provider Metadata. Provider Validation. Provider

Persistence. Provider Implements basic CRUD operations Can be responsible for one or more data object types For a given data object type, there should be only one valid Persistence. Provider OJB and JPA implementations will be provided out-of-the box with the krad-data module

Metadata. Provider Loads metadata into the data dictionary for a set of data object types Metadata for a given data object type can be combined from multiple providers into one Reasonable defaults should be applied when possible! Labels Validation Etc.

The Metadata Pipeline

Splitting the Data. Dictionary The Data. Dictionary becomes the authoritative source for all metadata in KRAD What is currently called the “Data Dictionary” is split into: Data Dictionary – data object metadata View Dictionary – KRAD UIF view configuration Document Dictionary – document framework configuration The “new” Data. Dictionary becomes part of krad-data module

Validation. Provider Allows for simple data object validation Data validation executed automatically upon save Can be disabled by passing a flag to save method Meant for simple, data-focussed validation Required-ness Max/min length Proper format Default provider will be applied in most cases which will leverage constraints defined in Data Dictionary

Externalizable Business Objects EBO’s were tacked-on to the KNS Implementation is a mess and very brittle Through the use of custom Persistence. Providers, the goal is the render the current incarnation of EBOs obsolete …and deprecate the Externalizable. Business. Object marker interface

Transaction Management Transaction management will still occur above the data layer Not all data stores support transactions It will be up to the provider implementation to be written in a “transaction aware” fashion if transactions are supported JPA and OJB providers will both be transaction-aware In KRAD, will work to discontinue the practice of coursegrained transactions automatically initiated on entry into any controller Instead, controller methods which should be transactional, will initiate transactions when appropriate/necessary

Impact Goal is to leave legacy KNS untouched as much as possible Existing KRAD applications will have impact if they are currently using Business. Object. Service and it’s friends

The Old-School Way Create database table(s) Create java object, implements Persistable. Business. Object Map Java object to Database using ORM Create Data Dictionary XML file for business object Configure all attributes in Data Dictionary file Inject data dictionary files in module configuration Use Business. Object. Service to load and persist object

The New-And-Improved Way Create database table(s) Create POJO Map Java object to Database using ORM Inject ORM provider into module configuration Use Data. Object. Service to load and persist data object Mapping the data object in an XML Data Dictionary file is optional! Intelligent defaults will be applied and all metadata sources will be leveraged wherever possible.

Advantages Metadata pipeline will derive dictionary info when possible Natural language derivation for labels (for example: account. Number -> “Account Number”) Max Length derived from database metadata Required-ness derived from database metadata Intelligent convention-based defaults whenever possible Data. Dictionary XML can be used to refine metadata, but is ultimately optional Data Validation is built into the data layer and sourced from metadata in Data Dictionary is simplified to just data object metadata

The Development Plan Data and Provider Layer implementation OJB Persistence and Metadata Providers Data. Dictionary refactoring Isolation of legacy KNS Refactoring of KRAD to utilize new service(s) JPA Persistence and Metadata Providers JPA Implementation Support Classes Conversion/Migration Scripts

Still Working On… How best to handle linking and refreshing Detailed design on EBO Work through issues on how to handle data dictionary split and modularity. Is proposed definition of Data. Object. Service enough? Method to create a new instance of a data object? Helpers for property accessors/modifiers? How, exactly, to do all of this without breaking legacy KNS?

Next Time Design of OJB implementation Design of JPA implementation JPA-specific considerations and challenges