EJB 3.1 - and Is There Still Room For POJOs? 📎
Back in the J2EE 1.X days the usage of Session Beans as facades to bare POJOs was considered as a best practice. A session bean was heavily dependent on the EJB API and the server infrastructure, so it was a really good idea to separate the technology from the domain logic. With the advent of EJB 3, Session Beans could be considered as annotated POJOs on stereoids. They save you a lot of code, even comparing them to "lightweight POJOs architectures" (in case something like this actually exists).
With the advent of EJB 3 we enountered "Inversion of Argumentation". You should rather justify why you are still relying on proprietary solutions or write your home grown frameworks, instead of using EJBs. Some facts:
- All major appservers do support EJB 3. Glassfish v3 partially EJB 3.1.
- With the introduction of EJB 3 you can save a lot of code, and remove XML completely.
- You are only marginally dependent on the the EJB 3 API - in practice you will need about 5 annotations (@Stateless, @EJB, @Interceptors, @Resource, @TransactionAttribute) - thats your dependence on the API.
- The most important aspects: transactions, concurrency and state management, are built in - you don't even have to care in simple applications.
- Monitoring is required by the spec. Every application server has to provide runtime monitoring data.
- Netbeans 6.5, Eclipse and IntelliJ support is superb. However, you don't even need lot of IDE support to develop EJBs. vi/emacs or jedit (for sophisticated use cases :-)) the annotations from 3. and Javac are absolutely sufficient.
- You can easily migrate your EJB 2 legacy to EJB 3. Even cross server (stay tuned).
- EJBs are easily testable.
- Deployment is very fast (seconds). Incremental deployment is supported by many appservers.
- EJB 3 are really productive. To understand the concepts you will need probably a half day. A simple application can be build in few minutes (without hacking or strange wizards).
- The performance overhead is negligible.
...but they have a bad name - this argument is somehow esoteric. So the question is not "Why?" but "Why not". This entry is actually a summary of previous posts - but I was asked about that. When not to use EJBs?:
- Utility classes with static methods (no added value here)
- Integration of legacy code without default constructors and strange signatures - it is better to wrap such a POJO with an EJB, instead making it an EJB.
- You are not allowed to use EJBs - this can happen sometimes. I see a trend to use openEJB inside Tomcat for that reason :-)
- You don't like the name (this is actually the major reason in practice)
In one of my past projects I was able to replace several "lightweight" POJOs with few EJB 3. Actually we were able to remove the majority of POJOs (hundreds) of that "lightweight architecture". The application now is 100% EJB 3 in the backend, no problems so far. I asked about the reasons, why such an architecture was chosen and lot of already existing container services were ignored and re-built with POJOs. The answer was very clear: "Because of lightweight..." :-).
[See also "Real World Java EE Patterns - Rethinking Best Practices" book, first two chapters]