Amber provides a Java model for a relational database, following the Java Persistence standard.
A typical project starts planning with the relational database schema and matching the Java model to that schema. This data-driven approach contrasts with a transparent persistent object approach which starts with Java classes and then tries to create storage to match the Java model, an approach more typical of object-oriented databases. While the transparent persistence model may be appropriate for some applications, the persistence specification wisely leaves transparent persistence to other products and specifications, and concentrates on the relational database model.
In a way, Amber simply provides an extension to SQL queries, returning fully-populated Java objects instead of just returning primitive values like Strings. That somewhat understates Amber's capabilities since the Java objects are live, updating the database in a object-oriented fashion, and also provides caching. Still, viewing Amber as a SQL extension supporting relations and objects is a good starting model.
The tutorial uses "entity" to mean a persistent object. Amber's entities are far simpler than the "EntityBean" of EJB 2.1.
The tutorial's design begins with its database model. The table is a collection of school courses, each with an assigned teacher. The table has an integer primary key "id" and two string data fields, "course" and "teacher".
To judge the complexity of Amber, it's useful to compare the Amber
Java model to the simplest possible Java model. The simple model
has a single class,
Course, for the table and three fields for the
The minimal class is missing any description of its intended use as a persistent object, information needed for maintainable code. In theory, a persistent object tool could use the minimal class automatically, but without more information, the source doesn't properly describe the class behavior. Fortunately, the JDK 1.5 metadata annotations can describe the persistence information in a maintainable, self-documenting way.
Of course, those annotations might have default values and should be overridable by an optional XML configuration file, but it's necessary to annotate the intended function of the entity in the Java source itself to properly document and validate the Java code.
To find and enhance a persistent Java bean, Amber follows the following procedure.
By the end of initialization time, Amber has enhanced CourseBean and made it available to the application in the persistence-unit "example".
A servlet will then lookup the CourseBean with the following procedure:
The minimal Java class needs the following annotations to produce a maintainable persistent object:
The following code shows the Amber annotations for the course entity. As a quick comparison with the minimal Java class shows, Amber is close to the simplest possible implementation of the Java model which provides the necessary annotations in the list.
The example uses the
teacher() methods to emphasize that the
field accesses to _course and _teacher are live, i.e. they
read and write the database values directly. (Under the covers, Amber
uses bytecode enhancement to make this work.)
Course uses the @Entity to mark the Java class as a field-based persistent object.
@javax.persistence.Entity declares a Java class as an entity bean.
Since the @Id annotation marks a field, the bean's fields are persistent, as in JDO. Unlike JDO, only the bean itself or its children may access the fields. Other classes must use the bean's methods, like getters or setters, to indirectly access the fields.
If the @Id annotation had marked a property method, the methods would be enhanced.
the SQL database table name to be used. If
unspecified, Amber will use the class name as the table name.
The @Id attribute marks the
bean's primary key. The
looks up a bean instance with the primary key, and relations use
the primary key to link beans together.
@GeneratedValue specifies automatic
generation of primary keys when beans are created. The default
AUTO generates primary keys depending on the database.
Postgres, for example, will use a SEQUENCE, while Resin's built-in
database will use an auto_increment IDENTITY.
The optional @Column annotation specifies the SQL column name. The default SQL column for an @Id is the property name.
The @Basic attribute marks a basic data column like a string or integer or double.
The optional @Column annotation specifies SQL column name. For a @Basic field, the default column name is the field name.
Amber processes the bean's class to implement field-enhancement. In practice, this means replacing setting a field with a Resin setter and getting a field with an Amber getter.
For example, Resin would process the above method and produce something like:
The client servlet queries the database for all courses and lists
them. It uses the
EntityManager API to create a
Query and uses the
Query to obtain the results.
EntityManager is the primary interface for
finding, querying, adding and deleting persistent beans. It is stored
in JNDI at java:comp/env/persistence/PersistenceContext/example.
The example uses dependency injection to configure the entity manager.
Query acts like a
JDBC. It saves a parsed SQL query and allows for parameters.
The SQL used for EJB 3.0 is an enhanced database SQL. The query can return objects directly ("SELECT o") and it can traverse relations ("o.next.data"). In most other respects, it can be thought of as regular SQL.
The query returns its values with
Queries which return a single value can
The Resin configuration is fairly straightforward. Resin needs to start the ejb-server, configure the JDBC data-source, and list the beans that will be used.
The <ejb-server> configures Amber support.
The persistence.xml lives in META-INF/persistence.xml. Since we're developing in WEB-INF/classes, the file will be in WEB-INF/classes/persistence.xml.