EJB 2.0 containers can manage relationships between entity beans. In this example, each boarding school house has a number of students. Each house and student has its own entity bean and each student belongs to a house.
Resin-CMP generates the classes and SQL to maintain the relationships automatically. If a student changes houses, Resin-CMP updates both the student and house records. If a student is expelled, both the student and house records get update automatically.
Relationships are updated using the local interface. The second draft of the EJB 2.0 specification distinguishes local from remote interfaces. Local interfaces are useful when using EJB as a database interface or for fast calls within the same JVM.
The tutorial focuses on the classes and configuration for a simple bean/bean relationship. Additional details, like changing houses or creating and deleting students are deferred to another tutorial.
The example has two tables: houses and students. Each student belongs to a single house. It's an n-1 relation like a parent-children relationship.
The database stores the student/house relationship using an field in the student record. The student table points to the house with the house's primary key. The generated code will create the query to list all students belonging to a house.
The example client loops through the houses and prints each student from the house. The student beans are returned in a collection.
As in the previous tutorial, Resin-EJB stores the home interfaces in a JNDI context. The student home is stored in and the house home is stored at . The is used since these are the local interfaces for the beans.
The list of students is passed using the JDK 1.2
class and taking students out requires an
Since we are using the local interface, the collection is live.
The application could use
a new sutdent.
Both the house and students beans have the three EJB classes: local home interface, local interface, and implementation class. Although the client only sees the local home and local interfaces, most of the interesting work happens in the implementation class. With container managed persistence, most of the work is done automatically, so the classes themselves are short.
The home interface for the house bean implements the minimal method, findByPrimaryKey.
The remote interface returns the name of the house and the collection of students. does not return the container-managed student collection directly. The implementation must first store the managed collection into a concrete implementation.
collection is active. Calling the collection
methods will add and remove students from
the house. Adding a student to a house will automatically remove it from
any other house. Resin-EJB keeps the relationship consistent.
The house's student list gets contructed from the student
records. In the SQL schema, the houses table has no reference
to students. So
needs to query the student records to
find the students in a house. In other words,
The deployment descriptor connects the paired fields
. Resin-EJB can't determine the pairings of
by introspection alone. So you'll need to tell Resin-EJB in the
The student bean adds the
accessor to a basic bean.
Since getHouse is paired with the house's
setting a house will automatically change the house's student list to match.
The student interface returns the student's name and the remote
interface of the house. As always, beans never refer to the implementation
classes, always the local interface. The student interface must return
implementation is simple since all the real code is
With Resin-EJB, all the Java source can be dropped in WEB-INF/classes. Resin will automatically compile any changes and regenerate the persistence classes, stubs and skeletons.
References to the bean in the relationships section use the definition.
The house definition is just like the simple entity bean in the previous house tutorial. The main addition is the section. The definition needs to define the studentList field and can specify its return type.
The house definition is also like the simple entity bean in the previous house tutorial. The main addition is the section.
The relationship connects the field of the
to the field of the
. Although the XML looks a bit
forbidding, it's almost entirely boilerplate. You can cut and paste a
standard example, only filling in a few fields. In this example, there are
only four actual values, surrounded by the verbosity of XML.
The student houses example just touches the simplest example of using container managed relations. Even in this basic case, it's easy to see how the EJB 2.0 persistent model takes the drudgery out of accessing databases.
But more important than saving a bit of work, the EJB 2.0 persistence model makes code more flexible and less brittle. Projects can explore data models and refactor code without worrying that the refactoring will break years-old SQL.