（计算机软件与理论专业论文）基于hubandspoke模式的企业应用集成方案研究与实现.pdf

塑蜘厶堂亟堂焦垒塞垄! ! ! 二血i 二i p ! 堕蕉式的垒些生旦墓盛直塞壁塞皇塞强 y ，6 3 孑7 霪i 摘要 企业中各个系统使用各自不同的编程语言和系统平台工作，数 据存在于一个个信息孤岛中，无法实现数据的共享和交换。怎样将 这些独立的应用集成起来，在平台和操作系统之间实现无缝互操作 是企业面临的主要问题之一。企业应用集成( e n t e r p r i s ea p p l i c a t i o n i n t e g r a t i o n ，简称e m ) 正是这个问题的解决方案。本文对e a i 的产 生和发展现状进行了简要介绍，并对现有e a i 解决方案及其性能进 行了研究。而后针对现有解决方案的不足，结合e a i 的构架模式 ( a r c h i t e c t u r ep a t t e r n ) ，提出了一种基于h u b a n d s p o k e 构架模式 的e a i 解决方案，并对该方案进行了总体设计和实现。最后给出一 个实际应用该e a i 方案的例子。 关键词：企业应用集成区域集成服务器h u b a n d s p o k e 挫刿盍堂亟堂焦迨塞 堑壬丛! ! 二丛i 二! 卫! 睦送耋煎垒些应旦堡盛直塞盟窒皇塞班 a b s t r a c t e a c hs y s t e mu s ed i f f e r e n tp r o g r a m m i n gl a n g u a g e sa n do p e r a t i n g s y s t e m s ，d a t a o f t e ne x i s ti ni s o l a t e di s l a n d s d a t as h a r ea n de x c h a n g ei s n o ta f f o r d a b l e h o wt o i n t e g r a t i o n t h e s e d e p e n d e n ta p p l i c a t i o n s a n d r e a l i z ei n t e r o p e r a b i l i t ys e a m l e s s l yi sam a i np r o b l e m f a c i n gt oe n t e r p r i s e i n f o r m a t i o ns y s t e m e n t e r p r i s e a p p l i c a t i o ni n t e g r a t i o ni sj u s tt h es o l u t i o n t ot h i sp r o b l e m t h ee m e r g e n c ea n dc u r r e n td e v e l o p m e n t a ls t a t eo fe a i a r ei n t r o d u c e df i r s t ，t h e nt h i sp a p e rg i v e st h es t u d yt ot r a d i t i o n a le a i s o l u t i o na n di t s p e r f o r m a n c e a f t e ra n a l y z i n g t h el i m i t a t i o n so ft h e t r a d i t i o n a ls o l u t i o n sa n d c o m b i n i n g t h ee a ia r c h i t e c t u r ep a t t e mw i t ht h i s p r o b l e m ，t h ep a p e rp r e s e n t s a ne a is o l u t i o nb a s e d h u b - a n d s p o k e p a t t e ma n dp r o v i d e st h ed e s i g na n di m p l e m e n t a t i o no ft h ee a is o l u t i o n i nt h ee n d ，w e g i v ea c o n c r e t ee x a m p l e k e y w o r d s ：e a iz i s h u b - a n d s p o k e i i 塑趔盘堂亟堂焦逢塞 茎出! b 二! ! i 二! p ! ! ! 塑丛数垒、业虚旦堡盛直塞堡窒皇塞避 1绪论 1 1 与本课题有关的研究开发现状 在信息化建设过程中，企业信息系统往往由于最终用户需求的阶段性和部 门信息系统的独立性，造成了硬件平台、数据库和网络的异构，从而使企业范 围内的数据存取、管理和应用开发遇到了一定的困难。同时由于没有统一的标 准格式，各系统间不能实现有效的共享，形成了一个个的“信息孤岛”，导致 了低水平的重复开发，浪费了大量的人力物力；因此怎样集成企业的应用系统 以便实现无缝的互操作成了摆在企业面前的亟待解决的问题，企业应用集成 ( e n t e r p r i s e a p p l i c a t i o ni n t e g r a t i o n ，简称e a i ) 正是在这种情况下应运而生的。 企业应用集成先后经历了a p p l i c a t i o n t o - a p p l i c a t i o n ( 简称a 2 a ) 、 b u s i n e s s t o b u s i n e s s ( x ) ( 简称b 2 b 或b 2 x ) ，实现方法和技术在变，但是 它的目标一直都没变。企业应用集成的目的是实现在企业范围内外任何相连 的应用系统和数据源间无限制地分享数据和业务过程。它通过一系列软件技术 实现对“信息孤岛”的连接、交互和集成，对各种分布、异构的数据资源进行 全局、统一、高效的访问和管理，为各种应用和决策支持提供一个良好的数据 基础。 企业应用集成同i t 领域的大多数技术相比较，发展和变化非常迅速。在集 成广度上，它可以从单个部门延伸到整个企业，甚至更广阔的虚拟企业：而集 成深度上，它可以从数据集成拓展到应用系统集成和业务流程集成。 目前，我们通常采用p o i n t - t o p o i n t ( 简称p 2 p ，点对点) 方式来进行应用 的集成。在p 2 p 模式中，通过特定的交互接口连接两个应用。p 2 p 模式有多个 点对点接口和多种数据格式，不利于资源的共享。当我们增加或者更改一个应 用时，每一个与之关联的连接必须重建。当交互的应用数目增多时，脆弱的连 接和定制的接口将终止作用，这必将引起当任何种类的应用被改变或者引入时 花费更高的集成费用【2 1 。因此，迫切需要一种新的e a i 方案来代替p 2 p ，更好 的实现企业应用问的集成。 塑型盍生亟堂僮迨窒 基王旦! ! ! 二! ! i 二1 2 1 堕搓丛的垒些应出筮盛直塞堡塑兰塞丑 1 2 本课题的来源、目的和意义 本课题来源于北京大学软件工程国家工程研究中心的电子信息产业基金项 目“青鸟分布式应用集成框架”，研究了基于h u b a n d s p o k e 模式的e a i 方案 以及该方案的设计与实现：在本课题基础上研发的基于h u b a n d - s p o k e 模式的 e a i 方案已经投入到奥组委网上招聘系统和朝阳区组织干部管理系统使用并初 见成效。 基于h u b a n d s p o k e 模式的e a i 方案主要通过实现一个与操作系统和语言 无关的集成平台，来对企业现有系统进行集成。现有系统不需要改变就能够加 入集成系统，实现企业内甚至企业间资源和信息的共享，该方案可以优化企业 内部进程，缩短产品的市场化周期，达到提高企业产品开发能力的最终目标。 系统的实现具有十分重要的理论意义和实践意义： ( 1 ) 扩展了关键遗产应用的生命期，缩短了产品的设计、开发周期，为提 高产品质量提供可靠的前提条件。 ( 2 ) 使维护和管理人员从繁重的重复劳动中和手工劳动中解放出来，能有 更多的时间从事新设计、新产品、新方法的研究。 ( 3 ) 提高了供应链的效率，扩展了企业的能力，改善了系统服务，提高了 企业标准化水平，全面减少了i t 花费。 ( 4 ) 以先进的技术为基础，利用先进的现代通讯技术和计算机处理技术， 同时，以浏览器和服务器作为基本运行环境，对技术资料实现计算机综合管 理，实现产品信息共享。 1 3 本课题研究的主要内容 本课题研究的主要内容是提出一种优于p 2 p 的新的e a i 方案基于 h u b a n d s p o k e 模式的e a i 方案，来实现异构数据系统间的信息共享，并对该 方案进行设计以及实现，开发出一个能够解决分布式异构应用集成的基础架 构。我们主要考虑以下几方面的内容： ( 1 ) 研究e a i 的现状以及现有解决方案的弊端。包括e a i 的概念、分类以 及目前存在的构架模式，同时对现有方案进行分析。 4 塑刿盘堂亟堂焦迨塞基王丛! b = 血i 二! p ! ! ! 夔煎鲍垒些蜒旦基盛直塞婴塞皇塞埋 ( 2 ) 针对现有解决方案的弊端， 于h u b - a n d s p o k e 模式的e a i 方案， 工作原理和各个组成部分的设计。 结合实际的应用系统，提出我们自己的基 并对该方案进行总体设计。包括该方案的 ( 3 ) 实现方案的核心z i s ( z o n ei n t e g r a t i o ns e r v e r ) ，包括消息传输机制、 消息服务机制、管理机制和数据库服务机制四个模块。 1 4 作者在课题中所做的工作 在本课题中，作者主要参与完成了以下工作： ( 1 ) 集成框架的调研、论证。研究了基于h u b a n d s p o k e 模式的e a i 方案 的工作原理，确定其作为解决实际应用集成的解决方案。 ( 2 ) 方案中核心部分z i s 的实现、部署、安装和维护。开发实现了具体的 r e q u e s t 和r e s p o n s e 消息流程。 一 ( 3 ) 确定具体集成方案。包括确定具体应用系统中的数据对象以及消息格 式。确定代理应该实现的功能以及维护的数据。 1 5 论文章节安排 本文的内容组织如下： 第一章：绪论，介绍本课题的来源、研究目的、意义以及主要内容和作者 所做的工作。 第二章：详细介绍企业应用集成，介绍了e a i 的概念，总结了e a i 的分 类。同时针对现有e a i 方案的弊端，结合构架模式，提出了一种基于e a i 架构 模式的解决方案，并指出其优点。 第三章：详细介绍基于h u b a n d s p o k e 模式e a i 方案的总体设计，其中包 括方案中涉及的关键概念以及主要构件的设计。 第四章：详细介绍基于h u b a n d s p o k e 模式e a i 方案中核心平台区域集成 服务器z i s 的实现，并对实现系统做了简介。 第五章：具体应用该方案的例子，详细介绍了方案中的一个可变部分“代 理”的实现。 第六章：对本文的总结。 塑型盍生亟堂笪丝塞垄王鲢! 丑! g 二2 殳虹塑基盟垒些虐旦墓礁友塞鲤窥当塞堡 本文针对e a i 现有解决方案的弊端和软件构件化的发展趋势，提出了一种 基于h u b a n d s p o k e ( e a i 架构模式的一种) 的e a i 方案，并对该方案进行了 研究和实现。 塑划厶翌亟圭芏焦适塞基王h 业= 皇! 自= q ! 蛙楚墓曲垒些堡旦堡盛直塞盟筮皇塞塑 2e a l 技术研究及本文方案的提出 企业应用集成是一个快速发展的领域，造成这一趋势的因素有多种。这些 因素来自于i n t e m e t 、企业并购和合并，以及激烈的竞争带来的商业需求的快速 变化，不断增长的客户和商业伙伴对实时信息的期望的持续增加，为了满足这 种期望的需要，企业被迫连接他们的那些异构的系统来增加产出、提高效率， 以及最终使顾客满意。简而言之，为使一个组织内部r r 系统互相通信和资源共 享，导致了e a i 的发展。 2 ，1 e a i 技术简介 e a i 的相关内容较多，在参考文献 3 中有一系列对其较详尽的描述，参考 文献e 4 5 中分别对e a i 的作用和e a i 在遗产系统交互中的用途做了简要介 绍，参考文献 6 7 分别描述了e a i 面临的挑战以及e a l 方案中涉及到的模 式，同时在文献 8 和 9 中c l a r i t y 公司实现了自己的e a i 框架并对其进行了阐 述a 在此，我们只对企业应用集成的概念、分类及实现时需要注意的一些关键 点进行一下介绍。 2 1 1e a i 的概念 目前，国内外许多学者对e a i 进行了大量研究，到目前还没有一个权威的 定义【l o 】。下面给出一些研究者对于e a i 的定义： 定义1e a i 是一种全新的战略企业解决方案，它利用通用的中间件融合了 企业已有应用软件、商业封装式应用软件以及新代码三方面的功能【1 1 】。 定义2e a i 构成了一个基础框架，将全异的系统组织集成为一个单一实 体，在合作伙伴、顾客以及店员之间实现信息共享【”。 定义3 使组织者能够建立一个技术基础结构，无缝的连接异构的商业应 用，形成一个统一的系统，数据和处理能通过该系统在合作伙伴、顾客以及别 的股东间共享l 。 定义4 它是集成多个独立开发的、使用不相容的技术和独立管理单元的计 算机应用的过程【1 4 】。 7 塑刿盘主亟望熊迨塞垫盐b 二堑d 乜! 虹攫丛啦垒、业廑! 王| 塞盛友塞婴塑蔓塞丑 定义5 企业应用集成就是将企业内部不同的、相互之间相对独立的软件集 成起来，并且在集成过程中应当不影响应用软件本身【1 5 l 。 概括上述定义，可以发现e a i 具有以下几个特点： ( 1 ) 是一个基础框架 ( 2 ) 能够实现异构的商业应用间的无缝连接 ( 3 ) 能够将独立的分布式应用集成为一个整体 ( 4 ) 实现系统间的信息共享 上述特点是e a i 所具有的特点。e a i 技术在今天被认为是企业获得成功的 关键所在，将一个机构的所有的信息资源集成到一个无缝的、并列的、易于访 问的企业资产中，这样可使一个功能强大的企业资产运作起来就像一个虚拟的 单_ 系统。e a i 通过建立底层结构来联系横贯整个企业的异构系统、应用、数 据源等，完成在企业内部的e r p 、c r m 、s c m 、数据库、数据仓库，以及其它 重要的内部系统之间无缝地共享和交换数据的需要。 2 1 2e a i 的相关分类 我们通常按照应用集成所使用的工具和技术将e a l 分为五个层次：平台集 成、数据集成、构件集成、应用集成、业务过程集成【1 3 【1 6 】【1 7 】。 平台集成 要实现系统的集成，底层的结构、软件、硬件以及异构网络的特殊需求都 必须得到集成。平台集成处理一些过程和工具，以保证这些系统进行快速安全 的通信。电子商务对企业数据交换平台建设的要求是能容纳多种网络技术、支 持多种协议、具有高度的可靠性和安全性、管理能力强、界面友好等。对象请 求代理( o r b ) 、远程过程访问( r p c ) ，远程方法调用( r m i ) 都是今天平 台集成的技术。 数据集成 为了完成应用集成和业务过程集成，必须首先解决数据和数据库的集成问 题。在集成之前，必须首先对数据进行标识并编成目录，另外还要确定元数据 模型。这_ - - - 步完成以后，数据才能在数据库系统中分布和共享。数据集成提供 签! ：! j 盍堂亟兰鱼垒塞 基h ! 二四二s ! 鲢搓基塑垒些鏖旦塞盛直塞丛塞皇型壁 了避开应用逻辑来直接获取和提交数据的工具。通过数据库网关、提取传送工 具和报表产生工具来实现。 构件集成 构件集成提供了现存的e r p 包和遗产系统的简单的耦合新服务。这通过应 用服务器有效的处理。构件集成能帮助添加g i s 到其他的企业信息系统，例如 顾客信息系统和企业资源计划等。 应用集成 为两个应用中的数据和函数提供接近实时的集成。在一些b 2 b 集成中用来 实现c r m 系统与企业后端应用和w e b 的集成，构建能够充分利用多个业务系 统资源的电子商务网站。应用集成更加接近于实时的集成。应用集成结构包括 基础的平台集成、数据翻译、传送和基于规则的路由，应用接口集成和应用自 身的集成。这主要应用于应用间共享数据的集成。例如，我们升级地址管理系 统为了分析犯罪模式和投票注册，集成大量的遗产系统和新的客户同时支持未 来的网络应用，需要大量额外的努力。单个灵活的平台保证了数据连通性和数 据完整性，通过不停的改变硬件和应用来维护实时的网络。应用集成通常分为 单步应用集成和多步应用集成。 业务过程集成 当对业务过程进行集成的时候，企业必须在各种业务系统中定义、授权和 管理各种业务信息的交换，以便改进操作、减少成本、提高响应速度。业务过 程集成包括业务管理、进程模拟以及综合任务、流程、组织和进出信息的工作 流，还包括业务处理中每一步都需要的工具。这个集成使业务员通过不同的应 用去定义、改变和处理信息流。这个解决方案可以作为e a i 集成的一部分或者 一个插件。 事实上，e a i 技术和内容从不同的角度有不同的分类方法。从应用集成的 对象来划分，可以分为面向数据的集成和面向过程的集成；从企业组织角度， e a i 可分为水平的组织内的集成、垂直的组织内的集成和不同组织间系统的集 成【1 8 】。 对于这些诸多的集成概念，可以从广度和深度两个维度来将其进行总括。 从集成的广度上来说，从最初的部门内集成到部门问的集成，及到今天的企业 塑删叁堂鲤堂焦适窒 基王h ! b = 血d 二匹生燕丛丛垒些生旦生盛直塞型童量塞丑 范围内和企业间的集成。从集成的深度上来说，从易到难有以下种类的集成： 表示集成 表示集成是最简单的集成方式之一。通过遗留软件的现有表示来集成新的 软件。通常用来创建一个新的用户界面，也能用它来与其他软件进行集成。 数据集成 数据集成的基本思想是对各种软件组件的数据存取进行集成。通过直接访 问软件所创建、维护并存储的相应信息来实现软件集成，这样做通常是为了在 应用软件之间实现数据的重用和同步。 功能集成 功能集成在代码级上实现软件集成，这可能在对象或过程级别上实现。它 的目的在于从其他新的或现有的软件中调用现有功能，这种集成可以通过软件 接口实现。 ， 2 1 3e a i 实现中的关键点 特定企业应用集成实现时必须注意的一些关键点如下： ( 1 ) 一个重要的决定在于选取消息范例，如果公司正在寻找i n t e m e t 上应用 间的分布式信息，消息中间件是值得考虑的。这个解决方案支持多重客户端和 异构的操作系统、数据库和应用。 ( 2 ) 企业消息架构的另一个要素是考虑网络协议的选择。i n t e r a c t 企业里的 应用，最好采用t c p i p 消息系统；企业内部的局域网，口多播将是一个较好的 选择。 ( 3 ) x m l 能用来描述结构化的数据并且通常是合适的。 ( 4 ) 另一个方面是路由处理。许多e a i 采用请求应答，发布订阅路由， 基于内容和逻辑地址的路由。 ( 5 ) 传送引擎被需要。当在源和目的之间变更消息内容时，传送引擎需要 遵循事件驱动的内容合并和分割原则，需要支持x m l ，需要支持从一个源但不 同时间的多记录，支持多个源等。 塑刿占芏墅生笪逢窒 基王盟! 二! d 二卫韭! 塑丛啦企墼廑删堡盛直塞盟塞皇基盟 2 2f ：a i 架构模式 2 2 2 现有e a l 方案弊端 传统的组织模式是按照职能来划分各个部门的，例如公司被划分为市场 部、技术支持部、开发部、人力资源部门等。各个部门根据各自的需要选择相 应的1 t 支持系统，没有考虑系统间的交互，这就导致了企业内部各个职能部门 之间形成了一个“烟囱式”的结构，相互间缺乏信息交流【1 9 】。“烟囱式”应用 能实现具体的企业目的，然而由于它们并不与其他应用相互操作，所以“烟囱 式”系统对于集成来说是一个重大挑战。 图2 1 “烟囱式”结构 通常我们采用p o i n t - t o p o i n t ( 简称p 2 p ，点对点) 方式来进行上述应用的 集成。在p 2 p 模式中，通过特定的交互接口连接两个应用。在特定的操作系统 平台上、特定的集成开发环境下、基于特定的数据表达格式，进行特定应用软件 系统的开发，很少考虑应用的可集成性、可重用性、可定制性、可移植性，造 成了众多软硬件平台、各类应用系统并存的局面。当众多系统问需要信息共享 时，往往以某一个或某几个关键应用系统为主，基于系统提供接口进行二次开 发，在需要共享信息的系统间由特定的程序员提供复杂的访问接口，与其它系 统进行整合，是一种复杂系统对接的模式。假定企业中有n 个系统需要共享数 据资源，那么需要特定的程序员开发复杂的接1 3 就有n 2x ( n 一1 ) 个甚至更多 的接口，于是，企业不得不为每套应用配置特有的专业技术维护人员，并保持 与不同技术供应商的密切联系，接口的复杂性和大量化以及不同技术供应商之 间的工作协调往往使企业望而生畏，结果往往形成了众多的数据孤岛和小规模 的紧密集成。由于这种方法对某一个或某几个系统的过分依赖，没有站在企业 塑蜘厶堂亟生坐焦迨塞 茎三e 丛! b 二旦t 二目韭! 撞式麴垒些应坦堡丝直塞受童量塞理 应用集成这个全局的高度，很难从根本上解决企业面临的信息共享问题，不能满 足企业信息化进程的要求。随着企业信息化的进展，新的应用部署需要考虑新 的接! e l 开发，应用的每次更改都必须由特定的程序员来完成众多复杂接口的升 级，随着企业应用系统的增加以及需要共享信息范围的扩大，这个问题变得越 来越尖锐，于是产生了应用中普遍存在着的软、硬件平台异构问题，导致了国外 引进、国内购置和自主开发的多种多类系统并存的局面，在某种程度上阻碍了 企业信息化的进程，客观上迫切需要一种有效的企业应用集成新方法。另外， 传统的应用开发模式与系统集成方法不利于企业基于i n t e r n e t 面向敏捷供应 链向企业上、下游合作伙伴扩张，不利于和动态电子商务接轨，不利于实现企业 外部市场利益驱动、企业内部资源优化配置的信息系统集成，难以达到快速响 应的目的瑚 【2 1 l 。 p 2 p 模式以及集成点随应用的增长情况如图2 2 所示： 图2 2p 2 p 方式及集成点随应用的增长情况 2 2 2 构架模式的提出 软件复用是近年来研究的热点，由于软件复用技术有助于提高软件开发的 生产率，提高软件系统的可靠性，减少软件维护的负担，因而大专院校、研究 所、企业界和政府部门都很重视软件复用的研究和实践【2 2 1 。 软件构件技术是支持软件复用的核心技术，构件是指应用系统中可以明确 辨识的构成成分，可复用构件是指具有相对独立功能和可复用价值的构件。随 着对软件复用的理解，构件的概念己不再局限于代码构件，而是延伸到需求、 系统和软件的需求规约、系统和软件的构架、文档、测试计划、测试案例和数 据以及其他对开发活动有用的信息。近几年来，软件构架技术得到迅速发展， 成为受到高度重视的一个学科分支。 塑刿厶堂塑堂焦迨塞 基王h ! ! 尘! ! 二! p 些! 攫式鲢垒些廑届基应友塞班煎兰塞埋 软件构架是对系统整体结构设计的刻划，包括全局组织与控制结构，构件 间通讯，同步和数据访问的协议，设计元素间的功能分配，物理分布，设计元 素集成，伸缩性和性能，设计原则等【1 。 研究软件构架对于进行高效的软件工程具有非常重要的意义：通过对软件 构架的研究，有利于发现不同系统在较高级别上的共同特性：获得正确的构架 对于进行正确的系统设计非常关键；对各种软件构架的深入了解，使得软件工 程师可以根据一些原则在不同的软件构架之间作出选择；从构架的层次上表示 系统，有利于系统较高级别性质的描述和分析。特别重要的是，在基于复用的 软件开发中，为复用而开发的软件构架可以作为一种大粒度的、抽象级别较高 的软件构件进行复用，而且软件构架还为构件的组装提供了基础和上下文，对 于成功的复用具有非常重要的意义【2 4 1 。 软件构架研究如何快速、可靠地从可复用构件构造系统自q 方式，着重软件 系统自身的整体结构和构件间的互联。其中主要包括：软件构架原理和风格， 软件构架的描述和规约，特定领域软件构架，构件向软件构架的集成机制等。 综上，构架模式( a r c h i t e c t u r ep a t t e r n ) 逐渐成为i t 业界人士用来处理复杂 问题的一种重要方法。当然，e a i 问题也不例外，它也有一套解决应用集成复 杂性的构架模式。e a i 构架模式提供了对e a i 在结构上的一种视图，是成功的 实施e a i 的一个基础。这些模式帮助i t 人士选择合适的方案和工具来扫除应用 集成的障碍和困难。 与设计模式的作用类似，e a i 构架模式也是为了提高应用系统的重用性和 灵活性的一种设计方案。构架模式和设计模式不同的地方是：构架模式指明的 是系统级的结构属性，并且会对子系统的结构产生影响；而设计模式却不会影 响子系统的结构。e a i 构架模式对于快速变化的商业时代来说是至关重要的。 只有这种可变性强的i t 集成方案才能跟上业务变化的步伐。 e a i 构架模式主要是针对系统或者应用程序的整体结构。构架模式被定义 为软件系统的基础的结构化模式。它提供了一系列定义好的子系统，定义了它 们之间的关系和组织这些关系的规则。e a i 构架模式的共同特点是解耦将 系统之间的相互依赖最小化，这样就提供了更好的灵活性和更强的独立性。 3 塑刿厶生亟土星世逢裹 茎h ! b = 卫女二p ! 虹燕萎鲢垒些逝旦堡盛立塞盟窒皇塞丑 2 2 3e a i 的构架模式 目前存在的e a i 解决方案的构架模式主要有h u b a n d - s p o k e 模式和 m e s s a g eb u s 模式【矧。在此我们对这两个模式进行简要介绍，并对两者进行简 要的比较，指出各自的适用范围。最后对采用e a i 构架模式的解决方案和现有 的e a i 解决方案进行了比较，指出了采用e a i 架构模式的优点。 ( 1 ) h u b a n d s p o k e 模式 在h u b a n d s p o k e 结构中，应用程序通过一个中央的s e r v e r 相互连接，这 种结构实现了“s e n da n dr e c e i v e ”的解耦。如图所示，各种关系数据库、客户关 系管理系统等不同的应用通过a g e n t 与中央s e r v e r 相连，此时这个s e r v e r 就像 一个h u b 一样。中央s e r v e r 主要负责消息的传送，起到一个m e s s a g eb r o k e r 的 作用，负责管理通信、数据的传送和处理多个接入系统之间的交互。一个新的 系统或应用程序若要和其他的应用相集成，只需要通过一个a g e n t 接s e r v e r 就 能够与其它的连接到s e r v e r 的应用相连接了。 图2 3h u b - a n d - s p o k e 模式 ( 2 ) m e s s a g eb u s 模式 在信息总线结构中，所有的节点都通过一个a d a p t e r 连接到集成s e r v e r 上，元数据库、关系数据库、各种管理系统和集成s e r v e r 通过一个公共通信主 干连成一串。在相互连接的应用之间传递的消息通过总线送至集成s e r v e r ， s e r v e r 主要负责数据的传送、转换和至接收节点的路由。信息总线提供了消息 传送至目的地的媒介。 塑! ! 盘堂亟堂焦迨塞基旦女b 二丛自蔓q q 虹撼真数企些虞旦篡虞直塞盟窒皇塞堡 图2 4 m e s s a g e b u s 模式 ( 3 ) 两种模式的比较 h u b - a n d s p o k e 模式中的中央s e r v e r 可以被集中控制，管理起来比较容 易，同时它带来另一方面的弊端，就是集中式的方法容易使s e r v e r 成为系统的 瓶颈，而且s e r v e r 一旦崩溃，整个系统就不能运行。m e s s a g eb u s 模式中集成 s e r v e r 只是起到了一个控制的作用，真正的传输是在信息总线上，集成s e r v e r 的负荷就轻了许多。然而它的实施难度要比h u b a n d s p o k e 模式复杂的多，整 个环境的控制系统也比较复杂。 h u b - a n d s p o k e 模式和m e s s a g eb u s 模式各自的优缺点决定了它们各自的 适用范围。h u b - a n d - s p o k e 模式适用于中小型企业，这些企业内的资源有限并 且整个集成环境中只包含少量的应用系统，这些应用之间的事务处理保持在一 定的限度内。m e s s a g eb u s 模式适用于规模较大的环境中，有几十个甚至上百个 系统间频繁的进行数据交互的系统。 ( 4 ) e a i 构架模式和点对点方案的比较 e a i i n d u s t r yc o n s o r t i u m 针对e a i 和点对点设计方案做了一个试验，结果如 下面图2 5 和2 6 所示：最初，配置e a i 和e a i 发展花费的天数比传统的点对 点方法多。随着时间的推移和系统所需新功能的增加，用e a i 技术开发表现出 了显著的功能，所花费的天数远远小于点对点花费的天数，从长远观点看集成 花费远远低于点对点方法【1 9 。 塑丛盘堂亟兰焦迨皇 基旦! 旦尘1 4 王目! 韭塑塞塑全些廑旦塞盛直塞班塑生塞塑 3 0 2 5 2 0 1 5 1 0 5 0 1 4 1 2 1 0 8 6 4 2 o s t r a t e g yd e s i g n c o n s t r u c t i o n t e s t l a gr o l l _ o u t 图2 5e a j 与点对点在第一个集成阶段花费的天数对比 s t r a t e g yd e s i g nc o n s t r u c t i o nt e s t i n gr o l l _ o u t 图2 6e a i 与点对点在第二个集成阶段与以后的阶段花费的天数对比 2 3 基于h u b a n d s p o k e 模式的e ai 方案 我们通常开发的系统规模较小，整个集成环境中只包含少量的应用系统， 因此，我们选择h u b - a n d - s p o k e 模式作为解决方案。 采用h u b - a n d s p o k e 模式的e a i 框架结构通常如图2 7 所示，不同的应 用程序都通过代理( a g e n t ) 与中央的区域集成服务器( z o n ei n t e g r a t i o ns e r v e r ， 简称z i s ) 相连接。此时z i s 作为区域的“中枢神经系统”，就像一个h u b 一 样，推动应用间的交互和调节它们的活动。它负责数据翻译、传送和基于规则 的路由，起到一个消息代理( m e s s a g eb r o k e r ) 的作用。一个新的应用若要和其 他的应用相集成，只需通过一个a g e n t 接入z i s 即可实现( 此处a g e n t 相当于 h u b - a n d s p o k e 模式中的a d a p t e r ) 。 该e a i 方案包括三个部分：z i s ，代理和集成区域。区域是一个逻辑的实 体，即集合了不同应用程序之间麸享部分的一个逻辑实体，区域可大可小，对 于区域的划分是灵活的，区域可以单个建筑、单位、几个部门等。该方案能够 使不同应用程序可靠、有效、安全地交换数据。在这里，有效意味着信息互操 作框架必须支持不同应用程序之间的实时数据交换，并且逻辑的区域有很好的 塑划盔生亟堂焦监塞基壬h 业二! 生二卫! 鲢搓丛鲍垒些堕旦堡丝直墨盟基皇塞翌 可伸缩性；可靠是指当一个应用程序向另一个预定接收器发送消息时，必须保 证收到；消息到达该接收器的顺序与发送他们的顺序相同，正常情况下每份消 息只发送一次。安全；发送的每份报文必须加密并确认是限制访问指定的应用 程序发送的。 广- 、 l 斜1i 鬻罗 魏s 叵岭 图2 7 基于h u b a n d - s p o k e 模式的e a i 框架 2 3 1 7 1 s 和代理的职能和结构 z i s ：z i s 是实施应用集成服务器的物理实体，对所有已注册的代理提供集 成服务，负责所有的访问控制和系统内部的路由并管理区域中的所有共享数据 的程序。z i s 用消息服务机制、消息传输机制、管理机制以及配置和存储机制 来保证上述功能的实现( 如图2 8 ) 图2 8 z i s 结构 代理；代理是每个符合互操作框架的数据、消息规范的应用程序的接口程 序，它是应用程序的扩展，它的任务就是使应用程序和z i s 间实现通信。代理 在后台为别的代理的请求提供服务，但一个代理不与另一个代理直接进行通 信，而是通过z i s 做中间仲裁者进行协调和管理。 1 7 塑刿盍坐亟堂焦迨塞 基壬h ! b 二些i 二! p ! 虹焦塞煎垒些应用塞盛直塞受童皇塞丑 每个应用程序通过调用标准的代理接口，把异构的数据映射为标准的数据 象定义，程序员可以为特定的应用开发定制代理，以集成现有的应用。代理主 要实现两个接口：通信代理接口和应用代理接口。通信代理接口负责与z i s 交 互，包括发送消息给z i s 并把从z i s 接收过来的消息告知代理。应用代理接口 负责与应用程序的交互，包括接收应用程序中的数据将其根据互操作协议转换 成z i s 中的消息格式，同时也能将从z i s 接收的消息转换成应用程序需要的数 据。代理结构如图2 9 所示。 l 丑sii 胡黼i 1r1 r 通信代理接口 i 应用代理接口i 】 消息服务机制消息传输机制 首 i 麟协议 l消息收发lj蓑 互操作协议 l消息处理l 制 ll i安全机制1 r r 存储管理机制( 数据库服务) 2 3 2 多区域集成系统 图2 9 代理的结构 该方案不仅能实现区域内部应用之间的互操作，还可以通过区域通信中心 完成与z i s 类似的功能( 如图2 1 0 ) ，从而实现区域间真正意义上的集成【2 6 】。 图2 1 0 多区域互操作 应用代理 1 8 塑划盍堂亟生丝逭塞 基王h 女b ：皇! 堕= n 垒虹攫式煎垒些应旦墓盛直塞班宣皇塞丑 2 3 3 本方案的优点 本文提出的基于h u b a n d s p o k e 模式的e a i 方案具有以下优点： ( 1 ) 操作系统和语言无关性。消息格式采用x m l 格式，消除了特定数据 格式造成的系统集成与信息共享屏障，为数据交换的一致性提供了保证。x m l 使信息交换策略与操作系统和数据库无关成为可能，有效的解决了应用间操作 系统、数据库和网络的异构给集成带来的困难。 ( 2 ) 资源共享。资源能在多个企业和部门应用中共享，各应用通过代理和 z i s 访问。 ( 3 ) 耦合度低、易管理。采用h u b - a n d s p o k e 的架构模式，简化了点对点 的集成，降低了软件间的耦合度。z i s 相当于一个中央服务器，集中控制系统 的资源，资源能在多个企业和部门应用中共享，大大减小了管理的复杂度。 ( 4 ) 易集成、低花费。原有的集成方式将大量的时间和资源耗费在支持和 维护原有的集成成果上，仅有少量的时间用于新系统的集成。许多原有的集成 成果需要不断的组装和维护，因而代价昂贵。采用“p l u g & h a y ”方式进行系统的 扩充，降低了集成的难度。当集成机构需要改变时，我们能在网络中通过代理 迅速“p l u g 一个新应用，一旦该应用被插入，用户或者应用程序就将自己的信 息以x m l 的形式“p l a y ”到现存的业务处理流程上，使所有需要该信息的应用都 能够轻松的获得。且原有的应用系统不需要改变，减少了维护的费用。 ( 5 ) 可复用性。该方案核心z i s 平台一旦实现，则可以不加改变的用到 任何需要集成的系统中，不需要重新开发，因而可复用性较强。 ( 6 ) 适应性强。当集成需求和信息需要随时间改变时，能够较快的适应和 改变。 1 9 塑! ：! j 盍堂亟兰焦迨童 董旦! 鱼二翌4 = p ! 鲢燕盛照垒些虞旦塞壁杰塞堡f 巍当塞丑 3基于h u b - a n d - s p o k e 模式的e ai 方案设计 3 1 概念 该部分提供了基于h u b - a n d - s p o k e 模式的e a i 方案的基本思想，包括系统 中传送的消息的实际内容( 数据对象) 以及消息交互的模式( 通信模式) 。 3 1 1 数据对象 通过提供x m l 的数据对象编辑器，应用系统开发商可以定义适合用户业 务规则和领域知识的数据对象，用于与领域中其他应用程序共享。一个数据对 象是部分系统信息的一个标准定义【卸。这些对象使用x m l 表达，并包含定义 s c h e m a ，这些s c h e m a 用来定义应用程序所管理的信息的语义，也是应用所使用 的信息的架构。例如，学校领域中学生的姓名，地址和电话都是 “s t u d e n t p e r s o n a l ”这个数据对象的成员。我们首先应该对系统间的交互信息进 行规范定义，确定出交互的数据对象，而后基于应用认可的数据对象，e a i 使 运行在不同平台连接不同数据库的软件程序能够进行数据的共享。 数据对象可分为三类：基础对象、领域对象和业务对象1 。基础对象是指 与领域和业务无关的公共数据对象，例如姓名、地址、邮件、时间、日期等数 据信息；领域对象是企业的关键概念，依不同的领域而不同，它们可以包含一 个客户的基本信息或者订单，也可以包括产品清单或者合同等；业务对象作用 于业务规则，它可能包括机构、客户、订单等的基本信息，也可以包含其行为 信息、业务规则。业务对象可能随着时间的改变而有所变化。 对所有的数据对象，必须提供一个用户可以定制的工具。所有的数据对象 通过数据映射层来实现和应用程序内部的数据格式映射。 应用间要进行信息的交互和共享，我们用包含数据对象的x m l 文档来代 表交互的信息。代理可以引用系统的很多数据对象，所有这些对象带有一个标 识特定对象的属性，即对象标识符。该标识符必须是全局唯一的。 整世! 叁堂亟堂焦迨童基鲢业：! 自二b 韭! 燕丛曲垒些出旦筮盛直塞受塞复塞现 3 1 2 通信模式 应用间通过包含数据对象( 部分系统信息的一个标准定义) 的x m l 消息 来进行通信和数据的共享。该e a i 方案支持三种数据通信模型： ( 1 ) 一对多异步( 发布订阅) ：进行动态的数据更新时，使用“发布订 阅”模式来进行数据的交互。当某个程序对数据对象进行了更新、修改等操作 时，z i s 能够把更改后的最新数据发布给订阅该数据对象的所有应用。如图3 i 所示，a g e n t l 发布数据对象，a g e n t 2 和a g e n t 3 订阅该对象，当该数据对象改 变时，a g e n t l 发布该对象的e v e n t 事件到z i s ，z i s 查找该对象的所有订阅者， 并将该事件消息发到订阅者代理。 图3 1 发布订阅模式 ( 2 ) 一对一同步( 请求应答) ：用予批量请求时，采用“请求应答”模 式( 如图3 2 ) 。应用程序可以向z i s 请求所需的数据对象，z i s 将该消息传递给 指定的应答者。应答者将数据以x m l 的形式通过z i s 发送给请求者。如果没 有应答者，z i s 将自动查阅提供者列表，指定该数据对象的提供者应答。 图3 2 请求应答模式 ( 3 ) 一对一异步( 消息队列) ，采用m s m q 来存储消息，当消息的接受 端不可用时，一直保存该消息直到接收端可用，确保消息可靠传输。 日曰 塑趔盘堂亟堂焦迨童 基王丛! b = 1 4 = 卫韭撞遗丝垒些廑旦塞盛直塞鲤窒皇勉 3 2 总体方案 3 2 1 该方案的构件 该体系结构有三部分组成： 区域：应用的逻辑组合，每个应用均对应于一个a g e n t 。区域可大可小， 可以有一栋建筑，一个单位，一个地区等组成。 代理：应用的一个组成部分，通过z i s 与其他代理交互，同时将应用内部 的数据转换成z i s 需要的数据。 z i s ：z i s 作为区域的“中枢神经系统”，推动应用间的交互和调节它们 的活动。处理所有的安全信息并路由这些信息到相应的应用。应用程序通过代 理和z i s 间接交互。 代理和z i s 必须使用不同的，大小写敏感的，在区域内唯一的标识符标识 自己，三部分之间通过消息来进行连接。 3 2 2 代理的设计 每个应用都有一个为其而写的集成代理。代理是与z i s 通信的应用的扩 展。所有区域内的应用必须能够适当的处理所有的消息，包括应用不支持的消 息和数据对象。所有的应用和代理需要执行以下职责： ( 1 ) 与z i s 相连接 所有代理须具有对h t l t s 的支持。代理必须能够通过h t i t s 连接到z i s 但它可以尝试通过在此标准或其他标准中定义的通信协议连接z i s 。h 2 t p 是 另一个在此标准中定义的通讯协议。对除h t l t s 之外的任何通讯协议的支持是 与实现相关的。如果非h t r p s 协议中的连接尝试失败，应当尽量建立通过 h t t p s 的连接，以保证通讯进行。鉴于区域内很多数据的敏感性，建议所有 的通讯通过h t i t s 或类似安全通讯协议进行。 对于给定的代理与z i s 之间的通讯通道，代理有责任注册到z i s 或变更并 重新注册设置。注册的消息中提供考虑了代理能力和需求的z s 信息，并在将 来需要代理的服务且代理能够接受z i s 发起的通讯时，允许z i s 联系代理。 代理也可以通过分别发送提供或订阅消息，指定它提供哪些对象，对哪些对象