Despite their eventual unpopularity, entity beans did much to popularize Object-
Relational Mapping ( ORM ) . The ORM ideas were picked up by a range of lightweight
alternatives to EJB s. The dominant competitor was an open source product called
Hibernate . Hibernate uses an XML file (or, in later versions, annotations) to define
the mapping between data objects and database content. The Hibernate framework
does all the JDBC work so that the application doesn't have to.
The Java Persistence API ( JPA ) is a Java EE 5 specification that's a natural evolution of
Hibernate and another ORM technology known as JDO . Many Hibernate ideas were
incorporated into JPA , and more recent versions of Hibernate implement the JPA spec-
ification (as do many other persistence providers such as EclipseLink and Open JPA ).
The standardization of JPA allows different persistence providers to be used without
Although JPA (and its precursors, like Hibernate) is now the persistence program-
ming model of choice, JDBC hasn't gone away. JPA implementations are all built inter-
nally on JDBC (figure 3.1).
Although it's a Java EE specification, JPA also works well in a conventional Java envi-
ronment. Unfortunately, until recently, neither JDBC nor JPA worked well in an OSG i
environment. This was a shame, because these technologies had some limitations that
could be fixed by OSG i. Although JPA gives good vendor-independence, because
there's no support for dynamic replacement, JPA providers can't be swapped without
restarts. Similarly, JDBC drivers can't be removed from a running system.
The problems with traditional persistence in OSGi
Why don't JDBC and JPA work well as designed in an OSG i environment? After all,
OSG i is Java with a fancy classpath.
Figure 3.1 JDBC provides a useful Java-language access layer on top of a raw database. JPA and other
ORM frameworks add support for transparently moving between database entries and Java objects.
Search WWH ::