在我Support過的許多BEA客戶里面，80%依然使用EJB2，20%已經開始使用Spring，但幾乎沒有看到有真實的大客戶在關鍵系統中使用 EJB3，EJB3的技術其實已經很成熟，在分布式能力上，WebLogic EJB2.0容器經過10年的改進，在分布式性能以及穩定性方面，已經相當成熟，強大的JMX支持亦為WebLogic贏得更多的商業用戶。盡管EJB2 的復雜性，但BEA畢竟將這些復雜性降至最低，比如通過WebLogic的Ant Task擴展，weblogic.ejb.GenericSessionBean等等，但這一切依然沒有解決無接口不OO的尷尬局面（EJB3做到了真正的POJO化，即ReviewManagerBean是implements ReviewService，POJOer舒了一口氣），且IDE工具的重構也更加容易直觀。
EJB3的Annotation改善了POJOer的Coding狀況，卻沒有增加EJB容器廠家很多的工作量。各個中間件廠商依然使用他們原有的EJB CodeBase作為EJB3的基礎，因此，我們完全信任EJB3的穩定性和可靠性。
在中間件廠家的角度，EJB3其實可以分為兩個部分：
A1，Session Bean、MDB領域【具有分布式容器依賴性】
A2，持久層實現（JPA）【對分布式容器無依賴性】
在 A1領域，中間件廠家更關注于屬于容器的范疇，即比如為笨重的EJB2容器添加DI能力，無論是Annotation還是XML描述符，都額外簡單；你可能有疑問，這些DI是否會增加容器設計的復雜性嗎? 顯然不會。據我所知，為了支持EJB3后，WebLogic容器的重構了大量的EJB2代碼，從weblogic.ejb20抽出了大量的EJB內部接口到weblogic.ejb Package去，且僅僅改寫了部分的內部類，于是，我們會看到內核中包含了一些beaninfo.isEjb3的條件分支的判斷。
至于MDB，WebLogic 11g之后會融合更強的Oracle JMS Provider實現，性能和可靠性絕對會讓人耳目一新。
A2，很久以前，WebLogic明顯花了很大的力氣去實現Entity Bean，它太難用了，幾乎毫無學習的必要，KODO隨后被BEA收購，并派生一個OpenJPA的開源項目（輸給了Oracle的TopLink Essential開源項目），Oracle收購BEA之后，可能會將TopLink重新融入到WebLogic默認實現中，之前使用KODO結合 Spring的被發現很多運行時問題(困擾了我很久，后來索性換成TopLink Essential)，可以讓開發者大為放心。有著10多年歷史、業界領先的TopLink作為WebLogic EJB容器的一部分（JPA Provider方式)，它的穩定性也是有目共睹的；另外，要提到的是，TopLink包含了Runtime監控的特性，Oracle移植TopLink 到Weblogic11g的時候亦會包含它為OC4J提供的TopLink Runtime Monitor特性，這些特性是容器依賴的，但并不是必須。
對 EJB3的客戶而言，Codebase的穩定性是非常重要的，從EJB2->EJB3，WebLogic并沒有改變太多的EJB核心設計，從而保證了EJB2客戶遷移到EJB3所帶來的可靠性；另外，持久層方面，從KODO過渡到TopLink，ORM的穩定性和性能亦會有一個不少的飛躍。總之，WebLogic 11g是值得期待的一個強大的EJB3版本。