Fog Creek Software
Discussion Board

The real benefits of EJB?

Why use Enterprise Java Beans?  So far people I know who've worked with it say it makes applications take much longer to develop and more difficult to maintain, and gives poor runtime performance.

On some of those projects, I could see the inherent reasons why they were problematic - one was a very low-volume system (<10 transactions per DAY) which had no need for EJBs, and with another they decided to make almost every object be an EJB.  The others weren't so clear cut as bad candidates for EJB, but still I haven't heard of anybody who actually used EJB say much good about it.  I've also read the article "EJB's 101 Damnations" (

So, can any of you help me get past the marketing hype and horror stories, and tell me about the *reality* of what makes EJB a good thing (if it's actually a good thing)? What has your experience been with it? If you're building a large-scale application in Java, what is there about EJB that can't be done easier and cheaper with another Java setup, such as a cluster of servlet-based Java application servers backed by a relational database? 

T. Norman
Sunday, December 22, 2002

Fowler's "Patterns of Enterprise Application Architechture" doesn't go into EJB much, but does state that generally, they are simple not necessary.

Mike Swieton
Sunday, December 22, 2002

Enterprise java beans are just a way of allowing someone else to write most of the server code for you.  This allows you to concentrate on things which are specific to your application.  I can't really give you general rules for when you would want to use them (you never need to use them, or any other specific software component standard).  If you are doing a web based application which is basically http connection to the client, and a back end connection to a database, you could easily get by with servlets.
Remember also, that there are many kinds of EJBs.  On the one project in which I used entity beans, my hope was that they would provide a good object interface to the relational store.  In this respect I found them hugely dissappointing.  Session beans, on the othe hand, are great place to put any server side logic and Message driven Beans can make writing message oriented applications a bit closer to a snap.

I think the real answer is that you don't need to determine if EJBs are useful or worthless.  You need to look at the capabilities of the application servers which implement them, and decide if the benefits of having those experts write most of you server code for you, outweighs the learning you will need to do on this fairly complex standard.

I have found projects on which it is worth it.

Erik Lickerman
Sunday, December 22, 2002

You may try reading the first chapter of "Mastering EJB" (free PDF version available at - it gives the motivation for EJB. This books is still considered as one of the best in the EJB area so it'll probably give you more answers than on-line articles ;)

As about EJB community (if you need) - was always the place to go.

Good luck !

Evgeny Goldin
Monday, December 23, 2002

Erik pointed out an important issue: the different kinds of EJBs. And, as he stated, session beans are nice puppets, especially if you use them to concentrate the business funcionality of your app.

Example: You might have a content managment system, where users can add articles, list articles, delete, link them, etc. A good way to develop real-life reusable code without adding too much bloat would be to implement the business functions (such as "add an article", "list articles from a channel", "link an article to another") as methods in a session EJB. This way, your front end is free to change a lot, to scale (e.g.: multiple Web Containers contacting a simple EJB Container) and you can even have multiple front-ends (Web, Sadistic Swing, or whatever can instantiate the remote EJB). Search for "Session Facade Pattern" on the Design Patterns literature for that.

If you want to spot a villain, Entity EJBs may be the culprits. There is a lot of discussion about using them or not in (and I think it´s the right place for that). I personally try to avoid them whenever possible, except if I have a good reason to act otherwise (e.g.: weak database backend + frequently needed, not huge set of data).

Of course, either use of EJB (and others, such as Message-Driven) has two "code bureucracies": the creation of several interfaces/mandatory methods when you design an EJB, and the process of finding home interfaces in JNDI, instantiating them, using them to find remote ones when you want to use it.

If that is your disappointment with EJB, welcome to the club. You can´t do much for that (other than thaving an IDE handling them for you).

And unless you have the power to change environments, I don´t recommend looking at .Net - you will be *very* sad when you go back to the why-make-it-simple-when-it-can-be-complex J2EE world...

Monday, December 23, 2002

What I am really trying to get it is not merely what makes EJBs useful, but what are the types of situations that make it *more* useful than other Java options such as servlets.  By more useful I mean something that saves effort in development, maintenance or gives better reusability or performance.

For example, why not just use a servlet, or a regular Java class wrapped by a servlet, for the "add an article" functionality?  Sure, it will work as an EJB, but what makes it better than doing it with servlets?

"And unless you have the power to change environments, I don´t recommend looking at .Net - you will be *very* sad when you go back to the why-make-it-simple-when-it-can-be-complex J2EE world..."

What did you mean ... that .Net is less complex than J2EE?  Or more complex than J2EE?  Or J2EE tends to breed unnecessary complexity, more so than .Net?

T. Norman
Monday, December 23, 2002

A couple of difference between EJB Session and simple java class. With EJB you get (with very little extra code):

> Automatic pooling
> Automatic declarative transaction
> Automatic security (usually not needed)
> No recode at all necessary when you need to scale up and deploy among several back-end machines (requires you have correctly designed the system)

And mostly forgotten IMHO
> Possible to be accessed thru RMI from any kind of client (not just Web). Very interesting when you do integration from other non web clients (like EAI, ETL, admin/supervision tools (eg JMX), etc.)

Compare this with what you have to write yourself if you need these features. But indeed, EJB's are for large multi-tiers enterprise apps, not your simple web app.

Robert Chevallier
Monday, December 23, 2002

First off, let's be clear that servlets and EJB's are not exclusive technologies. The real question is whether or not to use EJBs in your servlet, as opposed to other technologies. Servlets/JSPs would still provide the interface to the user (controller + view), where the EJBs would be acting as a data/bizlogic layer (model).

Anyway, what EJBs gain you, as I understand it, is:
1) Platform independence: theoretically you could migrate to a better suited appserver for your needs
2) Scalability: a good appserver will support transparent clustering, so you don't have to re-design your app
3) Transactions: EJBs support transactions inherently, so if you need transactional support outside of your database, this can be useful
4) Messaging: With message driven beans you can easily make message-aware applications
5) Goodies: Many of the appservers come with useful utilitities, such as built-in loggers and database pools (of course using them defeats 1)
6) Data: entity beans give you a simplified ORM system.

