My friend Dan has been looking at EJBs and thinking that he has to learn about them. I did my best to convince him not to. Here’s why:
The deal with EJB as I understand it:
1. There are entity beans and session beans, of which the Entity beans are more commonly thought of to represent persistent data. Session beans are intended to represent actions, logic against the entities. There can be stateless and stateful session beans, and the container will maintain the state for you, may replicate it for failover, etc.
2. There are major differences between earlier and newer version of the EJB spec. In the early ones, everything was remoted, which meant that after you wrote a class you had to generate a set of interfaces, skeletons and stubs for calling and managing its lifecycle on the client and server. You had to bundle, describe and deploy them. It was such a fucking mess that whole new projects grew up to automate and assist in that. The newer specs support a lighter-weight local method call against EJBs, where you can be in the same process and not have to go through RMI to get to them. This turns out to be crucial for performance (see next point). Also, newer releases support Message-driven beans for asynch messaging.
3. The architecture was seriously flawed — because Entity beans suggest a model for persistent data, and the architecture suggests making remote calls to them, naive implementations would end up with tons of round-trips to the EJBs where the protocol and the design punishes you terribly, yielding unacceptable performance. In short, if your client-side code makes a remote call, get the stub for the EJB, and starts manipulating it, but actually needs to interact with lots of different entities (as a real application does) then you suddently have all these conversations going on. What happens if you want to display a set of data to the user? Right, 100 EJBs you’re talking to. So a bunch of effort went into creating new Design Patterns (like Facade) that would hide the EJBs behind a stateless Session bean, and it would make local calls at that end to the underlying business objects, then return the data in one big parameter. So you have this conflict between the architecture of entity beans as fine-grained animals and the performance price of interacting with them like that.
4. I can recommend two great books that critique EJB convincingly: Bitter Java by Bruce Tate (a great read, and I believe he’s producing a followup just about EJB) and J2EE Design and Development by Rod Johnson (incredibly valuable). Both draw similar conclusions, but Johnson was actually on the committee and is ruthless in his analysis. Experience bears all this out — I know lots of folks who have failed, or had to rip out EJBs and replace them with a lightweight Model-View-Controller using servlets and pojos (plain old Java Beans) to yield success. Johnson has a terrific set of criteria for evaluating with the expense and complexity of EJBs are really justified. His general conclusion seems to be that they offer the most value through their container-managed transactions and the robust failover and scalability in the few cases where that is really justified.
I have avoided learning much about them from the beginning, mostly out of instinct and distrust. When the critiques appeared I was glad to read them. I remain optimistic that this is one pile of steaming **** that I won’t have to find more space for in my head than I just put on this piece of pixel dust.
Stay away from them, you’ve been warned. If you’ve got to go near, make sure the customer has deep pockets and isn’t going to blame you when it doesn’t work.