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