简介
实体 Enterprise JavaBeans™（EJB）开发人员发现自己面临数据建模问题的挑战，这并不稀奇。因为实体 EJB 通常代表由关系 DBMS 管理的数据，所以程序员们常常必须决定：如何将表中现有的数据映射到支持 Web 应用程序所需的新的服务器端 Java™ 对象。尽管许多开发工具可以帮助程序员构建映射到单个表的单个实体 EJB，但很难找到有以下能力的工具：能帮助程序员创建实体 EJB，且该实体 EJB 映射到非关系数据或由多个数据源（可能既有关系数据源，也有非关系数据源）管理的数据。
在本文中，我们将研究 IBM® DB2® 联合数据库管理系统（DBMS）是如何帮助 EJB 程序员解决这些问题的。该技术为程序员提供了全异数据的单站点映象，呈现了一个虚拟数据库，这个虚拟数据库掩盖了远程数据源所需的应用程序编程接口（API）中的差别。这是联合 DBMS的特征之一，它使 EJB 程序员能以透明和高效的方式使用全异数据。
前一篇文章 处理 Web 应用程序中的全异数据介绍了联合 DBMS 概念并对它们如何能补充 Web 应用程序服务器环境做了说明。另一篇文章 构建访问联合数据的Web 组件研究了构建使用联合数据的会话 EJB 和 Web 服务的设计需求。在本文中，我们将研究联合 DBMS 技术更进一步的用法：作为创建带有容器管理的持久性（container-managed persistence (CMP)）的实体 bean的基础。但在我们深入研究技术细节之前，理解联合数据库技术在什么情况下可能有益于实体 EJB 程序员是很重要的。
益处何在？
CMP 实体 bean 代表着 DB2 联合数据库技术的一种相当完善的用法，因为数据库访问的代码 — 也就是实现持久性的代码 — 是在部署 EJB 时自动生成的。相反，构建访问持久数据的会话 EJB的程序员，要编写自己的JDBC 语句才能建立数据库连接以及发出 SQL 语句。
在随后的几节中，我们将讨论如何构建使用联合 DBMS 技术的各种 CMP 实体 bean。IBM的WebSphere® Studio Application Developer 集成版（WSADIE）将作为我们的Java开发平台。但是，首先要理解在什么情况下使用 DB2 联合技术会对实体 bean 程序员有好处，这很重要。联合技术可以：
扩展 EJB 所表示的数据源的范围。尽管流行的Java 编程工具 — 如 IBM的WSADIE — 提供对多种数据源的本机支持，但 DB2的联合技术提供了对一些其它数据源（包括非关系数据源）的现成的访问能力。此外，如果需要，DB2 程序员还可以构建封装器，以便使 DB2 能访问任何想访问的数据源，其中包括“旧的”DBMS、文件系统、原型软件等。
支持许多常用 DBMS的CMP 实体 bean的自动化开发和部署，而 不要求这些 DBMS的客户机软件安装在运行 WSADIE 或 IBM WebSphere Application Server的平台上。
支持单个 CMP 实体 bean的自动化开发和部署，该实体 bean的属性映射到来自多个数据源的数据。在这种方案中，会创建一个 DB2 视图，它连接或合并来自多个数据服务器的数据。因为“视图更新”问题对任何关系 DBMS 都很常见，所以这样的CMP 实体 bean 都被开发成“只读”的。
实体 EJB 概述
EJB 是遵守某些编程规范的服务器端软件组件。实体 EJB 代表了通常存储在关系 DBMS 中的持久数据。开发人员可以自己管理他们 bean的持久方面（通过 bean 管理的持久性，或简称 BMP），但大多数人选择将这一职责委托给容器（通过 容器管理的持久性，或简称 CMP）。本文着重讨论 CMP 实体 bean。
EJB 规范对开发人员制定了某些编码需求。这些需求会稍有不同，取决于您希望支持的EJB 规范级别。对于本文，我们将着重关注 EJB 1.1，它是 WebSphere Application Server 版本 4（我们的目标部署平台）支持的级别。在部署时，每个 CMP 实体 bean 都有几个代码模块，包括：
home 接口，定义创建、查找和除去 bean 实例的客户机方法。
remote 接口，定义与 bean 关联的业务方法。“getters”和 “setters”常用来获取和设置 bean的各个属性。
bean 类，包含由 EJB开发人员编码的业务逻辑方法和由容器使用的EJB 生命周期方法。EJB 客户机不直接访问这个类的对象，而是用容器生成的类（实现了 home 和 remote 接口）间接使用这个类的服务。
主键类，对能唯一标识该 bean的每个实例的属性（或属性集）进行标识，并提供创建和操作键的方法。
开发了 EJB 后，程序员必须设置管理 bean的特征（如其事务隔离级别）的部署描述符。最后，必须将这个 bean 打包并部署在 EJB 服务器中。部署过程会导致产生附加的类，其中包括那些与前面描述的home和 remote接口相关联的类。一个合适的Java开发环境（如 WSADIE）在开发、部署和测试 EJB 时会有很大的帮助。
设置软件环境
在构建访问联合数据的Java 组件之前，必须配置 DBMS 客户机和服务器环境。前一篇文章描述了如何配置 DB2 V7.2 客户机以连接 DB2 版本 8 联合 DBMS，后者本身已被设置成可访问远程 Oracle、Sybase 和 Microsoft® SQL Server DBMS 上的数据。我们将不在这里重复所有的详细信息；而仅仅对总体任务进行概括以便您能回想起来。要了解更多信息，请参阅前一篇文章或查询 DB2 产品手册。
要开始进行设置，必须启用 DB2 客户机和服务器平台之间的基本连接（除非客户机和服务器软件安装在同一台机器上）。我们使用 TCP/IP 进行通信，并向每个系统上的services 文件添加一些项来指定我们使用的服务名和端口号。
启用连接后，我们设置了联合 DBMS 服务器。其步骤包括：
在 UNIX® 或 Windows® 平台上安装 DB2 版本 8 服务器实例。
更新数据库管理器配置特性 SVCENAME 和 FEDERATED。
创建一个 DB2 数据库（在我们的环境中是 rdjdb ）以管理联合访问。
安装我们的目标数据源所需的任何必备软件，并配置对这些数据源所驻留的系统的网络访问。
为每个我们希望访问的数据源创建封装器、服务器和用户映射对象。
按要求创建远程数据对象（如一个远程 Oracle 表）的别名，并根据这些别名创建视图。
为了确保一切都如预期正常工作，需要在本地对服务器配置进行测试，测试之后，我们配置了客户机平台。其步骤包括：
安装 DB2 客户机软件。
指定有关我们的联合数据库驻留的远程节点的信息。
指定该远程联合数据库的逻辑数据库名称。在我们的环境中，使用了 djdb 作为远程 rdjdb数据库的本地数据库名称。
为了简化 Java 组件的开发和测试工作，我们在客户机上也安装了一个 Java 集成开发环境 — IBM的WSADIE 4.1。随 WSADIE 一起安装的还有 WAS 4.0.2的一个嵌入式副本，它使部署和测试实体 EJB 变得简单。设置 WSADIE 以使用联合数据库的步骤包括：
将 db2java.zip 文件添加到 EJB 和 Web 项目的Java 构建路径。
创建与联合数据库对应的WebSphere DataSource 对象。我们指定 Java Naming Directory Interface (JNDI)的名称为 jdbc/Federated ，其 JDBC URL 为 jdbc:db2:djdb。我们还将用户标识和密码设置成适当的值（分别为 user1 和 pass1word ）。
使用实体 bean 和联合数据
在本文接下来的几节中，我们将循序渐进地指导创建各种 CMP 实体 bean，它们通过 WSADIE 来使用联合数据。这几节适合已熟悉 WSADIE 基本知识的程序员阅读。如果您不知道如何执行某一给定的步骤 — 例如如何创建 EJB 项目或如何在 WebSphere 测试环境中部署 EJB — 请参考产品的联机文档或访问 WebSphere开发者园地 http://www.ibm.com/webspere/developer，并遵循他们的一些产品教程。
为现有的别名创建 CMP 实体 bean
正如我们在以前的文章中提到的， 别名代表了 DB2的远程数据。对于已用 DB2 联合技术创建的别名，EJB 程序员可以使用 WSADIE 创建 CMP 实体 bean 来映射到这些别名。在我们的测试环境中，我们创建了各个实体 bean，分别映射到与各个 Oracle、Sybase 和 Microsoft SQL Server 表关联的别名。当然，DB2 联合技术支持对其它数据源的访问（包括非关系数据源）；对于来自其它数据源的数据，创建映射到代表该数据别名的CMP 实体 bean，过程是相同的。然而，如果 DB2 对某一给定的数据源施加了任何数据访问限制，那么您可能需要做些额外的工作。例如，DB2 支持对某些数据源的只读访问。如果对涉及这些数据源的别名构建 CMP 实体 bean，那么应该修改 bean 代码以避免写尝试。在后面的一节中，当我们讨论如何构建映射到一个视图（该视图连接或合并来自多个数据源的数据）的CMP 实体 bean 时，我们将知道如何做到这一点。这样的视图本质上是只读的。
在 WSADIE 4.1 中，自顶向下建模是支持使用联合数据开发 CMP 实体 bean的唯一方法。尽管用自顶向下建模工具来使用现有数据可能显得违反直觉，但它实际上是一个能取得预期结果的简单方法：为别名生成一个有效的CMP 实体 bean。
开发这样的CMP 实体 bean 要遵循以下步骤：
切换至 Java 2 Enterprise Edition (J2EE) 透视图。如有必要，可以按照 WSADIE的标准过程为您的实体 bean 创建一个 EJB 项目。
按照标准过程创建 CMP 实体 EJB。
将 bean 命名为与别名相同的名字。
添加对应于别名中各列的属性，要注意为每个属性指定适当的数据类型，并且要将适当的属性指定为键字段（它应映射到别名的主键列）。再次提醒，属性名应与列名对应。
调用 EJB 数据建模向导并选择自顶向下建模。
突出显示您的EJB，在其上单击鼠标右键，然后选择 Open With -> Mapping Editor。选择 top-down modeling。
单击 Next，确保数据库名与模式名设置正确。数据库名应映射到 DB2 客户机知道的联合数据库（在我们的环境中，它是 djdb ）。模式名应映射到已授权的联合数据库用户（在我们的环境中，它是 user1 ）。
取消选择 Generate DDL框，然后单击 Finish。
验证 EJB 到数据库的映射是否成功完成
突出显示您的EJB，在其上单击鼠标右键，然后选择 Open With -> Mapping Editor。
检查 Tasks 面板以确保没有出现过错误报告。
将 EJB 绑定到先前为联合数据库创建的适当的数据源。
突出显示您的EJB，在其上单击鼠标右键，然后选择 EJB Quick Links -> Bind Data Source。
在面板的Datasource 区域输入有效的JNDI 名、用户名和密码。例如，在我们的测试环境中，我们输入 jdbc/Federated 作为 JNDI 名，输入 user1 作为用户名，以及输入 pass1word 作为密码。
保存您的更改（ Control-S），然后关闭编辑器。
照常为 bean 生成部署代码（突出显示您的EJB，在其上单击鼠标右键，然后选择 Generate Deploy Code）。
为新的别名创建 CMP 实体 bean
对于您希望表示成 CMP 实体 bean的数据，如果它的别名不存在，仍可以使用 WSADIE 来构建和部署您的bean。其过程与 前一节描述的过程几乎相同。您仍将使用 WSADIE的EJB开发向导的自顶向下建模支持来对您的bean 建模。然而，在实际试图使用 bean 以前，您需要为远程数据创建一个 DB2 别名。如果还没有为远程数据源创建必需的数据对象或表，那么还需要预先创建它。可以遵循 DB2 手册中的指示，手工执行这些任务。或者使用由 WSADIE 生成的DDL 使该过程部分自动化。这里，我们将描述后一种选择。
DB2的联合技术以关系 DBMS的SQL 数据定义语言（DDL）透明性为特色。这意味着可以使用 DB2的CREATE TABLE …. OPTIONS 语法用一条语句执行两个独立的任务：在期望的远程数据源处创建一个表，并创建该表对应的DB2 别名。使用 DDL 透明特性可简化您的工作，因为 DB2 会执行任何必需的SQL 转换来正确地构造远程表；您不需要学习该数据源特定的SQL 语法来创建有效的表。我们将使用这一 DDL 透明特性在远程数据源处创建一个新的表，并为该表创建新的别名，该别名最终将由 CMP 实体 bean 使用。
开发这样的CMP 实体 bean 要遵循以下步骤：
切换至 J2EE 透视图。如有必要，可以按照 WSADIE的标准过程为您的实体 bean 创建一个 EJB 项目。
按照标准过程创建 CMP 实体 EJB。
用您打算创建的别名给 bean 命名。
添加对应于别名中各列的属性，要注意为每个属性指定适当的数据类型，并且要将适当的属性指定为键字段（它应映射到别名的主键列）。再次提醒，属性名应与列名对应。
调用 EJB 数据建模向导并选择自顶向下建模。
突出显示您的EJB，在其上单击鼠标右键，然后选择 Open With -> Mapping Editor。选择 top-down modeling。
单击 Next，确保数据库名与模式名设置正确。数据库名应映射到 DB2 客户机知道的联合数据库（在我们的环境中，它是 djdb ）。模式名应映射到已授权的联合数据库用户（在我们的环境中，它是 user1 ）。
保持 Generate DDL 框为选中，然后单击 Finish。
验证 EJB 到数据库的映射是否成功完成
突出显示您的EJB，在其上单击鼠标右键，然后选择 Open With -> Mapping Editor。
检查 Tasks 面板以确保没有出现过错误报告。
将 EJB 绑定到先前为联合数据库创建的适当数据源。
突出显示您的EJB，在其上单击鼠标右键，然后选择 EJB Quick Links -> Bind Data Source。
在面板的Datasource 区域输入有效的JNDI 名、用户名和密码。例如，在我们的测试环境中，我们输入 jdbc/Federated 作为 JNDI 名，输入 user1 作为用户名，以及输入 pass1word 作为密码。
保存您的更改（ Control-S），然后关闭编辑器。
照常为 bean 生成部署代码（突出显示您的EJB，在其上单击鼠标右键，然后选择 Generate Deploy Code）。
在部署并试图测试 bean 以前，创建别名和远程数据对象。请检查 WSADIE 生成的Table.ddl 文件。在 J2EE 透视图的Navigator 面板中在您的bean 项目名称下可以找到该文件。展开 ejbModule -> META-INF -> Schema来查看该文件。该文件为您将要生成的DDL 提供了一个良好的起点。以下列方式修改生成的DDL：
除去 CREATE SCHEMA 语句。
修改 CREATE TABLE 语句，以便在列的级别定义主键约束。例如，如果语句最初显示为
CREATE TABLE MYTABLE (COL1 INT, COL2 INT)
那么将该语句修改成与下面相似的语句
CREATE TABLE SCHEMANAME.MYTABLE (COL1 INT PRIMARY KEY NOT NULL, COL2 INT)
向 CREATE TABLE 语句添加 OPTIONS 子句，从而指定远程服务器和远程模式信息。远程服务器必须引用您在配置期间在 CREATE SERVER 语句中指定的数据源名。远程模式名必须与数据源处的有效模式名对应，该名称通常为您在配置期间在 CREATE USER MAPPING 语句中指定的REMOTE_AUTHID。例如，对于我们的环境配置，可以向 CREATE TABLE 语句添加一个 OPTIONS 子句，如下所示：CREATE TABLE SCHEMANAME.MYTABLE (COL1 INT PRIMARY KEY NOT NULL, COL2 INT) OPTIONS (REMOTE_SERVER 'ORACLE8', REMOTE_SCHEMA 'ORACLEUSER1')
除去 altER TABLE 语句。
下面是来自作者的测试环境的一个完整示例：
-- Generated by Relational Schema Center of WSADIECREATE SCHEMA user1;CREATE TABLE user1.FOOBAR (ID INTEGER NOT NULL, NAME VARCHAR(250));ALTER TABLE user1.FOOBAR ADD CONSTRAINT FOOBARPK PRIMARY KEY (ID);-- Revised DDLCREATE TABLE user1.FOOBAR (ID INTEGER PRIMARY KEY NOT NULL , NAME VARCHAR(250)) OPTIONS (REMOTE_SERVER 'ORACLE8', REMOTE_SCHEMA 'ORACLEUSER1')
可以在 DB2 命令窗口（Command Window）中、在 DB2 命令行（Command Line）上、或通过 DB2 命令中心（Command Center）（可通过 DB2 控制中心（Control Center）进入）执行修改后的DDL 语句。
创建跨越多个数据源的CMP 实体 bean
联合 DBMS 技术一个特别有趣的方面在于它能表示来自多个远程数据源的数据，就好象该数据是单一的本地管理的对象的一部分。管理员可以创建这样的视图：视图可以连接或合并来自多个表（或其它数据表现形式）的数据，而这些表驻留在由不同供应商制造的多个数据服务器上。对于 EJB 程序员来说，这提供了新的数据建模机会。可以较容易地构建单个 CMP 实体来跨越多个数据源。由于关系 DBMS 常见的视图更新约束，这样的bean 本质上是只读的，尽管如此，它们仍然提供了通过标准 EJB 技术集成全异数据的方法。在本节中，我们将讨论程序员如何用 WSADIE 通过三个步骤来构建这样的bean：
步骤 1：根据别名创建视图
步骤 2：为视图创建 CMP 实体 bean
步骤 3：修改生成的代码
步骤 1：根据别名创建视图
同任何关系 DBMS 一样，DB2 使管理员能够创建跨越多个表的数据视图。DB2的联合数据库技术扩展了视图的能力，因而它们可以包含来自多个服务器以不同本机格式存储的数据。要构建这样的视图，首先要为远程数据对象创建期望的别名。然后使用 SQL 创建一个连接或合并这些别名的视图。
在我们的环境中，我们利用 DB2的DDL 透明特性在 Oracle 和 SQL Server 数据库中创建表，并在我们的DB2 联合数据库中创建这些表的别名。
我们发出以下语句：create table orarest ( id int primary key not null, name varchar(20), cuisine varchar(20), budget int) options (remote_server 'ORACLE8', remote_schema 'ORACLEUSER1')create table msrest ( id int primary key not null, name varchar(20), cuisine varchar(20), budget int) options (remote_server 'MSSQL', remote_schema 'MSUSER1')
这使得下面的对象将被创建：
远程 Oracle 数据库中的ORAREST 表
DB2 联合数据库中的ORAREST 别名
远程 MS SQL Server 数据库中的MSREST 表
DB2 联合数据库中的MSREST 别名。
我们创建一个合并这两个别名的视图：create view multirest (id, name, cuisine, budget) as select id, name, cuisine, budget from orarest union select id, name, cuisine, budget from msrest
然后，我们使用该视图作为 CMP 实体 bean的基础（在下一节描述）。
步骤 2：为视图创建 CMP 实体 bean
创建视图后，您可以用 WSADIE 创建一个 CMP 实体 bean 来表示这一数据。其过程与 为现有的别名创建 CMP 实体 bean 中概括的方法非常相似。然而，如前所述，这样的视图本质上是只读的。如果您接受所有的缺省设置而不采取进一步的行动，那么在 EJB 容器试图执行与创建、除去和查找 EJB 相关联的方法时，会出现运行时异常。所有这样的方法都准备或试图执行数据库写操作，这对于我们正在使用的视图类型是无效的。（缺省情况下，生成的findByPrimaryKey() 方法执行 SELECT … FOR UPDATE ，这意味着将来可能会出现一个写操作。对于这里的视图定义来说，这种操作是无效的）。
此外，试图设置属性值的EJB 业务方法（“setter”方法）将导致运行时异常的出现，因为它们也会启动数据库写操作。在本节和下一节中，我们将看到如何通过 EJB 编程向导来修改缺省值，以及如何定制生成的EJB 部署代码以防止出现不必要的数据库写操作尝试，同时也使抛出的异常更容易说明：为什么给定的底层数据模型不支持某些 EJB 操作。
要创建这样的CMP 实体 bean：
切换至 J2EE 透视图。如有必要，可以按照 WSADIE的标准过程为您的实体 bean 创建一个 EJB 项目。
按照标准过程创建 CMP 实体 EJB。
将 bean 命名为与别名相同的名字。
添加对应于别名中各列的属性，要注意为每个属性指定适当的数据类型，并且要将适当的属性指定为键字段（它应映射到别名的主键列）。再次提醒，属性名应与列名对应。
调用 EJB 数据建模向导并选择自顶向下建模。
突出显示您的EJB，在其上单击鼠标右键，然后选择 Open With -> Mapping Editor。选择 top-down modeling。
单击 Next，确保数据库名与模式名设置正确。数据库名应映射到 DB2 客户机知道的联合数据库（在我们的环境中，它是 djdb ）。模式名应映射到已授权的联合数据库用户（在我们的环境中，它是 user1 ）。
取消选择 Generate DDL框，然后单击 Finish。
验证 EJB 到数据库的映射是否成功完成
突出显示您的EJB，在其上单击鼠标右键，然后选择 Open With -> Mapping Editor。
检查 Tasks 面板以确保没有出现过错误报告。
从您 bean的远程接口除去所有“setter”方法。
在 J2EE 面板中扩展您的EJB，并突出显示您 bean的远程接口。Outline 面板将显示 bean的远程接口内的所有方法。
突出显示每个 set…() 方法，在其上单击鼠标右键，然后选择 Delete。
将 EJB findByPrimaryKey() 方法的访问意图（access intent）设置为只读。
在 J2EE 面板中，突出显示您的EJB，在其上单击鼠标右键，然后选择 Open With -> EJB Extension Editor。
在该编辑器的Methods 面板中，扩展您的EJB 以显示 bean的home 接口中的所有方法。
突出显示 findByPrimaryKey() 方法，将 Access Intent值改为只读。
保存您的更改（ Control-S），然后关闭编辑器。
将 EJB 绑定到先前为联合数据库创建的适当数据源。
突出显示您的EJB，在其上单击鼠标右键，然后选择 EJB Quick Links -> Bind Data Source。
在面板的Datasource 区域输入有效的JNDI 名、用户名和密码。例如，在我们的测试环境中，我们输入 jdbc/Federated 作为 JNDI 名，输入 user1 作为用户名，以及输入 pass1word 作为密码。
保存您的更改（ Control-S），然后关闭编辑器。
照常为 bean 生成部署代码（突出显示您的EJB，在其上单击鼠标右键，然后选择 Generate Deploy Code）。
步骤 3：修改生成的代码
在为部署您的bean 而生成的代码中，有一小部分必须修改，以防止 create() 和 remove() 方法试图从 bean 所基于的视图插入和删除数据。从 bean的home 接口除去 create() 和 remove() 方法是不能接受的，因为 EJB 规范要求这些方法必须存在。将这些方法的访问意图设置为只读也是没有意义的，因为它们旨在产生 INSERT 和 DELETE 语句。相反，您应该修改这些方法的逻辑，以便抛出合理的异常而不是试图去写数据库。本节描述了应修改哪些生成的方法，并说明了如何这样做。但是，请注意，每当您为 bean 生成了新的部署代码，都需要修改这些方法。没有办法指示 WSADIE（或 WebSphere Application Server）在重新生成代码时保留您的更改。
要修改生成的代码，请遵循以下步骤：
重写 bean home 存根中两个 remove(…) 方法的逻辑。该文件的名称将是“ _ YourBeanNameHome_Stub ”。例如，我们构建名为 MultiRest的bean，因此我们的bean home 存根是 _MultiRestHome_Stub 。在该文件内，有 remove(Object …) 和 remove(Handle…) 方法。将紧随方法的声明之后出现的实现代码注释掉。修改方法，以便抛出带有一个合理错误消息的新的CreateException。例如：public void remove (Object arg0) throws .... { throw new RemoveException("This EJB is mapped to a view and cannot be removed."); // comment out generated code below ...}public void remove (Handle arg0) throws .... { throw new RemoveException("This EJB is mapped to a view and cannot be removed."); // comment out generated code below ...}
重写 bean home 存根中 create(…) 方法的逻辑。该文件的名称将是“ _ YourBeanNameHome_Stub ”。在我们的示例中，它是 _MultiRestHome_Stub 。（与前面讨论过的包含两个 remove(…) 方法的文件是同一文件）。将紧随 create() 方法的特征符之后出现的实现代码注释掉。修改方法，以便用一个合理的错误消息抛出新的CreateException。例如：public MultiRest create(...) throws ... { throw new CreateException("This EJB is mapped to a view. New instances cannot be created."); // comment out generated code below ...}
重写 bean 存根中 remove() 方法的逻辑。该文件的名称将是“ _ YourBeanName_Stub ”。例如，我们构建名为 MultiRest的bean，因此我们 bean的存根是 _MultiRest_Stub 。在该文件内，有一个 remove() 方法，应将它的实现代码注释掉并用一个合理的异常来替代。例如：public void remove() throws .... { throw new RemoveException("This EJB is mapped to a view and cannot be removed."); // comment out generated code below ...}
结束语
本文与前两篇文章一起，共同描述了如何将联合 DBMS 和 Web 应用程序服务器技术结合起来，为 Java开发人员集成来自多个数据源的数据提供了新的选择。可能的好处包括以下能力：
将现有的Web 应用程序服务器的应用范围扩展到它们本机不支持的其它数据源。
实现新的对象模型，其中包括那些 CMP 实体 bean 可在其中跨越多个数据源的对象模型。
简化了需要访问来自多个数据源的数据的Java 服务器端组件和 Web 服务的开发。
将必须在 Java开发平台和 EJB 部署平台上安装和维护的、与 DBMS 相关的软件最小化。
利用现有的Java开发工具。
在对于应用程序很关键的数据存在于多个数据源中，以及可使用数据库管理技能来解决管理问题时，是考虑这样的技术结合的最佳时机。
我不敢说我明天便可以做一个快乐的人，面朝大海春暖花开。
