Skip to main content

How Beans side-tracked Enterprise Java

Posted by johnreynolds on October 6, 2005 at 12:44 PM PDT

Sometimes a single word can really wreak havoc, and "Bean" is one such word.

My enthusiasm for Java took a distinct nose dive the first time I encountered the implementation details for the dreaded Enterprise Java Bean. It was quite a shock, and I did everything that I could to avoid using them. Now that EJB3 has significantly lessened the learning curve, many of my initial complaints have been addressed, but there's still something not-quite-right.

Beans?

Java Bean was a cute pun. What better name for a nice little package of Java functionality; but when you look at the Sun's definition for Java Bean, it becomes pretty clear that the original analogy didn't anticipate Enterprise Java.

From Greg Voss's Java Bean tutorial:

"A Java Bean is a reusable software component that can be visually manipulated in builder tools."

Greg is really talking about visual components, like Swing and JSF controls. These have very little in common with the problems that EJBs were supposed to address.

If the word "Service" had been used instead of the word "Bean", J2EE would have made more sense.

Think about it; the original EJBs only had Remote Interfaces. In the original EJB model, Entity Beans only appeared as an afterthought. When you use the word "Bean" this makes no sense. When you use the word "Service" it makes perfect sense.

The result of this poor word choice may have been five years of arguing about POJOs and misusing EJBs (both Entity and Session).

EJB3 goes a long way towards erasing the differences between EJBs and POJOs, and that is definitely a good thing in terms of simplifying our programming model, but are we still impeding ourselves with our own terminology?

Most EJBs, POJO based or not, are not really Enterprise in scope. Most EJBs are tightly coupled to specific applications and live within the same JVM. The term is still causing confusion.

The term "Enterprise" is a natural companion for the term "Remote". If something is useful across the Enterprise, then it probably has a remote interface. Think Jini. Think Web Services. Those are the real Enterprise aspects of Java

Related Topics >>