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

Introducing the krad-data module ( Encapsulate ) and and Simplify Simplify

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

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!

DataObjectService 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 general-purpose abstraction on top of any ORM or persistence technology would be doomed to failure.

Instead, we need to push the complexity down. 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? I thought we were just adding JPA support? JPA Roolz!

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 are 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 OJBJPAJDBCSpring-DataNoSQL Web Services

Architecture

DataObjectService Design find find findMatching findMatching save save delete delete validate validate getDataDictionary getDataDictionary

Flexible Data Types

DataObjectType<T> public class DataObjectType { public static DataObjectType create( Class dataObjectClass, String discriminator) {... } public static DataObjectType forClass( Class dataObjectClass) {... } // discriminator is null... } public interface DataObjectService { T find(DataObjectType type, Object id); T find(Class type, Object id); // for convenience... }

Example of a Static Data Type DataObjectService dos =...; DataObjectType accountType = DataObjectType.forClass(Account.class); Account acct = dos.find(accountType, “123”); System.out.println(acct.getNbr()); // prints “123”

Example of a Dynamic Data Type DataObjectService dos =...; DataObjectType jsonAccountType = DataObjectType.create(Json.class, “account”); Json accountJson = new Json(jsonAccountType, “{ ‘nbr’ : ‘123’,... }”); dos.save(accountJson); // assume we have implemented save Json json = dos.find(jsonAccountType, “123”); json.getType().equals(jsonAccountType); // true System.out.println(json.getJson()); // { ‘nbr’ : ‘123’,... }

Working with Dynamic Types Allows for a flexible design that could facilitate tasks on the roadmap such as rewriting eDocLite 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 ProviderRegistry or loaded via a ModuleConfiguration Three different types of providers: PersistenceProviderMetadataProviderValidationProvider

PersistenceProvider 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 PersistenceProvider OJB and JPA implementations will be provided out-of-the box with the krad-data module

MetadataProvider 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! LabelsValidationEtc.

The Metadata Pipeline

Splitting the DataDictionary The DataDictionary 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” DataDictionary becomes part of krad-data module

ValidationProvider 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 PersistenceProviders, the goal is the render the current incarnation of EBOs obsolete …and deprecate the ExternalizableBusinessObject 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 course- grained 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 BusinessObjectService and it’s friends

The Old-School Way Create database table(s) Create java object, implements PersistableBusinessObject 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 BusinessObjectService 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 DataObjectService 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: accountNumber -> “Account Number”) Max Length derived from database metadata Required-ness derived from database metadata Intelligent convention-based defaults whenever possible DataDictionary 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 Data Dictionary is simplified to just data object metadata

The Development Plan Data and Provider Layer implementation OJB Persistence and Metadata Providers DataDictionary 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 DataObjectService 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