数据交换平台范文

数据交换平台范文（精选12篇）

数据交换平台 第1篇

一、数据交换平台的作用

在传统的IT架构中, 两个应用系统为了实现数据交换, 需要在这两个应用系统之间建立点对点的数据连接, 并且每个系统都需要做相应的协议转换。当有n个异构的应用系统需要互相交换、共享数据时, 网络结构将变得极其复杂且协议转化工作将变得极其繁琐, 这种IT架构存在的问题, 主要表现在:

●系统越多, 网络拓扑越复杂, 接口关系越复杂, 越难维护;

●自动化程度低, 效率不高;

●无法快速响应新业务开拓或业务需求的变化;

●初期快速有效, 后续建设和维护成本越来越高。

为了解决上述问题, 引入了数据交换平台的概念。通过建立统一的数据交换平台, 消除以前信息化建设中的“信息孤岛”问题, 把各种应用系统有效地联系起来, 最大限度地发挥其效能 (如图1所示) 。

二、数据交换平台的设计

数据交换平台的应用架构如图2所示。

从层次结构来看, 可以将数据交换平台的主体功能分为四个层:业务层、服务层、组件层和已有系统资源层。

(一) 组件层

组件层将数据交换平台的基础性功能封装成不同的组件形式, 如数据缓存、数据传输、动态路由、格式转换等, 为上层的服务提供颗粒度适中的组件。

1. 系统接入组件

提供对各种常用协议的支持, 如HTTP, MQ, Web Service, Socket, JMS, FTP/SFTP, Email, ODBC/JDBC等, 提供对平文本、分隔符文本以及X M L, SOA P, SWIFT, ISO8583等多种通用或行业标准的数据格式的支持, 适合各种系统以不同的通信方式、不同的数据格式接入数据交换平台。同时, 系统接入组件提供良好的扩展能力, 为未来新增的通信协议和数据格式提供良好的支持。

2. 同步服务组件

为接入数据交换平台的应用系统提供实时的请求/响应服务, 主要包括各类实时交易报文的请求/应答。

3. 异步服务组件

为接入到数据交换平台的应用系统提供批量数据处理服务, 如批量报文处理、批量影像文件处理等。

4. 数据传输组件

数据传输组件是数据发送、接收、传输的通道, 支持报文和文件两种模式, 支持数据在各应用系统之间可靠、稳定、高效地双向传输。

5. 数据缓存组件

针对一些访问频率比较高、占用资源比较大的数据, 如数据库中的路由表等, 数据缓存组件在系统运行初始时读入到内存中, 系统运行时只从内存中访问该数据, 从而提高了该数据的访问效率, 同时降低了资源占用。在源数据被更新后, 数据缓存组件同时提供缓存刷新功能, 同步更新缓存到内存中的数据。

6. 异常处理组件

异常处理组件主要处理两类错误:数据交换平台本身产生的异常和各应用系统通过数据交换平台交互产生的业务错误。对平台本身的异常, 记录异常日志;对业务错误, 记录异常日志并回复交易发起系统或服务调用方错误信息。管理人员和运维人员可以通过查询日志流水, 查看异常信息并采取适当处理措施。

7. 日志记录组件

对于数据交换平台处理的任意数据, 如请求/响应报文、服务的调用和响应信息、异常信息等, 提供记录文件或数据库流水的功能, 为统计及查询管理提供原始数据。

8. 安全控制组件

安全控制组件提供通用的安全性控制。一般来说, 对安全的考虑主要涉及用户的认证、服务的授权、不可抵赖性和合法性校验、数据传输安全等几个方面。安全控制组件能够判断使用者是不是“合法”的用户, 能够判断服务的调用者有没有权限访问数据交换平台中特定的资源。传输的安全则利用数据传输组件提供的SSL传输方式进行认证和加密, 不可抵赖性可借助于签名验签组件实现。

9. 签名验签组件

签名验签组件对收到的报文调用加密机进行验签, 对发送的报文调用加密机进行签名, 从而保证数据的一致性和完整性。

1 0. 动态路由组件

提供多种方式获取路由信息, 实现动态路由。支持根据报文内容获取路由信息, 支持根据业务规则计算获得路由信息, 支持通过查询外部数据源获取路由信息, 如在数据库中定义路由信息表, 通过查询路由表实现动态路由的功能。

1 1. 格式转换组件

提供各应用系统之间存在差异的报文格式转换功能, 支持平文本、分隔符文本以及XML, SOAP, SWIFT, ISO8583等多种通用和行业标准的数据格式之间的转换。同时, 在转换前可以根据数据字典进行格式比对, 进行内容或者字段的校验。

1 2. 系统监控组件

系统监控组件通过监控数据交换平台处理的所有业务数据 (如各类报文) , 为业务分析提供数据基础;同时通过系统事件 (如不能处理的报文、不能发送的信息等异常事件) 对系统进行实时监控, 反馈系统的健康状况, 为管理人员和运维人员提供可靠的数据显示。

(二) 服务层

该层是系统中最重要的一层, 数据交换平台的所有核心服务都集中在这一层, 该层利用组件层的功能组件来构建数据交换平台所需要的不同功能服务。所谓服务, 指的是具有基于统一规范的服务接口、服务调度模式、完成特定功能的一个功能实体。服务层主要包括数据服务、日志服务、监控服务、同步服务、异步服务、格式转换服务、接入服务、安全服务等。

(三) 业务层

该层封装有部分业务逻辑调用, 利用已经封装好的各种数据交换服务来构建不同系统之间进行数据交换的流程。

(四) 已存在系统资源层

该层利用已经存在的信息系统, 如客户信息管理系统、员工信息管理系统等, 这些系统将与组件层进行交互, 尽可能将现有系统中的功能加以利用, 减少系统开发量。

(五) 组件间关键关系

数据交换平台中主要的组件可以分为两大类:业务处理组件和公共组件。业务处理组件包括数据传输、系统接入、安全控制、签名验签、服务注册、同步服务、异步服务、格式转换、动态路由等组件, 公共组件主要包括数据缓存、日志记录、异常处理、系统监控等组件。各个组件之间主要的交互关系如图3所示。

一次典型的处理过程为:

第一, 发送方或服务调用方通过数据传输通道和系统接入模块, 把请求数据或服务调用信息发送到数据交换平台;

第二, 进行安全性校验和验签操作;

第三, 如果是服务调用, 在服务注册库中进行服务查找, 检索到服务的相关信息;

第四, 进行格式转换, 转换成接收方或服务提供方认可的数据格式;

第五, 判断是同步服务还是异步服务, 如果是同步服务则需等待接收方的回复或服务提供方的响应;

第六, 根据正确的路由信息把请求数据发送给接收方或调用服务;

第七, 如果是同步服务, 数据交换平台接收回复或服务调用响应;

第八, 进行格式转换, 转成发送方或服务调用方认可的数据格式。

第九, 进行数字签名操作;

第十, 根据正确的路由信息把回复信息或服务调用响应发送给发送方或服务调用方。

三、数据交换平台实现策略

数据交换平台的建设存在两种实现策略:一是完全依靠自开发来实现, 二是采用市场上成熟的中间件加以少量定制化开发实现。不论是从技术可行性和成熟度, 还是从开发费用、运维费用等成本因素考虑, 推荐第二种方案。

首先, 从技术角度看, 自开发数据交换平台是完全可能的, 而且建设初期成本也相对较低。但我们应该看到, 数据交换平台是各应用系统交互的基础, 对功能性、可靠性、健壮性、扩展性等方面具有较高的要求, 自主开发往往受制于项目周期等原因, 无法进行充分的设计和大量的测试, 无法全面满足系统的要求。而且, 随着时间的推移和系统的扩展, 一方面是开发人员的流失导致再开发和维护的困难, 另一方面对平台本身的扩充性也提出了新的要求。综合看来, 各种成本反而会更高。

其次, 从应用开发商的角度看, 其核心竞争力在于对客户业务的了解和把握, 在于业务逻辑的开发, 而不是中间件平台。所以, 数据交换平台应该构建在市场主流的产品上, 并加以客户化的定制开发。

在数据交换平台的建设中, 推荐IBM WebSphere Message Broker, WebSphere MQ和WebSphere MQ File Transfer Edition产品的组合来实现。WebSphere Message Broker在多个企业中已得到了应用, 它的各项功能 (包括接入、转换、路由等) 以及高性能、扩展性、可靠性等, 都得到了验证。WebSphere MQ是目前市场上应用最广泛的消息中间件。Web Sphere MQ File Transfer Edition是可管理的文件传输方案, 基于MQ实现可靠、高效、稳定的文件传输。

网络交换平台创业计划书 第2篇

二．团队成员

三．项目背景：

现代我们正处于一个科技水平不断进步,生活水品不断提高的时代, 各种商品的更新率不断提升，以致折旧率下降 而造成了许多不必要的浪费，而生活的经济差距更是让这种浪费日益突出。这些表现更多的体现在大学生身上，尤其是毕业大学生。据统计，武汉市有在校大学生100多万，居世界之首，这也就意味着每年有20多万的大学毕业生，而在校大学生有些因处于离市中心较远的郊区（如；新路村大学城，大花岭大学城，黄家湖大学城等)他们周围并不繁华，学校周围并没有之于“沃尔玛”之类的大型超市，出门仅仅靠挤公交车，购物难度可想而知。鉴于交通等因素很多大学生的生活用品以及其他等电器产品都不方便带走，直接丢弃。这些东西大多还可以使用，还有部分是半新品。就拿电风扇打个比方，假如10个人中有2个人丢弃电风扇，这样算下来毕业生差不多丢弃了4万台，这是一个不小的数字，当然这只是保守的估计，结果可能远远不止这么多。

而武汉在“十七大”之后，就被国家确定为“两型社会”试验区，并且赋予了先行的政策创新权，而我们的“一点就Go” 的创意与两型社会切好吻合，为建设节约型社会贡献了一份力量。俗话说垃圾是放错了地方的资源，事实也是如此。因此我们想出了一中方法让这些“垃圾”变成有用的资源。

随着第三次科技革命的迅猛发展，网络开发商已成了不可阻挡的趋势，电子商务的发展也让人们正正的体会到了不出门也照样丰衣足食的乐趣。作为中国这个电子商务刚刚起步的国家来说，电子商务这一块有更多的资源有待我们开发,而我们就以独特的眼光发掘了“一点就Go”大学生网络互换交易平台。它将改变以传统的买卖为方式的交易平台，它既可以买卖也可以互换；它也改变了以快递为基础的交易平台;它既可以快递也可以面对面的进行交易。武汉市是世界上大学生最多的城市，我们拥有得天独厚的优势，因此，在这种情况下，开发大学生资源已成为不容考虑的商机。

四．市场调查

据不完全统计，武汉市的高校有86所以上，平均每个学校1万人的话就有86万多人，每年都有四分之一左右的人毕业，而每人平均丢弃两件有用的物品来算的话，数量是很庞大的。而社会上也并没有一个正规有效的渠道来处理这些物品，以至于让这些物品成了垃圾。武汉市一个快速发展的城市，在中部崛起政策的推动下，它更是在快速的发展，由此也带来了大批的外来务工人员。而这些外来务工人员都是流动的资源，因为没固定的工作岗位，所以他们都没有固定的住所，随时准备换行业。作为生活用品来说的话，他们是不可能去买新的，这样既不划算也不不能。因此，这些流动的资源也为我们开拓了良好的二手市场。武汉在建的地铁有三条，待建一条，外加上正在建造的楼房以及很多公共设施，这平台太让外来务工人员占了很大的比重。社会上都流行说赚钱赚两种人的:一是农名工，二是学生。光就这两点，武汉都具备了，市场前景很可观。而在目前为我们熟知的二手交易网站有“赶集网”“58同城网”。而主要针对大学生二手交易网站的平台还是一个空白，“一点就Go”它的方便性与可操作性是真正使用的，这种有利于环境的交易平台对构建友好型校园在某种程度上有促进作用。所以说这是一片很有前景的可开发资源。

五．总体进展安排与发展策略

1.项目总体安排

首先要租一台服务器，建立一个网站，并注册。然后要对这个网站进行加工，比如设计网页，制作LoGo,还需要向有关部门提交申请,注册品牌等.作为网络交易平台还需要与相关支付平台合作，这些大概发两个月时间，一切安排就绪后可以选择几所学校作为试点，调查市场情况，在逐步改进以及扩大覆盖范围。网络能稳定有效运转大概需要半年时间。

2．项目开发，生产策略，营销策略

由于武汉市高校相对集中，所以我们在销售自己的品牌方面有较大优势，可以通过人脉将自己的产品打出市场，还有各大高校的帖吧．腾讯网.人人网.朋友网.新浪微博.搜

狐微薄等网络资源来影响我们的品牌，以及有空余时间在一些高校进行宣传活动，相信在这些外力的影响下，我们这个品牌一定会广为流传，有市场才有效益。

3.获利方式

