EAI.docx
- 文档编号:30376529
- 上传时间:2023-08-14
- 格式:DOCX
- 页数:16
- 大小:89.11KB
EAI.docx
《EAI.docx》由会员分享,可在线阅读,更多相关《EAI.docx(16页珍藏版)》请在冰豆网上搜索。
EAI
一、企业应用整合
企业应用整合(EnterpriseApplicationIntegration,EAI)是企业为了要与企业内部甚至于将外部各独立的系统整合起来,主要的功能在解读并转换来自异质系统间不同应用程序的数据,它导入统一的工作流程藉以整合这些应用程序间的协同运作,提供了数据格式转换,同步或异步的自动流程处理。
除此之外,导入EAI还有增强传统系统(legacysystem)的效能,除了让封闭的系统能与Windows平台上的应用程序整合,尤其是互联网上的电子商务,还可增加异质系统上数据的使用率。
实施EAI的益处
EAI实施的益处,首先能够降低IT维护成本和开发成本。
以前,大多数组织通过编写大量代码来解决EAI的问题。
使用更好的工具可以降低初始投资和节省时间,且减少了以后的维护成本。
现在,所有的应用程序整合的问题都统一交给EAI服务器处理。
EAI服务器能处理应用程序间数据交换及格式转换问题,进行自动流程处理(流程中能进行决策、循环及分支等运算功能),同时进行监控。
其次是优化流程。
应用程序整合的主要目的,在于将不同系统间的执行过程连起来,让一项工作能在应用系统间有效的执行。
原先一份工作可能要经过好几个应用程序的处理才能完成,实施了EAI之后,各应用程序间流程管理能更合理、科学地运行。
通过将人工过程自动化来降低管理成本。
对每个企业中存在的大量人工过程进行自动化可以省去大量人员开支。
通过更高效的价值链过程降低运营成本。
对可以减少业务处理周期时间的关键价值链过程进行自动化可以降低很多方面的成本。
例如,更高效的供应链可以降低货运成本。
提供新服务,提高用户满意度和收入。
根据一项研究报告指出,当企业失去一个既有客户,需要找到五个新客户,才能弥补因失去旧客户所损失的利润。
目前企业为加强对既有客户服务,并增加对新客户的开发,纷纷投入建置客户关系管理(CustomerRelationManagement,CRM),而客户关系管理系统必须与既有的CallCenter、客户数据库、B2C网站及商业智能系统整合起来,如何以快速且低成本的方式进行,将是成功的关键。
EAI能帮助企业有效地解决这一难题。
通过推出新服务和节目来获得更高的客户满意度和忠诚度。
EAI项目本质上是为了比竞争者更快速地提供新信息和业务服务。
例如,如果使用EAI工具连接适当的系统后,则可更方便地进行关键在线客户的“自助”操作。
加速商业决策的过程----一个完整的企业应用整合必需要能考虑到延展性、可靠度、信息通透性、安全性及与异质平台整合能力,务必要达到让企业能保持既有信息技术上的投资,并延伸到企业内部所有角落。
透过企业应用整合,建构起完善的数字神经系统,让企业在外在或内在环境改变时能迅速应变,加速了商业决策的过程。
增强企业的灵活性和适应性---EAI的实施将会全面提升企业的竞争力,使企业能更顺应电子商务发展的需求,以及一体化经济的需求。
并且比没有使用的竞争对手更有优势。
实时管理事务活动查看历史性的交易。
更佳和更快的业务决策。
汇总业务信息并且使其近乎实时可用,可以从根本上使您比竞争者更快地进行更佳的业务决策。
二、企业应用集成的工具-消息代理中间件
消息代理中间件的作用
消息代理(MessageBroker)是一种在数据源与目的地之间移动数据使信息处理流畅的软件技术,数据源与目的地包括已有的应用、文件、数据库、对象(如CORBA、COM)、硬拷贝输出及Web客户端等。
消息代理技术实现之后的产品形式就是一种中间件。
作为面向消息的中间件(MOM)的一部分,消息代理中间件在企业应用集成(EnterpriseApplicationIntegration,EAI)中的作用日趋明显。
分布式环境下,业务单位四处散布,包罗万象的应用运行在不同的软、硬件平台上,消息代理中间件主要提供应用集成所必须的数据的递送、收集、翻译、过滤、映射和路由等功能,屏蔽不同的硬件平台、数据库、消息格式、通信协议之间的鸿沟与差异,提供应用到应用之间的高效、便捷的通信能力。
消息代理最典型的应用环境包括:
有许多程序,特别是混合多种语言;
多个数据源以及/或异构的数据库;
应用的生命周期期望在3年以上
处理的高吞吐量,复杂的系统设计
在客户/服务器天地中存在"老的"或者已有的应用
行将进行系统的增强、增加和修改
复杂的应用间的通信既有企业内部的通信,又有企业间的通信
GartnerGroup根据调查统计,企业在开发应用的过程中,30%-40%的费用都浪费在开发和维护与企业业务逻辑无关的各种接口上。
随着企业或企业间应用数量上的增加,应用间的通信接口日益增多,不同的平台、不同的语言与技术所带来的难度成倍的增长。
1996年,GartnerGroup就预测:
消息代理中间件由于降低了企业/机构内部应用的复杂交互,将变得和数据库管理系统、数据仓库一样重要。
归纳起来,基于消息代理中间件实现应用集成的主要理由有以下几个方面:
通过点对点的应用接口完成应用的集成复杂度高,花费大,严重地限制企业的灵活性。
消息代理中间件如同一个软件的HUB,连接需要交互的各个应用系统,减少了应用系统接口的数量、相互的技术依赖性。
应用与应用间传递的数据需要转换,传递需要按照优先级、实时地或批处理的方式进行。
消息代理中间件提供与各种资源的接口、数据转换能力和消息处理能力,高效地实现应用之间的消息传递。
复杂的业务处理逻辑带来应用间、应用与人之间交互的复杂性,要求提供一种支持流管理、处理智能化开发的简便性。
新一代的消息代理中间件以"商件(businessware)"形式,提供商务逻辑层开发能力。
集成应用的体系结构必须能适应业务逻辑、组织机构的变化,最大程度地减少对已有应用的修改。
消息代理中间件构造了一个基于消息的代理骨干,其基于API的适配器以及包装程序完全适应这一要求。
消息代理中间件的基本特征
构件化的结构
一个典型的消息代理中间件的基本结构见下图:
消息代理中间件一般不是单一引擎,通常由一组构件组成,基于构件的结构是消息代理中间件的关键特征。
构件化的结构能充分利用SMP和MPP技术,以增加吞吐量,同时也使环境是可伸缩的,可以根据需要配置不同构件。
多个消息代理引擎分布在多处但可以通过一点统一管理。
可恢复性、易于管理、灵活性等对关键软件结构的要求同样适合于消息代理中间件。
具有数据转换设施
消息代理中间件的核心是一个消息的路由程序,它接收和分发消息并基于预先定义好的消息处理流确保转发给正确的应用。
消息的路由程序通常能执行多段的路由("基于HUB的路由"),对于一个单个的消息,可以根据消息的源、目的地、类型等定义许多个处理段或对象。
对象可以包括消息的转换、数据的格式转换、查询数据库、记录日志和定时传送等。
应用间的互通可以是一对一、一对多或多向的。
消息代理中间件的核心还包括一个单独的通信与消息传递协议层,实现组织内部或组织间的实际的网络通信,有一个专门的消息格式库保存所有的消息定义,并提供建造和维护组织内部和组织间消息类型的工具。
路由程序最终通过这一层实现消息的接收与分发。
消息代理中间件的数据转换设施负责在应用之间对传输的数据进行转换,提供数据转换需要的API。
数据的规范化(normalization)或称数据的标准化,是使数据在交换过程中转换成标准状态的技术。
消息代理中间件有内置的数据规范化工具,替换一个应用时,不会影响到与其它数据交换伙伴的应用接口。
消息代理中间件的数据转换可以是实时的、接近实时的或批处理的。
批处理方式基于文件到文件的数据转换方式。
消息代理中间件有一个实时的请求/应答设施来执行同步的关键任务消息的处理,通过一个消息队列机制提供接近实时的数据转换。
消息代理中间件管理传递各个服务应用的并发路径,即使在企业需求最大时也能提供最佳的性能。
可靠高效的通信
消息代理中间件支持数据报和可靠传输("确保传输")通信方式。
可靠传输通信是基于消息队列机制的,发送和接收消息分别通过不同的消息队列。
对应用来讲,可靠传输确保"一次并且只有一次"的递送。
消息的传递可以选择压缩或/和加密传输方式。
消息代理中间件有消息优先级支持,高优先级的消息不必在队列中等待,可以优先得到处理。
消息代理中间件支持基于内容的消息路由,消息产生后按类型归类时,路经就确定了,消息代理能够根据消息的内容把消息路由到不同的目的点。
消息代理中间件能管理复杂的处理流,可以协调需要一系列复杂处理过程的交易处理,通过可配置的计时器和告警器处理异常的情况。
消息代理中间件内部的规则机制与可配置的计时器和报警器一起,确保交易处理的时效性,交易跟踪程序存储和显示检测单个交易的状态。
多样的管理能力
消息代理中间件的管理是分层次的,分别对应操作员和管理员。
运行界面提供了一个对消息代理运行的高层次的视角,保证消息代理的正常运作。
操作员可能不知道消息代理中间件运作的细节,管理员则可以控制消息代理中间件的每个方面,管理界面是给管理员支持操作员用的。
多个消息代理分布在多处但可以通过一点获得消息代理引擎的企业级的单一的视点,进行统一的管理,可以基于SNMP进行处理监控,可以使用浏览器运行管理系统
丰富的应用开发环境
消息代理中间件的开发环境主要涉及数据转换和与资源的接口的构造。
消息代理中间件提供灵活、高效的结构化的消息处理脚本语言(4GL)和其它面向对象的设计工具,支持基于对象的、3GL或是脚本语言来进行数据的转换。
消息处理脚本语言包含流控制、例外处理、数据抽取(基于SQL等)机制,能够灵活地构造高效的数据转换、校验、翻译和条件逻辑。
消息代理中间件提供便利的数据库访问接口,直接访问流行的关系型数据库和3GL接口
消息代理中间件的对象控制系统,提供企业级的开发与部署,允许大量的开发人员通过共享数据库并发地工作,从而最大限度地实现可重用性。
基于对象的开发结果,通常是消息代理中间件所支持的脚本开发语言。
脚本语言编译后生成的伪码可以在任意一个脚本语言环境(开发工具)中运行,保证了开发结果的可迁移性
应用测试可以离线进行,不必挂接到消息代理中间件上,引入新的应用接口或/和转换规则,也不需要停下消息代理中间件的运行。
消息代理中间件的另一个主要功能是与各种形式的信息资源接口,如果一个消息代理中间件只提供接口,但不提供建造这些接口的工具是完全不适用的。
消息代理中间件的开发环境是基于对象的,能够不用构造程序逻辑就建立与各种资源的接口。
消息代理中间件通常包括一些标准的接口,如SAPALE、HL7、FTP、LotusNotes等,如压缩包装的接口,构造接口的工具应支持TCP/IPsocket接口/SNACPIC接口/TTY接口/SQL接口/基于会话的接口/基于文件的接口/HTML接口等等。
完备的安全机制
消息代理中间件的安全控制,能识别冒名顶替者的消息。
消息代理中间件引擎,对来自接口、进行数据转换过程中的消息执行身份验证、授权和防抵赖处理。
消息代理中间件具有内置的数字签名功能,一组利用非对称秘钥或/和对称秘钥算法的安全功能的集合,可以在应用开发中调用这些功能。
数字签名基于非对称秘钥体系结构(PKI),可以有效地保证消息的完整性、发送方、接收方身份可鉴别以及不可抵赖性。
对称与非对称加/解密体制的结合,可以方便地实现消息在传输中的保密性。
未来走向
消息代理中间件作为企业应用集成的有效工具,发展极为迅速。
消息代理中间件一种新的趋势是,增加协同处理、处理自动化等"商件"(Businessware)模快,比较直观地支持在商务逻辑层上的应用集成与开发。
与商件的结合,是消息代理产品的一个重要的技术走向
三、EAI和Web服务-轻松进行企业应用集成
通过一个被Web标准支持的方法而不是一个有私有知识产权的系统,Web服务提供一个中立的平台来集成应用程序,从而被用于集成不同的应用系统。
依靠Web服务,企业能够实时地访问不同部门、不同应用、不同平台和不同系统的信息,这已是Web服务被接受的最重要和最有力的因素之一。
在企业"冒险"在B2B中使用Web服务实施应用集成之前,企业应当首先在他们内部的非面向事务的一般商业流程集成中使用Web服务。
本文所引用的资源主要包括两类,一类是Web服务的技术资源网站,包含了大量Web服务的技术信息,另一类是Web服务“stack"系列技术规范,他们是一个整体的技术体系,包括UDDI、SOAP、WSDL、XML等。
本文的最后给出了这些资源的链接,有兴趣的读者可以通过这些资源链接找到所需的内容。
我们知道,大多数企业都有由过去遗留下来的异构的系统、应用、商务流程以及数据源构成的应用环境。
应用环境的通信状况是混乱的,只有很少的接口文档,并且维护代价也非常的昂贵。
而数字时代市场的合并又提出了一些附加的问题,即公司的联合和兼并能够指数级的增加系统综合的复杂性。
当企业向B2B电子商务协作方向迁移时,他们首先要做的是审视他们内部的系统、应用以及商务流程。
一些商务流程会横跨多个内部应用,在企业能够有效的和外部网络连接之前,这些应用必须能够实时动态的进行通讯。
Figure1.点对点的B2B应用互联
随着诸如企业资源规划(ERP)、客户关系管理(CRM)、供应链管理(SCM)以及企业门户(EnterprisePortal)等多种商业应用的引入,激增了企业信息系统的应用分割。
早期这些系统被设计成自包含的"黒盒"系统,只有很少或者更本没有方法来访问它内部的数据和商务流程。
虽然现在许多这些应用都提供了更好的访问他们的内部数据和商业逻辑的方法,可是把这些系统和企业里其他系统集成仍是一个巨大的挑战。
Figure1的每一个节点都包含它自己的数据,而这些数据可能会在节点之间共享。
共享这些数据代表性的方法是通过数据传输方法,包括一批数据处理以及数据输入输出服务来完成。
之所以采用这种方法是因为一个节点的数据对其他节点来说不是实时存在的,而后者也不能在处理时分析和做决定。
什么是企业应用集成?
不断增长的客户和商业伙伴对实时信息的期望的持续增加,为了满足这种期望的需要,企业被迫连接他们的那些异构的系统来增加产出、提高效率以及,最终的,使顾客满意。
为使一个组织内部IT系统互相通信,导致了企业应用集成(EAI)的发展。
EAI通过建立底层结构,来联系横贯整个企业的异构系统、应用、数据源等。
EAI解决方案的起源可以追溯到那些提供双向的解决方案以完成在企业内部的ERP、CRM、SCM、数据库、数据仓库以及其他重要的内部系统之间无缝地共享和交换数据的需要。
Figure2.B2B企业应用集成
EAI不是一个能彻底解决最终问题的方案,他更可以说是正在建立一个灵活的、标准化的企业应用底层架构,可以允许新的基于IT的应用和商业处理能够更容易和更有效的被部署。
新的底层架构允许企业中的应用能够实时的,无缝的互相通信。
EAI的类型
EAI解决方案可以呈现许多种形式并以多种级别出现。
EAI合适的级别依赖于许多因素,包括公司的大小、公司的行业类别、公司应用的集成度或是项目的复杂度以及预算等等。
这里列出了EAI的中间件解决方案的4个类型:
用户界面集成数据集成商务流程集成函数/方法集成
当我们看到这些解决方案的类型,要注意的是我们在讨论解决方案的样式而不是具体实现。
用户界面集成(界面重组)
界面重组是一个面向用户的整合,他将原先系统的终端窗口和PC的图形界面使用一个标准的界面(有代表性的例子是使用浏览器)来替换。
一般的,应用程序终端窗口的功能可以一对一地映射到一个基于浏览器的图形用户界面。
新的表示层需要与现存的遗留系统的商业逻辑或者一些封装的应用如ERP、CRM以及SCM等进行集成。
企业门户应用(EnterprisePortal)也可以被看成是一个复杂的界面重组的解决方案。
一个企业门户合并了多个企业应用,同时表现为一个可定制的基于浏览器的界面。
在这个类型的EAI中,企业门户框架和中间件解决方案是一样的。
数据集成
数据集成发生在企业内的数据库和数据源级别。
通过从一个数据源将数据移植到另外一个数据源来完成数据集成。
数据集成是现有EAI解决方案中最普遍的一个形式。
然而,数据集成的一个最大的问题是商业逻辑常常只存在于主系统中,无法在数据库层次去响应商业流程的处理,因此这限制了实时处理的能力。
此外还有一些数据复制和中间件工具来推动在数据源之间的数据传输,一些是以实时方式工作的,一些是以批处理方式工作的。
下面列出了一些数据集成的方法:
批传输数据合并数据复制
析取、转换、装载解决方案(ETLSolution)
Figure3.ETLSolution
ETL解决方案(如上图所示),是基于ETL引擎的,从不同的应用程序析取、转换、过滤和装载数据到数据仓库和(或)数据市集。
现在ETL已经是企业实现数据集成的一个非常有效的途径。
商务流程集成
虽然数据集成已经证明是EAI的一个流行的形式,然而,从安全性、数据完整性、商务流程角度来看,数据集成仍然存在着很多问题。
组织内大量的数据是被商业逻辑所访问和维持的。
商业逻辑应用并加强了必须的商业规则、商务流程和安全性,而这些对于下层数据都是必需的。
商务流程集成产生于跨越了多个应用的商务流程层。
通常通过使用一些高层的中间件来表现商务流程集成的特征。
这类中间件产品的代表是消息中介,消息中介使用一个总线模式或者是HUB模式来对消息处理标准化并控制信息流。
下面的图示在一个较高的层次说明了一个开放的商务流程的组成:
Figure4.基于开放式商务流程的集成
函数/方法集成
函数和方法集成包括直接的和严格的,在网络环境中的跨平台应用程序之间的应用到应用(A2A)的集成。
它涵盖了普通的代码(COBOL,C++,Java)撰写、应用程序接口(APIs)、远端过程调用(RPCs)、分布式中间件如TP监控、分布式对象、公共对象访问中介(CORBA)、Java远端方法调用(RMI)、面向消息的中间件以及Web服务等等各种软件技术。
Figure5.函数/方法的集成
面向函数和方法的集成一般来说是处于同步模式的,即基于客户(请求程序)和服务器(响应程序)之间的请求响应交互机制。
Web服务
Web服务提供了一个分布式的计算技术,用于在Internet或者intranet上通过使用标准的XML协议和信息格式来展现商业应用服务。
使用标准的XML协议使得Web服务平台、语言和发布者能够互相独立,这是EAI解决方案的一个理想的候选者。
通过开放的Internet标准:
Web服务描述语言(WSDL,用于服务描述),统一描述、发现和集成规范(UDDI,用于服务的发布和集成),简单对象访问协议(SOAP,用于服务调用)和Web服务流语言(WSFL,用来定义工作流,这尚不是一个W3C标准),Web服务消除了现存解决方案(如CORBA和DCOM)中的互用性问题。
EAI和Web服务
Web服务不是EAI或者是EAI的一部分,更甚者,Web服务是另外一个技术,Web服务能够使EAI成为真正可能的、便捷实施的,同时又引人注目的解决方案。
Web服务能彻底地改变传统的EAI中点对点的集成处理方式。
使用Web服务,通过松散的应用集成,一个企业可以仅仅实现EAI的一个子集,即能取得实效。
与之相反,EAI要实现一个全盘的方案,来紧密的集成和联系支持公司业务的所有的系统和应用。
在公司内部不同的业务系统和技术单体中可能需要花费数年的持续的努力,高投资以及为之配备的充实的资源。
Web服务,以这样一种松散的服务捆绑集合形式(也可以说是一个特别得解决方案),能够快速、低代价地开发、发布、发现和动态绑定应用。
就当代Web服务的技术发展水平来看,Web服务可以实现应用程序之间的函数或方法级的集成。
他们不是自然的基于事务的,同时仅提供了基本的"请求/响应"功能。
然而,在下一代的Web服务中,在功能上和技术上都会更先进,将会提供用户接口封装和安全性,他们将能够包装一个应用程序并且把他嵌入到其他的应用程序中去。
现有的主要关注于应用集成的EAI解决方案将不得不因此而改变。
在将来,包装好的应用程序将使用如XML、SOAP、WSDL和UDDI技术来把他们的函数或方法作为Web服务的界面来显示。
因此,EAI解决方案将不得不提供一个对服务集成的广泛的支持,而不仅仅是应用集成。
传统EAI解决方案和Web服务之间的显著的不同
下面是传统的EAI解决方案和Web服务之间的一些基本的不同点:
(注意:
有一些不同点所描述的Web服务的特点可能并非是Web服务目前有的特性,而是考虑了Web服务被提议的未来的改进)
简单性:
毫无疑问,相比于典型的EAI解决方案(也许包括分布式技术如DCOM和CORBA),Web服务更便于设计、开发、维护和使用。
既然开发和使用Web服务的平台框架已经准备好了,创建跨越多个应用程序的商务流程处理将变得相对简单。
开放标准:
不像有所有权的EAI解决方案,Web服务是基于开放标准诸如UDDI、SOAP、HTTP的。
这个可能是导致Web服务被广泛接受的最重要的因素。
事实上基于现存的开放标准消除了企业潜在地为了支持新出现的Web技术的投资的需要。
灵活性:
既然EAI解决方案需要点对点集成,一端的改变必须告知另外一端,这自然使集成变得非常的生硬,同时也是浪费开发人员的时间的。
基于Web服务的集成是非常灵活的,因为他是建立在发布服务的应用程序和使用服务的应用程序之间的松散耦合。
便宜:
EAI解决方案,诸如消息中介,其实施是非常昂贵的。
而Web服务的实施则会变得便宜而快速。
范围:
EAI解决方案,诸如消息中介,把应用程序作为一个单个的实体来集成。
然而Web服务允许企业把大的应用划分为小的独立的逻辑实体并且包装他们。
举例来说,企业可以为一个ERP应用的不同的商业组件进行包装。
如订单管理、接受购买订单、订单情况、订单确认、帐户接受、帐户支付等等。
高效性:
已在前面几点提到的,Web服务允许应用程序划分为一些小的逻辑组件,因为在小粒度基础上集成应用程序,集成将变得更容易。
这也使Web服务的EAI解决方案比传统的EAI解决方案更有效率。
动态:
Web服务通过提供动态的服务接口来实施一个动态的集成。
然而传统的EAI解决方案都是静态处理的。
用Web服务的EAI示例
下面的Figure6显示了在一个在企业内使用Web服务的例子。
在这个例子中,在应用服务器中运行的企业门户从多个内部应用集成信息,并提供一个跨越这些应用的业务处理的入口点。
企业门户应用通过内部应用程序使用私有UDDI注册中心(PrivateUDDIRegistry)来获得可提供的Web服务的技术信息,并且在企业内部Intranet上调用这些服务。
一些经常被调用的Web服务的绑定信息将被企业门户应用缓存,这样得以避免花费在动态绑定上的资源和时间。
在这个例子里面,Web服务把企业门户和CRM、ERP应用程序松散的集成在一起。
Figure6.使用Web服务进行WAI的示例
流程步骤如下:
在登录企业门户之后,用户发出请求信息;
支持企业门户框架的应用程序通过浏览私有UDDI注册中心获得关于CRM和ERP应用的Web服务的技术;
Web服务的位置和WSDL绑定信息被穿送给应用服务器;
应用程序调用CRM应用发布的Web服务得到个人的信息,如名字、身份证号码、地址以及用户的Email。
这个通讯过程是基于SOAP交互的;
应用程序调用ERP应用发布的Web服务获得银行帐号信息,诸如银行帐号号码,结余和用户交易历史记录。
这个通讯过程也是基于SOAP交互
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- EAI
![提示](https://static.bdocx.com/images/bang_tan.gif)