or DB2, Oracle, Sybase, dBase, and Access. Object People has also built custom back ends for mainframe systems.
The linchpin of the TopLink system is a
descriptor
, which is a data structure that serves to map the details of the object structure (and object relationships) to the relational database. In other words, a descriptor tells the TopLink system how an object's data is to be stored in the relational database.
A descriptor includes the name of the Java class it describes, as well as the associated tables that the Java class will be mapped to (e.g., the table in the database where objects of the class will be stored). Information in a descriptor describes the attributes and object-object relationships that exist for objects in the class. Necessarily, a descriptor must
also carry information describing the structure of the table. This information includes the primary key of all records in the table, the field names, and so on.
A descriptor holds other information that's necessary for successful storage and retrieval of database objects. For example, the Java object may contain a data type that is not supported in the relational database. A descriptor contains information necessary to transform data of one type to the other.
A descriptor's information is actually stored in a file. The application imports this file prior to the application's accessing the database. As you might guess, building a descriptor is a complex undertaking, because it involves assigning classes to tables, attributes to fields, application data types to database data types, and more.
To help in this task, TopLink provides the Builder tool. The Builder reads in the database schema (via JDBC) and the class structure (Builder reads Java class files directly). With the schema and class structur
e fed into the Builder, you then have a visual view into both the database and the application's classes (
see the screen
). Using the Builder's Descriptor Editor, you can easily go through the process of mapping attributes to table columns. The Builder will construct a descriptor for you automatically and emit a file ready for import into the application.
At run time, a descriptor is imported into a session object (TopLink defines a session class). A session object is an abstraction of an application's access to a database. The session object includes connection information (e.g., log-in name and password). Once an application has registered a descriptor with a session object, the application can begin reading and writing objects from and to the database.
TopLink builds into an application an object cache -- called an identity map. When an object is read from the database, it's placed in the cache. At a later time, if the application requests the object again, TopLink can read the
object from the cache rather than from the database.
This cache is a customizable one. That is, the developer can control how long objects live in the cache and thereby control the memory footprint that the cache consumes.
I couldn't help noticing a one-page "design strategy" in the TopLink documentation. The question it tackled was this: As you begin designing an object-relational database system, which part do you design first: the object structure or the relational database schema?
On the one hand, tackling the object structure first appears advisable. It's certainly the tack I would take, because it would permit me to construct what I would consider to be an optimal object structure. Optimal, in this case, refers to how easy it would be to program and does not necessarily refer to performance.
Furthermore, it does
seem
to be best to design the object structures with no regard for artifacts from the relational database system underneath. Designing your structure with the relationa
l database in mind would mean adding features that don't really benefit the application. You're just adding them to make the relational database happy.
However, the documentation points out that the object structure and the underlying database schema are intertwined -- the structure of one influences the structure of the other. Also, the relational database imposes restrictions on the object model "above." Keeping these limitations in mind while the object structure is being built can keep you from painting yourself into a corner.
Still, this raises the "impedance mismatch" question. That the relational database need be considered at all is something that likely causes cheering in the camps of purveyors of pure object databases. They can rightly point out that -- their systems being object-based through and through -- they needn't worry about the underlying characteristics of a relational system adversely affecting the objects above. However, the fact is that many organizations have vital corporate
data stored in legacy relational databases.
TopLink also contains the classes necessary to create three-tiered applications. For example, TopLink defines ServerSession and ClientSession session subclasses. The former lets an application construct the server side of a session with a database (the server being the middle layer of the three-tiered application); the latter handles the client side.
ServerSession objects are session managers to the client tier. ClientSession objects give the application the "appearance" of being a "typical" (i.e., two-tiered) application.
Compared to other object-relational systems I've tried, I liked the visual approach taken by TopLink's Builder. It makes a difficult process of mapping objects to tables relatively easy.
Product Information
The Object People
Ottawa, Ontario, Canada
Phone: 919-852-2200
Fax: 919-852-1032
Internet:
http://www.objectpeople.com
TopLink Bridges Two Worlds