我们建立的交易平台不属于第三方交易平台，也就是我们不赚取与卖家（或者说是甲方或乙方）的费用。我们建立的平台是作为一个品牌的基台，我们会把网页分为不同的版块如：黄家湖大学城、新路村大学城、大花岭大学城、光谷大学城、江夏区同学可根据自己所在地区可实现本校的同学的同学进行交易，而bbs,只能在本校进行交易，且不是针对性，这一点就go需要足够的特色优势，我们对一切的交易都是免费的，当点击量上升时，就会有商家来找我做广告，我们主要收取广告费用，其次“一点就go"符合建设资源节约型社会，政府会在给予一定的扶持，从每一个注册的大学生以及代理商都采用实名制，以保证每个人的合法权益。这种获利方式虽不为最佳方式，但依照目前来看还是有利可寻的。

六．资金运作财务预测。

1.项目启动自今年来源与运营计划。

启动项目的资金会通过国家政策：是国家给大学生提供的创业优惠措施，为了支持大学创业，国家各级政府出台了许多优惠政策，涉及融资，开业，税收，创业，培训，创业指导等诸多方面。要具有一定生产经营能力或已经从事生产经营活动的个人，因创业或再创业提出资金需求申请，经银行认可有效担保后而发放的一种专项贷款。符合条件的借款人，根据个人的资源状况和尝还能力，最高可获单笔50万元的贷款支持；创业贷款的期限一般为1年，最长不超过3年，的方式来获取。

前期建立网站以及相关程序预计将花2~3万元来完成，后期的营销以及将品牌打入市场的费用在1万元左右。网站运营前三个月可能不会有较大盈利，甚至会出现亏损现象，当亏损幅度增大时，我们会适当减少支出以及运营规模，当网站运营平稳后再开始对代理商进行收费制，这样就可以实现盈利。

2.投资收益与风险分析

我们采取的收益方式是：收取商家的网站投放的广告所支付的费用，在“点击量”上来之后，这一点是完全的。我们的网站真正能免费为大学生们服务，政府会给予支持！财务预算： 总预算：6200元

租网站服务器：3000元

宣传海报，横幅，传单预计：800元

网站设计与制作：500元

机动费用：600元

市场插广费：800元

由上可得出，如果因经营不好导致失败，其损失可以降低到最小。

3．预测近3年得财务状况：

开始同学们可能由于不了解这个网站的真正方便性，可能不会去利用这个网站平台进行二手交易，因此收入会陷入低谷。但经过大量宣传之后，我相信在同学之间就会形成极迅速的推广效应，这样这个网站才会正式走入发展的正规时，我们认为此时应该完善网站运行规章制度，维护提升好“交易”信誉，使更多的同学参加运用次网站平台，这是发展中期阶段是财务稳增阶段，运用这个计划段需一年半左右的时间当一切进入正轨的同时运行规章制度，维护提升好交易平台，使更多的同学参加这个平台，这是发展中期阶段是财务为增长时期，这个计划时间为一年半左右，在稳定增长长期后应拿部分资金进行网站的整修，使其消除一些存在的“隐患”，从而使财务发展更加顺畅。

七.风险预测与应对

第一阶段（摸索阶段）：需要大量时间进行宣传调查，学生对“一点就Go”接受程度低。各种任务分配有待改进，扩大以及营销较为艰难。信息时代，竞争较为激烈。

解决方法：在前期做好宣传工作，正式运营开始时就对宣传事宜不必过于担心，成员应责任到各个学校，方便宣传以及市场调查，突出团队优势，做出团队自信，赢在起跑线。也可与别学校创业协会进行沟通，希望能得到他们的支持和帮助。第二阶段（成熟阶段）：学校同学利用平台反映强烈，竞相推广。部分成员可能因私人事件离开团队，需要每天处理的事情变得越来越多。

解决方法：进一步扩大市场，寻找商家合作，指定“特Go”点，多进行展销！同时扩招成员，做到每个部门的运作部缺乏人员。第三阶段（推广阶段）：武汉各大高校的学生对“一点就Go”基本了解，已形成局网覆盖。而每年大学毕业生的“二手物品”又不能被还未毕业的大学生全部“交易”，留下的可是一大笔资源浪费。

解决方法：当网站如以能够有资金时，可以对其进行低价收购，在校内搞展销活动。这样可以促使网站运行更加活跃，也使“二手”资源的浪费大大降低。

工作分工、人员执行如下：

八.远景规划

统一数据交换平台的设计和实现 第3篇

摘要:目前,数据共享困难已成为银行系统所面临的一个重要问题。本文指出统一数据交换平台能解决在分布式与多应用系统环境下的数据交换问题。文中根据组件化设计原则,以完成系统的总体设计、数据存储和加工设计。并应用NAS存储、使用NFS共享等技术部署对ETL技术进行了研究。

关键词:统一数据交换 存储 ETL

中图分类号:TP311.13文献标识码:A文章编号:1006-8937(2009)03-0064-02

在核心业务系统与外围系统之间批量交互数据是银行应用系统中最常见的任务之一,由于通常要受到多方面因素的制约,这是一个十分复杂而且耗费精力的工作。尽管目前银行正在进行综合业务系统大集中的改造,但并非所有银行的应用都会集中到唯一的核心业务系统上,而银行内还存在许多面向管理类的应用系统,这些围绕在核心业务系统的应用系统,我们称之为“外围系统”。

核心系统与外围系统的数据交换可以分为批量数据交换和实时数据交换两类。实时数据交换是双向的,一般由专门的中间件完成。批量数据交换也可能是双向的,但总体上是从核心系统流向外围系统的批量数据交换方式为主。从这一点来看核心系统是数据生产者,外围系统是数据消费者。外围系统之间也可以有批量数据交换和实时数据交换,因而互相扮演数据生产者和数据消费者的角色。

本文研究的是如何在中国建设银行总行实现统一的批量数据交换,从而建立统一数据交换平台(Unified Data Interchange Platform,以下简称UDI)。

1应用技术现状与研究

本文研究的重点之一是如何实现海量数据的加工,而且要在规定的时间窗口内完成指定的数据加工处理任务,否则,从业务角度看就是失败的。这一点的提出要求我们研究和应用先进的存储和计算技术,以及使用ETL技术对业务数据进行提取。

1.1网络存储的研究

早期的存储系统是计算机系统的一部分,大多以存储设备形式出现。随着网络的发展,数据的存储也逐渐由单机向多机方式和专用机发展,数据的共享与传递也逐渐从依赖主机系统向依赖网络系统发展。在大型企业应用和Internet发布系统中,安装数十台服务器已经很常见。但过于分散的数据资源,会给访问和管理带来困难。因此,数据存储问题备受关注。存储系统大致可以分成三种类型:

直接依附存储系统(Direct Attached Storage,DAS)又称为以服务器为中心的存储体系。其特征为存储设备是通用服务器的一部分。数据的输入/输出由服务器负责,数据访问与操作系统、文件系统和服务程序紧密相关。当用户数量增加或服务器正在提供服务时,响应会变慢。在网络带宽足够的情况下,服务器本身成为数据输入/输出的瓶颈。

网络依附存储系统(Network Attached Storage,NAS)这种存储方式多采用专用数据服务器。该服务器不再承担应用服务,称之为“瘦服务器”(Thin Server)。数据服务器通过局域网的接口与应用服务器连接。由于采用局域网上通用数据传输协议,如NFS,CIFS等,所以能够在异构的服务器间共享数据。NAS也是一种集中化数据存储形式,便于维护和管理。

存储区域网络(Storage Area Network)采用高速数据连接通道—光纤通道(Fiber Channel,FC)连接服务器和存储系统。从结构上看,服务器和数据存储系统相互独立。将设备连接到FC集线器或交换机上,便于扩展系统规模。FC的传输速率和可靠性极高,能够满足当前视/音频业务的需求。在SAN中,所有的存储设备和存储数据均可采用中心化管理,使得整个存储系统具有可伸缩性。并且,可以通过存储设备的集群方式而达到高可用度。

从软件角度看,NAS是应用与存储分离的系统,应用服务器通过局域网(LAN)访问文件存储系统,通常NAS以标准化访问协议(如NFS)提供服务;在SAN中,文件系统与存储系统完全分离,存储系统实际上成为运行应用程序服务器的设备,二者以高速FC连接。

1.2ETL技术的研究

企业的信息系统往往是一个由传统系统、不兼容数据源、数据库与应用所共同构成的复杂数据集合,各个部分之间不能彼此交流,这些数据的来源、格式不一样,导致了数据整合的难度,企业非常希望有一个全面的解决方案来解脱自己的困境,解决数据一致性与集成化问题,从而能够从所有传统环境与平台中采集数据,并利用一个单一解决方案对其进行高效的转换,这种解决方案就是ETL(Extraction,Transformation and Loading)。

从实际角度,ETL的使用包括数据抽取、数据传输、数据转换与清洗、数据加载、调度监控以及元数据管理等。

2 平台的总体设计

组件由一段执行码组成,通过对相应的控件资源的调用完成设定功能的执行模块。组件通过有序的组合,构成组件执行序列即流程,完成所要实现的功能。本节对UDI平台建设需要实现的功能进行分析,包括技术合规性检查、元数据管理、数据接入服务、数据组织和管理服务、数据提交服务、安全控管、系统监控管理等组件,并在此基础上依据组件设计的思想进行组合,提出统一数据交换平台的总体架构。

2.1 UDI的功能分析

2.1.1 技术合规性检查

按照UDI数据标准和目标系统的要求,针对数据格式所进行的检查,包括数据属性与值域检查、代码表引用检查、中文乱码和半个汉字等检查。

2.1.2 元数据管理

简单地说,元数据是“关于数据的数据”。包括业务性元数据,主要指数据的业务定义、计算公式、修改规则等;技术性元数据,主要指数据结构(数据表和字段)的定义和转换规则等;操作性元数据,主要指作业运行日志、数据保留期间、加载频率等。UDI系统重点是实现基于技术性元数据的元数据驱动服务以及对元数据的管理服务。

2.1.3 数据接入服务

负责源系统数据向UDI的接入,包括与源系统的连接、源系统数据的获取以及源系统数据向UDI标准数据的转换,特别要考虑系统面对大数据量和有限处理时间条件下的处理能力。UDI平台支持的转换规则如:格式与类型、数据翻译、数据连接、数据合并、数据排序、数据计算、码制转换等。

2.2 数据组织和管理服务

数据组织和管理是实现“目标系统通过UDI屏蔽对源系统的数据要求”的关键,UDI对进入其标准数据的源系统数据不做结构上的改变,对这些数据可以重新进行组织,这样可以满足目标系统对数据的多样性需求,并逐步形成UDI的数据标准和接口标准,统一UDI的数据管理流程和作业流程。

2.3 数据提交服务

负责由UDI标准数据向目标系统的数据转换和分发管理,包括按目标系统要求所进行的技术性转换以及对待提交数据的管理。

UDI作为批量数据交换平台基础设施,所以与源系统必须制定规范的数据交换协议标准,综合考虑源系统安全性,性能问题,传输效率等等原因,UDI系统与源系统之间不采用数据库直连标准,如ODBC等连接方式。

采用FTP协议作为源系统与UDI之间的数据交换协议,那么就得约定与源系统之间的数据准备就绪标准与检查方式,要求UDI平台支持数据就绪标记文件和时间约定方式。

2.4 安全控管

UDI总体安全控制分成:系统层安全性(如操作系统)、应用层安全性(如针对数据存储的安全加密措施,针对应用数据在网络传输过程中,采取的应用层加密控制等等)、网络层安全性(如采用防火墙,VPN等网络安全技术)。

2.5 监控管理

与管理流程相对应的对整个系统运行环境的管理,包括系统接入管理、转换配置管理、运行配置管理、日常作业管理和系统恢复管理等。

2.6 数据存储设计

2.6.1 存储方案的选择

基于NAS、SAN的存储系统都是完全独立的,不存在与服务器之间紧密的、依赖性的物理硬连接,都可以构造中心化的数据存储系统。二者都可通过冗余的硬件配置和软件支持做到安全可靠的保护数据,都具有良好的扩充能力和数据共享能力,都能实现中心化的数据管理。

在扩展能力方面,SAN通过多个FC交换机的级联,理论上可连接几十万个设备,要优于NAS。另外,NAS的系统访问能力受限于LAN的速率和服务质量,而SAN采用光纤技术,能提供高达1Gb/s的速率,数据访问速度优于NAS。

NAS的设计使得网络中的通用服务器可以从繁重的文件存储功能上解放出来。从具体的系统实施来讲,NAS有自己非常明显的优势。

首先,NAS结构简单,易于实现。只需将NAS文件服务器连接到LAN,进行简单的配置即可实现数据共享。而SAN至少要在每台服务器上安装一块HBA及其驱动程序,当服务器数量较多时,还要添加FC交换机,网络布线和系统配置都较复杂。术语“即插即用”对于SAN来说并不适用,至少还需要一段时间来达到。

其次,NAS易于实现多个局域网子网段的存储共享。

综上所述,结合银行实际情况,UDI的数据存储最终选择NAS存储方式。

2.6.2 存储方案的设计

UDI系统的数据共享主要分为UDI应用处理器之间的数据共享和ETL主辅节点之间的数据交换两种情形。其中ETL主辅节点的数据交换由ETL工具自身来实现。

服务所用的数据存储在集群文件系统中的磁盘设备组上。这种设置首先数据是高可用的,也就是说,因为磁盘是多主机的,如果当前主节点的路径出现问题,访问能换到可直接访问这些磁盘的另一节点。其次,因为数据在集群文件系统上,所以可以从任何集群节点上直接查看它,而不必过问此节点与存储设备是否有物理连接。可以像常规设备那样使用全局设备。UDI共享设计方案如图所示。

