ESB在SOA体系中的功能定位

1、ESB在SOA体系中的功能定位东方通首席架构师刘川企业服务总线(Enterprise Service Bus , ESB在现代IT领域可以说一个 炙手可热的名词。随着SOA进程的推进与落地，ESB的关键性更进一步的得到了 广泛的认可。厂商，媒体从各种角度对其进行诠释。 各个商业软件厂商以及开源 社区也纷纷推出各自的ESB产品。然而我们发现，厂商，媒体对ESB的解释，以 及具体ESB产品的功能定位有着相当大的差异。这种现象在某种程度上困惑着 IT人士： ESB的核心功能，尤其是其在 SOA体系中应当扮演的角色是什么？在本文中，我愿意和大家分享交流我们作为 SOA支撑产品提供者和SOA军决 方案提

2、供者对于在SOA体系中ESB的功能定位的理解。本文第一和第二部分着重描述在 SOA体系中，ESB这一概念层次应有的功能 定位，第三部分结合目前业界相关 ESB产品的功能，介绍这些产品的功能和 SOA 中ESB层的功能定位的关系。1、ESB核心功能一一中介代理在SOA体系中，ESB被当作一个集成平台来将企业各种各样的软件资产服务 化。这种服务化即将各种各样的私有技术以现代开放，标准的形式暴露为服务供 SOA体系中的更高层次(如业务流程管理 BPM使用。本质上说，SOAR要ESB为服务提供者和消费者之间提供中介服务。ESB作为服务提供者和消费者之间的中介，能够对服务消费者屏蔽提供者位置， 协议等技

3、术细节，从而在有多方参与的企业应用集成场景下能够更加灵活并能适应变化 的集成服务的调用方与提供方，比如，提供者位置(end point )变化时对服务 消费者完全透明。而且，ESB也常常充当服务集成的统一平台，在其上统一多个 被集成方的调用协议，通讯方式以及消息语义(统一消息模型)，使得其上层(North bound)服务调用者如BPM流程可以以单一且一致的语言与下层(South bound)实现各种各样的会话。围绕这中介代理这一核心功能，ESB应该具备的具体能力有:(1) 完善的服务组件模型，包括服务组件的编程模型ESB应该提供定义统一，明确的服务组件模型，所有软件功能都被封 装成服务组件。

4、只有这样才能够实现服务之间的松耦合组装。(2) 松耦合链接服务调用者与提供者的组装模型ESB应该提供独立的服务调用者与提供者的松耦合组装模型。这里 “独立”，“松耦合”指服务调用者与提供者的连接关系完全由组装模型定 义，对于调用者与提供者的内部实现逻辑完全透明。为了实现调用者与提供者的具体连接关系对服务实现透明， 消息路由, 服务提供者寻址(包括分布式服务寻址)，以及必要的数据转换，数据填充, 同步/异步通讯模式转换等中介功能需要由 ESB的组装模型提供而不需要调 用者与提供者实现逻辑关心。(3) 支持多种接入方式，通讯协议转换。包括对服务调用者提供多种调用协议，以及能够连接使用各种私有传 统

5、接口的服务提供者。2、ESB扩展功能作为SOA体系的支撑平台，ESB#成为整个架构中核心的服务使能者(Service Enabler )。因此需要ESB在提供核心中介服务的基础上，具备下面 的扩展功能特性：(1) 安全一一ESB需要提供认证，授权，加密等安全功能保证ESB上的服务被 安全的调用，以及ESB可以以服务提供者需要的安全机制调用提供者。(2) 与服务注册库的无缝集成一一可以有效的使用服务注册库提供的服务管 理功能。(3) 简化开发，部署的能力一一如提供图形化的开发工具，集中的提供分布 式部署能力的部署工具等。(4) 监控与管理提供必须的 ESB运行时监控与管理能力。(5) 高性能，高

6、可靠性一一ESB需要是一个高性能服务中介引擎，同时必须提 供足够的咼可靠性保障机制。3、ESB产品的服务编排与EAI最后一点想要说明的是，从 ESB的发展历史看，ESB并不是天生和SOA密切相关的，他反而更多的是由企业应用集成(En terprise Applicatio nIntegration ，EAI)的需求发展而来。从EAI的角度来看，将各个软件功能通过 ESB的中介封装成服务显然是不够的，它一般还需要将这些服务按照一定的业务 逻辑编排起来进而实现完整的 EAI功能，如数据的整合，交换功能等。因此，我 们看到，目前相当一部分的ESB产品同时提供(和BPM相比相对简单但高效的) 服务编排

7、功能，为松耦合但需短时间自动执行的服务编排流程提供了技术实现方 案。ESB产品提供更多的功能当然是好事。但我们想要指出的是，具体ESB产品的功能范围不应该影响SOA对ESB本质功能需求的理解，进而混淆 ESB在 SOA 中的定位。从SOA体系的层次结构来看，我们愿意给ESB设定一个相对狭义的功 能范畴，即ESB只为SOA上层构件提供透明的，标准的下层功能实体的服务化封 装。而将封装好的服务进行业务编排进而实现各种业务集成功能是SOA体系中ESB之上的构件实现的，其中可以是 BPM各个ESB产品的服务编排功能等等。虽然如前所述，对服务进行编排实现各种业务集成功能从层次上来说不建议 是SOA中的E

8、SB的功能要求，但在这里不妨补充说明一下这种业务集成功能的具 体实现方式。理论上说，基于ESB封装的服务的编排可以以任何方式实现。实际应用中， 我们看到大致有三种实现方式，即使用业务流程管理(BPM)引擎实现，使用某些ESB产品自身的编排能力，以及使用自定制的方式编排集成流程。BPM方式的优势在于：在业务服务已经被封装并能被业务人员理解的前提下，BPM提供业务人员可以理解驾驭的图形化建模手段来编排各种业务服务构成新 的标准化的业务流程。BPM的引入可以有效的提升业务人员对IT系统的参与，进而实现业务主导的集成应用快速开发和随需应变。同时，BPM实现目前已经有成熟的标准支持，使用BPM实现的集成功能实现对具体产品的依赖相对较低。因 此，BPM是业务层面应用集成的有力支撑技术之一，在有人工介入的长时间流程 方面，其更是唯一的选择。但另外一方面， BPMS现的集成应用在运行效率方面 则不如另外两种编排方式。使用ESB产品服务编排功能的方式的优势在于可以提供短时间自动执行的服 务编排流程的高效执行，但这种编排功能往往是各种ESB产品自己的特有功能，缺乏标准的支持，因此基于ESB品集成功能实现会比较依赖于具体的 ESBT品。 这种方式实