IBM的ESB产品

IBM 的 ESB 产品 IBM 有三款 ESB 产品：WebSphere ESB (WESB)，WebSphere Message Broker(WMB)，DataPower。这三款 ESB 产品都提供了 ESB 所必备的特征，但是它们各有侧重，WESB 主要构建与 WebSphere Application Server 之上，侧重于对标准协议和消息的支持，更适合于 J2EE，Web-Service 为主要特征的集成环境；WMB 提供了一个高级的 ESB，它构建于 WebSphere Message Queue 之上，提供了百种以上协议的连接和数据格式的转换机制。Datapower 是一款比较新的 ESB 产品，除了提供必备的 ESB 的特性之外，Datapower 更侧重于安全。众所周知，在 XML 的环境中，安全对于性能的影响是巨大的，Datapower 给企业 ESB 提供了强大的安全保障。下面分别介绍这三款 ESB 产品。 WebSphere ESB 从图 4 中可以看出 ESB 构建与 WAS ND 之上，它使用了 WAS ND 及 WAS 对于安全，用户注册表，事务，消息引擎的支持，在其之上增加了对服务集成、消息流处理、建模以及 ESB 编程模型的支持等等。从图中还可以看出 WebSphere Process Server 是构建与 WESB 之上，并扩展了服务编排和流程管理方面的支持。 图 4. WESB 在 WAS 产品线的位置 下面介绍在 WESB 上实现一个 SOA ESB 解决方案上的以下九个方面的特点，这九个方面的特点来源于上文中介绍的 ESB 的特性，或者特性的细化： 消息转换 WESB 所处理的消息为 XML 格式的数据，对于非 XML 结构的数据 WESB 不能处理。对于 XML 结构的数据，在 WESB 的消息流中数据以 SMO(IBM 对 SDO 的扩展，参见参考资料部分了解 SDO 的规范 ) 形式存在，WESB 可以对 XML 消息树的内容进行修改，包括改变某个节点的内容，增加新的节点以及删除某个节点等等。 支持的协议 WESB 支持符合 SOA 标准的协议，比如 SOAP/HTTP、SOAP/JMS、WSDL V1.1、UDDI V3.0，WebSphere MQ 等。也就是说 WESB 目前只支持 SOAP 方式来描述服务，传输协议可以是 HTTP、JMS 记忆原生的 WebSphere MQ 的连接。对于多传输协议的基础，建议使用 MB 来做 ESB 的解决方案，参考 MB 的介绍部分。 消息路由 消息的路由在 WESB 中有良好的支持，开发环境 WID 中提供了一个节点专门来负责消息路由，WID 也提供了良好的对路由规则定义的开发支持，开发人员可以很容易的定制负责的路由规则。若要实现动态路由的功能，则需要和一个服务的存储单元中来动态的查找服务，目前 WSRR 是一款优秀的提供该功能的工具（参见参考资料部分了解 WSRR）。WESB 从 V6.1 开始提供了 Endpoint lookup 节点来支持 WSRR 的集成，简化了开发过程。如果要实现简单的动态服务路由的功能，则可把服务的定义存放在数据库中，在 WESB 中通过 DB lookup 来查找服务的 Endpoint, 然后注入到消息流中，WESB V6.1 之前的版本就已经支持与数据库的集成。 对 Web Service 的支持 WESB 天生运行在 J2EE 的环境里面，对 Web Service 有着天然的支持。 事件处理 在消息流中，我们需要跟踪消息各节点的状态，以满足统计和出错处理的要求，在 WESB 中，通过 CEI 机制来处理消息。（CEI 的介绍请参见参考资料部分） 与遗留系统的集成 WESB 通过 Adapter 与遗留系统进行集成，支持 IBM Websphere Adapter 和 JCA Adapter，通过 JCA 我们就可以将遗留系统里面的服务和数据通过标准（SCA/SDO）的形式整合到集成环境中。 安全方面的支持 WESB 没有对安全做特殊的处理，使用 WAS 的安全支持来实现 ESB 的安全。 性能 WESB 是一个纯 Java 的应用，运行效率上有些限制，同时可以处理的消息流的数量级为几十到几百之间。 开发和部署 开发工具是 WID，一个 ESB 的消息流在 WID 中被称为 Mediation Module，它是一个 J2EE 应用，开发和部署工作无异于普通的企业级应用。 Message Broker WMB 是 IBM 的应用整合中间件，是 IBM ESB 架构重要的产品组成部分之一，用于企业应用整合领域。WMB 目前的版本是 6.1.2，它的前身是 MQSeries Integrator。本质上看，WMB 是 MQ 的衍生产品，它使用 MQ 作为内部通信的机制。然后，WMB 提供的接入方式远不止 MQ 一种，包括 JMS、HTTP(S)、SCADA 等常见的新一代接口规范。在消息转化过程中，WMB 能够识别 XML、C 结构、SOAP 等各种自定义的消息格式。 如图 5 所示，WMB 可以分为开发环境和运行环境两大部分。其中开发环境由开发工具（Toolkit）和调试环境（Rational Agent Controller）组成，运行环境是 WMB 核心，也叫 Broker Domain，由三部分组成，配置管理器（Configuration Manager）、用户名服务器（User Name Server）和代理（Broker）。 图 5. WMB 组件 代理（Broker）：消息代理是 WMB 的消息处理引擎，它提供 WMB 的所有运行服务，在 Windows 系统上它是一个系统服务，在 Unix 平台上表现为一个后台进程。应用系统利用与 MQ 的连接和队列将消息发送到消息代理。代理与代理之间，代理与配置管理器之间通过普通的 MQ 发生和接受类型的消息通道进行通信。在一个主机上我们可以创建一个或者多个 Broker，每个 Broker 会关联一个数据库，利用数据库存储 Broker 需要和相关的信息，每个 Broker 还需要一个队列管理器，多个 Broker 之间不能共享同一个队列管理器，每个 Broker 必须有自己特定的、唯一的队列管理器。每个 Broker 只能被一个配置管理器控制。 配置管理器（Configuration Manager）：配置管理器是整个 WMB 运行环境中的控制中心，它维护整个 Broker Domain 的配置信息，配置和管理所有代理，增、删、启动、停止消息流，所有的开发工具也是通过配置管理器来部署编译结果的。配置管理器也负责与用户名服务器联系，配置和管理各种用户权限。配置管理器和其他各个部件之间的接口是 MQ，所以配置管理器也必须是基于 MQ 队列管理器而运行的。 用户名服务器（User Name Server）：用户名服务器是 WMB 运行环境中的可选部分，它可以提供应用程序的接入认证以及订阅主题的访问控制服务。用户名服务器本身是不需要数据库，但必须依赖于队列管理器与其他组件通信。用户名服务器中的用户信息来自认证数据文件。 开发工具（Toolkit）：开发工具是基于 Eclipse 3.0 的集成开发环境，我们可以在其中开发消息流、消息集、ESQL 代码、Java 代码、映射规则等。通过内置的 MQ Client 与配置管理器连接，并将开发好的执行组件部署到相关的代理中。Eclipse 环境由不同的视图（Perspective）组成，我们在 WMB 中常用的有代理开发视图、代理管理视图等。 调试工具（Rational Agent Controller）：这是 IBM Rational 开发工具标准的调试工具。一般安装在代理所在的服务器一边，开发工具可以连接 RAC，通过它来控制和调试消息流的运行。需要注意的是，Toolkit 可以并行开发，但是对于同一个执行组不能并行调试，因 RAC 的调试过程是排他的。在 WMB6.0 之后 RAC 不需要再单独安装。 下面从九个方面来介绍 WMB 在实现一个 SOA ESB 解决方案上的支持的特点： 消息转换 WMB 在消息处理方面功能非常强大，对 XML 格式的消息或非 XML 格式的消息，如 C Header，COBOL 等都有很好的支持。实际上，通过开发消息对应的消息集（Message Set），可以在消息流中对任意格式的消息进行修改。WMB 提供了内置的 mapping 和 database 节点，用户可以通过图形化的方式方便的实现消息的转换或与数据库的交互。 支持的协议 WMB 支持所有 WESB 支持的传输协议，除了常用的 HTTP、JMS 等，还对 FTP、Socket、Mobile、Telemetry、Biztalk 和 Tuxedo 等有良好的支持。WMB 与 MQ 有着紧密的联系，对 MQ 的支持不在话下。WMB 内置的功能节点对这些协议提供了很好的支持，仅需配置即可，如图 6 所示。 图 6. Message Broker 的内置开发节点 消息路由 WMB 提供了很多功能强大的内置节点支持消息的路由，如 Filter 节点、Label 节点等，在新版本的 WMB 中又引入了 Router 节点，该节点几乎和 WESB 中的 Router 节点一样。若需要实现动态路由，可以使用 WSRR 作为服务的存储，WMB 和 WSRR 有很好的集成，通过 RegistryLookup 和 EndpointLookup 我们可以在消息流中实现动态路由。另外需要指出的是，WMB 可以提供一个消息输入，多个消息输出的功能，可以实现一个消息同时路由到多个输出端。 对 Web Service 的支持 在 WMB 中，消息流可以作为 Web Service 暴露出去供外部调用，也可以作为客户端调用外部提供的 Web Service。WMB 不仅提供了内置的 SOAPRequest、SOAPInput 等节点实现对 Web Service 的支持，而且对 WS 扩展，如 WS-Security 和 WS-Addressing 也有良好的支持。 事件处理 在 WMB 中我们可以通过 Trace Service 来记录所发生的事件。Trace 分两种，一种是 User Trace 记录消息流级别的事件，另一种是 Service Trace，可以记录整个 WMB 的事件，如 Broker 的部署执行。WMB 提供了 Trace 内置节点，可以实时的记录流程中消息内容的变化。 与遗留系统的集成 WMB 对遗留系统有良好的支持。对 SAP，PeopleSoft 等大型的 EIS 系统，直接提供了内置的节点，通过 JCA Adapter 配置的方式和 EIS 系统交互。对于比较特别的遗留系统，如 CICS、VSAM 等，WMB 提供了丰富的 SupportPacs，客户可以下载并安装。 安全方面的支持 WMB 本身提供了两个层次上的安装，一个是部署时安全性，管理部署 bar 文件到 Broker 以及运行 WMB 管理命令的权限控制；另一个是运行时安全，涉及的权限控制包括发送消息到相应的消息流，以及消息流可以访问哪些 MQ 资源和非 MQ 资源，如数据库系统。 性能 WMB 底层是使用 C++ 开发的，在性能上相对于 WESB 有很大的提高。同时可以处理的消息数量级为几千到几万之间。 开发和部署 开发工具是 WMB Toolkit，我们开发的消息流和消息集被打成 bar 文件通过配置管理器部署到 Broker 中。 总的来说，WMB 是 IBM 久经考验的一款消息中间件产品，为异构的 IT 环境提供了统一的连接和转化，其优势如下： 利用 WebSphere MQ 作为企业消息传递主干，提供了很好的并发性和可靠性 不仅支持各种标准协议，而且支持和 WebSphere 企业应用程序适配器进行集成 支持多种数据格式之间的转换，包括 XML、遗留系统、行业标准和自定义消息格式 针对大量数据处理进行了优化，极大提高了处理速度。 Datapower DataPower 是一个硬件产品，看起来像一个盒子。目前 IBM 有三款 Datapower 产品供用户选择。按照进入市场的先后次序，它们分别是：Datapower Accelerator XA35，Datapower Security Gateway XS40， Datapower Integration Appliance XI50，见图 7。 图 7. IBM 的 Datapower 产品线 XA35 的主要侧重点是 XML 加速，众所周知，在 SOA 的环境中，XML 是应用最广泛的，而对 XML 的解析，加密，解密这些操作让应用服务器来做的话，这是一个很大性能开销，而 XA35 就是要替应用服务器的分担这些 XML 相关的工作，让应用服务器专注于处理业务逻辑； XS40 的主要侧重点是安全，即负责提供安全的企业网关，及对 XML 攻击的防范。 XI50，从名字上看，主要侧重点是集成功能，是一款高级 ESB 产品，提供了多种协议和数据格式的路由和解析的功能。 虽然三款产品各有侧重，但是三款产品的功能也具有包含关系，XS40 包含 XA35 的功能，XI50 包含 XS40 的功能。 我们依然从以下九个方面来介绍 Datapower 在实现 ESB 解决方案中的特点。 消息转换 Datapower 对 XML 消息有强大的支持，但是 Datapower 绝不仅仅支持 XML，我们可以在 Policy 中使用 Transformation 节点来对消息进行任意我们需要的转换，其原理是使用 XSLT 来实现的，开发人员定义自己 XSLT Stylesheet 并在 Transformation 节点中指定，Datapower 负责转换。 支持的协议 Datapower 支持和以下传输协议，HTTP，HTTS，WebSphere MQ WebSphere JMS，TIBICO EMS，FTP Poller, FTP Server, NFS 等等。 Datapower 的 MPGW 就是一个处理不同协议的应用系统的互联的服务对象。 消息路由 Datapower 支持对服务和消息的路由，根据消息流中的上下文连接将消息动态的分发到不同的消息提供者。但是 Datapower 的动态路由和 WESB 以及 MB 的动态路由还是有区别的，Datapower 的动态路由需要由开发者定义路由的 Map，而 WESB 和 MB 支持在消息头的属性里动态的设置 Endpoint 的地址。目前 Datapower 可以和 WSRR 集成来定义 WS-Proxy（Datapower 中的一种服务对象），但不支持直接和 WSRR 联合实现动态访问 Endpoint 的功能。 对 Web Service 的支持 Datapower 的 XMlFirewall 和 WS-Proxy 提供了强大的对 Web Service 的支持，而且 datapower 提供了细粒度的对 Web Service 的控制，可以从服务级 (Service)，端口级 (port)，绑定级 (binding)，操作级 (operation) 来对消息体进行控制。此外，对 WS-Security 也提供了强大的支持。 事件处理 Datapower 中可以通过 Probe 的方式来跟踪消息流的中间状态，在 Probe 中，可以看到消息流的每个节点的消息内容。Probe 一般用于开发调试过程，在生产模式下一般不使用，因为使能 Probe 会牺牲一定的效率。Datapower 不支持与 CEI 类似将消息发送到其他应用系统的机制。 与遗留系统的集成 Datapower 不支持和 Adapter 的连接，若要与遗留系统的集成，则需要通过其他中间件转换在遗留系统和 Datapower 之间做而桥梁来连接。 安全方面的支持 Datapower 的强大之处在于其对安全方面的强有力的支持，它提供对 XML-attack 的原生支持（关于 XML-attack 的知识参见参考资料）；此外，Datapower 可以对 Web Service 提供细粒度的安全支持，包括加密 (Encryption)，解密 (Decryption)，签名 (Sign) 和确认 (Verify)，以及 HTTS 方面的支持。这些支持在 Datapower 上开发起来都异常简单。 性能 Datapower 无疑是三款 ESB 产品中性能最高的，对 XML 的处理速度达到线速，下图是一组测试结果。如果去处网络传输在其中的比例，对 XML 的处理性能所提高的倍数可达到上百倍。 Software Solution DP Solution Avg. response time ( TimeP / N ) XML processing time ( TimeX ) Avg. response time ( TimeP / N ) XML processing time ( TimeX ) 106 ms 96 ms 19 ms 11ms 开发和部署 Datapower 的没有相应的开发工具，但是提供了 Web GUI 的管理控制台和 CLI 方式的管理支持。我们在 Web GUI 下开发消息流，开发即部署。 高速的 XML 处理能力和强大的安全支持，是 Datapower 作为 SOA 应用中的 ESB 的重要特色，这个特点使得 Datapower 成为一款举足轻重的 ESB 产品。