Java – Do you really need stateless session beans in this case

ejbjavastateless-session-beanstatic

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?

Best Answer

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.