Web Forefront

Allowing you to process meta-data from your source code to generate newly minted data structures or configuration files, this framework/tool was a winner since late 2002. By simply placing a few lines in your core bean class, XDoclet avoided you the drudgery of generating -- as a separate process -- the ancillary interfaces and deployment descriptors needed in EJB 2.1 and prior versions. EJB 3.0 has adopted this same approach through annotations -- which is a functionality provided by Java 5/JDK 5. ( SIDENOTE: Yes, you read correctly : EJB 3.0 is pegged to features available only in JDK 5.0, so this is a strong indication that EJB 3.0 -- along with the whole J2EE suite in its 1.5 version -- will not be backward compatible with minor versions of the JDK ).

If you ever used entity EJB's in any of their flavors -- CMP (Container Managed Persistence) or BMP (Bean Managed Persistence) -- then you should be no stranger to the complexity of their persistence mechanism. EJB 3.0 has taken the same course some in the industry have taken for almost a decade : O/R mapping.

TopLink was among the first companies to offer such a solution, but possibly Hibernate as an open source framework -- released a few years back -- was a tipping point in favor of O/R mapping in J2EE development. This is definitely a proven technique for dealing with the impedance mismatch of the object/relational world.

Lightweight frameworks came on the radar as a solution to the growing complexities of developing in J2EE, among them, the extensive number of API's which needed to be dominated in order to generate production quality apps and the invasiveness produced by these same API's.

EJB 3.0 takes a series of lightweight framework approaches. For example, no longer will you need to use inheritance hierarchies to create EJB's, creating a plain old java object (a.k.a POJO's) will be sufficient to morph it into an EJB. This will allow you to concentrate on the real problem -- business logic -- than on learning a particular API needed to create EJB's.

This approach of using POJO's, will also lead to EJB achieving on of the tenets of agile software development : Testing. In previous versions of EJB's it was extremely difficult -- if not impossible -- to develop tests on your components due to same invasiveness of using specific API's, however, using POJO's the task of creating tests is extremely simplified, since the logic is clear cut.

Dependency injection is another feature which has been incorporated into EJB 3.0 that is currently available in lightweight frameworks. The task of accessing external resources -- such as Databases or security credentials -- in previous versions of EJB's, required the need to code JNDI lookups which entailed an error prone process of casting and error checking. In EJB 3.0 this task is simplified through dependency injection, a process which allows you to instantiate and access your resource through a simple annotation.

These are just a few of the similarities I have found in EJB 3.0 related to existing approaches, it is nice to see that the EJB working group has taken note of the relevant techniques used in other frameworks and incorporated them into their spec, a step that will surely go a long way in helping clear EJB's of their overly complex past.