January 30, 2014 Copyright Jim Farley Beyond JDBC: Java Object- Relational Mappings Jim Farley e-Commerce Program Manager GE Research and Development [email protected].

April 10, 2023 Copyright Jim Farley

Beyond JDBC: Java Object-Relational

MappingsJim Farley

e-Commerce Program Manager

GE Research and [email protected]


Agenda

• Define the problem• Review the issues and options

– Design approaches– Technical tools

• Some guidelines for choosing a solution


The Problem

• Impedance mismatch– OOP vs. RDBMS

• Both still prominent in their respective domains

• Both designed for different purposes– OO: Conceptual program design– RDBMS: Data relationship modeling

and access speed


The Building Blocks

• OOP– Interfaces, classes– Data member references– Methods

• RDBMS– Tables, columns– Foreign keys, integrity constraints– Stored procedures


Goals and Assumptions• Optimize “conceptual accuracy” and

robustness of OOP objects• Optimize robustness of data model

– Multiple use-cases, some non-Java apps• Online apps + reporting tools + OLAP

• JDBC is the underlying plumbing (directly or indirectly)

• Minimize latency of JDBC “bridge” code• Preserve “ACID” properties of database


The Framework

RDBMS

DO

DODO

Application/Business Object




Data layer(RDBMS “objects”)

Conceptual layer(Java objects)

Middleware(Java objects)


Why define a mapping?• Encapsulates the data access layer

– Preserve data-level business rules– Minimize impact on code due to data model

changes

• Reduces development overhead– Schema plus the mapping rules is all you need

to know to use the database

• Simplifies code management– Mapping is a shield/guide for introducing

fixes


Some Common Approaches• Schema -> JDBC abstraction -> app

objects– Non-remote by default, can be wrapped– Low overhead/high transaction rates– Context-independent

• Schema-> XML binding -> app objects• Schema -> EJB entity beans -> app objects

– Remote by default– J2EE compliant


Issues

• Reproducible mapping?• Where does the business logic go?• Who defines the transaction

boundaries?• How does the security model tie

in?


Reproducible Mappings• I.e., no hand-tweaking of the generated

code…• Pros:

– Schema changes can be tracked easily– Every set of data objects is consistent

• Cons:– Mapping utility needs to support full access

to data layer– Possibility for sub-optimal data access


Reproducible Mappings

• Recommendation: Keep the mapping reproducible– Adjusting the mapping utility rather

than the code is almost always a bigger payback

– Data access can be optimized in the mapping, or by allowing for app-layer “back-doors” to the JDBC level


Business Logic

• Possibilities:– App-layer (above the generated data objects)– Hand-tweak the data layer– Stored procedures

• “Business logic” comes in different flavors– Data integrity– Higher-level business process/workflow– Authorization


Business Logic• Recommendations:

– Don’t tweak the data layer• Too messy, easier to adjust mapping utility to access

it

– Look at the usage modalities you need to support and let that drive the decisions• E.g., Two-tier reporting/admin tools => more data

integrity logic and authorization in stored procedures

– Generally speaking:• Keep data integrity close to the database level• Keep business process/workflow out in the app level


Transaction Boundaries

• I.e., What operations make up an ACID transaction?

• Largely driven by business-logic decisions– “Hard-coding” a transaction in the mapping

layer implicitly places business logic there as well

– Some logic will go into app-layer => pass-through support in data layer

– Some logic may go into the RDBMS => multi-tier transactions


Transaction Boundaries• Recommendations:

– Keep data-layer transactions fairly atomic, allow for subsuming them into higher-level transactions

– Get intimate knowledge of how RDBMS and JDBC driver work together to support transactions• Data layer interactions with stored

procedures => tiered transactions• Can/will affect transaction rates


Security Model

• Authentication and authorization need to be supported top to bottom

• User identities and policies need to be mapped to RDBMS level

• RDBMS security support is erratic– Some do certificates, some don’t

• Account management– Roles, access modalities, etc. play into this


Security Model• Recommendation: Keep policies out of the

data layer– Provide pass-through support in the mapping– Try to avoid vendor-specific facilities in the

mapping layer

• You may need to “bridge” PKI with RDBMS authorization– Map user accounts to database accounts– Data relationships in the RDBMS, business

rules in the app layer


Solutions: Custom mapping• JDBC/schema -> abstraction layer -> app

objects– Abstraction layer provides entities that

represent tables, columns, procedures, constraints, etc.

– RDBMS “objects” mapped to “instances” of these entities (subclasses, wrappers)

• Non-remote, optimizable, portable• Transactions and security are all up to you• Have to worry about driver issues yourself


Solutions: EJB Entity beans• JDBC/schema -> EJB entity beans -> app

objects• App objects can be session beans,

higher-order entity beans, etc.• Remote by default, EJB engine required• Transactions directly supported

– But transaction rates will be lower

• Container-managed persistence is an option


Solutions: XML

• Schema-> XML binding -> app objects– Or some variation?

• XML binding plus standard schema language would extend portability enormously– Publish your schema and business components– Generate optimized RDBMS and middleware

• But: Not ready for prime time• But: No relationship with EJB defined (yet)


Overall Recommendations• EJB is a nice framework, use it if you can

afford it– Transaction rates need to be improved– Server costs may not make sense for you– Still need a mapping of some kind

• Custom middleware is a pain, but still an option– Third-party stuff is there, but be careful

• Watch the XML space for a “right” solution


Questions?

January 30, 2014 Copyright Jim Farley Beyond JDBC: Java Object- Relational Mappings Jim Farley e-Commerce Program Manager GE Research and Development [email protected].

Documents

mapping layer

datalayer transactions

app layer slide

copyright jim farley

copyright jim farley

copyright jim farley

data layer possibility

data integrity logic