Oracle+BEA 后的 ESB

前几天才刚闭幕的 Oracle OpenWorld 盛会中，Fusion Middleware 融合中间件产品部门的老大 -- 全球资深副总 Thomas Kurian 在 keynote 演讲中，突出一个重点 -- 在完成整并 BEA 产品之后，Oracle 中间件在针对开放标准支持方面，更为全面而完整，可说居于业界领先的地位；包括对 JavaEE 5.0 和 JAX 一系列 XML API 的支持。此外针对 SOA 相关标准方面，则包括了 WS-ReliableMessaging，WS-Security 和 WS-Addressing，以及（国内许多朋友持续关注，）目前正在 OASIS 进行标准化过程的 SCA（Service Component Architecture；服务组件架构）。

说到这儿，不禁想起，过去一阵子和一些客户交流时，发现他们在 Oracle 和 BEA 两家公司正式完成合并之后，关于产品线调整、存废，和路线图等相关问题，非常关注、且仍存有不少疑惑，少部分甚至于有「好像除了 Tuxedo 和 WebLogic 之外，其余的都没留下来」的错误印象。事实上，除了应用服务器和交易中间件之外，在 SOA 和 BPM 的领域，原本两家公司的产品，便有很高的互补性；换句话说，此次产品线的调整和未来发展路线图的规划，不管对原本是 Oracle 或 BEA 的客户来说，所受的影响和冲击，都已降到最低。

就拿上面提到的 SCA 标准来讲，恰可用来说明 Oracle 新的 SOA Suite 套件中的 ESB 部件的发展方向。原本 Oracle 的 ESB 产品和 BEA 的 AquaLogic Service Bus (ALSB)，都相当重视对 SCA 规范的支持，但先前各自的侧重点和优先级，有所不同 -- Oracle 将重点放在以 ESB 为工具，做服务组装、编制、打包这方面（这可以从去年早在宣布收购 BEA 之前即发布的 11g beta 版 ESB 中即可看出。至于原来的 ALSB 和整个 AquaLogic 产品线，则选择优先实现围绕以企业资产库产品（ALER; 现已更名为 Oracle Enterprise Repository）为中心的 SCA 视图，方便 SOA 架构师检视服务间的组合、调用关系。现在两家的产品合并之后，恰好两相互补，在 SCA 支持上，不但可基于图形化界面对服务进行组装，更可配合资产库，达到 SOA 全生命周期的监管和治理 (governance)。

不管是原来的 Oracle ESB (OESB)，或是原名 ALSB 的 Oracle Service Bus (OSB)，二者都继续保持战略性产品的地位。在明年 11g 版本正式推出时，除了计划将继续长期支持目前版本中，客户已经在使用的绝大多数功能之外，同样重要的是，将二者整合为更紧密的单一化产品。

在 SCA 的部分，如上所述，功能恰好互补、不重叠。除此之外，在服务路由、调度、编制，和异构连接协议（Web services, FTP, MQ, Socket, SMTP, JDBC...）支持方面，以 OSB 为主。格式转换方面，OESB 的基于 XSLT 的转换将继续长期支持，而 OSB 上基于 XQuery 的转换，包括图形映射界面，由于更为先进（例如能处理 XSLT 做不到的一变多、将单个消息拆成多份），是推荐客户今后尽量采用的方式。

工具界面方面，将本着过去的做法和产品策略，采用基于浏览器、基于 Web 的简易图形化界面，使 ESB 的主要使用对象 -- 负责服务、IT 运营的人员（而非开发人员），不需要先熟悉 Eclipse 或 JDeveloper 等 IDE 工具，不需要具备编程技能，便可快速上手，在 ESB 上进行各种设置的操作。