作者Adrien LOUIS译者胡键
摘要
在实施SOA时，现在非常流行使用象企业服务总线（ESB）这样的基础设施。在一个企业中，对于这种基础设施至少有两种不同的实现思路：在公司内使用多个的ESB服务器，每个服务器解决一个特定部门的特殊集成问题；或使用一个覆盖全公司的ESB，它负责将信息系统所有部分链接在一起。本文将讨论这两种方式在架构与管理方面的若干问题。
不同的基础设施
5年来，ESB一直是SOA基础方面的一个时髦词汇。ESB这个概念是David Chappell提出的，但时至今日仍然没有真正适合它的定义。的确，每个ESB厂商都鼓吹各自的愿景，另外在基础设施层面也存在着不同的实现方式。每种方式都有其优点和缺点。
第一种方式是让各个部门用自己的ESB实现去管理自己的SOA。它管理应用的集成与业务过程的开发。通过使用分散独立的ESB，每个部门可以自由地实施它想要的解决方案。但是当需要与其它合作伙伴进行通信时，部门ESB要通过一种标准的“桥接”技术（如Web服务）才能访问和提供一些业务服务。在这种情形下，通信可以依赖于诸如HTTP这样的协议，而服务质量（如可靠性或安全）则必须依靠手工实现。
第二种方式将SOA基础设施视为一个整体视图，在其中ESB是全公司统一的。这种ESB遍布于各个部门的各台服务器上，以确保它们之间能进行通信。对另一个部门提供的服务进行调用非常简单，因为消费者与ESB通信的方式与它调用本地服务的方式没有分别。
在这个视图中，ESB真正被视为一个主干基础设施，就像一个以太网。实际上，ESB是一个天生内部互联的节点集合。一个节点就是服务消费者或提供者的连接点。
注：一个ESB节点实际上是一个具有网络能力、能与其它实例互联的ESB服务器。
覆盖全公司网络的ESB并不是一个老大哥
首席信息官的第一反应可能会说“哦，不！我不想要一个允许任何人都可浏览和访问公司内任何东西的‘无处不在的’工具”，管理员们可能会嚷道“我如何管理和监督？”，“其它管理员可以修改我服务器上的东西，这不可能”，或大家经常听到的“安全性怎么办？”，等等诸如此类……
显然，一个通用ESB不会允许每一件事。它只是简化了整个网络的通信，并以一种简化的方式提供一组全网络的服务质量。
统一ESB中的域（Domain）
域和子域定义了实体间的边界。这样，从管理上来，每个ESB“节点”只能由子域管理员来管理。子域管理员是唯一能启动、停止、安装连接器、部署服务等活动的人，他管理被域中ESB节点所使用的端口，并可以设置代理或防火墙来保护这些端口。
部署于一个域中节点上的业务服务可以是公共或私有的。也就是说，在注册中心中，一个私有服务只对同一域中的消费者可见。而且，私有服务只能由相同域的消费者访问。
注：除非明确说明，在以下几节中将不会讨论私有服务。
服务和过程监测只能显示本域信息或其他域的公共信息，不能看到其他私有域的过程或服务统计。
既然我们已经清除了若干关于统一ESB是什么的潜在误解，让我们看看它的优点。
注册中心
在一个非互联ESB环境中，对于其他域的服务，只有在两个域的ESB之间显式地为该服务创建一个桥接才能访问该服务。比如，某域中的一个服务被暴露为一个经典的Web服务，另一个ESB必须知道URL才能调用它。要引用所有这样的Web服务需要一个公司范围的注册中心。在这种情形下，每个域的管理者必须将本域的Web服务发布到这个公司注册中心中。这些Web服务可以被认为是公司的“公共”服务，因为它们对所有消费者可见。
在一个统一ESB中，业务服务注册中心本身就是统一的；每个ESB实例的注册中心会与其它ESB的注册中心进行同步。一个消费者或服务浏览器只要连接到其中一个域的ESB就可以看到总线上的所有服务。每当有新服务被暴露于ESB上，每一个ESB实例上的所有消费者都可以立即发现并访问它，与这个 ESB的物理位置无关。所有服务以同一方式被访问；它们是“ESB服务”。不管它们是如何实现的，也不管使用的是什么协议。
编配
要编配遍布于多个非互联ESB上的服务有两种方案。一种方案是将BPEL引擎置于ESB环境之外，例如将它作为一个Web服务BPEL引擎。按照这种方式，过程设计者要对各个域上的所有服务均有所了解才行。而且，可能还得把这些服务整合为Web服务以便访问。在运行时，BPEL引擎要在整个网络上建立起 HTTP连接才能访问这些服务。
另一种方案是将BPEL引擎被集成到ESB里，调用那些本地环境可用的服务。当它需要访问其他域中的服务时，必须先通过桥接（如一个Web服务调用）访问对方的ESB，然后再调用对方服务。
对于统一ESB，“内部”注册中心包含了总线上所有的服务及描述。只要将BPEL设计器连接上ESB注册中心，就可以很容易地进行过程设计。过程设计只涉及ESB服务。可以在统一注册中心检索所有可用的服务，并将它们直接集成到过程里。在运行时，由于在BPEL引擎和服务间没有桥接，所以事务与补偿问题也比较容易解决。
可靠性
在像SOA这样的集成环境中，应用之间基本上会有大量通信。它们遍布于不同的服务器，信息大量地通过网络传递。为了避免信息丢失，基础设施的传输层要尽可能的健壮。ESB传输层常常提供了消息可靠性，但是ESB和应用之间的桥接的消息可靠性则要依赖底层协议（如Web服务、FTP、JMS、RMI 等）的能力。
对于非互联的ESB实例，同样需要确保实例之间的消息可靠性。对于每个位于其他ESB实例上的服务，必须配置一个可靠的通信。为每个服务配置一个 JMS队列可以解决这个问题。此外，发送者ESB、JMS队列和接收者ESB间的通信可能要支持事务才行。当需要大量访问其他域的服务时，这项工作会变得很困难。
使用一个统一ESB时，可以在作为集成应用宿主的每台物理服务器上安装一个ESB实例。这种情况下，一个Web服务调用或一个FTP连接仍然在那台服务器上。一次网络崩溃不会影响应用和ESB节点间的通信。网络通信通过ESB节点完成。可靠性由节点的传输层保证（通常是基于一个JMS MOM（面向消息的中间件））。
当然，在每个应用的宿主服务器上安装一个ESB节点是理想情形。那些无需完美可靠性的应用可以连接到一个寄存在单独的服务器上的远端ESB节点；同样，在一个网络安全的环境，ESB服务器也可能被几个应用所共享。这依赖于管理员资源、成本等等。
服务治理
在一个非互联的环境中，管理服务生命周期和版本不是件易事。每当有新服务被暴露在一个ESB实例中，为了允许其他实例的消费者可以访问它，必须对连接器加以配置，以便将服务暴露给其他实例。当这个服务的新版本可用时，每个连接器必须被更新，以确保与该新版本一致。此外，如果没有引用所有ESB实例服务的公司范围的注册中心，来自其他ESB实例的消费者将永远不会知道还有某些服务存在于一个实例之上。
在统一ESB中，因为每个实例都是天生内部互联的，部署在一个实例上的服务可以立即被其他实例上的消费者使用。在每个实例的注册中心中都可以看到这个服务。当这个服务改变时，每个消费者都能从这个新版本受益。
管理
大多数时候，非互联ESB环境的管理员（他负责执行连接器安装、服务部署和其他生命周期管理）不得不连接到域的每个ESB管理控制台上来完成管理任务。管理员是分别配置各个ESB实例的行为的。
使用统一ESB，可以让域管理员使用一个管理控制台来管理域中所有节点，在这个控制台中他可以看到全部的拓扑结构。这种方式的主要好处在于管理员可以查看域中所有实例活动（资源消耗、服务调用统计等）以及管理ESB的行为。例如，如果一个服务（如XSL转换服务）被过度使用，管理员就可以实例化这个转换服务的一个副本，将它部署到其他实例上，然后定义一个负载均衡规则来分发请求。这在非互联的ESB环境中是无法做到的（即使能，也很困难）。
业务监测
业务活动监测是SOA基础设施给运营管理者带来的最有趣的特性之一。服务统计可以实时获得；业务过程被监测且能被优化；当异常状况出现时，通过电子邮件发送警报……
在非互联的ESB环境中，收集关键性能指标（KPI）并不轻松。必须单独收集各个ESB实例的KPI，而且两个实例间的通信（如一次Web服务调用）也很难被监测。所有数据必须先相互关联起来才能被监测工具读取。
统一ESB又一次简化了域内的KPI收集工作。因为实例间没有不匹配的协议，从消费者到提供者的一次交换的生命周期亦可被监测，即使不是相同的ESB实例托管它们。监测控制台可连接到域的任意实例，然后显示域的统计结果。
总结
每个ESB都提供了集成应用的一组功能和工具。使用一组连接器和服务（如转换或编配），应用集成变得简单了。
对于一个给定的集成问题，人们可以使用一个“中心”ESB、一些连接器，并使用它来成为粘合2或3个应用之间的胶水。大多数时候，这种“点对点”的方式很简单，可快速安装，无需业务服务定义（WSDL等）。正如我们在这篇文章中看到的，这种“集成”视图也许对简单情形是够用的，但对于真正的“服务平台 ”（ESB必须是企业的SOA主干）并不够。
选择一个允许真正网络通信的ESB实现是在企业中实施“服务平台”的关键。它允许我们以全局视图来观看信息系统中的所有活动与业务，并增强了它的机动性，因为整个企业中的每一个服务均可按业务步骤的方式被方便地使用。
作者简介
Adrien Louis是EBM WebSourcing的首席架构师，他拥有8年的使用Java EE技术的经验。目前，他正致力于解决企业集成方面的问题。Adrien是一位SOA顾问，同时是PEtALS开源项目的架构师。PEtALS提供了支持SOA的领先开源ESB，并致力于成为同时适用于A2A和B2B的一个轻量级、高度分布式和伸缩性的平台。由于它的特殊的分布式架构和提供的工具，PEtALS提供了非常具有竞争性的集成解决方案，并支持范围广泛的协议、格式和集成特性。
