The Pros and Cons of EJB

I l @ ve RuBoard

There is a case to be made for using EJBs in certain situations. It's important to identify those cases so that you can make a valid assessment regarding whether your project is a good candidate for an EJB deployment.

For example, do you have an absolute requirement for distributed computing? One of EJB's major selling points is that it allows you to keep all your business logic and database access in a central location. This means that you can greatly reduce the possibility that two applications will implement the same business logic in two different ways. It also means that you have only a single location to change when you need to update business logic.

However, don't be faked out by salespeople or your local head-in-the-clouds architect. "Someday wanting to be able to run distributed" is not a valid argument for incurring the pain of EJBs.

Another selling point of EJB is transaction processing (TP). If TP is a critical part of your application, you should consider EJB for that feature alone. One strength of an EJB is that it has strong support for rolling back your application (as opposed to your database) on exceptions.

Also, if you need to be able to manage concurrent operations (for example, multiple application servers that all need to stay in sync with each other), EJB will give you that benefit. This makes issues such as seamless failover (see Chapter 18, "Security, Load Balancing, Failover, and Other Considerations") much easier to implement.

On the other hand, I personally don't like coding EJB. I think that EJB has been vastly oversold in the marketplace and has led to some multimillion-dollar projects being made out of nice, clean half-million “dollar ones. I once was involved in a massive 40-engineer project centered on an EJB deployment that was generally acknowledged by most of the developers to be at least twice as complex as it needed to be because of the EJB overhead.

Now, if the project had actually required EJBs, it would have been worth the trouble. However, the only reason that this project was being developed using EJB technology was because of the customer's vague belief that it might want to some day leverage EJB functionality. In addition, EJB allowed us to justify using the very EJB-centric platform vendor that we had partnered with. In short, we were using EJB for political rather than technical reasons.

And I'm not alone. Industry gurus The Gartner Group issued a report in 2001 on EJB platforms. The report stated that companies have overspent by $1 billion on EJB platforms since 1998 and are expected to waste another $2 billion by 2003.

I especially love a quote from one of Gartner's VPs: "The application server vendors are encouraging customers to purchase higher-end technology that they just don't need. It's like buying gourmet food to feed kids at summer camp. It's just not necessary."

Why am I so down on EJBs? In short, because they're hard to code with. As you'll see when you begin to develop using EJB, you end up having to write the code twice, once for the client and once for the server. EJBs make you jump through incredible hoops to get anything done, increase the complexity of your code tremendously, and usually require deployment platforms that chew up your money and require equally massive hardware to run.

I l @ ve RuBoard