美章网 资料文库 分布式企业服务数据研究范文

分布式企业服务数据研究范文

时间:2022-05-27 03:28:18

分布式企业服务数据研究

1国内外研究现状

在数据集成中异构数据源之间往往存在着语法和语义方面的数据冲突问题。XML技术能够较好地解决语法层面的数据冲突,而对于语义层的异构问题,一般采用知识库和本体技术,通过描述不同数据源的概念信息,并构建语义映射关系加以解决。已有的数据集成工作主要采用联邦数据库系统、数据仓库技术和基于中间件的信息集成技术来实现。联邦数据库系统(FDS)是多数据库系统数据集成方法,在已存在的局部数据库(LocalDatabaseSystem,LDS)之上为用户提供统一的存取数据环境。FDS由一组独立的LDS组成,实现数据库系统间部分数据的共享。以数据仓库(DataWarehouse,DW)为主的数据集成方法,通过对相关数据库的链接,抽取数据记录,复制需要的字段,将异构或同构数据源相关数据复制到特定数据源上,从而解决数据的分布和异构的问题,达到集成的目的。上述两种方法对异构数据大都采取先把数据转换为统一、静态的格式,再将数据转换和整合规则融合在定制代码中。由于应用系统代码与数据库模式紧密耦合,不能适应数据动态变化,这两种数据集成方案较脆弱。目前主流的数据集成方式是基于中间件的数据集成方案。传统的中间件解决方案是用DCOM、CORBA及RMI等分布式对象模型来构建信息集成系统。这种方法可以有效地避免联邦数据库系统开发代价大、代码重用难的问题,但分布式对象模型要求服务客户端与服务之间必须进行紧密耦合。随着SOA框架和WebService技术的发展,传统应用中间件向企业服务总线(EnterpriseServiceBus,ESB)过渡。ESB成为企业数据集成采用的主流技术,它将基于事件驱动架构(Event-DrivenArchitecture,EDA)的思想与面向服务体系架构(Service-OrientedArchitecture,SOA)的思想相结合,简化业务单元的集成,在异构平台和环境之间建立了联系。ESB系统的消息转换和消息路由功能为数据异构性问题提供了解决方案。集成大量的异构数据源需要建立高效、可靠的数据传输机制,集中式的ESB实现架构难以满足集成的需求。IBM提出了联邦式的ESB模式以及中介式的ESB模式,将多个服务总线通过JMS相联接,以支持大规模的跨组织应用集成。国内外对ESB的实现架构进行了大量研究,并建立了多个基于JBI(JavaBusinessIntegration)规范的分布式ESB平台,如MuleESB、ApacheServiceMix、OpenESB等。目前的一些分布式ESB系统已经可以支持应用整合、复杂业务集成以及消息的可靠传输。在负载均衡方面,动态负载均衡策略考虑的关键问题是及时、准确地把握节点的负载状况,并根据各节点当前的负载状态来动态调整和分配任务。动态负载均衡策略一般可分为两类,一类是求最优解问题,即集群系统的节点提供系统负载、流量及其他一些资源信息,并通过高效通信机制传给负载均衡器,负载均衡器监视所有节点的状态,以便将下一个任务分配给负载最轻的节点。在进行负载最轻的决策时,由于系统处于不断变化中,从更新负载信息到做出决策之间存在时间差,有可能出现负载信息过时的状况。为了解决这一问题,有些研究人员提出先从全集中随机选取包含K个元素的子集,再从子集中选择负载最低的一个。这种基于反馈的动态选取方式虽然存在一些局限性,但是对于节点数相对较少的分布式系统来说仍然是一种行之有效的方式。另一类动态负载均衡策略主要是通过负载迁移的方式来保持节点之间的负载均衡,这种策略的关键是确定过载和轻载的对象,以及需要迁移的负载数。负载迁移虽然可以较好地处理系统的过载现象,但是频繁的负载迁移会增加系统的额外开销,而且还会造成“负载抖动”问题。在基于企业服务总线系统的负载均衡机制方面,目前主流的开源ESB项目如Mule和ServiceMix都在一定程度上加入了一些负载均衡的实现,但是MuleESB的集群比较弱,只能配置一个主实例和一个从实例,因此它的负载均衡机制主要是为了解决服务路由的问题,即根据集成到总线上的服务负载状况,选择负载最轻的一个作为目标服务,以此确定路由路径[22]。目前,国内外针对基于分布式企业服务总线实现架构下的负载均衡机制的研究还比较少,尤其是面向数据集成场景时,多个集群节点中大量数据消息的负载平衡仍是需要解决的问题。本文主要研究分布式ESB系统中的数据集成模型及方法,以解决异构数据的集成问题,并通过设计负载均衡策略来保证系统在大规模数据集成时的效率。

