J2EE 與 IBM 對象-關系數據庫系列連載二

2019-11-18 12:39:07

字體：大中小

來源：轉載

供稿：網友

　　請求-響應
　　
　　基于 Web 的用戶和應用程序服務器之間的交互遵循使用 HTTP 協議的原始 Web 模型。這意味著我們要受上面簡要描述過的請求-響應模型的約束。
　　
　　為了便于進行該通信，引入了新的 java 類。用于處理該通信的主類就是 HttpServlet 類。該類包含了一組與 HTTP 協議相匹配的方法，其中獲得請求內容的方法是 doGet() 和 doPost()。
　　
　　HTTP 協議要么通過在 URL 中放置參數來向 Web 服務器傳遞信息，要么獨立于 URL 傳遞信息。第一種稱作 GET 命令，而第二種稱作 POST 命令。GET 命令的優點是，URL 包含了檢索請求信息所需的所有信息。因此，可將其加入書簽以便將來重新調用。而 POST 命令獨立于 URL 發送附加信息，提供了更好的安全性。當需要發送比較大量的信息時，該方法也更為合適。其缺點就是不能被加入書簽。
　　
　　doGet() 和 doPost() 接收兩個參數：HttpServletRequest 請求和 HttpServletResponse 響應。這些附加類為您提供了需要從請求中獲得的所有信息。您將使用響應參數來編寫應答。已提供的方法可以滿足您完成該應答所需的所有功能。
　　
　　瀏覽器和應用程序服務器之間的一切交互都是通過 HttpServlet 類完成的。您得花些時間去學習上述類中所包含的字段和方法。
　　
　　模型-視圖-控制器
　　
　　J2EE 建議使用 MVC 開發模型。該模型背后的思想是：盡可能地將與用戶的交互、處理以及數據訪問分離開。該模型已經活躍了很長一段時間。我記得它最早出現在 20 世紀 80 年代的 Smalltalk 語言中。
　　
　　圖 3 說明了該模型與 J2EE 組件的使用。應用程序首先發出一個 jsp（視圖）請求，而 JSP 稍后將返回一個在瀏覽器中顯示的頁面。接著，用戶選擇一個動作，向 servlet（控制器）發送信息。再由 servlet 來決定必須完成什么操作，它可能需要檢索一個 Java bean（模型）或 EJB 來提供數據訪問。然后，servlet 可以向 JSP 傳遞一個對 Java bean 的引用，以便訪問要格式化和顯示的數據。
　　　 J2EE 與 IBM 對象-關系數據庫系列連載二（圖一）

　　圖 3. MVC 模型
　　
　　EnterPRise Java Beans（EJB） EJB 體系結構提供了開發分布式應用程序的標準模型。一個 EJB 包含兩個接口：Home 和 Remote。home 接口用于創建或查找指定類型的對象。remote 接口是通過 home 接口檢索得到的，為您提供了對遠程對象的公共方法的訪問。
　　
　　EJB 有三種類型：會話（session）、消息（message）和實體（entity）。會話 bean 提供對業務過程的訪問。它們分為兩種類型：有狀態的和無狀態的。有狀態會話 bean 保存特定客戶機調用之間的信息。無狀態會話 bean 可以被多個客戶機共享，因為它不保存調用之間的任何特定信息。
　　
　　消息 bean 是一種無狀態的 bean，提供了用于操縱 JMS 異步消息的業務過程。實體 bean 代表業務數據及其相關的操縱邏輯。該業務數據必須保存在持久性存儲器（例如，一個數據庫）中。EJB 是通過部署描述符進行分布的，部署描述符包括事務屬性、安全性授權和持久性等信息。
　　
　　面向對象方法（OOA）面向對象（Object Orientation）改進了軟件的開發，它也是 J2EE 環境中的要害部分。OO 的要害包括數據封裝和繼續的概念。
　　
　　面向對象支持層次結構方法。我們可以看到對象繼續層次結構和對象組合層次結構。圖 4 通過部分醫學數字圖像和通信（Digital Imaging and Communications in Medicine，DICOM）標準，說明了這兩種類型的層次結構。
　　 J2EE 與 IBM 對象-關系數據庫系列連載二（圖二）

