漫谈从EAI到SOA.docx

漫谈从EAI到SOA.docx

《漫谈从EAI到SOA.docx》由会员分享，可在线阅读，更多相关《漫谈从EAI到SOA.docx（7页珍藏版）》请在冰豆网上搜索。

漫谈从EAI到SOA

从EAI到SOA

EAI（EnterpriseApplicationIntegration，企业应用集成）

SOA（service-orientedarchitecture，面向服务的体系结构）

随着点对点集成的数量越来越多，IT业界希望有一种有效的方法来解决并且替代复杂的一点到多点和多点到多点的集成方式。

此时EAI的集成方式的提出，迅速被大家认可。

EAI的全称是EnterpriseApplicationIntegration企业应用集成，是中间件的一种，可完成企业内部基于各种不同平台、不同方案建立的异构应用集成互联，实现数据和信息在各个系统中同步和共享的一种方法和技术。

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-orientedarchitecture，SOA）是一个组件模型和系统架构，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。

接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。

这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

SOA的最大优点是服务重用，打个比方来说不同的服务就好像不同的积木，而采用SOA，你可以按照自己的想法通过这些积木搭建一个符合自身业务特点和流程的IT架构，并且当业务流程发生了变化，对于积木本身无需调整，只需要简单的调整一下搭建的方法就可以了。

因此采用SOA架构可以说是最能够满足企业业务实际需求，同时在业务发生变化是能够以最小的代价、最迅速、最方便的完成IT对应支持的架构和解决方案。

此外SOA采用了和硬件、操作系统和软件无关的通讯协议，打破了各家硬件厂商形成的壁垒，使不同的产品在技术层可以方便的连接，从而进一步降低整体拥有成本。

此外SOA的架构也很好的解决了EAI的交换中心的瓶颈的问题，在SOA的架构体系上，取代EAI的是ESB（企业服务总线）。

ESB企业服务总线和EAI的目的也是完全相同的，其主要的目的是用于业务应用的集成，但是其更符合SOA的标准、甚至可以做到与产品无关。

如果具体的把ESB产品和传统EAI里面的消息总线类产品做个比较，其差异主要有三方面。

第一，ESB以SOA面向业务的哲学为基础，所以它主要是通过配置来建立，而不是通过编程建立；第二，ESB必须有能力在不同的协议之间建立互通机制，包括传统的消息机制和Web服务接口；第三，除了消息（服务）代理方式外，ESB还必须为SOA服务治理提供服务的生命周期管理，而非简单的过滤、转发、路由。

简单来说，EAI是将所有的消息均通过其进行集中处理和转换，而ESB在完全以上的功能外，其更可以将所有的系统提供的服务在ESB上登记注册，而ESB本身不提供真正的服务，服务还是有原有的系统提供。

但是其提供所有服务的查询、注册、规范描述等等功能。

因此ESB的负载一般不会向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）、发现协议（UDDI）和消息协议（SOAP）等。

EAI则大多使用基于具体实施EAI企业中制定的私有标准。

基于私有标准的优点是可以在一定程度上减轻EAI中间层对应用系统消息翻译转换的压力，在应用系统较少的情况下可以提高EAI的整体性能，但私有标准同时也对企业整合的灵活可扩展性上带来损失，当企业引入新的应用系统，或当某个应用系统需要做比较大的改动时，整个EAI总线的适应性将变得十分脆弱。

在系统较少的情况下或是系统集成的早期阶段，采用私有标准的EAI会体现出性能高，实现难度低等优点，但在企业规模不断增长的过程中，新引入系统的整合难度将因为标准的不统一而呈指数级上升。

4.灵活可扩展性

由于对标准的良好支持，使得SOA具有可灵活扩展的特性，而EAI要达到同样的扩展效果，其代价将远远高于SOA。

例如，现在有甲、乙两个系统需要集成。

假设它们通过SOA完成集成形成A方案，使用EAI完成集成形成B方案。

当集成需求发生变化后，甲乙两个系统需要以另外一种业务逻辑进行集成。

对于A方案而言，所需要做的工作比较简单，只需将之前的业务逻辑打开，重新组合一下业务逻辑就可以实现。

