Home
Getting Started
Download
Documentation
API Docs
Reference
FAQ
EJB 3.0 Support
Contact
Viewpoint
|
Hydrate as an EJB 3.0 Persistence Implementation
Overview
Now that the final version of JSR 220: Enterprise Java Beans 3.0, has been published,
it remains to be seen if the new direction taken by this bold departure from the
restrictions of EJB 2.1 will gain the widespread acceptance it is seeking and become
the standard for persistence frameworks in Java enterprise applications.
Over the next few months we should expect to get some clarity on whether EJB 3.0 persistence
can free itself from the sour taste of EJB 2.1 Entity Bean Container Managed Persistence and
become the one true persistence API.
We should also expect to see attempts at other successful and niche providers of O/R solutions
to attempt to support the EJB 3.0 APIs using these solutions as the back end. Products like
iBatis and Cayenne continue to have a following and if EJB 3.0 truly represents the best
abstraction possible, it should be possible to provide the benefits of these frameworks through
that API.
On the second point, it has proved very instructive to attempt a first pass of the implementation
of EJB 3.0 APIs using Hydrate as a back end. Since Hydrate comes from a very different place from
the principal drivers of the EJB standard (KODO, TopLink and Hibernate focus on mapping from Objects
to a Database using introspection, whereas Hydrate focuses on mapping from a Relational Database to
Objects using code generation), there is much to be learnt from this experience for both prospective
implementers and prospective users of EJB 3.0 persistence.
The whitepaper here (PDF) describes some experiences in executing a
basic implementation. It concludes that an implementation is indeed possible, but also highlights
a number of challenges: firstly in the detailled interpretation of the standard and secondly in
cases where it is difficult to expose important features of the Hydrate framework through the standard
API.
|
