toring and retrieving information for most applications usually involves some form of interaction with a relational database. This has presented a fundamental problem for developers for quite some time since the design of relational data and object-oriented instances share very different relationship structures within their respective environments. Relational databases are structured in a tabular configuration and object-oriented instances are typically structured in a hierarchical manner. This "impedance mismatch" has led to the development of several different object-persistence technologies attempting to bridge the gap between the relational world and the object-oriented world. The Enterprise JavaBeans (EJB) framework provides is one such means of bridging this gap.
This article is the first in a series, which will discuss how three different object-persistence technologies (EJB, Java Data Objects, and Hibernate) attempt to simplify the chore of connecting relational databases and the Java programming language.
The task of persisting Java objects to a relational database is currently being facilitated by a number of different tools that allow developers to direct persistence engines in converting Java objects to database columns/records and back. This task involves serializing hierarchically structured Java objects to a tabular-structured database and vice versa. Essential to this effort is the need to map Java objects to database columns and records in a manner optimized for speed and efficiency.
The Enterprise JavaBeans (EJB) framework provides a mechanism for object persistence. I will discuss this mechanism in this article, but first I'll take a brief look at the overall architecture of EJB.
EJB technology can be defined as a Java-based, server-side, reusable component framework for distributed applications. This framework facilitates centrally managed business logic, declarative deployment, and object persistence. Some of the characteristics of the EJB framework are as follows:
- EJBs are Java objects executed within a server environment.
- EJBs can be distributed across many machines and accessed remotely as if they were on a local machine.
- EJBs are centrally managed by a container.
Central to the EJB specification and architecture is an artifact known as an Enterprise Java Bean (which, like the framework, is often given the acronym EJB). Even though the names from the EJB framework are very similar to the names from the JavaBeans framework, the specifications and designs of each framework are very different.
The EJB and JavaBeans specification names and component names are very similar, but this is where the similarities end. The JavaBeans specification and component model and the Enterprise JavaBeans and component model have very little in common. To illustrate this, I'll look at the EJB concepts, components, and environment in detail.