You already have the JPA implementation you need
I have been responding to several forum posts, e-mails, instant messages, and phone calls recently concerning the use of Hibernate within the IBM® WebSphere® Application Server environment. Because there is so much interest in this topic, I thought it would be helpful to those of you who haven't been able to ask me yet in person to document this information here.
Specifically, I am referring to the use of Hibernate JPA in the WebSphere Application Server environment. There is also the original Hibernate programming model, which I refer to as Hibernate "Classic." Since the classic Hibernate programming model is not part of the Java™ EE 5 suite, it’s not that pertinent to this conversation. There have been several iterations of this article which documents how you can utilize the Hibernate "Classic" programming model within the WebSphere Application Server environment. This usage is basically like any other utility framework. You can package it as a (shared) library and use it from your application, but it’s not an integral part of the overall application server runtime.
What this article will focus on is the use of Hibernate JPA in the WebSphere Application Server environment -- or, rather, why use Hibernate JPA at all when WebSphere Application Server already provides an industry-leading JPA implementation?
What is JPA?
JPA is the Java Persistence API. It is the standard persistence framework first introduced as part of the EJB™ 3.0 family of specifications in Java EE 5. For Java EE 6, JPA 2.0 graduates to its own JSR. At its core, JPA is an Object/Relational (O/R) Mapping facility, but it has evolved to include several other features. Because JPA is an integral piece of the Java EE suite, its capabilities are fully integrated with the EJB container and Web container, as well as transaction management, database connection management, and security management. Many technologies fed into the creation of JPA, such as EJB CMP, JDO, and Hibernate. It is no wonder, then, that so many existing Hibernate users want to continue to use this framework within the WebSphere Application Server environment.
The continued use of Hibernate is arguably a valid objective, as moving from one programming model (classic) to another (JPA) takes time and resources. If insufficient justification exists to make this investment, then staying with what works is fine and possibly even encouraged.
But if you are planning to migrate to the JPA standard and enjoy those benefits, then there are several considerable reasons for migrating from Hibernate "Classic" to the WebSphere JPA solution.
WebSphere JPA solutions and advantages
WebSphere Application Server JPA solutions are built upon the Apache OpenJPA project:
- The WebSphere Application Server V6.1 Feature Pack for EJB 3.0 first included JPA and was based on the OpenJPA 1.0.x service stream.
- WebSphere Application Server V7 provided the full Java EE 5 stack, including an updated JPA implementation based on the OpenJPA 1.2.x stream.
- Most recently, the WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API 2.0 was introduced, which is based on the OpenJPA 2.0.x stream.
All these deliverables utilize the same binaries as are available from the OpenJPA download site, and so you can be assured that any applications written against Apache OpenJPA will continue to run without modification in the WebSphere Application Server environment.
Of course, WebSphere Application Server also has additional features beyond the base OpenJPA deliverable via defined plug points to provide a very complete, very rich JPA solution.
- Ease of use
The WebSphere JPA solution is fully integrated into WebSphere Application Server offerings. Whether your environment uses one of the feature pack solutions or WebSphere Application Server v7, the JPA solution is ready to use out-of-the-box with no additional configuration or packaging required.
Because of this integrated JPA solution (Figure 1), WebSphere Application Server is able to provide functional extensions to the base OpenJPA binaries. Some of the areas that have been enhanced are IBM DB2® extensions (specifically pureQuery integration and locking optimizations), performance, configuration and admin support, security support, extended trace and logging support, and national language support for message logging.
Figure 1. WebSphere JPA architecture
WebSphere Application Server JPA solutions enable alternate JPA providers to be installed and used with the WebSphere Application Server runtime. For example, the use of Hibernate JPA is possible, but none of the WebSphere Application Server extensions will be available with the Hibernate JPA provider. Beyond that, the packaging of the Hibernate JPA solution is not trivial (see Resources). The bottom line, therefore, is that WebSphere Application Server does support the use of alternate JPA providers, but there are drawbacks to this approach.
- Lower support costs
The complete WebSphere JPA solution has full IBM product service and support, which means that any problems discovered will be addressed via normal support channels. Most members of the JPA development team are active committers on the Apache OpenJPA project. Issues will be logged and resolved with the Apache OpenJPA project. These updates will then conveniently be delivered as part of the normal WebSphere support process.
Another major advantage of a WebSphere JPA solution is release-to-release compatibility support. It is important that migrating from one WebSphere Application Server release to the next – including full versions and feature packs – be as easy as possible, and every attempt is made to make the JPA migration painless as well. Should a new JPA or Java EE specification force incompatible changes to be made to the product, documentation and "back out options" to achieve the prior behavior are typically provided. Because of the flexible packaging architecture of OpenJPA, WebSphere Application Server can override any non-conforming behavior of OpenJPA to make the WebSphere Application Server experience consistent from release to release.
If you use an alternate JPA provider, such as Hibernate JPA, then WebSphere Application Server support stops at the defined plug point for the alternate JPA provider. Any problems discovered in the alternate JPA provider (such as object mappings, database interaction, performance concerns, and so on) will need to addressed with that provider. This might involve using their forums for support or establishing an external service contract. Clearly, not a convenience.
- Better performance
For the record, performance comparisons can be tricky. Any performance benchmarks that are developed and promoted by a JPA provider -- even so-called "independent" JPA benchmarks that get posted to the Web -- tend to favor one JPA provider over the others. Add in licensing concerns and these types of specific JPA benchmarks can be messy.
For these and other reasons, IBM generally relies on industry standard benchmarks. SpecJEnterprise, for example, takes several aspects of the application server into account but with a focus on the persistence framework. It’s been estimated that 75-80% of the SpecJEnterprise benchmark depends on the persistence layer (that is, JPA provider). The SpecJEnterprise 1Q2010 comparison clearly shows WebSphere’s leadership in this space, with similar results posed for 2Q2010 and later.
IBM constantly compares the WebSphere Application Server JPA solution against others by primitive operations (create, retrieve, update, delete), by running running industry benchmarks, and by other methods. Many variations are measured to ensure that the WebSphere JPA solution continues to lead in performance, as well as maximize the experience and overall benefit of WebSphere Application Server.
The bottom line is that sticking with the WebSphere JPA solution rather than moving to Hibernate JPA (or any other JPA provider) makes business sense, development sense, and just common sense overall. Ease of use, lower cost, better performance, and a seamless experience not only maximizes the benefits you receive from WebSphere Application Server, but also helps to maximize the results of your development efforts.
- Using Spring and Hibernate with WebSphere Application Server
- JSR-000220 Enterprise JavaBeans 3.0 specification
- JSR-000317 Java Persistence 2.0 specification
- Comment lines: An update on Java Persistence API 2.0
- Apache OpenJPA project
- Using third-party persistence providers
- Alternate JPA Providers in WebSphere Application Server (PDF 545KB)
- First Quarter 2010 SPECjEnterprise2010 Results
- IBM developerWorks WebSphere
Get products and technologies
- WebSphere Application Server
- WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API 2.0
- WebSphere Application Server Feature Pack for EJB 3.0