[转帖]从中间件厂商的角度看EJB3标准

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