在我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版本。