J2EE平台的資料存取技術

J2EE平台的資料存取技術

J2EE平台的資料存取技術

第三事業群研發工程師 蔡博至

前言
　　如何讓資料庫獨立於程式設計之外的想法，一直以來是設計資料庫應用系統時所追求的目標。
　　原因一，避免因後端資料結構的變動，造成對程式碼的直接影響。
　　原因二，各資料庫都會為了自家產品的最佳化而在標準的ANSI SQL之外再加上特有的語法，如MS SQL server的T-SQL與Oracle的PL/SQL即有些許差異，只要更換後端資料庫，即意味著必須把所有在程式碼內的SQL command都挑出來驗證一番，以期能符合新的資料庫的語法。
　　而這樣的想法，在系統採用物件導向分析設計方法時得到了實現的機會。將資料儲存的機制視為一個獨立於企業邏輯的特定物件，其功能就是能把其他物件透過O/R Mapping的技術存入資料庫，而不同資料庫的語法差異就在這物件內加以處理。而J2EE就是以這樣的概念為基礎，提供出完整的物件導向設計平台的解決之道，所以筆者以為這樣的目標可以試著透過J2EE來實現。

J2EE
　　筆者遇到這問題之初(希望企業邏輯與資料存取的程式碼分離)，是希望能把存取資料的行為圈在一個固定的小圈圈內，只要牽扯到資料存取的問題，只要往那小圈圈內去找一定能找到，而不會漫無目的翻動整個系統的程式碼，在經過與他人討論研究後我們發現J2EE平台上的應用可以提供某些我們想要的功能，且只要我們稍加改變其平台架構便可以為上述問題提供一個解決之道。

　　 J2EE全名為Java 2 Platform, Enterprise Edition，提供一個多層式架構的分散式系統模型開發的平台，且彈性交易控制整合了後端資料庫的存取。
在J2EE的平台上，其元件可被分為四個層如(圖一)：
1. Client-tier：此層元件會在客戶端的機器上被執行，如一些客戶端AP或動態網頁。
2. Web-tier：此層元件會在J2EE Server或Web Server上被執行，一般主要是準備一些組成Client-tier的資料與和下一層Business-tier溝通。
3. Business-tier：此層元件會在J2EE Server上執行，而此層元件所負責的就是如其名一樣負責整的系統的企業邏輯與控制邏輯。
4. Enterprise information system (EIS)-tier：此層主要是將第三層所處理之結果加以儲存，一般被執行在EIS Server，如資料庫伺服器。


圖一

　　有了這樣的平台，我們發現設計者只須把心力放在設計Business-tier上，而前端介面呈現則可以由不具備領域知識(domain knowledge)，但卻富有美感設計的設計師來規劃設計，EIS-tier呢？它真的如我們所需求的，只要我們把Business-tier上的enterprise beans(物件的class等)設計好，J2EE Server會幫你把這些該儲存的資料放到你想放的資料庫去，而你只需要在J2EE Server上對這些enterprise beans和資料庫伺服器稍做設定即可，如果後端資料庫更換成其他廠牌，也只需在設定檔內做調整。
　　然而要讓J2EE Server能管理這些Business-tier的beans，所設計的物件必須繼承特定的(J2EE標準的)物件，這樣的限制令單純的物件開發有些棘手；還有一個最大隱憂就是效能的問題。系統的使用者會覺得此種架構設計出來的系統會比傳統架構設計出來的系統慢。
　　於是乎，軟體的開發者所面臨的問題從原來的需求轉換成效能的問題，一旦有了問題就得要去尋找解決的方法，筆者從網路上找到一個名為Castor計劃提出來的一個概念，來針對由Java語言開發出來的物件做存取控制的一層，即為persistent layer，此層介於原來J2EE平台上Business-tier與EIS-tier間，然而交易控制與存取控制可由設計者自行控制，且persistent layer的植入讓原來在J2EE平台上設計enterprise beans時所遇到的小困難變簡單了，一切好似回歸成原來物件導向設計，Castor計劃把這個工具稱為JDO(Java Data Objects)。

Castor JDO
　　我們曾對JDO與J2EE模型的兩種架構進行實驗評估。而事實上，以Castor JDO作為persistent layer的雛形中，其針對資料庫的存取比交由J2EE平台控制存取的雛形來得快多了，是快多了。這樣夾著一層persistent layer，我們對於物件的存取更有彈性並迅速，且也可以滿足最原始的需求，支援後端不同資料庫，只要設計撰寫一套程式碼即可。而且這樣的好處還不只於此，如果今天軟體開發者對Castor JDO不滿意可以很簡單的抽換由不同廠商或計劃所提供的JDO。
　　筆者也嚐試著把當初假設的優點加以驗證。由於Castor JDO對於物件內集合屬性無法支援多型，且如果碰上了物件間的巢狀參考(nest reference)與遞迴參考(recursive reference)，會在儲存過程中發生死結(deadlock)。
　　Castor JDO的這些問題筆者也曾嚐試透過自行修改系統或更改O/R Mapping的設定檔來尋求解決之道，但不是讓程式碼繁雜了就是無功而返，於是乎筆者試著尋找替代工具，很幸運的找到了Apache DB計劃中有一個名為Jakarta的子計劃內有個一稱為ObJectRelationalBridge (OJB)的工具。這也是一個可以做O/R Mapping的工具，它可以將物件儲存到關聯式資料庫去，這樣的一個工具正好可以讓我們使用到我們所設計系統的persistent layer。

