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