隨着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市場注入新的活力！