This article is sponsored by the Java Community Process.
Linda DeMichiel is Sun Microsystems' specification lead and chief architect for Enterprise JavaBeans 3.0 and the Java Persistence API (JSR 220). In the first segment of this two-part interview, she discusses how the EJB 3 APIs simplify development, how to choose between annotations and XML in configuring an EJB environment, and suggests a practical way to learn about EJB 3.
Frank Sommers: The Enterprise JavaBeans 3.0 specification, JSR 220, is actually a set of three specifications. What are these documents, and why have three separate specifications?
Linda DeMichiel: There are three documents in the EJB specifications, but there are actually two specifications: EJB 3 core, and the Java Persistence API. When we started work on EJB 3, the Java Persistence API was at first strongly coupled with the EJB 3 specification, as it was intended to provide an ease-of-use alternative for the entity beans of EJB 2.0 and 2.1.
When we released the first early draft of the EJB 3 spec, we got considerable feedback suggesting that what we were doing with persistence in EJB 3 should have a broader scope [than entity beans]. We received feedback that that part of the spec should also be made available for persistence within other parts of the Java EE platform, such as the web tier, and that it would be useful outside Java EE containers, namely in Java SE environments.
In EJB 3.0, entity beans continue to be supported in their earlier form, but the Java Persistence API provides a POJO-based light-weight persistence technology, along the lines of other object-relational mapping technologies that had evolved in the industry. Some of those O/R technologies, and the communities around them contributed many of the ideas and constructs used in the Java Persistence API.
As the work on the specification evolved, the scope of the persistence work grew to the point where it became appropriate for it to become a separate specification document—also reflecting the fact that the persistence API was available for use outside EJB 3 containers. That explains why we have a separate Java Persistence API document, even though it is part of the Enterprise JavaBeans 3.0 release.
The EJB 3 Simplified API document is only 59 pages, and is basically a guide to the simplified EJB API. A year ago or so when I was producing the EJB Core Contracts document, the Expert Group agreed that it would be useful for developers to have a document that summarized the new simplified EJB API in a concise form so they didn't have to wade through the 500 pages of a document intended more for container implementers in order to extract information about the ease-of-use features of EJB 3.
What you find in the EJB Simplified API document is subsumed in the Core Contracts document—the "big" spec. Some of that information is redundant also because it captures functionality and annotations that originated within the scope of EJB 3, but which were adopted into the Java EE APIs. Some of the annotations for injection, for instance, were adopted into JSR 250, the Common Annotations JSR, so they could be used by other technologies. I left those in the EJB Simplified API document for convenience so that EJB developers would be able to get an overview of the new EJB 3.0 APIs more readily without having to download other specifications.
The simplified document is a good way for developers to get started learning about EJB 3, and then they can go on to the persistence [API] document, because the persistence document does not overlap with the Simplified API document.
Frank Sommers: Among the stated goals of EJB 3 was to simplify the developer's job in creating EJB applications. Could you please tell us about some of the EJB 3 features that make that possible?
Linda DeMichiel: In its genesis, the idea of EJB technology—and this predates my participation in EJB—was to provide an environment that offloaded some of what developers needed to do to develop enterprise Java applications onto the EJB container. If you think of the services the container provides—for example transaction management, security management, pooling, portable environment access—all of those were there in the original EJB work, in EJB 1.1, and some even in the 1.0 specs. But they were there in a form that was fairly awkward to use. When EJB was first introduced, it was perceived as a simplification. But we've grown more sophisticated, and learned that these APIs were rather clumsy and hard to understand.
What we tried to do with EJB 3 is to preserve all the good things about the EJB architecture for the management of applications, but make that [functionality] available in a much more easy-to-use form. In a sense, it's been more a transformation of how developers use this technology than a radical change to what the underlying services are.
We introduced new features to the API to achieve that: EJB did not have dependency injection before, for instance. Interceptors are also new to this release, which is functionality available to advanced developers. And we now use annotations to simplify functionality that had been there in a different form.
Also, in prior EJB versions, you had to program to predefined EJB interfaces, which were there more for the sake of the container than to facilitate the task of the developer. With EJB 3, we tried to offload more of that work to the container. As a result we eliminated the requirement for the home interfaces and the EJB component interfaces, and instead substituted more natural Java language constructs—business interfaces, which are just ordinary Java interfaces.
This article is sponsored by the Java Community Process.