Spring和EJB3的技術對比

隨着EJB3規範以及支持EJB3的Java EE應用服務器的即將發佈，全新Java EE體系架構的新戰爭將拉開帷幕，在過去3年中如火如荼的Spring佔據了Java EE應用開發基礎平臺的大半江山，面對EJB3和Spring你應該如何選擇呢？

做爲一個架構師，我對EJB是既愛且恨，對Spring又恨又愛，如今咱們來也把這兩大技術體系來作一個全面分析和對比，但願能給你們在進行技術選型時一個更好的參考。

1. 法制 VS 「民主」

EJB規範一直由國際組織JCP來制定，一經經過，即做爲官方標準，且各廠商都會竭盡全力的推進，因此對於企業應用來講，EJB就是法，以EJB爲企業應用的基礎架構暫且稱爲法治；Spring來自開源社區，由衆多的開源軟件開發者參與，逐步造成的一種流行的體系標準，它的設計以IoC(反轉控制)爲核心，提倡所謂的「零」侵入設計原則，這裏暫且稱之爲民主。

支持EJB的應用服務器通常是一個大而全的產品，包括了構建企業應用須要的方方面面，若是須要額外擴展通常不容易，若是對一個應用服務器不滿意的話，那麼能夠且也只能更換整個應用服務器了，好在因爲應用服務器市場百花齊放，從免費到低端再到高端，您能夠任意選擇；Spring從IoC容器發展而來，經過不斷集成AOP、MVC、OR/Mapping以及幾乎您能想到的各項服務而提供完善的企業應用架。對於一個應用，你能夠自由選擇具體的技術框架的實現，SSH就是最經常使用一套組合，然並且不說是否每一個架構師擁有正確選擇的能力，不管如何，最終的選擇在設計之初一旦肯定，要想更換便不那麼容易，你不可能輕鬆的將一個基於Spring + Struts的應用輕鬆的移植到Spring + WebWork，更不能輕鬆的將一個基於Spring + Hibernate的應用輕鬆的移植到Spring + iBatis，因此對於須要長期維護和發展的應用來講，將只能寄但願於你採用的框架都可以很好的發展，而且能在升級的同時保證向前的兼容性。

綜上所述，EJB因爲對於整個世界是標準的，就好像是一部國際法，一旦遵循，全球通用，你能夠比較輕鬆的在WebSphere、WebLogic甚至 JBoss之間進行切換，因此若是選擇EJB，你將在一個」法制」的環境下得到最大的民主；而Spring對於整個世界看似民主的，然而一旦整套架構肯定下來，卻成了專制，猶如美國式的民主，一旦被它征服，就成爲它的專政統治了，想掙脫它的控制可就不那麼容易了，其中的利害，你們細細品味吧。

2. 輕量級組件 VS 輕量級內核 VS 輕量級容器

關於輕量級內核，不論屬實是否，現今的應用服務器都宣稱採用了微內核技術，在此基礎上創建Java EE的各項服務構建成完善的應用服務器；而Spring自己就是一個基於IoC的輕量內核，而後經過集成第三方的服務器來提供完整的架構。

 

EJB組件曾經被認爲是一個重量級的組件，而備受批評，EJB3規範的重要目標就是簡化EJB的開發，提供一個容器管理的輕量級的組件方案。

可是有必要提醒一下，輕量級的組件，並不意味着提供服務的容器是輕量的，不論是EJB2仍是EJB3，應用服務器由於須要管理組件的負責生命週期以及行爲，而且內置提供了各項服務，容器天然是一個重量級的服務；至少如今看來，現有的Application Server提供的容器都還不足夠的輕量，從我的偏好來講，我就很是喜歡JBoss 2.4這個版本，它有我須要的功能，同時又夠簡單，而如今，JBoss 4的啓動速度已經逐漸讓我對它對失去了耐心。

而對於Spring，也有一樣的問題，輕量級的內核，也不意味着整個框架是輕量的，更不意味着基於Spring的整個應用架構是輕量的。對於 Spring，你須要去尋找並粘合各類服務，而後讓他們可以穩定的在一塊兒工做，若是應用對技術的需求較多，伸縮性要求也較高，你就會不斷的在應用服務中加入其餘服務，如：資源池、消息隊列、集羣等。當加入這些後，Spring的解決方案已經和Java EE Application Server解決方案同樣重量級了。

追求簡單、輕量，是每個應用架構的目標，對於企業應用的構建來講，輕量級組件標準+輕量的內核+輕量級的容器，並以此構建輕量級的應用平臺，纔是最終須要的。若是有輕量級的容器出現，將幫助EJB3在企業應用中從新佔據有利的地位。

3. 可管理性與可控性

這個問題對於一次性交付的項目也許不是問題，可是對於質量要求更高、生命週期更長的產品，倒是衡量平臺和架構的重要因素。

