隨著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的遠程調用方法，其優勢并不明顯。

@Stateless
@Remote
@Local
@WebService(endpointInterface = "jfox.test.ejb3.webservice.Calculator")
public class CalculatorBean implements CalculatorRemote, CalculatorLocal {

    public int add(int x, int y) {
        return x + y;
    }

    public int subtract(int x, int y) {
        return x - y;
    }

}

4.6 集成第三方框架

如果需要集成第三方框架的時候，估計您需要Spring了，當然前提是Spring已經給出很好的集成方案；而如果采用EJB，則需要視特定的應用 服務器了，推薦當類庫來用，或者使用context listener來啟動，是在不行，只能基于特定的應用服務器來進行集成，一般來說，應用服務器均提供了JMX集成能力。

5. 總結

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

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

原文地址：http://www.infoq.com/cn/articles/ejb3-spring-compare
附：Groovy輕松入門——Grails實戰之GORM篇