艾伯特.愛因斯坦曾經說過：“一切都應該盡可能地簡單，但是不能更簡單。”確實如此，簡化一門理論的基本假設，使我們可以專注於真正關鍵的地方，這正是一直以來對科學真理的追求。企業軟件開發同樣如此。
提供一個將復雜的事物（例如，事務、安全或持久性）對開發者進行隱藏的應用框架是簡化企業軟件開發的關鍵。一個設計良好的框架可以提高代碼重用率、開發者的生產力及軟件的質量。然而，現有J2EE1.4的EJB2.1框架被普遍認為設計差，且過於復雜。不滿於EJB2.1的框架結構，Java開發者嘗試了各種各樣的中間件服務傳遞方法。最引人注目的是，以下兩個框架引起了開發者極大興趣並得到了大量正面的反饋。他們以未來企業Java應用所選框架的姿態展現。
Spring框架雖然很流行但並不是一個標准的開源框架。它主要由Interface21 Inc開發和控制。Spring框架結構是基於依賴注入(Dependency Injection (DI))的設計模式。它可以獨立或在現有的應用服務器上運行，而且大量地使用了XML配置文件
EJB3.0是由Java Community Process (JCP)制訂的標准框架，為所有主要的J2EE廠商支持。JBoss已經提供了試用版EJB3.0標准的開源或商業性質實現。EJB3.0充分利用了Java的注釋
這兩個框架結構都有一個共同核心設計理念：將中間件服務傳遞給耦合松散的POJOS (Plain Old Java Objects, 簡單潔淨Java對象)。 這樣的框架利用截取執行上下文或在運行時將服務對象注入POJO來把應用服務“纏繞”到POJO。POJO本身並不關心這種“纏繞”，對這種框架結構也沒有什麼依賴。因此，開發者可專注於業務邏輯和脫離框架的POJO單元測試。除此之外， 由於POJO並不須要繼承框架的類或實現其接口，開發者能夠極其靈活地搭建繼承結構和建造應用。
然而，在擁有同一理念的同時，兩個框架結構使用不同的方式來傳遞POJO服務。許多書籍或文章都將Spring 或EJB3.0和EJB2.1做了比較，但是對Spring 和EJB3.0的比較並沒有仔細研究過。在本文中，我將對Srping和EJB3.0框架背後的關鍵不同處進行考察，並討論其優缺點。本文的觀點也適用於其它更少為人知的框架，因為他們都是對“耦合松散的POJO”的設計。希望這篇文章可以幫助你選擇適合你需求的最好框架。
廠商無關性
開發者選擇Java平台其中最引人注目的理由之一：廠商無關性。EJB3.0正是一套設計為廠商無關的開放性標准。EJB3.0標准為所有企業Java社團裡開源或商業性質廠商所開發和支持。它將開發者與應用服務器實現完全隔離。例如，JBoss的 EJB3.0實現基於Hibernate，Oracle的基於TopLink，但是開發者並不須要學習Hibernate- 或TopLink的具體API來使應用可在Jboss或Oracle上運行。廠商無關性使EJB3.0與現今其它POJO中間件框架區別開來。
但是，正如許多EJB3.0評論家迅速所指出的，在本文撰寫時EJB3.0標准還沒有到達一個最終版本。大概還有一到兩年的時間EJB3.0才能廣泛地為所有主要J2EE廠商所支持。即使你的應用服務器本身不支持EJB3.0，你仍然可以通過下載安裝”內嵌的”EJB3.0產品來運行EJB3.0的應用。例如，JBoss的內嵌EjB3.0是開源產品且可以在任何J2SE5.0兼容的環境運行(例如, 在任何Java服務器上)，此產品正處於軟件測試階段。其它廠商不久也將發布自己的內嵌EJB3.0產品，特別是針對標准中關於數據持久性的部分。
另一方面，Spring一直以來都是非標准的技術，在未來可預知的一段時間內這種情況將持續下去。雖然你可以在任何應用服務器上使用Spring框架，Spring應用會被鎖入在Spring本身和你選擇整合進Spring的具體服務中。
Spring框架是一個開源項目，但同時它有一個XML格式的配置文件和編程接口。當然任何一個非標准的產品都會有這種“鎖入”(lock-in)的情況，並不是Spring特有的。但Spring應用的長期生存能力仍然還得托Spring這個項目的福（或者是Interface21公司，它雇傭了大部分Spring核心開發人員）。除此之外，假如你用到任何一個具體的Spring服務，例如，Spring事務管理器或則Spring MVC，你也會被鎖入到這些API裡。
Spring的應用對終端用戶是不可知的。例如，對數據持久服務，Spring框架兼容不同的DAO和JDBC的模版幫助類，如Hibernate, iBatis, 和 JDO。所以假如你需要為spring應用切換在數據持久化服務（例如從JBDC到Hibernate），你需要修改你的代碼以適合新的模版幫助類。
服務整合
從一個很高的角度上看，Spring框架處於應用服務器和服務庫的上方。服務整合的代碼（如，數據訪問模板和幫助類）屬於框架，並暴露於應用開發者。相反，EJB3.0框架與應用服務器高度整合，服務整合代碼也包裝在一個標准接口後面。
因此，實現EJB3.0的廠商可以大大地優化整體性能和提升開發者的體驗。例如，在JBoss EJB3.0的實現中，當你在用EntityManager持久化一個Entity Bean時，後台的Hibernate會話事務已經自動地幫定到調用方法的JTA 的事務上，在JTA 事務提交的同時Hibernate會話事務也提交了。你甚至可以使用一個簡單的 @PersistenceContext 注釋（稍候例子演示）將EntityManager和它後台的Hibernate事務綁定到一個stateful session bean的應用事務中。在一個會話中應用事務橫跨多個線程，這在事務性網頁應用很有用，例如，多頁面的購物車。
由於高度整合的EJB3.0的框架，使簡單、集成的編程接口成為可能。Oracle EJB3.0框架和其後台的Toplink持久化服務也同樣程度地整合。
另一個EJB3.0整合服務的絕好例子就是集群支持。假如你在一個服務器集群上部署了一個EJB3.0的應用，所有容錯(fail-over)、負載均衡、分布式緩沖和狀態復制都已經自動為應用所獲得可用。後台的集群支持被隱藏在EJB3.0的框架後面，對EJB3.0開發者來說這些都是完全透明不可見的。
在Spring裡，很難優化框架和服務之間的通訊。例如，為了使用Spring裡的聲明事務服務來管理Hibernate事務，你必須顯示地在XML文件中配置Spring TransactionManager和Hibernate SessionFactory對象。Spring必須電顯示地管理橫跨多個HTTP請求的事務。除此之外，沒有別的方法均衡Spring應用裡的集群。
服務組合的彈性
由於Spring的服務整合代碼作為編程接口的一部份暴露在外，應用開發者有按自己需求裝配服務的彈性。這個特點使你能夠組合自己的輕量級應用服務器。Spring的一個普遍用法就是將Tomcat和Hibernate組合在一起支持數據庫驅動的web應用。在這種情況，Spring本身提供事務服務，Hibernat提供持久化服務――這種設置創建了一個袖珍型的應用服務器。
EJB3.0應用服務器典型地不提供這種根據需求任你挑撿服務的彈性空間。大多數時間，你得到的只是一系列包裝好的特性，其中一些你可能根本就不需要。但是如果應用服務器像JBoss一樣提供一個模塊性的內部設計，那麼你可以只取其中一部分，而把不必要的部分剝去。在任何情況，去自定義一個功能強大的應用服務器是沒有什麼價值的。
當然，假如應用已經超過單個點，那麼你應該加入常用服務器上的服務，例如，資源池（resource pooling），消息隊列（message queuing）和集群（clustering）。就總體的資源消耗而言，Spring解決方法和其他EJB3.0解決方法一樣是重量級的。
在Spring框架裡，具有彈性的服務裝配使得將虛擬對象而不是真正的業務對象綁定到應用中做脫離容器的單元測試更簡單。在EJB3.0應用中，大多數組件都是簡單POJO，他們可以很容易地在容器外被測試。但是對於與容器服務相關的對象（例如持久化實實體管理器EntityManager）建議用容器內測試。因為這樣會比虛擬對象測試方法更簡單，強壯及准確。
XML Vs.注解
從應用開發者的觀點上來看，Spring的編程開發接口主要基於XML配置文件而EJB3.0廣泛地應用Java注解。XML可以表達復雜的關系，但是它也冗長且不夠健壯；注解簡單明了，但是很難在注解裡表達復雜或繼承性的關系。
Spring選擇XML或EJB3.0選擇注解都是有他們兩者框架後的體系結構決定的。因為注解只能容納很少的配置信息，只有整合前的框架（重頭戲都在框架裡）才可以把廣泛地使用注解作為配置選擇。正如我們所討論過的，EJB3.0剛好符合這個要求，而Spring作為一個普通的DI框架並不符合。
當然，EJB3.0和Spring都相互取長補短，在某種程度上他們都支持XML和注解。例如，在EJB3.0中，XML配置文件作為一個可選的重載機制來改變注解的默認行為。注解也可以配置一些Spring服務。
通過例子是學習XML和注解方式之間差異的最好方法。在下面幾個環節裡，讓我們來看看Spring和EJB3.0是怎樣提供關鍵服務給應用的。
聲明性服務
Spring和EJB3.0都將運行時服務（例如，事務、安全、日志和配置服務）綁定到應用。因為這些服務於應用的業務邏輯是沒有直接聯系，他們只是由應用本身管理。換句話說，這些服務在運行時由容器透明地應用到應用中。開發者或是管理者配置容器，准確地告訴它什麼時候怎樣應用這些服務。
EJB3.0運用Java注解來配置聲明性服務，而Sring使用XML配置文件。在大多數情況下，EJB3.0注解方式對於這種服務更簡單明了。這裡有一個在EJB3.0中將事務服務運用到POJO的例子。
public class Foo { @TransactionAttribute(TransactionAttributeType.REQUIRED) public bar () { // do something ... } }
你也可以為一個代碼段聲明多個屬性，應用多個服務。這是一個在EJB3.0裡同時應用事務和安全服務到POJO的例子。
@SecurityDomain("other")public class Foo { @RolesAllowed({"managers"}) @Tran