基於Spring架構的應用，因爲過度的自由和靈活，隨着項目的進展，逐漸集成的第三方框架愈來愈多，很難保證集成的服務和編寫的組件中有沒有漏洞，甚至相互之間有嚴重的衝突，那麼，掌控整個項目的質量成了難題，光是一頁接一頁的配置文件，就知道從此的維護成本也就隨之增高，回想一下EJB2.0時代的ejb-jar.xml吧；而EJB由於集成的都是標準服務，並且組件模型也是固定的，加之應用服務器通常提供控制檯，用來查看運行時的各項屬性，並可對服務進行實時的管理，顯然比Spring開發的應用可控性更好。

4. 功能性對比

4.1 IoC容器，AOP能力

在IoC的能力Spring要略強一些，可是在EJB3中能夠徹底用Annotation方式進行注入，在開發上要簡單不少，對於一些相對比較固定的注入，採用Annotation更好，而對於一些可能須要常常變更的注入，XML更加靈活，EJB3恰好提供了這樣的兩種解決方案。若是你已經患有XML恐懼症，那麼EJB3無疑將給您以解脫。

同時，EJB3組件中，支持多種方式注入，好比依賴於名稱、接口或者JNDI名，另外還支持使用@PersistenceContext注入 EntityManager，@Resource注入服務器資源，如EJBContext、TimerService等，而一些Annotation已經成爲JDK6的一部分，未來可能直接被JDK支持。

AOP方面，若是您須要完全的AOP，而且在Spring中集成了AspectJ，那麼EJB3天然沒法比擬，可是若是您的項目以夠用爲原則，只須要通常方法攔截意義上的AOP，EJB3提供的各類回調方法應該能夠知足您的要求了。

4.2 事務處理

EJB的看家本領，Spring也經過提供TransactionTemplate以及集成第三方事務處理器來支持JTA，都支持申明式事務，能夠BMT，CMT，但不管如何，移植的器官總也沒有自身長的好吧。

4.3 分佈式能力

通常使用Java EE體系的公司都認爲這是EJB的最大長處，可是實施並不如想象那樣，一來絕大多數都是Web應用，依賴Web提供的分佈式能力已經能夠知足90%的須要了，二來你們基本上都是Web容器和EJB容器總體部署，EJB組件的分佈部署少之又少。固然若是您須要Web層和應用層分開部署，那麼Spring必定不在你的考慮範圍以內了。

4.4 Cluster能力

Cluster也是EJB的傳統優點，可是老師說，可以發揮EJB集羣優點的地方並很少，由於即便項目中採用了EJB，通常也採用Stateless SessionBean，而使用HttpSession Cluster，既然如此，不管EJB仍是Spring，你們都是平等的。固然，若是您正在構建一個大型的應用，對集羣的能力要求很是高，好比須要事務級的Cluster，並且還有分佈式的需求，那麼估計沒有多少因素會讓您考慮Web Server + Spring的架構了。

4.5 Web Services

EJB3中的Web Service和EJB組件集成得如此之好，使用起來再簡單不過了，以下面實例所示，JAX-WS也將逐步成爲Java Web Service事實標準；至於Spring能夠實現各類基於Http的遠程調用方法，其優點並不明顯。

 1 @Stateless
 2 @Remote
 3 @Local
 4 @WebService(endpointInterface = "jfox.test.ejb3.webservice.Calculator")
 5 public class CalculatorBean implements CalculatorRemote, CalculatorLocal {
 6 
 7     public int add(int x, int y) {
 8         return x + y;
 9     }
10 
11     public int subtract(int x, int y) {
12         return x - y;
13     }
14 
15 }

4.6 集成第三方框架

若是須要集成第三方框架的時候，估計您須要Spring了，固然前提是Spring已經給出很好的集成方案；而若是採用EJB，則須要視特定的應用服務器了，推薦當類庫來用，或者使用context listener來啓動，是在不行，只能基於特定的應用服務器來進行集成，通常來講，應用服務器均提供了JMX集成能力。

5. 總結

縱觀人類歷史，官方過於強勢，則必然官逼民反；而民間力量過於強大，社會必將不穩定，這都是咱們不肯看到的，在技術世界裏也同樣。對於EJB3 和Spring這兩種方案，Spring如今處於壓倒性的優點一方，但願EJB3的出現，一來能爲官方挽回一些失去的領地，二來也能繼續引起更多的探討，再也不拘束於一家之言，只有百家爭鳴的環境，才能讓開發人員和架構人員對企業應用的構建認識得更加完善，因此最好的方式是EJB3和Spring互相促進，和諧發展。

期待一個輕量的真正以開發需求爲中心的EJB3應用服務器的出現，爲疲軟的EJB市場注入新的活力！