應用程序組件應實現針對企業服務的請求。要實現這些請求，應用程序組件常常必須更改底層數據存儲的狀態。這些更改絕對不能破壞持久數據存儲的完整性。（在有關數據持久性的 第一篇文章中，我們將 持久數據存儲定義為獨立的數據資源庫，即使在服務器崩潰或網絡失敗時，這個數據資源庫也能保護其中的數據。）為了確保持久性，應用程序組件必須能處理並發性、連接管理、數據完整性以及同步。J2EE 的三種數據管理技術都能為開發人員處理這些功能，只不過每種技術都有自己的處理方法。
上月我們探討了實體 bean 和 JDBC 的優缺點。本月，我們將查看 Java 數據對象如何與無狀態會話 bean 組合，以及該解決方案如何與標准實體 bean 應用程序進行比較。由於 JDO 仍是一種相當新的技術（最新的 J2EE 持久性解決方案），所以我們將首先概述其工作原理。
JDO 概述
長久以來，Java 應用程序和持久數據管理之間的關系一直是不容易處理的。許多持久性機制以關系的方法而不是面向對象方法存儲數據。即，數據存儲在由包含字段的記錄組成的表中，而不是存儲為自包含對象（這些對象擁有內部數據和對其它對象的引用，而其它對象也擁有內部數據和引用）。將面向對象的表示轉換成關系表示一直就很麻煩、易出錯且會降低應用程序性能。直到最近，少數幾個本質上是非關系型的持久性機制（例如 SQL BLOB 和 Java 序列化）使用起來也很麻煩。大多數持久性機制讓開發人員負責處理持久性，或使用非 Java 語言（例如 SQL）與後端數據存儲進行相互作用。
JDO 的優點在於它很簡單。開發人員使用 Java 語言持久存儲對象實例並從存儲器檢索實例。處理邏輯、同步和故障轉移等均被透明地處理。開發人員無需使用 SQL 或 Java 語言提供的不便的序列化機制，只使用 POJO（無格式普通 Java 對象）即可，利用 JDO 接口將對象引用傳遞到存儲器中並從存儲器檢索對象引用。
JDO 還采用了很多 JDBC 使用的高級體系結構。它使用一種可插入的體系結構，在這一體系結構中，開發人員將自己的代碼編寫成標准接口集（JDO API），而供應商提供這些接口的實現。這允許使用 JDO 接口的應用程序“插入”任何支持 JDO API 的數據存儲。和 JDBC 一樣，這可以使移植容易，並促進各供應商之間的競爭，從而產生更好的產品，因為供應商會力爭提供更有效且功能更強大的實現。
會話 bean 和 JDO
會話 bean 是任何合並了 EJB 技術的 J2EE 體系結構的基干。對於無狀態會話 bean 尤其如此。正如以前討論的，無狀態會話 bean 的穩定性和可預測性使其特別適合於管理持久的企業數據。
但是會話 bean 本身不能訪問持久數據存儲。它們必須與其它技術（如實體 bean、JDBC 或 JDO）相結合以創建一種持久數據管理機制。將會話 bean 與 JDO 結合類似於將它們與 JDBC 結合，但 JDO 是以更面向對象且更以 Java 為中心的觀點處理該問題的。
功能強大的組合
通過向 EJB 容器請求資源管理器連接工廠，企業 bean 獲得對外部資源的訪問權。使用 JDBC 的 EJB 組件是這樣做的，使用 JDO 的 EJB 組件也是這樣做的。會話 bean 必須做的第一件事是通過調用 JNDI 查詢，獲得對 PersistenceManagerFactory 的引用。然後從工廠獲得 PersistenceManager 實例。如果會話 bean 正在使用容器管理的事務，那麼每個業務方法將使用工廠來獲得新的 PersistenceManager 實例，之後在退出該方法之前關閉該實例。如果使用的是 bean 管理的事務，那麼開發人員將確定事務的開始條件和結束條件。因此，可以在多個業務方法調用中使用同一 PersistenceManager 實例。同樣，可以在一個業務方法中打開並管理多個事務。 PersistenceManager API 支持所有這些方案。
與 PersistenceManager 交互的 JDO API 很簡單且非常直觀。開發人員通過調用 makePersistent() 方法使對象持久。而且，這個方法特征符被重載，從而允許將各種對象類型視為持久對象（單個對象、對象數組或對象集合）。檢索對象同樣很簡單。 getObjectById() 方法使用由開發人員確定的唯一值（類似於主鍵）來區別對象實例。JDO 還支持基於類型的查詢，這些查詢能基於指定的類型（即，實現公共接口的子類和類）檢索單個對象或對象集合。與 JDBC 類似，JDO 支持基本的事務性控件： begin() 、 commit() 和 rollback() ，並能指出 PersistenceManager 實例應該采用樂觀的還是悲觀的事務管理方法。
優點
作為組合技術解決方案，會話 bean 和 JDO 提供了許多優點，其中有些來自會話 bean，而其它的來自 JDO。正如我們上個月所了解的，使用會話 bean 而不使用實體 bean 進行交付的主要優點有兩個：
設計簡單。從體系結構設計的觀點來看，直接通過會話 bean 來處理數據管理比使用實體 bean 簡單得多。
細粒度控制。因為會話 bean 是通用的工作程序組件，所以它們允許開發人員對整個持久性進程進行完全控制，包括高速緩存、持久性、並發性和同步等。
這兩個優點並不是會話 bean／JDO 組合所特有的：會話 bean 與 JDBC 的結對也存在這兩個優點。但是，JDO 確實提供了一些獨特的優點：
編碼簡單。JDO 體系結構向開發人員隱藏了低級別的持久性細節，從而使他們專注於從業務過程的角度管理對象，不至於陷入數據持久性邏輯的瑣碎細節中。
提高的生產力。JDO 程序員能完全在面向對象的范例內操作。這通常會使開發更簡潔、更平滑且更不易出錯，因為程序員不用在關系的思想體系和面向對象的思想體系之間頻繁地轉換。
面向對象的持久性。JDO 的面向對象本質不僅提高了開發人員生產力，而且它還考慮到比關系持久性所提供的還要豐富的持久性機制。JDO 並不僅僅使 Java 對象持久；它還透明地處理整個相關對象圖的持久性。因此，當實例被持久存儲時，它所維護的對其它對象實例的任何內部引用也都被持久存儲（除非它們已被聲明為瞬態）。JDO 還存儲類型層次結構的完整信息，並能根據類型（父類和接口）實現請求，而不是只了解持久實例的特定局部類型。
概括起來，將會話 bean 與 JDO 結合使用可以產生三個主要優點：簡單（在設計和開發方面）、生產力以及增強了對數據持久性的控制。
缺點
從其優點來看，會話 bean 與 JDO 是完美的組合，可以解決所有持久性難題！但還是讓我們考慮一下這種方法的一些缺點：
JDO 不成熟。JDO 還處於初期。到編寫本文時，JDO 1.0 規范的發布還不到一年。其結果是，JDO 社區還非常小，最大且最具威望的 JDO 門戶網站可以炫耀的也只是其會員有五千多一點。盡管這些數據並不表示 JDO 是一種差勁的技術，但它們確實表明它還處於前沿。幾乎沒有幾家公司願意嘗試在業務級實現中使用 JDO。所有這些現狀使 JDO 開發人員和架構設計師幾乎沒有已經實踐證明的設計模式或案例研究來指導他們的 JDO 開發工作。
會話 bean 不是事務性的。J2EE 客戶機不能直接訪問 JDO 對象。必須由 servlet 或會話 bean 處理進入請求。因此，盡管很容易將 JDO 對象聲明為事務性的，但仍必須使用非事務性組件來訪問它們。在將事務語義直接編碼到會話 bean 的應用程序代碼中時，開發人員必須盡一切可能確保每個功能的業務規則、流程控制和事務完整性都得以保留並是容錯的。盡管使用容器管理的事務可以極大地緩解這一問題，但是這樣做限制了開發人員對持久性進程的控制，並除去了許多控制事務粒度所產生的體系結構上的靈活性。
概括起來，會話 bean 和 JDO 的組合有兩個主要缺點：與別的技術相比，JDO 是一種未經實踐證明的技術，而會話 bean 向業務過程引入了固有的非事務層。
實體 bean
我們已（在前一篇文章中）較詳細地討論了使用實體 bean 的優缺點，所以這裡只概括與本文關系最緊密的幾點。
作為企業數據持久性機制，實體 bean 有五個主要優點：
標准化。EJB 規范比較成熟，因而有許多優勢：眾所周知的設計模式、案例研究和最佳實踐，還有豐富的供應商支持的開發工具集。
容器管理的服務。EJB 容器使開發人員不必管理常見的企業功能，如安全性、事務處理、連接合用和外部資源管理。
透明的持久性。實體 bean 為處理持久性提供了兩個透明選項。容器管理的持久性（CMP）實體 bean 在容器中自動處理所有持久性語義。bean 管理的持久性（BMP）實體 bean 允許開發人員編寫持久性邏輯，但仍然減輕了確保數據完整性和並發性的責任（通過將這些任務分配給容器）。
事務支持。實體 bean 提供了兩個事務支持模型。在 CMP bean 中聲明事務語義。在 BMP bean 中，開發人員直接實現這些語義。這兩種情況中，都是容器管理事務，並確定應該提交給定的事務還是應該回滾它。
基於組件的設計。實體 bean 被設計成自我包含的組件，這些組件使用部署描述符配置，並且不用修改任何代碼就可以將它們部署到任何 J2EE 應用程序服務器中。
另一方面，實體 bean 也有四個主要缺點：
設計復雜性。容器管理的服務和自動且透明的持久性為整個應用程序設計引入了復雜性。實體 bean 通常也可以通過會話 bean 來訪問，這意味著每個事務至少包含兩個企業 bean，而通常會更多。
構建周期很長。一個 EJB 周期（設計／構建／測試／集成／測試／部署）所花的時間比可比的 Java 持久性解決方案多兩到三倍。
響應時間。實體 bean 與 bean 實例的粒度相關。因此，開發人員始終面臨選擇：要麼將 bean 按原樣裝入，而在別的方面解決響應時間長的問題；要麼將數據分解成較小的實體，從而創建更復雜的系統體系結構。
資源使用情況。實體 bean 消耗了大量系統資源。
概括起來，實體 bean 得益於標准化和業界最佳實踐、減少了企業開發的一些復雜性並提供了牢固的基於組件的設計。但獲得這些優點所付出的代價就是實體 bean 通常會引入復雜性和很長的構建周期，從而使包含它們的系統設計和開發更困難。實體 bean 還由於過度消耗資源以及對大型實體並發請求的響應較慢而聲譽欠佳。
幾點對比
在比較任何兩種技術時，重要的是不僅要考慮它們的差別，還要考慮它們的相似點。作為 J2EE 技術，實體 bean 和 Java 數據對象有幾個共同的特性。我們先討論這幾個特性，隨後討論每種解決方案特有的優缺點。
實體 bean 和 JDO 都有以下特征：
透明的持久性。透明的持久性所帶來的自由是人們夢寐以求的，開發人員不必知道也不必關心其中的技術持久性細節。JDO 和實體 bean 都使 Java 程序員享受到了這一點。
可移植性。JDO 和實體 bean 都基於與供應商無關的標准。使用各自的標准 API 編寫的應用程序可以移植到不同供應商的 API 實現。
靈活的事務管理。JDO 和實體 bean 都為開發人員提供了選擇：通過編程管理事務，還是自動管理事務。JDO 使用 PersistenceManager 管理事務，而實體 bean 將事務管理委派給了 EJB 容器。
在確定采用實體 bean 還是采用 JDO 時，請考慮這兩種技術的以下優缺點：
最佳實踐與設計復雜性。Enterprise JavaBeans 技術包含豐富的文獻、已成文的設計模式和最佳實踐、精巧的工具以及大量擁有 EJB 技術經驗的 J2EE 程序員。其缺點是，實體 bean 的復雜性使您必須運用所有這些有用資產才能確保項目成功。針對大量的 EJB 技術，架構設計師和開發人員必須在有經驗的程序員、設計模式和業界最佳實踐的可用性方面找到平衡。
缺乏經驗與簡單性。對於在最佳實踐方面的不足，JDO 用簡單性來彌補。它很簡單且易使用，而且 POJO 比“實體”概念更易於理解。盡管擁有實際 JDO 經驗的 Java 編程專家很少，但該技術很容易掌握。相對於 JDO 固有的簡單性，J2EE 架構設計師和開發人員必須權衡缺乏模式、最佳實踐和案例研究所產生的影響。
缺乏舊的支持。目前，沒有任何主要的關系數據庫管理系統（RDBMS）供應商支持 JDO。因此，開發人員必須將系統數據遷移到支持 JDO 的供應商，或者將 JDO 只用於其功能不依賴舊 RDBMS 數據存儲的新項目或組件。
新的持久性范例。JDO 考慮到了豐富的面向對象的持久性機制，它充分利用了對象合成（包含其它對象的對象）及繼承（通過完整的類型層次結構來識別對象類型）。盡管 JDO 的面向對象持久性范例給應用程序開發人員帶來了許多便利，但它也使數據庫管理員（DBA）灰心和困惑。目前 JDO 不提供結合存儲過程的機制，因此 DBA 要花大力氣學習如何使用 XML 聲明約束，或如何指導 Java 開發人員怎樣管理數據。我們再次發現 JDO 更適合於新項目、新組件或現有的獨立於舊 RDBMS 的應用程序。
資源使用情況。盡管可用的性能基准測試程序非常少，但我們可以假設依賴實體 bean 而獲得透明持久性的應用程序所消耗的服務器資源將比基於 JDO 的應用程序多。
結束語
在這篇 J2EE 探險者系列的專欄文章中，我們已經完成了對數據持久性的探究，它是 Java 開發中最具有技巧性的領域之一。盡管 J2EE 對處理數據持久性確實提供了三種可靠技術，但沒有一種是完美的。
多年來 JDBC 一直是 Java 開發人員進行數據訪問的標准。它是一種牢固的且已證實的技術，允許架構設計師和開發人員利用現有關系數據庫基礎結構和現有的專門技術來產生數據庫查詢。隨著時間的流逝，它已經發展成可以提供完全具有高速緩存和資源池機制的完善的數據庫驅動程序，很顯然這使開發人員得益頗多。作為企業持久性技術，JDBC 還存在一些不足，它讓開發人員或數據庫負責管理並發性和數據完整性。盡管有這個缺點，但是由於其成熟性、普遍適用性和性能使它被廣泛使用。
實體 bean 比 JDBC 稍欠成熟，但是它們仍對企業數據持久性提供了可靠的解決方案。就如同使用 JDBC 的情況，架構設計師和開發人員在使用實體 bean 時，能利用現有的關系數據庫基礎結構和現有的專門技術產生數據庫查詢。實體 bean 可以簡化開發健壯數據持久性代碼的過程，因為 EJB 容器提供了許多生命周期企業服務，例如安全性、資源管理、事務控制和透明的持久性。實體 bean 提供了功能強大的數據持久性解決方案，它為開發人員透明地處理大量語義和細節。這一強大功能和輕松的開發所付出的代價就是實體 bean 是資源密集型的，而且正確設置它很復雜，調試很困難。
對於 J2EE 陣營中較成熟但不以 Java 為中心的技術，Java 數據對象是一種引人關注的替代技術。JDO 的純面向對象方法和設計的簡單性使掌握它所需的適應期比其它兩種持久性技術都短。但 JDO 也沒有 JDBC 或 EJB 技術成熟，這導致開發人員和架構設計師在作設計和部署決定時無法獲得足夠有幫助的資源。而且，對於它向 Java 開發人員提供的所有易用性，JDO 要求 DBA 作出明確承諾，即為使用它必須盡快了解全新的數據管理范例。
下個月，我們將探索企業消息傳遞，以此來結束對 EJB 技術領域的首次探險。到那時，希望能快樂地探險！
