TOPLink for BEA Weblogic – Object Relational Mapping Tool |
Author: Bill EnnisTOPLink provides container-managed persistence for BEA Weblogic. It has been available for Weblogic's application server since Weblogic version 4.5.1 released in December, 1999. TOPLink can also be used in a pure java environment to access most JDBC enabled relational databases; i.e. you can use it to communicate between java classes not deployed to an application server and a relational database. TOPLink includes the following features:
Feature
Description
Object Oriented API for object storage
Programmers use methods readObject() and writeObject() to interact with the database. TOPLink translates into the necessary SQL to carry out the operations that may require to several underlying database tables.
Manage complex relationships between objects
Supports 1-1, 1-many, and many to many relationships between objects
Indirection
Indirection defers database access required by dependent objects. For example, the phone information for an Employee object.
Optimistic Locking
Allows for greater system concurrency since database locks are held only as needed.
Object Query API
Programmers construct Expression objects. TOPLink translates these into the necessary SQL.
Client/middle tier object cache
Objects are cached to reduce database access
Support for inheritance
Classes using inheritance may be “mapped”
Performance features
Includes batched writing, table-joined reading, advanced cursor structures
Type conversion
Automatic conversion of java to SQL data types
Multiple database support
If JDBC driver is supplied TOPLink can support the underlying database
Container managed persistence for WebLogic and WebSphere Application Servers
Works as a container in an EJB environment as a substitute for the vendors own Container for persistence.
Table 1: TOPLink features
A brief Definition of Object-Relational MappingThe basic problem that any O/R mapping tool attempts to solve what is known as the impedance mismatch between an object model and a database schema. Object models often use relationships between objects that introduce a hierarchy. These relationships introduce complexity when interacting with a relational database since the construction and storage of an object will then be accomplished by interacting with several database tables, rows, and columns. A simple example would be an object that represents a person who in turn can have multiple phone numbers. This would typically be represented in an object model as a person object containing a collection of phone objects (see Figure 1). In a data model would be a person table, a phone table, and a foreign key relationship between those tables. Whenever you construct a person you would need to gather the information from the tables and set the appropriate attributes in the person class. This would be accomplished via either a database join or a series of database accesses with accompanying code to read the data into program variables and move to the appropriate object attributes. Object Relational Mapping Tools/libraries encapsulate the details of how a database schema is translated into an object model and also provide the data access layer. Because of this you are dealing with normal java objects within your code with object oriented method calls such as readObject() and writeObject() when you wish to persist or instantiate an object graph. In addition each time you create a new query (i.e. a unique where clause) you usually need to add some code to perform this new operation. With an O/R mapping tool there is still some work to add new queries, but this work is isolated to the definition of the new query and does not include the cursor manipulation processing to gather the information (which is sometime a substantial amount of code). See figure 2 for come some source code related to reading and writing objects with TOPLink. If you use TOPLink for container-managed persistence within an application server you can avoid having to even write access logic. TOPLink implements the ejbLoad and ejbStore methods that correspond to reading and writing objects. Figure 1: Person Object representation vs. Relational Database representation
package TOPLink.Tutorials.Benchmark; Figure 2: Sample code using TOPLink to write and read objects Some other advantages of defining a persistence layer is that it allows a uniform representation of the data model to the application, and a client side object cache. When an application creates multiple access points to the same data element it becomes difficult to maintain when database schema changes are introduced. This is because the change must be propagated across all access points that are affected by the change. Client side object caches improve performance since they can reduce database accesses. One must keep in mind that this layer exists however whenever dealing with the database directly. For example, you may perform a direct SQL update on a table without the persistence layer. Since the data access layer does not know about this update it may not reflect the update in its cache (unless refreshed). Personal history with O/R Mapping ToolsIn June of 1998 I was asked to evaluate Object Oriented Databases. My early findings were encouraging. The OO database is was experimenting with seemed to have most of the operational functionality of many of the mature relational databases being used. It was at this point I was handed the task to kick the tires. The first thing I did was write a simple java application to load data into my database. I was impressed with the java database interface in it simplicity to use and was able to quickly load 1GB of data. Then it was time for some operational tests involving backup/recovery and replication. This is where the product came up short. The database core dumped during backups – maybe they never tested on a 1GB database? Creating a replica of my database never seemed to end. After stripping the database down to 50 MB I was able to create a replica in 27 hours! I didn’t need to look any further to see that Object Oriented databases were not ready for prime time. Therefore the focus was put on Object Relational Mapping technologies, since we would be using java and a relational backend (Oracle and Sybase were the preferred vendors at the site I was working at). We evaluated several including several application servers that included O/R mapping technology. We found that those products that focused solely on object-relational mapping always had the best feature set. TOPLink was selected as the technology based on the examination of its feature set and ease of use/speed in getting something up and running. Since O/R mapping is a desired feature in a java application server ObjectPeople (the makers of TOPLink) have started to provide container-managed persistence for some of the major application server vendors (the first being BEA Weblogic). Weblogic includes basic O/R mapping functionality, but it is limited with regards to relationships between objects, cache configurability, defining queries, and tools to support modeling of the mapping. Case Study – workzone360.comWorkzone360.com is using an EJB (Enterprise Java Bean version 1.1) based architecture. The application server used is Weblogic version 5.1. The architecture allowed us to take advantage of container-managed persistence. Therefore TOPLink was an immediate candidate. Since we had some experience on the team with it and it could potentially save significant time we decided on TOPLink. InstallationThe installation of TOPLink is not automatic. There are some subtle things that you need to be aware of. There is a jar file that comes with the software that must be copied to the weblogic directory hierarchy. This jar file (TOPLink_CMP.jar) needs to be in your $WEBLOGIC_DIR/lib/persistence directory. The install attempts to put this in there for you but isn’t always successful do to several possible scenarios. In addition, you must modify CLASSPATH’s to include the other TOPLink jar files. The TOPLink manuals actually cover the classpath information is adequate detail. However, those accustomed to NT based installs are not used to having to make these types of changes after an install. TOPLink licensing is developer based (no runtime fees apply). License keys need to be entered into your weblogic.properties file with the property Java.system.property.toplink.license=’<YOUR_TOPLINK_KEY_HERE>’ Figure 3: weblogic.properties file addition for TOPLink license key You also need to enable access for java reflection on our classes from within the weblogic policy file.
Grant { Figure 4: weblogic.policy file entries added The TOPLink Project file and related filesThe TOPLink Builder organizes the files it creates/edits with the use of a project file. The project file is the table of contents for a series of files that are used by the TOPLink Builder and eventually by the TOPLink container when your Entity Beans get deployed. Each Entity Bean class will have a file that describes the class (ending in .topclass). Each database table involved in a mapping will also have a designated file (ending in .table). And the mappings between classes and tables are stores in another file (ending in .descriptor). TOPLink often refers to a mapping as a descriptor. A descriptor contains information about a class attribute and what database table column that it maps to. TOPLink also supports generation of the mappings into java class files for production deployments. It is also possible to use TOPLink to map regular java objects that are not Entity Beans. These are usually dependent objects that you do not believe need the functionality (and excess baggage) of an Entity bean. EJB XML Deployment filesIn workzone360 we decided to deploy all beans in a common jar file. Each EJB deployment requires a set of XML files that define container dependent behavior for those beans. EJB 1.1 requires XML deployment descriptor files. Both Weblogic and TOPLink supply dtd’s for the respective xml deployment files. These files include:
Project OutcomeWe were able to achieve significant success with TOPLink on the workzone360 project. We did not have a need to create any SQL due to limitations in TOPLink. The realization of the power of the tool came when we needed to define a new finder for TOPLink mapped beans. Finders are EJB lookup methods, they allow an EJB client to pass in search parameters. Normally, we would have had to create a new interface for the finder and also the underlying data access code to create the query, fetch the data, and construct a data structure to send back to the client. All that was required with our application was to define a new finder (in the TOPLink deployment descriptor file); we did not even have to write code. Below is a cutout of the finder declaration that was required to retrieve all business objects that match a partial business name:
<finder> We added many finders after mapping our objects and were able to implement data access in a very productive manner. Some TIPS worth mentioning
Some Quick Notes on Entity Bean Development with Weblogic & TOPLink
note: If you ever modify the class you need to consider reverse engineering it into TOPLink. This comes into play if a getter or setter ever goes to call an internal method of your code. What does it cost?TOPLink only sells development licenses (no runtimes apply). You pay by the number of seats. Whoever is developing EJB’s on your project should be licensed. TOPLink also has a java only project that is licensed the same way. The cost is in the area of $5000 and discounts start applying at 10 seats on up. Summary and conclusionThe goal of this paper was to introduce TOPLink as a possible alternative as a persistence layer for java and for BEA Weblogic Enterprise Java Beans. It has also defined the Object Relational impedance problem and discussed some of the work that has been done in this area. More information on TOPLink can be found at http//:www.objectpeople.com. More Information on Weblogic can be found at http://www.beasys.com. Both site maintain a variety of newsgroups with many competent developers offering good advice. TOPLink also can be used in a non-EJB java environment for persisting objects to a relational database. |