2分布式企业服务总线

D-ESB服务总线系统通过实现多种中介模式来生成特定的中介组件。中介组件的主要工作就是消息表现层的转换和消息内容的转换,消息表现层转换是指改变消息格式,而消息内容的转换主要是为了解决数据集成中的语法及语义异构性问题。在企业服务总线系统中,可以通过实现特定的组件来完成传输协议的转化,这类组件也通常被称为适配组件,例如数据库适配器、HTTP适配器等。此外,在ESB中,可以通过服务端点来实现服务提供者的地址透明性,因为每一个接入的服务都会暴露成一个服务端点,而服务端点又与特定的适配器相绑定。本文研究的分布式企业服务总线结构如图1所示。整个框架由ESB主节点、ESB从节点、监控管理平台以及流程建模工具4部分组成。ESB主节点主要负责分布式环境管理,监控和统计各个客户端的资源信息,并且通过加载中介组件来提供消息转换和消息路由的功能。ESB从节点主要负责异构系统及外部应用的接入。监控管理平台是ESB服务端与平台管理员的可视化接口,管理员可以通过Console完成对各个客户端的资源管理以及消息流监控。流程建模工具给用户提供了图形化工具来完成集成场景的建模和部署。

3分布式ESB系统的数据集成模型

3.1基于消息的数据集成方法分布式ESB系统采用基于消息的数据集成方法。在这种基于消息的数据集成方法中,适配器作为企业服务总线的一种消息处理组件,主要充当外部异构数据源与总线之间交互的,异构数据源通过适配器接入ESB总线。适配器和ESB总线,以及ESB总线内部通过消息进行通信。分布式ESB系统的数据集成基本思路如下:1)企业服务总线平台在系统/异构数据源的数据传递与互操作上采用XML作为数据描述与交换的语言。2)将异构数据源抽象成统一的XML格式数据。将XML数据封装成JMS消息,将异构数据源数据的转换和传输问题转换成ESB环境下的消息转换和路由问题。3)通过XSLT转换引擎实现对不同的XML消息格式的转换。面向数据集成的ESB消息转换工作流程如图2所示。消息转换的整个流程可分为应用接入和数据转换两个过程。作为应用接入部分的适配器逻辑完成对具体数据源的包装、连接及各种读写操作。一方面它将从数据源获取的结构化、半结构化数据转换为公共的基于XML的数据格式,并以消息流的方式发送到下一个消息组件(转换中介)的消息通道中;另一方面,适配器从消息转换中介的消息通道中取出消息,并将消息体中经过转换的数据格式转换成需要的结构化或半结构化数据,输送到目的数据源。而ESB的中介模块的作用是接收消息发送者所定义格式的消息,经过转换或者路由以后以消息接收者所预期的格式传递到接收方。这个过程中涉及到多方面的消息处理,可以是对消息的格式、内容进行转化,也可以是加密、解密等自定义操作。在数据集成中,适配器既可以作为服务提供者,也可以作为服务的消费者。以数据库适配器为例,作为服务提供者的数据库适配器提供了4个接口,即CRUD这4种数据库操作,这些操作可以通过标准的服务描述规范配置成具体的某一个服务到注册中心。外部系统可以通过服务注册中心查找特定种类的服务,在获得服务的描述信息以后去调用服务进行具体操作。而在ESB环境内部中,适配器可以接收到消息通道中的ESB消息,并对消息内容进行解析和提取,之后调用数据库适配器内部接口进行具体的数据库操作。处理完成后通过适配器把回复内容转化为ESB消息,消息目标为服务消费者的回复端点。作为服务消费者的数据库适配器可以定时地检测本地数据库表是否有记录更新,发现有新的记录则将更新的内容封装成ESB消息以后进行输出。适配器只需要知道要负责监听的数据库表的地址就可以完成如上的操作。对于如何提供这个地址给适配器,具体的适配器解决的方式也可以不同。比如,可以将监听地址配置在流程中,当适配器框架部署某个适配器的流程时将地址信息部署到该适配器上,之后适配器就能够启动监听;另一种方式也可以将监听地址的信息配置在服务配置文件中,在部署服务的时候将地址信息部署到某个具体适配器上,之后在部署服务端点的时候适配器启动监听。本文的数据库适配器在开发的时候选择了后者的处理方式。

