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.

Rakehell

What's depressing is that so many developers (have to) use EJBs but there is not even one answer below that lists a real and solved problem. – Rakehell

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.

Tenement

Spring's IoC/DI framework is much more generic and powerful than EJB3's, and includes many other features, e.g., AOP. I'm not saying EJB3 is bad, but characterizing it as containing a simpler superset of Spring functionality isn't accurate. – Lannylanolin

Im currently in the middle of SCBCD for ejb3.0. It looks quite ok – Eulaliaeulaliah

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.

Doorway

Answer 3

Did lots of work in the past with EJB 2.1, glad to leave it behind.

EJB value proposition remains true for 3.0, and carries a nice lightweight programming model. Transaction management, concurrency, data versioning, state management, these are non-trivial problems to solve correctly and Java EE frameworks continue to do an excellent job.

Admittedly, I use Hibernate and Seam to further build on some of the Java EE features, so it isn't strictly fair for me to say EJB 3.0 itself is the mecca. However I find too many developers throwing the proverbial baby out with the bathwater when they give up on Java entirely and move to something more vogue like Rails.

Seam provides a nice glue framework that keeps the amount of programmer effort quite low. Also lets you decide on a project by project basis when EJB makes sense versus POJOs, WITHOUT having to change your programming style.

Harrietharriett

Answer 4

the main reason to use the java ee platform is by definition. you need a platform that solves the issues of concurrency, availability, transaction management, messaging, and management in a fully vetted, compliant, and compatible platform. yes you can do it all yourself by gluing together a whole host of libraries and slapping it on top of tomcat, but why waste all that time vetting and managing compatibility and feature set when you can write to a standards enforcing, fully vetted platform. any ee container MUST pass the tck or it cannot carry the Java EE monicker.

the things that various people raise about "lightweight", "types" of ejbs, etc. are superfluous. if you don't need the feature set of the platform or the guarantee of complete intra compatibility of your leveraged libraries, then ejb (aka the java ee platform) is overkill. but if you're really solving an enterprise quality problem (see the first paragraph), then the ejb and the java ee platform are going to give you what you need.

Liaison

In my experience you hardly ever need all those features. And when you do need one or two features there are simpler and better alternatives. And BTW, the same goes for Spring which is also overloaded. – Rakehell

Answer 5

One thing that has bitten many when using EJBs, or J2EE in general, is the dependency on the application server you're running your EJBs on. The appserver tends to be supported for a particular set of operating system releases and JVM versions. Not having the source code to a significant part of your runtime environment could also turn into a challenge.

While migrating from one vendor to another in principle is possible, you need to be very aware of small differences in how they implement the specification, and to stay away from vendor-specific extensions.

That being said, the appservers I've been exposed to can handle very much abuse from the code running in it and perform very well.

Chancey

Answer 6

Convention over configuration.

The default behaviour of EJB 3 it's more often the desired one. I think the main problem with EJB 2.1 was the necesity of verbose config files, the new annotation-based configuration solve most of this problem.

Overnice