he EJB 3.0 expert group seems to have handed JBoss the EJB application server market on a silver platter. Several weeks ago at TheServerSide Java Symposium in Las Vegas the EJB expert group announced its decision to shelve the current entity bean architecture and focus on the lightweight persistence of Plain Old Java Objects (POJOs). Specifically, it decided to use Hibernate as the persistence mechanism in EJB 3.0. Hibernate is an open source object/relational mapping solution that joined the JBoss Group last year.
The EJB 3.0 expert group’s decision to adopt Hibernate has given JBoss a lot of influence in the EJB app server market, and they are now leveraging it to gain an advantage. JBoss CEO and Founder Marc Fleury emphasized at a recent Triangle Java User’s Group meeting in Research Triangle Park, N.C. that “Hibernate is EJB 3.0″. He made a very compelling case for using Hibernate now as a means to gain early access to EJB 3.0. In addition, he provided convincing reasons why you should use JBoss now as the preferred EJB 3.0 application server. His take-home message was clear: to minimize the costs of migrating to EJB 3.0, use Hibernate and JBoss now. If I were an EJB community member who planned to eventually migrate to an EJB 3.0 implementation (which I’m not), he would have convinced me.
The EJB 3.0 expert group could have adopted JDO 2.0 as the persistence mechanism for POJOs instead, allowing Hibernate and the 20 or so other relational JDO implementations to compete for the business. A draft spec of JDO 2.0 will be out within a month. Instead, it chose a specific product, Hibernate, effectively handing the EJB application server market to JBoss.
Obviously my position is far from neutral, but I believe the entire enterprise Java community should be concerned with the possible outcomes of this decision. IBM and Oracle are two major players in the EJB app server space that one would expect to be at least leery of the EJB 3.0 expert group’s choice. However, as database vendors also, they probably prefer Hibernate to JDO because it uses the SQL syntax of the underlying RDBMS?which allows applications to be locked in to a specific database vendor. Members of the JDO community suspect that JDO’s portability across databases?preventing vendor lock-in?is a primary reason for IBM and Oracle opposing JDO. Maybe these vendors are willing to concede a portion of their application server market share to JBoss in exchange for having applications locked into their underlying database systems.
If this truly is their plan, it could really backfire. Many developers who use open source software like Hibernate and JBoss are also using the MySQL open source database. Many companies are starting their new, more risky application projects with MySQL to minimize costs during these projects’ trial phases. Many plan to then migrate the projects to name brand databases like Oracle 9i once they prove successful. But by using Hibernate, these companies are locking their applications in to MySQL. In which case, enterprise solution vendors such as IBM and Oracle will lose market share in both the application server and database markets. If JDO were used, the applications could migrate from MySQL to Oracle or DB2.
It’s hard to believe that the leading EJB app server vendors would allow JBoss to get a foothold in their market this way. Yet some of them recently voted against the JDO 2.0 JSR in the Java Community Process (JCP), citing its overlap with EJB 3.0 as one of their reasons. For example, Don Deutsch of Oracle justified his vote by stating, “the direction of lightweight persistence being taken by the EJB 3.0 group will have tremendous appeal to mainstream enterprise Java developers.”
The EJB expert group may be touting lightweight persistence of POJOs as a new concept that will greatly simplify system development, but the JDO community has known the importance of lightweight persistence for many years and has provided the technology since JDO 1.0 was released in 2002. In fact, the JDO expert group was formed under JSR-12 in 1999 to standardize the transparent persistence of object models.
In the years that followed, a lot of animosity grew between the EJB and JDO camps because of the heated debate over whose approach was better: entity beans (EJB) or POJO persistence (JDO). This animosity is likely why the EJB 3.0 expert group chose to adopt Hibernate instead of JDO. Yet by touting the many benefits of POJO persistence now, the EJB expert group is basically admitting that the JDO approach has been right all along. And despite the votes against it, the JDO 2.0 JSR still passed.
JDO Isn’t Just for Object Databases
Since the JDO 1.0 release, JDO has gained about 20 relational and three object database implementations. Most of the JDO applications being developed today are targeted for use with a relational database. However, the EJB community is trying to marginalize JDO by associating it with object databases:
Ed Cobb, VP of Architecture & Standards at BEA, voted against JDO, saying its “market acceptance is essentially constrained to use with object databases.”
Oracle also has been telling everyone that JDO is only for object databases. During last year’s JavaOne conference, I attended a presentation titled “Container Managed Persistence: Beyond the Specification” in which Oracle’s Sastry Malladi told his audience the same thing.
At the recent May meeting of the Triangle Java User’s Group in Research Triangle Park, N.C., Gavin King, the architect of Hibernate, stated that JDO is “a solution for flat files and object databases?and, oh yes, there are a few relational implementations too.” As a participant in the JDO 2.0 expert group, King knows there are many relational JDO implementations.
At this same meeting, Marc Fleury presented a slide stating “Hibernate is focused on ORDBMS, unlike JDO.”
None of these claims are true, and the EJB community knows it. JDO is being used primarily with relational databases. The irony of all these attempts to paint JDO as an irrelevant object database technology is that the EJB expert group has now chosen Hibernate, which attributes part of its technology to ODMG the object database standard. It supports the ODMG interface and includes ODMG jar files in its distribution. So the EJB expert group’s new Hibernate persistence technology actually has an ODMG object database heritage.
Disturbing Implications for JCP
Linda DeMichiel and the rest of the EJB expert group’s choice of a product like Hibernate, which has not gone through any standardization process, also raises an issue about the JCP and how decisions in it are made. At the May Triangle User’s Group meeting, Fleury bragged about how in his discussions with DeMichiel about joining the EJB expert group she insisted that Hibernate be used as the persistence mechanism. JDO has already gone through the JCP and has gained adoption as a standard. The JDO interface provides binary compatibility among JDO implementations, allowing developers to switch from one JDO implementation to another. Selecting JDO as the basis for EJB 3.0 persistence would have provided EJB vendors and the user community with a broad selection of competing implementations from which to choose. I haven’t found any technical justification for Hibernate’s supposed superiority over JDO.
Hibernate creator Gavin King, now with JBoss, and Oracle’s TopLink team were all members of the JDO 2.0 expert group. They demanded that JDO’s binary compatibility capability be made optional. The JDO 2.0 expert group made changes to the spec in order to get them to agree that Hibernate and TopLink would support JDO 2.0. In effect, both Hibernate and TopLink developers had stated that they could and would support the JDO standard. Still, immediately after the EJB 3.0 expert group announced the Hibernate decision, they asked to be removed from the JDO expert group.
Hardly a Final Decision
I wonder whether BEA, IBM, Oracle, and Sun realize the great gift the EJB 3.0 expert group has given JBoss? I suspect the final chapter on the EJB 3.0 persistence story has not been written yet. Given the market impact this will have on all the other EJB app server vendors, I doubt this Hibernate decision will withstand the tests of time and politics.
The JDO expert group is providing a smooth transition from JDO 1.0 to 2.0. JDO 2.0 will provide standardized object/relational mapping, extensive query language enhancements, and an attach/detach capability that the market has been requesting. The JDO standard has 20 binary-compatible JDO implementations, all competing for POJO persistence business. And they work in a variety of architectures?with or without an application server.