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

2019-11-18 12:28:19

字體：大中小

來源：轉載

供稿：網友

　　IBM ORDBMS 數據庫提供了大量功能，可以簡化軟件開發，減少硬件需求，以及加快進入市場的步伐。您必須在設計中善加利用，以便從中受益。IBM ORDBMS 不僅僅是一個持久性存儲器，更是一條提高您生產率和效率的路徑。
　　
　　非同小可的對象危機
　　
　　理論上，以及在許多實際案例中，對于持久對象的操作需要實例化該對象，對其進行操作，以及與持久性存儲器保持同步。這就導致了容器治理的持久性以及獨立于數據庫的思想：“使用容器治理的持久性的好處是，實體 bean 可以在邏輯上獨立于存儲該實體的數據源?！?br />　　
　　該規范還提到數據源可以是關系型的，也可以是非關系型的，如 IMS。當然還可以是面向對象的數據庫。任何修改容器治理 bean 的交互都需要與該數據源保持同步，以確保實體 bean 的一致視圖。對 EnterPRise javaBean（EJB）使用 chatty 接口會顯著地增加數據庫的交互量，從而可能導致性能問題。
　　
　　“每次實例化一個對象”的中心思想有可能會引起性能和容量問題。該問題不是僅限于容器治理的實體 bean 的使用中，而是普遍存在于面向對象方法中。讓我們用一個簡單的示例來加以說明。假設有一家專門從事貸款發放的大型銀行。它遍及多個區域，每個區域包括幾十甚至上百家支行。
　　　 J2EE 與 IBM 對象-關系數據庫系列連載三（圖一）

