Do you really need stateless session beans in this case?

Question

We have a project with a pretty considerable number of EJB 2 stateless session beans which were created quite a long time ago. These are not the first-line beans which are accessed from our client via RMI, rather they are used by that code to perform specific functions. However, I've come to believe that there's nothing to be gained by having them as session beans at all.

• They do not need to be accessed via RMI.
• They do not retain any state, they are just code that was factored out of the first set of beans to reduce their complexity.
• They don't have multiple different implementations which we are swapping out, each one has been as it was for years (barring bug fixes and feature additions).
• None of them alter the transaction that comes into them from the bean calling them (that is they don't require a new transaction, not participate in the existing one, or otherwise change things).

Why should these not all just be classes with a couple of static functions and no EJB trappings at all?

Answer 1

There seems to be no reason why they shouldn't just be simple POJO's rather than stateless session beans. I think this is the conclusion that people came to after using EJB 1.x in this manner as well.

It's also the reason why frameworks such as Spring exist as an alternative to EJB's.

I'd say change them over to be just standard POJO's, but make sure you have a safety net of unit and functional tests (which might be a little bit harder with EJB's) to help you.

Answer 2

The only reason I can see is for clustering purposes (if you are doing clustering). That is the hand off to those beans could be on another VM on another machine if clustering is being done right to spread the load around.

That is likely not the case, and the movement to EJB's was just over-engineering. I'm suffering with that too.

Even transactions aren't really enough to justify it, you can have a single EJB that handles the transactions and call the different code through it via a Command type pattern.