What’s new in EJB 2?

June 7, 2001— Sun Microsystems Senior Staff Engineer Linda DeMichiel and Senior Engineer Ümit Yaçinalp detailed several changes to the current draft of the Enterprise JavaBeans (EJB) specification at the JavaOne conference in San Francisco on Tuesday. In the one-hour “Enterprise JavaBeans 2.0 Technology: What’s New in the EJB Architecture” (TS-1829) presentation, the architects described:

• Local interfaces, which improve the efficiency of intracontainer entity relationships
• Container-managed relationships, in which the container manages object relationships between entity beans
• Changes to EJB QL, a query language for portable EJB finder methods
• Enhancements to the interfaces of Message-Driven Beans (MDBs), as well as to the home interfaces of remote entity beans

Local interfaces

A major requirement for the 2.0 revision of EJB technology is for a lightweight entity accessible only from within the container. For this purpose, the EJB 2.0 specification second public draft defines local interfaces — lightweight entity beans that optimize fine-grained, intracontainer entity access. Local objects are programmed using a home and a local (instead of a remote) interface. Yet local interfaces are not accessible from outside the EJB container (they are local to the container), and they are accessed with reference, rather than value, semantics. Access through a local interface avoids the overhead associated with a remote interface, so tightly coupled beans can communicate more efficiently.

In the first public draft of the EJB 2.0 specification, fine-grained access was modeled by so-called dependent objects, which were lightweight “helper” objects that grouped data and were specifically not entity beans. DeMichiel explained that dependent objects were deficient because their lifecycle was not managed by the EJB container and the container did not interpose calls to dependent objects. As a result, in the second public specification draft, fine-grained data objects have been promoted to full entity bean status, giving them home and local interfaces; and the EJB container now takes responsibility for their lifecycle management and call interpositioning.

Local interfaces are best used for modeling fine-grained entities with persistent state whose identity depends mostly or completely upon another object’s identity. For example, an individual LineItem object has little meaningful identity outside the context of an Order, and so is a candidate for a local interface. Entity bean remote interfaces work as before, providing remote access to coarse-grained business entities. Both interface types offer the benefits of container interposition in lifecycle management and persistent state access. The application modeler would choose which sort of interface to user.

Container-managed relationships

EJB 2.0 introduces additional modeling power, functionality, and complexity to container-managed persistence (CMP), including the new feature of container-managed relationships, or CMR.

Currently, entity EJB developers must shoulder the considerable burden of manually managing relationships between entity beans. For example, an Order entity bean might maintain a relationship with a collection of LineItem beans. Under EJB 1.1, the relationship between an Order instance and its LineItem objects must be handled by the programmer. Under the EJB 2.0 specification, the entity bean container can manage entity relationships based on a referential integrity model. In the second public draft of the EJB 2.0 specification dependent objects have been promoted to full entity bean status, but with a local interface.

From the entity bean provider’s point of view, CMRs are persistent relationships between local interfaces of entity beans. A reference from one entity bean to another is as simple as using an object reference of type Object (for unary) or Collection(for n-ary) relationships. One-to-one, one-to-many, and many-to-many relationships are all supported, and all relationships may be either unidirectional or bidirectional. When an object is added to or removed from a relationship, all other related instances and relationships are updated to maintain referential integrity.

EJB Query Language

EJB Query Language, or EJB QL, is yet another innovation of the EJB 2.0 container-managed persistence model. EJB QL provides a declarative way to navigate through networks of entity beans connected by container-managed relationships.

Currently, home interfaces include finder methods that allow developers to find beans based on various selection criteria. EJB QL is an SQL-like language used to describe entity finder methods. EJB QL queries are expressed in terms of the abstract persistence schema of entity beans, so they are portable and can be mapped to backend query implementations, such as vendor-specific SQL.

EJB QL methods can also define select methods, which are like finder methods whose results are not available to the client view.

Developers using an EJB 2.0 implementation will be freed from writing finder (and select) methods. Instead, the container provider’s tools will be responsible for generating finder and select methods based on the EJB QL expressions defined for the bean.

Changes to EJB QL between the first and second public drafts include aligning the syntax with the changes to container-managed persistence; basing the type system on only the abstract schema (for portability); and removing dependent objects, remote navigation and type casting, and finder expressions. Several other changes were made to EJB QL:

• The SELECT clause in EJB QL queries is now mandatory
• SELECTclauses can now be DISTINCT, eliminating duplicates from the result set
• An OBJECT operator in the SELECT clause indicates that objects, rather than values, are being selected
• The MEMBER OF operator provides searches for the presence (or absence) of a value in a collection

For more on EJB QL, see Chapter 11 of the second public draft.

Component interface enhancements

DeMichiel and Yaçinalp also described several enhancements to the interfaces of both remote entity beans and message-driven beans.

In EJB 2.0, remote entity beans will now have new security features, allowing unchecked and uncallablemethods. A method marked uncheckedin a deployment descriptor makes the method executable with no security checks; methods marked uncallablecannot be called regardless of the permissions of the caller.

The API of message-driven beans (MDBs) in the EJB 2.0 first public draft was tightly bound to the Java Messaging Service (JMS) API. The second public draft removes that dependency to increase freedom of choice in technology selection.

Conclusion

The improvements to the EJB 2.0 specification are a result of the specification leads’ study of existing technologies’ usage patterns, conferral with vendors about their needs, and input from the developer community. Their presentation showed that EJB 2.0 is well on its way to becoming a stable reality.