This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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
Integration tier DAOs
That's all pretty plain classic and known architecture, but then they define what the componets are:
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 J2EEpattern 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.
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 ]