EJB的體系結構是J2EE的基礎和核心，J2EE定義了整個標准的應用開發體系結構和一個部署環境，基於EJB的框架一度成為人們開發Java企業應用的首選。隨著Java開源項目陣營的發展壯大， 一些基於POJOs(Plan Old Java Objects)的開源框架被越來越廣泛地引入到Java企業應用的開發中來。根據復雜程度人們習慣把前者稱為重量級框架，把後者稱為輕量級框架。Java企業應用框架一般被劃分為三個層次：表現層、業務邏輯組件層和持久層。本文主要對目前企業應用對應於這三個層次的兩種類型的流行框架進行了細節比較，最後針對Java企業應用的系統框架選擇提出作者的觀點。
兩種類型框架概述
1、基於EJB的重量級框架
由於 EJB容器能夠很好的處理系統性能、事務機制、安全訪問權限以及分布式運算等問題，基於EJB框架進行開發能保證企業應用平滑發展，而不是發展到一種規模就重新更換一套軟件系統，且可以保證開發人員將大部份精力集中在業務邏輯的開發上。采用EJB框架開發的企業應用具有必須繼承或依賴EJB容器的特點。EJB充分考慮到了頂級大型項目的需求，使用它幾乎能解決企業級應用涉及到的所有問題，相應的基於EJB框架也是一個功能復雜的重量級框架。
J2EE1.4標准規定的EJB 2.1框架缺少設計且實現起來有些過於復雜。當前J2EE5.0的新規范提出的EJB 3.0的目標就是簡化開發[1]，借鑒了一些基於POJO的思想，它相對於EJB2.1中兩個重要的變化分別是：一是使用了Java5中的程序注釋工具，注釋取代了過多的XML配置文件並且消除了嚴格組件模型需求；二是采用了基於Hibernate和TopLink思想的O/R Mapping模型。
J2EE5.0的新規范中定義企業應用三個層次的標准實現為：表現層采用JSF（Java Server Face），JSF的開發流程的核心是事件驅動，組件和標簽的封裝程度非常高，很多典型應用已經不需要開發者去處理http。整個過程是通過IoC(依賴注入)[2]來實現的；業務組件層采用EJB3.0的Session Bean。EJB3.0允許開發者使用藕合松散的組件來開發應用。這些組件通過自己發布的商業接口來耦合，不必像EJB 2.1規范定義的那樣一個Bean必須遵守的嚴格的組件模型，每一個EJB類必須從某一種抽象類中繼承，並為容器提供了回調的鉤子；持久層采用EJB3.0實體Bean持久化模型，吸收了Hibernate的一些思想采用O/R Mapping模式， EJBQL也有許多重要的改變。
2、基於POJOs的輕量級框架
在基於POJOs輕量級框架上開發的應用程序無需依賴於EJB容器可獨立運行，對應於Java企業應用三個層次的輕量級框架技術分別都得到了一定的發展，這三個層次流行的框架如下：
目前比較流行的開源表現層框架主要有Struts和Tapestry。Tapestry與Struts應用框架不同的是，它是基於組件，而不是面向腳本語言（比如JSP和Velocity）的，組件是由一個定義文件(以XML的格式)、一個Html模板、一個JAVA類構成的；業務組件層輕量級解決方案也不少，包括Spring、Hivemind等。但是目前使用最為廣泛的還是Spring框架，Spring框架是一個基於IoC和AOP（面向方面編程）[3]的構架。采用IoC使得它可以很容易的實現bean的裝配，提供了簡潔的AOP並據此實現事務管理等，但是它不具備處理應用分布式的能力。Spring的核心要點是：支持不綁定到特定J2EE服務的可重用業務和數據訪問對象。這樣的對象可以在不同J2EE環境（Web或EJB）、獨立應用程序、測試環境之間重用；持久層框主要有Hibernate和各種JDO產品，以及iBATIS。Hibernate是一個開源的O/R Mapping框架，它對JDBC進行了非常輕量級的對象封裝，可以應用在任何使用JDBC的場合，可以在應用EJB的J2EE框架中取代CMP，完成數據持久化的重任。iBATIS是一個簡易的SQL Map工具，它是將手工編寫的在XML配置文件中的SQL語句映射成Java對象。
對應於三個層次的框架比較
1、表現層框架比較
MVC設計模式不再是某一種表現層框架的特點而是這幾種框架的共性。Struts框架由於出現時間早，所以使用相對廣泛，它的社區非常活躍，很容易找到很多現成的開源功能標簽以供使用以及樣例程序可供參考。但是它的組件在頁面中顯示的粗粒度，以及框架類的限制在很多情況下會表現得過於死板，給表示層的開發會帶來一些額外的代碼開銷。JSF在很大程度上類似Struts，只是JSF的組件概念沒有象Struts那樣必須繼承ActionForm的限制，JSF在事件粒度上要比Struts細膩。JSF有的另外一個優勢就是其身後有Sun公司和其他的一些大公司的支持。Tapestry是一個完全組件的框架，Tapestry的組件可以被套嵌並包裹其它組件，因此可以組合形成一個更大的組件或邏輯頁面。組件的行為模式為Web頁面編程提供了很大的方便，事件處理也方便很多。所以，如果做一個對頁面要求靈活度相當高的系統就可以考慮選用Tapestry。
表1 三種框架的表現層功能技術細節比較
2、業務組件層框架比較
EJB 2.1框架有些過於復雜了，有如下缺點：① EJB模型需要建立許多組件接口和實現許多不必要的回滾方法；②EJB的部署描述復雜而容易出錯；③開發人員不能脫離EJB容器測試。對於以上缺點JCP (Java Community Process)制訂的EJB3.0標准框架做了相應的改進，該框架為所有主要的J2EE廠商支持。EJB3.0和Spring兩個框架結構都有一個共同核心設計理念：將中間件服務傳遞給耦合松散的POJOs。
EJB3.0框架與應用服務器高度整合，服務整合代碼也包裝在一個標准接口後面。EJB框架一方面有成熟的EJB容器支持，基於EJB框架的企業應用性能優良；另一方面EJB容器設計因為考慮了多方面的功能，所以在其內核上總是會顯得臃腫，這也是一種重量表現。不需要的東西存在肯定會影響效率，EJB不能根據項目需求對EJB整體包括EJB容器進行可配置式的切割。
Spring框架處於應用服務器和服務庫的上方，服務整合的代碼屬於框架，並暴露於應用開發者。它與應用服務器整合的能力相對EJB3.0要弱。但是Spring框架模塊的可分離配置體現了它優於EJB3.0的靈活性。
3、持久層框架比較
容器管理持久性（CMP）是對EJB中Entity Bean進行持久性管理的方式。EJB2.1 持久性模型過於復雜並且存在基礎缺陷[3]。EJB3.0持久層針對EJB2.1的缺陷做了相應改進，采用與Hibernate類似的機制。
Hibernate相對而言其基本優勢如下：①Hibernate 使用 Java 反射機制而不是字節碼增強程序來實現透明性；②Hibernate的使用簡單；③映射的靈活性很出色，它支持各種關系數據庫，從一對一到多對多的各種復雜關系。Hibernate 也有一些缺點，它限制所使用的對象模型 (例如，一個持久性類不能映射到多個表)。
使用iBATIS提供的O/R Mapping機制，對業務邏輯實現人員而言，面對的是純粹的Java對象，這一層與通過Hibernate 實現O/R Mapping 而言基本一致，而對於具體的數據操作，Hibernate 會自動生成SQL 語句，而iBATIS則要求開發者編寫具體的SQL 語句。相對Hibernate等 “全自動”O/R Mapping機制而言，iBATIS以SQL開發的工作量和數據庫移植性上的讓步，為系統設計提供了更大的自由空間。作為“全自動”ORM 實現的一種有益補充，iBATIS的出現顯得別具意義。
企業應用系統框架選擇
設計和性能是實際框架選擇的兩個基本點，善於平衡才是框架選擇的主要宗旨。輕量級框架和重量級框架解決問題的側重點是不同的。
輕量級框架側重於減小開發的復雜度，相應的它的處理能力便有所減弱（如事務功能弱、不具備分布式處理能力），比較適用於開發中小型企業應用。采用輕量框架一方面因為盡可能的采用基於POJOs的方法進行開發，使應用不依賴於任何容器，這可以提高開發調試效率；另一方面輕量級框架多數是開源項目，開源社區提供了良好的設計和許多快速構建工具以及大量現成可供參考的開源代碼，這有利於項目的快速開發。例如目前Tomcat+Spring+Hibernate已經成為許多開發者開發J2EE中小型企業應用偏愛的一種架構選擇。隨著可供選擇的框架層出不窮，開發者可以根據需要對應於企業應用三個層次的輕量級框架選擇，本文第2節的內容可供選擇參考。
而作為重量級框架EJB框架則強調高可伸縮性，適合與開發大型企業應用。在EJB體系結構中，一切與基礎結構服務相關的問題和底層分配問題都由應用程序容器或服務器來處理，且EJB容器通過減少數據庫訪問次數以及分布式處理等方式提供了專門的系統性能解決方案，能夠充分解決系統性能問題。
輕量級框架的產生並非是對重量級框架的否定，甚至在某種程度上可以說二者是互補的。輕量級框架在努力發展以開發具有更強大，功能更完備的企業應用；而新的EJB規范EJB3.0則在努力簡化J2EE的使用以使得EJB不僅僅是擅長處理大型企業系統，也利用開發中小型系統，這也是EJB輕量化的一種努力。對於大型企業應用以及將來可能涉及到能力擴展的中小型應用采用結合使用輕量級框架和重量級框架也不失為一種較好的解決方案。
總結
目前適用Java企業應用的系統框架可謂百花齊放，各種框架都有長短，選擇應用系統框架時不可盲目的追求流行，首先需要明確所要實現的應用系統的系統處理能力需求，然後在熟悉比較各種框架細節的基礎上從設計以及開發效率方面進行考慮。本文旨在為系統框架選擇提供一個參考，限於篇幅本文只對其中的幾種框架做了比較，開發者可以根據需要對更多其他框架細節進行比較。
