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