3.2基于WSDL的消息模型企业服务总线平台内部的适配模块要在异构系统与ESB之间提供的功能,特定的适配器可以抽象出接入到总线上的数据源的具体实现,通过协调不同系统间的传输协议(例如FILE、JMS、SOAP、JDBC等)来完成消息转换过程中的传输层转换。为了实现上述功能以及组件间的交互通信,在面向数据集成的企业服务总线平台中定义了基于WSDL的消息模型。JBI规范中使用WSDL1.1和2.0规范描述组件所提供的和消费的服务模型。WSDL在以下两个层面上定义了基于消息的服务模型:1)抽象服务模型:使用抽象消息模型定义的、未限制到特定消息交换协议的服务。WSDL服务描述中抽象服务模型需要定义以下几个元素:抽象消息类型(MessageType)、抽象操作(Operation)以及抽象服务类型(ServiceType)。2)具体服务模型:建立在抽象服务模型之上,为抽象服务同特定通信协议及通信端点的映射提供描述信息。WSDL具体服务模型需要定义以下几个元素:绑定类型(BindingType)、端点(Endpoint)以及服务(Service)。以外部应用为数据库系统为例,在面向数据集成的企业服务总线平台中定义了如下的基于WSDL的消息模型:type元素中通过import引入的XSD文件(XMLSchemaDefinition)即XML结构定义,描述了XML文档的存放结构,因此可以通过该文件来生成JMS消息体中的XML文档格式。例如,当外部应用为数据库系统时,数据接入服务需要在XML文档结构和数据库结构之间建立映射,把数据从数据库转换成XML文档,或者把一个XML文档转换到数据库中。本文将关系模式映射到XML模式,图4表示了将数据库表person结构映射成XMLSchema的person.xsd文件。

3.3基于XSLT的消息转换企业服务总线平台内部所涉及的消息转换按层次角度区分,可以分为3类:传输层转换、消息表现层转换和消息内容转换层。其中传输层转换主要是为了协调不同系统间传输协议的区别,主要由适配模块完成;消息中介模块则负责消息表现层转换与消息内容转换层,图2中所示即为将应用A格式的数据转换为应用B格式数据的过程。为了解决异构数据间的映射问题,在ESB平台内部采用XML来描述和存储数据,再通过映射规则进行数据转换。常用转换规则表示有XSLT(eXtensibleStylesheetLanguageTransformations)和用户自定义规则等。XSLT的主要功就是转换,它将一个没有形式表现的XML内容文档作为源树,将其转换为一个可显示的有样式信息的结果树。同时,在XSLT文档中定义与XML文档中各个逻辑成分相匹配的转换模板,以及匹配转换方式。图2中的Transformer是将源消息格式转换为目的消息格式的主要模块,它可以根据配置信息来选择合适的消息转换器,并按照规则库中存储的XSLT规则把消息转化成合适的格式,图7所示为根据XSLT语法规则定义的样式文件。该样式中包含了xsl:stylesheet元素,该元素是XSLT文件的根元素,它包含了XSLT名字空间、函数名字空间、变量名字空间以及版本信息。在XSLT中使用xsl:template表示模板元素,它也是XSLT中最重要的一个属性元素,每个xsl:template有一个节点匹配属性,由“match=”指定。在对模板进行匹配时使用“xsl:apply-templates”选择要匹配的模板。

