EJB 3.0和Spring在傳遞POJO服務時採用了完全不同的方法，這使得開發者在實施POJO時不得不進行艱難的選擇。
對於POJO的開發，存在着兩種框架EJB 3.0和Spring，這兩個框架組件的核心設計理念是相同的：把中間件服務傳遞給鬆散耦合的簡單舊式Java對象（POJO）。這些框架組件通過在運行時截取執行內容或向POJO注入服務對象，把應用程序服務與POJO捆綁在一起。POJO本身不關心捆綁的過程，並且對框架組件幾乎沒有依賴。其結果是，開發者可以聚焦於業務邏輯，個人可以在沒有框架組件的情況下測試他們的POJO。此外，由於POJO不需要從框架組件中繼承或實現框架組件接口，開發者建立繼承結構和構建應用程序的時候都有高度的靈活性。
但是，儘管兩者的設計理念是相同的，它們傳遞POJO服務時卻採用了完全不同的方法。
注入方式
Spring仍然是依賴XML來注入到POJO的，XML寫起來比較麻煩，雖然流行的IDE都有圖形化的編輯界面，但還是很難操作，同時Spring使用XML來說明配置聲明性服務，也會產生一個冗長的配置文件。這些配置文件必須在運行時才能知道其中的錯誤，哪怕是一個大小寫的問題。因此Spring目前也在考慮如何簡化XML配置文件。
EJB 3.0使用Annotation，這要比Spring簡單明瞭，但其功能也受到一定的限制。Spring基於XML配置的依賴注入語法複雜，但功能卻非常強大。可以將任何一個POJO注入到另一個POJO，包括應用程序中自定義的那些POJO。
鬆散耦合度與服務集成
Spring與應用服務器採取鬆散耦合，作爲Spring設計的核心理念，這樣增強了Spring的靈活性，但同時也增加了開發的複雜度，因爲如此一來，開發者就必須弄清楚Spring對應的應用服務器的。而事實上，這些與應用服務器的關聯代碼對於開發者大都是不必要的，開發者往往只需要關係業務邏輯就可以了。使用Spring的聲明式事務服務來管理Hibernate事務，必須在XML配置文件中明確的配置Spring的事務管理器（TransactionManager）和Hibernate SessionFactory對象。
EJB3.0框架與應用服務器結合較緊密，服務被集成封裝，隱藏在EJB接口後面。因爲EJB3.0本身就是J2EE標準的一部份，因此，它與其他J2EE服務如JCA，JMX都結合的很好。而缺點也正是結合太緊密，不夠靈活。
對Web框架的支持度
Spring在這方面要優於EJB3.0，幾乎所有開源項目都有這個特性——對現有的流行技術支持度都非常好。Spring可以靈活地集成各種Web框架和模板語言，另外自身也提供了相當強大的Spring-MVC框架，而且可以很好的結合spring webflow，webwork，struts等。同時隨着Spring Web Services 1.0正式公佈，Spring對web service開發明顯增強了，這無疑使Spring愛好者開發者更加熱衷於Spring。
EJB3.0標準集成JSF，但JSF目前並不成熟，也沒有得到預期的效果。同時EJB3.0對其他web框架支持也比較差。
開源與標準規範
Spring框架是開源項目，但不是標準的。Spring的接口配置文件描述都是私有的。雖然，Rona 聲稱Spring完全支持可以不使用Spring的特殊專有服務，但是實際情況往往不是這樣的。因此，一旦使用了Spring的特殊服務，那麼就綁定到了Spring框架上了。例如，如果使用它的管理服務，則必須使用相應的Spring私有的API。而且，Spring的發展完全依賴於Spring開源項目，這使得它的支持力度也不夠。
EJB3.0是完全公開的規範標準，它本身是J2EE標準的一部分，因此得到了很多廠商的支持。例如，JBoss在EJB3.0剛出來時，就宣佈其新的版本支持EJB3.0的服務器。這樣基於EJB3.0的程序就可以比較輕鬆地在WebSphere、WebLogic以及JBoss之間進行切換（除非使用了應用服務器提供的專有組件）。