2.7 数据加工设计

应对数据源的数据提取可以有两种方案,一种是设定一种类型,比如关系数据库,作为统一的源类型,其他类型首先转换到关系数据库表中,然后再实施提取;另一种方案是直接选用数据提取的中间件产品,比如Ascential Datastage等。

如将数据装入数据库,再进行提取,文件在服务器上有转换、装载、抽取的环节。来自源系统的数据使用文件形式,数据量很大, UDI初始全量数据约820G,把文件Load到数据库中是需要时间的,同时,数据库通常会用到索引,Enable索引比较慢,因而效率要差一些。而采用中间件产品,如ETL工具,可以直接将接收到源文件进行提取,根据节点个数设置并行处理进程,提取后结果文件直接发送到目标系统,这样不用经过“数据落地”的中间环节,处理效率比较高。

UDI平台的数据逻辑加工处理最终采用Ascential公司的DataStage ETL工具进行规划设计,UDI平台一部分组件是基于ETL工具的进行开发(ETL工具开发语言 SCRIPT),另外一部分组件需要采用开发语言进行开发,统一规划成AIX下C/C++。管理数据库采用Informix数据库,任务调度和监控通过ODBC与数据库连接。

统一数据交换平台项目作为建行基础设施的建设,已成功投入运营。当前接入源系统有五个(DCCN、DCCS、CMIS、国际卡、证券等),接入目标系统有四个(BDB、ECIF、OCRM、IPSS等)。平台在功能上满足了建行核心系统与外围系统之间的批量数据交换需要。

参考文献:

[1] 周敬利,余胜生.网络存储原理与技术[M].北京:清华大学出版社,2005.

水利数据中心数据交换平台设计探讨 第4篇

近年来, 水利信息化建设取得重大成就, 并逐步进入全方位、多层次推进的新阶段。水利信息网络基本覆盖全国;截至2012 年12 月底, 国家政务外网已连接31 个省 (区、市) 和新疆生产建设兵团、311 个市 (地、州、盟) 和2 251 个县 (市、区、旗) , 地市和区县级政务外网整体覆盖率分别达到93.9% 和80.1%;国家政务内网“十二五”计划扩充至县级[1]。水利日常工作基本实现电子化, 应用系统数量迅速增加, 积累了大量分布异构独立的业务数据;水利普查工程、水资源监控能力建设等项目的开展为水信息提供了持续更新的能力。与此同时, 各级水利单位及业务系统间的互联互通、信息共享、业务协同, 成为水利信息化深入发展的迫切要求。建立数据交换平台是整合信息资源、深度利用分散存储数据资源的有效途径。

随着水利信息化进程的不断推进, 特别是国家水资源监控能力建设项目的建设和水利信息网络覆盖范围的扩大, 为充分利用水利信息资源提供了肥沃的土壤, 水利信息的多点获取、分散处理与分布存储特性将促使各个业务部门建立相应的数据交换系统。这就迫切需要从整体上对水利数据交换平台进行规划, 做到信息化建设的“五个统一”[2], 避免出现交换平台建设过程中各自为政、互通困难、重复建设的现象, 进而保证交换主体间数据共享、发现与交换能够高效有序的进行。

1 交换平台的需求分析

国家水利数据中心总体布局为“三级两域四区”, 国家、流域和省级节点组成三级节点[3], 政务内网和外网形成两域, 并根据保密和访问权限分为A, B, C, D四区, 其中A区完全开放, B区运行于政务外网, C区运行于政务内网, D区为本级政府首脑机关提供特殊信息服务, 如图1 所示。水利信息资源分布存储于这些数据节点中, 数据间具有不同的保密等级, 信息交换体系需要支撑三级之间, 以及各节点内部不同区域之间信息交换的实现。

水利领域长期的信息化实践积累了大量的数据资源, 从采集方式视角归纳如下:实时监测信息, 主要包括水文观测 (地表地下水量水质状态等信息) 、水利设施在线运行状态、用水户用水排水等信息;通过自身业务办理过程搜集整理或不定期专项调查获得的信息;通过与国土、环保、气象和农业等政府涉水部门交换获得的信息资源。这些数据又以结构化、非结构化和半结构化等形式, 分散地利用文件、数据库等各种系统存储于国家水利数据中心各级节点 (数据中心内部亦分布存储) , 形成模式各异数据资源[3]。这就要求, 数据交换平台不仅要支持中央、流域和地方内网/外网的数据交换 (甚至是面向水利行业外的涉水政府部门以社会大众的数据交换需求) , 也要支持结构化、非结构化、半结构化等多种数据格式的交换。

在现有数据的基础之上, 国家防汛抗旱指挥系统 (二期) 、水资源监控能力建设项目等的开展也为水利大数据提供了持续更新的能力。此外, 随着水利信息化进程的不断推进, 水利业务应用将日益增加, 新生数据交换需求旺盛。水利数据交换平台还需具备前瞻性, 不能以特定的专用数据交换系统为目标, 要保障先期建设的数据交换系统能够为后续的数据交换需求提供基础, 面对新生数据交换需求时, 能够对后续建设系统进行指导, 快速利用现有交换资源[4], 尽可能少地进行新的建设就能快速形成解决方案, 满足新的交换需求;构建起分布数据资源和交换服务目录, 以形成可以“生长”的水利交换平台。

2 交换平台的体系架构

水利数据交换平台的总体体系架构用以描述构成水利数据交换平台的各组成部分, 以及各组成部分之间的相互关系, 便于从整体上了解“交换体系”概念。总体体系架构包含水利数据交换平台、交换节点和涉水政府部门交换业务系统, 如图2 所示。

水利数据交换平台作为构建于具体交换业务系统之上的控制与管理平台, 部署于国家水利数据中心国家级节点, 包括软硬件环境, 提供交换节点、服务管理, 以及数据目录和平台管理服务, 形成交换服务门户。交换平台中的中央交换库用以存储各级交换节点共享的交换数据 (构建数据目录服务支持发布与订阅) 及行业外交换过来的数据。

数据交换节点是指中央、流域和省三级水利单位构建的实现信息资源推送和拉取的单元。通过注册方式进入交换平台, 基于交换平台的标准与规范进行软硬件条件的建设和交换业务支撑软件的开发与部署, 依据交换平台的服务配置指令构建相应的交换服务 (结构化数据表、非结构化数据目录资源配置等) 。

交换节点是交换平台数据交换任务的执行单元, 实现数据资源传送和处理。交换节点部署交换库用以存储需要向外交换和从外接收的数据资源;针对具体的交换需求, 进行交换任务的管理, 实现对结构和非结构化数据交换服务的启动、停止等管理功能, 利用交换业务服务实现交换库中数据的推送与拉取。采用主动推送的方式将交换服务的运行状态推送至交换平台。特别注意的是, 水利数据交换服务平台需要具备基本的FTP数据传输能力, 各级交换节点在进行建设时必须构建相应的FTP服务。

国土、环保、农业与海洋等行业外涉水政府部门通过数据共享交换门户发现数据资源, 提交数据交换请求, 通过拉取与推送的方式获取数据;由涉水政府部门交换过来的数据资源统一进入中央交换库, 交换平台通过监控中央交换库, 实现对涉水数据交换过程的监控。

3 交换平台的工作流程设计

按照数据交换用户参与工作的内容, 水利数据交换平台用户可以分为数据拥有者、使用者, 交换平台和节点的管理者。其中数据拥有者是中央、流域和省等水利数据资源的拥有机构与个人;数据使用者是指需要从数据拥有者处获取交换数据的机构与个人;交换平台管理者是交换平台的维护与管理机构与个人;交换节点管理者是指中央、流域和省等三级交换节点的维护与管理机构与个人。数据拥有者和使用者是参与数据交换用户的不同角色, 同一用户可以同时承担这2 种角色。

水利交换平台的工作流程如图3 所示。数据拥有者从水利信息资源库中提取数据资源的特征信息, 编目形成交换资源核心元数据, 注册到交换资源核心元数据库中, 生成数据资源目录, 为使用者提供数据发现服务;针对数据使用者的交换需求, 数据拥有者从中抽取出需要交换的数据资源, 并根据需要进行转换和封装, 采用推送方式放入交换平台中的交换前置库中;数据使用者通过水利数据交换平台的数据交换服务拉取所需的数据资源 (或者由交换平台主动推送给数据使用者) 。数据拥有者和使用者通过推送方式将数据交换状态信息发送到交换平台运行管理支撑库, 交换管理者 (包括交换平台和节点管理者) 通过数据交换平台门户, 实现对交换平台数据拥有者与使用者交换过程的监控及交换平台的维护。

4 交换平台的功能设计

4.1 交换节点管理

交换节点管理用以实现中央、流域和省等三级交换节点的注册、配置和查询等功能, 对于3 种业务功能, 交换平台以门户访问和Web服务调用等方式对外提供服务。

交换节点注册供交换节点管理员依据节点元数据规范向交换平台进行注册。注册信息参考北京市地方标准《政务信息资源共享交换平台技术规范第3 部分:政务信息资源交换管理》[5], 主要包括:节点名称、类型、编码, 以及数据交换功能描述 (本节点具备的交换能力, 例如具备FTP, Tong GTP和Tong Link Q的交换功能软件) 、交换节点的类型 (由交换节点配置功能进行管理) 。

交换节点配置用以支持交换节点管理者配置交换节点的类型 (接收、发送、混合, 以及本节点能够接收和发送的数据类型) 。类型配置修改后, 需要再次提交到交换平台进行审核通过后生效。交换节点的交换能力可以通过逐步构建的交换业务系统得到丰富和完善。

水利数据交换平台通过交换节点注册形成交换节点目录服务, 通过交换节点查询功能提供按类型、状态查询各个交换节点的情况。

基于统一规划、分步实施的原则, 中央、流域和省级交换节点可以根据基础设施情况 (例如政务内外网的网络条件、软硬件设施等) 逐步构建交换节点, 节点建设完成后, 通过节点注册接入交换平台, 逐步形成对“三级两域四区”数据交换的需求。

4.2 交换服务管理

交换服务是指交换节点为实现水利信息资源的交换而提供的一组对数据操作的集合。为了实现交换服务的可生长性, 交换服务采用平台统一规划, 交换节点分别建设实施的模式进行构建, 各级交换节点依据交换平台的服务配置指令进行服务构建与运行维护。三级数据交换节点构建的交换服务须经交换平台审核后发布成为交换服务目录, 提供给数据拥有者和使用者使用, 以保证交换服务的全局通用性 (通过服务构建可以将交换节点现有的交换基础设施进行公用, 达到兼顾现有交换系统的目的) 。交换服务管理用以实现各级交换节点交换服务的建模、发布和查询。

交换服务建模用以支持在交换节点交换软硬件基础设施之上, 根据交换业务需求生成数据交换服务的构建指令, 交由交换节点进行构建, 建立起交换节点间的数据交换能力。交换服务审核用以审查交换平台管理者交换节点构建的服务是否符合交换平台的服务构建指令和接口规范;并将审查通过的交换服务发布成为交换服务目录。交换平台支持以门户和Web服务等方式查询交换服务目录获取相应的交换服务。

4.3 交换平台管理

交换平台管理包括监控、用户、日志和中央交换库的管理等功能, 用以维护交换平台的日程运行。

监控管理包括平台监控 (平台自身运行状态的查询和监控) 和交换监控 (对交换业务系统数据交换过程的监控) 。交换监控包括数据流量和状态的查询、统计与审计。交换平台支持主动和被动相结合的多模式交换监控策略, 其中主动监控指交换平台基于节点和交换服务目录, 主动获取相关服务运行状态;被动监控则由部署于交换节点的交换服务主动推送状态信息供交换平台进行交换统计。

中央交换库管理用以实现中央交换库交换数据的存储组织, 数据推送、转发 (经由中央节点下发的数据) 等;并依据交换平台的服务构建指令实现中央交换库交换服务的构建。

日志管理用以记录系统的运行状态, 及时发现运行过程中出现的问题, 并提供日志审核的功能, 形成对交换平台监控的支持。

用户管理用以实现交换平台管理员及数据拥有者和使用者 (数据目录的用户) 的管理功能, 包括对相关用户的权限、角色的分配与访问控制。

4.4 数据目录服务

交换平台提供对数据资源的共享服务功能, 支持数据拥有者将需要交换的数据 (包括中央交换库的数据资源) 发布成为目录服务, 以便数据使用者订阅与获取。数据目录服务包括资源编目, 目录审核、发布和发现等基本功能, 并支持以Web服务和门户等方式向外提供服务。

资源编目用以提供数据资源核心元数据的编辑功能, 并对数据资源核心元数据中的分类信息进行赋值, 实现元数据到交换平台汇集。通过建立相应的审核系统, 平台管理者确认提供者提交的数据资源元数据是符合标准要求的, 审核通过进行入库操作, 未通过审核的元数据返回给提供者修改。平台管理者通过部署于中央节点的目录服务器, 把数据资源核心元数据发布到交换门户系统上, 实现数据目录的发布。目录发现用以为应用系统提供标准的调用接口, 支持公共资源核心元数据的查询;提供无关键字的目录浏览、单条件的快速定位和多关键字组合的精确定位等方式的多途径目录内容查询。

