Best features of EJB 3

Question

The scenario

• You have developed a webapp using EJBs version 3.
• The system is deployed, delivered and is used by the customer.

If you would have to rewrite the system from scratch, would you use EJBs again?

No: Don't answer this question, answer this one instead.

Yes: Provide one important, real problem that EJBs solved, based on your personal experience.

Let the answer contain just one problem. This will let other readers vote up the best feature of EJBs.

Answer 1

I think it depends on what version of EJBs you're talking about. Let's discuss the only two relevant (IMO) versions.

EJB 2.1 might still be used by some people in a legacy system. They really have the most use as an RPC abstraction. They also provided a rudimentary ORM (Object-Relational Mapping) system as well. And as you mentioned, transaction support is provided. So if you were building a system where you wanted to communicate with a remote system, transfer object-oriented data and do it transactionally, you might find EJBs to be worth the effort. Otherwise, I'd say stay away.

EJB 3.0, however, has been greatly improved. It has all the features of the previous version, but does it in a more straightforward way. It also provides a fairly simple Inversion-Of-Control framework not unlike Spring, and a pretty decent ORM in the form of the JPA (Java Persistence API.) I have used EJB 3.0 and actually enjoyed it. You could argue for the use of EJB 3.0 the same way you would for Spring, plus it has a few more advanced, or enterprise-y, features available.

Answer 2

Well, this really depends on which EJBs we are talking about. I would say that MDBs can still be useful even now. For entity beans and session beans you can surely find a better approach. Maybe one feature which I still like in EJBs is scalability. Using "remote" option you can deploy EJBs to different servers if necessary. However, I don't think this is really necessary, and I've seen only one huge project where it was really useful.