从 EAI 到 SOA
EAI(Enterprise Application Integration，企业应用集成)
SOA(service-oriented architecture，面向服务的体系结构)
随着点对点集成的数量越来越多，IT 业界希望有一种有效的方法
来解决并且替代复杂的一点到多点和多点到多点的集成方式。此时 EA
I 的集成方式的提出，迅速被大家认可。EAI 的全称是 Enterprise Applic
ation Integration 企业应用集成，是中间件的一种，可完成企业内部基于
各种不同平台、不同方案建立的异构应用集成互联，实现数据和信息
在各个系统中同步和共享的一种方法和技术。EAI 通过建立底层结
构，来联系横贯整个企业的异构系统、应用、数据源等，完成在企业
内部的 ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部
系统之间无缝地共享和交换数据的需要。简而言之，EAI 是在各个业
务应用、业务流程或者说业务竖井上的桥梁。其将每个业务应用之间
两两对接的一点到多点的集成方式又转换成为业务应用只和 EAI 对接
的一点到一点的连接方式。
伴随着 EAI 技术的不断发展，它所被赋予的内涵变得越来越丰
富。现在我们谈到的 EAI 的集成，具有更为广义的内涵，它已经被扩
展到业务整合的范畴，业务整合相对 EAI 来说是一个更宽泛的概念，
它将应用整合进一步拓展到业务流程整合的级别。当前从最普遍的意
义上来说，比较宽泛的对 EAI 概念的理解是认为 EAI 包括数据集成、
应用集成和业务流程集成等多个方面。
EAI 本身也会对于传递的数据和信息内容进行规范，EAI 一般采用
信息集线器（Hub-Broker）机制，即 EAI 创建了一个交换中心，用于
转换不同应用程序间的数据和消息。EAI 交换中心使用一些适配程序
将所有进入数据的格式重新转换为一种 EAI 交换中心内部和外部适配
程序都可以理解的通用格式，并将其称为规范格式。
在 EAI 这种集中的交换中心的概念下，交换中心将是企业的生命
线，企业必需购买更强大更稳定的硬件设备来保证总线的效率和稳
定。随着应用的增长，数据交换量的增加，以及业务流程整合的开
展，交换中心也有可能成为整体应用的瓶颈，从而造成所有的应用的
停滞。
1. Hub/spoke （集线器架构）
Hub/Spoke 架构是星型拓扑结构，由处于系统中央的一个 Hub 和
连接在 Hub 及应用系统的多个适配器(adapter)组成。适配器在 Hub 和
应用系统之间，进行数据格式的转换与传输。适配器将应用系统的数
据信息转化为 Hub 可以识别的格式并传递给 Hub, Hub 通过消息代理管
理消息路由，并将这些来自应用系统的数据消息按其要求的路由规则
传递给目标应用系统的适配器。
这种架构中的 Hub 使得系统易于管理，但是不易扩展。在需求突
增时，只能通过硬件的升级才能增加系统容量。然而，这种升级方式
的改进是有限的，不足以应付越来越多的整合需求，因此出现了联邦
Hub/spoke 架构的概念，在这种架构下，出现了多个 Hub，每一个 Hub
拥有本地元数据，并且同全局元数据进行同步。对于全局规则和元数
据的改变将自动传播到其他的 Hub 上。
EAI 之 hub/spoke 结构示意图
2. BUS（总线架构）
EAI 的总线架构可以看作是 Hub/Spoke 星型架构的一种变形。将星
型中心点 Hub 的传输消息的功能提炼成一条消息传递总线，而将适配
器、集成引擎绑在了应用系统所在的平台。应用程序使用适配器转换
消息格式，并将消息发送到总线上。这些消息通过消息总线流动到预
订的应用系统的适配器中。该适配器再将消息翻译成符合其应用系统
要求的格式。
由于将适配器和集成引擎捆绑在了应用程序的平台上，bus 架构在
获得比 hub/spoke 布局更好的扩展性的同时提升了集成的复杂性。但两
种架构本质上都是应用系统之间点到点的整合模式。
3.ＳＯＡ方式：
面向服务的体系结构 SOA（service-oriented architecture，SOA）
是一个组件模型和系统架构，它将应用程序的不同功能单元（称为服
务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用
中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和
编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和
通用的方式进行交互。SOA 的最大优点是服务重用，打个比方来说不
同的服务就好像不同的积木，而采用 SOA，你可以按照自己的想法通
过这些积木搭建一个符合自身业务特点和流程的 IT 架构，并且当业务
流程发生了变化，对于积木本身无需调整，只需要简单的调整一下搭
建的方法就可以了。因此采用 SOA 架构可以说是最能够满足企业业务
实际需求，同时在业务发生变化是能够以最小的代价、最迅速、最方
便的完成 IT 对应支持的架构和解决方案。此外 SOA 采用了和硬件、操
作系统和软件无关的通讯协议，打破了各家硬件厂商形成的壁垒，使
不同的产品在技术层可以方便的连接，从而进一步降低整体拥有成
本。
此外 SOA 的架构也很好的解决了 EAI 的交换中心的瓶颈的问题，
在 SOA 的架构体系上，取代 EAI 的是 ESB（企业服务总线）。ESB 企
业服务总线和 EAI 的目的也是完全相同的，其主要的目的是用于业务
应用的集成，但是其更符合 SOA 的标准、甚至可以做到与产品无关。
如果具体的把 ESB 产品和传统 EAI 里面的消息总线类产品做个比较，
其差异主要有三方面。第一，ESB 以 SOA 面向业务的哲学为基础，所
以它主要是通过配置来建立，而不是通过编程建立；第二，ESB 必须
有能力在不同的协议之间建立互通机制，包括传统的消息机制和 Web
服务接口；第三，除了消息（服务）代理方式外，ESB 还必须为 SOA
服务治理提供服务的生命周期管理，而非简单的过滤、转发、路由。
简单来说，EAI 是将所有的消息均通过其进行集中处理和转换，而 ES
B 在完全以上的功能外，其更可以将所有的系统提供的服务在 ESB 上
登记注册，而 ESB 本身不提供真正的服务，服务还是有原有的系统提
供。但是其提供所有服务的查询、注册、规范描述等等功能。因此 ES
B 的负载一般不会向 EAI 这么繁重，甚至 ESB 宕机后，已经完成的系
统间的服务调用还是可以正常运作。
ESB 除了运营支撑系统作为服务提供者和消费者的中介提供服务
交互、代理和路由功能外，还可以提供可扩展的服务编排、目录、元
数据管理、生命周期管理、服务质量和级别控制等功能。通过这些功
能，ESB 帮助屏蔽各种服务生产者的差异，集中管理所有的服务消费
行为。从而避免服务的大量蔓延，简化用户 SOA 环境的复杂性。
4. EAI 与 SOA 的比较
我们从以下的几个方面对 EAI 与 SOA 进行比较：
1. 集成的本质
EAI 的集成方式从本质而言是基于消息的集成，因此 EAI 的各组
成部件，如适配器与 hub，都带有消息转换与消息路由的功能，在 EAI
的运作过程中，单个应用系统只关心其与 EAI 连接部分消息的输入与
输出，不关心具体的业务处理，业务处理都是在应用系统内部完成
的。
SOA 的集成方式，其本质是对业务功能服务化后根据业务流程进
行编排，是真正意义上的基于功能服务的集成。当然在基于 SOA 的集
成中同样包含了基于消息集成的功能。
因此基于 SOA 的集成方式比 EAI 的集成方式适用范围更广。
2. 集成对象的颗粒度
SOA 和 EAI 从不同的视角切入去看待企业已有的信息资源，并基
于此对企业已有的资源进行梳理、分类和集成。
EAI 从应用系统的层面去看待企业已有信息资源，企业的每一个
应用系统被看作一个集成单元，EAI 工作的目标就是，通过为这些已
有的应用系统提供一种中间沟通方式，让这些应用软件之间可以进行
数据的共享与交换，从而盘活这一个个独立的“信息孤岛”。
SOA 从提供服务、使用服务的角度去看待企业已有的信息资源。
在这种方式下，同样的一种资源既可能是服务提供者，也同样可以是
服务使用者； 在这种方式下，一个应用模块可能只提供一种服务，因
此被封装成一个服务，也可能由于提供了多种服务，而需要进一步划
分。
显然，SOA 方式集成处理的颗粒度比 EAI 要小，因此 SOA 方式
比 EAI 方式更具有灵活性。
3. 标准化
SOA 在实现企业信息化集成的同时，也将实现企业级服务的高度
可重用作为目标，因此，在 SOA 架构中任何一种接口、通讯、协议都
是遵循相应的国际标准，如：标准描述语言（WSDL）、发现协议（U
DDI)和消息协议(SOAP)等。
EAI 则大多使用基于具体实施 EAI 企业中制定的私有标准。基于
私有标准的优点是可以在一定程度上减轻 EAI 中间层对应用系统消息
翻译转换的压力，在应用系统较少的情况下可以提高 EAI 的整体性
能，但私有标准同时也对企业整合的灵活可扩展性上带来损失，当企
业引入新的应用系统，或当某个应用系统需要做比较大的改动时，整
个 EAI 总线的适应性将变得十分脆弱。
在系统较少的情况下或是系统集成的早期阶段，采用私有标准的
EAI 会体现出性能高，实现难度低等优点，但在企业规模不断增长的
过程中，新引入系统的整合难度将因为标准的不统一而呈指数级上
升。
4. 灵活可扩展性
由于对标准的良好支持，使得 SOA 具有可灵活扩展的特性，而 E
AI 要达到同样的扩展效果，其代价将远远高于 SOA。例如，现在有
甲、乙两个系统需要集成。假设它们通过 SOA 完成集成形成 A 方案，
使用 EAI 完成集成形成 B 方案。当集成需求发生变化后，甲乙两个系
统需要以另外一种业务逻辑进行集成。对于 A 方案而言，所需要做的
工作比较简单，只需将之前的业务逻辑打开，重新组合一下业务逻辑
就可以实现。而对于 B 方案而言，过程就会麻烦的多，需要根据新的
业务逻辑，重新设计开发满足新业务逻辑需要的适配器和中间层的消
息处理逻辑。
5. 重用性
企业信息化建设的投资可以分为两个部分：现有应用系统的维护
与新系统的开发费用。在 SOA 架构下，各个服务是以完全独立的方式
通过服务目录暴露在 SOA 集成平台上的，当新集成进来的应用系统需
要使用现有的某个服务时，可以直接使用，无需再次开发，即服务是
可重用的，只需用开发目前还没有的业务功能服务，这样可以充分利
用现有的资源，降低成本。
通过 EAI 方式实现企业应用集成，其开发的适配器、中间层消息
转换规则和消息路由都是紧耦合的，当新系统要在 EAI 中进行集成，
便需要对现有的部分适配器、中间层消息转换规则与消息路由进行改
造，无法重用。
因此，使用 SOA 比使用 EAI 更经济，尤其在多个应用系统相互集
成的复杂场景下，SOA 的优点将更加突出。
6. SOA 企业服务总线与 EAI 总线的比较
ESB(Enterprise Service Bus 企业服务总线）是一种用于推动 SOA
的基础设施，从技术上而言，企业服务总线是一种消息传递的主干
线，它用于提供协议转换，消息格式的转换，地址路由，接收并分发
从各个连接到 ESB 的服务请求与系统传递来的消息。
在 EAI 的总线架构中，EAI 为消息传播提供了一个中央消息主干
线---Bus。应用程序使用适配器将消息发布到总线，消息通过总线流动
到预订的应用程序中。总线是消息流动的通道，捆绑在应用软件端的
适配器负责将消息在应用程序端的格式与符合总线标准的格式之间转
换。因此，对于每一个应用程序，都需要单独为其开发符合应用程序
自身要求的适配器，而由于没有遵循统一的标准，这些适配器是无法
通用的。当某个应用系统进行比较大的改动时，则有可能存在对适配
器的改造已经不能满足系统变更需求的情况，此时甚至有可能会牵涉
到对 BUS 总线的修改，给企业信息架构带来很大的风险。
从 ESB 和 EAI 的总线工作过程上的区别可以看出 ESB 承担了更多
的责任，做了更多的事情，为集成后的系统提供了完善、坚固的底层
支持。而 EAI 的总线，只是一个消息的分发器，由于没有统一的标
准，需要依赖适配器来完成转换。功能上的差别导致了系统集成到总
线上的代价的巨大差异。
7. 系统集成的代价
SOA 架构中的企业服务总线与 EAI 中私有形式 BUS 尽管结构较为
相似，但是在系统集成中却导致集成的成本代价却有很大的差别。这
种在代价上的差异主要由两个方面的因素造成的，一是私有形式的总
线提供很多产品套件式的内建函数功能，这些函数功能需要根据业务
需求进行开发；二是很多的私有形式的总线采用专有的消息格式来提
高性能，但却增加了系统开发代价。企业服务总线都是基于标准的。
企业服务总线主要的优点就是相比集线器架构和基于产品套件的总线
架构的支出要低，而且它是完全基于业界标准化。
另一个关键的不同是：ESB 具有分散的和分布式体系结构，更加
轻型的安装，而 EAI 遵从 HUB-SPOKE 体系结构，因而企业中进行多
个大型应用系统之间的集成时，硬件成本高，扩展性也会相对比较薄
弱。.
5. 总结
到目前为止，传统的编程技术所形成的软件系统都是刚性的。也
就是说，一旦开发完成并投入运行，就是固定不变的，不能在使用过
程中进行调整和改变。在业务流程中，软件系统严格按照预先设定的
目标，各功能模块按照确定的顺序执行。如果数据结构或者业务逻辑
发生改变，就必须对所有相关的软件模块、数据源和消息逐个进行修
改。就算是有了 EAI 中间件，这种情况也并没有得到根本性的改变。
今天，SOA 改变了这种现状。SOA 采用服务请求(Service Request)
的方式，使软件系统向“柔性化”迈进了一大步。与传统的软件系统不
同，SOA 只限定服务所需的信息并提出服务请求，但是不限定提供服
务的模块。SOA 架构替代 EAI 实现企业应用集成是必然的趋势，只有
通过 SOA 架构来进行企业应用集成，才能使企业信息化快速、稳定发
展。
