数据交换平台的实现（精选十篇）
数据交换平台的实现 篇1
关键词：先进的能量管理系统,数据交换平台,双机热备
1 引言
近年来,世界各主要电力系统发生的大规模停电事故[5,6]表明,电力系统的控制管理理论和技术的发展远远落后于电网本身规模的增长和复杂程度的增大。AEMS是建立在传统的EMS基础上,基于混成自动控制理论,对网内各种资源(包括发电机、电容、电抗器、变压器和各种配电设备等)进行统一的自动调控,实现电力系统多重目标趋优化控制的自动化系统。AEMS已于2007年4月在上海电网投入运行,并取得较好效果[1,2,3,4]。
与传统EMS系统和控制系统[7,8,9,10]相比,AEMS主要在如下几个方面有显著的不同:(a)传统EMS侧重于分析,而AEMS侧重于控制;(b)传统控制系统,如AVC,侧重于运用某些控制手段实现某个控制目标,AEMS侧重于综合利用所有控制手段实现系统多重目标趋优化运行;(c)AEMS以“事件驱动”为其内核,通过将不满意状态分类定义为事件,将难于求解的多目标趋优化问题转化为事件的处理和消除问题。
需要特别指出的是AEMS并不是对传统EMS的取代,而是在传统EMS基础上构建新一代的控制型EMS。因此AEMS需要从传统EMS系统及相关系统中获取一些信息,并利用传统EMS系统及相关系统已有的一些控制手段来完成一些控制。下面本文将探讨如何从已有EMS系统获得AEMS所需要的信息。
2 AEMS与EMS间的数据交换
AEMS与外部系统交互如图1所示。从图中,我们可以看出AEMS需要从EMS中获取状态估计、CIM模型等数据,同时需要把AGC基准值等数据传递给EMS,通过EMS下发这些指令。除了需要与EMS进行信息交换以外,AEMS还需要从SCADA中获取实时数据等数据,并通过SCADA发送变电站指令等控制指令。本文讨论的主要内容就是如何完成上述AEMS与EMS的数据交换。
AEMS以实现多目标趋优控制(即同时保证电网运行的安全、优质和经济运行)为目标,包括有自动电压控制、自动发电控制、自动低频振荡控制和自动安全稳定控制4个主要高级功能的子系统。因此,AEMS需从EMS系统中获取的数据类型可归纳为表1,简要说明如下:
电网静态模型数据。主要包括网络静态拓扑数据、设备(线路、变压器、发电机、负荷等)参数等。
电网实时采集数据。主要指SCADA系统中采集的实时电压、有功、无功等量测数据以及开关设备的开合状态数据。
辅助决策数据。这部分数据包括电厂母线的电压计划等计划数据、分区负荷统计等统计数据、AGC经济上下限等其他数据。辅助决策数据是电力系统实时控制系统计算指令时非常重要的参考数据。
分析计算结果。分析计算的结果是指状态估计、拓扑分析和潮流计算等电力系统基础计算的结果。
实时控制数据。主要指AGC机组的发电控制指令等控制指令。
3 数据交换平台的设计与实现
3.1 数据交换平台的框架
由于AEMS与EMS系统处于不同平台,这需要数据交换平台具有跨平台的功能。许多厂商EMS系统提供的数据交换接口需要采用特定编程语言编写,还需要完成注册授权等步骤且在EMS系统管理下才能进行数据交换,这使得AEMS直接从EMS获取数据变得不大现实。
为了克服上述困难,我们采用Client/Sever的架构来设计数据平台。数据平台的伺服端位于EMS侧,负责数据平台与EMS系统的数据交换;客户端位于AEMS侧,负责数据平台与AEMS的数据交换,客户端与伺服端通过TCP/IP的方式进行通讯。这样做的好处是:(a)通过TCP/IP实现跨平台,并保持客户端与伺服端的独立性;(b)对于不同厂商的EMS系统,位于AEMS侧客户端不需要重新编写,而只需针对特定的EMS系统编写特定的伺服端即可。数据平台的框架如图2所示。
3.2 伺服端与客户端的设计方案
数据交换平台的伺服端运行在EMS系统上,利用EMS系统提供的接口查询EMS系统的运行状态,当EMS系统发生双机切换时,伺服端程序跟随EMS系统进行双机切换。在监测EMS系统的运行状态的同时,伺服端程序还需要检测客户端程序的请求,根据操作码执行相应操作。由于伺服端程序需要同时监测两种消息,所以在设计伺服端程序时要么采用多线程阻塞的方式监听消息,要么采用轮询非阻塞的方式监听消息。采用多线程阻塞的方式监听消息时,线程之间需要进行通讯来交换数据;而监听EMS系统消息的线程在发生双机切换时,EMS系统可能会将该线程杀死,这样会造成程序的紊乱。因此采用该方式设计的程序不仅结构复杂,而且可靠性低。基于上述分析,我们采用轮询式非阻塞的方式来设计服务端的程序,程序流程图如图3所示。采用该方式设计的伺服端程序不仅具有良好的效率,而且程序结构简洁,可靠性高。
数据交换平台的客户端作为AEMS系统的一个模块,运行在AEMS系统侧。程序流程如图4所示。
3.3 不同类型数据的传输
从表1我们可以看出,EMS和AEMS之间需要交换的数据类型很多。不同数据对数据平台的要求不同,具体表现为数据通道不同,数据采样周期不同等。为了解决这些矛盾,保证数据传输的可靠性,并提高数据传输性能。对不同的数据,我们采用了不同的传输方式。对于离线计划数据、CIM模型等传输量大、更新周期较长的数据,通过采用文件形式并通过FTP方式来进行传输;对于实时采集数据和控制命令等传输量小、更新周期较短的数据,采用TCP/IP的方式来进行传输。
为了保证数据传输的可靠性,数据交换平台对每次数据交换,都会判断数据交换是否成功。具体做法是位于EMS侧的数据平台的伺服端,对数据平台每次数据交换请求,都会返回一个该次数据交换的操作结果,如实时量测数据是否成功获得,控制信号是否成功发送等。
由于不同数据对数据平台的要求不同,为此我们设计了一套灵活的通讯规约。这个规约的关键是在交换数据之前加了一个操作码共同组成传输数据,通过解析这个操作码来确定对数据的处理方式。为了确定数据的来源与更新时刻,我们在交换数据的头部加上YYYY-MM-DD-HH-MI-SS的时间格式来标识数据更新的时间,用POINT-NUMBER和POINT-TYPE两个参数来定位每条数据的数据源。基于上述考虑,我们设计数据包的格式如图5所示。
3.4 控制信号的下发
控制信号下发,是数据交换平台的重要功能。在上海系统中,原有SCADA系统仅支持变电站AVC指令和AGC指令下发,而不支持电厂AVC指令下发。为充分利用已有投资,AEMS利用原有SCADA系统下发AGC指令和变电站AVC指令,电厂AVC指令则通过AEMS中新开发的前置系统下发(如图1所示)。
作为控制型EMS,控制信号传输的可靠性,是AEMS数据交换平台所需考虑的最为重要问题。
为了保证控制信号传输的可靠性,数据交换平台会首先对发送控制信号的合理性适当首检测。例如,在发送AGC基准值信号时,数据平台会检测EMS系统的AGC开关是否打开、该台机组的AGC开关是否打开、指令值是否合理(是否超过该机组AGC的上下限)等。只有通过这些检测, AGC基准值信号才会被发送给SCADA系统,否则就会发送不成功。
在成功发送控制指令后,数据交换平台还会查询SCADA系统是否正确接收该控制指令以及指令执行的情况。对于通过SCADA下发的指令,数据交换平台在成功写入指令后,会再读回写入以确认指令写入成功和一致;而对于电厂机组的电压AVC指令,数据交换平台在成功写入指令后,会检查指令返回值以确认指令写入成功和一致。在发送控制指令失败后,数据交换平台会重新发送一次控制指令,如果再次失败则不再重发。每次AEMS成功发送控制指令后,该指令都会被存入数据库中,供历史查询与分析。
4 AEMS与EMS数据交换的难点
4.1 双机双网问题的处理
为了实现热备用保持系统一直在线,EMS系统大多在双机双网的环境运行。在EMS系统发生双机双网切换时,AEMS需要保持与EMS之间数据交换通畅。为了解决上述难题,在设计数据交换平台时,我们将平台的伺服端运行在EMS系统侧,并跟随EMS系统进行热备用。因此,伺服端对应的IP地址有四个。同时,我们约定伺服端只在主机上提供服务,不在备机上提供服务。因此,位于AEMS系统侧的客户端通过轮询这四个可能提供服务的IP地址,判断IP地址的变化得到EMS系统的主备状态。这样通过伺服端和客户端的分离,数据交换平台就可以屏蔽EMS系统双机双网切换的影响。
此外,在EMS系统发生双机双网切换时,为保证下发的控制指令的可靠性与一致性,数据交换平台会将已发送的控制指令再次发送给切换后的EMS系统,以防出现漏发和不一致的情况。由于控制指令给的是调控目标值,控制指令的重复发送不会给系统带来负面影响。
4.2 电网结构发生变化后的处理
当电网结构发生变化后,例如增加线路或变电站后,拓扑、参数、量测表也随之变化。这时,调度中心的人员通过EMS侧一个小程序,调用EMS厂家提供程序自动生成相应CIM文件,置于指定位置并自动通知数据交换平台。数据交换平台中相关程序会自动读入并解析CIM文件,进而对AEMS数据库系统做相应的更新。CIM模型之所以采用半自动方式更新,是因为在实际运行中,调度中心的人员会对CIM模型进行维护,在维护过程中会有许多临时的版本,如果采用自动的方式更新CIM模型,就可能会将一些不完整甚至错误CIM模型导入。
4.3 传输性能优化
在实时采集数据中,电网量测数据采集周期短,数据量大,更新的数据源很少发生变化。基于这种数据的特点,为了优化传输性能,我们在EMS系统的本地放置一个标识这种数据的文本文件。每次需要更新电网量测数据,通过解析该文件来确定需要更新的数据。当这种数据的数据源发生变化,如CIM模型发生改变,增加了量测数据,我们通过FTP的方式更新上述的文本文件即可。
同时,对于相邻的两个量测断面,数据交换平台会对需要传输的数据进行比较,只发送有变化的数据。在双网的环境下,数据交换平台共享同一数据库,每次数据交换只需读取一次和存储一次。这些做法,节省了网络传输带宽,优化了数据交换平台的性能。
5 运行效果
最后我们给出该系统在实验室的测试结果。测试服务器的配置为:CPU是 Pentium(R) 4,主频为3.00GHz,内存容量为1GB,客户端与伺服端在百兆局域网中通过TCP/IP交换数据。对于5947个量测点数据,一次数据交换所用时间仅为0.094秒。因此这套平台的效率还是令人满意的。
AEMS的数据交换平台于2007年4月起在上海电网投入试运行,每5秒钟更新一次电网量测数据,每5分钟更新一次状态估计数据。到目前为止,历经多次双网切换和EMS系统的双机切换,该平台依然保持连续运行,表现出良好的稳定性与可靠性。
参考文献
[1]卢强,何光宇,梅生伟,等(Lu Qiang,He Guangyu,MeiShengwei,et al.).AEMS及其在上海电网试运行(Advanced EMS and its trial operation in Shanghai powergrid)[J].中国科学E辑(Science in China Series E),2008,38(3):476-480.
[2]阮前途,何光宇,柳明,等(Ruan Qiantu,He Guangyu,Liu Ming,et al.).AEMS系统及其在上海电网应用(Advanced EMS and its application to Shanghai power grid)[J].电力系统自动化(Automation of Elec.PowerSystems),2007,31(14):17-24.
[3]孙英云,何光宇,梅生伟(Sun Yingyun,He Guangyu,MeiShengwei).基于Filter集合的内点最优潮流新算法(Anew optimal power flow algorithm based on filter set interiorpoint method)[J].电工电能新技术(Adv.Tech.ofElec.Eng.&Energy),2007,26(2):29-33.
[4]卢强(Lu Qiang).数字电力系统(Digital power system)[J].电力系统自动化(Automation of Elec.PowerSystems),2000,24(9):1-4.
[5]何大愚(He Dayu).对于美国西部电力系统1996年7月2日大停电事故的初步认识(A preliminaryunderstanding of WSCC disturbance and separation on July 2,1996 in the United States)[J].电网技术(Power SystemTech.),1996,20(9):35-39.
[6]匡洪海(Kuang Honghai).基于GE Smallworld GIS的停电分析系统研究(Research of GE small world GIS basedoutage analysis system)[J].电工电能新技术(Adv.Tech.of Elec.Eng.&Energy),2006,25(4):71-75.
[7]董海鹰,樊波,薛钧义(Dong Haiying,Fan Bo,XueJunyi).基于模糊专家推理的500kV变电站自动调压控制方法研究(Study of automatic voltage control approachbased on fuzzy-expert inference for 500kV substations)[J].电工电能新技术(Adv.Tech.of Elec.Eng.&Energy),2003,22(4):28-31.
[8]于尔铿,周京阳,刘广一(Yu Erkeng,Zhou Jingyang,LiuGuangyi).能量管理系统(EMS)的技术发展(Technicalhistory of energy management system)[J].中国电力(Elec.Power),1997,30(8):3-5.
[9]傅书(Fu Shuti).IEEE PES 2005年会控制中心与EMS部分综述(Summary and comments on IEEE PES 2005general meeting:Electricity market and EMS part)[J].电网技术(Power System Tech.),2006,30(16):11-14.
政务数据交换平台及算法实现 篇2
关键词：数据交换；SOA；算法
中图分类号：TP393.09文献标识码：A文章编号：1007-9599 (2011) 03-0000-01
Government Data Exchange Platform and Algorithm Implementation
Xu Guibing
(Nanchang Institute of Technology,Nanchang330000,China)
Abstract:The Government Data Exchange Platform is a platform for e-government support,through the platform integration of government information resources,improve government services capacity and regulatory standards.SOA architecture based on performance and efficient data exchange platform,information security and platform stability and reliability.
Keywords:Data exchange;SOA;Algorithm
随着电子政务建设的深入，政府各部门协同工作要求越来越高，因此不论是部门的信息化系统，还是一些全局性的信息化系统，都提出了在纵向政府部门或在横向政府部门之间实现数据交换和共享的要求，通过信息资源的整合促进政府服务能力和监管水平的提高。
一、数据交换平台实现
政务数据交换平台是政府电子政务系统间数据交换的“立交桥”，是连接各政府部门电子政务系统的公共基础平台。政务数据交换平台应由系统软硬件、安全体系、交换中间件、平台管理系统和交换前置系统等组成。数据交换平台应包括数据交换服务、数据转换服务、用户管理和系统管理等功能（如图1）。
图1 数据交换平台结构
数据交换服务能够实现不同电子政务系统前置交换数据库之间安全、可靠、稳定、高效的信息交换传输，能够配置和管理各种符合业务需求的信息交换流程。从运行结构来看，数据交换服务包括以下内容：
系统的接入：实现与各部门业务系统连接的功能，将交换信息传入政务系统的前置交换数据库，并接收由前置数据库反馈的处理结果。
数据的传输：数据传输的流程是可以配置和管理的。利用数据交换网络，实现不同部门不同电子政务系统与中心交换服务器间可靠、稳定、安全的数据传输。
信息流管理和制定：采用图形化方式对交换的信息流进行定制和管理。能动态的制定、管理和监控根据业务流而形成的信息流。
作为电子政务应用中的基础平台，数据交换服务在性能上应满足如下要求：
（一）系统接入的灵活性。作为电子政务应用系统的基础设施，政务数据交换平台应提供灵活的接入方式：对数据交换实时性要求较高、接入条件成熟的部门，政务数据交换平台采用前置系统为其提供应用系统接入，通过放置于用户单位的前置机，实现数据交换平台与用户应用系统之间相互连接；政务数据交换平台还建立数据上传网站，为接入条件不够成熟的部门提供格式化数据文件的上传服务，将数据文件上传至网站后，再由网站服务器上配置的前置系统将数据发送到政务数据交换平台，政务数据交换平台根据业务流程对数据进行相应处理后将数据发送到其他相关部门前置系统中。格式化数据文件支持XML、XLS、文本文件等文件格式。
（二）数据传输的稳定性、可靠性。能够确保不重传、不漏传，支持断点续传，支持2GB以上的大文件传输，对于大文件可以实现文件分割传送，并且在异常情况下有相应的补救措施。平台能够满足较大规模数据传输要求。实现在网络发生故障、系统产生异常或发生崩溃的情况下实现数据交换“不丢、不错、不重”。
（三）交换模式的多样性。交换模式支持消息触发主动发送、请求/应答、订阅/发布三种方式。支持数据的群发、群收，支持数据的异步或同步发送、接受。数据交换既可以由人工触发，也可以按照指定的流程自动完成。
（四）数据交换的可管理性。数据交换平台应具备数据的交换管理功能，提供图形化便捷的交换监控和配置工具，对交换任务能够按优先级顺序进行处理；提供图形化的数据交换流程设计工具，支撑信息交换项目快速开发和部署。政务数据交换平台支持远程配置和部署。
政务数据交换平台应提供远程监控的功能。通过可视化图形界面完成对交换流程的全面监控。监控功能包括对交换平台的总体监控、交换节点监控、前置适配器监控、节点交换情况统计、交换情况统计、交换过程监控等。
政务数据交换平台将用户业务系统划分为群组进行管理，群组的管理权限可授权给业务系统的管理部门。根据用户业务系统的实际需要，提供組内的交换监控功能、界面和报表的定制，以完全达到用户的工作需求。
（五）数据交换的标准性。支持在TCP/IP基础上运行的常用的报文传送协议，例如：FTP、OFTP、MQService、ASYNC、HTTP、HTTPS、E-mail（SMTP/POP3）等。符合国家政务信息资源交换体系标准规定的消息基础协议。
（六）数据交换的安全性。采用加密和用户身份验证技术（SSL，CA认证），保证信息传输过程中信息传递的安全性和用户操作的不可否认性。
二、算法
以XML基准格式数据流向关系数据库转换算法就是遍历XML文档的所有元素，并存储它们的信息的过程。XML元素的嵌套性质决定了它的遍历必须采用先根遍历，算法的形式化描述如下：
设T是一棵以r为根的树，V1，V2，…，Vn是r的儿子。这里，k>=0，T1，T2，…，Tk分别是以V1，V2，…，Vk为根的子树。
1.获取根元素r的信息并存入xelement表中，获取根元素r的属性信息并存入xattribute表中。
2.遍历根为r的每一个子树T1，T2，…，Tk（按从左而右的顺序）。
在调用该算法之前，必须获取XML文档的文件名以及生成一个id，并把它们存入表xdocument中，该算法是一个递归算法。
采用SOA方式设计的政务数据交换平台，系统成熟可靠，能充分应对异构信息系统之间数据交换，提高各部门信息资源的共享和交流，从而提升政府各部门协同工作能力和工作水平，更有效地为社会公众服务。
参考文献：
[1]王银杰,宋顺林.电子政务数据交换平台的技术与架构.计算机应用,2004,24
数据交换平台的实现 篇3
在三网融合的大背景下, 构建全台业务网络互联互通一体化系统数字电视平台也是发展的必然, 它可以有效地整合电视资源, 对提高业务效率, 提高节目质量、强化管理有着重要的作用。全台网从根本上改变了以往传统的运作模式, 节目以文件传递取代了磁带, 最大限度实现信息流通、跨平台跨频道资源共享和高效管理, 并为运作、管理、应用提供了先进完善的技术手段, 使节目的业务处理更加高效率、高质量。全台业务网络互联互通一体化系统一般由以下几个网络板块组成:制作网、录音网、收录网、播出网和媒资网。
全台网的互联互通主要包括:制作网与媒资网的互联互通、收录网与制作网的互联互通、录音网与制作网的互联互通、制作网与播出网、媒资网与播出网的互联互通。
全台网的建立, 为电视台的业务运营提高了效率的同时, 也带来了安全隐患, 因为全台网也是标准网络, 也存在网络安全问题。最典型的就是病毒的感染。一旦某个网络节点感染了病毒, 就有可能使病毒在网络内部迅速蔓延, 并通过网络边界, 传播到与之互联的网络, 继而扩散到全台网, 那样后果将会非常严重!
多数基于全台网设计的电视台在与外网交换数据时, 采用的是安全隔离网闸的技术。
安全隔离网闸, 又名“网闸”、“物理隔离网闸”, 用以实现不同安全级别网络之间的安全隔离, 并提供适度可控的数据交换的软硬件系统。安全数据交换单元不同时与内外网处理单元连接, 采用安全隔离技术, 创建一个内、外网物理断开的环境。通用的网闸模型设计一般分三个基本部分。
1. 内网处理单元
内网处理单元包括内网接口单元与内网数据缓冲区。接口部分负责与内网的连接, 并终止内网用户的网络连接, 对数据进行病毒检测、防火墙、入侵防护等安全检测后剥离出“纯数据”, 作好交换的准备, 也完成来自内网对用户身份的确认, 确保数据的安全通道;数据缓冲区是存放并调度剥离后的数据, 负责与隔离交换单元的数据交换。
2. 外网处理单元
外网处理单元与内网处理单元功能相同, 但处理的是外网连接。
3. 隔离与交换控制单元 (隔离硬件)
隔离与交换控制单元 (隔离硬件) 是网闸隔离控制的摆渡控制, 控制交换通道的开启与关闭。控制单元中包含一个数据交换区, 就是数据交换中的摆渡船。对交换通道的控制的方式目前有两种技术, 摆渡开关与通道控制。
z摆渡开关是电子倒换开关, 让数据交换区与内外网在任意时刻的不同时连接, 形成空间间隔GAP, 实现物理隔离;
z通道方式是在内外网之间改变通讯模式, 中断了内外网的直接连接, 采用私密的通讯手段形成内外网的物理隔离。该单元中有一个数据交换区, 作为交换数据的中转。
在内外网处理单元中, 接口处理与数据缓冲之间的通道, 称内部通道1, 缓冲区与交换区之间的通道, 称内部通道2。对内部通道的开关控制, 就可以形成内外网的隔离。
采用“中间数据交换区”摆渡数据, 称为三区模型;摆渡时, 交换区的总线分别与内、外网缓冲区连接, 也就是内部通道2的控制, 完成数据交换。
取消数据交换区, 分别交互控制内部通道1与内部通道2, 称为二区模型。二区模型的数据摆渡分两次:先是连接内、外网数据缓冲区的内部通道2断开, 内部通道1连接, 内外网接口单元将要交换的数据接收过来, 存在各自的缓冲区中, 完成一次摆渡。然后内部通道1断开, 内部通道2连接, 内外网的数据缓冲区与各自的接口单元断开后, 两个缓冲区连接, 分别把要交换的数据交换到对方的缓冲区中, 完成数据的二次摆渡。
通过以上传统网闸原理的简单描述, 我们知道其存在以下缺点:
z由于采用专用硬件和相应的系统, 网闸的价格很高;
z只能针对已知的病毒进行防范, 存在和杀毒软件一样的滞后性;
z操作使用不方便, 交换数据需使用专用软件, 而且只能在安装有客户端的电脑上交换数据;
z安全管理人员需定期更新网闸中的安全策略。
二焦作广电局安全交换平台的设计
焦作广电局从搬入新广电大厦后这两年, 在使用外来IT素材方面一直采用传统手工摆渡的方式:记者将需要导入的素材用U盘拷贝给技术人员, 技术人员在电脑上杀毒后拷贝到专用移动硬盘里, 再对专用移动硬盘杀毒后拷贝到制作网内。这种方式效率低下, 而且安全性也不是很好。2010年下半年, 随着焦作广电局自办节目对外来素材使用的增加, 自动化的网络安全交换数据平台的建设已迫在眉睫。
2010年9月, 焦作广电局设立了项目小组, 通过对多家公司的网络安全产品进行比较, 并联合一些院校的安全专家进行论证, 在10月份确定了自主研发的思路, 并制定了该平台的设计目标:
z针对4种常见素材进行深度安全分析, 通过检测的安全数据才能进入摆渡存储区;
z摆渡存储区与内、外网之间没有任何传输协议, 实现真正意义上的物理隔离, 安全级别高于通用网闸;
z任何一台办公室电脑不需要安装专用软件即能上传素材, 实现桌面到全台网的安全连通, 方便性高于通用网闸;
z内、外网服务器不需改变使用的操作系统。
针对制定的设计目标, 研发小组拿出了详细的设计日程表, 并于5月初完成了项目的设计, 目前该项目正在焦作广电局试运行, 在确保网络安全的前提下, 极大地提高了工作效率, 取得了较好的使用效果。
三核心技术
1. 文件深度检测分析
通过分析文件内部数据对文件进行深度检测, 避免了JPG病毒等利用系统漏洞的可能。
2. USB数据摆渡
通过USB摆渡的方式, 内、外网没有任何协议连接, 实现了真正的物理隔绝。
四效果
该项目实现了编辑、记者在自己办公电脑上就能将需要导入的素材进行提交, 配合相应的管理流程“自动”交换数据。在安全性上具备专业网闸的文件深度检测功能 (由于只需针对广电行业经常使用的文件格式深度检测, 在牺牲通用性的同时, 安全性比网闸的安全性能大大提升) , 并且不使用任何通用协议 (真正实现了物理隔绝) 。
五总结
全台网在保证安全的前提下与外网交换数据, 是电视台都面临的一个共同课题。在这方面, 焦作广电局做了从桌面到制作网物理隔绝数据交换平台开发和研究的有益尝试, 并取得了较好的效果, 可以给地市级电视台提供一些借鉴和参考。
摘要：介绍了全台网数据交换平台常用的安全隔离网闸技术, 对通用的网闸模型设计进行了说明, 介绍了焦作广电局安全交换平台的设计、核心技术、应用效果等。
网上办公数据交换事务的自动化实现 篇4
【关键词】网络办公 EMAIL自动化 VBA
在网络飞速普及的今天,各企事业单位、学校均在努力适应网上协同办公的新工作模式。怎样实现网络办公事务自动化,最大限度提高在网络数据交换事务上的工作效率,是企事业单位急需解决的问题。本文以OFFICE套件中EXCEL为例,以网络办公中常见的数据交换事务为切入点,试探讨一下利用VBA工具实现网络办公事务的自动化。
常见的网络数据交换分实时与非实时性,非实时大多是通过逐个分发电子邮件来实现的。在客户众多、发送频率较高的场合下,逐个分发将花费大量时间,极大地降低部门工作效率。而VBA是内部集成在OFFICE中用于实现程序自动化的开发工具,我们可以通过VBA来实现分发电子邮件的自动化与傻瓜化操作。全程只须轻轻一键,不需要登录邮箱,就能完成批量邮件自动发送和收集的问题,自动实现批量电子交换工作。VBA门坎低,上手快,在部门提高工作效率上应用极为普遍。具体实现代码如下:
Dim WB As Workbook
For I = 1 To Sheets("用户名工作表").[A65536].End(xlUp).Row
Fname = Environ("TEMP") & "" & Sheets("通讯录").Range("A" & I).Text
ThisWorkbook.Sheets("另存文件名").Copy
Set WB = ActiveWorkbook
WB.SaveAs Fname'生成副本
WB.Close False
Dim NameSpace$, Email As Object, mypass As String
NameSpace = "http://schemas.microsoft.com/cdo/configuration/"
Set Email = CreateObject("CDO.Message")
Email.AddAttachment Fname'指定副本為附件附件形式发送
With Email
.From = "发件邮箱"
.To = Sheets("通讯录").Range("B" & I).Text'对方邮箱
.Subject = "邮件主题"
.TextBody = "邮件正文"
With .Configuration.Fields
.Item(NameSpace & "smtpusessl") = 1
.Item(NameSpace & "sendusing") = 2
.Item(NameSpace & "smtpserver") = " SMTP服务器域名"
.Item(NameSpace & "smtpserverport") = " SMTP服务器端口"
.Item(NameSpace & "smtpauthenticate") = 1
.Item(NameSpace & "sendusername") = "发件邮箱"
.Item(NameSpace & "sendpassword") = "邮箱密码"
.Update
End With
Send
End With
If Err.Number = 0 Then MsgBox "发送完成" Else MsgBox "发送失败,请检查网络或配置"
Next
需要注意的是项目需要引用MICROSOFT CDO FOR WIN2000内置控件,发送邮箱应选用支持SMTP服务的ISP邮箱, 如QQ邮箱、GMAIL邮箱。同理,如果在分发的文档中设置回送按纽,当用户完成表格填写后,轻轻一点,就能把下发的文件从用户手中及时送回到收件邮箱中,邮件还可按收信规则归类到指定文件夹中。傻瓜式的处理,大大降低对用户的工作难度,加快了文档回收工作的进度。
文档回收到了邮箱指定文件夹中,如果一个个去点击存取,那也是相当费时间。我们可以使用VBA的OUTLOOK对象,自动从邮箱批量下载附件到本地指定文件夹,从而实现邮件附件批量下载的自动化。
Dim MyOutlook As New Outlook.Application
Set fs = CreateObject("Scripting.FileSystemObject")
Path = ThisWorkbook.Path & "本地下载目录"'设置下载目标文件夹
If Not fs.FolderExists(Path) Then fs.CreateFolder (Path)
Dim MyOutlook As New Outlook.Application, vItem As Object
Set myNameSpace = MyOutlook.GetNamespace("MAPI")
Set myFolder = myNameSpace.GetDefaultFolder(olFolderInbox)
Set fldFolder = myFolder.Folders("邮件归类文件夹")
For Each vItem In fldFolder.Items
For Each att In vItem.Attachments
att.SaveAsFile Path & att.Filename
Next
Next
至此,用户手中的数据已收集到了我们的桌面,我们完全可以使用EXCEL自带的合并计算功能进行汇总统计。结构较复杂的,我们还可以使用FileSearch 方法(OFFICE2003)或FSO对象(OFFICE2007),对目录下的统计文件进行遍历,自动逐一打开并提取既定位置数据,自动进行后续汇总处理,从而实现多文件数据收集的自动化任务。现以FileSearch示例如下:
With Application.FileSearch'查找
.LookIn = Path :.Filename = "*.xls"'查找所有的xls文件
.Execute msoSortByFileName '执行查找过程,并且将查询结果按文件名排序
For Each s In .FoundFiles'在每一个查找到的结果里
If s.Name <> ThisWorkbook.Name Then Set WB = Workbooks.Open(s)
'结合数据统计需要,对数据进行提取与收集
WB.Close False
Next
End With
网络数据交换第二种情况是实时性要求较高的事务。在远程协同办公的工作中,有时需要对各个用户终端进行数据同步实时更新。对于此,我们的解决方案是采用简易的客户端/服务器体系。使用VBA制作一个简单的OA客户端,里面集成了上传数据到FTP服务器,检测服务器数据版本更新及下载更新本地数据库的功能。这样用户就可以通过客户端,自主的进行数据的上传下载,从而实现24小时无人值守的数据同步的自动化任务。
实时上传代码如下:
hOpen = InternetOpen("eDIY FTP Client", 0, vbNullString, vbNullString, 0)
hConnection = InternetConnect(hOpen, "FTP域名", 0, "FTP用户名", "FTP密码", 1, 0, 0)
If hConnection = 0 Then
Call FtpRenameFile(hConnection, "FTP数据库文件名", "备份文件名")
hFile = FtpOpenFile(hConnection, "FTP数据库文件名", GENERIC_READ, &H1, 0)
Call InternetWriteFile(hFile, Data(0), 255, 0)
End If
以上实现方式要声明WIN32的wininet函数应用到的内置方法,以操作网络及支持FTP的网盘或服务器。检查版本并更新下载数据限于篇幅在此不再详述。
由上可见,在网络办公中,利用VBA,我们完全可以把一些常用的繁杂的网络数据交换工作,以模块化的方式制作成按纽,嵌入到员工熟悉OFFICE工作界面中去,只须点击一下,就可自动地完成批量网络操作,达到提高部门工作效率,实现轻松网络办公的目标。
作者简介:
智能数据交换平台的建设与应用 篇5
移动业务是目前各大运营商竞争的重要领域, 对于实时性的要求很高。随着中国电信计费结算中心与各省计费结算中心之间的纵向数据传输实时性越来越高, 数据种类越来越多, 原有基于固网业务的数据交换模式已经不能适应实际要求。主要体现在:集团和省份公司两级计费系统交换数据过程中频繁出现“文件丢失、延误而责任不清晰”的情况, 由于数据交换进程长期高负荷运转, 频发“僵死”现象, 而且原有的通信前置机缺乏精确的数据管理和核对机制, 难以满足全网移动运营和上市公司的内控要求。
因此有必要建立一个全新的智能数据交换平台, 从根本上解决分散建设的运营支持系统由来已久的问题。例如信息孤岛, 资源整合, 信息的加工和增值, 系统的平滑扩展与升级等。利用信息总线, 规范化接口, 统一数据模型, 将各个业务处理系统按照网元的方式进行互联互通, 从而达到“信息资源充分共享, 新增网元系统灵活接入”的目的。
1 建设智能数据交换平台的意义
1) 解决全国计费结算中心与各省计费结算中心通信前置机目前存在的数据漏传、多传、错传, 责任不清的顽症, 解决省间、省内各计费网元没有一套标准、规范的协议接口进行数据交换的现状;
2) 实现“应用与数据分离”的目标。周边系统的数据都可以利用平台集中交换和共享, 减轻了各个系统之间做接口的开销, 节省了宝贵的主机资源、存储资源、网络资源;
3) 引入物流处理模式, 采用一套有保障的机制来规范数据的发送和接收流程, 对数据自动进行传送和复制, 并且通过严格的数据稽核和校验机制, 保证了在平台中交换的数据的一致性、可靠性和安全性, 同时对异常数据也有相应的错误处理和拒收处理流程;
4) 实现核心系统网元到通信设备的接口互联, 不仅能够被动地从通信接收数据 (如话单采集) , 还能主动地发送各种指令, 核心系统网元和MSS/OSS (管理支撑系统/运营支撑系统) 的接口互联, 实现双向的数据传输。
2 智能数据交换平台的设计思想
智能数据交换平台的建设, 引入了以下3个重要的设计思想, 见图1。
2.1 仓储物流
仓储物流是指物资实体物理流动过程及其有关活动的总称。它不仅包括货物的搬运和运输, 还包括与此相联系的包装、装卸、储存保管、配送和流通加工等过程。智能数据交换平台充分借鉴这一思想, 将数据与信息的传输过程形象地予以展示, 其中比较重要的几个概念分别是货品、仓库、货架、数据广场、工作单、调度中心。
货品对应于业务支撑网的各个网元如计费系统、营业受理系统、综合结算系统产生的, 通过智能交换平台进行接收、配送, 最后提供给接收方的数据。
仓库对应于存储业务支撑网的各网元之间交互数据的专用场所, 仓库内包含一个或多个货架。
货架对应于智能交换平台中存放货物的物理位置, 负责数据在货架和数据广场之间的交换。
工作单分为取货单、入库单、出库单、配送单、退货单、换货单、清货单等基本的工作单。智能交换平台的任务是一个或多个工作单的有机结合。
数据广场对应于货物的集散地, 是数据取货、发货和数据处理的场所。
流程调度中心对应于智能交换平台的管理核心, 它控制了仓储物流概念下智能交换平台所有工作单和执行者进程的运行过程, 决定了整个系统的正确、稳定、效率等各个方面。
2.2 Petri网参考模型
Petri网是对离散并行系统的数学表示, 目前已经成为广泛应用的离散事件的建模工具。
智能数据交换平台作为电信运营支撑体系的重要组件, 需要承担电信运营商业务支撑网内所有实体间的接口数据交换工作, 大量的数据日吞吐量对智能数据交换平台可用性、稳定性、效率和自动化水平等主要性能指标均提出了极高的要求。系统所处环境还具有交换数据种类多、数据交换流程各不相同、处理任务到达时间与数量波动明显和处理实时性要求高等特点。因此, 异步多进程并发处理的软件架构体系成为必然的选择, 而系统行为的复杂性和不确定性也随之显著增加。
因为Petri网模型具有强大的描述离散事件系统的能力, 所以智能数据交换平台采用基于Petri网的系统模型作为分析工作流模型的理论基础。另外, 对Petri网模型的深入研究也对系统业务处理工作流中的并发、冲突、资源分配、业务调度机制分析等具有较大的参考价值。
智能数据交换平台在规划求解模型基础上建立了基于Petri网图形的模型。图2的Petri网模型仅包含了智能数据交换平台的一个业务流即文件类数据交换和两个共享资源访问 (冲突) 场景。虽然在模型中还存在更多的并行和冲突环节, 但简化后的图形已足以说明业务流内部和业务流之间的关系。
2.3 控制流与数据流分离
坚持数据流和控制流分离的原则, 将智能数据交换平台视同于一种核心网元, 并参考当前传输网和信令网分离的方式, 可提高数据传输过程的及时性和安全性, 并通过调度来均衡数据流量。
智能平台的数据流与控制流采用CTP (China transport protocol) 。CTP是一种应用于智能交换平台与远端文件服务器间的网络文件传输的协议。CTP客户端与CTP服务器端的接口传输层采用TCP/IP, 应用层使用socket通信方式实现。协议层采用CTP基础协议, 规范请求信令, 传输信令, 鉴权信令的交互, 分离控制和传输的过程。见图3。
整个CTP传输过程中, 服务器端和客户端之间的协议流程整体分为两类:传输控制流程和数据传输流程。客户端与服务器端之间先后建立了两个socket通信连接, 一个控制连接和一个数据传输连接。控制连接用作客户端与服务器端之间发送控制指令和响应;数据传输连接用作客户端与服务器端之间进行文件内容数据或目录文件列表数据的传输。
控制端口和传输端口均由服务器端监听。控制连接在CTP服务器端进程启动时就建立监听端口并一直监听客户端发起的连接请求。而传输端口则是需要进行数据传输时由客户端通过控制指令向服务器请求数据连接端口信息, 由服务器端进程临时开一个数据连接的监听端口, 在建立连接数据连接并传输完成后, 连接关闭。
3 智能数据交换平台建设内容
3.1 总体流程
作为应用网元间数据通信的枢纽, 需要满足不同网元间数据交换的要求, 同时交换的数据具有种类多、时效性、优先级、数据规模、传输方式等多种特性, 智能数据交换平台通过定义取货广场、配送广场、取货、入库、出库、配送等多种不同角色, 由调度中心的调度工作单在不同角色之间的信息传递和执行过程, 实现网元间数据交换的流程。总体流程如图4所示。
1) 两个调度核心:流程调度server和管控调度server。
流程调度server主要通过对交换策略的调度, 负责工作单的生成, 工作单的分配、工作进程的并发起停等, 完成数据交换工作。管控调度server通过对管控策略的调度, 定期完成清货、盘点、安保、备份等仓储管理工作。
2) 常驻进程和动态并发进程。
常驻进程包括工作单生成、文件名校验、排重、日志告警入库、共享内存参数、系统监控查询等后台服务工作进程。动态并发进程包括取货、入库、出库、配送、下架、盘点、安保、备份等根据数据传输要求满足传输性能而实时并发启动的工作进程。
3) 广场与货架。
收货广场和发货广场是对数据打包待处理的临时场所, 所有经智能平台转发的数据都在这两个广场上中转。货架是数据备份存放的场所。
3.2 内部架构
根据系统设计思想, 在体系结构上, 智能数据交换平台采用“三层结构”的设计是指应用系统在逻辑上均应按“数据服务层、业务处理层和接入层”三层结构考虑, 见图5。
将接入层独立出来使得系统的访问和使用更灵活方便, 易于实现个性化和客户化。将业务处理层和数据服务层分开可以屏蔽业务数据的存储、组织和访问的细节, 实现业务数据的充分共享, 从而实现横向组合。
3.2.1 接入层
接入层是系统与外部进行数据交换的层, 由接入逻辑构成。接入逻辑分为界面逻辑和接口服务。对于系统使用者, 提供多样化的界面逻辑, 实现对业务逻辑的共享;对于与系统相联的外部系统, 向业务层提供一组接口服务, 业务层通过接口服务完成与外部系统的数据交换。
3.2.2 业务处理层
业务处理层是系统业务处理的逻辑层, 为接入层提供业务服务, 实现业务逻辑的共享, 完成相应的业务功能。它通过对数据层服务子层原子服务的调用访问业务数据, 实现数据存取。
业务层又有两级逻辑组件:流动调度控制逻辑和数据交换流程。
流程调度控制逻辑主要实现智能数据交换平台数据交换过程中的工作单调度、工作进程调度、仓储管理策略调度、工作单生成等逻辑控制组件, 其功能的实现是由交换调度、管控调度、工作单生成、客户端等基本功能组件完成。
数据交换流程分为两类处理流程, 分别是文件类数据交换流程 (如取货组件、配送组件、出入库组件) 和管控流程。流程流程调度模块根据具体业务流程来定义功能模块的组合、并调度各功能模块完成业务流程处理。
3.2.3 数据服务层
数据服务层是对业务数据进行统一组织、集中管理的平台, 它为业务层提供规范、高效的数据服务, 实现业务数据的充分共享, 是整个智能数据交换平台一体化的基础。智能数据交换平台的数据管理对象主要分为货架、取货广场、配送广场、数据库参数、日志告警等。
由于各个业务组件和数据服务组件等是基于标准消息总线的, 而类似于CORBA (common object request broker architecture) 的消息总线是基于网络的, 因而各个组件可以被安装到不同的主机上, 实现分布处理, 从而大大增强了系统的可扩充性, 这对于数据量增长迅速的电信行业非常重要。整个系统采用软件总线方法, 实现各类构件的插拔, 采用 (结构) 技术支持数据的分布式处理。
3.3 外部接口
智能数据交换平台由中国电信全国中心智能数据交换平台和省级智能数据交换平台两级系统组成。系统提供了省级智能数据交换平台和本地计费账务系统的接口, 以及与其他电信运营商, 决策分析系统、财务系统、OA (办公自动化) 系统、网管系统、CRM (营业受理系统) 、ERP (企业资源计划) 系统之间的接口。省级智能数据交换平台与外部的边界在图6中描述。
4 传输方式与协议
4.1 传输方式
智能数据平台的数据传输方式包括端到端的数据传输方式和仓储物流方式。
1) 端到端方式:网元间数据交换由智能数据交换平台完成, 但只在智能数据交换平台临时中转数据, 货架只起备份功能, 不经过入库和出库操作。
2) 仓储物流方式:网元间数据交换由智能数据交换平台完成, 严格执行基本的数据交换流程, 如取货、入库、出库、配送等基本操作。
4.2 传输协议
智能数据交换平台同时支持CTP和FTP (file transfer protocol) 协议两种方式, 满足不同网元不同数据传输要求, 达到及时、效率最优化的目的。数据传输流程见图7。
5 应用效果
经过一段时间的实际应用, 智能交换平台不仅适合文件类型的数据端到端的传输, 满足定时传送数据文件需求, 满足手工命令执行需求, 也适合消息类型的数据端到端的传输, 支持消息路由转发, 加密解密, 满足同级业务网元之间的消息传输, 满足异地查询、异地缴费等跨省业务实现要求。只要遵循统一的通信协议和交互流程, 智能数据交换平台可以和其他网元可以进行无缝连接。通过配置方式实现文件类传输业务的智能数据交换平台, 可以满足计费系统、营业受理系统、OSS (运营支撑系统) 、MSS (管理支撑系统) 等系统间之间的数据交互。现有系统如能遵循智能交换协议, 也能融入到智能数据交换的高速通道中。
随着智能数据交换平台的上线, 横向打通省份支撑系统内部同一层级不同网元、核心网元与企业外部其他系统之间的信息交互, 纵向打通不同层级之间的信息交互, 不仅可以适用于本省范围内的文件类数据交换, 支持不同网元间各种不同形式接口数据的交换工作, 而且承担了集团和省份公司数据枢纽平台的作用。由于实现了集团、省和本地网两级核心网元、三级应用之间的接口互联, 从而也可以方便地实现异地受理、异地缴费、异地查询、经营分析等等特性, 体现出“一点服务全网、全网服务一点”的中国电信整体优势。
6 结束语
异地就医数据交换平台的研究与设计 篇6
异地就医结算一直以来是医疗保险管理的难题之一。究其原因一是各地医疗保险的政策差异性大;二是跨统筹地区管理服务协作机制的缺失;三是全国没有形成统一的信息系统和信息网络。解决这一难题的理想途径,就是逐步提升统筹层次,实行统一筹资标准、统一待遇标准、统一支付标准。然而要达到这目标,还有很多困难,也还需要很长的时间。这是因为:(1)我国实行中央、省(市)、县(区)三级财政体制,统筹层次受财政体制制约。据统计,至2007年底,全国共有统筹区域2200多个,其中县级统筹的约1900个[1]。实现省级统筹尚有很大困难,实现全国统筹,短时间更难以达到。(2)提升统筹层次后,地区差距问题将会显现,同一统筹区域内,相对贫穷地区的医疗保险费将转而支付给相对富裕地区,另外,由于医疗资源不平衡,还会产生享受医疗保险待遇的公平性问题。在政策层面难以统一、统筹层次难以在短时间内提高的情况下,一些省市结合实际,借助信息技术、通信网络,做了许多有益的探索,取得了一定进展。福建省通过建立全省医保业务专网,发行统一的“异地就医卡”,按“异地就医、参保地政策”模式,实现了全省范围内异地就医的实时结算[2]。长三角地区16个城市通过异地医疗保险经办机构委托代理、网络互联、持卡就医的方式,实现异地就医结算[3]。但这些措施和做法,尤其是应用系统建设、异地就医卡、网络构架等方面在大范围的区域内推广时有其局限性。一是需要建设业务专网,投资大,建设周期长,维护费用和维护技术要求高;二是使用统一的异地就医卡,需要更新现有IC卡及读卡设备,增加了管理成本和难度;三是需要建立全省或整个区域的统一的基本医疗保险药品目录、诊疗项目和医疗服务设施范围三个目录的编码。本文提出建立一个依托于互联网、不需要发行专用IC卡的异地就医数据交换平台,以解决异地就医结算难的问题。
1总体设计
1.1总体功能
(1) 基本目录代码参照表管理
实现医疗保险统筹地区基本医疗保险药品目录、诊疗项目和医疗服务设施范围三个目录代码的录入、更新、删除等信息管理维护,并建立统筹地区之间三个目录代码的一一对应关系。
(2) 定点医疗机构管理
实现各统筹地区的定点医疗机构(包括医院、药点)的增加、更新、删除等信息管理维护功能。
(3) 基本医疗目录代码转换
利用基本目录代码参照表,将就医信息(或结算信息)中的药品、诊疗与服务项目代码转换成参保地(或就医地)相对应的代码。
(4) 数据分发
将经代码转换后的就医信息、结算信息分发到参保地医保机构、就医地定点医疗机构。
(5) 结算数据管理
实现按定点医疗机构、参保地医保机构、就医地医保机构分类,并对相关结算数据进行分析、统计、汇总、清算和查询。
(6) 数据存储
存储异地就医人员基础信息、就医明细信息、医保机构与定点医疗机构之间的结算信息,为相应的统计、查询、决策提供基础数据。
1.2总体流程
平台总体流程分为异地就医人员登记、就医、费用结算三个部分10个步骤,如图2所示。
1) 异地就医人员登记
(1) 参保人员到参保地医保机构办理异地就医相关手续;
(2) 参保地医保机构将参保人员身份证号等信息录入到数据交换平台;
(3) 参保人员到就医地医保机构报到;
(4) 就医地医保机构在数据交换平台上确认。
2) 就医
(1) 参保人员凭身份证到就医地定点医疗机构就医;
(2) 就医地定点医疗机构将就医信息录入本地信息系统,转换成标准格式后上传至数据交换平台;
(3) 数据交换平台接收就医信息,校验是否为异地就医人员和是否在定点医疗机构就医,执行代码转换,将就医信息中就医地的目录代码转换成参保地相对应的代码,连同就医信息传至参保地医保机构。
3) 费用结算
(1) 参保地医保机构接收就医信息后将其转换为本地格式的数据,利用本地信息系统执行结算操作,再将结算信息转换成标准格式后上传至数据交换平台;
(2) 数据交换平台保存结算信息后,将结算信息中参保地医保机构的目录代码转换成就医地相对应的代码,然后传至就医地定点医疗机构;
(3) 就医地定点医疗机构接收结算信息后将其转换为本地数据格式,利用本地信息系统与异地就医人员进行费用结算。
1.3平台拓扑图
平台的拓扑如图3所示。平台依托于互联网,部署在签订异地结算协议的任一医保机构外网,通过隔离网闸或其他安全隔离设备与内网相连。平台的日常维护和管理由该医保机构负责。
2关键技术设计
2.1关键数据表
(1) 签订异地结算协议的医保机构信息表
包括:统筹地区编号、所属省市、开户银行、联系人等信息。其中统筹地区编号应能唯一识别该医保机构。
(2) 异地结算协议签订信息表
包括:统筹地区编号(甲),统筹地区编号(乙),甲乙双方签订协议时间、基本医疗保险目录代码对照表名称等信息。
(3) 基本医疗保险目录代码参照表
包括:统筹地区编号(甲)、药品或诊疗项目或服务设施编码、药品或诊疗项目或服务设施名称、启用时间、终止时间;统筹地区编号(乙)、药品或诊疗项目或服务设施编码、药品或诊疗项目或服务设施名称、启用时间、终止时间等信息。
(4) 定点医疗机构信息表
包括:所属省市、所属统筹地区编号、定点医疗机构编码、定点医疗机构名称、定点医疗机构等级、开户银行、户名、银行帐号等信息。
(5) 异地就医人员基础信息表
包括:所属统筹地区编号、单位编号、单位名称、个人编号、姓名、身份证号、性别、出生日期、参加工作日期、异地就医类别等信息。
(6) 异地就医费用明细表
包括:所属统筹地区编号、定点医疗机构编码、个人编号、身证份号、住院号(门诊号)、收费项目编码、处方日期、收费类别、收费项目名称、收费项目等级、单价、数量、金额等信息。
2.2异地就医人员的识别
各地目前普遍使用IC卡对医保参保人员身份进行识别。另外,IC卡还具有参保人员基本信息和医疗保险相关帐户信息的存储载体、支持脱机结算等功能。使用IC卡,必须具备两个条件:一是各医保机构和定点医疗机构的读卡设备均使用统一的读卡密钥。二是所有IC卡内的数据格式要统一。由此可见,使用统一的IC卡,在一个省内实现可能比较容易,在全国或大区域范围实现“一卡通”仍是个长远目标。平台使用“一号通”代替“一卡通”,即使用身份证代替IC卡对参保人员进行标识。以下是两者的功能比较:
(1) 从识别身份功能来说,身份证完全具备IC卡的功能。
(2) 从读卡设备来说,身份证阅读器比IC卡读卡器更具有通用性。
(3) 从作为医疗保险相关帐户信息的存储载体和支持脱机结算功能来说,身份证不具备这些功能,但只要保持网络畅通,相关信息就随时可以从后台数据库获取,并不影响系统的运行和结算。
综上分析,对于一个网络保持畅通的系统,使用身份证代替IC卡是可行的。
2.3基于XML技术的数据交换
目前,各地医保机构、定点医疗机构都运行着由不同开发商开发的各种各样的信息管理系统,这些系统在构架、操作系统和数据库上存在着异构性。要在这些系统之间实现数据交换,需要引入异构数据库访问的相关技术。这些技术主要有[4]:(1)利用现成数据转换工具。但这些工具并不是独立的软件产品,必须先运行该数据库产品的前端程序才能运行相应的数据转换工具,且多用手工方式进行转换。(2)中间数据库法。这种方法在实现过程中比较复杂,转换过程长。(3)中间件技术。事实证明,制定一定的数据交换标准是解决异构系统之间数据交换的根本途径[5]。XML作为一种与操作系统平台无关的可扩展性标记语言,便于表达各种类型的数据,非常适合于数据转换,而且这种转换是不以预先规定一组数据结构定义为前提。因而,在网络传输中通常使用XML作为中间数据格式,实现数据库间的数据交换[5]。在本文中,就医地医疗机构将就医信息转换成XML数据文件后上传至数据交换平台,数据交换平台调用医保机构字典查找对应的参保地,将就医信息中就医地的目录代码转换成参保地相对应的目录代码后,连同就医信息传至参保地医保机构,参保地医保机构再将XML数据文件转换成本地格式的数据文件,从而实现异构数据库间的数据交换和互访。
2.4应用安全设计
解决网络数据交换和通信安全问题的最佳途径是正确实施PKI系统[6]。PKI是在公开密钥理论和技术基础上发展起来的一种综合安全平台。在PKI系统中CA是核心,它负责产生、分配并管理PKI结构下的所有用户(包括应用程序)证书,把用户的公开密钥和其他信息捆绑在一起,在网上验证用户身份。CA通常由可信赖的第三方权威机构担当。设计本文的平台时,在人力资源和社会保障部尚未建立统一的CA中心之前,可由签订异地结算协议的各方商定,使用某一省区统一规划的CA认证中心。解决办法二是各统筹地区仍使用各省的CA认证中心,通过推动各省认证中心联入国家CA互联互通示范工程,实现统筹地区之间的交叉认证。
3结束语
数据交换平台依托于互联网,具有部署灵活、无需建立专网、无需发行专用IC卡等特点,可在不统一医保政策、不转移医保关系、不改变参保人所享受参保地医保待遇标准的前提下,按“异地就医,参保地政策结算”模式,实现异地就医结算。在具体实施时还需进一步完善和补充相关数据表的设计,提出对医保机构、定点医疗机构现有系统的改造方案。
参考文献
[1]中国人大网.我国基本医疗保险制度基本情况和主要问题.[EB/OL](2008-12-23)[2010-02-28].http://www.npc.gov.cn/npc/zt/2008-12/23/content_1463573.htm.
[2]王媛红.福建全省联网铺设异地就医坦途[N].中国劳动保障报,2007-05-24.
[3]李荣,陶维洲.长三角16城市有望实现医保“异地就医、联网结算”[EB/OL](2009-03-27)[2010-02-28].http://news.xin-huanet.com/newscenter/2009-03/27/content_11085111.htm.
[4]冯靖淋,何火娇.XML技术在异构数据库间信息交换中的作用[J].计算机与现代化,2008(2):15-20.
[5]朱夏,王茜.异构系统间数据交换模型的设计与实现[J].东南大学学报:自然科学版,2006,36(2):226-231.
数据交换平台的实现 篇7
2002年以来, 我国省市地方的电子政务建设取得了很大的进展, 为推动政府改革和廉政建设, 加强对企事业单位和公众的服务, 发挥了很大的作用。在当前总结“十一五”、规划“十二五”之际, 研讨地方电子政务建设的一个重要问题——如何建设地方电子政务数据中心和数据交换平台, 具有重要的理论意义和现实意义。
我国地方电子政务建设的基本问题
我国“十五”和“十一五”期间, 省市电子政务建设的基本内容, 是政府门户网站建设和一些业务应用系统的分散开发。由于缺乏统一的规划和统一的数据标准, 各种应用系统所形成的“信息孤岛”和“信息烟囱”比比皆是, 政府部门各自为战、独立建设、重复投资等问题时有发生。这些问题不解决, “十二五”期间, 要求政府创新与电子政务互相促进, 实现跨部门业务协同, 全面提升公共服务水平, 是办不到的。
“信息孤岛”产生的原因是多方面的, 但就认识根源来说, 是长期以来的一个普遍性的认识误区在作怪——总以为可以通过做数据接口来实现应用系统的集成;或者以种种数据接口的变种, 如数据库中间件、企业服务总线和数据交换平台等技术, 来实现多个“信息孤岛”的整合。例如, 许多地方在经济管理信息服务网建设方面, 为了实现工商、国税、地税和质监等政府部门的协同监管和服务所建立交换平台, 虽然投入巨大, 但如期效果并没达到。
信息工程方法论 (IEM) 已经彻底地从理论论证和实践检验上澄清了这一认识误区, 指出靠做数据接口不能实现多个孤立应用系统的集成;只有建立统一的数据标准, 面向业务主题建立共享的数据库, 实施数据环境的重构 (DER) , 才能解决信息资源整合与应用系统的集成问题。地方电子政务数据中心 (GDC) 建设的目的, 就是实施数据环境重构, 一体化地解决一个时期以来各种“信息孤岛”问题, 加强政务信息资源整合, 提升政务协同能力的重点工程。
数据中心与数据交换平台统一建设的可行性
事实上, 已经有些省市在进行电子政务数据中心建设的探索了, 取得了一些成果, 也出现了一些问题, 主要有:
◆某些地方立项目标任务定位不正确, 重叠立项“数据中心”和“数据交换平台”, 将两和本来是紧密联系、不可分割的统一建设任务, 划分为两个建设项目, 不仅重复投资浪费, 实际整合的效果还不好;
◆大部分停留在物理建设层面, 只注重解决数据集中存储、备份与安全等问题, 不注意解决数据标准化建设、信息资源整合与支持应用集成问题;
◆没有发挥业主方的主导作用, 将数据中心建设项目承包给系统集成商或软件开发商, 政府部门既不积极参与需求分析, 又不注重培养自己的数据管理人员;
◆数据中心和交换平台设备先进, 也购买安装一些数据抽取、加载和展现软件, 但业务实用数据贫乏, 开发商只给加载、调通少量数据, 项目验收后并不能投入实用。
为避免上述问题的发生, 电子政务建设的主管领导、信息中心负责人和骨干人员, 需要加强学习, 调整思路。首先要全面、正确把握电子政务数据中心和交换平台建设的总体任务。研究表明, 按数据中心建设所涵盖的业务范围, 可以有不同类型的数据中心:省市为经济管理信息服务的数据中心 (涵盖发改委、财政、工商、国税、地税、质监、统计等政府管理部门的业务) ;为社会保障管理信息服务的数据中心 (涵盖医疗保险、养老保险、失业保险、工商保险、生育保险、劳动就业等政府管理部门的业务) , 还是一些专业性信息服务的数据中心 (如省市财政数据中心、区域物流数据中心、电子口岸数据中心、文化教育数据中心等) 。我们的研究发现, 从基本构成上来说, 所有电子政务数据中心和交换平台建设, 都包括如下五项总体任务:
1、整合网络资源, 完善通信-计算机网络基础设施;
2、建立信息资源管理基础标准——数据元素标准、信息分类编码标准、用户视图标准、概念数据库标准和逻辑数据库标准;
3、重整数据结构, 建立共享的空间图形信息库、主题数据库和支持辅助决策的数据仓库;
4、建立信息资源元库和信息资源目录与交换体系, 科学有效管理各种业务数据和交换数据;
5、以数据中心支持核心业务系统的集成化开发和运行, 支持首长信息系统 (EIS) 的开发和运行。
某些地方重叠立项数据中心和数据交换平台建设的重要原因, 是受信息资源整合与应用系统集成问题的复杂性所困惑, 片面理解数据中心和数据交换平台建设任务, 不掌握数据中心共享数据库重建的关键技术, 对数据交换平台建设的“企业服务总线 (ESB) ”技术期望过高。按信息工程方法论 (IEM) “以数据为中心”的基本观点, 在数据中心建设的业务范围内, 已经堆积、并且正在堆积一些交错复杂的“系统”和冗余无序的“数据库”, 如果不从数据标准化和共享据库建设入手, 以“保护已有投资”为名, 完全靠数据交换平台来解决两类堆积问题, 不仅其复杂性会超过数据标准化和共享据库建设, 而且至今没有完全成功的先例。这里, 有一个简单的事实是ESB推行者所避而不谈的:你说将一些应用系统 (“信息孤岛”) 用前置机或适配器 (Adepter) 联到服务总线上, 就可实现这些应用系统的互联互通, 它们之间的数据就可以自动交换。可是, 适配器里的信息内容是什么?——设想王某人在工资系统里的编码是0134, 在社保系统里的编码是021045736, 在银行卡中的编码是130034, 这些数据不分别装载到三个系统的适配器里, 系统怎么能自动比对识别呢?而需要整合的业务范围内, 要建立多少个这类的数据对照表?谁来做这些数据对照表, 能跟得上业务的变化吗?
我们说, ESB技术还是可以用的, 数据交换平台还是需要的, 但不是实现信息资源整合与应用系统集成的主体技术;实现信息资源整合与应用系统集成的主体技术是数据标准化和共享据库建设。以某市社会保障信息系统的优化提升为例, 按照金保工程总体规划, 他们设立了生产区、交换区和决策区三个逻辑工作区, 现在面临三个区的升级改造。我们的研究认为, 生产区多个应用系统的升级改造, 要着力数据标准化建设, 构建共享的主题数据库, 使核心业务通过存取共享数据库, 实现最便捷、最经济、最高效的信息共享。交换区要逐渐将重点转向核心业务数据与外部的交换, 即通过建立信息资源目录与交换体系, 实现核心业务数据与外部 (工商、质监、银行等) 的数据交换;核心业务之间的数据交换, 如过去统筹与医保、失业保险与劳动就业等业务之间的数据交换, 要改为通过共享数据库的存取实现信息共享, 而不再是数据交换。这就是说, 核心业务之间不通过数据接口 (或变相的数据接口) 进行数据交换, 即消除核心业务的“信息孤岛”, 以支持社会保障业务协同和综合服务。决策区除了建立与生产区同步更新、只读的查询数据库外, 还要建立面向社会保障指标体系的数据集市, 改变面向报表的统计为面向指标的统计, 以支持广大企事业单位和公众的信息查询;建立由主题数据库升档的数据仓库, 而不是由应用数据库抽取形成的数据仓库, 以支持社保局、政府有关部门和领导的辅助决策工作。交换区建设在采用企业服务总线 (ESB) 技术时, 要根据左右、上下、内外数据流的分析, 分类指导信息资源目录与交换体系的建设, 科学规划当前、近期和远期的自动化数据交换的实施步骤。
数据中心与数据交换平台统一建设的可行性和必要性, 在于它们的建设目标和建设策略的统一性。数据中心建设的目标, 是通过对业务数据集中采集、集中存储、集中管理、集中使用, 一体化地解决信息资源整合与应用系统集成问题, 支持核心业务集中统一管理, 实现跨地区、跨部门业务协同和综合服务。数据交换平台建设目标, 主要是解决与上下、外部的数据自动交换;而核心业务之间的数据交换, 随着共享数据库的建设, 会逐渐减少, 因为核心业务将以对主题数据库存取, 取代以往的核心业务之间的数据交换。由此可见, 数据中心的共享数据库与数据交换平台两大机制建设是不可分割、紧密联系、相互依存的。两平台的统一建设, 要遵循“四统一原则”:统一规划——统一进行信息资源规划;统一标准——统一建立数据标准化体系;统一设计——统一搞好总体设计;统一实施——根据信息资源规划方案 (IRR) 和信息工程总体方案, 统一进行数据中心和交换平台的建设。
基于信息资源规划的总体设计
我国自1993年全面推进国民经济与社会信息化以来, 在电子政务和企业信息化建设过程中, 不断出现重复投资、重复开发、各自为战、条块分割、先出现“信息孤岛”后考虑整合的被动局面, 到2004年, 国信办领导和信息化专家一致认为, 信息化建设的主要问题已经不是网络构建、应用开发和软件选型问题, 而是首先搞好总体设计或顶层设计问题。
这时, 一些专家学者和研发机构开始引进介绍美国联邦政府业务框架 (FEA) 和企业架构 (EA) 等参考模型, 军内信息化专家王保存少将介绍了《美国如何进行军队信息化顶层设计》。到2007年, 国家出台《电子政务系统总体设计要求》 (GB/T21064-2007) , 使电子政务建设的总体设计, 有了可参考的指导意见。该意见指出, 电子政务总体设计的目标, 是确定系统所支撑的政务活动的范畴, 明确系统在其所属电子政务框架中的位置与作用, 给出满足系统需求的一种解决方案, 确保电子政务系统的无缝集成和预期目标的实现。一些总体设计的要素, 如需求分析、业务功能、信息资源和系统体系结构等, 可以作为总体设计的参考要素予以关注。
钱学森在《论系统工程》中对总体设计有精辟的论述:总体设计部由熟悉系统各方面专业知识的技术人员组成, 并由知识面比较宽广的专家负责领导。总体设计部设计的是系统的“总体”, 是系统的“总体方案”, 是实现整个系统的“技术途径”。总体设计部一般不承担具体部件的设计, 却是整个系统研制工作中必不可少的技术抓总单位。钱老指出了谁做总体设计、总体设计做什么和总体设计有什么用等关键问题。
我们以钱老的系统工程思想为指导, 学习运用信息工程方法论 (IEM) , 创新提出了基于信息资源规划总体设计的整套技术方法, 简单说就是“三大模型、五项标准和三大信息工程总体方案”。现以某市“金财工程”数据中心与数据交换平台建设基于信息资源规划的总设计为例, 简述要点如下:
1、全面梳理和优化业务流程, 建立应用系统功能模型。信息资源规划是以“职能域” (Function Area) 为基本单元进行数据流分析的, 职能域是指组织中的一些主要业务活动领域的抽象, 它不是当前机构部门的翻版, 但会覆盖当前的机构部门。该市财政职能域界定为:预算编制、国库支付、收入管理、政府采购和财务核算等十个职能域。对每一职能域分析识别业务过程 (Process) , 再对每一业务过程识别定义业务活动 (Activity) , 从而形成稳定的三层结构“职能域-业务过程-业务”表达的业务模型 (Business Model) 。然后, 通过对每一业务活动做计算机化可行性分析, 确定程序模块或组件 (Component) , 形成由三层结构“子系统-功能摸块-程序模块”表达的逻辑子系统功能模型 (Function Model) 。
2、调研并规范用户视图, 进行数据流定性和定量分析。用户视图 (User View) 是指最终用户对数据实体的看法, 是对单证、报表、帐册、屏幕表单等的综合。数据流就是用户视图的流动。采用软件支持工具, 对10个职能域约1000多个用户视图做规范化处理 (达到1-NF) ;基于用户视图, 通过数据流程图做数据流的定性分析, 进而做数据流的定量分析, 全面搞清楚各职能域之间, 以及与外部应用系统的数据流关系。
3、基于用户视图分组和数据流分析, 建立应用系统共享数据模型。数据建模是信息资源规划核心、也是难度最大的工作。借助于专业支持工具软件, 可建立由若干主题数据库 (35个) 、若干基本表 (140个) 所构成的数据模型, 采用简化E-R图来表达全域数据模型和各子系统数据模型。
4、基于数据存取分析, 建立应用系统体系结构模型 (C-U矩阵) 。体系结构模型是功能模型和数据模型的关联, 采用C-U矩阵来表达数据库的共建共用关系和程序模块研发顺序的控制机制, 是应用系统开发过程中确定数据分布的重要依据。每个子系统一个C-U矩阵, 反映子系统内程序模块与基本表的关联, 全域一个C-U矩阵, 反映各子系统与主题库的关联。
5、统一数据标准, 建立信息资源管理基础标准。该市财政核心业务所涉及到的数据标准规范, 在采用和借鉴现有的国际、国家、行业标准的同时, 还需要根据实际需要, 来建立统一的信息资源管理 (IRM) 基础标标准, 包括数据元素标准、信息分类编码标准、用户视图标准、概念数据库标准、逻辑数据库标准 (共5项) 。在此基础上, 建立与外部进行数据交换的信息资源目录与交换体系。
6、采用软件支持工具, 建立信息资源元库系统。信息资源规划工作是由多个小组、众多业务人员与IT人员密切合作完成的信息化工程, 就需要有能够集“理论指导、标准规范和操作方法”为一体的专业软件工具的支持。我们研发并具有自主知识产权的规划工具软件——信息资源规划工具IRP2000net与信息分类编码工具IRP3-icc, 能够对信息资源规划工作过程中的分析调研、建模和数据标准化过程和结果, 都统一保存在信息资源元库 (Information Resource Repository, IRR) 之中, IRR是后续应用系统开发工作所依据的核心资源。
以上就是基于信息资源规划总体设计的第一部分工作——信息资源规划的三大模型和五项数据标准, 而且由工具系统建立和存储, 即形成活化的计算机文档。在此基础上, 做基于信息资源规划总体设计的第二部分工作——
7、信息工程总体方案编写。通信-计算机网络工程总体方案、数据标准-数据中心工程总体方案和应用软件工程总体方案等三大信息工程总体方案, 将用来指导、控制和协调该市“金财工程”数据中心与数据交换平台有序成功的建设。
实践表明, 我们创新提出的电子政务总体设计方法论——基于信息资源规划总体设计, 不仅完全覆盖GB/T21064-2007的总体设计要素, 而且更为科学、简明和实用。
要在实践中推进两化融合
工业和信息化部副部长杨学山
2010年7月1日, 全国首个推进两化融合高级培训班 (第一期) 在上海开班。工业和信息化部副部长杨学山出席开班仪式并发表重要讲话。
要充分认识两化融合。第一, 推进两化融合是党中央国务院的重大战略决策。第二, 两化融合是历史发展的必然趋势。第三, 无论是从企业或国家竞争力的角度、从微观或宏观经济效率的角度, 还是从发展转型的角度, 两化融合的本质就是材料、能源、信息三种社会发展的基本资源综合、协调、高效利用和均衡优化, 中国应该加快创新步伐, 实现科学发展。第四, 推进两化融合是转变发展方式的重要抓手。两化融合在各个方面支撑发展方式的转变:两化融合促进战略性新兴产业发展, 在宏观和微观两个方面提升生产效率, 是节能、减排、降耗、治污的重要抓手, 是提升创新能力的重要基础, 是产品和产业升级的内在动力, 是产业布局调整的技术支撑。
要在实践中推进两化融合。首先, 在战略层面, 第一要提升经济运行整体效率:发展电子商务, 降低贸易成本;发展现代物流业, 降低物流成本;发展诚信体系, 降低交易成本;发展创新平台, 降低研发成本, 提升研发质量;加强预测预警, 引导平稳发展。第二要在三大产业结构调整、产业内结构变化、产业布局、生产技术选择方面着手, 构建现代产业体系, 转变经济发展方式。两化融合是构建现代产业体系的重要抓手, 在构建现代产业体系中发挥着重要作用。
其次, 在重点工作层面, 要大力发展企业信息化、行业信息化、区域信息化。
最后, 要高度重视创新与延续的关系, 两化融合在创新发展的同时, 要高度重视发展的延续性。传感网、物联网、泛在网、云计算、智慧地球等一系列新概念正在发展, 并影响着两化融合进程。但万变不离其宗, 不能就概念论概念, 要正确认识技术的发展, 正确认识技术发展与两化融合的关系, 要切实做到重本质、讲延续、求效果。
摘要：本报告在总结我国地方电子政务建设基本问题的基础上, 提出了地方电子政务数据中心与数据交换平台统一建设的目标、任务和策略, 论述了基于信息资源规划总体设计是其成功建设的基础保障。
关键词：电子政务,信息资源,数据中心,信息资源规划,总体设计
参考文献
[1]中共中央办公厅.关于加强信息资源开发利用工作的若干意见[S].2004.
[2]中国工程院“十二五”规划信息化专题组.我国“十二五”信息化发展的思路[M].2009.
[3]高复先.信息资源规划——信息化建设基础工程[M].北京:清华大学出版社, 2002.
供应链数据交换平台设计 篇8
在当今竞争环境下, 数据量呈现爆炸性增长, 从各种数据中获取正确可靠及时的数据, 可为企业提供高效的决策支持, 从而帮助企业在适当的时机做出正确的决定。因此, 对数据的正确组织和管理是一个组织有效运作所必需的。
为了适应当今时代对企业供应链信息化的新要求, 需要建立新型的供应链信息交换平台, 实现对业务的快速响应。而供应链平台的建设离不开产品图纸、计划以及质量等信息在不同企业的信息交互, 在这一交互过程中, 信息的准确性和时效性是确保相互协作的重要前提。
1 数据访问
数据库的诞生和发展给计算机信息管理带来了一场巨大的革命。随着数据库应用的扩展和深入, 其数量和规模越来越大, 对数据库的访问要求也越来越高。数据库访问技术提供了在各种不同的数据库系统中读取存储数据的方法。
数据库及其编程来源于不同的背景, 每种数据库管理系统都有一套自己的编程应用程序接口 (API) , 这就为数据库编程带来极大的局限性, 结构化查询语言 (SQL) 是标准化数据库编程接口的ISO标准[2]。数据库访问技术为各种数据库提供了统一的数据库编程接口, 简化了客户访问数据库的过程。当前的数据库访问技术[2]有ODBC、JDBC和ADO.NET三种。
2 数据总线
供应链平台中存在各种应用和各种数据存储需求, 但由于“信息孤岛”的存在, 阻碍了各应用之间的数据共享, 也阻碍了企业对数据管理和数据安全方面的需求。数据总线是各原始数据库对外提供的一种规则可控的数据连接存储服务。
基于数据总线技术的统一数据交换模式是一种松耦合的连接方式[3]。在这种模式下, 数据交换平台维护各个系统的数据接口, 所有应用或基础数据库不再通过数据库的直接互连进行数据数据交换, 而是通过这个数据接口统一协调信息资源, 实现数据共享。通过数据总线技术, 实现了原始数据库的集成, 提供了访问者权限的精细控制, 有效支持了跨平台、跨语言和跨空间的数据访问, 同时, 有效地隔离了对数据的直接操作, 保证了数据的安全性。数据总线的框架图如图1所示
数据总线可分为三个层次:服务宿主层、业务规则层和数据连接层。服务宿主层主要提供对外的查询和管理API。业务逻辑层提供业务逻辑的配置和管理, 并记录状态信息。数据连接层主要提供数据库的加载与卸载, 实现对数据库连接的控制。
3 数据交换平台设计
供应链协作平台需要支撑产品图纸、计划以及质量等信息在不同企业的信息交互, 在这一交互过程中, 信息的准确性和时效性是确保相互协作的重要前提。通过建立一个统一的数据交换平台, 简化规范供应链各流程对数据交换、数据共享和数据管理的操作, 提高业务的灵活性和扩展性, 保证信息的准确性和实效性。
3.1 数据交换平台体系结构
供应链数据交换平台采用SOA思想[1,4], 将功能模块和数据模块封装为服务, 屏蔽具体的技术和实现方式。服务之间的信息交互载体为XML[4]或JSON, 通过消息机制, 建立数据交换通道。整个数据交换平台由数据层、数据总线层、数据组件层、数据服务层、界面层和企业服务总线层构成, 系统体系结构如图2所示。
供应链管理平台的数据主要有存储管理数据库、计划管理数据库、质量管理数据库、订单管理数据库和访问控制数据库等组成。数据总线层为各应用模块访问数据的入口, 提供有异构数据格式到XML格式或JSON格式的双向转换, 解决异构数据的信息交互问题。数据组件层将交换平台的各个功能封装成不同的模块, 是整个交换平台的核心。数据服务层利用组件层的功能模块构建不同功能的服务。界面提供用户与系统的交互。企业服务总线提供服务的注册和查询。
3.2 数据总线层
数据交换平台数据总线层主要由五个模块组成, 分别是数据格式转换模块、数据封装模块、消息收发模块、访问控制模块、安全监控模块和日志记录模块。数据格式转换模块完成XML格式或JSON格式的数据标准化规范化。数据封装模块将标准规范的数据添加描述信息完成数据封装, 交给消息发送组件。消息收发模块调用数据交换中心的消息接收WEB服务, 实现数据的发送。访问控制模块实现对数据库中的数据的读写控制, 安全监控模块实施监控, 日志记录模块对整个数据总线发生过程进行记录。
3.3 数据组件层
数据交换平台的组件层主要包括消息模块、数据存储模块、数据传输模块、数据验证模块、服务注册和查询模块、企业服务总线和安全监控模块。消息模块主要处理数据交换平台结点和业务系统结点之间的互操作控制信息。通过统一规范的数据交换消息协议控制数据交换的整个过程。数据存储模块系统采用多种机制存储过程数据、源数据、目的数据等交换过程中需要访问的重要数据。数据传输模块主要处理数据交换中心结点和业务系统结点之间的数据传输问题。数据验证模块数据验证是为了保证其存储数据的安全性和一致性, 通过数据权限的验证限制, 系统可以控制细粒度的数据权限, 只允许相应权限的用户角色来访问。服务注册和查询模块提供了数据交换相关服务的注册和注销等管理功能, 允许代理发布和取消代理的数据交换服务, 为了便于维护, 该模块提供了服务服务查询功能。
3.4 其他层
数据访问层和组件层的模块和实现对表示层是透明的, 表示层主要提供面向用户的服务界面, 包括数据交换注册管理服务、数据导入服务和数据导出服务。
另外, 企业服务总线 (Enterprise Service Bus, ESB) 主要用于提供消息队列和缓存服务。接收、缓存、排队和分发各业务系统结点产生的异步消息及返回的数据。安全监控模块对系统在运行过程中的操作和出错信息进行处理和记录, 保证系统正常运行。服务层利用组件层的模块构建数据交换平台所需要的不同功能的服务。
4 总结
数据是企业最有价值的资产之一。在海量数据的仓库中利用数据挖掘技术析取有意义的信息, 可为企业管理者提供相关预测并提供相应的决策支持。该文介绍当前流行的数据库访问技术, 然后提供了一种数据总线技术的解决方案。它为异构化的数据库提供了统一的总线支持, 有效地解决了企业数据管理松散、数据共享、数据安全、系统整合、跨平台跨语言应用等各方面带来的数据库访问问题, 为企业的数据交互与维护提供了强有力地支持。最后提出了应用数据总线技术和SOA技术搭建供应链数据交换平台, 为企业内部数据资源的共享提供强有力的支持, 也为企业的数据挖掘和智能决策提供数据支持。
参考文献
[1]李晓东, 杨扬, 郭文彩等.基于企业服务总线的数据共享与交换平台[J].计算机工程, 2006, 32 (21) :217-219, 223.
[2]希凡.基于.NET框架的WEB数据库访问技术的研究与实现[D].武汉理工大学, 2006.
[3]龚岳松, 吕文斌, 李佼等.基于数据总线技术的水务数据交换管理平台的设计与实现[J].计算机应用与软件, 2012, (4) :97-100.
数据交换平台的实现 篇9
关键词:仿真支撑平台;客户机/服务器软件;测试 Data Management
中图分类号:TP391.9文献标识码:A文章编号:1007-9599 (2010) 03-0034-03
Simulation Supporting Platform Data Management
Design and Achievement
Liang Hongyu
(Chongqing Municipal School,Chongqing400042,China)
Abstract:According to characteristics&application of simulation supporting platform,we designed a platform based on the windwos distributed applications and support multi-purpose simulation platform support.
Simulation platform in addition to providing programming for simulation and compilation, task scheduling and management, and the number of management and other basic functions, it should with real-time control, database management and related real-time simulation database, shared memory area function.shared-memory area function.
Keywords:Simulation Supporting Platform;Client/server Software;Test Data Management
一、仿真支撑平台的总体架构
(一)仿真支撑环境的基本结构及实现方式
从仿真语言发展成一体化建模与仿真环境是一个大的跃进。一体化建模仿真环境是一类采用计算机支持建模仿真环境,它向用户提供了一个完全类似于对实际系统进行实验的框架。同时,它对仿真中涉及到的各种资源,如模型、算法、实验框架以及行为数据进行统一管理。另外,它还应具有多功能并行工作的能力。它的主要性能表现在:支持建模仿真全过程:一体化集成程度;方便的用户接口;开放性等。一体化仿真环境应具有四个相互独立的管理系统及一个实验运行系统:
1.模型库管理系统;
2.算法库管理系统;
3.实验管理系统;
4.数据管理系统;
5.实验运行系统:
四个管理系统通过一个中心数据库与实验运行系统实现集成。从软件工程的角度分析仿真环境,可认为仿真开发过程就是一类具体的软件开发过程,故软件工程的各种方法、技术和工具可应用于仿真模型及其支撑系统一仿真环境的开发过程中。一个理想的仿真环境是一个复杂的软件系统,由许多部分组成,通过开放的、模块化公共软件体系结构,设计和实现这些成员,构造仿真环境。在具体实施时将根据实际需要实现上述系统中的部分功能。根据一体化的构成,可以有以下几种实现方式:
1.不同功能软件通过一个软件,利用数据建模接口实现一体化,这是最初级的一体化方式;
2.以数据库为中心,实现仿真全过程不同阶段活动的数据共享,支持各类活动的集成,实现一体化;
3.开发仿真操作系统,由仿真操作系统实现对仿真关联资源的有效管理,并支持这些资源的匹配运行,实现整个仿真软件系统的高度一体化。一个仿真操作系统应具有对仿真关联资源(模型、参数集、实验框架、算法和实验结果等)进行描述、存储和管理的功能,支持模型在实验框架内的实验,并具有一个交互式的用户界面,它支持仿真研究全过程,有关仿真研究的工作都可以在该仿真操作系统支持下完成。
(二)仿真支撑平台的总体设计
1.仿真支撑平台的体系结构设计
根据一体化仿真环境的基本结构,结合仿真培训系统的特点,本实时仿真支撑软件采用构建一体化仿真环境的第二种方式进行实现,即以数据库为中心,实现仿真全过程不同阶段活动的数据共享,支持各类活动的集成,实现一体化。该系统主要由四个功能模块组成:数据管理模块、网络通信模块、模型管理模块、外部接口模块:每个功能模块都紧紧围绕着仿真数据库来设计实现。
(1)数据管理模块
数据管理模块是用来实现对仿真支撑平台各个数据库的统一调度、管理。据管理模块主要分为对以下几个数据库的管理:变量数据库、表和图库、模库、故障库。其中,变量数据库是系统运行的核心,通过平台提供的变量扫工具将数学模型中的变量扫描到变量数据库中,各种功能模块通过变量数据库中数据的存取及处理来完成其所要求的各种功能,是支撑软件的关键技术和主要部件;表和图库用来保存所有感兴趣的变量的信息和值,表可将感兴趣的100个变量以表格的形式进行实时输出监视,而图则用趋势图或直方图等可视化形式对变量进行监视,表和图库极大地丰富了变量监视的手段;数学模型是仿真活动的灵魂,模型库正是用来对各个数学模型进行分类管理的数据库;故障库是用来保存故障设置信息的数据库,对故障的保存为以后重设故障提供了极大的方便。
(2)模型管理模块
仿真是一种基于模型的活动,仿真模型必须通过模型调度程序的调度,才能表现出具体的行为特性。模型管理模块即围绕着模型的编写、编译、连接和运行展开的。首先,使用仿真支撑平台提供的建模工具,采用面向对象的方法用C++编写模型程序,仿真支撑平台支持模型的并行开发,即允许多个客户在各自的机器上编写子模型,完成后各个客户将各自的子模型保存在服务器上的某一共享目录中;模型编制完成后,操作人员在服务器上将刚才的共享目录指定为工作目录,通过支撑平台提供的编译窗口打开工作目录中的各个子模块,点击扫描变量按钮后,支撑平台利用指定的变量扫描规则将各个子模块中的变量扫描入库并建立变量与内存之间的映射关系;点击编译连接,支撑平台就可以用内嵌的程序模块组合规则将各个子模块组合成一个完整的模型源程序,这时就可以调用编译器对此模型源程序编译和连接,最终生成可执行程序;最后,编译链接完成后的模型可执行程序就可以被仿真运行在线控制系统实时调度。
(3)网络通信模块
网络通信模块用来负责仿真支撑平台的服务器和各个客户机之间实时数据和控制信号的传输。在仿真支撑平台整个系统的实时通信中,仿真主机作为服务器,监控机作为客户机,而且监控机可以有多台。服务器与客户机之间进行实时数据的通信是基于TCP胆网络协议的,使用流式的面向连接的网络套接字发送和接收实时数据和控制信号。服务器上模型程序的数据可能很大,且每个数据随时都可能会发生变化,为了保持服务器和所有客户机上数据的同步,一种最简单的办法就是服务器和客户机之间定期相互复制数据。这样,如果复制间隔较短时会使得网络的负荷非常繁重,甚至无法正确完成工作;而如果间隔过大,则无法在各计算机上实现数据的同步,而且由于每增加一个客户机都会导致服务器网卡负荷的增加,使得系统不能具备很好的扩展性,对仿真系统带来了很大的局限性。为了提高数据传输效率,减少不必要的资源浪费,我们对仿真支撑平台的网络通信在技术和思想上进行了专门的设计。考虑到服务器上数据某时刻并不是都在变化,我们专门开辟一个线程定时发送变化的数据,定时周期与仿真模型运算周期保持一致,这样能最大限度地使发送数据与模型运算同步。然后在每个客户机内存中都保存服务器上变量数据库的副本,当客户机收到变化的数据信息时就刷新各自的内存区,这时,各客户机就可以从自己的内存区中取得所需要的数据。这样有选择的发送数据,大大减少了网络通信量,提高了系统效率。
(4)外部接口模块
外部接口模块是仿真支撑平台提供给外部用户的一个开放的接口规范。它允许应用程序利用该接口库中的方法函数直接访问平台的变量数据库,这样用户就可以利用接口库中的接口函数对变量数据库中的数据进行取值、修改等操作。所有这些接口函数都被封装到动态连接库中,各种应用程序通过调用此动态连接库中的接口函数,就可以实现多个进程间数据的共享,又可以保证及时的响应速度。仿真支撑平台启动模型程序运行后,仿真支撑平台便建立了共享内存区,这时其它的应用程序就可以利用仿真支撑平台提供的外部接口函数,将外部接口对应的动态链接库导入内存中,再调用相应的接口函数建立应用程序与仿真支撑平台的共享内存区的映射关系,这样应用程序就可以通过相应的接口函数对仿真支撑平台的变量数据进行取值、修改等操作了。
(三)开发平台的选择
一个通用、高效的应用程序开发环境对于程序开发人员来说是至关重要的。当前,微软(Mcioros)tf公司的Windows在操作系统领域中独领风骚,其良好的性能和“EnbalingTechnology”的“平台”设计思想为第三方软件开发商提供了众多的增值机会,因此成为广大软件开发人员的首选开发平台。微软公司推出的全新产品Windows2000突破了Windows操作系统在应用领域的界限,将适用于PC领域应用的Windowsxg系列和适用于企业领域应用的WindowNsT合二为一,最终成为一个真正通用的应用平台。
二、仿真支撑平台的数据管理的思路与实现
(一)仿真数据库的组成
1.数据存储与管理技术的比较与选择。
数据库管理技术的发展经历了人工管理、文件系统和数据库系统3个阶段。
(1)人工管理。20世纪50年代以前,计算机主要用于科学计算。在硬件方面,外存只有纸带、卡片和磁带,没有磁盘等直接存取的存储设备:在软件方面,没有操作系统,没有管理数据的软件:数据处理方式是批处理。
(2)文件系统。20世纪50年代后期到60年代中期,这时硬件方面已有了磁盘、磁鼓等直接存取的存储设备;软件方面,操作系统中已经有了专门的数据管理软件,一般称为文件系统;数据处理方式上不仅有了批处理,而且能够联机实时处理。
(3)数据库系统。20世纪60年代后期,计算机应用规模越来越大,数据量急剧增长。这时硬件已有大容量硬盘,硬件价格下降:软件则价格上升,为编制和维护系统软件及应用程序所需的成本相对增加,在各个应用领域如果一旦改变数据结构都要修改应用程序,代价无法计算;在数据处理方式上,联机实时处理的要求更多,并开始提出和考虑分布处理数据。文件系统管理数据已经不能满足应用的需求,于是为了解决多用户、多应用共享数据的要求,使数据为尽可能多的应用服务,数据库技术应运而生,出现了统一管理数据的专门软件一数据库管理系统。
2.仿真数据库的组成
仿真数据库按功能划分,包括变量数据库、模型库、故障库、表和图库。
(1)变量数据库。变量数据库是仿真数据库的核心数据库,它存储了仿真过程中的所有变量的信息和值。考虑到管理方便和提高性能,变量数据库必须放在内存中,而且把变量数据库分为两部分:变量信息部分和变量值部分。变量信息部分采用哈希表数据结构存储变量信息,运用哈希算法进行快速检索,进而对变量进行修改、删除等操作,变量信息并不保存在共享内存中,它是专门为提高仿真支撑平台和外部应用程序访问共享内存区的性能而创建的高效数据结构,所有的关于仿真支撑平台和外部应用程序对共享内存区的查找、修改等操作都是通过变量信息数据结构来实现的;变量值部分存储了包括输入变量、输出变量、常数等变t的值,既有模拟量,也有数字量和逻辑量。为了保证实时性,变量值部分以连续的结构数组的形式保存在共享内存区中。在仿真平台扫描变量过程中,通过哈希表将每个变童的变量信息映射到变量值的共享内存区的相应位置。经过对各种数据属性的抽象和归纳,用如下所示的数据结构来描述变量的数据结构,它完整地描述了一个仿真变量的所有性质,基于此数据结构的数据库构成了实时仿真支撑软件中的变量数据库。
(2)模型库。模型库是仿真支撑平台为了管理用户为众多系统创建的数学模型而建立的系统仿真模型数据库,是仿真数据库的关键,仿真模型的调度和运行控制都是在模型库的基础上进行的。首先,在仿真平台的服务器端建立一个共享目录,多个用户在服务器和各个客户机上同时编写数学模型,然后各个客户端利用Windows操作系统的重定向技术(应用程序利用网络远程访问Windows文件系统资源的机制)将各个数学模型模块保存在服务器端的共享目录中。每当新建一个任务时,必须指定该共享目录为此任务的工作目录,不同的数学模型正是根据任务的不同来分类保存。模型库是用文件系统来创建、以文件目录的形式来维护的,所有的模型文件保存在共享目录中被模型调度程序统一管理的。
(3)故障库。故障库存储了所有的故障设置情况,该数据库也是变量数据库的子集,库中所有的故障变量都映射到变量数据库。故障设置主要用于仿真系统中,对于普通的科学计算和监控人员来说,一般不会用到。仿真支撑平台利用故障设置对话框来增加故障、删除故障、修改故障属性和设置故障状态。故障库中每个故障称为故障项,若干个相关的故障的集合称为故障组,故障库是用文件系统来创建故障项、利用故障组来分组管理的。故障按照任务的不同,分别以文件的形式保存在各个任务的工作目录中。
(4)表和图。在仿真活动中,可能会有大量变量,甚至达到上万级。当用户需要监控变量时,这么多的数据在不同的页面显示会给用户带来不便,为此,我们采用了“表”的概念。表用来存储用户感兴趣的一组监视的变量,一般不超过100个。表为变量数据库的子集,其中所有受监视的变量都映射到变量数据库中。图主要用可视化的方法查看某个或某些变量的变化趋势,主要分为曲线图和直方图,其中的变量也都映射到变量数据库中。我们可以利用仿真平台提供的相关工具来建表和建图,并且支持多用户在线创建、编辑等操作。表和图也是按任务的不同,以文件的形式保存在相应的工作目录中。
(二)仿真数据库的通用存储策略
设计仿真数据库,处理时空矛盾时,理应优先考虑效率的要求。如果不在限定的时间内得到数据,则该数据就是过时数据,而过时数据是无效的数据。数据库的设计应以支撑平台对不同数据所要求的响应速度以及数据量的大小为依据,来决定数据的存取策略。传统的数据库技术具有数据共享性、独立性、安全性、完整性等优点,但是这是以牺牲计算机的空间和时间为代价的,它在相应速度上劣于文件系统。为了满足大量数据实时地访问、存取和快速的网络通信能力,仿真数据库需要专门设计。为此我们采用内存数据库、文件系统兼用的方式:模型计算和网络通信等追求实时性和高效率的模块我们采用内存数据库来保存数据,其它需要长期保存的数据则用文件系统统一分类保存。当系统运行时,先把变量通过扫描模型程序或直接从工况文件中装载到内存数据库中,之后模型运行通过内存数据库接口函数和内存数据库中的变量进行交互。这样,通过利用文件系统和内存数据库等多种存取方式和存储介质,既保证了数据的共享性、独立性、完整性和安全性,又节约了内存,提高了系统的响应速度。
三、结语
由于实时仿真支撑软件涉及到的技术含量高,系统庞大,结构复杂,要想开发一套成熟的仿真支撑软件,难度较大。因此,本仿真支撑软件拟进行一些改进,其主要优化表现在以下几方面:系统的界面设计不太美观;目前的实时仿真数据库只能存储整形、浮点型、布尔型变量,只能支持最多二维数组;建模工具还不够强大,模型建立不是非常的方便和灵活。只支持常规建模,没有提供图形建模等其它建模手段。
目前,随着internet技术在全世界范围内的流行,基于Wbe的仿真技术和Internet的远程培训系统的研究也是方兴未艾。今后在原有的基础上增加远程访问的功能,实现远程培训的目标。
参考文献:
[l]刘怪峰.李仁发,莫铁强,孙婷.实时操作系统仿真环境的UML建模[J].系统仿真学报,第14卷,第6期,2002年6月
数据交换平台的实现 篇10
关键词：企业服务总线,数据共享与交换,面向服务架构
电子政务在多年的发展过程中, 已经取得了一定的成果,在设施建设方面得到了很大的完善, 但在一些公共服务信息系统设计方面仍存在很多问题, 仍未实现信息资源 的共享 ,建设力度远远不够, 引发严重的信息孤岛问题, 影响政府办公系统中业务和信息的处理效率。本文通过基于企业服务总线的数据共享与交换平台的设计研究, 为电子政务逐渐向着面向服务、规模应用的方向发展提供给术研究基础, 从而达到提高电子政务系统工作效率的目的, 为相关研究提供参考意见。
1 概述
1.1 ESB 架构
建立在面向服务的体系结构 (SOA) 基础之上的企业服务总线 (ESB) 本质上属于电子行业设备应用集成模型, 其内部集成式软件构件具有紧密的联系, 相互影响和作用。面向服务的体系结构的组装和集合是构建ESB的前提, 包括多种功能元件, 能够满足不同层次目标的要求。
1.2 ESB 特点
在面向服务的体系结构下, 企业服务总线可以实现企业应用的集成。ESB特点体现在事件驱动、面向消息和面向服务3个方面, 其中, 在不同应用间进行的消息接收、产生均属于事件驱动, 面向消息及服务则分别指的是利用ESB进行消息的接收/发送和重复利用服务组合而成的分布应用[1]。
由Web服务、可扩展标记语言及中间件技术共同构成的ESB, 可以起到传递企业应用信息数据的作用 , 改进了传统的传输模式, 在性能上具有显著的优势。在企业构建数据共享与交换平台的过程中, 应用ESB技术可以大大降低成本的投入, 避免了因应用技术差异较大而导致的服务不统一的问题。
1.3 ESB 功能
在研究技术不断完善的过程中, ESB具备的功能逐渐增多, 这些功能的发挥能够以开放标准或专项技术为基础, 主要涉及消息处理、建模、集成、通信、 安全、质量服务和服务交换等。但不同技术的综合运用也可能会带来潜在的问题,例如 : 采用标准 不一致、 技术安全 和灵活程 度差异大 等[2]。ESB核心功能简介如下 : (1) 服务交换。可实施替代服务 ,可以高效地完成应用服务代码的提取工作, 具有一定的开放性特点;(2) 集成。能够使适配器、Web服务和Java2连接器等不同集成方法正常运行;(3) 通信。应用普遍性的传输协议, 通过进程间通信的重要途径, 管理命名服务、网络服务寻址, 将有关位置透明性的寻址服务、路由的信息进行收集。
1.4 ESB 的组成及适配器技术
适配器组 件、管理 控制组件 、转换组 件及通信 组件是ESB的关键组成部分 , 在发挥连接 应用系统 功能的过 程中 ,需要借助适配器技术, 从服务组件、应用及数据库系统等方面实现整合系统与被整合系统应用的统一。多种连接方法为应用系统的联系提供了技术保障, 其中数据库连接、开放数据库互连为应用数据库系统的连接提供了标准规范。ESB的架构图如图1所示。
为了保障系统的高效连接而研制的适配器, 可以使多种系统的接口整合为一个, 并在此基础上实现业务数据的交换,减少了系 统数据传 输的繁琐 性[3]。ESB适配器技术的优 势如下: 改善面向对象、以组件为基础的模块网络应用性能; 提升数据相关操作和处理的工作效率; 将应用系统同管理系统的连接、数据共享变为现实, 可以管理各项事务。
2 信息共享交换平台
2.1 平台的层次结构
用户交互层→流程整合层→应用整合层→应用接口层→信息系统基础设施是组成数据共享与交换平台的5个层次结构,流程整合层又分为业务间整合、业务行为监控和业务流程管理, 而应用层又包括消息路由、数据转换及数据格式定义。
应用接口层是数据共享与交换平台构建的基础, 该平台需要在信息系统基础设施的支持下发挥作用, 可以针对系统间的数据传输提供解决路径。应用整合层作为应用接口层的上一级, 尤其适用于整合系统应用数据信息转换方面, 企业系统数据的应用都应通过该层的数据模型来完成。二者的上一层次为流程整合层, 是确保不同系统高效运作的重要前提,可以整合不同系统, 具有管理业务流程、设计流程、监管控制流程等多项功能[4]。位于数据共享与交换平台的最高层次是用户交互层, 主要面对的广大用户, 使用户能够进入应用系统中, 满足不同用户的需求。用户交互层可以对系统内、外部的信息进行融合。企业服务总线技术在流程整合层及以上层次结构占据着较高的地位, 提供了坚实的技术保障。
2.2 平台功能
数据共享与交换平台的功能包括多种内容, 如:(1) 连接和运行各种数据库, 通过适配器的作用, 对系统进行全面的管理;(2) 建立在可扩展标记语言 基础上的 集成服务 模式, 高效传输应用系统及业务间的数据信息, 结合实际需求,对系统应用功能进行优化配置;(3) 包含测试、监管控制、动态观察和整体部署等功能, 实现远程管理控制;(4) 平台互用性较强, 可以发挥传递数据、数据定位、数据包封装的作用, 根据相关标准, 整合多种应用系统的整合;(5) 转换多种数据格式, 如: 可扩展标记语言同文本文件间 的转换、可扩展标记语言同其他可扩展标记语言间的转换、 短消息服务同可扩展标记语言间的转换等。此外, 还能利用不同的函数关系, 映射异构数据[5]。
2.3 平台架构
就企业中基于ESB的数据共享与交换平台的管理原则来说, 其属于一种集中、统一式的管理, 但在运行角 度来看 ,则归为分布式运行的范畴, 平台架构的设计和实现参考的原则为松耦合原则。应用系统平台包含着大量的节点, 不同节点的自身运行环境相对独立, 均支持数据集成、服 务交换 ,在应用系统的大环境下, 这些节点能够通信联系, 承担着服务总线系统负载。
如图2基于面向服务的体系结构的企业服务总线体系架构所示, 在中央服务器的统一约束管理下, 企业服务总线服务网络呈现分布式的特征, 共包括6大部分, 都是由多个节点整合而成。各层功能独立而统一, 既确保了自身系统扩展性, 同时也存在协作关系, 共同实现企业业务需求。
3 数据共享与交换平台系统实现
3.1 集中式的服务总线的管理
各节点适配器、运行环境的管理均利用的是JMX (JavaManagement Extensions) 技术 , 适配器及SOA解决方案的分布式JBI (Java Business Integration) 环境的管理控制阶段位于企业服务总线体系架构核心的中央服务层, 应用标准为JMX。集中管理层、代理层及设备层是组成JMX代理服务的基本模块, 不同应用层中分布的节点, 可以将涵盖所有注册MBean的仓库、JMXUrl进行连接, 获取有关管理对象的数据信息 , 并向MBeanServer发出一系列的执行命令 , 最终落实和完成相应的操作。
3.2 日志管理
具备日志收集服务功能的数据共享与交换平台, 在Java日志框架的支撑下, 通过多种管理工具, 向用户提供大量的日志信息, 并采取嵌入式数据库的途径, 将不同种类的日志进行存储和管理, 在系统伸缩性方面具有独特的优势, 避免了企业服务总线争用的问题。在当前应用系统中, 开放源码的嵌入式数据库的程序库有着极其广泛的应用, 方便了工作人员和用户进行管理和操作, 性能更加优化[6]。通过设置日志记录表的途径, 可以在平台数据库中对日志的内容、时间和级别进行记录, 还可以查询到日志创建者的网络之间互连的协议。
3.3 节点
各节点运行环境均符合分布式JBI规范要求, 允许适配器组件的接入和运行, 大量节点在基于ESB的数据共享与交换平台中的位置对等, 平均承担着系统总负荷, 大大提高了节点资源的管理和应用效率。
3.4 适配器
数据共享及交换平台的功能实现, 依靠的关键部件就是适配器, 适配器种类繁多, 是应用系统功能整合的根本所在。适配器实现技术包括DBIn、DBOut, 二者均属于数据库适配器, 前者具有接受、解析数据信息的作用, 能够将可扩展标记语言形式的信息转化为结构化查询语言形式, 并执行Sql语句; 而后者根据数据库应用记录查询相应的操作, 进行实时性的监测和控制, 实现数据增量抽取。
4 结语
相关文章：
数据交换服务注册01-12
数据交换功能开发管理论文01-12
电子数据交换技术01-12
职业人文素养01-12
数据交换技术论文01-12
模态计算01-12
数据交换网技术01-12
利用数据交换实现导航仪功能的论文01-12
数据交换和沟通01-12
数据交换技术教学设计01-12
