How many EJBs is too many?

Question

I'm currently developing a large piece of software base on JavaEE. We have followed the general guidelines of JavaEE that says that each related set of operations should go into their own EJB. We currently have over 275 different EJB classes (Stateless Session beans). This number is most likely going to grow to at least double that number.

I would like to know if the EJB containers are designed to hold that many different kinds of EJBs. I'm interested in knowing if we are going to get some bad performance penalty from having too many such classes, and if some application server level tweaking can help alleviate those hypothetical problems.

We are using Glassfish v2 with JavaEE 5 on sun's Java 6, so advice on this particular platform would be most appreciated.

Answer 1

EJBs should be fine-grained, so there is no problem with what you are doing if you are consistent in your design.

The EJBs are just classes, so there's nothing to worry about except for general load, which is orthogonal to the number of EJBs you have deployed.

If you are worried about performance, put in some monitoring or other performance metrics and see how things go as you add new features.

At the end of the day, would you rather maintain fewer classes with many methods, or many classes with fewer methods? I know which one I'd pick.

Answer 2

(Is there a way I can say "any at all" without being voted down?)

On a serious note, use as many as you need. My rule of thumb is (for both EJBs and classes in general) if you can't fully describe what the thing does in a class name of about three words, you've got it doing too much.

As far as performance goes, I suspect that if the system starts to suffer from "too many EJBs" you've got much bigger problems somewhere.