views:

205

answers:

4

Hello,

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.

+3  A: 

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.

davetron5000
+1  A: 

(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.

Electrons_Ahoy
+1 for the "any at all" comment
Thanks, etlerant! Another enterprise java refugee, I see.
Electrons_Ahoy
+1  A: 

EJBs are components and not classes and you should think of them in that term and express your system design appropriately.

The granularity of the component is obviously domain dependent.

Assume you were modeling a (fairly old fashioned) computer with EJBs. Resistors, transistors, coils, etc.: These are pojos. Chips and Boards are Components. The assembly is the EAR.

Interface granularity should reflect component function.

+1  A: 

EJB is not just normal class instance. It needs extra maintenance in container, instance pool,etc. Lots of EJBs require much resource in server.

I don't think a system do need hundreds EJBs. While I was also involved an application with 90 EJBs, it was nightmare:< There was no testability, and deployment is also a huge task.

卢声远 Shengyuan Lu