　　圖 4. DICOM 層次結構
　　
　　一個 Data 對象（DICOMData）可以非凡化為以下四種對象中的一種：patient、study、series 或 image。而在圖 4 所展示的另一層次結構中，則可以將 TAG 對象非凡化為 DataElement。這些類型的繼續在 OO 分析、設計和編程中極為普遍。僅僅查看 Java 類就可以看到一組精巧的對象繼續層次結構。
　　
　　圖 4 還展示了聚集/組合示例，包括組合層次結構中的多個層次：我們看到，一個 Patient 可以包含多個 study，而一個 study 可以包含多個 series，而一個 series 又可以包含多個 image。我們還看到所有這些對象都可以包含多個 TAG/DataElement，因為該組合是在對象繼續層次結構的父類（DICOMData）中表示的。
　　
　　聚集/組合模型使對象之間不太明顯的區別變得有意義。閱讀 OO 文獻時會發現，在多數商業應用程序中，具有頻繁搜索并直接操縱的“第一級”對象，以及僅通過第一級對象來訪問“第二級”對象 —— 假如您不檢索第一級對象，就永遠無法獲得第二級對象。30 年前，這種典型的層次結構模型主導了數據庫模型。我們將在后面的小節中進一步討論它所帶來的優點和缺點。
　　
　　OO 中另一個有趣的主題就是對象持久性。實際上，OO 文獻整個都在討論對象，以及它作為內存中的對象與其他對象的交互。另一方面，持久性似乎是個很麻煩的問題。主要問題就是“持久保存對象”。數據庫服務器除了在必要時恢復對象之外，不會添加值。這就是為何“阻抗失諧”問題對于許多 OO 人員來說顯得如此重要的部分原因。
　　
　　J2EE 持久性模型
　　
　　在談論 J2EE 環境中的持久性時，我們很可能要涉及實體 bean。J2EE 環境為實體 bean 提供了兩種持久性模式：bean 治理和容器治理。Bean 治理的持久性將所有的工作交給 EJB 開發人員，讓他們確定如何存儲和檢索特定的對象類型。
　　
　　容器治理的持久性從 EJB 的實現中去除了持久性的細節。部署描述符中包含的抽象模式定義了實體 bean 的持久性字段，以及它與其他 bean 之間的關系。這一工作是通過 EJB QL 語言完成的，該語言是 SQL 92 標準的一個子集。
　　
　　在創建一個實體 bean 時，容器治理的持久性會將其信息保存在數據庫中。每當一個方法調用修改該 bean 的內容時，這些修改就必須在數據庫中加以反映。當然，這也要考慮目標實體 bean 的事務屬性。
　　
　　J2EE 試圖讓對象持久性盡可能地簡單、透明和自動。在此過程中，它希望使持久性盡量獨立于所有的數據庫產品，而無需考慮使用何種類型的數據庫或持久存儲器。因此，數據庫被降級為簡單的持久性存儲設備。
　　
　　IBM 的對象-關系數據庫
　　
　　IBM 提供了兩種最新型的對象-關系數據庫：DB2? Universal Database（UDB）和 Informix Dynamic Server（IDS）。這兩種都是關系型的數據庫，因而包含了關系模型及其集合處理的優點。它們還包含了對象的概念，并且可以擴展數據庫服務器的功能，更好地配合您的業務模型。而數據庫服務器則是一個用于處理業務數據的可擴展性的架構。這些可擴展性特性與 J2EE 環境中的概念一致，因為 J2EE 確實是一個可擴展的應用架構。
　　
　　這些數據庫產品在數據庫市場中處于領導地位。要了解這些產品是如何崛起的，我們必須先看一看關系數據庫為何成為了該行業的主導。在關系數據庫出現之前，占主導地位的各種數據庫都是按照層次結構來組織的。這應用了“分而治之”的概念。
　　
　　從層次結構的頂層開始，您要選擇一個指定節點來表示一個容器對象，如區域或部門，其中包含的是您數據庫中所有數據的一個子集。該對象有可能包含成員。然后，您可以通過該節點的成員指針來選擇另一個子集。該過程可以一直進行到您找到了需要操作的指定元素為止。除了可以添加、刪除或修改元素之外，您還可以通過操縱指向元素或節點的指針，將元素移動到該層次結構中的另一位置上。
　　
　　層次型數據庫具有兩大優點：
　　
　　它們是系統開銷最小的輕量級數據庫，因為它們僅僅返回應用程序所請求的節點和成員指針。它們快速地將數據分成較小部分以獲得所需的記錄。另外，它們還具有一些可改善性能的特點：
　　
　　針對單個問題的優化：本質上，層次數據庫就通過一條指定的路徑來優化數據訪問。例如，一家大型銀行可能按區域、部門和帳戶來劃分單元。那么，就可以極其高效地找到屬于已知部門和區域的指定帳戶，或者按區域和部門制作報表或進行分析。但是，要為某個指定客戶找到所有帳戶就比較困難了，因為該客戶可能有多個過去創建的帳戶。而且，該客戶可能經歷過多次職位和住所的改動，從而會擁有多個部門和多個區域中的帳戶。
　　
　　大多數公司都要通過他們的數據來解決多重問題。假如遵循層次模型，他們可以很好地解決某一個問題。而其他問題的解決則可能比較糟糕。為了取得相當好的性能，可能需要在多個層次中復制數據，從而可能極大地增加數據治理的復雜性。
　　
　　對于物理記錄的處理：層次數據庫中所存儲的記錄是由應用程序來直接操縱的。應用程序必須知道每個字段的次序和類型，因為它必須計算該字段在記錄中的偏移量。修改了記錄結構就需要修改訪問這些記錄的應用程序。以編程方式實現對象的重定位：該指針操縱為復制和懸空指針（dangling pointer）等問題的發生制造了機會。
　　
　　總的來說，層次模型在某些特定的應用程序中是一種極為可行的模型，IBM IMS 產品的長久生命力就證實了這一點。關系型數據庫已經超越了持久性存儲設備的角色，它們還解決了上述層次數據庫的兩個缺點。關系型數據庫的主要特點有：
　　
　　扁平的層次結構（Flattened hierarchy）：關系數據庫以表的形式來表示數據。所有的表都處于同一層次。這意味著所有的數據都可以直接進行訪問。再回過頭來看上文中的銀行示例，我們可以直接訪問所有帳戶，并且找到屬于指定客戶的記錄，而不必管其帳戶屬于哪個部門或區域。
　　
　　邏輯記錄：表中的列是通過列名而非記錄偏移量來訪問的。操作中只會使用指定的列。這樣一來，應用程序可以獨立于數

上一篇：利用WebLogic的POOL連接數據庫

下一篇：JAVA中通過JDBC訪問MS SQL Server2000的常見問題