5 交换平台的交换服务建模

通过交换服务建模, 后续构建的交换业务系统可以充分利用已有交换软硬设施, 保证交换平台具备“生长”能力, 例如水资源项目已建设部署有Tong DXP, Tong GTP和Tong Link Q等交换软件和相应的服务器, 后续的交换业务系统可以通过交换服务配置继续使用上述软硬件设施, 只需要通过交换平台进行服务配置即可达到快捷构建交换解决方案的目的。通过配置构建满足不同类型数据的不同周期、频次数据交换的需求, 以保证交换平台能够适应水利交换业务节奏。

交换服务的建模过程如下:

1) 获取交换节点服务能力。要构建相应的数据交换服务, 需要先判断相应的交换节点是否具备相应的数据交换能力, 即交换节点是否具备相应的交换软硬件设施, 交换平台管理员根据交换业务需求, 通过交换节点管理功能查询交换节点目录, 获取数据交换源和目的节点的交换服务能力。

2) 生成交换服务配置指令。基于交换源和目的节点的交换服务能力, 交换平台管理员结合交换需求生成交换服务配置命令下发给交换源和目的节点, 并将数据交换服务注册到交换服务目录中, 等待交换节点进行交换服务构建。

3) 构建交换服务。交换源和目的节点的管理员根据交换平台下发的交换服务构建指令, 基于交换平台的交换服务接口规范构建相应的交换服务, 并将所构建服务的信息反馈给交换平台。

4) 发布交换服务。交换节点依据指令建立交换服务后, 交换平台管理员对构建的服务进行形式化审查 (服务参数、时空范围值域等) , 审查通过后发布成为交换服务目录, 构建起交换节点的数据交换能力, 逐步丰富交换平台, 形成对“可生长”交换模型的支持。

通过交换服务建模形成丰富的交换服务目录, 数据拥有者可以通过交换平台的交换节点和服务的查询服务等功能, 获取交换节点具备的数据交换能力和相应的交换服务接口参数, 进而完成数据推送。同样的, 数据使用者可以查询交换节点的交换能力和服务接口参数进行数据的拉取。

6 结语

随着国家防汛抗旱指挥系统 (二期) 、国家水资源监控能力建设项目等的开展, 水利大数据时代已经到来, 大数据时代下, 如何通过数据交换实现水利数据中心“三级两域四区”大规模数据资源的自由流通, 是水利信息化建设必须破解的难题。本文从水利数据中心数据交换的需求出发, 总结多年来水利信息化实践经验, 对水利数据交换平台的设计进行探讨;为建设统一规划的数据交换平台, 实现水利大数据的深度利用迈出坚实的一步。

水利数据交换是一项系统工程, 交换平台的建设仅仅是万里长征的第一步, 如何保障数据交换常态化进行是关键, 后续需要针对具体的交换需求和数据资源构建交换服务, 充实数据目录, 完善管理机制和规章制度等。

参考文献

[1]中华人民共和国工业和信息化部.国家电子政务“十二五”规划[R].北京:中华人民共和国工业和信息化部, 2009.

[2]水利部水利信息化工作领导小组办公室.水利信息化顶层设计[R].北京:水利部水利信息化工作领导小组办公室, 2009.

[3]艾萍, 吴礼福, 陈子丹.水利信息化顶层设计的基本思路与核心内容分析[J].水利信息化, 2010 (2) :9-12.

[4]水利部水利信息化工作领导小组办公室.水利信息化顶层设计初探及进展[J].中国水利, 2009 (8) :8-10.

数据交换平台 第5篇

目前成熟的数据导入导出工具比较多，但是一般都只能用于数据导入或者导出，并且只能支持一个或者几个特定类型的数据库。这样带来的一个问题是，如果我们拥 有很多不同类型的数据库/文件系统(Mysql/Oracle/Rac/Hive/Other)，并且经常需要在它们之间导入导出数据，那么我们可能需 要开发/维护/学习使用一批这样的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader /mysqldumper)。而且以后每增加一种库类型，我们需要的工具数目将线性增长。(当我们需要将mysql的数据导入oracle的时候，有没 有过想从jdbcdump和dbloader上各掰下来一半拼在一起到冲动?) 这些工具有些使用文件中转数据，有些使用管道，不同程度的为数据中转带来额外开销，效率差别很非常大。很多工具也无法满足ETL任务中常见的需求，比如日 期格式转化，特性字符的转化，编码转换。另外，有些时候，我们希望在一个很短的时间窗口内，将一份数据从一个数据库同时导出到多个不同类型的数据库。 DataX正是为了解决这些问题而生。

(问题: 新增第n+1个数据源，是不是要新开发n个数据同步工具 ?)

我们只需要针对新增的数据源开发的一套Reader/Writer插件，即可实现任意数据的互导

南京企业信息交换平台的征信策略 第6篇

建设社会信用体系，是完善市场

经济体制的客观需要，是整顿和规范市场经济秩序的治本之策。南京市企业信用信息系统建设中信用信息征集是首要环节，但随着全市信用平台建设的不断推进，信用信息征集共享工作所面临的困难也很快暴露出来。企业信用信息征集难，信息分散在各个部门、行业和机构，由于政府信息公开共享的制度不够完善，共享机制不够健全,制约了信用建设的发展。

为此，南京市企业征信采取“法律主导、政府推动”的模式，搭建起南京企业信用信息交换平台，提高了信用信息系统的联合监管和服务水平，也促使企业增强信用观念，营造诚信为本、操守为重的社会信用环境。

企业信用信息征集策略分析

(一)企业信用信息联合征集指标项的确定

企业信用信息征集难。信息分散在各个部门、行业和机构，由于政府信息公开共享的制度不够完善，各信息主体对于企业信用信息的认定有所分歧；其次是数据处理难。由于南京市企业信用信息系统尚未制订相应的数据规范，因此对同一信息概念，不同部门、机构的信息系统都对其进行了重新定义，但定义并不完全一致，如对企业名称的定义，工商部门称“企业名称”，金融机构称“借款人名称或单位名称”，组织机构代码库称“组织机构名称”。在信用平台将不同信息主体的信息整合过程中，如果来自不同机构的信贷数据整合错误，将严重影响信用信息的准确和完整，制约数据质量的提高，使得企业信用档案无法全面客观地反映被征信主体的信用状况。

结合实际情况，南京市对南京近20个部门进行指标项的重新梳理和确定，确定了5项部门共性数据项（包括企业主体标识信息、企业证照资质信息、行政强制信息、行政处罚信息、企业表彰信息）、公共（企业）事业数据项和省公共信用信息系统第一批归集数据项等相关企业信用信息征集指标项，通过指标项的确定以及各部门间相互协作，在信用信息系统建设中各部门能及时、准确、完整地向市公共信用信息系统提供信用信息。企业信用信息联合征集指标项的确定，对企业信用信息征集的范围要有明确的要求。（详见附件1：《南京市企业信用信息联合征集指标项》）

(二)企业信用信息的共享机制与渠道问题

企业信用信息只有实现共享才能发挥其应有作用，起到促进提高企业信用的目的。从理论上分析，企业信用信息共享主要依靠以下几种机制：一是信用信息的自愿共享机制，即由拥有信息的企业自己对外披露，如企业身份、资质、信用优良信息等一般可依靠企业自愿披露；二是信用信息强制共享机制，即由法律或规章授权某国家行政机关公布有关信用信息，如吊销营业执照、假冒伪劣产品等。这类信息失信企业是不会自行公开的，必须依靠国家行政机关的权力，实行强制公开；三是机构互惠共享机制，如不同银行之间可以实行团体互惠共享各自收集的企业或个人信贷信息。在企业信用信息公开意愿上，不同的信用信息具有不同的公开意愿，对于企业有利的信息公开意愿最高，而负面信息则公开意愿最低，甚至抵制公开。因此，企业信用信息共享机制的建立就是要根据不同性质的信用信息，选择合适的共享机制，构筑不同的信用信息共享渠道，促进企业信用信息的公开。结合目前归集的数据和市信息中心对其数据处理情况，南京市制定了公共信用信息交换机制。（详见附件2：《南京市公共信用信息交换机制》）

(三)企业信用信息共享中的时效性问题

企业信用信息的有效性与具体时间有着密切关系，不同类别的信息具有不同的时效特性。有的信用信息具有较长的时间效应，如企业身份信息，其注册资本、公司住址、经营范围等一般变化不大，长期保留不会丧失时效；有的信用信息则相反，时间效应较短，如某公司资信状况被评为“AAA级”，这一信息只能表示当年的状况，甚至当时的情况，对一段时间以后可能完全失去其参考意义；还有的信用信息，不仅时效短，而且长期保留还不利于企业信用行为的改善。假如某个企业在历史上曾有过作假的行为（如假冒伪劣或逃废债务），若该企业的信用信息记录上长期保留该信息，则历史的不良信用信息肯定会给该公司的各种营业活动带来不利影响，企业将会陷入一种“一失足成千古恨”的绝望境地。面对无法挽回的信用，企业要么选择破产，通过重新注册而改变身份，摆脱历史信用问题的负面影响；要么抱着“破罐子破摔”的心态，放弃改善信用的努力。因此，长期保留企业历史上的不良信用信息并不是最优的制度安排，应该给予企业有“悔过自新，重新做人”的机会。正因如此，目前世界各国的信用信息共享制度中，都不同程度地规定了信用信息的时效。也许，信用信息的时效应根据经济环境和法律环境来确定，如果经济环境不够成熟，企业平均寿命相对较短，在不违背法律规定的前提下，信用信息时效偏向于采用较短的时间；同时，优良信息保留的时间应适当长于不良信息的保留时间，以满足企业对信用不良羞涩感的认知。

(四)企业信用信息共享中的商业秘密保护问题

企业信用信息共享意味着一个企业的信用信息会通过一定的途径或渠道为另一个企业所得知，于是就产生了一个问题，如果信用信息中包含了某些商业秘密，那么在企业信用信息实现共享的同时就可能造成企业商业秘密的泄露。造成商业秘密泄露的可能性取决于两个方面，一是企业信用信息中是否包含商业秘密；二是披露的包含商业秘密的信息是否足以造成商业秘密泄露。法律规定的商业秘密主要包括技术信息和经营信息两类，其中经营信息包括了企业采购计划、供应商清单、销售计划、销售方法、会计财务报表、分配方案等公司内部文件。按商业秘密的法律理解，显然公司财务信息是属于商业秘密，也正因为如此，国内有些会计专家已经呼吁“上市公司会计信息强制披露应该适度，不应侵害公司的商业秘密”。当然，这样的观点也给人们另外一个相反方面的启示：尽管财务信息（包含会计报表在内）是从属于商业秘密范畴的，但适度的披露可能不会造成商业秘密泄露的后果，否则，上市公司披露会计信息就属于违规之举了。南京市赞同财务信息适度共享的观点，通过财务指标的简化，适当限制报表公开范围、公开时间、采用不同审计要求等来调节财务报表的信息含量，做到在实现信用信息共享的同时保护商业秘密。 　　企业信用信息共享对促进企业信用的提高具有非常重要的作用，而要实现企业信用信息共享，不仅要解决共享内容、共享机制、共享渠道、共享时效，以及共享与保密等理论问题，还必须加强企业信用宣传，改变企业管理层的信用观念。

构建企业信用系统交换平台建设

通过上述的策略分析，在已有信息化建设的基础上，南京市决定构建一个共享的企业信用信息交换平台

2006年，按照国家四部委联合文件通知的要求，由市信息办牵头，市工商、质监、地税、国税和市信息中心联合承担建设了“南京市企业基础和信用信息交换平台”。该平台按照国家要求设计了4部门约200多项指标的信息，系统运行至今，已比对基本形成了全市的企业基础信息，归集了注册、年检、注销、涉税等企业动态信息23万条记录。

2007年，南京市构建权力阳光运行机制，并建设了“权力阳光”系统平台，到目前为止，已有全市52个部门、13个区县加入平台，实现了依法行政、规范运作和实时监管。

为了避免重复建设，充分利用资源，南京市将通过上述两个系统的数据来构建南京企业信用数据库。上述两个平台的建设和运行，为南京市企业信用平台的建设提供了比较成熟的技术基础和扩展条件，同时也积累了大量的涉信信息资源，有了一定的基础。但是，相对于企业信用信息的融合度不高，对单一企业实体对象而言，各部门的信息未能归集统一，综合应用面受到局限，协同监管存在一定的障碍，迫切需要统筹协调，形成比较完善的企业信用信息归集一体化的数据体系。

南京市将“企业基础信息交换系统”（该系统数据来源于工商、地税、国税、质监四个部门）中的所归集的23万家企业入库（每条信息包含企业名称、企业组织机构代码等关键字段）作为企业信用信息的基础类核心内容。“权力阳光信息系统”中的行政事项都是各部门花费大量精力梳理，并经过法制办和监察部门审核通过的。其涉及企业的审批和处罚等结果信息，则将该系统的处罚信息通过关键字段比对与企业基础类信息进行关联。

“企业基础信息交换系统”中已经比对成功的企业户数已达23万，数据质量是比较高的。但需要进一步提高企业的户数，使得全市的企业和机构完全纳入。