4基于消息流程的ESB数据集成

4.1基于分布式ESB平台的数据集成框架基于分布式ESB平台的数据集成框架如图8所示。在数据集成框架中,用户视图代表的是外部应用层,对于特定的数据集成场景,一般都由用户来进行指定。流程编排的主要过程是用户根据具体的集成场景,使用特定的描述语言来完成对信息集成的建模。流程部署主要在系统的后台执行,主要过程是将流程中的单个服务部署到位于不同ESB节点上的执行组件中。而系统的负载均衡机制主要负责将流程中的单个服务与合适的执行组件进行绑定。结合分布式ESB平台的集成方法,本文可以通过ESB流程建模工具对数据集成场景建模,然后将生成的流程文件部署到后台系统执行以实现数据集成。

4.2数据集成流程数据集成流程是对数据集成场景的逻辑表示,由许多个相关的流程节点组合而成。为了更好地描述流程这个逻辑概念,以及将相关的流程节点部署到对应的执行组件上,本文引入XML描述语言以便很好地表述消息中介的逻辑符号与实际的消息中介之间的对应关系,并且能够表示流程节点中的参数信息以及相关节点之间的链接关系。通过构造流程配置文件来描述相关的中介规则信息以及服务描述信息。下面给出相关概念和数据集成流程的相关定义。1)Component:表示了分布式企业服务总线平台中的服务执行组件,也称为消息组件。它主要负责接收请求消息,处理消息的内容,并且将处理后的消息进行转发。系统中主要存在两种类型的组件:适配组件(adaptor)和中介组件(mediator)。2)WebService:表示所请求的外部服务,它可以是数据源、Web服务(WebService)或者应用程序等。3)Application:表示服务的请求者,它也可以是数据源或者Web服务。4)AtomicService:表示了应用流程中的单个节点,可以将它看成是原子服务。流程中的所有节点可以分为两类:中介规则(mediation)和端点(endpoint)。中介规则描述了消息中介的规则(例如消息验证、消息路由以及消息转换)。对应数据集成场景,中介规则为消息转换。它被部署到对应的中介组件以后,中介组件才能执行具体的中介操作;端点又可分为两类,一类描述了所请求的服务的相关信息,比如服务名称以及服务地址等信息,另一类描述了客户端通过怎样的方式将请求发送给ESB,比如暴露HTTP端口等等。与中介规则类似,端点被部署到对应的适配组件以后,适配组件才能执行具体的适配操作。定义1esbprocess表示基于ESB平台的数据集成流程,它主要由中介规则序列和服务端点集合组成,因此,它的主要属性包括processid,inendpoints,mediations,outend-points。其中:①processid表示ESB流程的名称,全局唯一;②inendpoints表示请求者端点集合,流程中可能存在多个服务请求者的相关信息;③mediations表示中介规则的集合;④outendpoints表示服务端点的集合,流程中有可能存在多个服务端点。定义2requesterendpoint表示请求者端点,它描述了接入到总线上的服务请求者的相关信息。它的主要属性有:consumer,type,adaptor,description,nexthop。其中:①con-sumer表示服务请求者的名称,它在一条流程中是唯一的;②type表示用于执行该流程节点的组件类型信息;③adaptor表示用于执行该流程节点的组件名称以及位置信息;④de-scription表示服务请求者的描述信息;⑤nexthop表示与该流程节点有逻辑关系的下一个节点的名称信息。定义3mediation表示中介规则,描述了中介服务信息,主要包括mediation,type,mediator,rule,inbounds,outbounds等属性。其中:①mediation表示该中介服务的名称,它在一条流程中也是唯一的;②type表示用于执行该流程节点的组件的类型;③mediator表示用于执行该流程节点的组件名称以及位置信息;④rule表示具体规则的内容,包括一些参数信息;⑤inbounds表示与该流程节点逻辑相关的前一(或前几个)流程节点的名称;⑥outbounds表示与该流程节点有逻辑关系的下一个(或几个)节点的名称信息。定义4serviceendpoint表示服务端点,它描述了服务提供者的相关信息,包含的属性有:service,type,adaptor,de-scription,replyto。其中:①service表示服务提供者的名称,它在一条流程中是唯一的;②type表示用于执行该流程节点的组件类型信息;③adaptor表示用于执行该流程节点的组件名称以及位置信息;④description表示服务提供者的描述信息;⑤replyto表示请求是否需要返回结果。图9是一个基于XML的流程片段描述。