而对于B方案而言，过程就会麻烦的多，需要根据新的业务逻辑，重新设计开发满足新业务逻辑需要的适配器和中间层的消息处理逻辑。

5.重用性

企业信息化建设的投资可以分为两个部分：

现有应用系统的维护与新系统的开发费用。

在SOA架构下，各个服务是以完全独立的方式通过服务目录暴露在SOA集成平台上的，当新集成进来的应用系统需要使用现有的某个服务时，可以直接使用，无需再次开发，即服务是可重用的，只需用开发目前还没有的业务功能服务，这样可以充分利用现有的资源，降低成本。

通过EAI方式实现企业应用集成，其开发的适配器、中间层消息转换规则和消息路由都是紧耦合的，当新系统要在EAI中进行集成，便需要对现有的部分适配器、中间层消息转换规则与消息路由进行改造，无法重用。

因此，使用SOA比使用EAI更经济，尤其在多个应用系统相互集成的复杂场景下，SOA的优点将更加突出。

6.SOA企业服务总线与EAI总线的比较

ESB（EnterpriseServiceBus企业服务总线）是一种用于推动SOA的基础设施，从技术上而言，企业服务总线是一种消息传递的主干线，它用于提供协议转换，消息格式的转换，地址路由，接收并分发从各个连接到ESB的服务请求与系统传递来的消息。

在EAI的总线架构中，EAI为消息传播提供了一个中央消息主干线---Bus。

应用程序使用适配器将消息发布到总线，消息通过总线流动到预订的应用程序中。

总线是消息流动的通道，捆绑在应用软件端的适配器负责将消息在应用程序端的格式与符合总线标准的格式之间转换。

因此，对于每一个应用程序，都需要单独为其开发符合应用程序自身要求的适配器，而由于没有遵循统一的标准，这些适配器是无法通用的。

当某个应用系统进行比较大的改动时，则有可能存在对适配器的改造已经不能满足系统变更需求的情况，此时甚至有可能会牵涉到对BUS总线的修改，给企业信息架构带来很大的风险。

从ESB和EAI的总线工作过程上的区别可以看出ESB承担了更多的责任，做了更多的事情，为集成后的系统提供了完善、坚固的底层支持。

而EAI的总线，只是一个消息的分发器，由于没有统一的标准，需要依赖适配器来完成转换。

功能上的差别导致了系统集成到总线上的代价的巨大差异。

7.系统集成的代价

SOA架构中的企业服务总线与EAI中私有形式BUS尽管结构较为相似，但是在系统集成中却导致集成的成本代价却有很大的差别。

这种在代价上的差异主要由两个方面的因素造成的，一是私有形式的总线提供很多产品套件式的内建函数功能，这些函数功能需要根据业务需求进行开发；二是很多的私有形式的总线采用专有的消息格式来提高性能，但却增加了系统开发代价。

企业服务总线都是基于标准的。

企业服务总线主要的优点就是相比集线器架构和基于产品套件的总线架构的支出要低，而且它是完全基于业界标准化。

另一个关键的不同是：

ESB具有分散的和分布式体系结构，更加轻型的安装，而EAI遵从HUB-SPOKE体系结构，因而企业中进行多个大型应用系统之间的集成时，硬件成本高，扩展性也会相对比较薄弱。

.

5.总结

到目前为止，传统的编程技术所形成的软件系统都是刚性的。

也就是说，一旦开发完成并投入运行，就是固定不变的，不能在使用过程中进行调整和改变。

在业务流程中，软件系统严格按照预先设定的目标，各功能模块按照确定的顺序执行。

如果数据结构或者业务逻辑发生改变，就必须对所有相关的软件模块、数据源和消息逐个进行修改。

就算是有了EAI中间件，这种情况也并没有得到根本性的改变。

今天，SOA改变了这种现状。

SOA采用服务请求（ServiceRequest）的方式，使软件系统向“柔性化”迈进了一大步。

与传统的软件系统不同，SOA只限定服务所需的信息并提出服务请求，但是不限定提供服务的模块。

SOA架构替代EAI实现企业应用集成是必然的趋势，只有通过SOA架构来进行企业应用集成，才能使企业信息化快速、稳定发展。