adam bien's blog

Regardless, with which technology / framework / tools you are starting, this question should be answered first. What happens, in case for some reasons, the EJB 3 will be replaced with something else, or the major vendors will not support EJBs any more? What is actually the dependency between your business code and the platform? In EJB 3.X (Session Beans, Message Driven Beans and JPA), your code is dependent on some few annotations (@Local and @Stateless, @EJB, @PersistenceContext, @Resource) - so you will need them to compile / run your application. This is not a big deal - the conceptual dependency to the container is much higher. You will need a container, which understands your annotations - or you will have just to migrate your code another DI container. In an average project you will have about 50-100 Session Beans (and no XML :-)), so it shouldn't be that painful. Actually you could even deploy your EJB application directly to Spring Pitchfork, migration to Guice shouldn't be that hard either. Just delete the annotations and migrate your classes with interfaces to something else.

However, a more probable scenario, is the lack of features. In my experience EJB 3 cover about 80-90% of all needed features in an average project - the rest has to be provided by something else. The good story here: you can just start with EJB 3, and use on top just another framework (Spring, Guice and remaining few hundreds DI frameworks :-)) you like. However - most of the architects overestimate the complexity and introduce additional frameworks for every possible situation at the beginning of the project - which increases further the overall complexity. In last years I introduced EJB 3.0 / Java EE 5 several times in the variety of projects. The result: EJB 3 were good enough, and we were able to delete all remaining superflous, layers, home grown frameworks and utilities. In most projects the problem weren't the EJBs, but heavily overengineered systems :-).