David.Turing's Blog

Oracle应用服务器战略：
WebLogic+Tuxedo+JRockit将成为Oracle的J2EE服务器的基础设施，Oracle原来的J2EE容器将边缘化。
WebLogic将很快采用Oracle的命名法，下一个版本可能是WebLogic 11gR1，它将融汇Oracle现有的产品特性：

其中，KODO被TopLink替换是意料中事，另外，Oracle认为它Web Service协议栈可能也比BEA的要好，基于这个观点，可以预见，在WS*上面的产品线，尤其是SOA产品线（基于WS*），基本上会以Oracle SOA产品线为主流。

Oracle Portal产品战略:
Oracle的WebCenter无疑是Portal产品战略的核心，WebLogic Portal可能不再依旧风光了，它可能仅仅作为一个轻量级Portal继续存在，对BEA来说，Portal的基本要素，比如内容管理，WebClipping(临时收购回来的Kapow)，搜索引擎(WLP自带的Autonomy也不是BEA自己的，比Lucene还难用，而且还有让人恼火的License限制)，可能在Oracle的产品重组之下变得更加悲观了。
未来的Oracle Portal很明确，它应该会在BEA的WebLogic中间件上运行。

Oracle SOA战略：
Oracle放弃BEA的SOA产品线，并且在中间件的层面上增强它现有的SOA产品体系：

除了BEA的Aqualogic Service Bus(ALSB)能够进入SOA大名单，其他的产品比如ALDSP对做数据业务出身的Oracle来说是太小儿科了，可能被放弃。

Oracle BPM产品战略:
之前业界的猜测是正确的，Oracle还是基本上保留了它自己的BPM的产品线，BEA的Aqualogic BPM对Oracle BPM产品线贡献仅仅是Designer工具：

Oracle的BPEL Process Manager依旧是BPM产品线的战略核心，当然，在收购BEA之前，Oracle已经是BPM领域的领导者(From Gartner)。


Oracle开发工具战略：
Oracle的JDeveloper依然是主角，BEA收购回来M7虽然优秀，但始终没有得到广泛的认同，因此，Workshop Studio最终将作为一个面向现有客户的产品，依旧提供补丁但可能不会再支持新的JavaEE标准，而Oracle JDeveloper将成为Oracle的Sell给新客户，与竞争对手PK的主要产品，所有BEA现有的Eclipse Plugin(包括M7)将会融入此工具，结合Oracle原有的领先的ADF、TopLink以及元数据解决方案，可以预见，JDeveloper会是一个多么强大的工具。
至于BEA以前曾经提交给Apache的Beehive，将会逐渐退出舞台，但近期依然会提供有限度的支持。
原先Workshop Studio绑定销售Adobe Flex Builder策略，可能Oracle不会再继续，未来的用户需要自己安装FlexBuilder。
老的BEA用户应该能够区分WebLogic Workshop和BEA Workshop studio两个产品，这两个产品都会被边缘化。


总结：
这次产品重组的结果，基本符合了之前很多业内IT人士分析预测，在收购案开始的时候，我已经一针见血指出，
Oracle不是冲BEA的SOA而来，而是冲BEA的中间件而来。
这个混沌的JavaEE世界，不管宝马有多少炫耀的功能，车的发动机不能差。
Oracle收购BEA――如何看待J2EE中间件的价值

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

标签： EJB3 Container Technology