Enterprise JavaBean 2.0 Specification Changes

Print-friendly Version

Articles Index

The Enterprise JavaBeans (EJB ) architecture is a component architecture for developing and deploying component-based distributed business applications. The EJB specification defines the responsibilities of both component developers and EJB server and container vendors. The EJB 2.0 specification builds upon and extends the architecture and functionality defined by the earlier EJB 1.0 and 1.1 specifications.

This article summarizes the changes introduced by the 2.0 specification. (Note that the 2.0 specification is not yet public, so this article focuses on high level information only.) It provides an early view of the forthcoming EJB changes so that developers can plan accordingly. Keep in mind that the EJB 2.0 specification is not in its final form, and there could be further changes.

In brief, the EJB 2.0 specification introduces these new features:

• Message-driven beans
• An improved architecture for container-managed persistence
• Container-managed relationships for entity beans with container-managed persistence
• Local interfaces
• Enterprise JavaBeans Query Language

Types of Enterprise Beans

The EJB 2.0 specification introduces a new type of enterprise bean, called a message-driven bean, in addition to session beans and entity beans. Session and entity beans are very much the same as in the earlier EJB architecture. However, there have been changes to how these beans are accessed and used.

• Session beans
  Session beans represent non-persistent server-side components that may be transaction aware. Typically, session beans model processes, services, and client-side sessions. As before, a session bean may be stateful or stateless. A stateful session bean maintains session data for its client between operations. Thus, it is often used to model services such as shopping carts and bank tellers--services that usually require multiple steps or operations. Stateless session beans are lightweight, scalable components that are used to model services that do not maintain session data for the client.
• Entity beans
  Entity beans are server-side components that are persistent and transactional. They are used to model persistent data objects. An entity bean can manage its own persistent state in a datastore and its own relationships, in which case it is a bean-managed persistence (BMP) entity bean. Or, it can let the EJB container manage its persistent state and relationships, in which case it is a container-managed persistence (CMP) entity bean. Container-managed persistence has changed significantly in the 2.0 specification from the earlier specifications.
• Message-driven beans
  Message-driven beans are stateless, server-side, transaction-aware components that process asynchronous messages delivered via the Java Message Service (JMS). Asynchronous messaging allows applications to communicate by exchanging messages in a way that leaves senders independent of receivers. That is, the sender sends its message and does not have to wait for the receiver to receive or process that message. Message-driven beans serve as router processes that operate on inbound enterprise messages from a JMS provider. You might use a message-driven bean to integrate an EJB-based system with a legacy system or to enable business-to-business interactions. The message-driven bean's sole responsibility is processing messages, because its container automatically manages the component's entire environment.

Container-Managed Persistence in EJB 2.0

The changes to the EJB 2.0 specification principally concern container-managed persistence (CMP). Along with CMP, the 2.0 specification introduces container-managed relationships (CMR).

The 2.0 approach to CMP allows multiple entity beans to have container-managed relationships among themselves. The automatic management of relationships, plus the container management of the referential integrity of relationships, is an advancement above the EJB 1.1 specification which allowed you to expose only an entity bean's instance state through its remote interface.

The 2.0 approach, with the introduction of local interfaces, offers some significant advantages, especially in terms of greater flexibility. The 2.0 approach to CMP is a lightweight way of doing fine-grained container-managed persistence. It uses a local model that can be more tightly coupled than the remote model, and it avoids the performance overhead of the remote model. It is also closer to the Java programming model, particularly with regards to passing parameters between enterprise beans.

If you are familiar with the earlier version of the EJB 2.0 specification, note that the Persistent Manager and the use of dependent objects to model entity bean relationships are both gone. Together, CMP with managed relationships--that is, container-managed persistence at the entity bean level with local interfaces--represents the functionality encompassed by dependent objects. The EJB container performs the persistent manager functionality.

CMP and CMR Fields

In the 1.1 specification, a client stored and accessed persistent data via an entity bean's instance variables. In the current 2.0 specification, instance variables can be designated as

• Container-managed persistent fields (cmp fields)
• Container-managed relationship fields (cmr fields)

These cmp and cmr fields are defined through the deployment descriptor. The bean developer also defines get and set methods in the entity bean to retrieve and set the values of these logical fields. You do not access the instance variables directly. Instead, much like with JavaBeans, you use the entity bean's get and set methods to retrieve and set these instance variables. Keep in mind that the get and set methods only pertain to variables that have been designated as cmp or cmr.