4.3数据集成的流程部署在流程部署视图中,当一条数据集成流程被部署到分布式ESB平台的主容器时,容器中的流程管理器会将流程分割成n个流程节点。每个流程节点中的type属性是在流程编排时由用户事先配置的,主容器的负载均衡模块会首先获取该节点的组件类型信息,之后找出合适的执行组件,并将信息添加到该流程节点中,这一过程被称为流程的重配置过程。最后,流程管理器会根据重配置后的结果,将流程节点分配到相应ESB节点上的相应执行组件中。本文在分布式ESB系统JTangSynergy上展开研究,在目前的Synergy系统的实现机制中,处理消息流的消息处理器只有一个,它需要负责各种消息流的处理;其次,所有的消息都存放在唯一的一个消息接收通道中,消息组件在取出消息以后还需要匹配相关的配置信息,才能决定采用哪种处理方式来处理特定种类的消息。这种处理方式相对效率较低。在本文的方案中,考虑在D-ESB主节点中增加负载均衡器,其负责将中介规则以及服务端点等信息分配到合适的消息中介上。同时,通过设计消息中介的消息队列模型,来提高中介的消息处理和传递效率。本文第5节将介绍负载均衡方案。

5分布式ESB数据集成中基于流程的负载均衡策略设计

5.1消息多队列模型为了提高执行组件的消息处理性能,在实现流程部署的过程中,我们设计了如图10所示的执行组件的多消息队列模型。其中,每个组件内部有可能存在多个实例,而每个实例主要由3部分组成:处理器(Processor)、消息队列(Queue)和中介单元(MediationUnit)。消息队列是消息系统中的基本数据结构,主要用于存储消息,队列的创建和销毁都是基于JMS技术,每当一个流程节点部署到某个执行组件时,组件就会初始化一个具体的处理实例,并由该实例负责对应的消息接收队列的创建,该队列只负责接收与部署的流程节点相关的请求消息;MediationUnit是流程中的中介(mediation)被部署到执行组件的时候创建的,它实际上是一个内存中的片段,描述了路由规则或者转换规则等信息;Processor负责从消息通道中获取消息,处理消息体中的内容,最后根据中介单元的信息将处理后的消息转发给下一个目的地。该模型具有以下的一些优势:1)与特定流程相关的消息都会被发送到指定的消息队列中,使得各个消息流可以并行传输而不会相互影响,从而提高了消息传递的可靠性;2)组件中的每个实例都会从自己的消息队列中获取和处理同一类型的请求消息,从而提高了消息中介处理和传递消息的能力。

5.2服务执行组件的负载评价传统的负载均衡策略多数是基于网络的负载平衡和基于操作系统的负载平衡,这些策略的算法和实现都比较复杂,动态参数很多而且难以控制。例如:基于操作系统的负载均衡策略常常通过计算系统资源来评价服务器的负载,比如CPU利用率、内存使用率等等。中间件技术提供的异构环境下的通信和互操作功能,为解决分布式企业服务总线平台的负载均衡问题提供了有效的工具。分布式企业服务总线平台中负载调度的对象是执行组件,因此,本文提出将组件的消息队列数以及各个消息队列中的剩余消息总数作为组件负载评价的标准。结合之前提出的组件的多队列模型,对于分布式ESB系统中的任意一个执行组件,通过一个五元组来定义它的负载度量模型:

