新的 EJB 2.0 規范不僅僅是一個新的階段性發行版，它加入了許多引人注目的變動，包括 CMP 組件模型中的一些變動和一種新的 bean 類型，它們將增強您在開發應用程序時的靈活性和可移植性。請率先了解此新規范的功能，本月已發布了它的公開草案。 2000年6月2日發布的 Enterprise JavaBeans 2.0 不僅是一個階段性發行版，而且是該規范的一個新版本。整個規范有 500 多頁，比以前的 EJB 1.1 規范長了 200 頁 (66%)。該規范中最重要的變動是對容器管理的持久性 (CMP) 所作的更改，以及引入了一種全新的 bean 類型，即 MessageDrivenBean。 EJB 2.0 中的大量更改都集中在一種新 CMP 組件模型的定義中。它完全不同於舊的 CMP 模型，因為它引入了一個全新的成員，即持久性管理器，並引入了全新的方式來定義容器管理的字段，以及定義這些字段與其它 bean 和從屬對象的關系。 MessageDrivenBean （消息 bean）的引入也是非常重要的。消息 bean 體現出 JMS （Java Message Service）與 EJB 相集成，以創建出一種全新的 bean 類型，它設計用來處理異步的 JMS 消息。這種振奮人心的新型 bean 為 JMS 客戶機提供一種組件模型，允許將它們部署到 EJB 容器系統的豐富而強健的環境中去。 對該規范還作了許多較小的其它更改。這些其它更改雖然也重要，但它們主要是涉及使該規范更嚴格，以便消除多義性，並使這些組件具有更高的可移植性。本文集中討論 EJB 2.0 中引入的新 CMP 和消息 bean 組件模型。 我將提供幾個具體的例子，所以讀者應該很容易跟上並理解它。但是，EJB 初學者可能發現這個材料比較困難，因為它假定讀者已對 EJB 有了基本的了解。有關 EJB 的詳細信息，請參閱參考資料。 容器管理的持久性 容器管理的持久性在 EJB 2.0 中發生了根本變化。在 EJB 2.0 中，持久性管理器在運行時自動處理 CMP 實體 bean 的持久性。持久性管理器負責根據一種稱為抽象持久性方案的新的 bean 持久性管理器合約，將實體 bean 映射到數據庫。此外，持久性管理器還負責實現和執行多種查找方法，這些查找方法均基於一種稱為 EJB QL 的新型查詢語言。 注意到以下事實是很重要的，即符合 EJB 2.0 規范的產品必須能支持 EJB 1.1 CMP 模型，又能支持新的 EJB 2.0 模型。雖然這兩種模型並不兼容，但是為了保證向後兼容性，就必須能支持 EJB 1.1 模型。 抽象持久性方案 為了理解抽象持久性方案是如何工作的，以及它為什麼重要，我將為您快速地回顧一下在 EJB 1.1 中是如何處理 CMP 的，隨後再討論在 EJB 2.0 中如何定義它。 EJB 1.1 中的 CMP 模型 在 EJB 1.1 中，bean 開發人員負責將 bean 類的持久性字段聲明為 Java 基本類型或可序列化類型。下列示例顯示了一個 Employee 企業級 bean 類，它是按 EJB 1.1 定義的，帶有幾個 CMP 字段： // Employee bean 類 public class EmployeeBean implements Java.ejb.EntityBean { // 實例字段 EntityContext ejbContext; file:// 容器管理的字段 public int identity; public String firstName; public String lastName; public double salary; public Address address; public Integer ejbCreate(int id, String fname,String lname){ identity = id; firstName = fname; lastName = lname; return null; } ... // Address 從屬類 public class Address implements Serializable{ public String street; public String city; public String state; public String zip; } 當將關系數據庫用於持久性時，基本字段如 identity、firstName、lastName 和 salary，很容易持久化，因為它們很好地映射為 SQL 類型，如 INTEGER、CHAR 和 DOUBLE。 在 EJB 1.1 中，CMP bean 的 XML 部署描述符提供 cmp-field 元素，用以標識此 bean 類中的持久性字段（容器管理的字段）。如下所示，cmp-fIEld 元素用來區分寫入數據庫的字段和不寫入數據庫的字段。例如，ejbContext 字段就不包括在容器管理的字段的列表中，因此它不是持久性字段。
EmployeeEJB ... Container ... identity firstName lastName salary address ... 容器提供者提供一種工具，用來將 bean 的持久性字段映射到數據庫表中的列，通常每個 bean 對應一個表。但是，可序列化的類型，如 Address，就比較難於持久化。在 EJB 1.1 中，沒有標准的方法將可序列化的對象映射到關系數據庫。雖然 Address 類有其自身的字段集，但 XML 部署描述符並沒有提供一種機制，來將這些字段映射到數據庫。在大多數情況下，人們期望將可序列化的對象（如 Address）作為二進制類型（有時稱為 blob 類型）持久化到某個數據庫表中。 由於實體 bean 的數據方案逐漸復雜起來，所以這個問題也變得嚴重了。例如，Employee bean 可能有多個類似於 Address 的子對象，如 Benefits 和 JobPosition。這些子對象稱為從屬對象，可以形成關系數據庫中跨幾個表的復雜對象圖。另外，EJB 1.1 中的 CMP 在很大程度上不足以持久化與其它 bean 的關系。在 EJB 1.1 中，如果某個 bean 准備維持與另一個 bean 的關系，則容器會自動將主關鍵字或句柄用作一個鏈接。與某些其它 bean 的關系其性質可能是雙向的，或者要依賴於一些不易用主關鍵字或句柄來表示的字段，為了保持與這類 bean 的關系，上面的辦法已被證明是一種遠未完善的機制。 EJB 2.0 的 CMP 模型 在 EJB 2.0 中，CMP 實體 bean 和持久性管理器之間的新合約，使您能夠在實體 bean 中定義更復雜的、可移植性更強的關系，包括 bean 與 bean 之間、bean 與從屬對象之間、甚至從屬對象與從屬對象之間的關系。 持久性管理器是新加入到 Enterprise JavaBeans 部署過程中的。容器廠商，或專長於特定數據庫的持久性的廠商，將能提供這種持久性管理器。其思路是將用於管理 bean 關系的機制從容器中分離出來，容器只負責管理安全、事務和資源。這種職責上的分離使不同的持久性管理器能夠與不同的容器一起工作。它也使實體 bean 在不同 EJB 廠商之間以及在各種持久性管理器之間具有更強的可移植性。 如果您使用或學習過 Thought Inc. 生產的，能自動為 EJB 1.1 容器生成 BMP（bean 管理的持久性）bean 的產品 CocoBase，則您對持久性管理器工具如何工作就已經比較熟悉了。CocoBase 根據 bean 部署者提供的，從對象到關系的映射信息，為 BMP bean 生成全部數據庫訪問邏輯。在 EJB 2.0 中，持久性管理器能夠根據部署描述符、bean 的抽象持久性方案和部署者完成的工作所提供的信息，生成 CMP 實體到關系數據庫的映射。但是，持久性管理器並不局限於關系數據庫。也可以為對象數據庫以及遺留的系統和 ERP 系統（如 SAP）開發持久性管理器。 為了將持久性管理器從容器中分離出來，必須定義 bean 與持久性管理器之間的合約。這個合約在新的抽象持久性方案中表現出來。此方案是通過部署描述符中一組新的 XML 元素和 CMP 實體 bean 中的一組代碼習語定義的。在 EJB 2.0 中，CMP bean 類被聲明為抽象類，它的持久性字段和關系字段是使用抽象的讀方法和寫方法來訪問的，而這兩種方法的方法特征則映射為 XML 部署描述符中的特定元素。 在部署該 bean 時，您將使用持久性管理器工具，根據 XML 部署描述符和 bean 類，來具體實現此抽象 bean 類及其從屬對象類。具體實現將包括數據訪問代碼，此代碼將在運行時將 bean 的狀態實際讀出和寫到數據庫中。在運行時，容器使用由持久性管理器工具生成的子類，而不使用 bean 提供者定義的抽象類。 bean 類的繼承層次結構 為了使討論更充實，這裡提供一個 CMP 實體的示例，它更具體地說明了抽象持久性方案是如何工作的。
