One of the exciting new features of the WebSphere Application Server (WAS) 5.0 release is support for J2EE 1.3. With this release of the J2EE specification comes EJB 2.0, which contains a number of features that effectively make both session and entity beans far more flexible and scalable components of an application's architecture.

Major advancements in container-managed persistence (CMP), along with new capabilities such as local interfaces, combine to provide far greater consistency and efficiency for EJBs than was ever possible with earlier versions of the specification. Another important capability introduced in EJB 2.0 is the ability to specify and implement relationships between entity EJBs. These container-managed relationships (CMR) allow developers to declare relationships of various cardinality between entity beans, while deferring the actual implementation and enforcement of these relationships to the underlying container. Collectively, all of these EJB 2.0 features make it possible to implement complex associations between fine-grained entity beans - a capability that has been desired since the introduction of entity beans to the EJB specification.

This article will take a look at CMR, along with the CMP advancements and new local interface features that make up the EJB 2.0 specification and that will be supported by WAS 5.0.

EJB 2.0 & WAS 5.0: Solid Underpinnings for CMR
Before delving into CMR, it is important to first address the other features of EJB 2.0 upon which CMR depends. The first feature is the advanced CMP model introduced with EJB 2.0. In this new version of the specification, the persistent state of an entity bean can no longer be explicitly defined in the entity bean class as attributes. Instead, developers must provide abstract accessor ("getter") and mutator ("setter") method declarations within an abstract bean implementation class. Upon compilation and subsequent deployment, the J2EE container will supply the appropriate implementations for these abstract methods, including the automatic storage and retrieval of bean attribute values to and from the underlying persistent store. The elimination of explicit bean state attributes means that such attributes can no longer be explicitly addressed in code. Instead, they can only be addressed via their respective getter and setter methods. An example of this change is illustrated in Listings 1 and 2, in which an extract of a Loan entity bean is shown under the EJB 1.1 (pre-WAS 5.0) and EJB 2.0 (WAS 5.0+) paradigms, respectively.

As a comparison of the listings shows, it will be necessary for applications employing EJB 1.1 entity beans to be refactored upon migration to WAS 5.0. These changes promote bean encapsulation and consistency of access, which were somewhat compromised under previous versions of the EJB specification. In addition, it will be shown that the consistent use of getter and setter methods to access bean attribute state under CMP will be extended to get- and set-related bean instances under CMR.

WAS 5.0 extends the power of EJB 2.0 CMP with its support for advanced data sources. Under EJB 2.0 it is possible to use CMP to map a bean's state to a nonrelational data source, such as an object-oriented or hierarchical legacy database. Most EJB 2.0-compliant application servers overlook this subtle point, relying solely on JDBC data sources. Instead, WAS 5.0 employs Java Connector Architecture (JCA)-based resource adapters to manage the physical connections beneath its data sources. In fact, WAS 5.0 developers who wish to use CMP with traditional relational databases must use a new JCA-based Relational Resource Adapter. This architecture makes it much simpler to provide access to nonrelational data sources. This concept is especially compelling when one considers the possibility of supporting CMR relationships between CMP beans spanning vastly different kinds of data stores, as illustrated in Figure 1.

Another EJB 2.0 feature that will be supported by WAS 5.0 - and that is crucial to CMR support - is the local interface. Local interfaces were, in part, created to address the networking overhead associated with using traditional remote interfaces. Local interfaces are essentially pure Java interfaces that do not extend java.rmi.Remote. As such, they incur none of the networking or serialization overhead of their remote counterparts. The introduction of local interfaces means that it is now possible, and entirely appropriate, to design EJB applications using fine-grained entity beans. CMR relies upon local interfaces to establish and maintain relationships between entities. In fact, any bean that does not provide a local interface can only participate on the source side of a CMR relationship. CMR's reliance on local interfaces makes the implementation and enforcement of interrelated entities extremely efficient. Hence, with EJB 2.0 and WAS 5.0 it is entirely appropriate to designate robust 1-to-1 (1:1), 1-to-many (1:m), or many-to-many (m:n) relationships between fine-grained entities. Such designs were expressly forbidden in earlier incarnations of the EJB specification due to the enormous performance implications resulting from networking overhead. Entire design patterns, such as the J2EE Composite Entity, were created to deal with this overhead by creating coarser-grained entities. Under WAS 5.0, such patterns should, for the most part, no longer be necessary. In fact, unless absolutely necessary, such patterns should be removed from J2EE applications when migrating to WAS 5.0.

Exploring CMR
Implementing CMR under WAS 5.0 requires a combination of support structures defined at the bean, database, and deployment descriptor levels. At the bean level, CMR support requires extending the familiar CMP concept of providing abstract methods for attribute access to methods that provide container access to the relationships between entity beans. In CMR, such relationships can be classified by cardinality and navigability. For simplicity, let's assume the existence of two entity bean classes, A and B. CMR can support 1:1, 1:m, or m:n relationships between instances of A and B. At the bean level, abstract relationship methods must be defined to allow the container to enforce and manage the relationship.

