Slide 1

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

Slide 2

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

Slide 3

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

Slide 4

Slide 5

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

Slide 6

The current abstraction is leaky

Slide 7

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

Slide 8

DataObjectService Focus on what the KRAD framework needs to get its job done. Basic CRUD Metadata Data Validation

Slide 9

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.

Slide 10

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.

Slide 11

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

Slide 12

Yes, but first we need to fix our foundation!

Slide 13

Otherwise

Slide 14

and it wouldnt hurt to plan for the future a bit.

Slide 15

But lets be honest

Slide 16

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

Slide 17

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

Slide 18

Slide 19

Architecture

Slide 20

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

Slide 21

Flexible Data Types

Slide 22

DataObjectType 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... }

Slide 23

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

Slide 24

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,... }

Slide 25

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.

Slide 26

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

Slide 27

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

Slide 28

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.

Slide 29

The Metadata Pipeline

Slide 30

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

Slide 31

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

Slide 32

Externalizable Business Objects EBOs 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

Slide 33

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

Slide 34

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 its friends

Slide 35

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

Slide 36

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.

Slide 37

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

Slide 38

Slide 39

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

Slide 40

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?

Slide 41

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

Slide 42