1. January 30, 2014 Copyright Jim Farley Beyond JDBC: Java Object- Relational Mappings Jim Farley e-Commerce Program Manager GE Research and Development farley@crd.ge.com

2. January 30, 2014 Copyright Jim Farley Agenda Define the problem Review the issues and options –Design approaches –Technical tools Some guidelines for choosing a solution

3. January 30, 2014 Copyright Jim Farley 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

4. January 30, 2014 Copyright Jim Farley The Building Blocks OOP –Interfaces, classes –Data member references –Methods RDBMS –Tables, columns –Foreign keys, integrity constraints –Stored procedures

5. January 30, 2014 Copyright Jim Farley 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

6. January 30, 2014 Copyright Jim Farley The Framework Data layer (RDBMS objects) Conceptual layer (Java objects) Middleware (Java objects)

7. January 30, 2014 Copyright Jim Farley 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

8. January 30, 2014 Copyright Jim Farley 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

9. January 30, 2014 Copyright Jim Farley Issues Reproducible mapping? Where does the business logic go? Who defines the transaction boundaries? How does the security model tie in?

10. January 30, 2014 Copyright Jim Farley 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

11. January 30, 2014 Copyright Jim Farley 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

12. January 30, 2014 Copyright Jim Farley 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

13. January 30, 2014 Copyright Jim Farley Business Logic Recommendations: –Dont 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

14. January 30, 2014 Copyright Jim Farley 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

15. January 30, 2014 Copyright Jim Farley 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

16. January 30, 2014 Copyright Jim Farley 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 dont Account management –Roles, access modalities, etc. play into this

17. January 30, 2014 Copyright Jim Farley 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

18. January 30, 2014 Copyright Jim Farley 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

19. January 30, 2014 Copyright Jim Farley 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

20. January 30, 2014 Copyright Jim Farley 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)

21. January 30, 2014 Copyright Jim Farley 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

22. January 30, 2014 Copyright Jim Farley Questions?