Section 6.1. Issues with EJBs

6.1. Issues with EJBs

Our two biggest complaints about EJBs are that:

• They require a complex set of programming artifacts for deployment.

• Developers tend to overuse them.

The complexity of the EJB programming model has hindered the adoption of J2EE. To deploy an EJB, you are dealing with as many as seven or more files (five Java files and two deployment descriptors). As you'll see later on, the main thrust of J2EE 1.5 (which includes EJB 3.0) is to simplify and lighten J2EE development by eliminating many of the programming artifacts required to deploy components. J2EE 1.5 will still offer core enterprise-class services such as transaction management and security, but it will be much easier to use. This book will not go into much detail about EJB 3.0 because the specification hasn't been finalized. But it will briefly discuss the improvements you'll see once EJB 3.0 becomes available. This book uses EJB 2.1, and it still has to deal with deployment descriptors and extra Java interfaces. It will show how XDoclet generates most of the code for us so that we can focus on business logic.

As software developers, most of us have the tendency to over-engineer a solution. You may also have heard the old adage, "If all you've got is a hammer, every problem tends to look like a nail." Bruce Tate, author of Better, Faster, Lighter Java (O'Reilly), calls the combination of these two predilections the "Golden Hammer" theory. Developers who know only EJBs tend to use them in wholly inappropriate situations.

Tate's book, as the title might imply, argues against the notion that every application you develop should be "Enterprise-grade," with all the associated complexity and overhead. He recommends the use of other third-party ORMs rather than CMP Entity Beans, and also suggests using a "better, faster, lighter" container to manage transactional applications called the Spring Framework. Like Hibernate, Spring is not J2EE-specification compliant and can run inside either a J2EE container or standalone. Both Hibernate and Spring have had a huge impact on the upcoming EJB 3.0 specification, and due to the influence of these external frameworks, EJB 3.0 will be lighter and simpler to use.