　　圖 5. 銀行貸款機構
　　
　　圖 5 說明該銀行對應多個區域，每個區域都有多個支行，而每個支行又進行多項貸款。它還顯示我們可以獲得不同種類的貸款。
　　
　　假如該銀行需要獲得一份清單，列出那些在貸款中承擔了過高風險的支行，它就會按區域來收集該清單。每個區域將搜索其支行，找到那些風險過高的。而支行本身必須查詢每一項貸款的風險和貸款額，用以計算該支行的平均風險。
　　
　　以下是一種適宜的對象方式：每個對象封裝自身的信息和處理。支行要獲得貸款風險的惟一方法就是向該貸款查詢這一信息。該方式比較合理，因為它消除了對象類型之間的緊密耦合。對象間的通信取決于定義良好的接口。只要該接口保持不變，就可以修改其實現，且不影響整個系統。
　　
　　本例中，假如我們考慮：該銀行遍及 10 個區域，每個區域有 100 家支行，而每家支行又有 10,000 份貸款，我們總共創建了 1000 萬多個對象來響應該查詢。要求每份貸款返回兩個值：風險級別和貸款額。在區域和支行之間的通信中，這會在兩個對象之間傳遞超過 2000 萬條消息。最后從內存中刪除這些對象需要進行額外處理。
　　
　　所使用的數目（10/100/10,000）絲毫不過分，我們絕對可以想像將生成更大數量級對象的系統。這很輕易成為一個性能以及容量（例如內存）問題。若通過給應用程序服務器增加節點來解決該問題，非但解決不了，反而會增加復雜性。
　　
　　通過利用 DB2 和 IDS 等對象-關系數據庫的優點，即使無法消除該問題，也可以有所緩解。請記住，大多數面向對象人員僅僅將數據庫看作持久性存儲器。他們習慣于將所有處理放在對象的代碼中完成，事后才添加數據庫。
　　
　　假如考慮面向對象是何時成為主流的，我們就可以設想，現在絕大多數 30 出頭或更年輕的程序員已經被練習成以這種方式來思考了。由于數據庫僅僅用于“持久保存”對象以及檢索它，所以系統開銷最小的數據庫在該模型中就占有優勢。這會有利于層次、網絡和對象數據庫。而對象-關系型的數據庫可以完成比持久保存對象多得多的功能，卻成為永遠不被啟動的大引擎。這就好比是在一場用賽車對抗自行車的比賽中，卻不答應您發動引擎一樣。
　　
　　讓我們來解釋一下：面向對象方法是優秀的。問題在于許多架構師和開發人員視野過于狹隘，不知道可以選擇將處理置于何處。這一選擇結果會影響設計，并且可以帶來重大性能影響。利用 ORDBMS 的優點可以簡化設計，以及極大地提高結果系統的性能。這相當于加快進入市場的步伐，以及降低開發和維護的成本。更快的結果還可以帶來重要的商業優勢。
　　
　　數據庫獨立性
　　
　　我在前面已提到 J2EE 通過促進數據庫獨立性來提高應用程序的可移植性。并且還進一步提到可以是任何類型的數據庫：關系（對象-關系）或非關系的。這是整個 J2EE 體系結構的一個美好目標，但在構建商業應用程序中卻是一種十分危險的方法。
　　
　　商業應用程序的目標應該是提供對抗競爭者的商業優勢，而非可移植性?？梢浦残允且粋€次要目標。假如需要進行移植，可以將不可移植的部分隔離起來，以便限制所需的工作。我們需要以盡可能最低的成本獲得盡可能快的響應。假如您針對移植性進行設計，就要設計最底層的功能，從而放棄所有優勢。這就像雇主拒絕雇用一個高度稱職的人，因為怕他某一天離開，而下一任雇員的能力可能遠遠不及。按照該邏輯，我們應該雇用最無能的人。否則的話，我們應該確保限制雇員對公司的貢獻，這樣，假如我們哪天必須用一個遜色一些的人來接替他時，就不會感到失望。期望越多，您將得到越多。而期望越少，您得到的也會隨著時間越來越少。
　　
　　這同樣也適用于企業應用程序。您應該權衡您的數據庫系統的所有功能，并且對于能夠帶來商業優勢的功能善加利用。您可以在設計中隔離數據庫的交互，以便當您偶然必須遷移到另一數據庫時，就只需要完成有限的移植工作。由于數據庫的競爭十分激烈，所以，很可能您現在計劃使用的獨特的新功能將來會出現在某個競爭對手的數據庫中?；蛘?，在數據庫供給商為爭取您的業務，協商將如何補償其缺點時，這可能成為其中的一個缺點。因此，設計要謹慎，但也要贏得成功。
　　
　　J2EE 復雜性
　　
　　J2EE 具有許多好處，有助于商業應用程序的開發。它們包括平臺獨立性、組件架構、多層應用程序模型、統一的安全模式以及一個豐富的標準集合，這些標準涉及事務控制、數據庫訪問和消息傳遞等領域。實際上，J2EE 在一個架構下集成了過去 50 年左右軟件中所取得的進展。這也付出了一定的代價：復雜性。
　　
　　盡管 WebSphere Studio application Developer 等工具明顯地簡化了開發，而且 WebSphere Studio Application Developer 治理控制臺提供了控制，在啟動大型項目之前，我們還是必須確保已經具備了適當的專業知識。最有效的方法就是培訓與聘請專家顧問相結合。
　　
　　同樣重要的是，要具有一支包括了各個領域專家的綜合隊伍。在項目啟動之前，要將這支隊伍聚集在一起。例如，數據庫治理員（DBA）和 SQL 專家應該從一開始就一起討論將如何使用不同的對象。讓我們用一個示例來加以說明。
　　
　　從 DICOM 對象之間的關系。我們看到，每一種類型的 DICOMData 都可以包含許多其他的 DICOMData 對象。我們可以通過標準的關系方法或使用新的數據類型，在數據庫中表示該層次結構關系。一個數據元素是由一個標簽（tag）和一個值表示。存在不同類型的值，如字符串、日期（date）、小數（decimal）等一個值還可以具有重復字段。一個 DICOMData 對象有可能包含幾百種不同的數據元素。但實際上，數目要少得多。
　　
　　將一個 DICOMData 對象表示為一大行幾乎為空的數據元素既不實際，也不可能。那么，我們可以將 DICOMData 對象表示為 DICOM 對象本身與數據元素之間的關系。第一種方法是為每一種類型的數據元素預備一個數據元素表。這會產生 23 個表，而且檢索一個 DICOMData 對象要連接 24 個表。其他的方法可能答應我們將 23 個表縮減為一個。即便如此，通過關系型數據庫來存儲和檢索 DICOMData 對象也要付出昂貴的代價。
　　
　　假如數據庫專家恰好從一開始就參與進來了，那么就可以討論這些問題，并可以揭示那些使實現更加輕易的新信息。結果顯示每種類型的 DICOMData 對象中只有少數元素將用于搜索。這就答應我們表示 DICOMData 對象中的少量值，并且將所有其他的數據元素組合成一個大型對象列。在存儲和檢索 DICOMData 對象時，這帶來了顯著的性能提高。
　　
　　在前一小節中，我們討論了通過向每個支行查詢貸款上所承擔的平均風險度導致的對象爆炸（見圖 5）。DB2 UDB 和 IDS 的對象-關系功能答應我們擴展數據庫功能，以便在數據庫中包含風險計算函數。那么，我們可以使用存儲過程或用戶定義的聚集來計算每個支行的平均風險。我們甚至可以添加條件，其中定義了不能接受的風險級別，并且規定只檢索處于過高風險中的支行清單。結果帶來了顯著的性能增長，因為我們不必實例化一百萬個對象，并且避免了對象之間的多數消息傳遞。在對象人員看到了許多對象創建和通信的地方，數據庫人員可以找到直接提供對策的辦法。在恰當的地方進行處理將提供更簡單、更高效的解決方案。
　　
　　J2EE 的其他方面也增加了它的復雜性。這包括牽涉共享 EJB 的多線程環境。您如何共享 EJB 呢？在一次更新中又如何協調多個 EJB 呢？您的代碼是可重入的，還是設置必須鎖定的臨界區呢？這將導致許多問題，如數據完整性、鎖定策略以及數據庫人員所熟知的一些問題。
　　
　　那么，存在 EJB 訪問的性能問題，您需要以怎樣的粒度進行才能獲得高性能。您還必須確定如何監控應用程序以找到性能瓶頸。
　　
　　J2EE 環境在開發和運行企業應用程序中表現極佳。但由于其復雜性，不宜濫用。假如希望項目取得成功，您就要在初期組織好一支合適的專家隊伍來共同完成。
　　
　　尋求解決方案本文前面所提出的問題沒有理想的解決方案。要從正確的培訓抓起，這樣您才能充分使用解決方案的所有組件。其中可能包括在 Web 瀏覽器中使用 applet、中間件當中的合理設計、以及利用數據庫系統的優點。
　　 J2EE 與 IBM 對象-關系數據庫系列連載三（圖二）