由于“权力”的结果信息必须与基础信息相关联，因此，能否比对成功是汇集能否成功的关键。南京市通过以下几项比对规则对数据进行了比对。

（1）权力阳光系统中的组织机构代码与企业基础信息数据库中的组织机构代码比对；

（2）权力阳光系统中的申请者（企业名称）、处罚当事人（企业名称）与企业基础信息数据库中的企业名称进行比对；

（3）权力阳光系统中的申请者（自然人名称）、处罚当事人（自然人名称）与企业基础信息数据库中的法人代表进行比对；

（4）权力阳光系统中的申请者地址与企业基础信息数据库中的注册地址进行比对。

所有这些，都是企业信用信息征集的相应策略在实际（南京企业信用系统平台建设）工作中的具体应用。在实际操作中，仍存在不少问题值得人们去思考研究，比如，由于某些部门不规范因素，导致编码不唯一等。总之，企业征信业是社会信用体系的重要组成部分，对完善市场、促进经济发展有着重要作用。因此，发展和完善企业征信业刻不容缓。

（附件《南京市企业信用信息联合征集指标项》和《南京市公共信用信息交换机制》详见本刊网站www.chinaeg.gov.cn）

数据交换平台的研究与设计 第7篇

数据交换平台可以帮助企业提高其各项工作的信息化、自动化程度, 提升企业在其领域的影响力和和号召力。由于数据交换平台系统体系结构的设计没有一个严格的标准, 所以各企业部门之间的系统都存在的一定的差异, 导致各个系统架构之间的交互非常的复杂和困难。

最初的数据交换系统没有一个数据交换的标准的接口, 因此各种数据的交换需要很大的开销。为了将某一种行业数据转换到不同的系统中, 可能需要将实现这一数据的处理和格式化过程的操作多次使用不同的方式实现, 造成数据转换的效率非常的低。

数据交换是一种计算机应用技术, 按照用户提前的约定, 按照规定的形式将数据信息进行相应的处理, 然后通过计算机网络将处理后的数据在网络上的各个系统之间进行相应的转换后处理。数据交换平台系统应能够为用户提供可靠的参考数据服务, 确保各个交换系统之间能够共享所有信息, 并且各个系统之间的数据交换不需要进行复杂的格式变化或转换。

1 数据交换平台设计

1.1 数据交换平台设计目标

数据交换平台必须能够为企业中各种数据的转换提供良好的接口, 为用户提供最优的交互视图、因此数据交换平台的设计必须实现一下几个目标:1) 数据交换平台系统必须能够提供给用户友好的操作界面, 并保证各个系统之间数据转换的调度能够更加的快捷和方便;2) 数据交换平台应该能够确保各个系统之间的数据转换和参数的传递能够有一个统一的标准, 避免同一数据的转换代码需要多次重复实现;3) 必须降低客户端与其所访问的相关服务系统之间的依赖性, 提高各个数据转换接口的通用性;4) 使用不同的网络适配器实现各种类型客户端的跨越式访问。

1.2 数据交换平台系统设计

1.2.1 系统功能设计

根据需求, 系统的功能分为基础功能与适配器, 如图1功能结构图所示。其功能主要包括基础功能、适配器两部分:其中适配器主要是完成异构的数据源与平台的数据的交互以及进行数据的加密、解密等操作。

1.2.2 路由管理模块

路由管理是对系统中各个节点的执行过程进行合理的控制, 确保每个节点能够按照规定的顺序进程相关工作, 从而由此完成系统中的数据转换的重要任务。用户在进行路由管理时还可以根据自身需求定义嵌套的路由, 即数据交换平台中的节点在完成自身工作后内部所需进行的进一步的操作。本文数据交换平台的路由管理模块的用例图如图2所示, 它需要完成以下几个方面的工作:

1) 通过使用POST方式取得客户端提交的信息, 然后利用数据库插入操作INSERT语句将信息保存到相应的数据库表中;

2) 必须能够使用文件传输协议下载服务器站点中的数据, 并使用INSERT语句将下载的数据插入到规定的数据库文件中;

3) 利用SELECT查询语句将数据库对应表中的信息读取出来, 并且能够使用文件传输协议将数据库文件上传到所需服务器站点;

企业数据交换平台中存储的有些数据信息可能是行业秘密, 因此必须保证其安全性。每个企业为了确保数据交换平台的安全, 可以对其进行不同的用户权限设置。如必须企业内部的网络地址才能够访问, 禁止任何外部用户的使用和访问。与此同时, 可以根据企业中每个工作人员的职能的不同, 对其授权的权限也要有规定。防止某些人员的恶意操作, 禁止普通员工浏览一些密级高的数据资源。

4) 适配器设计。适配器是各种不同的数据交换平台之间进行数据交换的桥梁, 一个设计合理的适配器能够方便、快捷的完成不同的数据交换平台之间数据和服务之间的转换。适配器将由业务系统所采集的数据信息进行提前的处理, 从而将采集的数据转化为统一格式, 最后提交的数据交换引擎进行进一步的处理。

下面将对适配器基类Adapter.cs的设计进行详细的说明。

所有适配器的公共接口, 每一个适配器必须实现它。在实际开发中会有Adapter抽象类实现此接口, 每个适配器只需继承Adapter抽象类即可。本文中接口定义为IAdapter, 其中Config Des是适配器的Config配置字串;Input Des描述一个适配器的输入参数字串等。Adapter是定义的适配器的类, 每个适配器必须继承它, 此类实现I-Adapter接口。

Excute () 方法:该方法是一个虚方法, 其目的是将形参中的o Input对象传递至具体的适配器, 再去调用具体适配器中指定的适配方法, 将适配方法返回的值转换为object返回。

Standar Excute () 方法:此方法是系统中标准的用于调用具体适配方法的虚方法。

if (i Input!=null&&i Input.Struct!=空&&i Input.Data!=空) this.In-put=i Input;

检查this.Config、this.Input中的数据格式是否正确, 若不正确则返回一个空的Adapter Out Put对象。若正确执行下面的流程。

Invoke Adapter M ethod () 方法:它是一个非虚的保护方法, 作用是调用当前应用程序域中指定的方法。利用反射技术来调用s_a M ethod方法, 并将args参数传递过去。

Add Exception () 方法:将形参中的O_a Exception添加到异常列表 (arr_Exception) 中。此方法的意图是:在具体适器上执行时若发生异常, 不要将异常直接throw出, 而是将异常信息存入AdapterOut Put对象的异常列表中。若是重大异常则返回Adapter Out Put对象, 否则继续执行。不要将异常直接抛出的原因是:如果部署为SOA架构Client端与服务器端是网络分布, 若将服务器端的异常throw出, 那么Client端将会一直等待, 若Client端没有捕捉异常会导致错误。

2 结论

本文通过对数据交换系统研究现状的分析, 提出了现有系统所存在的问题, 继而引出了本文的设计。对系统功能进行了设计, 保证了系统的实现功能和数据结构的合理性。

本文系统的设计从数据交换平台的需求出发, 结合目前流行的xm技术实现信息与平台的无关性, 从而很好的解决了异构平台之间的数据交换和数据共享的问题, 使得各个部门能够采用相同的标准进行数据的交换与共享。

摘要：为了解决传统的数据交换平台系统复杂度和可扩展性的问题, 提出了基于XML的数据交换平台模型。XML提高了数据交换平台的通用性和可扩展性本文, 并对该模型进行了详细的分析。

关键词：数据交换平台,XML,数据交互

参考文献

[1]范玉顺, 胡耀光.企业信息化战略规划方法与实践.电子工业出版社, 2007.

[2]科林, 格雷戈里.企业门户:构造企业的信息平台.中国金融出版社, 2003.

[3]崔有利, 崔宏阳.B/S模式应用系统的一种新型结构及实现.计算机应用研究, 2001.

[4]闪四清.数据库系统原理与应用教程.清华大学出版社, 2001.

[5]马军.精通ASP.NET 2.0网络应用系统开发.人民邮电出版社, 2006.

[6]张树亮, 李超.基于.NET Framework的网络应用系统开发案例精解.清华大学出版社, 2006.

[7]刘亮亮, 潘中强.精通ASP.NET 2.0.人民邮电出版社, 2008.

电子政务平台数据交换系统研究 第8篇

1 目前电子政务平台数据交换系统存在的问题

我国电子政务在20年的时间里,经历了一个内涵不断丰富、地位不断提高、作用不断增强的发展过程。20年的电子政务发展虽然促成了一个繁荣的IT市场,但带给我们则是更多的启示和反思。虽然各级政府都大力推进了信息化建设,但有效信息的利用率低,政府部门内部以及部门之间信息衔接不紧密、信息汇总与实时的综合处理能力弱,“信息孤岛”、重复建设、资源浪费、共享程度低、标准不统一等现象仍然比较突出,已成为我国电子政务建设中共性的关键性问题。其主要表现在以下方面:不同应用系统,数据库之间的数据交换问题;异构数据转换即不兼容的数据格式问题;支持多种协议的问题;工作流的设计问题[5,6,7,8,9]。为解决现有电子政务系统中存在的问题,同时也为了提高系统的扩展性,必须研究数据交换系统。

2 萍乡市政务网数据交换系统设计与实现

萍乡市作为首批入选我国智慧城市试点名单的城市,根据国家“智慧城市”创建任务书要求,要依托萍乡市城市发展现状和规划,打造城市公共信息平台和城市公共基础数据库等基础性的智慧工程,构建智能、协同、高效、安全的城市公共信息服务体系,由此更加迫切需要建设全市的公共数据交换系统。

2.1 系统架构(如图1所示)

为了彻底实现数据的共享与完善,在数据交换系统建设之初,必须明确系统所要实现的功能,功能明确了,平台的建设就明确了方向,就明确了数据交换系统建设的最终目的。

(1)数据交换系统的建设目的之一就是实现不同系统之间的通信需要,建立智能数据交换平台的首要目的就是实现各种各样的不同系统平台间的不同类型数据之间的信息传输与信息交流,实现不同平台的不同形式的数据之间的整合与综合利用。要实现数据交换平台的异构数据之间的数据共享,必须建立交换信息平台之间的信息接口的对接与交流,对信息系统之间的信息共享与提取提供可能。

(2)利用数据交换平台建设,顺利实现数据之间的相互转换,对来源于不同系统的相互异构的数据进行相互的转换与调整,最终实现数据的相互通用,利用一种通用的格式实现数据的相互统一,实现资源的充分可比,实现信息资源效益的最大化。

(3)利用数据交换平台的建设,在充分利用数据信息的基础上,实现提高数据安全性能的目标,使不同类型的数据共同存放在一个第三方的安全性能比较高的数据管理平台中,按照不同级别的公开性程度,进一步实现数据的有效、安全管理,成为数据平台建设的一项十分有意义的工作。

(4)利用数据交换平台建设,加强用户对数据的管理职能,通过加强用户对数据的管理,增强数据的有效性和可靠性的保障,以达到实现数据管理的最终目的,实现数据应用性的最大化保障,提升数据的可应用性与可操作性,加强用户对数据的及时更新和管理[10,11]。

2.2 功能要求

2.2.1 平台交换形式要求

支持不同的网络环境之间的交换,支持两类数据传递方式:实时类型的数据传递方式和持久类型的数据传递方式。部门之间数据的实时交换(Web Service、接口调用),包括应用系统之间调用Web Service交换,交换平台代理Web Service交换以及系统之间调用API交换,适用于信息比对、查询服务等数据量较少的场景。

(1)包交换。

目前交换平台主要的交换模式,结构化数据或非结构化数据以包的形式从一个应用系统前置机交换至另一个业务前置机。

(2)资源目录。

以资源目录的方式按需要驱动数据交换,省略手动配置交换流程。

2.2.2 平台交换数据类型要求

(1)结构化数据。

指存储在各类数据库里,可以用二维表结构来逻辑表达实现的数据。一般得应用系统进行对接都是采用结构化数据,可以进行条件筛选,应用程序可以直接取用,监控统计可以精确到条。

(2)非结构化数据。

指图形文件、音视频文件、文本文件、超过2G大文件及条数多数据量较大(如阳光医药的医院用药数据就是结构化数据打包成文件)的交换需求。

2.2.3 平台交换数据业务要求

(1)一对一交换。

数据只需从一个系统交换到另外一个系统。如对于市发改委来说,审批数据从发改委业务系统交换至审批系统就是一对一交换。

(2)一对N交换。

数据从一个系统交换到多个系统。如交通车辆信息需同时交换至市公安局和市国安局。

(3)N对一交换。

数据从多个系统交换到一个系统,如企业社会联合征信系统,多个部门将企业基础和信用信息交换至征信系统中。

(4) M对N交换。

数据从多个系统交换到多个系统。如工商、地税的数据都同时要交换至审批系统和征信系统,就是这种模式。

2.2.4 其他公共功能要求

数据交换平台还要具有可扩展能力、提供隔离能力、提供有效的安全管理功能、方便的系统管理能力。

2.3 系统构成

(1)资源管理。

该模块主要为各部门提供可共享信息的注册、发布、审核、订阅功能。

(2)配置管理。

该模块为参与交换的各物理节点、交换业务应用域、部门前置、数据源等基础设施提供注册、设置、配置、管理功能。以保障数据交换平台的搭建和交换任务能顺利完成。

