Enterprise Java Beans have become a heavily hyped solution for the problems inherent in developing complex computer systems. In the interest of balance, here are some reasons why you don't want to use EJB.
1. You don't have an "enterprise" problem.
Don’t be a ashamed - maybe you don’t have an enterprise problem. Do you have multiple database to integrate? Do you have a need for CORBA or messaging integration? If not maybe a simpler solution is more appropriate. As a rule of thumb, if you don’t need distributed transactions, you probably don’t have an enterprise level problem. Maybe you’re lucky enough not to need EJB.
2. You can convert your "enterprise" problem into a "simple" problem.
OK, so you have a tough problem to solve. Now, how can you simplify it? Do you really need multiple database online at once. What are your data access patterns? If you are doing read-only or read-mostly access maybe you can create a single operational database with scheduled synchronization to back-end databases. Once a day you update the back-end system. If you already do this for database warehousing the infrastructure may already be in place.
Do you really need to use that old CORBA code? Can write a little new code to avoid having to use the old code? If it simplifies your architecture, it may be worth it.
3. Your business logic is scattered around.
Where is your legacy business logic? EJB wants it to be in Java. If it scattered between database stored procedures, server processes and web pages, you may have to do a lot of work to get it to play well with EJBs. Do you really want to rewrite those stored procedures? Can you wrap them in beans?
4. Your legacy data doesn’t map to beans.
Modeling your data as beans can be problematic. If the granularity of the beans is too low, performance will suffer as the system is swamped with beans. If the granularity is too high, you will end up with a monolithic system that will also perform poorly. Figuring out how to map your data to beans and preserve performance and system design is the "art" of EJB design. There is no simple formula telling how to get it right.
5. Bean Managed Persistence (BMP) doesn’t work for you.
The initial EJB specification for BMP was laughably incomplete. Only the most basic data model was supported. Complex relationships were not allowed. The EJB 2.0 specification will allow relationships and dependent objects but will these be
enough?
6. Vendor lock-in is unacceptable.
EJB is written as a lowest common denominator specification. For any but the most basic systems you are going to spend time tuning and crafting code for the application server you choose. A good deal of your code will be portable, but much will be specific to your app server.
7.You don't want to re-train your team.
Although conceptually simple, the 400 pages of the specification belie the idea that EJB is easy to learn. The basics are straightforward but, inevitably, situations arise where complicated interactions
become the rule.
And of course, this assumes your team already knows Java. Taking a ASP, ColdFusion or PHP/Perl programming and turning them into
Java programmers will take time (and if they are Perl programmers no small amount
of indoctrination.)
8. Performance is important, especially Price/Performance.
The default configuration of an EJB application will perform poorly. Specifically, transactions, caching and RMI usage must be tuned to get adequate performance. Naively letting the application server will most likely result in a negative result. How much time and budget can you spend getting it
right?
9. You don't have the budget.
EJB doesn’t come cheap. You should estimate at least 10k per CPU. Open source isn’t really an option unless you are willing to spend a lot of time getting it working. In addition, you will probably find that an EJB solution will require more CPU than a simpler solution. Add in training and support costs and you are looking at big bucks. Maybe your budget is better spent on more hardware or
a front-end database cache.
10.