Furthermore, the deployment descriptor specifies the relationships between entity beans, and these relationship specifications become the schema definition. Relationships are defined by the bean provider and specified in the deployment descriptor. Then, when the bean is deployed, the bean relationships may be captured in a relational database. For example, a relationship between two beans specified in the deployment descriptor may appear as a foreign key relationship in a relational database.

Entity Bean Relationships

Container-managed relationships--represented by the cmr fields in the deployment descriptor--support both one-to-one relationships and one-to-many relationships. With one-to-many relationships, the entity bean uses a Java Collection to represent the "many" side. This ability to manage relationships is closely aligned to relationship modelling in relational databases.

The EJB container maintains the referential integrity of the entity bean relationships. For example, in a one-to-one relationship, if you change one side of the relationship, the container automatically drops the old relationship and replaces it with the newly formed one-to-one relationship.

This relationship functionality is not available to bean implementations adhering to the EJB 1.1 specification. However, the 2.0 specification support continues to 1.1 level enterprise beans.

Bean Interfaces and Implementation

According to the 2.0 specification, the implementation classes for entity beans that use CMP are now abstract classes. The implementation classes for non-CMP entity beans and session beans are the same as under the 1.1 specification.

Session beans and entity beans in 2.0 can have two types of interfaces: a remote interface and a local interface.

• Local Interface
  The local interfaces for session and entity beans provide support for light weight access from enterprise beans that are local clients. That is, the bean uses a local interface if the bean wants to provide tight coupling with its clients with pass-by-reference semantics. The local interface is a standard Java interface that does not inherit from RMI.
• Remote interface
  A bean that needs to have remote capabilities--the bean inherits from RMI and interacts with distributed clients--uses a remote interface. A bean can have both a local and a remote interface--that is, it can provide both a local and a remote client view.

Typically, however, a bean will be designed to provide only one or the other interface. Similarly, a bean can have a remote home interface and/or a local home interface.

In the 2.0 specification, a bean typically uses its remote interface to expose its methods across the network tier. A bean uses the local interface to expose its methods to other beans that reside within the same container. It is thus possible to directly access a bean through its local interface without the overhead of a remote method call.

Local interfaces provide the foundation for container managed relationships among entity beans and session beans. The bean uses the local interface to maintain its references to other beans. For example, entity beans use local interfaces to maintain relationships to other entity beans. They also allow session and entity beans to be tightly coupled with their clients. Using local interfaces, beans can also expose their state and use pass-by-reference to pass their state between related bean instances.

Query Language

The EJB 2.0 specification also introduces a query language called EJB Query Language, or EJB QL. EJB QL defines query methods--finder and select methods--for entity beans with container-managed persistence, and it is intended to be portable across EJB containers.

EJB QL is based on SQL92. However, it has been enhanced to allow querying or navigation over entity bean relationships. That is, a query can begin with one entity bean and, from there, navigate to related beans. For example, the query can start with an Order bean and then navigate to the Order's line items. It can also navigate to the products referenced by the individual line items, and so forth.

EJB QL builds on the container-managed relationships specified in the deployment descriptor. The query is specified in the deployment descriptor. The container then generates the QL implementation for the query.

For example, in the deployment descriptor, you might have the following query:

Select O from Order O, o.lineitems
 L where L.customer.name = "John Doe" 

A query such as this navigates two relationships: from Order to lineitems and from lineitems to customer.

Conclusion

This article has presents a brief overview of the forthcoming changes to the Enterprise JavaBeans architecture that the EJB 2.0 specification will introduce. Refer to the actual specification for more complete information. Keep in mind that further changes may occur until the time that the specification is released in its final form.

About the Author

Beth Stearns is the principal partner of ComputerEase Publishing, a computer consulting firm she founded in 1982. Her client list includes Sun Microsystems, Inc., Silicon Graphics, Inc., Oracle Corporation, and Xerox Corporation. Among her publications are the "Java Native Interface" chapter in "The Java Tutorial Continued" book in the Addison Wesley Java series, "The EJB Programming Guide" for Inprise Corporation, and "Understanding EDT", a guide to Digital Equipment Corporation's text editor. Most recently, she co-authored with Vlada Matena of the forthcoming Addison Wesley Java series book, "Applying Enterprise JavaBeans: Component-Based Development for the J2EE Platform."

Have a question about programming? Use Java Online Support.

Back to top