KRAD Data Layer A Data Access and Persistence Architecture for KRAD Eric Westfall February 2013
Preview:
Citation preview
- 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