It's not a secret anymore!
The moose likes EJB and other Java EE Technologies and the fly likes Dark side of EJBs: bad use? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Dark side of EJBs: bad use?" Watch "Dark side of EJBs: bad use?" New topic

Dark side of EJBs: bad use?

Aurelio Calegari
Ranch Hand

Joined: Nov 25, 2005
Posts: 55
Hello All,

Well, I have here a case I'd like to discuss with you all. Recently I start working in a new project for a huge insurance company. My company is one among a number of companies that were hired to work in a huge and ambicious downsizing project.

We have received an architectural document which we are required to follow strictly. The thing is that they are enforcing the use of EJBs in every single tier. They exploded the business and application tier into sub-tiers and within these tiers they have a number of EJBs, one calling another.

Let me first draw the basic structure proposed:

Presentation tier (WAR):
JSP -> Action -> Delegate (so far so good)

Business tier split into (no problem at all for now):
  • Application tier, and
  • Component tier

  • Integration tier

    That's all pretty plain classic and known architecture, but then they define what the componets are:

    ApplicationFacadeEJB ---> ComponentFacedeEJB --> ComponentEJB --> DAOEJB --> JPA Entity


    ApplicationFacadeEJB: Will expose business services for presentation tier. This is the application tier and is accessed by a business deleagete (so far so good).

    ComponentFacadeEJB: Will expose business component service. If presentation tier want to access biz components, it'll happen passing through this component facade...

    ComponentEJB: This guy is also an EJB and is the biz rules hoster. So... what's the point??? It alredy has a "component facade" that IS an EJB... Ok, let's go on...

    DAOEJB: A simple CRUD guy who uses JPA to dumbly insert, update, retrieve, delete... They say it must also be an EJB.

    What are the practices I have learned from industry:

    Business Rules should be placed on POJOs, preferrebly. The J2EE pattern Application Services comes to the rescue.

    Data Access Objects are generally also pojos, and once they are accessed internally the application there's no need to make it EJB. If we're using JPA already I see no need for DAOs, as long as we won't run any stored procedures or any other kind of integration.

    A Facade, generally a Session Facade is an EJB who would expose services to an external environment. Then all the dependend pojos would have EJB transaction, security and so on inherited, because they are called by that EJB. I see no problem with the ComponentFacade. It's my understanding that a ComponentFacade would be nice idea if you want to expose services to components from outside the VM that comes from other business tiers...

    Other modules were built and they have by now more than 900 EJBs... When they try to deploy they get a big fat OutOfMemoryError. EJB container will create a pool of each type of EJB, and thus that explains a lot the memory problem, and I tell you: the problem is not Horse Power.

    My first thought is that EJB is being used naively. They could optimize resources by simply reducing the nnumber of EJBs being used. For example, to display a sigle name in the screen, it has to go at least 4 EJBs to get to the database.

    I'd like to here from you what you think.

    Thanks in advance.

    Scott Selikoff
    Saloon Keeper

    Joined: Oct 23, 2005
    Posts: 3753

    In my experience DAO EJBs, or Entity Beans/Spring to be more precise, are common as are session bean facades. Anything in between is usually a helper class or general reusuable (or another facade), not usually an ejb.

    I don't like to have more than one session bean involved in a transaction, although multiple entity beans is common. It sounds like they are using multiple levels of EJB facades, which, yeah could be bad, but believe when I say there are far worse "J2EE" architectures out there.
    [ May 13, 2008: Message edited by: Scott Selikoff ]

    [OCA 8 Book] [Blog]
    Aurelio Calegari
    Ranch Hand

    Joined: Nov 25, 2005
    Posts: 55

    Thanks for your contribution. Yes, I believe that there are even worse J2EE architectures: Mankind has unlimited capacity to come up with good things and bad things.


    Consider Paul's rocket mass heater.
    subject: Dark side of EJBs: bad use?
    It's not a secret anymore!