• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Dark side of EJBs: bad use?

 
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
    DAOs

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

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

    Where:

    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.

    Aurelio
     
    author
    Posts: 4335
    39
    jQuery Eclipse IDE Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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 ]
     
    Aurelio Calegari
    Ranch Hand
    Posts: 55
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Scott,

    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.

    Regards,

    Aurelio
     
    reply
      Bookmark Topic Watch Topic
    • New Topic