Relationships among entity EJBs are a standard part of the EJB 2.0 specification. See, especially, Chapters 10 & 11. Please see those discussions as well as the discussions in Kyle Brown's book, especially chapters 24 and 25.
Basically, EJB relationships allow you to do most of the things with EJBs that DBMS relationships allow you to do in a conventional relational database. The difference is that relationships are defined declaratively, through the XML deployment descriptor, they are supported by the EJB Container, and they are accessed through methods generated by WSAD for you.
Several points are worth emphasizing. First, relationships are maintained through foreign keys, but you do not define foreign keys as conventional EJB variables; they are generated and maintained by the container. Second, relationships generate additional methods on the local interfaces of the EJBs involved. Consequently, you will need to work with the Home interfaces for beans through JNDI, rather than using factory classes as you might for accessing them through their Remote interfaces. Finally, Container Managed Relationship (cmr) fields may be used in EJB QL queries, just like conventional fields, but only for EJBs within the same jar file. Practically, this means within the same WSAD project.
Since Relationships often involve queries, you should review the lesson on EJB QL. Several useful tutorials are: O'Reilly's/Jeelani Shaik's Learning EJB QL and IBM's audio tutorial on EJB QL.
Below is a checklist of steps that may be used to create a relationship between to cmp top-down EJBs.
Implementing Relationships
A checklist of key steps for specifying this follows:.
- Create the two EJBs that will participate in the relationship in the conventional (e.g., top-down) manner, but without any specified foreign keys; for example, Set and SetMember, in which there is a 1-to-n relationship between the two. Put both EJBs in the same EJB project, but with different package names. Do not map the EJBs to the database yet.
- Open the Deployment Descriptor for the EJB project and scroll down to the section labeled Relationship. Select Add.
- When the wizard opens, designate the n-EJB (e.g., SetMember) on the left and the 1-EJB (e.g., Set) on the right. Click next.
- In the left panel, you may accept set as the role but I prefer to rename it setRole to make it clear that this will be a generated cmr field. In this example, select Many for Mutiplicity, check Navigable, and Cascade delete.
- Follow a similar sequence for the right column, designating setmemberRole, Multiplicity One, and the CMR Field Type as Collection.
- When you Finish the wizard, save the Deployment Descriptor.
- Go back to the EJBs and look at their respective bean and local interface classes (e.g., SetBean and SetLocal). Note the methods inserted into them that provide navigation (e.g., getSetmemberRole()). Note, also, that these methods are defined on the Local interface, not the Remote interface. Consequently, you must access these EJBs through these interfaces using JNDI lookup, not a factory class.
- Next, you must map EJBs to the database, including the roles to actual keys (generated by WSAD). Select the EJB project, right click, and select Generate > EJB to RDB Mapping. Save the map.
- From the DataBase perspective, select the project, open the MATA-INF folder > backends > DB2UDBNT_V8_1.
- You may wish to edit the default mapping, such as changing VARCHAR lengths for the tables. You may do this by selecting the file corresponding to the particular table.
- Next, map the relationship by opening the Map.mapxmi file. Expand both EJBs and tables (e.g., Set and SetMember).
- Map the SetMember role (named SetRole) to the generated key opposite by selecting it and dragging it across. Save the table.
- Export to server, in the normal fashion. Verify that the mapping and export worked by looking directly at the tables in the database and noting the inclusion of a SETROLE_ID in the SetMember table.