I'm currently attending IBM WebSphere Technical Exchange
2004 in San Francisco, California. In one of my talks, "Architecting and Developing J2EE Applications Using Patterns," I talk about the Business Object
and Domain Model
patterns and how to persist these objects. I suggest that, in general, when developing a J2EE application, you should implement your business/domain objects as Enterprise JavaBeans
(EJB), more specifically entity bean
s, more specifically those implemented using container-managed persistence
Some of my audience members asked a rather interesting question: What about Java Data Objects
(JDO) or Hibernate
? Why use CMPs instead of those? Here's the answer I gave them.
CMP entity beans are part of EJB and therefore J2EE
. Thus there is built-in runtime support for them in WebSphere Application Server
(WAS). Furthermore, there is built-in support for entity beans and specifically CMPs in WebSphere Studio Application Developer
(WSAD). This support provides tooling for developing the O/R mappings
needed to make CMPs (or any other persistence approach) work (see "Developing and Testing CMPs with the Table and Data Source Creator in WebSphere Studio Application Developer Version 5.1
"). The tooling supports three development approaches:
- Top down - You've already developed an object model using entity beans, so the tooling generates the relational database schema for your data model, which you can then execute to configure your database.
- Bottom up - You've already developed a database schema, so the tooling generates a set of entity bean classes for an object model that matches you data model.
- Meet in the middle - You've already developed entity bean object model and a database schema, so the tooling takes a stab at mapping the two and then lets you adjust and finalize the mappings.
In any of these approaches, if you're using CMPs, the tooling also generates the necessary parts of the deployment descriptor
to perform the O/R mappings.
JDO, Hibernate, and similar approaches for solving the O/R mapping problem are admirable efforts. But bottom line, they're not part of J2EE and are not supported by WebSphere products nor by most (any?) other J2EE products. I (and many (most?) of my IBM colleagues) recommend that you develop your J2EE applications to the J2EE specification, maximizing use of the J2EE services. CMPs are part of J2EE; JDO and Hibernate are not.
Because approaches like JDO and Hibernate are not part of J2EE and WebSphere, to use these approaches, you have to add this support. This means that you have to add libraries and frameworks to the application server runtime to support the approach. And you should have tooling for your approach to support developing the O/R mappings (which should ideally be Eclipse plug-in
s so that it can easily be added to your Eclipse IDE or to WSAD). WebSphere customers have already invested money and time into using WAS and WSAD; I would be hesitant to invest more cost and effort into additional products to solve the same problem.
I was very excited about JDO when it was developed and finally released. However, the process took a long time, and in the meantime, the entity bean spec evolved to incorporate many of the innovations that were also going into JDO (the evolution of dependent objects and container-managed relationships in EJB 2.0
comes to mind). Hibernate has gotten a lot of favorable attention, and in fact EJB 3.0
), the next version of EJB (unofficial FAQ
), will incorporate many Hibernate-like features. This is no coincidence; Gavin King
of Hibernate is a member of
the EJB 3.0 committee.
So bottom like, I think WebSphere customers should use CMPs. They increasingly have many of the advantages of JDO and Hibernate, are a standard and supported part of J2EE and WebSphere, and will have an upgrade path to future versions of J2EE and WebSphere. This seems like the best of all worlds.
Having said all this, I also have to agree with Don Box
when he said
: "As an aside, I really wonder how many O/R mappers the world needs. It's frightening how much energy goes into building these things (on both sides of the aisle I might add)."