Building an entity EJB across federated data

Brief introduction

It is not uncommon for entity Enterprise javabeans™ (EJB) developers to find themselves facing the challenge of data modeling issues. Because entity EJBS typically represent data managed by relational DBMS, programmers often have to decide how to map existing data in a table to a new server-side Java™ object that is required to support WEB applications. Although many development tools can help programmers build a single entity EJB mapped to a single table, but it's hard to find tools that can help programmers create entity EJBs, and the entity EJB maps to data that is not relational or is managed by multiple data sources (which may have both relational and non relational data sources).

In this article, we'll look at how the ibm®db2® Federated database Management System (DBMS) can help EJB programmers solve these problems. The technology provides programmers with a single site image of a completely different data, presenting a virtual database that masks the differences in the application programming interfaces (APIs) required by remote data sources. This is one of the characteristics of the federated DBMS, which enables EJB programmers to use all the different data in a transparent and efficient manner.

The previous article describes the federated DBMS Concepts and describes how they can complement the Web application server environment with all the different data in the Web application. Another article building a Web component that accesses federated data studies the design requirements for building session EJBS and Web services that use federated data. In this article, we'll look at a further use of federated DBMS Technology: As a basis for creating entity beans with container-managed persistence (container-managed persistence (CMP)). Before we delve into the technical details, however, it is important to understand the circumstances in which federated database technology might benefit the entity EJB programmer.

What are the benefits?

CMP entity beans represent a fairly sophisticated use of the DB2 federated database Technology, because the code accessed by the database-the code that implements persistence-is automatically generated when the EJB is deployed. Instead, programmers who build session EJBS that access persistent data have to write their own JDBC statements to establish a database connection and emit SQL statements.

In the following sections, we will discuss how to build various CMP entity beans that use federated DBMS technology. IBM's Websphere®studio Application Developer integrated version (Wsadie) will serve as our Java development platform. However, it is important to understand under what circumstances the use of DB2 Federated technology will benefit entity bean programmers. Combined technology can:

Extends the scope of the data source represented by the EJB. Although popular Java programming tools such as IBM's wsadie-provide native support for a variety of data sources, DB2 's federated technology provides out-of-the-box access to some other data sources, including non relational data sources. In addition, DB2 programmers can build wrappers if needed so that DB2 can access any data sources they want to access, including "old" DBMS, file system, prototype software, and so on.

Automates the development and deployment of CMP entity beans that support many common DBMS, without requiring that the client software for these DBMS be installed on a platform running Wsadie or IBM WebSphere application server.

Supports automated development and deployment of a single CMP entity bean, which maps properties of the entity bean to data from multiple data sources. In this scenario, you create a DB2 view that connects or merges data from multiple data servers. Because the view update problem is common to any relational DBMS, such CMP entity beans are developed as read-only.

Entity EJB Overview

EJB is a server-side software component that adheres to certain programming specifications. An entity EJB represents persistent data that is typically stored in a relational DBMS. Developers can manage their own persistent aspects of beans (through bean-managed persistence, or BMP), but most people choose to delegate this responsibility to the container (through container-managed persistence, or, for short, CMP). This article focuses on CMP entity beans.

The EJB specification develops some coding requirements for developers. These requirements will vary slightly depending on the level of EJB specification that you want to support. For this article, we will focus on EJB 1.1, which is the level of support for WebSphere application Server version 4 (our target deployment platform). At deployment time, each CMP entity bean has several code modules, including:

The home interface, which defines the client methods that create, find, and drop bean instances.

Remote interface, which defines the business methods associated with the bean. "Getters" and "setters" are commonly used to get and set individual properties of the bean.

The Bean class that contains the business logic method encoded by the EJB developer and the EJB lifecycle method that is used by the container. Instead of directly accessing the object of this class, the EJB client uses the services of this class indirectly using the class generated by the container (implementing the Home and Remote interfaces).

A primary key class that identifies a property (or set of properties) that uniquely identifies each instance of the bean, and provides methods for creating and manipulating keys.

After the EJB has been developed, the programmer must set up a deployment descriptor that manages the characteristics of the bean, such as its transaction isolation level. Finally, you must package this bean and deploy it in the EJB server. The deployment process results in additional classes, including those associated with the previously described home and remote interfaces. A suitable Java development environment, such as Wsadie, can be a great help in developing, deploying, and testing ejbs.