We recently received some feedback asking:
At the J2EE for dummies level, I would like a diagram that shows a clear relationship between JPA and (EJBs, Hibernate, Toplink, ...). Maybe an onion model. As it is, JPA claims to have incorporated the best of several models but at the same time it seems to be a wrapper for the available models.
The Java EE architecture diagram here shows where the Java Persistence API fits into the Java EE concept of containers, but this might be confusing for some people, as it gets lost with all the other boxes full of acronyms. A more simple might be something like this:
Here, an application I'm calling App 1 has three components, a web component, an EJB component, and a JPA component. It's deployed to a Java EE server, which runs on top of Java SE. So far, so good. When the JPA component is being used in the application, what's happening behind the scenes in the Java EE server?
Regardless of whether an enterprise bean or a web component is using the JPA component, the container (EJB or web) communicates with the configured JPA provider to access the underlying data. Because the Java Persistence API is required in Java EE 5 servers, every Java EE server has a default JPA provider. With GlassFish/Sun Java System Application Server, the default JPA provider is TopLink Essentials. TopLink Essentials is also the reference implementation of JPA.
There are other implementations of the Java Persistence API, though. Hibernate is a popular one. Another is OpenJPA. All of them, including TopLink, provide the baseline functionality of JPA, and also include implementation-specific features that go beyond the JPA specification. If your app uses one of these features, it's not portable across all JPA implementations. For example, if you use a Hibernate-specific feature, you can't deploy the application unchanged to a GlassFish server.
You can, however, configure your application to use an alternate JPA provider, provided that you make the alternate provider available to the Java EE server. The easiest way of doing this is to package the other provider's JAR with your application.
In this case, App 1 is bypassing GlassFish's default JPA provider, TopLink, in favor of Hibernate, which they have made available to GlassFish by packaging the Hibernate JAR with App 1, and configured their JPA component to use Hibernate. The EJB and web containers will use Hibernate to manage App 1's persistence unit.
Update: I should point out that if you want to avoid having to package the alternate JPA provider's JAR with each application, you can copy the JAR to GlassFish's INSTALL/lib directory and restart GlassFish so the JAR's classes are in GlassFish's runtime classpath.
