本文主要是介绍EAI和SOA比较,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
原文:http://blog.sina.com.cn/s/blog_493a84550100j94u.html
1.EAI(Enterprise Application Integration,企业应用集成)
EAI是将基于异构平台下的业务应用系统集成在一起的一种技术。EAI通过中间件作为粘合剂来连接企业内外各种业务相关的异构系统、应用以及数据源,从而满足企业内部应用系统之间信息共享的需要。 EAI可从以下的几个层面来实施:注:从EAI集成的三个层面来看,完全和SOA集成的三个层面相同。
-
用户界面集成:这个层面是一个面向用户的整合,强调的是要将来自多个信息源的信息以一种可以定制的、个性化的界面展现给用户。
-
应用集成:应用集成是以应用系统为基本集成单位,通过中间件,为两个应用系统提供业务集成。
-
数据集成:数据集成是应用集成的基础。在实施集成之前,必须首先对数据进行标识并编成目录,另外还要确定元数据模型。这三步完成以后,数据才可以在多个数据库系统之间进行分布和共享。
EAI的结构一般可以分为以下两种形式:
a. Hub/spoke (集线器架构)
Hub/Spoke 架构是星型拓扑结构,由处于系统中央的一个Hub和连接在Hub及应用系统的多个适配器(adapter)组成。适配器在Hub和应用系统之间,进行数据格式的转换与传输。适配器将应用系统的数据信息转化为Hub可以识别的格式并传递给Hub, Hub通过消息代理管理消息路由,并将这些来自应用系统的数据消息按其要求的路由规则传递给目标应用系统的适配器。
这种架构中的Hub使得系统易于管理,但是不易扩展。在需求突增时,只能通过硬件的升级才能增加系统容量。然而,这种升级方式的改进是有限的,不足以应付越来越多的整合需求,因此出现了联邦Hub/spoke架构的概念,在这种架构下,出现了多个Hub,每一个Hub拥有本地元数据,并且同全局元数据进行同步。对于全局规则和元数据的改变将自动传播到其他的Hub上。
EAI 的总线架构可以看作是Hub/Spoke星型架构的一种变形。将星型中心点Hub的传输消息的功能提炼成一条消息传递总线,而将适配器、集成引擎绑在了应用系统所在的平台。应用程序使用适配器转换消息格式,并将消息发送到总线上。这些消息通过消息总线流动到预订的应用系统的适配器中。该适配器再将消息翻译成符合其应用系统要求的格式。
由于将适配器和集成引擎捆绑在了应用程序的平台上,bus架构在获得比hub/spoke布局更好的扩展性的同时提升了集成的复杂性。但两种架构本质上都是应用系统之间点到点的整合模式。(EAI集成本质仍然是为了打破原有系统的点对点集成,转变为总线式集成。如何还是点对点集成,总线的目的何在?)
2.SOA(service-oriented architecture,面向服务的体系结构)
SOA(面向服务的体系结构)将企业中各个系统应用程序的不同功能单元抽象为服务,通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务能够通过统一和通用的方式进行交互。SOA架构由服务总线、服务目录、门户、流程管理等几个核心组件构成的。这些核心组件协同工作共同支撑服务的部署、运行与管理监控。
a.服务总线
SOA集成平台通过企业服务总线(ESB)完成业务应用系统和其他系统的功能调用的统一接入,业务应用系统和公共功能作为标准服务在总线上公开,隔离服务消费者和服务提供者的技术实现细节,实现松耦合。
所有的服务调用均通过服务总线进行。但服务总线不保存服务信息,在运行时,它动态地会通过服务目录的查询接口,查询服务的路由信息、服务的访问权限、服务的优先级、服务的版本信息等,从而决定如何进行服务调用。
b.服务目录
服务目录主要用于保存运行时进行服务调用所需的必要信息,它要求能实现快速的服务寻址。服务目录保存的信息包括:服务的路由信息、服务的访问权限、服务的优先级、服务的版本信息等。
c.流程管理
业务流程通过流程设计工具,对服务进行编排,实现企业业务流程,生成可执行的业务流程服务,在业务流程引擎中部署执行。业务流程管理同时提供业务的管理和监控工具,进行业务流程的监控管理。
d.门户
门户作为SOA架构中展示层。门户可以对服务、流程、应用模块等进行组合,形成复合应用。门户同时也是展示服务(Portlets)的运行环境。门户对服务的使用和流程(以流程服务的形式)的集成也通过服务总线进行。
EAI和SOA的比较
a. 集成的本质
EAI的集成方式从本质而言是基于消息的集成,因此EAI的各组成部件,如适配器与hub,都带有消息转换与消息路由的功能,在EAI的运作过程中,单个应用系统只关心其与EAI连接部分消息的输入与输出,不关心具体的业务处理,业务处理都是在应用系统内部完成的。
SOA的集成方式,其本质是对业务功能服务化后根据业务流程进行编排,是真正意义上的基于功能服务的集成。当然在基于SOA的集成中同样包含了基于消息集成的功能。
因此基于SOA的集成方式比EAI的集成方式适用范围更广。(服务集成更加标准化,更加体现业务驱动)
b. 集成对象的颗粒度
SOA和EAI从不同的视角切入去看待企业已有的信息资源,并基于此对企业已有的资源进行梳理、分类和集成。
EAI从应用系统的层面去看待企业已有信息资源,企业的每一个应用系统被看作一个集成单元,EAI工作的目标就是,通过为这些已有的应用系统提供一种中间沟通方式,让这些应用软件之间可以进行数据的共享与交换,从而盘活这一个个独立的“信息孤岛”。
SOA从提供服务、使用服务的角度去看待企业已有的信息资源。在这种方式下,同样的一种资源既可能是服务提供者,也同样可以是服务使用者;在这种方式下,一个应用模块可能只提供一种服务,因此被封装成一个服务,也可能由于提供了多种服务,而需要进一步划分。
显然,SOA方式集成处理的颗粒度比EAI要小,因此SOA方式比EAI方式更具有灵活性。
c. 标准化
SOA在实现企业信息化集成的同时,也将实现企业级服务的高度可重用作为目标,因此,在SOA架构中任何一种接口、通讯、协议都是遵循相应的国际标准,如:标准描述语言(WSDL)、发现协议(UDDI)和消息协议(SOAP)等。
EAI 则大多使用基于具体实施EAI企业中制定的私有标准。基于私有标准的优点是可以在一定程度上减轻EAI中间层对应用系统消息翻译转换的压力,在应用系统较少的情况下可以提高EAI的整体性能,但私有标准同时也对企业整合的灵活可扩展性上带来损失,当企业引入新的应用系统,或当某个应用系统需要做比较大的改动时,整个EAI总线的适应性将变得十分脆弱。
在系统较少的情况下或是系统集成的早期阶段,采用私有标准的EAI会体现出性能高,实现难度低等优点,但在企业规模不断增长的过程中,新引入系统的整合难度将因为标准的不统一而呈指数级上升。
d. 灵活可扩展性
由于对标准的良好支持,使得SOA具有可灵活扩展的特性,而EAI要达到同样的扩展效果,其代价将远远高于SOA。例如,现在有甲、乙两个系统需要集成。假设它们通过SOA完成集成形成A方案,使用EAI完成集成形成B方案。当集成需求发生变化后,甲乙两个系统需要以另外一种业务逻辑进行集成。对于A方案而言,所需要做的工作比较简单,只需将之前的业务逻辑打开,重新组合一下业务逻辑就可以实现。而对于B方案而言,过程就会麻烦的多,需要根据新的业务逻辑,重新设计开发满足新业务逻辑需要的适配器和中间层的消息处理逻辑。
e. 重用性
企业信息化建设的投资可以分为两个部分:现有应用系统的维护与新系统的开发费用。在SOA架构下,各个服务是以完全独立的方式通过服务目录暴露在SOA集成平台上的,当新集成进来的应用系统需要使用现有的某个服务时,可以直接使用,无需再次开发,即服务是可重用的,只需用开发目前还没有的业务功能服务,这样可以充分利用现有的资源,降低成本。
通过EAI方式实现企业应用集成,其开发的适配器、中间层消息转换规则和消息路由都是紧耦合的,当新系统要在EAI中进行集成,便需要对现有的部分适配器、中间层消息转换规则与消息路由进行改造,无法重用。
因此,使用SOA比使用EAI更经济,尤其在多个应用系统相互集成的复杂场景下,SOA的优点将更加突出。
f. SOA企业服务总线与EAI总线的比较
ESB(Enterprise Service Bus企业服务总线)是一种用于推动SOA的基础设施,从技术上而言,企业服务总线是一种消息传递的主干线,它用于提供协议转换,消息格式的转换,地址路由,接收并分发从各个连接到ESB的服务请求与系统传递来的消息。
在 EAI的总线架构中,EAI为消息传播提供了一个中央消息主干线---Bus。应用程序使用适配器将消息发布到总线,消息通过总线流动到预订的应用程序中。总线是消息流动的通道,捆绑在应用软件端的适配器负责将消息在应用程序端的格式与符合总线标准的格式之间转换。因此,对于每一个应用程序,都需要单独为其开发符合应用程序自身要求的适配器,而由于没有遵循统一的标准,这些适配器是无法通用的。当某个应用系统进行比较大的改动时,则有可能存在对适配器的改造已经不能满足系统变更需求的情况,此时甚至有可能会牵涉到对BUS总线的修改,给企业信息架构带来很大的风险。
从ESB和EAI的总线工作过程上的区别可以看出ESB承担了更多的责任,做了更多的事情,为集成后的系统提供了完善、坚固的底层支持。而EAI的总线,只是一个消息的分发器。功能上的差别导致了系统集成到总线上的代价的巨大差异。
g. 系统集成的代价
SOA 架构中的企业服务总线与EAI中私有形式BUS尽管结构较为相似,但是在系统集成中却导致集成的成本代价却有很大的差别。这种在代价上的差异主要由两个方面的因素造成的,一是私有形式的总线提供很多产品套件式的内建函数功能,这些函数功能需要根据业务需求进行开发;二是很多的私有形式的总线采用专有的消息格式来提高性能,但却增加了系统开发代价。企业服务总线都是基于标准的。企业服务总线主要的优点就是相比集线器架构和基于产品套件的总线架构的支出要低,而且它是完全基于业界标准化。
另一个关键的不同是:ESB具有分散的和分布式体系结构,更加轻型的安装,而EAI遵从HUB-SPOKE体系结构,因而企业中进行多个大型应用系统之间的集成时,硬件成本高,扩展性也会相对比较薄弱。
总结
到目前为止,传统的编程技术所形成的软件系统都是刚性的。也就是说,一旦开发完成并投入运行,就是固定不变的,不能在使用过程中进行调整和改变。在业务流程中,软件系统严格按照预先设定的目标,各功能模块按照确定的顺序执行。如果数据结构或者业务逻辑发生改变,就必须对所有相关的软件模块、数据源和消息逐个进行修改。就算是有了EAI中间件,这种情况也并没有得到根本性的改变。
今天,SOA改变了这种现状。SOA采用服务请求(Service Request)的方式,使软件系统向“柔性化”迈进了一大步。与传统的软件系统不同,SOA只限定服务所需的信息并提出服务请求,但是不限定提供服务的模块。SOA架构替代EAI实现企业应用集成是必然的趋势,只有通过SOA架构来进行企业应用集成,才能使企业信息化快速、稳定发展。
这篇关于EAI和SOA比较的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!