异构处理器平台（精选7篇）
异构处理器平台 篇1
0 引言
软件无线电[1](Software Defined Radio,SDR)是一种新型的无线电体系结构,在理想状态下可以通过下载适合的通信波形实现以任意频率、带宽、调制方式和数据数率进行通信[2],即可以通过软件定义来完成不同功能。SDR平台对多种无线通信体制的支持,尤其是3G,4G,WLAN,WIMAX等计算密集型通信体制的出现,对硬件平台的处理能力以及硬件和软件框架的可重构能力提出更高的要求,无线电平台设计在功耗、可编程性、计算能力、尺寸、重量等方面面临新的挑战[3]。
1 主要技术背景
软件通信体系结构[4](Software Communications Architecture,SCA)是美军在联合战术无线电系统(Joint Tactical Radio System,JTRS)计划中提出的,旨在提供一种标准的、开放的、可互操作的软件平台。波形是为了实现信息的无线传输对信息的一系列变换,包括无线通信双方为实现信息传输而采用的所有协议。实现一套完整功能的软件模块或单元称为组件。SCA的架构如图1所示。
SCA使用CORBA中间件技术屏蔽了操作系统、编程语言的差异为软件开发提供了一个统一的编程环境,实现软件无线通信中各种软件组件的移植和重用,但是受处理器件特性和开发复杂度等因素的限制,在SHP上不运行CORBA中间件。
在SDR的信号处理中,数据流信号处理任务(滤波、编码等)适合在DSP和FPGA等专用处理器(Specialized Hardware Processor,SHP)上实现,这些任务在许多的SDR应用都会用到,只需要对相关频率进行调整就可以在不同SDR波形实现中复用,因此可以通过将处理任务分配到异构处理器平台上执行来提高计算性能、降低功耗。但是异构处理器平台中计算性能的提升和功耗的降低是以软件开发的复杂性的增加为代价的[5]。软件无线电的分层结构图如图2所示。
为了使不同平台实现无缝通信并为上层软件屏蔽底层通信接口的差异性,有效地支持向SHP上部署波形组件,实现消息的透明传输,需要设计异构处理器上的互联架构屏蔽底层硬件差异为软件应用提供透明的消息传输机制;实现软件开发与硬件平台设计的分离,提高系统开发效率,以提供对异构处理器平台上的软硬件资源的抽象和管理,支持软件框架对硬件设备的管理和控制。
JTRS先后提出了几种硬件互联结构,包括HAL-C[6],CP289[7],MHAL[8],MOCB[9]等,其中MHAL方案考虑了硬件的抽象和组件互联是较为完善的解决方案。为波形组件和其他组件之间数据和控制流信息交互提供与SCA兼容的通信服务,但是由于国际武器管制组织的管制,MHAL方案的具体内容不对外公开,为硬件抽象层的实现增大了难度。
2 主要设计思想
异构处理器互连架构的实现首先要对硬件模块的对外接口进行抽象,将其与外界的交互进行独立设计,即要实现底层屏蔽功能并为波形组件提供异构处理器环境下透明的消息传输机制的硬件抽象层。带有硬件抽象层的硬件平台能为软硬件开发提供便利的条件,能实现系统设计中软件开发与硬件平台设计的分离,降低系统开发的复杂程度和重要软件组件接口的重新编写,提高系统开发效率。针对GPP、DSP、FPGA组成的异构处理器互连架构设计的硬件抽象层如图3所示。
第二,要实现传递数据在异构处理器环境中的数据路由功能。由于专用处理器之间、专用处理器与通用处理器之间采用逻辑地址(logical Destination,LD)进行数据和控制信息的交换,因此硬件抽象层必须提供对传递数据的封装、解析和分发功能。
第三,要支持配置查询功能,SDR系统中一块处理器上可能需运行多个组件,由于不同组件所需的端口数量、连接方式和消息长度等都有所不同,因此需要通过动态配置的方式使硬件抽象层能够适应不同的组件需求,同时支持配置结果和运行状态的动态查询。
3 互连架构的实现
在互联架构中,硬件抽象层通过屏蔽硬件平台相关的底层通信机制、封装标准的通信接口,实现波形组件间通信方式与硬件平台的分离,提高了波形应用在异构硬件平台间的跨平台可移植性;硬件抽象层收发模块不关心收发数据的格式,对数据的封装由硬件抽象层API采用统一报文格式进行封装,调用硬件抽象层API收发数据;应用组件通过硬件抽象层API实现对组件的控制管理、寄存器寻址和数据端口间通信,支持应用组件的可复用、可移植和应用的动态部署。
3.1 数据报的构造
为了支持异构处理器中装配控制器与组件控制端口、组件数据端口之间的互连互通,需要指定组件端口间传输数据的统一格式;保证不同硬件处理器能以相同的语义理解数据,以根据收到的数据进行正确的响应。
为了与MHAL规范兼容,硬件抽象层消息帧格式采用MHAL的帧格式如图4所示。
每个处理单元上的每个波形组件都会提供若干信源函数和信宿函数,信源函数是发布硬件抽象层消息的线程,负责请求其他处理单元上的信宿函数执行特定的操作,或返回本地处理单元上特定函数的执行结果,信宿函数对硬件抽象层消息进行解析并执行相关操作,每个信宿函数都由一个LD进行惟一的标识,从而使硬件抽象层通信函数能够进行正确的路由转发。硬件抽象层负责接收波形组件数据,并将报文发送到LD相匹配的目的处理器。同样,从I/O接口驱动接收到数据后,将数据分发到与LD相匹配的波形组件上。
3.2 流量控制
硬件抽象层通信的流量控制在数据发送端实现,发送端根据传输链路中的数据量调整发送数据包的时间。硬件抽象层的实现中设计一个用于监测通信链路状态的线程,当通信链路中的数据包过于密集时向发送端发送消息,发送端经过一个随机延迟后再发送数据。
4 各处理器上互连架构的设计
为了灵活地支持多种波形及不同的业务类型,提高物理信道的复用率,降低时延,提高传输效率,互连架构的实现需要支持多线程、多优先级并提供配置接口,基于包交换的互连架构分层结构如图5所示。
硬件抽象层位于应用层之下,驱动层之上,由通信函数和接口组件两部分组成:接口组件提供消息传输功能,负责将硬件抽象层消息通过外部传输链路向外部发送,或者从外部传输链路中接收硬件抽象层消息。GPP和DSP硬件抽象层接口组件为硬件驱动程序,FPGA硬件抽象层接口组件为硬件接口实体模块;通信函数提供硬件抽象层消息的路由功能,负责将接口组件接收到的硬件抽象层消息或解析后的数据转发到特定的信宿函数,或者将特定信源函数传递过来的硬件抽象层消息或数据封装并通过接口组件向外发送。
4.1 GPP硬件抽象层设计
硬件抽象层设备提供的接口通过硬件抽象层设备组件进行封装,为上层GPP波形组件提供数据收发和路由功能。GPP硬件抽象层的实现如图6所示。
硬件抽象层设备根据目的组件的LD和物理通道的映射关系,通过相应的设备驱动将数据发送到与LD对应的处理器MHAL接口;反之,从与之互连的处理器的接口接收到数据后,根据接收数据与LD的映射关系,将报文转发给与LD相匹配的GPP波形组件上。
4.2 DSP硬件抽象层设计
DSP硬件抽象层设备可以看做对DSP各种外围设备接口提供的设备间通信机制的封装,DSP上的不同物理通信接口(PCI、rapid IO、以太网、EMIF、异构处理器I、GPIO等)提供的通信方式不尽相同,在速率、接口规范等方面有较大差异,因此需要对其进行不同方式的封装。提供接口配置、驱动、容错处理等机制,为DSP上的波形应用提供符合Qo S要求的通信API。
4.3 DSP硬件抽象层模块
DSP硬件抽象层如图7所示,DSP硬件抽象层通过I/O接口驱动实现数据收发:当有数据从I/O接口到达时,MHAL设备从相应I/O接口驱动中接收这些数据,对其进行适当解析,根据LD将其分发给本地的波形组件;当本地的波形组件有数据要向外发送时,硬件抽象层设备对数据封装,然后将处理后的数据通过I/O接口驱动向外部发送。
硬件平台开发者实现DSP硬件抽象层中定义的标准接口函数。DSP上的波形应用通过将DSP硬件抽象层实体在编译时联编到波形应用中,实现DSP上的完整功能。
4.4 FPGA硬件抽象层设计
FPGA硬件抽象层应实现对外部I/O接口和外部存储器访问接口驱动的封装,为FPGA波形组件提供一套标准的硬件抽象层接口时序,从而为波形组件提供异构处理器环境下透明的消息传输机制,硬件抽象层对传递数据进行封装、解析和分发,能够对到达数据进行解析,根据LD分发到对应的组件,同时对等待发送的数据进行适当封装,发往LD所指定的组件。
硬件平台开发人员负责提供FPGA中硬件抽象层的实体模块,FPGA波形应用开发人员通过将FPGA硬件抽象层实体模块例化到自己的设计中,实现完整的FPGA功能,经过一起编译后形成统一的映像加载到FPGA中运行。一个FPGA片内只需要设计一个硬件抽象层设备,所有的波形组件与I/O接口驱动均连接到硬件抽象层设备。软件无线电系统中同一块FPGA上可能需运行多个组件,由于不同组件所需的端口数量、连接方式和消息长度等都有所不同,FPGA硬件抽象层通过动态配置的方式适应不同的组件需求,同时支持配置结果和运行状态的动态查询。
5 结语
异构多处理器平台互连架构通过硬件抽象层为波形应用提供了统一接口,实现了软硬件的分离和组件间无缝通信,一般而言,对硬件接口的抽象层次越高,组件移植性越强,但可能存在复杂度高而性能降低的不足。寻找更加有效的软硬件分离方法以及对接口抽象与性能之间关系的建模和量化研究将有助于异构处理器互连架构的设计。
参考文献
[1]MITOLA J.The software radio architecture[J].IEEE Communi cation Magazine,1995,33(5):26-38.
[2]ULVERSOY T.Software defined radio:challenges and oppor tunities[J].IEEE communications Surveys and Tutorials,2010,12(4):531-550.
[3]GOMEZ I.MAROJEVIC,V,GELONCH,A.ALOE:an Open Source SDR execution environment with cognitive computingresource management capabilities[J].IEEE CommunicationsMagazine,2011,49(9):76-83.
[4]Anon.JTRS support and rationale document for the softwarecommunications architecture specification(version:2.2.2)[S].Joint Tactical Radio System(JTRS)Joint Program Office,2001.
[5]BIEBERLY F.Heterogeneous processing in software de fi nedradio:flexible implementation and optimal resource mapping[D].Blacksburg:the Virginia Polytechnic Institute and StateUniversity,2012.
[6]JTR Joint.Specialized hardware supplement to the softwarecommunication architecture(SCA)specification[S].[S.l.]:[s.n.],2004.
[7]JTRS JPO.Extension for component portability for specializedhardware processor(SHP)change proposal 289(CP289)[S].[S.l.]:[s.n.],2005.
[8]JTRS JPO.Joint Tactical radio system(JTRS)standard modemhardware abstraction layer application program interface(API)[S].[S.l.]:[s.n.],2007.
异构处理器平台 篇2
随着社会的信息化发展，很多部门逐渐建立起各自的业务信息系统，但由于各业务系统建立时间和提供商不同，也导致各种数据的存在形式、来源和记录格式也各不相同，这对各部门、各系统之间实现数据共享带来不便。同时，随着社会高速发展，各企业部门对数据的“实时性”需求也越来越高，因为数据实时性越高，便更有利于企业部门高层作出更及时、更准确的决策。特别对于那些目前仍然主要采用以“文件形式”记录数据的部门来说，将具有多种来源途径和记录格式的文件型数据实时处理、集成，并最终建立统一、透明的“综合数据实时共享平台”，为企业或部门的高端决策提供实时数据支持，已是迫在眉睫。
以“文件形式”记录的数据在存储、提取、使用效率以及统计查询等方面仍存在较多不便。首先各类数据的“多源”存储，给数据文件的获取带来不便，同时也较不稳定;其次，各类数据的“记录格式”不统一，也不利于数据信息的提取;再者，数据的“文件型”记录，造成数据的“多次使用必须多次提取”，特别是对于部分数据在抽取完成后需要进一步处理加工过程时，就很大地影响了数据的使用效率，也加重了系统的负荷;最后，随着各类数据文件的日积月累，一方面容易造成文件的丢失，另一方面也不方便数据的管理和历史信息的查询统计。
针对目前数据文件在这些方面的不足，本文设计并实现了“多源异构海量数据实时处理平台”，该平台能实时从多种数据路径获取并处理多种数据文件，并按照各数据记录格式实时提取并将处理完的数据保存到数据库，不仅克服了文件型数据在保存、使用效率和统计查询等方面的不足，而且实现了各业务系统之间“多源异构数据”的实时共享。同时，将各类数据都统一保存到数据库后，对其他基于数据库开发的信息系统的开发与发展具有很大的意义[1]。
1 系统分析
1.1 系统数据源分析
目前各企业部门业务系统的数据来源途径主要有四种:远程FTP服务器、局域网数据服务器、局域网数据库服务器和本地数据服务器[2]。
(1)远程FTP服务器:系统平台通过互联网连接一台或多台FTP服务器，文件更新频率可能各不一样，对服务器存储的文件有下载权限。
(2)局域网远程数据服务器:在局域网内部，但物理距离较远，建立多台远程数据服务器实现数据共享，主要用作存储各种类型的文件型数据，各文件更新频率不定。
(3)局域网数据库服务器:在局域网内部，有部分数据经过其他系统处理，将处理完的产品数据保存到局域网的数据库服务器，通过权限设置为其他主机提供数据共享。
(4)本地服务器:本地服务器主要存放一些本地的数据文件。
系统数据源总体架构如图1所示。
1.2 系统设计目标
建立“多源异构海量数据实时处理平台”在功能上主要包括以下目标:
(1)系统具有基本的参数设置功能。主要是对各种数据存放位置的设置，比如:设置数据路径、FTP站点、必要信息的增删改查等。
(2)系统能够实时监测各类数据，对于最新更新的数据文件，能够实时获取并处理，并且最终保存到数据库中，同时能够通知其他系统实时使用最新数据。
(3)系统能够完成必要的数据保存、备份以及其他的各种维护功能。
(4)该系统能够24小时不间断运行于服务器端，必须保证数据的实时性、准确性以及系统的稳定性。
(5)基于软件设计的基本宗旨，该系统应具有良好的可扩展性。
2 系统设计
2.1 系统框架
根据本系统大的设计要求和目标，系统总体框架主要分为实时监测模块、实时处理模块和实时保存模块。
实时监测模块主要功能是对所有数据源上的数据文件进行实时监测，当有新增文件或者有文件内容发生变动时，能够实时获取该文件，然后交予实时处理模块处理。
实时处理模块主要功能是实时处理由实时监测模块监测到的新增或者内容发生变动的文件。该模块主要包括文件判断和文件处理两个功能，文件判断主要是用于判断实时监测到的文件是否为需要处理的文件，而文件处理主要包括数据抽取和数据加工。具体处理细节按照各种数据文件的要求不同。
实时保存模块主要是将实时处理完成后的数据保存到数据库中，并且在数据库中形成相应记录以通知其他系统的实时使用最新数据[3,4]。
此外，系统还包括了数据备份、数据清理等一系列必要的数据库维护功能。为了数据的安全，数据备份是必不能少的。本系统处理的数据种类较多，而且各种数据的使用情况各不相同，其中，有些数据需要永久保存，而有些数据只是用作最近时段的实时展示，有效时限较短但占用资源又较大，所以不需要永久保存，对这些数据则需要系统定时清理。同时对于一些存放临时数据的中间表，也需要系统定时清理。
2.2 系统功能设计
系统主要功能包括实时监测、实时处理和实时保存等三大模块。
1)实时监测
系统的实时监测模块主要分为两种方式:“定时扫描”和“实时监测”。主要是根据数据的存储位置和数据文件的特征采用不同方式。
对于远程FTP数据文件实时监测主要是采用“定时扫描”的方式，即指每隔指定时间后对所有文件进行一次扫描，以发现这段时间内是否有新增文件或文件发生变化。对于远程FTP服务器无法使用实时监测路径方法，系统主要结合FTP文件更新频率设置系统定时扫描频率。对于具有固定文件更新频率(即每隔固定时间更新一次文件)的FTP服务器，系统主要按照文件的更新频率设置系统扫描频率。而对于没有固定文件更新频率的FTP服务器，系统扫描频率主要根据实时性要求和系统与FTP服务器负荷而定。系统扫描频率越高，对系统与FTP服务器负荷就越大，所以在保证系统和FTP服务器正常运行的前提下，实时性要求越高，扫描频率就越高，反之相反[5]。
对于局域网远程数据服务器，可以在本系统平台建立映射盘，类似访问本地磁盘一般访问该远程数据服务器中的数据，所以对于该种存储方式的数据可以像监测本地文件一样使用“实时路径监测”，.NET已经提供了该类方法的实现，即当某路径有新增文件或者有文件发生修改时都能得到该文件的具体信息。同时，该方法的实时性较高。
对于本地服务器，也可采用“实时路径监测”方法对文件路径进行实时监测。
对于局域网数据库服务器，主要有两种方法:“定时扫描”和“使用触发器”。“定时扫描”主要和前文相似，每隔指定时间检查目标数据库是否有数据更新。“使用触发器”主要是结合数据库的触发器技术，对目标数据库设置触发器，当目标数据发生更新时，实时通知本系统数据库，对更新的目标数据进行处理。
2)实时处理
实时处理模块作为本系统一个核心模块，主要是处理实时监测模块监测到的最新实时文件。该模块主要包括文件判断和文件处理两个功能。
(1)文件判断:采用实时监测方法监测的是某一个路径下的所有内容，但是并非该路径下的所有文件都是所需要处理的文件，所以根据实际需求，对监测到的文件还需要判断该文件是否为所需文件，判断依据主要依数据实际需求而定。
(2)文件处理:当文件判断确定为所需数据文件后，就将对该文件进行处理。其中，文件处理主要包括数据抽取、数据加工等过程[6,7]。
a)数据抽取:按照各自的文件格式将所需的信息抽取出来。系统处理的大部分文件主要是文本数据格式，对该类数据文件只要进行简单的数据读取就可以[8]。但同时还有一些数据文件可能还使用了加密技术，所以在数据抽取之前还需要按其加密格式对其进行解码，再处理为所需的数据[9]。
b)数据处理:根据各种数据需求不同，处理的需求也不同，目前主要分为以下几种处理方式:数据提取、数值计算和数据统计等，而对于具有时空特性的一些数据，除以上几种方式外，可能还有:插值、生成等值线/等值面、平滑和图层叠加等，最终生成具有时空特性的空间GIS数据[10]。总之，对于各种数据，各自的读取格式、数据计算要求以及最终生成的产品数据形式也各不相同[11]。
3)实时存储
实时存储模块主要是将实时处理模块处理完成后的数据保存到数据库中，同时在数据库中形成相应记录以方便其他系统的实时使用最新数据[12]。其中，因处理完后的数据形式不同，数据存放形式也有所不同，在本平台中，数据库分为关系型数据库和空间数据库[4]，对于一些简单的数据主要存储在关系型数据库的表中;而对一些具有时空特性的空间GIS数据主要存放在空间数据库中[13]，比如各种色斑图和等值线/等值面数据等。
3 关键技术
3.1 数据实时处理模型
本系统根据目前数据存在的特点:存储在不同位置或者多种路径、数据格式各不相同、数据文件量增长更新速度较快等，针对因此带来的较多不便，比如因数据文件增长更新速度较快而导致数据文件越来越多，不便于保存，也不利于历史数据的统计与查询，更重要的是，很多数据文件还不能被实时处理和利用。
为此，本系统提出了一种“多源异构海量数据的实时处理模型”，主要包括三层架构:实时监测层、实时处理层和实时存储层。其中，“实时监测层”利用多种监测方法完成对多源数据的实时监测;“实时处理层”完成对“异构”且“海量”数据的实时处理;“实时存储层”完成对产品数据的保存和数据的实时被利用，同时也方便以后历史数据的计算和统计等。由此得出，本模型能够较好解决目前多源异构海量数据在保存和实时处理方面存在的诸多不便，有效提高数据的实时利用效率[5]。
系统三层模型架构图如图2所示。
3.2 数据并行处理
分析系统数据处理需求如下:
1)系统实时监测多种路径的“海量”数据，经常会出现同时有多个文件已经更新。
2)系统处理数据的“实时”需求，需要对每一个实时更新的数据进行实时处理。
再结合各种文件处理复杂度各不一样，有的文件处理较为复杂，耗时较长，所以会出现前一批数据还没处理完，后一批实时数据已经到达，导致系统来不及处理，因此不能满足系统的“实时”要求。
因此，系统采用“多线程”技术，为每一个实时更新的数据创建一个线程进行处理，最终实现并行实时处理海量数据文件[14]。但根据实际监测情况，会出现“很短的时间内有大量文件更新”的情况，且数据处理较为复杂，占用系统资源较大，一段时间内给系统带来较大负荷，因此系统制定如下“并行处理策略”:
1)设置系统最多同时并行处理指定数量的数据文件。具体数量由系统能承担的负荷和实际文件更新频率而定。
2)制定文件“处理优先级”。其中，根据客户对各数据的实时需求，实时需求较高的“处理优先级”较高，反之，实时需求较低的“处理优先级”也较低。
3)对于同一“处理优先级”的多个数据文件，根据文件的更新时间，优先处理较早更新的数据文件。
按照此策略，既能够有效缓解系统在文件更新高峰期时的负荷，同时又能够满足数据处理的“实时”需求。
4 应用实例
4.1 气象应用实例
通过以上对多源异构海量数据实时处理平台的设计，最终实现了基于Super Map的“多源异构海量气象数据实时处理平台”系统，并且已经实际应用在上海市嘉定区气象局日常业务中。
系统能够24小时实时监测多个路径，包括:一台远程FTP服务器、多台局域网远程数据服务器和多台本地数据服务器，对于实时监测的海量气象数据文件实时处理，对每一种格式的数据，按照各自的记录格式进行解码或者数据提取，再按照实际数据需求进行处理，并最终实时保存到各自数据库中。
系统框架图如图3所示。
该系统主要工作在于后台实时监测数据和处理数据，前台展示较少，图4为系统实时处理数据的记录首页。
同时，该系统主要处理的数据文件基本是以文本格式记录，用数值记录各格点的气象要素信息，不能直观地看出总体数值的空间分布和变化。该系统主要结合各样点数据空间分布和待创建表面的类型等特征，对每种特征的数据应用适当的插值方法进行处理，将文本型数据转换为具有时空特性的空间GIS数据[15]。本系统实现的插值方法主要有:距离反比权重插值、普通克吕金插值和样条插值。对于空间呈均匀分布且密集程度能够反映局部差异的样点数据集，比如Micaps的第四类格点数据，主要采用“距离反比权重插值方法”;对于插值字段值的期望(平均值)未知且恒定，数据变化成正态分布的数据，比如系统中的自动站各气象要素数据，主要采用“普通克吕金插值”[16];而对数据呈不均匀分布但输入点较多且较为密集的气象数据，如No Caws的自动站数据和Micaps的第一类地面全要素填图数据和第二类高空全要素填图数据，主要采用“样条插值方法”[17]。通过多种插值算法，最终生成等值线或者等值面等空间数据集[18]。
如图5所示，图的上部为自动站分钟数据，其中包括温度、风、雨量的各种气象要素信息数据，图的下部为将其中的“温度”要素经过“数值提取插值平滑”后生成的等值面数据集。
4.2 运行环境
目前，系统正在以下运行环境上运行:
硬件设备如表1所示。
支持软件如表2所示。
系统在长时间的试运行过程中较为稳定，且能够很好解决目前上海市嘉定区气象局业务所需的气象数据文件处理。
5 结语
本文针对目前各业务系统数据文件的“多源、异构、海量”等特点，结合对“实时性”的需求，设计了一种对“多源异构海量数据实时处理模型”，能够实时监测以多种形式存放在多种路径的海量数据，对所需数据文件能够及时响应，实时并行处理具有多种结构的海量数据文件，最后将处理完的数据实时保存到各自数据库中，确保数据能够实时被使用。同时，系统在数据处理过程中，结合各种数据的空间分布等特征，采用各种适当的插值算法，将文本记录的数据转换成更加直观的具有时空特性的空间数据，使数据得到更好的展示。
异构处理器平台 篇3
随着计算机应用技术的发展和信息系统规模的不断扩大，分布式计算机正在以惊人的速度引领IT技术的潮流。分布式对象计算实现了不同对象之间的透明互操作，解决了大型企业和商务公司运行过程中的诸多问题，已经在金融、通信等行业部门得到广泛的应用。最近几年，由于Internet在各个领域应用的普及和深化，用户迫切需要能够方便地实现Internet上跨平台、语言独立、松散耦合的异构应用的数据共享和应用集成，这对分布式计算提出了更高层次的要求。Web Services作为一种新的技术应运而生，提出了面向服务的分布式计算模式，用于解决在不同平台下应用之间的协同性。Web Services是一种部署在Web上的对象，它们具有对象技术所具备的各种优点，同时，Web Services建立在以XML语言为主的、开放的Web规范技术基础上，因此具有比任何现有的对象技术更好的开放性，是建立互操作的分布式应用程序的新平台。Web Services平台是一套标准的集合，它定义了应用程序在Web上实现的互操作性，可以使用不同语言，在任何平台上编写需要的Web Services。基于上述分析，Web Services可以有如下的表述：
(1)模块化的应用程序结构，它可以在网络中被描述、发布、查找以及调用。
(2)基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，因而能与其他兼容的组件进行互操作。
(3)由企业发布的能完成其特别业务需求的在线应用服务，其他企业和应用软件能够通过Internet访问来使用这些应用服务。[1]
在过去电子政务的使用和实施过程中，各个职能部门会有多套系统(如Windows,Linux等)，并且这些系统是基于不同平台模式下(.NET,J2EE平台等)，随着业务规模的不断扩大，行政部门之间的交互性与协同性将日益增强，系统需要根据工作流和用户进行交互，然而异构数据资源无法直接进行共享，一个用户无法在异构系统中同步获得数据信息。因此，电子政务平台需要逐渐发展成为一个全开放，可与其它异构系统进行交互，以实现跨机构、跨系统的应用系统。在这种情况下，需要建立Web Services来统一管理和调整，对于Web Services与客户端信息交互的方式通过固定格式的XML文档来实现，从而真正实现异构平台的应用和数据的集成，以实现软件即服务的操作。所以，Web Services的应用构架将成为实现电子政务解决方案的有效方式，比如电子政务网络上的用户根据用户的权限通过一次性登录，就可以访问平台上不同机构所发布的服务，共享各个相关部门的数据;电子文档在各个行政部门可以跨系统进行传阅、审批等业务，极大地提高了政府办公效率，真正实现“无纸化办公”。在Web服务建立的基础上，需要保证整个系统在数据传递上的安全性，可以对XML文档进行加密处理。
2 系统架构
电子政务系统是一个数据流与工作流集成的应用平台，是一个数据开放的基于XML和Web Services数据交换体系。整个系统将参与交换的各机构异构应用系统看成是客户端可访问的服务对象，并通过消息传递机制、事物管理机制、工作流流程等建立起一个可扩展、集成数据和应用的系统结构，从而动态实现应用和数据的深层次交换和整合，主要是解决与促进各机构同构现有的应用系统之间信息交互、协同办公的问题，达到将业务流程、应用软件、数据以及各种标准联合起来，在两个或更多的政府、政务应用系统之间实现无缝连接，使它们像一个整体一样进行业务处理和信息共享[2]。如图1分布式系统结构图所示。
从图1所示的系统结构图可以看出，客户端通过发送请求可以通过Web Services所提供的应用接口在.NET平台下和J2EE平台下共享A部门和B部门的数据业务，而不需要分别进入各个系统单独进行操作，真正实现了不同系统、不同平台下工作的统一性。系统结构中的核心环节是Web Services模型的建立。
首先，建立一套完整的基于Web服务的电子政务应用系统集成模型需要将各个职能部门(如图1所示的A部门和B部门)的实际应用逐渐转化成一组统一使用的业务逻辑单元(数据共享服务)，这些业务逻辑单元为Web Services提供了集成的基础条件。同时，由于Web Services继承了组建开发和Web应用的优势，各种不同平台下的应用系统将根据标准的SOAP(Simple Object Access Protocol，简单对象访问协议)协议作为消息传递机制，进行结构化的数据访问和交换，得到相应服务请求的执行结果。同时，电子政务系统的Web集成模式是将行政机构之间的多种应用系统按照规定的协议WSDL(Web Services Description Language,Web服务描述语言)被封装成可被Internet调用的Web服务，WSDL定义了一套基于XML的语法，用来将Web Services描述为能够进行消息交换的服务访问点的集合，集合中的元素包括访问地址、变量等信息[3]。因而，电子政务系统中大多数Web Services都带有WSDL文档，指定应用程序提供的Web服务信息，如Web Services所提供的应用功能、Web服务的映射地址和客户端如何选择服务传输消息，电子政务应用程序利用这些信息分析Web Services的WSDL文档，寻找满足各个部门和用户特定需求的Web Services，使得整个Web Services更加层次化和有序化。最后，创建UDDI(Universal Description,Discovery and Integration，统一描述、发现和集成)注册中心，实现Web服务的发布和发现，为用户提供了一致的接口，使得已经发布的Web服务能通过编程被需要的请求者发现，从而建立起服务请求、服务提供和服务注册的Web Services系统构架。
3 异构数据共享
在电子政务系统实际使用的过程中，一个用户可能在异构系统中担任不同的角色，当该用户需要了解所有业务信息的时候，需要采用不同的方式登录系统完成相应的业务职能，无法同时获得数据信息，造成了工作流程的复杂性，极大地影响了工作效率。因此，异构数据共享成为系统集成的核心环节，从而在建立和管理基于Web系统的时候，XML提供了一种统一、有效的数据标准，同时具有显示和定义数据结构的能力[4]。在电子政务集成应用系统交互的过程中，需要存取异构多数据源数据，它们之间的数据无法进行直接转化和交互。所以，对于异构多数据源之间的访问，在系统中间层上生成的XML文档可以包括来自多个独立的数据库(比如SQL Server、DB2、Access和Oracle等)中的数据，使数据形成统一的格式，建立与不同平台下多个数据库的连接，后利用建立的公共模型来表示各数据源的数据，形成高效紧密的业务链接[5]。通过Web Services应用程序可以用标准的方法把相应功能和数据展示出来，供其它应用程序使用或用户直接使用，使用户能够迅速而完整地获得数据信息，与此同时，XML数据的更新同时也会同步地影响各个数据库相关数据信息的更新，完善了系统的数据架构，根据上述的分析，建立如图2所示的数据交换平台。
从图2可以看出，基于Web Services的数据交换平台是电子政务系统实现集成化和共享化的关键部分，一个基于XML格式的数据交换接口，所有不同类型和格式的数据都在这里进行有效控制。在此基础上，权限流控制是统一数据交换接口的重要部分，Web Services的服务对象是用户，不同权限的用户在获得共享数据的范围不同，接收通过格式转换后的XML数据，对这些数据进行分权限处理，然后传给相应的事务处理模块。事务处理模块处理完数据交换接口传来数据后，又将结果以XML文档形式传给数据交换接口。这些以XML形式存在的结果根据其数据流的方式，返回到相应的应用系统中。需要特别指出的是，权限流控制层针对XML数据进行识别，将不同的数据文档转为系统可以识别处理的具有特定标识的XML文档进行传输。
同时，对于XML中的某些元素，可能在多个数据源中的源字段标记不同[6]，数据类型也不尽相同，但它们实际应用中表示相同的字段。所以，将数据固定在中间层的好处是语义可以连续识别，有效地消除数据冲突，保持数据的完整性、一致性。XML作为结构化数据的一个统一标准，可以屏蔽掉多种数据源，而用一致的XML数据呈现给客户端和用户，为用户与数据库相关的办公自动化等类型的应用提供了基础性条件。
4 系统模块
电子政务系统的实现是建立在Web Services和XML语言的基础上的，异构系统之间数据交换是整个系统重要的模块之一，它将整合原有系统中的各种不同的异构源，统一成XML数据标准，最后形成一致的、开放的、集成的应用平台。以用户登录为例，在集成平台的两个系统之下，都有该用户的角色信息，通过Web服务提供相应接口，实现多个系统用户登录的服务体系。具体实现如下：
4.1 利用XML建立用户的数据信息
4.2 对数据信息的XML文档进行加密
4.3 编写Web Services服务组件及相关方法
(1)添加用户信息——addUser。
(2)更新用户信息——updateUser。
(3)删除用户信息——deleteUser。
(4)备份用户信息——bakeupUser。
(5)用户日志信息——transactUser。
这些基本方法都是应用服务根据客户端接收到的SOAP消息，用来及时更新电子政务系统中的用户数据和应用，然后将建立的Web Services服务组件系统部署在应用服务器上，并将生成相应的WSDL文档提供给调用服务的电子政务系统。
4.4 在电子政务系统中调用用户同步服务组件
在电子政务系统中，可以根据WSDL文档获得服务组件的访问地址以及提供的函数方法，然后在合适的地方访问服务，调用用户同步方法，如对用户的增加、更新、删除等操作以及对于系统用户数据备份的操作。
基于上述的分析，Web服务为电子政务系统提供了异构数据交互的良好平台，不仅限于用户信息的使用，同时可以应用政务文档的发布、批文的审批等业务环节，充分体现出了Web Services在支持服务数据的异构结构、服务描述的集中化存储和发布、服务的动态查询以及服务的组合等诸多方面的优势，从而建立起一套完整的电子政务平台。
5 安全分析
当电子政务系统引入当前的Web服务，那么系统将会不断增加新的层次，系统的安全性面临更加严峻的挑战，政务信息对于安全性有较高的要求，因此，整个Web服务需要满足以下四个基本的安全性要求。
(1)机密性：指信息对没有经过授权的个人、实体或进程的不可用性或不可公开性，并保证消息内容不对没有经过授权的个人公开。所以，数据在以XML格式进行传递时要进行加密操作。
(2)授权：指权限的授予，包括根据访问权限授予访问权和保证发送方被授予发送消息。因此，系统实现的过程中，消息传递模式SOAP需要进行数据签名，从而保证授权的正确性和有效性。
(3)数据完整性：指数据没有以未经授权的方式或被未经授权的用户不可察觉的改变或者破坏的性质，从而保证消息在传递的过程中不会被偶然或者故意修改。在安全性策略中，电子政务的层次增加了事务模式，从而保证了数据的完整性。
(4)原始性证明：对消息或数据的发送者进行标识的证据。断言消息由正确标识的发送者传送，并且不会重新发送以前传送过的消息。
因此，在数据传输的过程中，各种安全技术从某种程度上加强了Web Services的安全性，它能够定制数据传输到后，能否被接受者所查看，进一步完善了传输后的安全，各种组织也在不断地制定Web Services的安全标准，比如SAML和WS-Security[7]等，从而保证电子政务平台在Web Services的支持下高效、有序、稳定的发展。
6 结语
采用Web Service技术进行电子政务异构系统的集成，大大提高了系统的可扩展性和兼容性，增强了行政部门内部的协调能力，增强了应用系统的服务质量。Web Services提出了一种新的面向服务的体系结构，它结合了面向组件方法和Web技术的优势，可以被任何应用系统、在任何地方动态访问，而不必考虑服务的具体实现。所以利用Web Services框架结构，能抛开各类应用系统的对象体系、运行环境、开发语言等技术方面的束缚，打破不同机构间的界限，建立稳定安全的电子政务平台。但是，单一的Web Services功能毕竟相对简单，具有一定的局限性，难以满足电子政务所有实际应用的需求，因而需要对Web Services技术进行合成[8]，以生成功能更加全面，应用更加广泛的Web Services来适应各种实际需求。
参考文献
[1]顾宁,刘家茂,柴晓路等.Web Services原理与研发实践[M].北京:机械工业出版社,2007.
[2]Medjahed B,Rezgui A,Bouguettaya A,Ouzzani M.WebDG-An Infrastructure for E-Government Services[J].IEEE In-ternetComputing,2003,37(18):58-65.
[3]Etban Cerami著,陈逸译.Web服务精髓[M].北京:中国电力出版社,2003.
[4]Short S著,戴荣,马方平,吴健等译.构建XML Web服务——基于Microsoft.NET平台[M].北京:清华大学出版社,2002.
[5]陈宏,曹健.分布异构环境下的数据集成方法及应用[J].计算机工程,2005,31(5):115-116.
[6]Akmal B.Chaudhri,Awais Rashid,Roberto ZIcari著,邢春晓,张志强,李骅竞等译.XML数据管理[M].北京:清华大学出版社,2006.
[7]W3C.Web Service相关标准[S].http://www.w3c.org,2003-06.
异构处理器平台 篇4
20世纪90年代以后,Web应用遍及全球,网络深入人心,数据库日益普及。大型机构由于分支机构不断变化、产生,原有集中式应用模型不能适应新环境,分布式数据库成为主要研究方向。企事业单位不能真正解决信息孤岛问题[1],信息化建设很难成功,真正发挥应有作用。为消除信息孤岛,实现信息共享,迫切需要建立一种公共环境,对用户提供统一、透明的访问界面,信息集成研究因此而起。历经十多年信息化工作积累,信息化程度已初具规模,为了能共享数据,可以建立统一的数据交换平台实现。交换平台为系统提供了基于XML的数据交换机制,可以直接为全局的应用系统提供信息交换服务,是实现信用信息系统业务功能的技术基础。同时,为了能更充分利用现有系统,可采用Web服务和中间数据库构建数据交换平台。
1 异构数据库
1.1 异构数据库系统
异构数据库系统是相关的多个数据库系统集成,实现不同数据库之间数据信息资源、软硬件设备资源和人力资源“并轨”共享,。为各种系统提供集成、统一、安全、快捷的信息查询、数据挖掘和决策支持等服务,实现数据(主要是异构数据)共享和透明访问。每个数据库系统在加入异构数据库系统前就已存在,拥有自己的DBMS(Data Base Managment System)。异构数据库各组成部分具有自身的自治性,实现数据共享的同时,仍保有自己的应用特性、完整性和安全性控制。异构数据库系统的异构性主要体现在三个方面:系统异构、DBMS异构和逻辑异构[2]。
1.2 异构数据库的发展和特征
数据库技术的出现为信息管理带来了新手段。作为计算机科学技术发展最快、应用最广泛的重要分支之一,数据库已成为计数机信息系统和应用系统的重要技术基础和支柱。数据库技术发展大致经历了三个阶段,在发展第二和第三阶段,分布式数据库系统(Distributed Databses)基本解决了集中式数据库系统的弊端;但对不断发展的大型机构,由于发展阶段、应用目的不同等原因而产生的不同数据系统,有机地结合在一起共同工作仍存在问题,这便首次产生了异构数据库系统的研究需求。在20世经90年代,数据库发展面临新挑战,在Web、新的应用需求及硬件技术飞速发展情况下,web提供一个集合异构数据源平台;Web发展促进了异构数据库系统理论进一步研究和发展。异构数据库系统是对分布式数据库系统的继承和发展,二者既有相同之处又有区别。最根本的区别在于:分布式数据库系统只拥有单一逻辑数据库,虽然可以在物理上分布,但只有一个DBMS为其服务,提供一致的查询与更新,严格说,各分布子系统是同构的;而异构数据库系统则以多个异构、自主的数据库系统为基础,通过一定程度集成而构成一个分布式数据库系统。异构数据库特征则可从以下三方面说明[3]:
(1)分布性。
异构数据库系统各组成部分是分布在不同位置的各种自治数据库系统,通过通讯网络建立各部分之间连接。系统的数据保存在分布的数据库系统中,可以以各不相同方式保存,没有严格逻辑要求。每一个独立自主的数据库系统只是整个异构数据库系统中的一个网络结点。
(2)异构性。
排除数据库宿主系统的异构性,异构数据库系统的异构性主要由两方面产生:
(1)数据库管理系统(DBMS)的异构:由于组成系统的各数据库系统可以不同,因此形成了DBMS的异构,这种异构实质上可分为三个方面:
A.结构不同:根据不同的方法论,DBMS采用不同的数据模型和数据结构,反映在物理上的存储方法也可能不同。例如层次数据库与关系数据库。
B.数据存储种类异构:相同或相似的现实世界数据,存在表达多样性,因此不同数据库系统存储方式不同,可以是数据类型、范围、精度以及组成部分的异构。例如:在一个数据库中可以采用整型表达的数据,很可能在另一数据库中采用字符串表示,而在第三种数据库中则变为某种对象的一个属性。
C.关系表达异构:由于不同环境及需求,事件中两个事务之间关系可从多方面理解,由此造成在数据库中关系表达的异构,这种异构与该数据库系统采用的数据型或密不可分,可能出现同一数据的不同分割和组合以及关系连接。
(2)数据遗漏及冲突:不同的应用对数据对象的不同侧面要求不同,很可能在某领域内非常必需的数据在另一环境中却可以忽略,或者实际上是另一种数据,所以数据遗漏和冲突在所难免。
(3)自主性。
构成异构数据库系统各子系统具有各自的自主性,拥有对自身系统内各种资源使用的权利,包括设计、执行、修改等,同时拥有与其它系统交互的权利,包括加入、退出、通讯、提供服务等。它们有权利接受外来服务请求,也有权利拒绝请求服务的权利。但在这些权利与承诺的系统义务之间必须有机结合。
2 数据交换平台的总体设计
2.1 系统的体系结构
由于各业务系统是异构的,首先必须定义一个统一的XML文件数据标准进行交换。考虑到旧系统改造和新系统扩展方便性,本文采用的数据交换系统结构如图1所示[4]。
首先,各业务系统按自身系统数据结构情况开发应用程序,以共同的数据标准规范,将要共享的数据生成合符要求的XML文件;然后将XML文件通过数据采集接口模块传输到数据交换平台。这样,外部系统就可通过查询请求查询到平台中间数据库中自己需要的数据,从而达到数据共享目的。下面,对图1数据交换系统架构四大部分作一简析。
(1)业务系统:是指企业内部各业务系统,负责将自身系统需要共享数据转换成规范的XML文件。它是共享数据提供者,又是共享数据使用者。
(2)外部系统:是指需要查询共享数据并具有对应权限的用户系统。
(3)数据采集模块:是数据交换系统重要组成部分,包括传统采集接口和Web Service接口两种方式,将要传输的数据采集出来,送到数据交换平台处理。
(4)数据交换平台:是数据交换系统重要组成部分,由原始数据池、平台中间数据库及核心处理模块三部分组成,负责XML文件的处理和存储。
数据采集模块和数据交换平台是系统实现数据共享的核心部分。
2.2 数据交换平台
数据交换平台负责所传输到达的XML文件转换和存储操作,其中包括原始数据池、核心处理模块和中间数据库三部分。
(1)原始数据池。
它是数据缓冲池,在采集模块和核心处理模块之间起缓冲作用;负责将从数据采集接口模块中采集到的数据以XML形式分类暂时存储[5],在核心处理模块空闲时再行处理,处于数据交换和存储模块最前方位置;数据按各业务系统分类存放,各业务系统都有自己对应的文件夹,XML文件暂存在文件夹里,如果在获取数据过程中有错误发生时,将错误信息打包成XML文件,发送到错误反馈信息子目录中。
(2)核心处理模块。
它是数据交换的中心,是连接原始数据池、数据库和外部系统的纽带,负责XML数据处理和数据库数据转换,包括两种功能:
(1)从原始数据池传输过来的XML文件,按照规定的数据结构存放到中间数据库中。(2)根据用户查询请求,将需要的中间数据库的共享数据处理组合成XML文件,传输给用户使用。
这里涉及XML文件到数据库之间数据转换问题。由于原始数据池中数据以XML文档形式发送到平台中间数据库,假如将整个文档原封不动存储到数据库中,就会切断数据与数据之间联系,且难于管理和维护。因此数据交换平台中使用的是按XML文档结构层次拆分的,分别存于不同的表或字段形式当中。
(3)中间数据库。
它是业务系统上传的共享数据集中存储的地方,是由核心处理模块处理后的共享数据。各业务系统只要将自己的数据按照一定通用格式如XML提供出来,完全不用改变原来数据库结构。中间数据库,方便了网上检索需要,易于操作。这一方式使各业务系统对自己的数据有完全的控制权[6]。如果用户需要查询信息,那么对应的数据信息将从中间数据库取出,并经核心处理模块进行从数据库结构到XML文件的处理,将XML文件传输给用户,在用户的系统中被处理和显示。
中间数据库的数据表分为两大类:基本码表和用户表。码表用于维护系统中基本不变的数据,包括性别、民族、职务、国家、提交方式、办结结果、特别程序种类、特别程序结果等。用户表用来维护用户日常经常操作的数据,主要包括申请人信息表、申请企业信息表、受理信息表、业务信息表、业务规则信息表、补给信息表、审批是想信息表、经办人信息表、办结信息表、特别程序信息表等。
3 结束语
Web技术及Internet的飞速发展,使产品信息集成要求迅速与新兴技术相结合;但由于信息来源多样化,产生了大量异构数据。如何使各种应用程序能够透明地操作多种数据源,在应用程序和各数据源间建立传输信息的纽带,对实现信息化至关重要。本文探讨了基于XML的企业信息集成问题,可为企业间信息共享提供良好的理论支持。
参考文献
[1]熊光楞等:《并行工程的理论与实践》[M];清华大学出版社,23-24。
[2]李黎:《基于XML的异构数据库数据集成技术研究》[R];四川师范大学计算机科学学院,2008:5-7。
[3]C W Chung.“DATAPLEX:An access to heterogeneous distributed databases”[M],Comm.——ACM,Vol.1No.1.2002.
[4]李阳:《数据交换系统设计与实现》[R];北京交通大学,2006:21。
[5]Charles F Goldfarb.《XML实用技术》[M];清华大学出版社,1999:56-58。
异构处理器平台 篇5
1 数据交换过程
数据交换能有效实现数据之间信息共享, 数据交换在现实中的应用意义重大。例如能实现企业业务之间的数据资源共享、业务协同, 彻底的冲破了信息孤岛的现象。数据交换理论在不同的数据环境中实现途径存在不同。在数据交换平台中, 主要包含以下几个部分:数据配适器服务、数据传输服务、数据安全服务、数据转换服务以及平台控制服务。数据交换的过程主要包括:数据提取、数据转换、数据传输、数据接收以及数据控制与管理。
数据交换中的第一环节是数据提取, 数据的提取同时也是对数据的识别, 通过连接上原始异构数据源, 对需要进行交换的原始数据进行提取, 对数据进行分析处理, 使得用户能实现数据信息之间的准换。那么可以通过数据信息提取法形式进行提出信息的原始数据源主要分为以下三种:第一, 数据库资源, 数据库资源是指专门对企业数据进行存储的各种关系数据库, 比较典型有SQL Server、Oracle、DB2;第二, 文件数据源。文件数据源是指, 在单位业务系统中, 具有特定格式的文件, 例如企业的工资表以及财务报表等形式;第三, XML文档。该种形式的文档能实现结构化的数据交换。在科技化的信息交换中占据着重要的地位。而在数据交换中的数据传输、以及数据交换平台相关的数据传输, 都是数据交换系统中比较重要的环节。在数据交换中, 数据转换技术其中最为核心的部分, 该项技术能实现数据的格式化转换, 下文将对数据转换技术进行详细的分析。
2 数据异构性分析
2.1 系统异构
数据系统的异构性是指, 数据源在其存在的数据系统环境、数据库管理系统以及实际数据操作系统中所表现出来的异构, 在数据形态上表现出来较大的显性, 对于数据系统的异构分析具有较强的现实意义。最为常见的数据异构就是数据库管理系统的不同。数据库管理系统从文件管理系统中发展而来, 能实现数据的结构和数据管理, 在数据模型基础上, 对物理数据模型进行异构。而操作系统的不同是指, 操作系统在各个数据库系统中, 其最为基本的操作系统可以是Windows、Unix, 但是信息在不同的操作系统中, 也具有着不同方式的表达, 因此数据也存在很多差异性。不同数据来源于不同存储格式, 有的数据来源于XML文件, 有的数据来源于其它格式, 存储异构的问题需要在数据交换技术中被解决。
2.2 模式异构
数据模式异构中, 数据长度不同比较明显。不同长度的数据, 即使其属于同一字段, 但是在不同数据形式之间的交换长度的定义也存在很多不同。例如, 不同长度的编译器中, 不同数据类型所能分配到的数据长度有着明显的差异性。数据模式的异构性还表现在数据精度的不同方面, 字段的属性的精度不同, 数据交换的双方都必须是数字类型。当一个数据的精确度是小数点后面两位, 那么来过一个要进行数据交换的数据精度也需要是精确到小数点后两位。
3 数据转换技术
3.1 XML文件数据模型交换
在异构数据之间进行转换技术, 就是对数据库中的中数据进行数据转换, 其核心就是对异构数据中包含的问题进行分析。数据模型实际上就是对数据固态特征的抽象化, 能充分展示出数据库管理的形式框架来。而数据模型同时也是数据库中数据的约束条件, 通过数据库的结构部分、操作部分对其约束。对XML数据交换模型进行分析, XML文件是模型中的中间数据, XML丰富的表现形式能将数据表示与结构相互分开[5]。
3.2 数据配置
在数据配置模块中, 主分为三大部分, 分别为注册集成、数据匹配以及数据卸载。这三部分对数据配置模块进行大力支持, 能帮助其实现功能。要想完成数据交换中的数据配置, 这三个模块在形式上缺一不可。其中, 数据注册集成, 实现了对应用系统中的需求集成, 将配置信息已统一格式写入XML文档中。数据匹配是指, 在传输的数据中, 为数据匹配提供规则, 实现数据转换。数据卸载是指, 在数据交换成功之后将需求运用的数据退出平台中, 并对数据信息进行卸载。
3.3 数据平台管理
数据的平台管理是指, 对数据日常交换中产生的日志以及数据浏览进行管理与维护。在数据平台管理模块中, 主要包括四部分:日志管理、用户管理、系统数据信息维护以及数据交换监控。其中日志管理是指, 在进行数据交换环节中, 会产生一些由于数据接收、数据发送等的历史数据记录, 用户数据访问记录档案等。而用户管理是指, 对数据交换平台进行直接管理, 例如信息交换的密钥、重点信息存储等。系统的维护是指, 在进行数据交换环节中, 难免会产生一些数据故障, 此时就需要系统维护对故障进行处理, 实现数据搜索的优化[6]。
3.4 数据映射之间的关系
在实际的异构数据交换技术中, 存在着以下的数据之间的映射关系。
Equal相等关系:该种关系比较简单, 所表达的含义是数据源中数据与目标数据相同, 在数据长度、数据类型以及数据精度等方面都能相互吻合。
Const固定值关系:该种关系是指需要被转换的目标数据与规定的数据常亮。
Null空值关系:该种数据关系是指, 在实际准换中, 目标数据为空。
Custom自定义关系:该种关系是指从数据用户的自定义公式中得出目标数据。
Double Config双配置表关系:数据源配置表能衍生出目标数据。
DBMapping数据表映射:该种数据关系是指在数据表的简单计算下, 能计算得出目标数据。
4 结语
随着科技信息技术不断发展, 各行各业中为了实现工作效率, 并将工作流程进行简化, 在企业数据管理中建立众多数据库系统。为了实现各个部门、单位之间的数据信息共享, 需要一种数据转换技术在各个数据库系统中运用, 实现数据资源的交换。对于数据交换平台汇中的异构数据转换技术的研究能实现数据库系统中的数据转换, 在时代发展中发挥着重要的作用。
参考文献
[1]王亚玲, 刘迪, 曹占峰.基于优先级的任务调度模型在数据交换平台中的应用[J].中国电力, 2008 (4) .
[2]芦大鹏, 郭荷清, 郑毅强.数据交换平台中的中介结构研究[J].计算机应用与软件, 2008 (10) .
[3]陈艳, 刘燕, 杨彦臣.XML技术在森林资源数据交换平台中的应用研究[J].河北林果研究, 2007 (3) .
[4]展翔.基于XML技术的异构数据库数据交换技术的研究[D].武汉:武汉理工大学, 2007.
异构处理器平台 篇6
现在,网络技术的发展促进了各种网络安全技术的应用,如病毒防火墙、入侵检测技术等。而对于这些网络安全技术的管理,则渐渐成为互联网管理技术的重点。通过对所有管理技术的总结,可以将现在广泛采用的技术方法总结为三类:(1)利用安全设备自身管理平台实现管理;(2)利用简单网络管理协议实现设备管理;(3)利用专业厂家所提供的管理平台和系统进行统一管理。
通过对上面三类管理技术和方式的详细了解,以及对现在网络安全设备管理具体需求掌握的基础上,本文构建一个对异构网络设备进行网络统一管理的平台,能够将网络架构进行有效扩展,从而满足网络日益增长的需求,最大可能地发挥安全设备的应用效能。
2 平台架构
通过网络安全设备的异构管理平台,能够实现对整个网络中所有安全设备的统一管理,为网络中数据和安全资源的共享和管理,以及多种安全管理模块的有效互动奠定基础。参考现在主流软件的设计思路,根据组件化的平台构建思想,可以将整个平台划分为四个不同的层次,即客户层、业务逻辑层、数据交换层和后台数据层等。
本文所构建平台,在具体的实现过程中,主要基于主流的B/S结构进行开发和系统架构,具体到不同的层,客户层采用RIA/AJAX技术、业务逻辑和数据交换层则采用J2EE架构,利用Java语言来实现,而后台数据库主要利用SQL Server系统来完成。
3 主要功能模块划分
对于文中平台主要功能的实现,则主要通过业务逻辑层来完成,概括起来主要包含四个方面的功能。
3.1 设备管理
对于设备管理模块来说,可以作为其他功能模块的基础,是其他模块有机结合的基础模块,主要包括几个子功能:(1)设备信息管理;(2)设备状态监控;(3)设备拓扑管理等。
这些子功能的实现,可以在网络拓扑和手动的基础上,通过统一通信接口来对设备的状态和性能进行实施的监控和管理,必要的情况下,还可以通过图形化的方式来表示,方便平台和系统管理员对设备运行状态的及时掌握和定位,减轻管理员的工作量。
3.2 事件分析
作为安全设备管理平台的核心模块,安全事件分析模块的目的就是对大量的网络事件进行分析和处理、筛选,减轻管理员的工作压力,所以,该功能模块的主要子功能有安全时间分类统计、关联分析和处理等。同样,该功能模块也能够通过统一通信接口来对各个安全设备所生成的时间报告进行收集、统计,在统计分析的过程中,可以根据不同的标准进行分类,如时间、事件源、事件目的和事件类型等,通过科学统计和分析,还可以利用图表的方式进行结果显示,从而实现对安全事件内容关系及其危害程度进行准确分析的目的,并从海量的安全事件中挑选出危险程度最高的事件供管理员参考。
3.3 策略管理
安全设备管理平台中的策略管理模块包含多个功能,即策略信息管理、冲突检测和策略决策等功能。通过对各类安全设备的策略进行标准化定义的基础上,就可以统一对设备的策略定义进行管理和修改,对当前所采用的策略进行网络安全事件冲突检测,及时发现可能存在的网络设置冲突和异常,确保网络策略配置的正确性和合理性。通过对网络环境中安全事件的深入分析,在跟当前所采用安全策略相比较的基础上,就能够为设备的安全设置提供合理化建议,从而实现对网络安全设备设置的决策辅助和支持。
3.4 级别评估
最后一个功能模块就是安全级别评估模块,该模块的主要任务就是对网络商业设备安全制度的收集汇总、实施情况的总结和级别的评估等。该模块通过对网络安全事件的深入分析,在结合安全策略设置的基础上,实现对网络安全水平的准确评估,从而为网络安全管理的实施和水平的提高提供有价值的数据参考。
4 平台中的通信方法
要实现网络中异构安全设备的统一管理,就需要通过统一的通信接口来实现,该接口的主要功能就是通过对网络中异构设备运行状态、安全事件等信息的定时获取,从技术的角度解决异构设备所造成的安全信息格式不兼容和通信接口多样的问题,实现网络安全信息的标准化和格式的标准化。
4.1 资源信息标准化
在网络安全管理中,所涉及到的安全资源信息主要包括安全设备的运行状态、设备配置策略信息和安全事件信息等。其中,安全设备的运行状态信息主要通过数据交换层中的通信程序通过跟安全设备的定时通信来得到,可以通过图表的方式进行可视化。这些资源信息主要采用RRD文件的方式进行存储,但是采用数据库存储的则比较少,这主要是由于:(1)RRD文件适合某个时间点具有特定值且具有循环特性的数据存储;(2)如果对多台安全设备的运行状态进行监控的情况下,就应该建立跟数据库的多个连接,给后台数据库的通信造成影响。
对于上面提到的安全设备的运行状态信息和安全事件信息,通过对各种安全设备信息表述格式的充分考虑,本文中所设计平台决定采用XML语言来对设备和平台之间的差异性进行描述,不仅实现了相应的功能,还能够为平台提供调用转换。而对于安全策略类的信息,则是先通过管理员以手动的方式将安全策略添加到平台,然后再在平台中进行修改,之后就可以在通过平台的检测冲突,由平台自动生成设备需要的策略信息,然后再通过管理员对策略进行手动的修改。
4.2 格式标准化
对于安全事件和策略的格式标准化问题,可以通过格式的差异描述文件来实现彼此之间的转换,这里提到的差异描述文件则采用XML格式来表述,而格式的自动转换则通过Java Bean的内置缺省功能来实现。
4.3 通信处理机制
对于通信接口而言,由不同厂家所提供的同类型设备之间的差异也比较大。所以,对于设备的运行状态信息,主要采用两种途径来获取:(1)通过标准的SNMP、WMI方式获得;(2)通过专用的Socket接口调用特定函数来获得。而对于网络运行中的安全事件,其获得途径也有两种:(1)通过专用Socket接口来获得;(2)将安全事件通过推送的方式发送到指定的安全管理设备。
通过综合分析,本文平台主要采用独立的通信(程1)序和集中设置调用的方法来获得安全资源信息,这样就可以实现对安全设备管理的最有效支持。本文所采用方式的实现机制为:平台通过标准接口获取网络的安全资源信息,再通过通信程序的调用设置功能,对程序调用的时间间隔及其语法规范进行定义。
5 总结
现代互联网技术的快速发展,促使网络中所采用安全设备的种类也越来越多,从而在网络设备管理中出现了多种问题,如异构设备的协同问题和安全事件的有效响应和处理等。所以,本文针对这些问题设计出一种对网络安全设备进行管理的异构网络平台。在该平台中,采用了一种异构安全设备通信处理机制,使得该平台能够对异构安全设备完全兼容。
参考文献
[1]赵悦,徐涛.统一网络安全管理平台建设研究.信息系统,2009;32(1):117~118.
[2]吴蓓,陈性元,张永福等.可扩展的网络安全设备内策略冲突检测算法.计算机应用研究,2010;27(4):1484~1488.
[3]鄣锡泉,姚国祥.网络安全管理的多维度可拓模糊综合评价.计算机工程,2011;37(4):287~289.
异构处理器平台 篇7
近年来, 随着互联网应用与信息化技术的快速发展, 高校的财务、教务、招生、后勤等各职能部门逐渐建立了相应的业务管理信息系统。各个信息系统的建设有效提高了办公效率, 促进了高校管理工作的规范化, 在高校改革发展中发挥了不可或缺的支撑作用。
随着校内各部门之间联动性的不断增强, “信息孤岛”的问题亦日渐突出, 各业务系统之间的数据不能充分共享与直接利用。如笔者所在的财务部门在学生学杂费管理工作中, 与教务、后勤等部门进行业务数据交换过程中, 常常会遇到数据传递不完整、不及时和重复维护等问题, 既影响数据的准确性, 也影响工作效率。
可见, 在高校“局部信息化”迈向“全面信息化”进程中, 焦点将逐步转移到业务的管理精细化和协同化, 信息集成和应用集成是大势所趋, 而在信息集成的过程中, 如何实现数据的集成无疑是重点。因此, 研究、构建适用于高校内部异构系统间的数据集成与交换平台则显得十分必要而有意义, 它是消除数据孤岛、实现各项业务数据有效交互的基础, 也为日后开展管理决策、建立门户信息服务打下坚实基础。
2 高校信息化的现状与问题
当前, 各高校信息化工作历经了“诺兰模型” (由美国哈佛大学教授查理·诺兰提出) 的初始、推广、控制阶段, 基本建成高速校园网, 高校各部门广泛地将信息系统应用在辅助教学、科研、行政等管理工作中。随着业务的深化和管理要求的提高, 现有信息化建设模式逐渐暴露出许多难以解决的问题和亟待突破的瓶颈, 主要体现在以下几个方面:
(1) 因缺乏统一规划, 不同时期建设的业务管理信息系统, 在技术平台、系统架构等方面都存在众多差异, 系统开放性、规范性和可扩展性均不可预料, 系统间横向协同的能力较差。
(2) 各业务管理信息系统建设时处于各自为政的状态, 缺乏统一的数据规范, 信息编码方式、数据的格式及数据的存储方式各异, 信息系统越建越多, 却逐渐陷入信息共享困难、数据无法有效集成的窘境。
(3) 信息维护的方式差异大, 不仅信息维护的途径和工具多种多样, 甚至许多业务仍然采用电子表格人工维护等方式, 数据的及时性、一致性和规范性均无法保证。需要应用这些信息和数据时, 往往出现不可靠、不可信或者不完整的情况, 校核这些数据又需要耗费巨大的工作量。
3 解决思路和步骤
针对高校信息化建设的现状和问题, 从尽可能保障现有业务正常开展、尽可能保护现有信息系统投资的角度出发, 必须构建面向异构数据的数据集成与交换平台, 以解决数据交互的难题;同时, 为了避免新建的信息系统重蹈覆辙, 还应逐步建立高校的信息化建设标准, 指导将来的信息系统建设。
(1) 建立高校信息化标准体系, 包括基础设施建设、信息编码规范、系统接口规范、信息系统建设框架等标准规范。对于新建的信息系统, 要求必须依照统一的高校信息系统建设规范, 从技术架构、数据架构和应用架构上确保有规划地建设;对于现已建成的信息系统, 遵照信息编码规范重新梳理信息编码, 在统一的系统接口规范下, 建设适配接口, 为数据交换与信息共享提供基础。
(2) 构建高校数据集成与交换平台, 用于高校内各信息系统数据的抽取、汇聚、清理、转换和交换;通过搭建数据总线和服务总线, 为各信息系统的数据交互打通渠道。在构建数据集成与交换平台时, 除了提供数据交换功能外, 还必须建立数据质量管理的机制, 确保平台数据的权威性和可信度。
(3) 为保障数据集成与交换平台的正常运行, 还应建立配套基础设施和管理制度, 包括:网络规划和硬件资源、安全防护、运行维护管理等。
4 平台建设的重点
4.1 高校信息化标准体系建设
信息化标准体系的建设是一个长期的过程, 需要各业务部门密切配合、持续完善才能起到实效。各项标准与规范主要包括基础设施的规范要求、应用系统建设的规范要求、信息编码的规范要求以及面向用户的交互规范要求等。在构建标准体系的过程中, 也可参考IT行业和软件工程的相关标准, 结合自身的业务特点, 形成符合高校信息化建设实际要求的标准规范。
(1) 开展业务流程调查, 结合校内各业务流程和数据产生特点, 编制各项业务的数据字典。若已有信息系统, 则需按规范格式提供数据, 为数据交换提供统一的依据。
(2) 信息编码规范设计。针对公共的数据集成与交换平台, 从整个高校的角度出发, 为公共的数据编制统一的信息编码, 避免多个业务系统之间“同物异码、同码异物”的情况。
(3) 建立数据交换标准。采用Web Service、XML作为数据传输的标准, 协助各业务部门建立数据传输与数据交换规范, 实现不同的业务数据之间的交互基础, 并且充分考虑扩展性。
(4) 建立信息系统的文档数据规范。各业务信息系统必须依据文档数据规范出具系统建设的过程文档, 对非结构化的数据要提供交互、检索的基础依据。
4.2 数据集成与交换平台的实现
4.2.1 数据集成与交换平台框架
数据集成与交换平台的框架结构如图1所示:
如图1所示, 各业务信息系统处于数据来源层 (数据提供层) , 基于信息系统的数据接入要求, 在适配层建立统一、规范的数据适配接口, 将各业务信息系统的数据抽取到数据交换层的临时数据存储区和操作数据存储区;操作数据存储区经过转换、清理, 成为正则的数据存放到数据仓库中, 此时已经将冗余的数据剔除。最后, 针对数据访问层, 即业务应用层的需求, 构建不同业务主题的数据集市, 将数据提供给各项业务, 实现数据的交换与共享。
4.2.2 数据适配接口的实现
数据适配接口主要采用Web Service的方式, 通过统一的数据规范, 以XML为载体, 实现多个业务系统之间的数据适配。在这个过程中, 特别强调交互数据格式的统一性和规范性, 数据来源层中的各业务系统在提供数据时, 必须遵循这个交互的规范。接口开发主要涉及XML、XSD、Web Service、SOAP、WSDL等关键技术。
XML即可扩展标记语言, 它使用一系列简单的标记描述数据, 是互联网环境中跨平台、依赖于内容的技术, 是一种处理结构化文档信息的有力工具。在高校数据集成与交换平台中应用XML技术, 在制定基于XML交换的规范和标准基础上, 可通过统一数据接口将各类数据源转化成XML格式, 以便与不同的信息系统实现数据交换。另外, 平台提供XML到XML的映射转换工具, 实现不同的业务系统之间的数据映射与格式转换。
XSD定义了一套标准数据类型, 并给出语言扩展该数据类型。Web Service平台即采用XSD作为其数据类型系统。当用某种语言, 例如C#来构造Web Service时, 为符合Web Service标准。使用的数据类型必须转换为XSD类型。
Web Service (Web服务) 是开放的基于因特网标准, 具有松散藕合、可重用、可编程访问、自适应和自描述等特质的Web组件。它具有模块化、良好描述、实现独立、可访问性和互操作性好等优势。Web服务由WSDL、SOAP和UDDI三个基本结构单元组成, 它们解决了Web服务的描述、通信和发布等基本问题, 是构建Web服务的核心与基础。Web服务协议栈进一步对Web服务的互操作、路由、安全和服务质量等进行了规范。
SOAP (简单对象访问协议) 基于XML和XSD, XML是SOAP数据编码方式。SOAP提供类似XML的能通过HTTP描绘参数和返回数值的方法, 可运行在任何传输协议上。
WSDL (Web Service描述语言) 能用机器阅读方式提供的正式描述文档, 用于描述Web Service及其函数、参数和返回值。因基于XML, 所以人可阅读。
4.2.3 数据存储结构
交换数据临时存储区是用来保证数据交换过程中安全隔离和临时存储的存储区。该存储区按业务系统创建, 负责临时存放从各业务系统采集上来的数据, 在数据采集策略上, 一般采用先删除后新增的更新方式, 不保存历史数据;若有特殊的要求时, 也可将历史数据做短期暂留。
操作型数据存储区存放集成的、可更新的、近实时的业务数据。主要用于交换数据临时存储区的明细数据整合后、导出数据文件进入数据交换区前的存储。操作型数据存储区按业务主题创建, 按查询需求保存一段时间内的数据, 可新增、删除、修改。
4.2.4 数据抽取 (ETL) 和转换
ETL是数据抽取 (Extract) 、转换 (Transform) 、清洗 (Cleansing) 、装载 (Load) 的过程, 是构建数据仓库的重要一环, 它直接通过内部机制把根据用户需求从数据源 (关系数据库、平面数据文件等) 抽取出的所需数据, 经过数据清洗, 最终按照预先定义好的数据模型, 将数据加载到目的数据库中去。数据集成与交换平台的开发工作可以直接面向这个数据库进行开发, 开发者可以很方便地利用该数据库的优越特性进行性能上的优化, 或者数据结构的调整, 从而不影响到底层的业务系统的数据。ETL还应具有丰富、灵活的数据转换策略, 能够把底层的数据库数据重新转变成更符合业务逻辑的数据。具备数据采集流程控制, 提供管理监控流程的措施, 使得数据从来源端到目的端的传输有条不紊地运行。
在数据采集过程中, 因ETL的实时性相对较弱, 需要使用ETL工具自身的一些采集机制定时到各数据源中获取数据, 以实现数据的同步。数据采集的过程中应能够分不同的时间颗粒度, 如按小时、分钟、日、月、年采集不同数据库的数据。在自行定制的ETL工具中也可具备更好的同步机制, 其“复制”的机制能够分时段同步指定范围的数据, 源端数据的改动能够快速地反映到目的数据库中。
数据转换机制方面, 实现映射的手段通常有三种。第一种是数据源直接映射, 它是指按照源数据库的原始结构采集进入数据集成与交换平台的数据库, 与源数据库的结构完全保持一致。此种手段是最简单的映射手段。第二种是数据源策略转换映射。这种方式完全改变源数据库的结构, 反映在数据集成与交换平台上的数据结构是全新的数据结构, 利用ETL工具的各种策略把源数据库的数据进行转化, 产生新数据体, 并存储进入数据库。第三种是上述两种方式的融合, 即:该映像除了包含与源数据库一致的结构外, 还加入了经过策略算法形成的新结构。例如:两表间的数据合并、表格式的转置等, 此种映射手段将随着数据集成应用的逐渐深入而变得日益广泛。尤其是在为数据集成与交换平台提供综合报表分析的时候, 采用这样的手段会越来越多。
根据ETL的特点可知, 对于海量的数据挖掘, ETL优势极为明显, 它可以为历史数据的分析工作提供更佳的底层数据基础。
4.2.5 数据清理
数据清理是ETL的一个重要内容, 该环节负责把冗余数据、不规范数据实现规范化, 保证数据的正确性、完整性、一致性、完备性、有效性、时效性和可获取性。
4.3 数据质量管理和评估
数据质量管理是采用科学的方法, 对数据集成与交换平台中存储数据的准确性进行判断, 对存在的数据质量问题进行核实, 并最终确认的过程。数据质量是数据集成应用的“生命线”, 质量差的数据即便可以共享, 也达不到预期目标, 所以在建立数据交换平台时, 必须时刻将数据质量摆在第一位。在数据交换过程中, 通过数据质量评估, 及时掌握各类数据的可靠程度或差错率的大小, 系统查找影响数据质量的因素, 并有针对性地采取措施, 持续提高数据质量。对于具体数据的质量检查模式可采用以下几种方法:
(1) 记录数检查法。通过比较记录条数, 对数据情况进行概括性验证, 主要是检查数据表的记录数是否为确定的数值或在确定的范围内。这个方法的适用范围是:对于数据表中按日期进行增量加载的数据, 每个加载周期递增的记录数为常数值或可以确定的范围时, 必须进行记录条数检验。
(2) 关键指标总量验证法。对于关键指标, 对比数据总量是否一致。指标总量主要是指具有相同业务含义, 从不同维度统计汇总逻辑的检查, 适用范围包括:同表内对同个字段从不同的维度进行统计, 存在汇总关系时, 必须进行总量检验。例如:某表的字段与其它表中的字段具有相同的业务含义, 从不同的维度统计, 存在汇总关系, 且两张表的数据不是经同一数据源加工得到。满足此条件时必须进行总量检验。
(3) 历史数据对比法。通过历史数据观察数据变化规律, 从而验证数据质量, 通常以同比发展速度进行判断。评估时应根据各种指标发展特点, 重点对同比发展速度增幅 (或降幅) 较大的数据进行审核。历史数据对比法包括同比和环比两种方式。历史数据对比法的适用范围是:不能进行记录数检查法、关键指标总量验证法, 且事实表的记录数小于1000万条时必须进行历史数据对比法。
(4) 值域判断法。确定一定时期内指标数据合理的变动区间, 对区间外的数据进行重点审核。其中数据的合理变动区间范围是直接根据业务经验来确定的。当事实表中的字段可以确定取值范围、同时可以判定不在此范围内的数据必定是错误的, 满足此条件必须进行值域判断法。
(5) 经验审核法。针对报表中指标间逻辑关系仅靠计算机程序审核无法确认、量化, 或有些审核虽设定数量界限, 但界限较宽不好判定的情况, 需要增加人工经验审核。适用范围:以上方法都不适用的情况下, 可以使用经验审核法, 在计算机自动校核的基础上, 由人工聚焦某些问题数据进行审核。
(6) 匹配判断法。与相关部门提供或发布的有关数据进行对比验证。适用范围:与有相关部门提供或发布的有关数据口径一致的, 可以使用匹配判断法。匹配判断后, 应当具备经验累积机制, 在确立某个数据口径为标准后, 自动遵循该项规则。
数据质量是一个长期性的问题, 要解决这个问题, 除了技术手段保障外, 还是必须从产生数据的源头抓起。根据经验, 70%的数据质量问题都是由用户输入产生的。因此, 在信息系统建设过程中要规范用户的使用方式, 保证数据的录入是按照定义的标准流程和方式进行维护;其次, 系统要严谨的对各数据项进行约束, 按照规范要求设计, 保证关联数据的一致性。
4.4 配套基础设施和管理制度
数据集成与交换平台的建设, 还可参考以下几个工作要点:
(1) 按照“科学规划, 合理布局”的原则有序建设高校网络。根据不同时期的信息化需求, 充分考虑业务量、数据量和应用增长情况, 配备适当的硬件设施, 为避免初期投入过大造成浪费, 可根据数据和业务的实际增长量, 分步持续扩充。在系统硬件设施规划方面, 要以保障系统的可用率和可靠性为出发点, 充分考虑关键设备的冗余, 避免单点故障带来的影响。
(2) 为高校各业务管理信息系统制定配套的系统运行维护管理规范, 主要包括网络、设备、数据、软件维护要求以及机房管理、运维质量管理要求等管理规范。通过IT运行维护流程的规范化管理, 不断提高系统运行保障能力, 保证高可用的平台环境。在日常管理的过程中, 还应编制配套的应急预案, 定期演练, 以应对突发的故障。
(3) 制定高校信息系统安全保障措施, 抵御外部对高校信息系统资源的非法的访问和使用, 保证高校信息系统的软、硬件和数据不因偶然或人为因素而遭受破坏、泄露、修改或复制, 确保信息安全。一是在管理层面, 明确高校信息化工作的职责与分工, 成立相应的领导工作机构, 制定信息系统安全管理制度, 利用行政管理防止安全事故的发生。二是在技术层面, 通过采取各种相应的技术手段, 包括防火墙技术、数据加密技术、身份认证技术、访问控制技术、漏洞检测、数据存储、数据备份和安全恢复等;保障网络环境、应用系统、通信环境的安全性。
(4) 针对高校数据交换和信息系统应用的特点, 配套建设数据集成与交换平台的运行管理工具, 例如监测平台数据通道的健康状况、平台运行日志的主动分析等功能, 增加平台运行的健壮性, 也为持续的运行维护带来便利, 节省人工成本。
5 结语
综上所述, 在建立高校信息化标准体系的基础上, 构建面向异构数据的高校数据集成与交换平台, 对数据质量进行管理与评估, 将从根本上解决数据质量差, 数据交互难的问题, 逐步实现高校数据资源共享与应用集成, 对高校自身发展及进一步推动教育信息化发挥积极作用。显而易见, 高校数据集成与交换平台建设是一项复杂、长期的系统工程, 而随着高校事业的不断发展及信息领域新技术的不断涌现, 平台建设势必也是一个动态、变化、发展的过程。本文提出的高校数据集成与交换平台建设方案, 需在实际运行和服务实践中不断完善升级, 最终形成一个高效、标准的, 能充分满足高校信息化工作需要的数据集成与交换平台。
参考文献
[1]黄松.基于诺兰模型的高校信息化建设趋势分析与展望[J].江汉大学学报:自然科学版, 2013, (1) :71-75.
[2]李幼军, 张广庆, 刘炳兴.高校信息化建设中信息标准的确立及应用[J].计算机时代, 2008, (10) :66-68.
[3]胡致涌.基于信息整合的数据中心平台的研究[J].制造业自动化, 2011, 33 (18) :69-71.