May 5, 2011, 4:30 p.m.
posted by franni
Concepts in EJB 2.0 Relationships
So what you want is the best of both worlds. You want to be able to represent object relationships like you do in standard Java classes, but you also want to take advantage of the automatic persistence, distribution, and transaction features that you get from EJBs. The EJB 2.0 specification provides a solution by defining entity EJB relationships within the specification. This section explains how relationships are defined between entity beans within the deployment descriptor.
The EJB 2.0 specification allows for relationships to be defined between two entity beans with CMP. This is accomplished with the definition of a new type called an ejb-relation in the EJB deployment descriptor that contains two ejb-relationship-roles where each role has a reference to an entity bean by name within the ejb-role-source element. Each ejb-relation element is defined within the relationships tag of the deployment descriptor. These relationships can have multiplicities of one-to-one, one-to-many, and many-to-many. The multiplicity of a relationship role is defined in terms of the number of instances of the source entity with respect to the relationship.
Entity bean relationships can be bidirectional or unidirectional. This means that a relationship can be navigated from both entities if it is bidirectional and navigability can be restricted to only one entity if it is unidirectional. Navigability between entities defined in a relationship is controlled by defining a CMR field (cmr-field) on the relationship role that you would like to traverse. Thus this cmr-field will be implemented on the source entity bean for the relationship role.
A cmr-field is very similar to a cmp-field in that both have to be valid Java identifiers and they obey the same generation rules for the entity. This basically means that there must be get and set accessor methods defined for each cmr-field which will be used for traversal and update of relationships. Also, the cmr-field type must be either the local interface of the other relationship role's source entity within the relationship or a collection (i.e., java.util.Collection or java.util.Set). If the cmr-field type is a local interface, it represents a cardinality of 0..1 within a relationship. If it is of a collection type, it represents a cardinality of 0..N in a relationship.
CMRs are defined in terms of local client views of the related beans. This means that accessor and setter methods for the cmr-fields can only appear on the local interface. Remember, the type of a cmr-field must be a local interface, java.util.Collection, or java.util.Set. Therefore, an entity bean that does not have a local client view can only have unidirectional relationships from itself to other entity beans. The lack of a local client view restricts navigation to the entity bean from another related entity.
Chapter 16 touched on what it would take to add relationships by hand to your application but it did not go into detail about maintaining referential integrity. There are two types of referential integrity: relational database constraints and container-managed entity bean integrity. The strict definition of referential integrity within a relational database is that each foreign key value must have a corresponding primary key value. This is accomplished by creating foreign key constraints which define a set of columns within the owning table that match in order, size, and type of the columns in the primary key of the owned table. Defining foreign key constraints on a database can slow performance and force the application to insert and delete rows into database tables in the proper order so that the foreign key constraints are not violated (i.e., the row in the owned table must exist before the row in the owning table).
Among container-managed entity beans, maintaining referential integrity means maintaining references between two objects that have been related. For example, we could have an Employee who is the submitter of a collection of TimeSheets as shown in Figure. If a TimeSheet were added to the collection of timesheets for an Employee, referential integrity mechanisms would ensure that the TimeSheet also refers to the Employee to which it was just added. The CMR support handles referential integrity among container-managed entities for you. EJB modules running in WebSphere cannot run with foreign key constraints defined since the insert and delete queries within a transaction are not ordered in such a way that ensures that the foreign key constraints are not violated.
We will go into more detail about CMRs when we discuss relationship support in WSAD.