Author: Vance McCarthy
When it comes to the future of EJB 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 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.
And just when is the new EJB coming? During the TSS Java Symposium, dates for an approved EJB 3.0 spec ranged from one to two years. “This is a non-trivial task, and a fairly lengthy process,” DiMichiel said.
Inside the EJB 3.0 revamp
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 lightweight 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 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 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:
- 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
- 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.
Vance McCarthy is editor in chief of Open Enterprise Trends. This article is reprinted by special arrangement with the publisher and author.
Category:
- Java
