簡介
實體 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 WSADIE
CREATE SCHEMA user1;
CREATE TABLE user1.FOOBAR
(ID INTEGER NOT NULL,
NAME VARCHAR(250));
ALTER TABLE user1.FOOBAR
ADD CONSTRAINT FOOBARPK PRIMARY KEY (ID);
-- Revised DDL
CREATE 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開發工具。
在對於應用程序很關鍵的數據存在於多個數據源中，以及可使用數據庫管理技能來解決管理問題時，是考慮這樣的技術結合的最佳時機。