(3)业务管理。

该模块能按不同的角色(如平台管理员和业务域管理员管理),管理不同的业务域。并在不同的业务域中进行不同交换任务的创建、设置、启停等操作,支持多业务、多个交换任务同时实施。

(4)监控管理。

该模块提供了物理节点监控、业务域监控、交换过程监控、数据交换统计、预警规则、参数设置等功能。物理节点监控,可以对参与数据交换的各物理设备中CPU、磁盘空间、内存等资源使用情况进行预警和监控;业务域监控,可以从不同的业务域管理员视角对各自业务域中的交换任务状态、交换数据量、交换频率等健壮情况进行预警和监控;数据交换统计功能,实现了从宏观数据交换量的统计到微观交换任务数据包的状态查询功能。

(5)系统管理模块。

该模块主要提供对平台相关的基础数据维护管理功能。如组织结构、用户、权限、授权等。

3 结论

电子政务平台数据交换系统通过对应用需求和业务场景的梳理与归纳总结,在建设思路和技术架构方面进行了大胆的尝试和创新,开创性地采用了虚拟交换子平台模式与技术,实现了在同一物理交换平台上支持多个业务应用系统的跨地区、跨部门、异构系统的数据交换,突破传统数据交换平台建设的局限,实现与资源目录体系无缝对接,为全市政务信息资源的充分共享和高效利用提供了可靠的技术支撑。

参考文献

[1]王长胜.中国电子政务发展报告No.3[M].北京:社会科学文献出版社,2006.

[2]张繁.蔡家楣.电子政务系统中的数据交换和共享服务平台设计[J].计算机工程与应用,2003(7):226-229.

[3]高云君,张学杰,章方铭.XML技术在电子政务信息交换中的应用研究[J].计算机应用,2003($2):170-172,179.

[4]赵亮.面向整合的基础架构软件平台的开发与应用[D].上海:复旦大学,2005.

[5]江涌.于建武,刘镇,李征.电子政务系统中数据交换平台设计[J].计算机技术与发展,2008(7):218-221.

[6]刘源,姚淑珍.XML的关系化存储及与关系数据库的数据转换[J].计算机工程与设计,2004(11):2039-2043.

[7]庄子明.基于XML的数据库技术及应用[J].计算机工程,2002(1):120-122.

[8]常雪琴,王玉珍.基于云计算的电子政务平台建设研究[J].电子商务.2014(4):25-26.

[9]李霞.电子政务与行政管理创新探究[J].电子测试,2014(7):131-132.

[10]王兆宪.基于政务内网的电子政务系统设计与实现[D].长春:吉林大学,2012.

数据交换平台 第9篇

随着物联网技术的快速发展, 以城市消防远程监控系统为典型代表, 以消防设施信息化为主题, 各种类型的信息系统正在不断涌现, 如消防产品身份管理系统、移动消防设施状态监控系统、消防水源状态监控系统。

在物联网的发展背景下, “互联互通、数据共享”的发展趋势要求这些系统除了要实现自下而上的、纵向的、系统内部的数据交换之外, 还要求实现横向的、系统之间的数据交换, 甚至实现与其他消防无关系统之间的对外数据交换, 最终通过逐步建设新的信息系统, 来扩展消防设施信息化的覆盖范围, 达到消防设施全面信息化的目的。

笔者以消防产品身份管理、固定消防设施状态监控、移动消防设施状态监控、消防水源状态监控为典型应用, 介绍集产品追溯、实时监测、整改监督、现场应急等于一体的消防设施综合信息平台的数据交换机制。

1 消防设施综合信息平台的组成

消防设施综合信息平台由消防产品身份管理系统、固定消防设施状态监控系统、移动消防设施状态监控系统、消防水源状态监控系统4个业务子系统和消防部队远程监管系统1个综合应用子系统组成。

(1) 消防产品身份管理系统实现所有消防产品的基础信息管理。消防产品身份是消防产品的登记簿, 即消防产品的户籍, 通过为每一件消防产品赋予唯一的身份号码, 结合通信、网络、数据库等技术手段, 在系统内记载产品的基本信息、生产企业信息, 跟踪其生命周期内各种变更, 包括生产 (出厂) 、安装、维修、维护、报废等信息, 对消防产品进行全生命周期的信息化管理。

(2) 固定消防设施状态监控系统实现对固定消防设施实时状态的远程监控。以城市消防远程监控系统为基础, 将监控范围扩展到火灾自动报警系统、消防联动系统、图形显示装置、消防应急照明和疏散指示系统、消防电源监控系统等建筑内固定安装的电子消防设施。对这些设施的运行状态进行实时采集和远程监控, 在日常状态下, 实现消防设施保养水平的综合评估, 实现隐患设施整改效果的证实, 为所在企业提高消防设施的维护保养能效提供基础数据;在紧急状态下, 除了实现火灾报警信息的快速、完整、精确传输外, 还可以为核实火灾蔓延范围和趋势、联动设备是否触发等提供参考依据。

(3) 移动消防设施状态监控实现对移动消防设施实时状态的远程监控。手提式灭火器、推车式灭火器、消防水带移动式灭火器材, 在企业经营活动中容易出现药剂泄漏、药剂过期、挪动后长期不归位等情况, 通过监测这些器材的压力、质量、所在位置等物理属性, 避免出现灭火器压力不足、质量不足、位置偏移过大等情况, 确保其在紧急状态下可达、能用。

(4) 消防水源状态监控实现水源类消防设施的实时状态的远程监控。系统收集消火栓、消防水鹤、消防水池 (箱) 等消防储备水源的基本信息, 包括地理位置、最大出水流速、最大水压, 并采集消火栓和水鹤的水压、水温, 消防水池 (箱) 的顶部、底部、出水口等位置的水温, 消防水池 (箱) 的水压、水位, 确定其可用状态, 实现集中监控, 在应急状态下, 为火灾现场救援提供可用的消防水源信息。

2 数据开放平台的设计

2.1 总体思路

消防设施信息化建设的现状:固定消防设施状态监控相对成熟, 已在国内大多数城市普遍设立监控中心, 但这些监控中心技术方案互不兼容;消防产品身份管理、移动消防设施状态监控、消防水源状态监控尚处于起步阶段, 部分城市尝试开展相关业务。

此数据开放平台引入了面向服务 (SOA, Service-O-riented Architecture) 的架构技术, 通过异构应用系统的松散耦合和复用, 将各自独立的多个系统整合成互联互通、协同工作的综合系统。一方面能够充分利用企业现有系统, 减少对现有系统的影响, 降低系统整合的风险;另一方面, 通过建立接口规范, 方便未来信息系统对已有系统的重用和集成, 提高企业信息化的投资回报率。

Web服务 (Web Service) 作为SOA的实现方式之一, 利用网络技术对异构、粗粒度应用系统进行分布式部署、组合和使用, 在系统之间定义良好的接口, 接口采用中立的方式进行定义, 屏蔽系统的硬件平台、操作系统、数据库和编程语言差异, 达到异构系统可以采用统一、通用的方式进行交互的目的。

2.2 体系架构

整个平台的体系架构为三层体系结构, 如图1所示, 包括数据资源层、服务层、应用层。在保持固定消防设施系统、移动消防设施系统、消防产品身份系统、消防水源系统内部业务不变的情况下, 分别为这些系统增加用于进行数据交换的Web服务, 将其部署在各自系统内部的服务器或专门设立的服务器上, 并在UDDI注册中心发布服务。该UDDI注册中心为私有UDDI中心, 应用层的各类应用如需获取数据资源层的支持, 或数据资源层的某个系统需要获取同在数据资源层的其他系统的支持, 若自己需要的Web服务地址已知的情况下, 可直接调用服务;若Web服务位置未知或经常变更, 可到注册中心查找自己需要的服务功能, 得到该服务的服务描述后, 根据服务描述定位服务、调用服务。在整个数据交换过程中, 数据资源层各系统内部业务不受影响的同时, 还对外提供数据交换服务, 实现“内部自治、分工合作”。

可以看出, 整个平台的关键是UDDI注册中心和各种Web服务节点。UDDI注册中心只有1个, 为私有UDDI中心, 是数据开放平台的服务索引节点, 负责收集Web服务节点的服务类型和地址等描述信息, 并向各类应用提供查询服务;Web服务节点是在数据开放平台中提供实际数据交换服务的节点, 数量不受限制。

任何可以提供消防设施信息的系统、软件都可以向数据开放平台提供服务, 只需向UDDI中心登记所能提供的服务信息, 即可等待其他应用的调用;任何符合要求的系统、软件都可以从数据开放平台中获取数据, 只需向UDDI中心查询网络中可用的服务节点的服务描述, 便可调用指定的网络节点的服务。

数据开放平台的服务能力依赖于服务节点的数量规模, 通过动态优化服务节点的数量规模, 达到动态调整平台服务能力的目的。

3 数据开放平台的实现

4个业务子系统收集了大量消防设施的基本信息、当前状态信息、历史状态信息, 这些信息除了可以为自己所在系统服务外, 还可用于其他场合。笔者以建立消防部队远程监管系统为目标, 介绍数据开放平台的实现。

3.1 公共数据规范

统一、通用的数据规范是实现数据交换的基础。采用XML语言描述的数据规范可以屏蔽硬件平台、操作系统、数据库的差异。数据规范除了要描述产品、设施的属性和变化外, 还要解决同一产品或设施在不同系统中的对应关系问题。本平台定义的部分规范如下, 与维修保养、全生命周期相关的数据规范不再赘述。

(1) 消防产品身份码编码规范。消防产品身份码是全国唯一识别的, 用于识别任何单件消防产品。消防产品身份码由产品类型码、生产厂家码、生产批次码、产品流水码组成。产品类型码、生产厂家码为全国统一分配, 生产批次码、产品流水码由生产厂家自行分配。

(2) 消防设施身份码编码规范。消防设施身份码也是全国唯一识别的, 与消防产品身份码不同, 用于唯一识别消防设施的安装位置。以此避免由于维修代换而出现在同一位置上具有不同消防产品身份码的多个产品带来的混乱。消防设施身份码由地址码 (采用邮编) 、建筑流水码、消防设施类型码、消防设施流水码构成, 对所有消防设施进行统一编码, 加以区分。地址码、建筑流水码、消防设施类型码、消防设施流水码由同一机构协调分配, 供各应用系统使用, 实现一次分配、到处使用。

(3) 消防产品属性的数据规范。依据消防产品类型的不同, 分别定义用于描述消防产品的物理属性、功能特性的数据结构, 如尺寸、质量、工作电压、功耗、灵敏度等。对于电子类产品, 可利用RFID、二维码等技术, 将产品属性数据固化到消防产品中, 实现就地查询, 也可根据消防产品身份码利用数据开放平台远程查询。

(4) 消防设施状态信息数据规范。依据消防设施类型的不同, 分别定义用于描述消防设施的物理属性、运行状态的数据结构, 如经纬度、温度、压力、火警状态、开启状态等。

3.2 基于Web服务的数据交换接口

基于Web服务的数据交换, 可以屏蔽操作系统、传输协议、开发语言的差异。本平台为4个业务子系统等分别定义了若干Web服务接口, 用以实现数据交换。遵循统一的接口规范的各个应用系统, 可由不同开发商分别开发和建设, 但均可实现系统间的互联互通和等效代换。此平台为前述系统制定的接口可实现以下功能:

(1) 消防产品身份信息系统收集和提供消防产品基本信息, 包括产品类型、生产厂等;跟踪消防产品生命周期内各种信息, 包括生产 (出厂) 、安装、维修、维护、报废等信息。

(2) 移动消防设施监控系统收集和提供灭火器、消防水带等移动消防设施的基本信息, 包括地理位置、灭火剂类型、灭火剂容量等;远程采集和提供这些消防设施的物理属性, 包括位置、压力、质量, 判断其可用状态;提供灭火器压力不足、质量不足、位置偏移过大时的历史告警记录;提供灭火器的充装、灭火器水压试验、灭火器报废等维护流程进行跟踪记录。固定消防设施监控系统的接口与此类似, 不再详述。

(3) 消防水源监控系统收集和提供城市范围内消火栓、消防水鹤、消防水箱等消防水源的基本信息, 包括地理位置、最大出水量、最大出水速度、最大水压;远程采集和提供消防水源的物理属性, 包括温度、水压, 判断其可用状态;提供消防水源供水压力不足、水位不足、温度过低时的历史告警记录;提供消防水源的日常巡查、放水、油漆等维护流程的跟踪记录。

3.3 消防部队远程监管系统

数据开放平台中, 同一类型的数据资源子系统可以有多个, 分别由不同的开发商开发, 由不同的运营商在不同的城市分别建立和运行。消防部队无需自建任何信息系统, 利用前述系统提供的数据, 即可开发和建立消防部队远程监管系统。数据交换步骤如下:

(1) 服务注册。数据资源子系统设计实现的各个Web服务, 采用WSDL描述接口的详细信息包括接口地址、名称、参数等, 并将WSDL描述发布到UDDI注册中心。WSDL是Web服务接口的标准描述语言。

(2) 服务查找。消防部队远程监管系统等根据自己的需要, 在UDDI注册中心收录的Web服务中检索特定的接口, 收到的接口描述信息也采用WSDL进行描述。

