Changes in EJB 1.1 Specification (Java Enterprise in a Nutshell)

7.9. Changes in EJB 1.1 Specification

Shortly before publication of this book, Sun released a public draft of Version 1.1 of the EJB specification. In this incremental release, Sun tightened up a few areas, changed its scheme for deployment descriptors, and made various other updates to the specification. The major updates are described below, followed by a short laundry list of the more significant changes.

7.9.1. XML-Based Deployment Descriptors

In EJB 1.1, the javax.ejb.deployment package is deprecated, and deployment descriptors for enterprise beans are composed using XML, instead of serialized DeploymentDescriptor objects. In the XML DTD defined in EJB 1.1, there's a clear separation of information regarding the structure of the enterprise bean(s) from information regarding the use of the beans in a particular application. The structural information for an enterprise bean includes components such as its various classes, environment variables the bean recognizes, and the container-managed fields (for entity bean). Application-specific information includes, for example, values for environment variables, the various client roles that are used for controlling access to beans, and permission settings for these various roles.

Similar to the deployment descriptors defined in EJB 1.0, these XML-based deployment descriptors are intended to include only structural information when a bean provider ships a collection of enterprise beans to application developers, and both structural information and application-specific information when an application provider ships an EJB-based application to an application deployer. The separation of these two types of information in the XML deployment descriptor makes this process more straightforward than under EJB 1.0.

The XML deployment descriptor for a set of enterprise beans can be provided separately or as part of an EJB-JAR file. In an EJB-JAR file, the deployment descriptor must be in the file META-INF/ejb-jar.xml.

7.9.2. Entity Beans Required

In EJB 1.0, support for entity beans was optional for compliant EJB servers. In EJB 1.1, all compliant servers must provide support for entity beans.

7.9.3. Home Handles

EJB 1.1 adds a new HomeHandle interface and a getHomeHandle() method on the EJBHome interface. A HomeHandle is a serializable reference to a home interface for an enterprise bean, analogous to the Handle interface, which represents a serializable reference to an EJB object. This allows a client to get a handle for a home interface and serialize it to some persistent storage, like a filesystem or database. The serialized HomeHandle can be deserialized later (in the same or another Java VM) and used to acquire a reference to the same home interface.

7.9.4. Detailed Programming Restrictions for Bean Implementations

EJB 1.1 lists detailed restrictions on what an enterprise bean implementation should avoid in its business methods in order to be portable across different EJB servers. These include rules against using sockets, creating class loaders, and including writable static fields on EJB implementation classes.

7.9.5. Assorted Other Changes

In addition to changes already listed, the following are some of the more significant updates introduced in the EJB 1.1 specification:

Finder methods on entity beans can now return java.util.Collection types from Version 1.2 of the Java 2 platform.
Entity bean primary keys can now be java.lang.String objects.
All ejbCreate() methods on entity beans, including those with container-managed persistence, must now return the bean's primary key type. Previously, container-managed entity beans had ejbCreate() methods that returned null, and bean-managed beans returned their primary key type. With this change, a container-managed bean can implement ejbCreate() methods that return null, and this bean can optionally be subclassed to define a bean-managed bean that returns an actual primary key.
All EJB clients should use the narrow() method on the javax.rmi. PortableRemoteObject interface in order to cast remote and home object interfaces for enterprise beans. This guarantees that clients will be compatible with EJB servers that use RMI-IIOP for exporting enterprise beans.