Does EJB 3.0 Put J2EE Thinking on Its Head?

Developers got their first view into the future of Java development during last week's TheServerSide Java Symposium, and what's in store may put some Java thinking on its head -- literally. See why EJB Expert Group members say today's "view of the [J2EE] container will disappear," as the bean takes on more significance -- and self-directed smarts. See what the pursuit of EJB simplicity might mean to your career, and what other devs are saying.

Tags: EJB, Java, Bean, Container, DeMichiel, Interfaces, J2EE Developers,


Developers got their first view into what may be the future of Java development during last week's TheServerSide Java Symposium. What's in store for EJBs, in fact, may put some long-held Java thinking on its head -- literally.

When it comes to the future of EJBs (Enterprise Java Bean) development, it will be the bean -- rather than the container -- that will be the focus for J2EE developers. It's a move that has prompted quite a debate at TheServerSide.com's Java/J2EE community. Comments thus far range from glee over the plan to ease the dev load for J2EE and non-J2EE developers, to concern and consternation that skills and Best Practices of today's J2EE devs (now at the top of their game) may have to be relearned (or unlearned).

"The view of the container needs to evolve," said Linda DeMichiel, EJB 3.0 spec lead and a Sun J2EE architect during her TSS Java Symposium presentation in Las Vegas. Further on in her talk, DeMichiel stated: "With EJB 3.0, today's view of the container will disappear, with an inversion of the [roles] of the container and the bean," and outlined just how the EJB 3.0 Expert Group in is considering making these changes.

Inside the EJB 3.0 Revamp
Where The Bean is "The Thing"

The mission for EJB 3.0 is to greatly simplify Java development by moving away from complex EJB requirements and reverting, where possible, to Plain Old Java Objects (POJO). Also gone in EJB 3.0 will be requirements for EJB component interfaces, Home interfaces, callback interfaces, and even anti-patterns.

To achieve this greater simplicity, DeMichiel said EJB 3.0 is considering adding support for light-weight domain modeling -- including inheritance, polymorphism and O/R (object relational) mapping using Java metadata. Custom type mapping is also under EJB 3.0 Expert Group consideration, she added.

At the core of the changes, DeMichiel said, is that after almost a year of hard research, testing and discussions the EJB 3.0 Expert Group has decided to looking to make the bean itself, rather than the container, the focus of J2EE development efforts. "The view of the container needs to evolve," she said. "With EJB 3.0, today's view of the container will disappear, with an inversion of the [roles] of the container and the bean."

The needed 'intelligence' for this new, smarter, self-actualizing bean will come in large part from from Java's much greater reliance on metadata.

In fact, J2EE developers will use metadata to define the nature and properties of a bean, she said. Metadata will generate the interface files, eliminate the need for deployment descriptors, and provide the demarcation points for where the container needs to interface with a bean. "With metadata, we are inverting the model for how a bean and a container interface," she said. "It will be the container's responsibility to figure out what the [bean] needs."

With EJB 3.0, DeMichiel said the Java Community Process (JCP) is "radically simplifying our view of what a 'bean' is." There are two key shifts in the Java landscape driving these changes, DeMichiel said, which include:

(1) The lack of good Best Practices for developing web-to-legacy Java applications (especially end-to-end web-to-legacy transactions that need ways to retain 'state' from the web to the non-web world); and

(2) The increased desire by Sun and other Java vendors to make Java more attractive to non-
Java/J2EE developers.

As far as query types, EJB 3.0 revs EJB QL, adding support for the container's ability to interposition and manage transactions, security and caching. As a way to improve J2EE's support for web-to-legacy transactions, DeMichiel also said the EJB 3.0 Expert Group is considering defining a third type of JavaBean, with proposed names such as a Stateless Session Bean or a Message-Driven Bean. "We will evaluate a 'service bean" type" before the final draft of EJB 3.0 is released, she said.

And just when is EJB coming? During the TSS Java Symposium, dates for an approved EJB 3.0 spec ranged from 1 to 2 years. "This is a non-trivial task, and a fairly lengthy process," DiMichiel said.





back