All that said, do I use EJB's? Nope. The one project I tested them for changed our mind. All of the RMI stuff put a huge overhead on any activity involving them, even the simplest call-a-session-bean type activity. I've had better luck with platform independence using servlet/jsp technology with open-source tools like struts -- these you can just ship with your app, and you really can deploy it to different servlet containers. For data purposes, I've never really seen anyone seriously say entity ejb's are a good idea. There are much better and more flexible ORM systems out there -- I've had good luck with castor.

As far as I can figure out, EJB's were designed for a type of application so far up from most web developers that it's nigh useless for most apps. Unlike .NET, which is clearly designed specifically for 95% of web apps.

The one case I've considered using EJBs is in the case of a running server where I want to be able to change/add various functionality on the fly. JBoss lets you hot-deploy beans by dropping them in a directory, which is pretty useful. I'd consider using this feature in the future, but it really would be no more than stateless session beans taking advantage of JBoss's hot-deploy features.

Matt Christensen
Monday, December 23, 2002

With respect to Matt's post, and the original post, I think you get just as much platform independence and scaleability with Servlets as you do with Session Beans.  A message oriented system would probably be higher performing under proper conditions.
I have seen two comparisons with .Net in this thread.  If it is true that it is oriented around 95% of web apps, I suspect it is more competitive with the JSP/Servlet/JDBC part of J2EE.  I don't think we need a flame war on which is better.  Most of the time either should get the job done.  Using JSP/Servlets is plenty simple.  I find it hard to believe that .Net is signifigantly less complex to program.

Erik Lickerman
Monday, December 23, 2002

I've fallen into the trap of using EJB when it wasn't necessary, and it's a really bad idea. If all you need to do is make a bunch of SQL queries from an app running on a single server, servlets/JSP and JDBC are the way to go.

On the other hand, there are times when EJB is very helpful. Session beans make transaction management pretty easy. Message-driven beans are also very useful if an app needs to receive requests via JMS. There's no good substitute for message-driven beans in the rest of J2EE, and writing your own code to listen for incoming messages is a waste of effort if you can get the server to manage that process for you.

Beth Linker
Monday, December 23, 2002


Sorry for the weird wording: I wanted to say that J2EE is sometimes a bit more complex than .Net when performing similar tasks - especially in the web application realm.

It is not anything that will knock down your development productivity, but when you stack it up with the IDEs, deployment process, reuse of language knowledge and other stuff where .Net has other tiny bits of advantage, you begin to think twice about the "right" environment for your project (if there is any place in the world where the environment isn´t already set, of course :-) ).

Monday, December 23, 2002

And I can´t avoid repeating Erik´s very fortunate statement - something to remember before starting any flame war on this J2EE/.Net subject (online or within your corporation):

"Most of the time either should get the job done."

Monday, December 23, 2002

Well, at least for now the J2EE/.Net debate is not an issue for me, as my company doesn't have any intention of using anytime .Net soon, but they have used EJB with some disastrous results in terms of huge schedule and budget overruns and pathetic performance.  The projects that used servlets without EJB fared much better.  Still, the projects with EJB also had management and design issues so they aren't sure if it was EJB that was the main source of the problems.

I've done some work with servlets already but not yet EJB.  I tend to be given a lead technical role in the projects I work on, so if put on a J2EE project I may be able to steer them away from EJB if I can show good reasons why it isn't appropriate.  Regardless, I am still teaching myself EJB even if it will end up being for no other purpose than knowing why *not* to use it.

T. Norman
Monday, December 23, 2002


With respect to the "pathetic performance" of EJBs (Entity beans specifically because I don't think this was ever true of stateless session beans) I to found the performance wanting and had to implement my own caching scheme.  With any signifigant distributed app which uses persistent objects, caching is vital to importance.  I am told that many J2EE systems now implement caching themselves (There is actually a distributed caching standard that the java community is working on) so performance might well be better.

Erik Lickerman
Tuesday, December 24, 2002

It takes longer and is more complex. The upgrades and patches keep coming in. So as a consultant they are great.

Thursday, December 26, 2002

*  Recent Topics

*  Fog Creek Home