Adam Bien's Weblog

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:

  1. All major appservers do support EJB 3. Glassfish v3 partially EJB 3.1.
  2. With the introduction of EJB 3 you can save a lot of code, and remove XML completely.
  3. 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.
  4. The most important aspects: transactions, concurrency and state management, are built in - you don't even have to care in simple applications.
  5. Monitoring is required by the spec. Every application server has to provide runtime monitoring data.
  6. 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.
  7. You can easily migrate your EJB 2 legacy to EJB 3. Even cross server (stay tuned).
  8. EJBs are easily testable.
  9. Deployment is very fast (seconds). Incremental deployment is supported by many appservers.
  10. 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).
  11. 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?:

  1. Utility classes with static methods (no added value here)
  2. 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.
  3. You are not allowed to use EJBs - this can happen sometimes. I see a trend to use openEJB inside Tomcat for that reason :-)
  4. 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]

NEW online workshop: WebStandards Igniter (online)

Airport MUC workshops: Java EE 7: Bootstrap, Effective, Architectures, Web, React and Angular, Testing and Microservices


A book about rethinking Java EE Patterns


Another reason why EJB 3 cannot be used is its lack of 'advanced' JMS features, like:
- process messages in a queue in order The spec states that you have to make sure manually that the messages are processed in order. Luckily there are container-specific workarounds.
- listen to queues dynamically or create MDBs whose destination can be specified at runtime (if that is possibly I'd REALLY like to know how)


Posted by Ron on January 22, 2009 at 11:55 AM CET #


I'd be interested how you see App-Server portability nowadays ?
Would an application developed against JBoss with EJB3 easily run on Websphere or Glassfish ?

In his books Rod Johnson always mentioned Classloader/Deployment differences and more subtle stuff concerning cross-server-portability of an app (yes - these might be myth - its a long time gone since).

We are in a position where our products have to run on whatever appserver the customer likes to have it run.

Stuff like JNDI, giving support for different AppServers' monitoring solutions, DataSource Config/JAAS etc. then always get complicated.

That's why this is for me still a valid reason not to use EJB3 and go instead for a 'lightweight - but you have to integrate a lot of stuff yourself' solution that is only dependend on a robust servlet implementation.

Posted by Stefan Hansel on January 22, 2009 at 01:37 PM CET #

Hi Adam,

Nice post.

The "lightweight POJOS" were inspired by Spring and Hibernate. Essentially, you get all the dependencies via Spring and the ORM solution of Hibernate.

But the most interesting part of that is now there are efforts in integrating EJB 3 with Spring. Moreover, Hibernate has provided an implementation of EJB 3 API.

I would like to add some points in

When not to use EJBs?:

- Poorly Designed Data Model

I am victim in this case. We have no control over the data model, yet we were required to use EJB 3. I for one would have gone to a SQL centric ORM solution such as IBATIS if the schema would changed from time to time.


Posted by Jerwin Louise Vergara Uy on January 23, 2009 at 03:17 AM CET #


I almost agree most of yours points but the "8. EJBs are easily testable." i'm still figuring out a easy solutions to test EJB 3 properly.

Posted by Kenneth on January 23, 2009 at 07:18 AM CET #

Hi Adam,

Another good post.

Just a note. OpenEJB has partial EJB 3.1 support as well; Singletons, Embedded EJB Container, and EJBs in .war files. The later of the two are very old features.

Speaking as just some guy who has spent a lot of his life working on a project that historically hasn't been very popular, I'm really proud that some of the things we've innovated such as the embeddable EJB container concept are centerpieces of the EJB 3.1 spec. All humility aside it really is quite an amazing feeling. It has been quite a pleasure for me working with you and the other members of the EJB 3.1 Expert Group.

Knock on wood that our good fortune continues and we are able to handle the growth we're seeing in the project.

Posted by David Blevins on January 23, 2009 at 07:38 AM CET #


Regarding "8. EJBs are easily testable." Here is a small catalog of ejb testing examples.

Note that although those examples use OpenEJB for the testing, there's no reason you can't still use something else in production -- there are a growing number of people who do just that. We do what we can to make that possible, for example we have full support for the Glassfish deployment descriptors so those users don't have to maintain two sets of descriptors. We can also mimic the JNDI naming formats of other vendors, etc.

Hope that helps.

Posted by David Blevins on January 23, 2009 at 07:56 AM CET #

Thank you for your information

Posted by Farmacia on January 25, 2009 at 09:16 PM CET #

EJB do exists! tell me, can we use EJB in production with only tomcat?

We are using tomcat for production, what is the very good reason to use EJB with tomcat?

Posted by Marlon on February 12, 2011 at 07:27 PM CET #


some reasons:

and search this blog for EJBs :-)

The main reason is: laziness. With EJB 3.X you don't have to re-invent the wheel.



Posted by on February 12, 2011 at 08:28 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments