Many enterprise Java developers gained some experience with Enterprise JavaBeans back in the era of EJB 1.X and 2.X, and many of these developers went on to choose technologies they deemed lighter-weight, such as the Spring framework, because they felt that building a solution by hand, or with a lighter-weight framework was easier and less time-consuming than Enterprise JavaBeans.
Both Java EE 5.X and EJB 3.X sought simplicity and lighter-weight development practices; is it still true that a POJO-solution is simpler, more-comprehensible code? Adam Bien doesn't think so:
Actually it is hard to simplify the EJB 3.0 (suggestions are really welcome).
The funny story is: Java EE 5 webapplications without EJB 3 Session Beans are more complicated.
He demonstrates with two code snippets, one with EJB 3 and one without, and concludes with:
The code not only simpler but also cleaner. The resources are managed and injected by the container. But with the introduction of a single Session Bean the manageability and monitoring can be significantly increased. With tools like Glassfish's call flow you can monitor the performance of the whole invocation stack. The coolest story - the XML-configuration is optional. In EJB 3.1 even the local interfaces will be optional.
Matt Corey adds:
Interesting topic, given that in EJB 3.1 it will also no longer be necessary to package your EJB's separately from your web application... From the JSR: "Support for direct use of EJBs in the servlet container, including simplified packaging options."
Jason Carreira provides some counterpoints:
The thing is, as much nicer as EJB3 is vs. EJB 2.1, Spring is that much nicer than EJB3. EJB3 dependency injection is pretty weak compared to the full power that Spring gives you to wire your stack together.
Plus, why do I want to depend on different app servers implementing the EJB3 spec compatibly when I could just bring the Spring jars with me and always have a consistent implementation? If I decide to stick with a particular implementation of Spring, I can bring that with me to any app server or servlet container, and, if the specs move on and change, I won't have to upgrade or change my code if I don't want to. Will the newest release of your app server still run your EJB3 application in 5 years? 10? Maybe, maybe not.
The comparison between Spring and EJB3 is a common one; many people left the complexities of EJB 1.X and 2.X for Spring and now find themselves wondering how EJB 3 compares, or a larger shift to Groovy and Grails or Ruby and Rails.
Is Java Enterprise Edition simpler with EJB3 than without? If you've used previous versions of Enterprise JavaBeans, does the new simplicity help to encourage you to use them again?
