One of the more complicated issues that J2EE application developers face is the process of mapping relational data to EJBs. The J2EE specification provides EJBs as the mechanism to persist objects into a database. They certainly solve lots of problems for developers, especially in the areas of transaction management and distributed computing.

EJBs come in two basic flavors: session and entity beans. Conceptually speaking, session beans are simpler to understand as they map fairly easily to logical business transactions. Entity beans provide the glue that allows a session bean to interact with the relational database tables that manage the actual data. Database tables are relational and entity beans are objects; combining these two technologies may look simple - but it's a complex process under the covers.

Fundamentally speaking, working with entity beans and a relational database is an exercise in data mapping. RDBMS engines such as Oracle store data in tables and columns. Thus customer data is stored in a "customer" table and information relevant to the customer is stored in columns. All the data for a single customer within the customer table is equivalent to a "record." From the EJB perspective, customer data is represented by a customer "class" and the data elements are represented by "attributes." Conceptually, the mapping process is a simple one. Each database table is an EJB class and each and every column in the table becomes an attribute. Individual customer records are instantiated as EJB objects as necessary. Although it sounds simple, it can be complex to implement this type of mapping.

Entity beans come in two flavors, bean-managed persistence (BMP) and component-managed persistence (CMP). If you have connected EJBs to your database, you're probably familiar with BMP entity beans. With them you connect your EJB object with a JDBC driver that works with your target database. You're responsible for writing all the SQL code so you're able to optimize your application for the target database. Many first-generation EJB applications were constructed this way. The downside to this approach is twofold. First, you're locked into a single database vendor and the process of porting between databases can be a complex task. I'd argue that the second issue, productivity, is the more serious problem. Handcrafting SQL statements for a database is a huge loss in productivity. All the leading relational databases have high-speed optimizers and fast transaction processing engines. Ideally, then, EJB developers should be able to reverse-engineer preexisting relational databases and generate the persistence layer automatically.

A solution to this problem comes in the form of dynamic data mapping. A number of third-party vendors offer highly sophisticated data mapping tools for many of the popular J2EE application servers. One company garnering a lot of press and attention in this market is San Francisco-based THOUGHT, Inc. The developers at THOUGHT, Inc., have built an enterprise-class object-to-relational mapping product called CocoBase. CocoBase is packaged as an administration utility and a code-generation layer that works with most of the leading application server engines.

CocoBase plugs into your favorite database via JDBC drivers. Once you've connected to your database, CocoBase creates both BMP and CMP beans for your relational database tables.

You're free to map multiple objects to a single database table and/or map multiple tables to a single object. For example, you might create different EJB objects to represent "good customers" and "bad customers." CocoBase generates a mapping file so you can change the mapping layer without having to modify the code or recompile the application. Developers are then free to concentrate on the business logic instead of wasting valuable programming time writing endless SQL statements. CocoBase uses a three-step process for building EJBS:

1. Using the CocoAdmin GUI tool, the developer connects to the database and visually maps tables to objects (and vice versa).
2. CocoAdmin generates CMP/BMP bean code for each object for the specified J2EE application server.
3. EJBs are loaded into your EJB server and are ready to use.

Since the developers at THOUGHT, Inc., concentrate all their attention on the persistence layer, they're able to optimize the performance of this portion of the application. As an individual application developer you may not have the time or resources to build optimizations in your persistence layer. CocoBase generates some sophisticated performance optimizations directly into the EJB code that's generated. For example, it uses a data caching mechanism to reduce the number of interactions between the application layer and the database. It adds this performance improvement at the application server level without significantly impacting the performance of the database itself.

It's important to keep in mind that the J2EE specification provides a road map for development, not the implementation details. Application server vendors offering products in the J2EE space will find it more difficult to incorporate best-of-breed technologies inside their server suites as the J2EE specification expands. This provides an excellent opportunity for vendors such as THOUGHT, Inc., to provide optimized solutions for specific parts of the J2EE specification. As both the specification and the vendor implementations mature, we'll begin to see the benefits of this type of plug-and-play at the application server layer. After all, this is exactly what Sun would have us believe J2EE is all about - true interoperability.

Summary
Object-to-relational mapping is a complex process and may prove to be one of the single biggest hurdles that must be overcome when building an enterprise-class EJB-based system. Sophisticated mapping tools such as CocoBase are worth considering as a solution for this problem. I'd encourage you to place O/R mapping solutions on your short list of technologies for speeding up J2EE development within your organization.