5.3基于流程的负载均衡策略首先定义以下几个数据结构:1)组件负载信息表(ComponentId,Load等);2)定时器H;3)组件列表list{},初始为空,记录属于同一服务类型的组件ComponentId。基于流程的动态负载均衡策略主要由以下3个阶段组成:主节点负载信息的维护、基于负载统计的信息更新以及基于反馈的流程节点分配。具体步骤如下:1)负载信息维护①ESB主节点成功启动后,主容器初始化组件负载信息表(ComponentId,Load等);②当任意一个ESB节点中有新的执行组件需要动态加载时,该节点的容器会将该组件的ContainerId、Component-Id、ComponentType以及State等信息以事件消息的方式通过消息通道发送给主节点容器,此时,组件的Qnum以及Load的初始值都为0;③主容器接收该组件初始化的事件消息,并将消息中的内容写入负载信息表中;④当某个ESB节点需要动态卸载某个执行组件时,节点的本地容器会将ContainerId信息以及组件的ComponentId信息通过消息通道发送给主节点,主节点根据收到的信息将负载信息表中对应的组件删除。2)负载信息更新①主容器的资源监控模块使用定时器H,当更新时刻到时,向各ESB节点中的组件发起当前负载查询请求;②组件接收到查询请求,将当前的实时负载信息通过本地容器以事件消息的方式发送给主容器;③主容器接收各节点反馈的负载信息,其中包括组件的Qnum和Load这两个参数的值,并将它们更新到负载信息表;④主容器会根据组件类型(Type)创建多个组件列表list,并将负载信息表中属于同一类型的组件加入到相同的list中。3)流程节点分配①解析流程:流程第一次部署到主容器时,主容器会首先解析流程配置文件,将中介规则和服务端点分割成n份,并且获取中介规则和服务端点中的组件类型信息type;②定位组件:根据上一步获取的type值,负载均衡器会根据5.2节中的评价策略在对应组件列表中查找其中负载最轻的组件;③重组流程:根据上一步得到的组件,负载均衡器会获取组件的ContainerId和ComponentId值,并以“ContainerId∪ComponentId”表示该流程节点的执行组件名称,该信息会被添加到流程节点中的“adaptor”属性或者“mediator”属性中;④分配流程节点:流程管理器获取重组后的流程文件并再次解析,对于其中每个节点,获取“adaptor”属性或者“me-diator”属性的值,之后,主容器根据ContainerId信息将该流程节点的完整内容发送给对应的ESB节点,并且由ESB节点根据ComponentId信息将流程节点最终交给本地的执行组件。

6仿真实验

