Enterprise beans in a federated system

Programmers can use enterprise beans and federated system objects to perform database operations or transactional work and access data that spans multiple heterogeneous sources. Federated systems support automated development and deployment of a single container-managed persistence entity bean whose attributes map to data from multiple resources.

Enterprise beans are Java™ components that run on a Web server. You can create container-managed persistence entity beans and map them to nicknames that you create with federated systems. Federated objects such as wrappers, nicknames, and views extend the usefulness of entity beans to integrate disparate data through Enterprise JavaBean architecture.

The container-managed persistence entity bean can access data that is located in relational databases. The read-only container-managed persistence entity bean can access data that is located in nonrelational databases.

Enterprise JavaBean architecture

Enterprise bean components are part of the Enterprise JavaBean architecture. An enterprise bean implements business logic. For example, the relational and nonrelational tables in Figure 1 describe a customer order scheduling system that is implemented by entity beans. The enterprise bean components run in an enterprise JavaBean container. The container runs on an enterprise JavaBean server. The enterprise JavaBean container provides services such as transaction and resource management, persistence, and security to the enterprise bean components. The enterprise JavaBean container controls the details of database manipulation, such as managing access to a target data source.
Figure 1. Container-managed entity beans mapped to federated objects
Container-managed persistence entity beans that are mapped to federated objects. The instances of the beans can correlate to rows in the tables.

Entity beans and session beans

Two types of enterprise beans are used in a federated system:
Session beans
Usually associated with a single client and is usually not persistent. The session bean acts as a single client that performs some actions on the server. The session bean does not represent or update existing database contents.
Entity beans
Represents information that is stored persistently in a database. Entity beans are associated with database transactions. Entity beans can provide data access to multiple users. An entity bean might represent an underlying database row or the result of a SELECT statement in a single row.
Figure 1 shows four container-managed persistence entity beans that map to federated database objects:
  • Customer is a Db2® table.
  • Orders is an Oracle table that is accessed with the nickname Orders.
  • Order_date is an XML flat file that is accessed with the nickname Order_date.
  • Cust_Order_View is a view that is created by joining the Customer table, the Orders table, and the Order_date table.

The federated server translates the database access to data access requests that are appropriate to the data sources. When you deploy an enterprise bean, the bean resides in containers that provide services such as support for persistence. The entity bean automatically generates the code that implements persistence when you deploy the enterprise bean. By contrast, when you build session enterprise beans that access persistent data, you must write your own Java database connectivity statements to establish database connections and issue SQL statements.

A container-managed persistence entity bean defers all interaction with the database to the enterprise JavaBean container. Typically, the enterprise bean reads the data from the database and places the data into the fields in the container-managed persistence entity bean. You can reference or update (when the data is part of a relational database) the data in the entity bean. When a transaction ends, the Enterprise JavaBean container accesses the data in the entity bean and updates the underlying row in the relational table.