Object Relationship Mapping (ORM) is probably the best things that happened to enterprise software development since the invention of the Lego brick in 1949. Implementing the database access through ORM allows you to access the account data of a customer through the class 'Account' (with pure Java code), rather than having to mix SQL code in your Java classes. A framework does the job of translating your Java code to SQL statements and executing them though a JDBC connection.

ORM adoption has faced (and still does) a lot of resistance from the IT industry in general, but even more with enterprise software. Can't blame them: database access is a very common bottleneck for software that has intense use of data. Would you give away your fine tuned SQL scripts in favor of some 'magic bullet' that will automatically write that SQL for you at run-time?

It certainly does not help that many ORM frameworks did not work, or were simply not up to the challenges faced by enterprise software (ever heard of EJB entity beans?). It also does not help that many trials were done with unfairly high expectations: ORM will let you forget about SQL or ORM will deal with the most complex queries without any tuning of the database.

However, today, you could rely on ORM for enterprise development with confidence that it won't only increase your developers productivity (its main goal), but also improve your application performance. I remember saying this to a meeting of architects for one of the biggest banks in the world. They thought I had drank too much chocolate milk or worse. How could automatic SQL runtime generation be better than manually written SQL?

To begin with, just having a layer of separation between you application and the database helps. It doesn't, because that layer (the ORM framework), will know exactly what you code needs (in terms of data) and when. So if you need the balance of an account, it'll fetch just that (not the whole row). Will you write one select statement for each column of each table? No, it's too much work. But not for the ORM framework. It allows the implementation of 2nd level cache that dramatically reduces round trips to the database.

Actually, I find many similarities to ORM performance impact to the discussion around garbage collection. A lot of (very knowledgeable) people out there still think that GC makes you application slow, when in fact it is faster than direct memory management (even in C++, you'll have better performance implementing GC rather than doing malloc and calloc).

For jbilling, we selected the J2EE platform for a lot of good reasons. This happened about 5 years ago and, like many other poor devils, that included using entity beans. 5 years is a lot of time in this micro-universe, so it is clear to all now that entity beans is a very poor ORM implementation. I could live with a lot of its flaws: the DTO anti-pattern, interfaces, abstract classes, XML mapping, the whole thing. But there is one single aspect of it that make is totally useless for enterprise software: its pessimistic locking.

It is just not possible to access a database with multiple users and having locks spread around the way entity beans work. The way we managed this is to use direct JDBC calls to access the database for those operations where entity beans would lock the whole database to a halt.

But now, Java EE 5 is out and surprise! Entity beans have bean replace by JPA. I know, they are technically still part of the specification, but who in her right mind would pick entity beans over JPA? So it is time for jbilling to switch from entity beans + JDBC to full JPA.

We are very excited about this, but we hit some disappointment when we found out that JBoss does not fully support Java EE 5 yet. The latest production version (4.2.1GA) is not really a Java EE 5 application server. It is a J2EE 1.4 application server with support for EJB 3. What's the difference? Java EE 5 states that you can mix you EJB 2.1 with EJB 3. So you can have entity beans alongside JPA classes. This does not work with JBoss 4.2.1.

Well, we want to do this migration step by step, with plenty of testing in between steps. So the only way around for us is to stay with JBoss 3.x and bring Hibernate Entity Manager along. It is pretty ironic that you can mix these two with JBoss 3.x but not with JBoss 4!

The result of the first migrated beans is terrific. Check out this commit: http://jbilling.svn.sourceforge.net/viewvc/jbilling?view=rev&revision=250

These were 4 classes to access 4 tables. They were entity beans, now they are JPA annotated POJOs. Notice how much clutter code is gone. No more entity bean to DTO to entity bean code. Xdoclect comments are now nice annotations that eclipse understands and validates. The list of benefits is long, see for yourself!

Entity beans were a good step forward to bring ORM as part of an integrated framework. That much is true, and the 2.1 release was usable to an extent. The real issue was that it was sold as an enterprise level tool. It is not. It does not work because the design is flawed. I am glad that other frameworks did have a sound architecture (noticeably Hibernate). Now we can enjoy enterprise ORM with JPA. Cheers!

Emiliano Conde
Lead Developer
jbilling.com