摘要：随着面向服务架构(SOA)的广泛应用,大量采用不同通信技术的遗留系统以服务的方式接入企业服务总线(ESB)。在实时性要求较高的领域,其信息系统一般采用数据分发服务(DDS)通信技术,将它们接入ESB总线时,必须面对DDS总线与ESB总线间信息通信转换的问题。为此,设计一种通信转换适配器模型,该模型是一种三层体系结构,包括SOAP消息收发层、消息与报文映射转换层及DDS报文发布订阅层。根据消息与报文名称,遍历Mapping映射文件,根据映射规则进行消息与报文的相互转换,再遍历消息或报文的信息模型定义文件,将转换后的结果解析成通信所用的标准格式,用于通信交互。构建一个ESB与DDS的混合通信系统用于测试该适配器模型性能,实验结果表明,其信息转换耗时低于100 ms,满足实时性要求。
关键词：企业服务总线;数据分发服务;适配器;消息队列;消息映射;转换;解析
1 概述
随着信息技术的不断发展,各行各业的信息化、自动化程度不断提高,企业内部各信息系统间,企业与企业之间就存在大量的数据交互、资源共享问题。原有的一些遗留系统成为信息孤岛,为实现对新系统及原有遗留系统的信息共享资源整合,提出一种基于面向服务架构(Service-oriented Architecture,SOA)的企业应用集成[1]。而企业服务总线(Enter-prise Service Bus,ESB)作为SOA架构的核心技术,是一个面向消息的、分布式的、基于标准的、具有智能性路由的系统整合平台[2]。ESB使用松耦合的方式,实现服务间的通信连接,成为各类应用系统间的通信桥梁[3]。任何独立系统都作为一个服务连接在ESB总线上,并能实现即插即用[4]。ESB通过预定义的接口和契约联系异构的组件,通过基于SOAP标准的消息在各服务间进行信息通信,通过UDDI标准实现服务的动态发现,使用分布式管理功能、Web服务池进行智能查找适用的服务,使用开放标准的、非专有的技术实现跨越多种平台进行互操作[5]。
由于系统应用需求的不同,以及信息技术的不断发展更新,因此各遗留系统使用的通信技术也不尽相同。比如航空航天、海洋船舶等行业,对信息通信的实时性要求较高,它们的应用系统通常都采用了数据分发服务(Data Distribution Service,DDS)作为系统通信技术[6]。DDS是一种采用实时发布——订阅协议的分布式系统标准,此标准提供了一种与语言、系统平台及位置无关的通用应用层接口,为分布式计算环境提供了一种以数据为中心的通信规范。该模式定义了2种基本角色,发布者:创建数据,给数据命名(即主题)并发布该数据;订阅者:根据自身需求订阅所需服务,当订阅服务的数据产生变化时,接收改变后的数据。通过发布订阅的形式,实现信息交互共享[7]。因此,当将一个采用DDS通信技术的系统,作为一个服务接入到ESB总线时,必然要面对SOAP消息与DDS报文间的信息转换问题。针对该问题,本文设计一种通信转换适配器作为ESB总线与DDS总线间连接的桥梁,实现SOAP消息与DDS报文间的信息转换。
2 ESB与DDS的混合通信系统
为对DDS与ESB通信转换适配器模型进行研究,本文设计一个基于ESB与DDS混合通信的SOA框架系统[8],通过运行该系统来验证适配器模型的功能及处理性能。该系统主要由三部分组成[9],前台的客户端显控界面,用于发布服务请求及显示服务结果;中间的通信适配器,完成SOAP消息与DDS报文的相互转换分发功能;以及后台的DDS服务端,实现某种应用服务功能。其中, ESB总线部分使用IBM公司的WebSphere Message Broker来控制消息的路由转发[10],而DDS通信部分则采用了RTI公司的DDS网络通信中间件。信息流程见图1。
图1 ESB与DDS通信系统信息流程
根据实时与非实时应用分开的原则,将实时应用与非实时应用分别集成在DDS总线与ESB总线上,适配器作为双方通信转换的桥梁,桥接在2条总线之间。适配器模型中通过消息流存取发送的SOAP消息,通过DDS发布订阅管理器收发DDS报文。其中消息流以服务的方式发布在ESB总线上,消息流接收ESB总线上的SOAP消息后,存入一个消息队列(MQ)中,适配器则调用MQ的API提取SOAP消息。另一方面对于DDS总线而言,适配器被当作DDS的应用节点,其需要订阅与ESB总线端通信的所有DDS服务的TOPIC。
启动仿真系统后,客户端显控界面发布自己的服务请求,以SOAP消息的形式封装请求,并将该消息发送给ESB总线上的某个消息流。消息流将收到的SOAP消息存入到消息队列Adapterin中,然后消息流调用适配器模型。适配器模型通过MQ的应用接口从Adapterin队列中取出消息,去除用于封装SOAP消息的消息头,提取出该消息有效数据,从消息体中找到UnitID元素,根据该UnitID及信息映射文件的定义,转换为对应的DDS报文,交由DDS发布订阅管理器发布该报文。后台DDS服务端,由于事先已经订阅了该主题,直接获取该报文并进行相关服务处理后发布返回的DDS报文,适配器已经订阅了所有主题的服务,当相关主题的数据改变后,能及时接收该报文,根据报文名称通过mapping文件找到对应的映射规则,转换为返回的SOAP消息,存入到AdapterOut消息队列中,然后由消息流提取并发送回客户端显控界面[11]。适配器模型体系结构见图2。
图2 适配器体系结构
3 适配器系统解析
3.1 ESB消息及DDS报文结构设计
ESB消息由协议头与逻辑层次两部分组成,协议头中包含了该消息的基本信息,包括消息属性、发方IP地址、收方IP地址、单位标识、单元长度5个数据字段。其中UnitID为每个消息的唯一标识符,用于不同消息间的区分。逻辑层次则包含了该消息的所有有效字段,例如本文中所用到的消息有效字段就包括速度、方位角、里程等信息字段。该消息所有有效字段都是自定义的数据结构,在esb.xsd信息模型文件中对消息的所有字段类型进行了相关定义[12],该模型文件在后文中将做详细介绍。在系统应用中,整个ESB消息作为消息体的有效数据,被封装在一个SOAP消息中,通过SOAP消息进行信息传递。
与此类似,DDS报文也由两部分构成,首先是报文头,包括了报文的5个基本属性(报文名称、关键字、域、类型、主题名),其中报文名称是某一类报文的唯一标示符,而关键字则用于同一类型报文之间的区分符号。同样的第2部分也是报文的逻辑层次,定义了该报文所要传递信息的所有有效字段。本文中的DDS报文有效字段包括速度、方向角、里程等信息字段。逻辑层次中所有有效字段都是自定义数据结构,每种数据结构都在dds.xsd文件中进行了详细定义,包括该字段的长度、基本类型、基本单位等信息。
3.2 信息模型定义文件
本文设计的适配器进行消息与报文间转换的核心在于,通过mapping映射文件,将对应字段进行替换。替换完成后根据数据结构定义的XSD文件,将报文内容解析成DDS自带的数据类型,并按顺序写入一段缓存中发布出去。因此,该转换过程中的关键在于数据模型的建立,接下来重点介绍本文中所用的数据模型定义文件。
mapping文件的作用在于定义了SOAP消息及DDS报文之间的映射关系,在mapping根元素下面有多个esbdds子元素,每个子元素定义了一种消息与报文之间的映射关系。该元素主要包含3个部分,第1部分为dds子元素,定义了DDS报文头的所有内容;第2部分为esb子元素,定义了ESB消息的协议头部分的所有内容;最后一部分则是elemmap子元素,每个子元素定义了ESB消息与DDS报文逻辑层次中,某对有效字段间的映射关系。mapping文件结构见图3。
图3 mapping文件结构
DDS报文数据模型的定义文件dds.xsd,该文件中定义了本系统所有DDS报文的数据结构,每个报文都是一种自定义的复杂数据类型,包含一个sequence子元素,即报文中每个有效字段都是按指定顺序排列。每个有效字段也是一种自定义的复杂数据类型,每种字段的复杂数据类型又在basicdds. xsd文件中做了详细定义。在basicdds.xsd文件中,将每种自定义数据类型,分解成某种基本数据类型(如string、octets等),并且含有该数据类型的字段长度、单位等基本属性。与此相同,esb.xsd文件则是定义了系统中所有用到的ESB消息的数据结构。
3.3 数据类型的基本属性
每种数据类型都含有3个基本属性:datatype, bytes及baseunit。其中,datatype为数据类型代码,共定义了7种数据类型(0代表未指定类容,1代表BCD码,2代表无符号整形,3表示二进制补码,4代表离散数值,5表示编码值,6是字符型)。Bytes则定义了该数据类型所占缓存大小。baseunit表示基本单位,初始值为1.0,不同数据类型基本单位值不同,用于该数据类型与二进制代码间的转换。
由于收发的DDS报文都是一段连续的缓存,要按照报文信息模型的定义,依次取出各字段的有效值。此时就需要用到各字段的3个基本属性,根据默认定义,该缓存前16个字节默认存储报文名称,此后按照信息模型的定义顺序,及各字段的字段长度,依次获得各字段的二进制代码。然后根据该字段的数据类型代码,调用对应转换语句,获得该字段对应数据类型的有效值。
3.4 自定义数据结构
在信息转换过程中,为方便数据存储,自定义了多种数据结构,以下简单的介绍几种重要数据结构。包括用于存储消息或报文有效字段名称及取值的mapnode,用于映射转化时存储消息或报文定义特征值及其在映射文件中的元素地址值,各结构体的具体定义及功能如表1所示。
表1 重要结构体定义及功能
此外,本文还用到了3个Vector容器ESBInfo, DDSInfo,MappingMap(容器类型都是Vector＜Mapnode＞类型),其中,ESBInfo用于存储ESB消息协议头及其逻辑层次、各有效字段名及其取值。同样DDSInfo用于存储DDS报文协议头及其逻辑层次,各有效字段名及其取值。而Mappingmap则是存储映射文件中定义的,ESB消息及其对应DDS报文各有效字段的映射关系。
4 SOAP消息与DDS报文的相互转换
4.1 SOAP消息转换为DDS报文的过程
系统启动后,客户端显控界面发出服务请求的SOAP消息,经消息流接收并存储于AdapterIn消息队列中。适配器模型从AdapterIn消息队列中取出该消息,去除消息头,提取出消息体中的有效信息ESB消息(以xml的元素节点形式)。然后用xerces c++DOM解析该元素,得到该ESB消息的协议头及逻辑层次的所有有效字段名及其取值。各字段名称及取值以MapNode结构体的形式,依次存入ESBInfo容器中。
然后再用xerces c++DOM解析信息映射文件Mapping.xml[13],依次遍历该文件的每个esbdds子元素,从而得到每个子元素的UnitID值。将每个UnitID值及其所属元素的地址值以esbiden的结构体形式,依次存入名为set的vector容器中。然后再遍历set容器,从中找到与所要转换的ESB消息UnitID值相同的esbdds元素,得到该元素的地址值。再用xerces c++DOM解析该元素,将它所有的elemmap子元素中有效字段的映射关系存入mapping容器中,并获取该SOAP消息转换后对应的DDS报文名称,及转换后对应DDS报文协议头部分,然后根据提取出的映射关系,将ESBInfo中存储的所有逻辑层次有效字段值,赋值给对应DDS报文逻辑层次的有效字段,从而得到了完整的DDS报文内容。再按照预先定义好的xml文档格式,将该DDS报文内容转换生成一个xml文件。
然后再用xerces c++DOM解析DDS报文的信息模型定义文件dds.xsd,依次遍历该文件的每个子元素,找到转换后报文的结构定义子元素。继续解析该元素,找到该报文每个有效字段的自定义数据类型,再解析basicdds.xsd文件,找到每种自定义数据类型的结构定义,得到其基本类型名及其3个基本属性(bytes,datatype,baseunit)。将前面得到的DDS报文的内容,转换为DDS内含数据类型,并依次存入一段缓存中。开始的16个字节默认为存储关键字,其后按信息模型定义的顺序,依次写入各有效字段值。通过提取每个有效字段的3个基本属性,根据bytes值得到该字段所占内存大小,根据datatype值等到其所属数据类型,再调用相应处理函数转换为其对应的DDS内含数据类型值。将该报文的所有内容转换并存储于一段缓存后,将该段缓存交由DDS发布订阅管理器,通过发布者将报文发布出去[14]。
4.2 DDS报文转换为SOAP消息的过程
在适配器运行时,就已创建了DDS发布订阅管理对象,其一直监听网络中是否有自己订阅主题的DDS服务,一旦发现则接收并读取该报文[15]。将获取的内容存在一段缓存中,按照该报文定义格式,依次读取该缓存,获取报文各字段的二进制代码,然后交由报文处理对象进行报文解析。
首先根据报文名称,将该报文的关键字及其有效值成对存入一个名为respDDSMap的VECTOR容器中。然后按照报文名称,从dds.xsd文件中刚找到该报文数据模型的定义元素eltpack。用xerces c++ DOM解析该元素,从而提取出该DDS报文中报文头的field,theme,type这3个基本属性,并与其对应值一起存入respDDSMap容器中。
然后解析遍历eltpck元素,获取该报文所有有效字段名及其数据类型。解析遍历basicdds.xsd文件,从而得到各字段数据类型的详细信息(如bytes, datatype,baseunit这3个基本属性及备注信息)。根据各字段的详细信息,从该DDS报文缓存中,依次取出各字段所占内存中的二进制代码。按照转换规则,转换成该字段数据类型的对应取值。按照定义好的xml文件结构,将获取的DDS报文内容生成一个DOMElement∗的元素节点。解析该xml元素,提取出DDS报文各有效字段名称及取值,成对的存入一个名为DDSInfo的容器中。遍历解析mapping文件,按照该报文名称,得到该报文所在的esbdds元素。从该esbdds元素中找到UnitID,unitlenth等对应ESB消息协议头部分的有效字段。根据映射规则,将DDS报文所有字段的内容,赋予对应ESB消息的相应字段。再按照xml文件的格式定义,生成ESB消息。将该ESB消息作为消息体的有效数据字段,加上SOAP消息头,封装成一个SOAP消息,再将该SOAP消息存入adapterOut消息队列中,由消息流取出发送出去。
5 实验及结果分析
针对上文提出的适配器模型设计方案,编写完成适配器模型后,将其应用于上述的ESB与DDS通信仿真系统中。运行系统,对适配器进行功能与转化时间的测试。实验环境介绍如下:
实验设备:惠普工作站;
CPU:Intel Xeon 5160;
内存:3 GB;
操作系统:Microsoft Windows XP专业版SP3;
软件环境:Microsoft Visual 2005,RTI DDS, Altora XMLSpy 2006;Websphere MQ version 7.0.1.0 Message Broker Toolkit 7.0。
实验数据检查表如图4所示,其中详细列出了SOAP消息及DDS报文所含数据项,供实验人员记录并分析实验结果使用。
图4 实验数据检查表
5.1 功能测试
启动仿真系统后,适配器不断接收服务请求的SOAP消息,完成信息转换及转发功能。测试工具分别在2条数据总线上监视对应信息,通过ADO方式操作ACCESS数据库,将每个ESB消息及DDS报文的内容存入数据库中,待实验结束时提取数据库中内容,对实验结果进行分析。根据实验要求,从数据库中随机抽取60组实验数据,按照图4格式,将实验数据填入表格中,将每组报文及消息数据字段与目标数据进行比对,得到实验结果100%正确。
5.2 处理时间性能测试
方法与功能测试相似,在系统运行过程中,每当适配器提取一条ESB消息时,程序会将此刻的系统时间t1存入数据库中,然后经过信息转换生成DDS报文,在发布报文的同时将此刻的系统时间t2存入数据库。待DDS处理服务处理完成后,适配器根据订阅的主题名,获取返回的DDS报文并将此刻的系统时间t3存入数据库。完成信息转换后,将生成的ESB消息存入消息队列,同时存入此刻的系统时间t4。实验完成后,从数据库中随机抽取60组实验数据,计算出ESB消息转换为DDS报文所需处理时间Te,及逆向DDS报文转换为ESB消息处理时间Td。处理时间实验结果见图5、图6。
图5 ESB消息转换为DDS报文的处理时间
图6 DDS报文转换为ESB消息的处理时间
实验的数据结果如表2所示,从表中可以清楚地看出,2组实验结果都符合实验设计处理时长100 ms的要求,处理时间基本都在47 ms左右,最高不超过63 ms。通过样本方差及样本期望值的比较,可知ESB消息转换为DDS报文时,适配器模型平均处理时间稍短且更加稳定。
表2 实验数据统计
6 结束语
针对SOA架构中原有遗留系统的不同通信技术与ESB总线间通信适配问题,本文设计了一种DDS与ESB通信转换的适配器模型,并通过一个ESB与DDS混合通信系统的运行验证,该适配器程序能准确、及时地完成SOAP消息与DDS报文间的转换及分发功能。通过预定义的信息模型文件,解析自定义的映射文件,完成信息数据间的映射转换。但还有一些不足之处,如消息与报文间的转换只能在预先定义好的消息报文之间,不能达到运行时自定义转换关系,这也是今后研究的重点内容。