基于以上的研究,本文在分布式ESB系统JTangSynergy上采用本文的数据集成模型和负载均衡方法,对医疗系统进行数据集成。JTangSynergy主要采用了Master/Slave的容器集群架构,主节点实现了分布式环境管理以及资源监控和负载均衡,从节点完成外部应用及异构数据源的接入。此外,用户可以通过系统提供的图形化流程开发工具完成应用场景的流程建模,并且通过监控管理平台Console实现对系统的资源管理和消息流监控。下面以模拟医院内部各个信息系统之间的数据集成为例对基于分布式ESB平台的应用步骤进行说明。(1)服务封装。在基于ESB应用的角色分配中,服务一般是由第三方负责提供,而ESB平台主要完成服务集成的工作。但是,用于应用集成的服务也可由ESB系统的提供商负责统一封装。在这个仿真实验中,所涉及到的服务都是针对数据库访问操作,目的是实现对数据库数据集成操作的复用。针对这个应用案例,共封装了(2)启动系统各个节点,安装组件。分别在需要进行集成的HIS系统、NIS系统、EMR系统以及LIS系统所在的服务器上部署一个ESB的从节点,并在数据中心的服务器上也部署一个ESB的从节点,另外,还需要一个高性能的服务器来部署ESB的主节点。这样一来,就确定了一个ESB主节点和5个标准节点的集成环境。此外,还需要在各个ESB节点上安装由系统提供的执行组件。图11和图12是通过监控管理平台的界面显示的ESB各个节点(客户端)以及执行组件的信息。(3)数据集成流程的建模和部署。针对当前的应用案例,共设计了4条数据集成的应用流程,分别是病人信息同步流程、医嘱信息同步流程、收费信息同步流程以及病人信息汇总流程,在这些流程中应用了广播路由、聚合路由以及消息转换等服务。图13所示的是对病人信息同步流程的建模界面。在图13所示的病人信息HIS系统原始数据源采用MySql数据库,NIS系统的数据源采用SqlServer数据库,以符合数据源异构性的特征。在Mysql数据库中创建一张存储病人信息的表Patient,表结构如表3所列;在SqlServer数据库中创建一张以HL7标准格式存储病人信息的表Patient_HL7,表结构如表4所列。该场景下需要完成的转换操作主要有ID-PID、Sex-Gen-der、Birthday-Age这3组对象名称的转换以及Birthday-Age的值转换操作,通过流程定义器的配置界面定义生成转换规则集(命名规则和计算日期的运算函数规则),将上述规则作为参数进行输入,并根据定义的转换算法生成针对该具体实例的转换节点,从而实现了数据集成中的数据兼容问题。流程设计器中创建抽取原始数据源以及写入目的数据源的节点,这两个节点是通过适配器组件经过配置后生成。将生成的流程导出成为配置文件包,并将它部署到已运行的ESB环境中,至此,实现了对病人信息转换和信息同步的流程。(4)系统运行及消息流监控。对于每条应用流程,可以通过监控平台来查看实时的消息流状况。图14显示了病人信息汇总流程的实时消息运行状况,对于流程中的每个节点,监控管理平台中都会显示该节点的消息发送和接收数据量。在该医疗信息集成测试用例下,需要同时运行的消息流程有4条。为了获取系统目前的消息吞吐量的变化情况,选择进行宽泛的测试方案,对于每条消息流程,保持每秒钟发送330条消息的数据量。当所有流程同时运行时,系统的总体消息传输率会达到900条/秒左右。对于每条消息流程的运行情况,可以通过“监控”来查看实时的消息流状况,图14显示了病人信息汇总流程在传输了130万条消息时的运行状况,对于流程中的每一个节点,监控管理平台都会显示出该节点的消息发送和接收数据量,可以看到图中的病人消息聚合路由的消息接收数是前面3个节点的消息发送数之和,而发送出去的消息数是已经处理完的消息。图15显示了ESB主节点的实时负载监控情况,从中反映出了节点所在服务器的CPU使用率、内存使用率以及JVM的使用率等信息。从图上结果可以看到,基于本文的数据集成方法以及负载均衡策略实现的分布式企业服务总线平台可以有效解决异构分布式环境下的数据集成问题,并且可以充分利用各个ESB节点的系统资源,完成百万级数据量下的消息流调度,能够较好地满足实际应用集成的需求。(本文来自于《计算机科学》杂志。《计算机科学》杂志简介详见)

7结束语

本文在基于分布式企业服务总线的系统框架之上,为了解决系统在面向大规模数据集成时碰到的数据源异构性问题,定义了一种基于WSDL和XML的数据集成模型;此外,为了解决系统的数据传输效率问题,提出了一种基于流程的负载均衡算法,以实现对分布式ESB各个节点中消息资源的有效分配,从而提高应用集成时的运行效率。下一步工作将对大规模应用集成下的数据安全性以及消息传输的可靠性进行深入研究,通过在分布式ESB平台内部实现有效的安全机制来提高系统的安全性。

作者:范菁熊丽荣徐聪单位:浙江工业大学计算机学院

被举报文档标题:分布式企业服务数据研究

被举报文档地址:

https://www.meizhang.comhttps://www.meizhang.com/gllw/qyfwlw/645255.html
我确定以上信息无误

举报类型:

非法(文档涉及政治、宗教、色情或其他违反国家法律法规的内容)

侵权

其他

验证码:

点击换图

举报理由:
   (必填)