(3) 数据调用请求。消防部队远程监管系统等应用根据接口描述信息, 生成调用请求的SOAP消息, 通过HTTP协议发送给接口描述中指定的接口地址, 请求查询 (或修改) 数据资源层子系统内的数据。

(4) 数据结果返回。数据资源层子系统接收到SOAP消息后, 执行消息内指定的Web服务接口, 并将数据查询 (或修改) 结果, 封装成SOAP消息, 通过HTTP协议返回给服务调用请求者。

利用本数据开放平台, 消防部队远程监管系统具有内生界面和数据相分离的特性, 可在智能手机、平板电脑、台式计算机等终端上, 基于Web浏览器的统一界面, 实现产品追溯、实时监测、整改监督、现场应急等操作。

消防部队监管系统通过调用各资源子系统的数据, 可以随时随地查询不同消防重点单位的固定消防设施、移动消防设施、消防水源的基本信息、历史动态、维修保养的详细记录, 查看异常消防设施的整改情况。

最主要的是, 消防部队监管系统通过对各子系统数据的综合利用, 还可实现按时间、地区、主管单位进行分类汇总、对比分析;实现消防设施的运行完备度、维保效率的综合评价, 并参与区域火灾风险指数的成分运算;在火灾扑救过程中, 可实时调用各种消防设施的可用状态, 并根据这些状态信息, 结合消防水源位置, 为火灾现场救援提供可用的消防水源信息, 按照作战计划中提供的出水枪位置、出水量要求、出水压力要求、出水速度要求, 生成推荐消防水源接入表。

系统的大范围、长时间运行, 可以运用大数据技术, 收集火灾报警设施、联动设施的触发和动作序列, 经汇总、分析、挖掘后, 发现消防设施在应急状态下的全局性运行规律, 用于科学研究。

4 结论

此数据开放平台采用基于Web服务的数据交换机制, 在实现异构应用系统的松散耦合和复用的同时, 采用XML、HTTP等标准化的技术, 实现界面和数据分离, 具有兼容能力强、易于扩展等特性, 可以提高消防设施信息化的开放性, 实现消防设施信息的“一次录入、终生使用”、“一处录入、到处使用”, 建立不同业务系统之间“内部自治、分工合作”的机制, 通过系统间合作与复用, 降低系统集成的风险和门槛, 为消防设施的全面信息化建立网络化协同工作平台, 加快消防设施的信息化速度。

参考文献

[1]李志刚.消防远程监控系统发展方式的建议[J].消防科学与技术, 2011, 30 (9) :857-860.

[2]GB 26875, 城市消防远程监控系统[S].

[3]GA 846-2009, 消防产品身份信息管理[S].

[4]赵杰, 徐峰, 单联海.智能消火栓实时远程监控系统:中国, CN203400449U[P].2014-01-22.

数据交换平台 第10篇

OFDM-MIMO技术被认为是未来4G核心技术[1,2],数据交换模块是MIMO平台基带部分的核心模块,它为空域模块与通道模块之间提供控制与交换信号,协调各模块之间正常运行。数据交换模块的性能直接影响平台性能。在众多方案中择优选取,本平台采用DSP+FPGA方案实现,既保证资源的充足性,又提高了模块的通用性。

1 数据交换模块介绍

基站的基带模块总体上分为上行链路和下行链路每条链路都通过网口等接口与上位机相连。下行链路包括一个下行空域处理模块,一个下行数据交换模块和四个下行通道模块,分别对应4个发射天线;上行链路包括一个上行空域处理模块,一个上行数据交换模块和四个上行通道模块,分别对应4个接收天线。上行或下行链路的六个模块分别通过各自底板上的AT BUS总线相连,基于该总线结构根据处理的复杂度选择算法。基带部分组成及数据交换模块位置示意如图所示

实验平台在系统结构上采用两级结构,数据交换模块处于第一级位置,空域处理模块和上下行通道模块位于第二级位置。数据交换模块是系统的中心,主要功能是进行数据的交换调度:在系统正常工作时,控制通道模块、空域处理模块和上位机之间的数据传输,在下行链路中,数据交换模块把下行空域处理模块送来的用户数据整理成每个通道模块要发送的数据,然后传递给下行通道模块,经其处理后发送出去;在上行链路中,每个通道板所接收到的信号都包含了当前所有用户的信息,和其余三个通道交换数据“互通有无”,获得空域处理所需的完整的用户信息。其次,还可以通过串口或并口接收上位机的指令,然后控制空域模块和通道模块的初始化。此外数据交换模块还为空域和通道模块提供时钟、同步信号和其它控制信号,以协调它们工作。

两级结构为信号处理算法的实现提供了更大的灵活性,尤其是为信号的降维处理提供了可靠的硬件基础。系统不仅对信号做空域处理,还要进行频域、时域乃至码域的处理。虽然在MIMO系统中,采取多维联合信号处理的方式会使系统的性能优异一些,但处理复杂度明显增加,运算量加大,在天线数增多或是时间增长的情况下,会成几何倍数增长,有必要先对信号进行降维处理,把信号由多维处理分解为几个级联的低维处理来解决。数据交换模块在完成控制和数据交换调度任务的基础上,为空域处理模块和通道模块分担一些算法,比如说空时编码译码、训练符号定位和符号映射等[3],这样可以比较有效地减轻空域处理模块和通道模块的计算压力,在一定程度上提高了系统的实时性和数据传输率。

硬件设计上,采用基于DSP+FPGA的硬件结构。实验平台的基带部分共有上、下行两个数据交换模块,虽然在上下行链路中,数据交换模块所担负的任务并不相同,但是立足于建立一个通用的、模块化的实验平台,因此两个数据交换模块在硬件结构上设计完全一致,只是通过编写和加载不同的软件来赋予上、下行交换模块各自应该担负的功能。

2 下行链路交换调度策略与实现

多发多收模式下,为了提高数据传输效率,下行链路采用异步的、并行的数据交换调度策略。如图2所示。

多发多收模式下行链路的数据交换调度策略,当4个下行通道模块的FIFO都为空时,把标志b2置为有效;当DSP进行4个EDMA传输,把算法处理后的数据依次写给4个下行通道模块中的FIFO后,才把标志c2置为有效。并在交换调度策略中增加查询机制:数据交换模块的DSP不仅要知道4个下行通道模块的4个FIFO总体的状态,还必须知道每一个下行通道模块FIFO的状态。把4个下行通道模块送来的中断请求信号BINT0、BINT1、BINT2和BINT3通过FPGA分别连到DSP的4个GPIO管脚,同时在FPGA中逻辑或,逻辑或的结果通过GPIO6送到DSP。增加查询机制,实验平台的运行更加可靠,即便某个通道模块发生故障,其它通道模块仍可以正常收发为了简化逻辑并保证数据传输的可靠性,在多发多收模式下数据交换模块采用DSP通过FPGA直接面向空域模块和通道模块共5个FIFO的模块间接口设计方案[4]。其简化电原理图如图3所示。

FPGA把DSP的EMIFA口的输出时钟分配给空域模块和4个通道模块,因为下行链路是从下行空域处理模块中读数,所以FPGA把与读有关的控制信号以及CE2地址空间分配给下行空域模块,由于数据交换模块把读到的数据处理完还要发给下行通道模块,所以FPGA把与写有关的控制信号分配给4个下行通道模块。4个下行通道模块共享与FPGA之间的数据总线,必须用4个片选信号让它们对数据总线分时复用。把CE1地址空间分时分配给4个通道模块,即把ACE1信号分成BCE0、BCE1、BCE2和分时片选个下行通道模块实现的方法是把DSP的两个GPIO管脚GPIO2和GPIO7连接到FPGA,然后在FPGA内部设计个地址译码器,经过译码后分别选通CE1[5]。

在多发多收模式下,必须保证所有的下行通道模块同时发射。下行通道模块设计两个FIFO,一个专门用来接收数据交换模块发来的数据,另外一个用来存放经DSP处理好后准备给数字上变频芯片AD9857发送的数据。使FPGA READY0、FPGA READY1、FPGA READY2和FPGA READY3四根信号线接收4个下行通道模块发来的中断请求信号BINT0、BINT1、BINT2和BINT3。为了保证发射同步START信号是必需的,这个逻辑信号用软件实现,实现方法是:在数据交换模块确信4个下行通道模块的FIFO都为空后,准备依次给它们发数之前,DSP先把通用输入输出管脚GPIO0置高电平,开始EDMA传输的时候再把该管脚置低,这个脉冲经过FPGA的IO管脚后作为START信号送给4个下行通道模块,4个下行通道模块收到这个START信号后同时使AD9857之前的FIFO为其发数,这样每个下行通道模块中的基带数据被同时上变频,就可以做到同时发射。

3 上行链路交换调度策略与实现

在多发多收模式下的上行链路中,数据交换模块同样采用异步的、并行的数据交换调度策略。如果DSP的GPIO管脚资源够用的话,该策略也可以增加查询机制,在一定的时间范围内查询哪些上行通道模块的FIFO满,超出查询时间如果还有某个通道模块的FIFO不满,则认为该通道有故障,DSP就会放弃从该通道读数。

该策略下具体的数据交换调度流程可以参照下行链路,具体调度策略如图4所示。

具体硬件实现上,上行链路与下行链路也具有相似性,对比下行链路简化电原理图,区别在于FPGA把与读有关的控制信号分配给了4个上行通道模块,把与写有关的控制信号分配给了上行空域处理模块,另外数据总线的方向也发生了变化。在多发多收模式下,上行链路简化电原理图如图5所示。

START信号用来控制四个上行通道模块同时进行下变频,以确保它们同步。该逻辑信号也可以用软件实现,在DSP开始读上行通道模块FIFO数据之前,从GPIO0输出高电平,开始读数据以后再把GPIO0置为低电平,该信号经过FPGA后作为START信号送给每个上行通道模块,以完成对它们的同步。

4 结束语

该MIMO实验平台的建立充分运用了软件无线电思想,具有一定的通用性,可通过加载不同的软件实现各种制式的通信功能,可供研发机构在开发MIMO通信系统时作为实际测试和实验的平台。利用该实验平台,可进行系列相关理论研究,包括MIMO系统中的时空频联合处理方法、MIMO-OFDM结构中的时空频联合信道估计、时空频联合多用户检测时空频联合波束形成以及时空频联合分集等关键技术。还可以实现理论方法的实验验证、算法的DSP与FPGA实现及优化方法的研究。通过利用该实验平台对上述理论及关键技术进行研究及实验评估,从而取得具有实际应用意义的3G关键技术研究成果

参考文献

[1]刘丽,刘世忠,郭燕飞.4G通信系统核心技术MIMO-OFDM研究[J].移动通信,2009(Z1):132-136.

[2]管晓光,宋伟.MIMO-OFDM技术[J].电信快报,2004(11):28-31.

[3]赵婧华,酆广增.OFDM—第四代无线通信的技术核心[J].电信建设,2002(3):61-63.

[4]杨芳,何子述.MIMO实验系统中的数据缓冲应用研究[J].电子科技大学学报,2005,34(5):577-580.

动态数据交换技术的简单讲解 第11篇

关键词： 计算机测控 动态数据交换 组态王

1.引言

计算机及测控技术是为高等教育自动化专业本科生开设的一门专业选修课，课程的主要教学内容是计算机测控系统设计开发方面的专业知识，该课程集理论性、工程性和实践性于一体。随着工业生产规模不断扩大，使得测控系统复杂程度大大提高，系统需要交换的数据种类和数量不断增加，不同系统的设备具有不同的通信机制，造成测控软件相互之间不能通信。为了该问题，动态交换技术（DDE，Dynamic Data Exchange）应运而生，解决测控系统之间通信的一系列问题[1]。DDE技术较抽象，学生理解较困难，本文以理论与实例相结合的方式讲解该技术，使学生更好地理解和掌握该技术。

2.动态数据交换技术基本原理

2.1 DDE基本概念

动态数据交换DDE（Dynamie data exchange）是Mierosoft Window所制定的程序间通信的一种常用协议。动态数据交换已经成为Windows的一部分，并且许多应用程序都采用DDE技术，DDE作为一种基本机制已经应用于对象链接和嵌入OLE（Object Linking and Embedding）中。近年来，随着OLE及COM技术的逐渐成熟和发展，使用DDE方式的程序间通信有所减少，但是这并不意味着使用DDE方式进行程序间的通信不再有价值，DDE在MicrosoftOffice和众多的组态软件等许多应用程序中得到普遍支持。例如，Excel、QQ、组态王等。

DDE应用程序可以分为四种类型：客户、服务器、客户/服务器和监视器。DDE会话发生在客户应用程序和服务器应用程序之间。

DDE应用程序采用三层识别系统：应用程序名（Application）、主题名（Topic）和项目名（Item）：（1）应用程序名位于层次结构的顶层，用于指出特定的DDE服务器应用程序名。（2）主题名更深刻地定义了服务器应用程序会话的主题内容，服务器应用程序可支持一个或多个主题名。（3）项目名更进一步确定了会话的详细内容，每个主题名可拥有一个或多个项目名。

2.2 DDE通信原理

确切地讲，Windows下应用程序间的DDE通信的实现基础是Windows消息机制，DDE通信的基本原理如图1所示。

