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.