Jakarta OJB
誠如上述，Jakarta OJB所提供之功能剛好可以適用於persistent layer。而其架構如圖二：


圖二

　　在圖二中的Client-tier可視為＜圖一＞中的Business-tier，因為對OJB而言Business-tier的元件就像他的客戶一樣。而Backends層可以支援的儲存機制除了我們所需要的各種關聯式資料庫外，其也支援了其他異質性的儲存媒體。
　　對於，Jakarta OJB的架構與多種可使用的API在此不多做贅述，然而我們要針對兩種可運用在persistent layer的工具寫了測試程式碼，來測試兩者的功能並比較之。

Castor JDO V.S Jakarta OJB

以下是筆者針對兩者的功能所測試出來的結果：
Castor JDO Jakarta OJB
基本物件新增、刪除、查詢、修改 支援，如果新增一個同樣PK的物件進入資料,則會造成PK重複的錯誤 支援新增一個同樣PK的物件進入資料則不會有PK重複的錯誤,甚至任何錯誤訊息都不會有,但也沒有把物件建入資料庫中.此點要特別注意。
1:1物件參考關係 可新增,修改,但如果刪除參考其他物件的主物件,則被參考的物件不會刪除 可新增,修改,但如果刪除參考其他物件的主物件,則被參考的物件不會刪除.如果設定reference-descriptor element內的auto-delete屬性為true則可以連帶把被參考物件刪除
物件的繼承關係 支援物件繼承時1. 可把繼承相同父物件的多個子物件存在同一個table.2. 可把繼承相同父物件的多個子物件各存在不同的table.3. 可把被繼承的父件的屬性存在自己的table；然後各個子物件個別的屬性也存在其自己的table內。 支援物件繼承時，也支援左述的1，2兩點，但針對第三點而言，其建議運用1:1的物件參考關係。
1:n物件參考關係 支援多種Collection型態，ArrayList、Map、Set等都支援。 除了Map外，其餘都支援，也支援自訂型態的Collection.
n:m物件參考關係 支援同上 支援同上
是否確實支援 Polymorphism Collection (Interface) 不支援 支援
是否確實支援 Polymorphism Collection (Super Class) 不支援 支援
1:1物件參考關係的 Lazy Loading 不支援 支援
是否確實支援 Collection 屬性的 Lazy Loading 只支援Collection型態的屬性，不支援其他如set或map等型態 支援其所能使用之型態。

　　綜觀上面的比較表，我們不難發現大部分的功能Jakarta OJB是比Castor JDO強多了，其中以支援Polymorphism Collection為其優勢，而且它沒有Castor JDO可能造成的deadlock情形。

結語
　　從AP的開發平台之發展，我們看到了前端介面與後端資料庫的部分從原來必須在設計時就被涵蓋其中的設計概念，漸漸的淡出。但是這不代表前端與後端的部份就不再重要，筆者的看法覺得它們依舊是整個系統的門面與後援，所以才更需要分開被設計與規劃。而因為這樣的思維才會有目前的系統架構，透過一層persistent layer來隔開資料儲存與運算邏輯間的關係。
　　那麼大家一定會疑問，這樣的架構集大部分的優點於一身，如可以支援後端不同儲存機制卻只要一套程式碼；無須下任何SQL command；persistent layer抽換簡單方便；資料存取的交易控制交給J2EE Server；設計者完全不用煩惱資料儲存的問題…等。難道沒有缺點嗎？
　　是有的。就像之前所以提的”效能”。系統設計者往往在設計的過程中不會重視到這個點，但一旦系統開發完成交到使用者手中，問題立刻被反應。如果系統的效能不佳，就算它的架構再漂亮，程式碼再簡潔，在所有人眼中也不過是件沒有實用性的藝術品，可惜的是軟體無法被當藝術品來欣賞與把玩，所以它等同沒有價值可言。於是這樣的問題往往令設計者不敢將資料庫存取的問題交於特定元件來完成，他們寧願用hard code的方法一步一腳印的把SQL commands寫在程式碼內。
　　其實現在的JDO工具都很聰明了，至少本文介紹的兩種工具都做到一定加速存取的機制，如物件的快取(cache)，產生的SQL commands是prepare statement，以及lazy loading的機制，有了這些機制的加持與更趨成熟，這樣的系統架構將不會再被詬病效能不足了。

參考文件
1. J2EE Tutorial，Sun Microsystems 所提供。http://java.sun.com/j2ee/tutorial/1_3-fcs/index.html
2. Castor Project，http://castor.exolab.org/
3. Apache DB Project，http://db.apache.org/ojb/