（1）运行DDE服务器端和客户端；（2）DDE客户端向服务器提出连接请求；（3）DDE服务器响应客户端的连接请求建立DDE会话连接；（4）DDE客户端与服务器端的通信；（5）结束DDE会话。

建立DDE会话后，客户应用程序和服务器应用程序可通过三种链接方式进行数据交换。三种链接方式为：冷链接（ColdLink）、温链接（Warm Link）和热链接（Hot Link）。

冷链接：客户程序申请数据，服务器程序立刻给客户程序发送数据，一次会话就此结束。

温链接：客户程序在与服务器程序建立连接后，每次数据发生变化时服务器程序都会通知客户程序。

热链接：客户程序在与服务器程序建立连接后，每次数据发生变化时服务器程序立即把变化后的值发送给客户程序。

3.实例讲解

本文以组态王访问Excel的例子讲解动态数据交换技术。

3.1定义DDE设备

首先在组态王中定义DDE设备，具体步骤如下：

3.1.1在工程浏览器的目录显示区，单击大纲项设备下的成员DDE，则在目录内容显示区出现“新建”图标，如图2所示[2]。

3.1.2选中“新建”图标后双击，安装设备配置向导进行相关配置，最后得到一个新建的DDE设备，如图3所示。

从图3可知，新建的DDE设备逻辑名为：ExcelToView，服务程序名就是DDE三层识别系统中的最顶层，应用程序名，用于指出特定的DDE服务器应用程序名。在本文中组态王访问Excel，从Excel中获取数据，Excel即为服务器应用程序，因此在信息汇总表中服务程序名为：Excel。话题名即对应DDE三层识别系统的主题名，定义服务器应用程序会话的主体内容。本文中服务器应用程序为Excel，因此我们定义话题名为：sheet1。组态王与Excel的数据交换方式为：标准WindowsDDE交换。

3.2定义变量与动画连接

在定义DDE设备以后，需要在数据词典中定义变量，具体信息如图4所示。

我们将变量名定义为：FromViewToExcel，变量类型定义为：I/O实数，因为组态王与Excel进行数据交换，故必须将其定义为I/O型变量。该变量连接的设备为已经定义的DDE设备：ExcelToView。项目名即为DDE三层识别系统的项目名，更进一步确定会话的详细内容。从图2已知，我们将话题名定义为sheet1，但是sheet1中有无数数据，组态王变量具体访问哪一个不确定。为了确定具体的访问数据，我们将项目名定义为：r1c2，即第一行第二列的数据。

接下来将开发界面中的文本与已定义的变量FromViewToExcel进行动画连接，具体信息如图5所示。

由图5可知，我们对文本进行模拟值输出连接，连接变量为FromViewToExcel。

3.3组态运行

动画连接结束以后，进入到运行状态。将Excel打开，同时组态王切换到运行状态，这样组态王就可以访问Excel，获取Excel中的数据，如图6所示。

4.结语

动态数据交换技术是测控系统中一种非常重要的数据交换技术，由于其概念较为抽象，不便于学生掌握。本文以一实例组态王访问Excel，详细生动地讲解动态数据交换技术的概念及原理，使学生很快掌握DDE技术的基本原理，并灵活应用。

参考文献：

[1]何坚强，徐顺清，张春富等.计算机测控系统设计与应用[M].北京：中国电力出版社，2012（9）.

数据交换平台 第12篇

国际物流主要包括跨国海运、空运及铁路运输等业务, 国际物流集团的分公司通常分布在世界各地, 一张国际物流订单的操作需要两个或两个以上位于不同国家的分公司协作完成。因此, 如何实现各分公司间快速、准确的信息交换, 成为物流集团提高服务质量、降低物流成本的关键。

笔者通过剖析参与设计实现的某国际物流集团的数据交换平台LDEP (Logistics Data Exchange PlatForm) , 提出了建设集中式数据交换平台的解决方案。该解决方案基于SOA (Service-Oriented Architecture, 面向服务的架构) , 以标准化数据交换接口实现各分公司信息系统的数据交换。

1 相关知识

1.1 现代物流

现代物流是一种新型的集成化管理, 其范围涵盖信息、运输、仓储、库存、货物装卸及其它相关的生产和物流业务。现代物流的宗旨是为客户提供最佳的服务, 同时将物流总成本降至最低[1,2]。

随着技术、装备和管理水平的进步, 现代物流呈现出以下特点[3]: (1) 对市场变化的快速响应; (2) 功能的集成化和模块化; (3) 物流服务的系列化和标准化。

1.2 电子数据交换

传统的电子数据交换方式是EDI (Electronic Data Interchange) 。随着因特网的广泛应用, 电子商务快速增长, 以XML为核心的数据交换技术成为新一代信息系统构建的基础。Xin Yu等[3]提供了一个基于XML的分布式物流信息系统的数据交换解决方案。Mostafa Hashem Sherif[4]详细介绍了数据交换技术的发展历史及相关标准, 从传统的EDI到Web Service和EBXML (Electronic Business XML) 。Yang Zhexi等[5]描述了一个基于EAI (Enterprise Application Integration) 的钢铁行业供应链数据交换平台, 该平台支持基于Web Service技术的数据交换。

2 LDEP设计中需要解决的问题

2.1 架构模式选择

物流集团的数据交换系统, 有两种主要的架构模式可供选择:

一种模式是采用分布式架构, 即将数据交换功能集成到每个分公司的信息系统中, 以分公司之间的点对点通信实现数据交换功能。这种架构看似简单, 实际上存在比较明显的缺陷: (1) 不利于多个分公司之间的数据共享; (2) 容易造成各分公司信息系统中数据的不一致; (3) 增加了分公司信息系统设计和实现的复杂度。

另一种模式是采用集中式架构, 即构建集中式的数据交换平台, 所有分公司间的数据交换均以该平台为枢纽。集中式的数据交换平台将数据交换功能从各分公司系统中剥离, 简化了分公司系统的设计复杂度和运行负荷, 最大程度实现了信息共享的统一管理, 确保数据的一致性。因此, 集中式的数据交换平台是物流集团内部数据交换的理想解决方案。

2.2 端到端数据交换

端到端数据交换是平台提供的数据交换服务应该具有的重要特性。在数据发送方将数据上传到数据交换平台后, 端到端数据交换要求平台能够按照指定方式将数据主动推送至数据接收方。

2.3 基础数据的一致性

这里所说的基础数据包括系统基础数据和业务基础数据两类。

系统基础数据指物流信息系统所涉及的众多基础编码, 如国家编码、币种编码、港口编码、包装单位编码、货品种类编码等, 这些编码是物流信息系统实现的基础。

业务基础数据指物流业务数据中的基础信息, 其中最主要的是在物流业务中大量出现的相关单位信息。在物流业务的操作流程中涉及许多相关单位, 如发货人、收货人、承运人、订舱代理、报关行等, 而且同一单位经常会反复出现在同一分公司的不同订单以及不同分公司的订单中。在信息系统中, 为便于统计查询, 所有相关单位都是采用编码进行标识和存储。这就要求所有相关单位信息在各分公司的信息系统中进行统一标识且严格保持一致。

从以上描述可以看出, 如果各分公司信息系统中的基础数据不一致, 将导致分公司之间无法有效地进行数据交换, 而且会进一步导致集团公司无法进行集团数据汇总统计。

3 LDEP的关键技术

3.1 集中式数据交换

通过上述分析, LDEP最终采用了构建集中式数据交换平台的方案。LDEP数据交换工作流程如图1所示。LDEP数据交换的具体步骤如下:

(1) 作为数据发送方的分公司信息系统调用LDEP的数据上传接口, 将数据上传至LDEP;

(2) LDEP接收数据后, 首先将数据存储至平台的数据库中;

(3) LDEP根据所接收数据中指定的推送方式 (如即时推送或定时推送等) , 当推送条件满足时, 触发数据推送操作;

(4) 进行数据推送时, LDEP首先从平台数据库中读取待推送数据, 并从中获取数据接收方信息;

(5) LDEP调用被指定为接收方的分公司信息系统提供的数据推送接口, 将数据发送至该分公司信息系统。若同一数据指定了多个数据接收方, 则并发执行本步骤, 同时将数据发送给所有数据接收方。

3.2 基于Web Service的数据交换接口

LDEP实现集中式数据交换主要依赖两类接口:一类是由LDEP提供的分公司信息系统向平台上传数据的数据上传接口;另一类是由各分公司信息系统提供的LDEP向各分公司信息系统推送数据的数据推送接口。这两类接口均采用Web Service技术实现。Web Service是一项已得到广泛应用的功能强大、技术成熟的分布式应用技术, 具有良好的技术开放性及互操作性。采用Web Service技术为LDEP提供了良好的开放性和可扩展性。

3.3 基础数据统一维护系统

为保证基础数据的一致性, LDEP提供了专门的基础数据统一维护系统, 如图2所示。

由集团公司指定的基础数据维护人员通过基础数据维护系统, 对基础数据进行集中录入和维护, 结果保存至基础编码标准库和相关单位信息标准库, LDEP自动将两个标准库的修改数据同步至各分公司的数据库中。通过基础数据统一维护系统及相应的自动数据同步机制, 确保所有分公司信息系统中基础数据的一致性。

4 LDEP系统结构及功能

LDEP共包括数据交换、平台门户、基础数据维护、平台管理4个子系统, 系统结构如图3所示。其中: (1) 数据交换子系统实现平台的数据交换功能, 提供平台对外的数据通信接口; (2) 平台门户子系统为各分公司提供与平台相关的管理接口及信息查询接口; (3) 基础数据维护子系统提供对系统基础数据和业务基础数据的统一维护接口; (4) 平台管理子系统用于对数据交换平台进行全面管理和监控。

5 LDEP技术架构

5.1 面向服务的架构SOA

IBM SOA Foundation白皮书中对SOA的定义如下:SOA是一种用于创建企业IT架构的风格, 该架构风格利用面向服务的原则将业务与支持业务的信息系统更为紧密地联系在一起。LDEP的系统技术架构采用SOA架构, 通过将系统的各组件单元进行服务封装, 并定义服务间的接口和契约构建整个系统。通过应用SOA架构, 实现了平台系统各组件间的松耦合, 提高了系统的可复用性及可扩展性。

5.2 分层结构

在基于SOA架构的前提下, LDEP的系统设计采用了如图4所示的分层结构, 将整个系统划分为表示层、服务接口层、业务层及数据层。表示层:实现平台各个子系统的Web网页及相关界面流程控制逻辑;服务接口层:对外提供平台所有的Web Service服务接口;业务层:实现系统的业务逻辑;数据层:实现系统的数据访问功能。

6 LDEP的实现技术

LDEP的系统实现选择了企业级的Microsoft.Net开发平台, 该平台不仅提供了极高的开发效率, 也保证了LDEP运行的高性能及可伸缩性。

7 LDEP运行效果分析

LDEP作为集团公司的数据交换平台, 除需要提供完善的数据交换服务外, 还必须具备良好的性能及可伸缩性。为此, 笔者对LDEP进行了全面的系统测试。

服务器硬件配置包括:应用服务器与数据库服务器各一台, 采用高端PC服务器, 两台服务器基本配置相同, 均为双Xeon 4核CPU, 128G内存, 200GSAS硬盘。服务器软件配置为Microsoft Windows 2008Server, Microsoft SQL Server 2008以及Microsoft IIS Web服务器。

经过系统测试, LDEP的功能测试全部达到设计要求。在因特网环境下, 平台系统平均响应时间低于1.5s, 平台门户并发连接数≥500。经过一年多的运行, 系统运行稳定, 功能及性能两方面均满足实际业务需求。

8 结语

本文论述了国际物流集团公司数据交换平台的架构与实现。平台系统通过应用SOA、分层结构、组件化等业界优秀的设计实践, 提高了系统的可复用性、可扩展性和可维护性。

LDEP下一步的工作重点是开发商业智能服务。LDEP积累的海量数据对集团公司具有重要的商业价值, 首先基于LDEP的平台数据库构建数据仓库, 然后在此基础上进行数据分析和数据挖掘, 可为集团公司提供更多有价值的决策支持信息。

摘要：为实现国际物流集团各分公司间快速、准确的信息交换的目标, 提出了构建集中式数据交换平台的解决方案。该平台采用面向服务的架构, 通过集中式数据交换、端到端数据推送等一系列技术, 实现了各分公司信息系统间的数据交换。系统运行结果表明, 该平台能够满足国际物流集团数据交换要求。

关键词：国际物流,数据交换,数据推送,服务架构

参考文献

[1]YUKUI, SHENG, WANLIAN.Application of principal component analysis method in logistics performance evaluatio[C]//2009International Conference on Intelligent Human-Machine Systems and Cybernetics, 2009.

[2]S L XIAO, Y SUN, S Q SHI.Study on modem logistics cost management[C]//IE and EM 2009Proceedings 2009IEEE 16th International Conference on Industrial Engineering and Engineering Management, 2009.

[3]XIN YU, PING LI, SHUFEN LI.Research on data exchange between heterogeneous data in logistics information system[C]//2010Second International Conference on Communication Systems, Networks and Applications, 2010.

[4]MOSTAFA HASHEM SHERIF.Standardization of business-tobusiness electronic exchanges[C]//5th IEEE Conference on Standardization and Innovation in Information Technology, 2007.