To explore CMR in more concrete terms, let's discuss its use in a simplified financial application involving loans, borrowers, and addresses. To further simplify our example, we will assume that these entities support only local interfaces. In our application, a given borrower can have one address and potentially multiple loans. Hence, the relationships are 1:1 for Borrower_Address and 1:m for Borrower_Loan. At the bean level, the Borrower_Address relationship would require that abstract methods be defined in the source bean (borrower) implementation class to allow the container to manage (i.e., get/set) the target address instance automatically.

Listing 3 illustrates the method declarations that would be required in the borrower interface and implementation classes to support the aforementioned relationship.

Borrower also has a 1:m relationship with Loan, so the Borrower local interface and implementation class must provide abstract methods to support this relationship in addition to the 1:1 relationship with Address. Assuming the relationship is navigable from Borrower to Loan, Listing 4 illustrates the methods required on Borrower to support its 1:m relationship with Loan. The key difference between these methods (besides the target bean class used) - and the methods supporting the 1:1 relationship between Borrower and Address - is the use of java.util.Collection as the parameter and return types for the 1:m relationship in lieu of the target bean class. A subclass of java.util.Collection, such as java.util.Set, could have been used as well.

At the bean level, many-to-many relationships are not appreciably different from one-to-many relationships. However, the differences are more interesting at the database level.

The underlying database is responsible for the long-term durability and persistence of container-managed relationships. CMR would be useless without a permanent account of how various bean instances are related. CMR relationships are persisted in the underlying database using the combination of primary and foreign keys representing the entity beans that are interrelated. Specifically, for 1:1 and 1:m relationships, the target (or many-sided) bean database record must contain a foreign key (FK) that references the source (or one-sided) bean instance. For example, to support the Borrower_Address 1:1 mapping discussed earlier, the underlying table for Address, say Address_TBL, must contain a column(s) that references the primary key (PK) of the specific Borrower instance to which the Address belongs. So, if borrowers are uniquely identified by social security number and addresses are uniquely identified by a "one-up" object identifier or OID, then each Address_TBL record must contain a foreign key to the social security number PK identifying the source borrower. Similarly, each Loan_TBL record representing a Loan bean instance must contain a foreign key to the owning or source borrower. These table relationships are depicted graphically in Figure 2.

Many-to-many relationships are particularly interesting at the database level. For m:n relationships, a junction table containing foreign key columns to the primary keys of the relationship participants must be introduced. Suppose, for example, that we adjust our example to support m:n relationships between borrowers and addresses. In this case, the table mappings shown in Figure 3 would be needed in order to support the relationship.

The last major step required to exploit CMR under WAS 5.0 is to make deployment descriptor-level declarations of the relationships. These descriptor definitions can either be created using the EJB Relations capabilities of the WAS Application Assembly Tool (AAT), or manually. Either way, the relationship definitions will ultimately exist within the EJB JAR's ejb-jar.xml descriptor file. A relationships XML stanza must be added after the enterprise beans XML stanza within ejb-jar.xml. Within the relationships stanza are one or more ejb-relation stanzas that define the specific semantics of a particular container-managed relationship between two beans. Each ejb-relation contains a name, along with the roles each bean plays within the relationship. The cardinality of the beans participating in the relationship is defined within these role definitions. Listing 5 provides an illustration of the CMR descriptor definitions required to model the Borrower_Loan 1:m CMR relationship.

Each major stanza can be optionally identified with an ID attribute, as shown in the listing. For the Borrower_ Loan relationship, there are two roles - one for the borrower and one for the loan. The borrower is an owner of loans, and there is one borrower for many loans in the relationship. Hence, the borrower's multiplicity is specified as "one", and its bean is explicitly referenced within the ejb-name element of the relationship-role-source stanza. The subsequent cmr-field stanza declares the Borrower bean attribute that will be used to contain the loans associated with that borrower. In the spirit of CMP 2.0, the container will use the setLoans and getLoans accessor methods to manipulate this relationship, instead of explicitly accessing a declared attribute. The second relationship role covers loan relationships with borrowers. As such, its multiplicity is "many", and its "borrower" bean attribute will ultimately refer back to the owning borrower.

The CMR stanzas accommodate 1:1, 1:m, and m:n mappings between entity beans. Hence, there is considerable flexibility offered to cover the most demanding persistence relationships.

Conclusion
WAS 5.0's support for EJB 2.0 and CMR will provide significant advantages to system architects and designers. Much of this functionality was previously deferred to bean-managed persistence (BMP) entities, external object-to-relational mapping products (like Oracle's TopLink), or simply not tackled for fear of the overwhelming complexity of implementing the solutions in code. With WAS 5.0, the power of declarative relationship management will allow architects to create simpler, yet more sophisticated and robust J2EE solutions.

Reference
Alur, D., Crupi, J., Malks, D. (2001). Core J2EE Patterns - Best Practices and Design Strategies, Java 2 Platform, Enterprise Edition Series. Sun Microsystems Press/Prentice Hall.