ESB在SOA体系中的功能定位

企业服务总线（Enterprise Service Bus，ESB）在现代IT领域可以说一个炙手可热的名词。随着SOA进程的推进与落地，ESB的关键性更进一步的得到了广泛的认可。厂商，媒体从各种角度对其进行诠释。各个商业软件厂商以及开源社区也纷纷推出各自的ESB产品。然而我们发现，厂商，媒体对ESB的解释，以及具体ESB产品的功能定位有着相当大的差异。这种现象在某种程度上困惑着IT人士：ESB的核心功能，尤其是其在SOA体系中应当扮演的角色是什么？

在本文中，我愿意和大家分享交流我们作为SOA支撑产品提供者和SOA解决方案提供者对于在SOA体系中ESB的功能定位的理解。

本文第一和第二部分着重描述在SOA体系中，ESB这一概念层次应有的功能定位，第三部分结合目前业界相关ESB产品的功能，介绍这些产品的功能和SOA中ESB层的功能定位的关系。

1、ESB核心功能——中介代理

在SOA体系中，ESB被当作一个集成平台来将企业各种各样的软件资产服务化。这种服务化即将各种各样的私有技术以现代开放，标准的形式暴露为服务供SOA体系中的更高层次（如业务流程管理BPM）使用。

本质上说，SOA需要ESB为服务提供者和消费者之间提供中介服务。ESB作为服务提供者和消费者之间的中介，能够对服务消费者屏蔽提供者位置，协议等技术细节，从而在有多方参与的企业应用集成场景下能够更加灵活并能适应变化的集成服务的调用方与提供方，比如，提供者位置（end point）变化时对服务消费者完全透明。而且，ESB也常常充当服务集成的统一平台，在其上统一多个被集成方的调用协议，通讯方式以及消息语义（统一消息模型），使得其上层（North bound）服务调用者如BPM流程可以以单一且一致的语言与下层（South bound）实现各种各样的会话。

围绕这中介代理这一核心功能，ESB应该具备的具体能力有：

    (1)完善的服务组件模型，包括服务组件的编程模型

   ESB应该提供定义统一，明确的服务组件模型，所有软件功能都被封装成服务组件。只有这样才能够实现服务之间的松耦合组装。

    (2)松耦合链接服务调用者与提供者的组装模型

   ESB应该提供独立的服务调用者与提供者的松耦合组装模型。这里“独立”，“松耦合”指服务调用者与提供者的连接关系完全由组装模型定义，对于调用者与提供者的内部实现逻辑完全透明。

 为了实现调用者与提供者的具体连接关系对服务实现透明，消息路由，服务提供者寻址（包括分布式服务寻址），以及必要的数据转换，数据填充，同步/异步通讯模式转换等中介功能需要由ESB的组装模型提供而不需要调用者与提供者实现逻辑关心。

    (3)支持多种接入方式，通讯协议转换。

  包括对服务调用者提供多种调用协议，以及能够连接使用各种私有传统接口的服务提供者。

2、ESB扩展功能

作为SOA体系的支撑平台，ESB将成为整个架构中核心的服务使能者（Service Enabler）。因此需要ESB在提供核心中介服务的基础上，具备下面的扩展功能特性：

(1)安全——ESB需要提供认证，授权，加密等安全功能保证ESB上的服务被安全的调用，以及ESB可以以服务提供者需要的安全机制调用提供者。

(2)与服务注册库的无缝集成——可以有效的使用服务注册库提供的服务管理功能。

(3)简化开发，部署的能力——如提供图形化的开发工具，集中的提供分布式部署能力的部署工具等。

(4)监控与管理——提供必须的ESB运行时监控与管理能力。

(5)高性能，高可靠性——ESB需要是一个高性能服务中介引擎，同时必须提供足够的高可靠性保障机制。

3、ESB产品的服务编排与EAI

最后一点想要说明的是，从ESB的发展历史看，ESB并不是天生和SOA密切相关的，他反而更多的是由企业应用集成（Enterprise Application Integration，EAI）的需求发展而来。从EAI的角度来看，将各个软件功能通过ESB的中介封装成服务显然是不够的，它一般还需要将这些服务按照一定的业务逻辑编排起来进而实现完整的EAI功能，如数据的整合，交换功能等。因此，我们看到，目前相当一部分的ESB产品同时提供（和BPM相比相对简单但高效的）服务编排功能，为松耦合但需短时间自动执行的服务编排流程提供了技术实现方案。

ESB产品提供更多的功能当然是好事。但我们想要指出的是，具体ESB产品的功能范围不应该影响SOA对ESB本质功能需求的理解，进而混淆ESB在SOA中的定位。从SOA体系的层次结构来看，我们愿意给ESB设定一个相对狭义的功能范畴，即ESB只为SOA上层构件提供透明的，标准的下层功能实体的服务化封装。而将封装好的服务进行业务编排进而实现各种业务集成功能是SOA体系中ESB之上的构件实现的，其中可以是BPM，各个ESB产品的服务编排功能等等。

虽然如前所述，对服务进行编排实现各种业务集成功能从层次上来说不建议是SOA中的ESB的功能要求，但在这里不妨补充说明一下这种业务集成功能的具体实现方式。

理论上说，基于ESB封装的服务的编排可以以任何方式实现。实际应用中，我们看到大致有三种实现方式，即使用业务流程管理（BPM）引擎实现，使用某些ESB产品自身的编排能力，以及使用自定制的方式编排集成流程。

BPM方式的优势在于：在业务服务已经被封装并能被业务人员理解的前提下，BPM提供业务人员可以理解驾驭的图形化建模手段来编排各种业务服务构成新的标准化的业务流程。BPM的引入可以有效的提升业务人员对IT系统的参与，进而实现业务主导的集成应用快速开发和随需应变。同时，BPM实现目前已经有成熟的标准支持，使用BPM实现的集成功能实现对具体产品的依赖相对较低。因此，BPM是业务层面应用集成的有力支撑技术之一，在有人工介入的长时间流程方面，其更是唯一的选择。但另外一方面，BPM实现的集成应用在运行效率方面则不如另外两种编排方式。

使用ESB产品服务编排功能的方式的优势在于可以提供短时间自动执行的服务编排流程的高效执行，但这种编排功能往往是各种ESB产品自己的特有功能，缺乏标准的支持，因此基于ESB产品集成功能实现会比较依赖于具体的ESB产品。这种方式实际上自定制实现方式的一种特例，差别是编排功能不是由应用集成系统的构建者提供而是由ESB产品供应商提供。

自定制实现方式能最直接，高效的精确实现业务集成流程，但其缺点也是显而易见的：定制开发的复杂度，难以持续功能扩充，随需应变。因此仅适用于特殊的集成需求的场景。