统一数据交换平台-总体框架设计方案初稿-v1.3

tdjava 贡献于2012-08-28

作者 yulp  创建于2010-06-12 02:50:00   修改者ZhouYan  修改于2010-06-24 05:19:00字数24873

文档摘要:根据江西省交换平台现阶段反馈问题协调会(2010-0528)的讨论结果,总体技术框架设计方案在原有的数据交换平台的基础上,对平台进行功能扩展和配置优化,完善“多种交换模式(格式化、非格式化数据)、多业务横向交换、三级平台的传输通道设计、ESB服务中介代理、平台的监控管理机制、平台的部署与实施” 。
关键词:

数据交换平台总体框架设计方案 数据交换平台总体框架 设计方案 方案初稿(V1.3) 第 页 数据交换平台总体框架设计方案 目 录 关于技术框架设计方案 4 1 总体架构 5 1.1 系统边界 5 1.1.1 逻辑边界 5 1.1.2 物理边界 6 1.1.3 行政管理边界 7 1.2 数据交换的平台的功能 7 1.2.1 传输功能 7 1.2.2 转换功能 7 1.2.3 路由功能 7 1.2.4 数据采集、同步及入库功能 8 1.2.5 提供实时和非实时两种业务功能 8 1.2.6 提供名字服务及web service支持 8 1.2.7 平台提供流程配置功能及监控功能 8 1.3 数据交换的平台的约束 9 1.3.1 相对独立性 9 1.3.2 易管理性 9 1.3.3 可扩充性 9 1.3.4 可靠性 9 1.3.5 支持异构操作系统、数据库 10 1.3.6 松耦合性 10 1.3.7 安全性 10 1.3.8 标准统一 10 1.3.9 业务流程相对独立 11 1.3.10 节约成本 11 1.3.11 前瞻性 11 1.4 平台技术架构 11 第 页 数据交换平台总体框架设计方案 1.5 数据交换平台三级结构 12 2 多种交换模式设计 14 2.1 格式化数据交换模式(消息内容路由) 14 2.1.1 路由功能适用的业务 14 2.1.2 功能实现的设计 15 2.1.3 路由功能的配置详解 26 2.2 非格式化数据交换模式(文件传输) 28 2.2.1 采用GTP进行文件交换 28 2.2.2 文件传输系统监控、管理 31 2.2.3 业务系统与前置机TongGTP节点文件接入方式 31 2.2.4 各级文件发送流程举例 32 2.3 交换中心的虚拟前置交换模式(Web方式的虚拟前置) 34 2.4 平台中的WEB服务代理接入模式 35 2.4.1 代理接入模型 35 3 三级平台的传输通道设计 38 3.1 平台中心节点间主干传输通道 39 3.2 单级平台中心与前置传输通道 41 4 平台的统一管理 43 4.1 概述 43 4.2 体系架构 43 4.3 系统组成结构与相互关系 44 4.4 需求描述 45 4.4.1 交换域管理 45 4.4.2 用户授权管理 47 4.4.3 Web服务管理 48 4.4.4 监控管理 49 第 页 数据交换平台总体框架设计方案 5 平台的部署与实施 50 5.1 硬件部署框架 50 5.2 平台模块部署模型 51 5.2.1 中心节点的模块部署 53 5.2.2 前置节点的模块部署 56 5.3 平台的实施 57 5.3.1 实施团队组建与分工 57 5.3.2 软件系统实施 58 5.3.3 平台接入 59 5.3.4 平台日常运维 59 5.3.5 制度规范制订 59 6 平台的标准化 60 6.1 平台的提供的功能 60 6.2 全省机构代码的标准化 61 6.3 TongLINK/Q节点名及队列名的及大小的标准化 63 6.4 TongIntegrator配置命名标准化 65 6.4.1 路由表数据的命名规则 65 6.4.2 交换中心的TI配置命名 65 6.4.3 前置机的TI配置命名 66 6.5 数据库访问的标准化 67 6.5.1 表的结构标准化 67 6.5.2 前置机上的数据库访问的标准化: 68 6.5.3 交换中心的数据库访问的标准化 68 6.6 业务流程命名的标准化 69 6.7 web服务命名的标准化 69 6.8 安装目录的标准化 69 第 页 数据交换平台总体框架设计方案 关于技术框架设计方案 根据江西省交换平台现阶段反馈问题协调会(2010-0528)的讨论结果,总体技术框架设计方案在原有的数据交换平台的基础上,对平台进行功能扩展和配置优化,完善“多种交换模式(格式化、非格式化数据)、多业务横向交换、三级平台的传输通道设计、ESB服务中介代理、平台的监控管理机制、平台的部署与实施” 。 1 总体架构 1.1 系统边界 1.1.1 逻辑边界 江西省电子政务统一应用技术支撑平台的逻辑框架下图所示: 第 页 数据交换平台总体框架设计方案 图表 1 江西电子政务统一应用技术支撑平台逻辑框架 如上图所示,统一应用技术支撑平台包括数据层,交换与管理层,门户服务层和安全管理四部分。数据交换统一平台如上图红色部分所示,功能是完成数据层和服务层中同层或异层间的数据交换。功能为实现不同网络系统、不同操作系统、异构数据库、不同数据格式、不同地域的应用系统之间的信息共享与交换,提供数据处理和数据传递服务。 1.1.2 物理边界 从物理上看,数据交换平台的机器设备分部在全省各县、市(地区)区及机关单位,每一个机关单位都有一个数据交换平台的前置机(如硬紧张,可和业务共用一台机器),每个县或市都有一个数据交换中心,前置机和交换中心通过中间件跨地域构成一个数据交换平台, 第 页 数据交换平台总体框架设计方案 前置机是数据交换平台和各县市区业务系统的边界线,如下图所示: 图表 2 数据交换系统和业务系统的物理边界 如上图所示:虚线包括的部分即为数据交换平台。 1.1.3 行政管理边界 从管理上看,前置机的管理应属于省、市、县的信息中心管理,而各机关的业务系统为各机关单位单独实现和管理。 1.2 数据交换的平台的功能 1.2.1 传输功能 提供跨地域的部门和部门间可靠、稳定、高效的数据传输,能够在网络发生故障、交换平台产生异常或发生崩溃的情况下实现数据交换,确保 第 页 数据交换平台总体框架设计方案 内容不重传、不漏传,支持断点续传,能够保证在故障修复后及时自动完成未完成的交换事务。支持2GB以上的大文件传输,对于大文件可以实现文件分割传送,并且在异常情况下有相应的措施。交换平台能够满足较大规模数据传输要求。 1.2.2 转换功能 提供数据的格式转换功能,能将文本文件、xml文件、数据库、JMS提供的数据通过过滤、组合处理,对数据进行格式转换和过滤清洗,成为干净的附合条件的数据。 1.2.3 路由功能 由于业务数据需要跨级传输,县委办局的业务数据要到省委办局,但县委办局到省委办局要经过县数据交换中心和省数据交换中心,在县或省数据交换中心,要先择TongLINK/Q的发送到市中心或省中心的发送队列发送,所以,必须提供路由选择功。 1.2.4 数据采集、同步及入库功能 平台能定时或自动的从前置机数据库中采集相应数据,同步到市中心或省中心数据库,数据可以是格式文件、数据库、及外部系统调用平台的接口API传入的数据。 第 页 数据交换平台总体框架设计方案 1.2.5 提供实时和非实时两种业务功能 交换平台对一些紧急业务,提供实时传输,对于非紧急的业务数据,提供正常业务传输。 1.2.6 提供名字服务及web service支持 各种服务程序要提供规范的名子,应用程序在发送数据时,要标明接收程序名称,即获得相应的服务,从而实现应用到应用间的跨越网络、平台的通讯。同时,支持web service。 1.2.7 平台提供流程配置功能及监控功能 平台提供流程配置功能,当业务不断增多时,通过配置即可完成传输流程定制,现时,提供监控应用及调用接口,供监控使用。 1.3 数据交换的平台的约束 1.3.1 相对独立性 数据交换平台独立于各个业务应用系统的业务逻辑,数据传输与数据的内容、形式无关。同时,数据交换平台与现有的业务应用系统应保持相互隔离和透明,数据交换平台对现有业务应用系统没有影响或尽量减少影响。 1.3.2 易管理性 数据交换平台应提供可视化的管理界面,易操作,可方便地实现对按不同业务需求进行数据交换的配置与管理。 第 页 数据交换平台总体框架设计方案 1.3.3 可扩充性 交换平台应具有良好的可扩充性。随着业务需求的变化和发展,通过在交换平台上进行配置部署,即可实现不同的业务数据的实时交换,无需开发或修改程序代码。随着系统规模的不断扩大,当参建部门增多和硬件系统需要升级时,交换平台可方便地适应建设规模扩大的需求,实现平滑升级过度。 1.3.4 可靠性 交换中心任何一台机器发生故障均不影响整个交换平台的正常工作和运行,在交换任务繁忙时可将任务自动分配到多台交换中心服务器上运行。当前置机数据库出现错误时,能够及时发现、规避和处理,以保证系统具有一定的自我恢复或容错能力。 1.3.5 支持异构操作系统、数据库 系统要支持各种不同的数据库及操作系统,如常用的oracle,db2、sybase、mysql、人大金仓、达梦数据库及linux、HP、AIX、windows等操作系统。 1.3.6 松耦合性 各个跨部门跨地域的业务应用系统在使用统一的数据交换平台时具有逻辑独立性,其中任何系统出现故障,都不会对其他业务系统造成直接的危害和影响,唯一的影响只是出现故障的业务应用系统不能实时获取或提供交换数据。 第 页 数据交换平台总体框架设计方案 1.3.7 安全性 采用可靠的身份验证、电子签名校验、SSL传输等防范措施手段防范系统运行风险,确保数据传输安全、系统稳定运行。 1.3.8 标准统一 标准统一,有利于各系统互联、数据校验,同时,也利于安装布署和系统检查。标准化包括以下几处方面: ● 接口统一 ● 安装用户和目录统一 ● 数据格式校验统一 只有在统一的标准之下,才能建立起来功能强大的业务系统,也才能将来统一各部门间的接口。 1.3.9 业务流程相对独立 业务流程之间要相对独立,之间只有处理性能的影响,不会影响业务流程自身数据的正确性。 1.3.10 节约成本 在完成功能和性能要求的条件下,注意节约成本。 第 页 数据交换平台总体框架设计方案 1.3.11 前瞻性 数据交换平台要有一定的前瞻性,充分考虑到未来技术进步时,能平滑过度到新系统上。 1.4 平台技术架构 政务信息资源整体上通过政府信息资源目录和信息资源交换平台为各级政府信息资源提供服务。 数据交换平台以东方通数据交换中间件为基础支撑,通过思创的信息资源交换管理系统提供统一的配置和监控管理,实现跨应用域,多部门的数据交换。 总体技术框架设计是在已有的数据交换平台的基础上,对平台功能进行了汇总梳理,同时又根据业主的要求对现有交换平台进行功能扩展,通过东方通公司针对现有产品的配置优化、接口功能改造以及思创的管理系统的建设 第 页 数据交换平台总体框架设计方案 ,用以完善和提高平台的整体功能,满足业务部门的需要。 此方案将通过“多种交换模式(格式化、非格式化数据)、多业务横向交换、三级平台的传输通道设计、ESB服务中介代理、平台的监控管理机制、平台的部署与实施”这几方面的设计来展开对现有平台的改造方案 。 1.5 数据交换平台三级结构 平台架构方案采用三级结构来满足不同级别的前置管理和业务数据交换功能需求: Ø 省中心:通过前置传输通道负责省级前置节点的数据交换功能,包括文件传输、ESB的Web服务接入、省级交换的监控管理等,监控省级平台各业务应用的数据交换信息等。通过中心主干传输通道完成接收市级中心发送数据、路由数据的接入并转发到各前置节点,或将数据转发至市级中心。 Ø 市中心:通过前置传输通道负责市级前置节点的数据交换功能,包括文件传输、虚拟前置、市级交换的监控管理等,监控市级平台各业务应用的数据交换信息等。通过中心主干传输通道完成区级中心、省级中心发送数据、路由数据的接入并转发到各前置节点以及区级中心、省级中心。 Ø 区县中心:通过前置传输通道负责区县级前置节点的数据交换功能,包括文件传输、虚拟前置、市级交换的监控管理等,监控区县级级平台各业务应用的数据交换信息等。通过中心主干传输通道完成向市级发送数据、路由数据的接入并转发到各前置节点及市级中心。 第 页 数据交换平台总体框架设计方案 2 多种交换模式设计 2.1 格式化数据交换模式(消息内容路由) 2.1.1 路由功能适用的业务 路由功能适用于将业务数据发送到不同级别的委办局的业务,如县发改委要将数据发送到市发改委,市发改委和市交换中心直连,而县发改委和县交换中心直连,两个因为连接的交换中心不同,从而不同 第 页 数据交换平台总体框架设计方案 “级别”。 2.1.2 功能实现的设计 本数据交换项目整体框架采用路由转发方式对各节点数据在市和省两级中心进行路由转发,实现各县、市、省委办局之前的数据交互,最终实现各委办局之间信息的交换和共享。 数据交换架构将节点分为两类:委办局前置机和中心。各级委办局的数据可以经由本级中心通过路由转发至其他中心或其他中心的委办局;中心委办局数据也可以通过中心路由转发至其他级委办局。 中心在数据交换过程中起到路由转发功能,当数据消息中的路由信息与路由转发节点信息匹配成功时说明该发送数据消息已到达目的地,这时可以对数据消息进行落地操作;匹配不成功时说明仍然需要对数据消息继续进行转发操作,这时需要通过其他发队列转发至其他中心再进行路由。 2.1.2.1 委办局前置机节点 委办局的数据流向包括发送需要上传的数据和接收其他节点转发的数据两种,为了便于路由,在前置机上需要创建相应的路由表,记录路由信息和数据包信息。前置机发送上传数据和接收转发数据的示意图如下图所示: 第 页 数据交换平台总体框架设计方案 在图中委办局前置机上部署TI和TLQ,用于数据交换处理。下面就发送上传数据的处理过程,与接收各节点转发来的数据的处理过程分别进行描述。 发送上传数据的处理过程 发送上传数据时委办局业务库需要将要同步的表推送至前置机业务表上,委办局前置机上传数据时需要分别创建:发送业务表、发送路由信息表、发送路由信息备份表。 l 发送业务表:相当于委办局业务库需要同步的业务表的影子表(需要去除实际业务表之间的主外键约束),上传数据由此表同步至发送路由信息表中。 第 页 数据交换平台总体框架设计方案 l 发送路由信息表,用于存储从发送业务表中获取到的上述信息,供发送流程使用,这个表包括的字段信息如下: 数据ID 状态标志位 发送地编码 目的地编码 业务编码 请求编号 数据包内容 1 N/Y [区县+部门]编码 [区县+部门]编码 如:征信系统 …… …… 数据ID :是自增长字段 表示数据的ID,可用于监控 状态标志位:代表该数据是否已经被发送,或者已经接收 发送地编码:代表该业务数据是由哪个部门发送的,代表来源地 目的地编码:代表该业务数据将要交换到的目的地,可以是多个 业务编码:标示该条数据包所含的内容 是属于什么类型的业务数据 请求编号:该次数据交换的请求编号,业务系统用来识别该表中的数据是否是自身请求的数据 数据包内容:数据内容 l 发送路由信息备份表:与发送路由信息表同构,用于定期备份发送路由信息表中的内容。 发送数据在前置机流程处理过程见图中蓝色箭头指示:流程读取业务影子表的增量数据,获取增量数据中的DO信息与节点路由信息,插入至发送路由表中,此时状态标志位为“N”表示末发送,然后再将发送路由表中的新增数据传至前置机上的上传发送队列中,记录成功发送至发送队列之后,更新发送路由表中的当前状态标志位为“Y”。由TLQ传输至中心进行路由,中心对于上传数据的处理逻辑见中心对数据转发处理过程。 第 页 数据交换平台总体框架设计方案 对于发送路由信息需要定期进行转存备份,操作方式是对发送路由表进行定时同步至发送路由备份表,备份过程中删除发送路由表中相应的记录。该清理备份工作需要在非工作日进行。 接收各节点转发来的数据的处理过程 委办局前置机接收其他节点传来的数据时需要分别创建:接收业务表、接收路由信息表、接收路由信息备份表。 l 接收业务表:相当于委办局业务库需要同步的业务表的影子表(需要去除实际业务表之间的主外键约束),其他节点转发来的数据最终发送至此。 l 接收路由信息表:与发送路由信息表结构相同,用于存储从其他节点转发来的数据记录,供接收流程使用。 l 接收路由信息备份表:与接收路由信息表同构,用于定期备份接收路由信息表中的内容。 接收其他节点转发来的数据时,在前置机的流程处理过程如红色箭头指示:流程从下发接收队列中取到消息后,向路由转发表中插入信息,此时状态标志位为“N”,然后通过定制组件将路由信息表中的记录中包含DO信息的数据包字段剥离成记录信息对业务影子表进行入库操作,入库成功后,将路由信息表中的状态标志位更新为“Y”。委办局业务可以从业务影子表取数据进行后期使用。对于接收路由表信息也需要定期进行转存备份,操作方式与对发送路由表的备份方式相同。 第 页 数据交换平台总体框架设计方案 2.1.2.2 中心节点 在中心交换服务器上部署TLQ用于存放其他节点转发过的数据,在中心交换服务器上使用TI的路由适配器完成路由工作。 第 页 数据交换平台总体框架设计方案 中心对于数据的转发架构图如上图所示,图中体现了由中心转发数据至中心业务库、中心各委办局、其他中心节点发送队列的数据流向。 第 页 数据交换平台总体框架设计方案 从中心转发的数据就有三种去向: l 发到本地接收队列进行数据落地操作(入中心业务库) l 路由至向其他中心节点发送数据的发送队列,进一步转发 l 路由至各委办局发送队列,进而传输至委办局 中心用于转发的接收队列是整个流程的起点,TI流程负责完成对该队列数据的路由工作: 路由规则为:与本地路由信息匹配的消息被本地接收队列接收并通过定制组件将数据包信息中的DO信息的剥离出进行入库;与本地路信息不匹配的消息被转发至其他中心发送队列或各委办局发送队列继续进行路由传输。 l 当数据消息符合中心路由规则时,将数据消息发送至中心接收队列,然后剥离出数据消息中的DO信息进行落地操作; l 当数据消息路由规则与中心委办局路由规则符合时,该消息被发送至中心委办局发送队列,由中心委办局接收队列接收到之后完成与委办局接收各点转发数据过程同样的操作流程,即:先从接收队列取消息插入到接收路由信息表中,TI流程通过定制组件将数据包信息中的DO信息的剥离出,实现真正记录信息入库操作。这样委办局的业务表就可以从接收业务表中获取相应的数据信息进行业务操作(示意图见委办局接收各节点转发来的数据处理过程)。 l 当数据消息路由规则与其他中心路由规则符合时,该消息被发送至发往其他中心的发送队列,由其他中心接收队列接收到之后,继续进行路由操作,直至数据发往目的地。 第 页 数据交换平台总体框架设计方案 中心在对数据消息进行路由过程中,如果向发送队列发送数据消息失败,异常处理机制会将当前失败的数据消息记录至数据库表中(结构与路由信息表相同),通过定时读该表中内容进行分发,实现补偿转发处理工作。 2.1.2.3 数据交换业务相关原则说明 委办局前置系统上的共享业务数据为全数据 为了解决数据交换平台的松耦合问题,同时也为了数据交换平台可以有效地利用资源,避免在网络上传输的数据冗余,对于同类业务数据,交换平台将为委办局提供所需的完整业务数据到平台前置节点上,各委办局业务系统可以通过前置系统获得自身所需的部分。 委办局业务库数据至前置机影子表推送过程注意事项 同步前期需要相关业务人员把委办局业务库数据库中需要同步的数据推至前置机影子表中,前置机影子表结构与委办局业务库需要同步的业务结构相同,但要去掉相关的主外键约束。 发送业务表至路由信息表数据处理 业务影子表数据同步至路由信息表的过程,形成路由信息,该路由信息需要由一定规则给出,实施前必须对路由规则进行统一约定,如路由信息的引入以何种形式给出,什么人员进行维护,维护过程对路由规则如何操作,路由信息在路由表中如何体现。 第 页 数据交换平台总体框架设计方案 路由信息表与中心路由规则约定 数据从业务影子表同步至路由信息表所生成的路由信息,归根结底是用来在中心进行路由的依据,因此,中心的路由规则与路由表中路由信息的具体形式需要制定出统一的标准。 2.1.2.4 数据交换模式 针对数据交换平台的整体数据交换功能以及路由交换的设计,平台将提供两大类别的数据交换模式,在提供不同数据交换的服务功能同时,减少业务系统与数据交换平台的耦合度。 第 页 数据交换平台总体框架设计方案 2.1.2.4.1 实时交换(平台默认) 首先,平台默认提供委办局业务库系统的实时数据交换功能,只需要通过平台提出数据交换功能并核准后即可,当申请成功后,提出申请业务部门的前置机上将会定期收到被交换业务系统的实时数据。 实时交换(平台默认):实时类交换采用实时处理方式进行交换,可接受多部门同时实时交换,此类交换得具体处理过程采用TI的实时同步流程即可 第 页 数据交换平台总体框架设计方案 。 2.1.2.4.2 特殊的数据交换(平台定制) 其次,对于用户提出的特殊交换需求,由平台提供统一的发起请求接口和操作接口,由平台定制特殊的交换流程进行处理,对于请求交换来说,由于用户所请求的表和请求的条件都有可能不同,因此这里对于每个业务均需要单独作流程进行处理。 特殊的数据交换(平台定制):特殊类的交换采用请求方式进行交换,这类的交换往往带有特殊的要求,所以此部分将由平台运维部门提供定制流程实现。具体处理过程为:用户通过平台发起请求,运维部门提供定制交换流程提取数据并形成路由信息数据,同时维护请求方部门前置机数据库,数据在平台中的流转和管理依然通过平台核心路由交换完成,运维部门不用维护此部分内容,仅需提供前置机上的提取数据流程。 【注意】 A. 对于一些多个业务部门都需要定期进行查询的业务数据,建议采用实时同步的方式将数据放在部门前置机上,用户直接查询前置库中的实施数据。 B. 对于需要根据某些特定条件检索数据的请求(通常查询的条件类别固定,比如组织机构代码,或者企业名称),如果多个业务部门都需要这种固定的模式,平台可以统一通过TLQ的消息接口,封装成查询数据流程服务,在平台上的应用通过用户输入查询条件后,发送消息至 第 页 数据交换平台总体框架设计方案 提供服务的部门前置机TLQ队列,消息内容包含请求业务类型和内容时限等查询条件,提供服务的部门前置上的流程解析TLQ队列中的消息内容,实现对符合约定条件数据的抽取,并形成路由信息记录,同步至路由信息表,从路由信息表发送数据的处理过程与委办局前置节点发送数据过程相同。 2.1.3 路由功能的配置详解 数据内容的路由功能由东方通的TongIntegrator提供协同TongLink/Q完成,TongIntegrator检查数据是向本交换中心的直接下级委办局还是发向其它中心的,如是自己直连的下级前置机,则通过TLQ直接发到其前置,如不是,则发向其所连接的交换中心,再由其中心转发至目的前置。 对于路由的信息配置可以通过数据库路由配置表的方式来进行增改等管理操作。 下面是通过东方通TongIntegrator路由配置做出说明,在前置系统中增加路由配置表,流程通过该表中的目的地编码,自动获得该流程的路由目的地,为每种业务配置一种路由规则,其中路由目的可配置多个,如下表示示: ID 业务描述 目的委办局(编码) 1 征信 省工商编码,省税务编码… 2 审批 省工商编码,省税务 第 页 数据交换平台总体框架设计方案 编码… 3 公安 交通局编码 …… …… …… 当前置系统中的TongIntegrator流程,在提取影子表数据后,通过上述表动态获得目的标示,并形成路由信息数据发送的路由信息表中,路由信息表如下: 路由信息表:用于存储从业务影子表中获取到的共享数据以及通过路由配置表中获得的目的前置节点等信息,供发送流程路由发送使用,这个表包括的字段信息如下: 数据ID 状态标志位 发送地编码 目的地编码 业务编码 请求编号 数据包内容 …… 1 N/Y [区县+部门]编码 [区县+部门]编码 如:征信系统 …… …… …… 数据ID :是自增长字段 表示数据的ID,可用于监控 状态标志位:代表该数据是否已经被发送,或者已经接收 发送地编码:代表该业务数据是由哪个部门发送的,代表来源地 目的地编码:代表该业务数据将要交换到的目的地,可以是多个 业务编码:标示该条数据包所含的内容 是属于什么类型的业务数据 请求编号:该次数据交换的请求编号,业务系统用来识别该表中的数据是否是自身请求的数据 数据包内容:数据内容 第 页 数据交换平台总体框架设计方案 2.2 非格式化数据交换模式(文件传输) 文件交换系统有两种构建方式,采用GTP或者TI+TongLINK/Q,各有优缺点。分述如下: 2.2.1 采用GTP进行文件交换 在数据交换平台中采用文件方式进行数据交换时,可以通过TongGTP搭建的交换通道实现省、市、线三级数据交换,确保数据可靠、安全 、完整性传输。每个县、市及省数据交换中心都布署一套,TongGTP的管理中心和日志中心设在县、市、省的数据交换中心,每个前置上只布署TongGTP节点,由数据交换中心通过TongGTP的管理中心远程配置、监控和管理各前置节点上的TongGTP。前置节点不需要任何管理。 TongGTP可以在任意两个委办局间建立数据传输业务,各委办局只是将现有业务系统生成的文件(文件名必须带有一定规则,即文件路由信息)放到前置机上TongGTP配置的目录下,由TongGTP负责传输到对应的委办局。 TongGTP的传输任务可进行调度,规定各传输任务的起始时间,调用频度。可人工触发、自动触发、定时触发传输任务。在传输过程中,TongGTP不对文件做任何解析。 TongGTP虽然在各节点间可以建立连接,但当节点增多时,GTP传输任务会成指数级增加,这会增加管理难度,如100个委办局间全建相互连接,则连接数将达到4950条,传输任务只有在建立联结后才能进行传输,这样,会使传输任务很多,建议各数据交换中心尽量采用星形结构,减少同级部门的横向连接。一个GTP任务将被分成两段,一段是传到中心,另一段是传到目的委办局,这样,有利于减少GTP管理中心的管理负担。但这样的缺点是经过中间传输节点,效率会较低。 第 页 数据交换平台总体框架设计方案 架构图如下所示: n 文件名加路由信息设计 在一个委办局的业务系统中产生的文件传输的目的地有多种:同属中心的某一个委办局、上级中心的委办局、多个目的点;对于TongGTP而言如何将这些文件分发到不同的目的节点,可以采取两种设计模式,其一:对应不同的目的节点采用不同的目录存放,由TongGTP根据不同的目录进行传输到不同的目的地;另外一种模式是在文件名中加路由信息,通过TongGTP解析路由信息发送到不同的目的地;比较两种架构,第一种模式受限于加入平台的业务节点个数,每加入一个节点都需要对所有节点下的目录进行更新,且需要建立大量目录,维护工作非常大;第二种模式需要制定一套路由规则即可;两种模式中,在将文件由业务系统到到前置机时TongGTP不能自动导入相关的目录或者文件名上加入路由信息,都需要专门的程序进行处理,在此方案中采用文件名加路由信息的模式架构。 第 页 数据交换平台总体框架设计方案 n 省、区县级中心架构 在方案中采用了文件名加路由信息的方式解决文件路由传输的问题,为了防止下行文件和上行文件存放在同一个目录中引起资源的争抢,为此在中心的架构中建立5个目录,上行、下行临时目录各1个,用来存放从市级中心或者各级中心转发来的文件,1个存放发向委办局的文件,1个存放从委办局来的文件,另外1个目录用来存放发向市级中心的文件。 在中心一级分别部署了两个TongGTP节点,一个负责对本中心外的委办局发送和接受文件,一个负责对本中心管理的委办局间传输文件。 n 市级中心架构 市的TongGTP节点配置基本和省,区县的类似。由于市的节点处在一个中间层次,需要做路由转发的工作,需要对上下级节点分别建立2个目录,1个是专门负责向上一级发送的“上行中心转发目录“,1个是专门负责向下一级发送的 第 页 数据交换平台总体框架设计方案 “下行中心转发目录”。 2.2.2 文件传输系统监控、管理 对各级文件传输节点的监控,管理,有2中监控管理方式。 n 采用3层分级管理的方式 采用3层管理中心,分别对应省,市,区县3级传输节点进行文件发送监控,节点管理。 省一级管理中心,管理省级的中心节点,省中心节点所属的委办局节点,以及市中心节点中,向省级发送文件的节点。 市一级管理中心,管理市级的中心节点,市中心节点所属的委办局节点,以及市县心节点中,向县级发送文件的节点。 县一级管理中心,管理县级的中心节点,县中心节点所属的委办局节点。 n 采用集中管理的方式 由于所有的TongGTP节点不在一个域管理中,目前的架构模式中TongGTP无法实现对所有的前置机节点和中心实现统一的集中管理,因此如果要实现集中管理,需要在3层分级管理的模式上再进行重新的封装、开发。 2.2.3 业务系统与前置机TongGTP节点文件接入方式 业务系统往委办局TongGTP节点前置机的发送目录上传文件或在接收目录接收文件时,可以采用以下两种方式进行上传或接收。 第 页 数据交换平台总体框架设计方案 1. 采用TongGTP客户端的方式上传下载。 采用TongGTP客户端的方式上传下载文件,能够很好地嵌入到业务系统当中。上传和下载只要调用简单几个TongGTP客户端API,就能完成上传和下载。 也可以采用TongGTP客户端中自带的demo程序,进行上传和下载。Demo程序中是通用的上传和下载功能,只要加上参数即可以使用,也无需编程。 2. 采用FTP的方式上传下载。 采用FTP的方式,另外需要安装FTP服务端及客户端,并由运维工程师进行手工上传和下载。 总的来讲:基于FTP的方案,基本可以满足平时委办局的传输需求;而基于TongGTP客户端的方案,在传输、安全和管理方面提供了完善的支持,对系统运维和安全保障提供了更好的实现。 2.2.4 各级文件发送流程举例 1. 从本地委办局发往不同级委办局 如架构图所示,如果从区县本地委办局W111往不同级委办局W1发送文件。 首先是业务系统往本地委办局W111的“发送目录”写入文件,该文件的文件名带有路由信息,表明该文件要发往W1。接着本地委办局部署的TongGTP会扫描“发送目录”,发现有文件,会马上发送到上级中心“上行临时目录”。 第 页 数据交换平台总体框架设计方案 中心GTP_X2节点会把“上行临时目录”中的文件,按路由信息把文件移到“上行中心转发目录”中,进而GTP_X1节点会把文件往上一级中心GTP_C1的“上行临时目录”发送。 GTP_C1接着再检查在本节点内的“上行临时目录”中,该文件的路由信息是否是往GTP_C1管理的委办局,如果不是,则移往“上行中心转发目录”。GTP_C2会不停扫描“上行中心转发目录”目录,当发现有文件时,根据该文件的路由信息,发往GTP_P2的“上行临时目录”。 GTP_P2接着再检查该文件的路由信息是否是往其他中心管理的委办局,如果不是,则移往“上行委办局接收目录”。GTP_P2会不停扫描“上行委办局接收目录”,当发现有文件时,根据该文件的路由信息,发往GTP_P2管理的W1。 2. 从本地委办局发往同级委办局 如架构图所示,如果从本地委办局W111往同级委办局W211发送文件。 首先是业务系统往本地委办局W111的“发送目录”写入文件,该文件的文件名带有路由信息,表明该文件要发往W211。接着本地委办局部署的TongGTP会扫描“发送目录”,发现有文件,会马上发送到上级中心GTP_X2的“上行临时目录”。 中心GTP_X2节点会把“上行临时目录”的文件,按路由信息把文件移到“上行委办局接收目录”中,进而GTP_X2节点会不停扫描“上行委办局接收目录”,当发现有文件时,根据该文件的路由信息,发往本中心管理的管理的W211的 第 页 数据交换平台总体框架设计方案 “接收目录”中。 2.3 交换中心的虚拟前置交换模式(Web方式的虚拟前置) 部分委办局需要交换数据的业务很少或者不具备安装前置机的条件,这时,需要在数据交换中心给此委办局提供一台虚拟前置,委办局通过远程https访问,直接将平台所需数据录入到网页,传送到数据交换平台。 由于数据的需要者可能是县,也可能是市,也可能是省,如果全省统一个虚拟前置,则有可有各县的要求不一致,从而无法满足个性化需求,所以,建议各县、市、省交换中心分别部署一台虚前置,供本中心管辖的委办局使用。 虚拟前置中心为架构在TongWEB应用服务器上,在收到委办局录入的数据之后,直接调用交换平台api接口,将数据传到数据中心或者入库。当委办局需要查询数据时,直接调用平台api,从平台上获取数据。 虚拟前置由于采用互联网访问,所以,安全非常重要,建议采用双向认证https对数据进行加密传输,同时,对访问用户的IP地址、mac地址、证书有效日期、操作人员、及操用人员密码、数据间的关联关系等进行校验登记,以确保数据安全,同时,要对访问频度也进行限制,以防止恶意灌注。从而对整个统一平台造成影响。 第 页 数据交换平台总体框架设计方案 2.4 平台中的WEB服务代理接入模式 目前,省级交换平台存在通过WEB代理方式接入省级部门业务系统的代理接入需求,其主要需求来源是一些涉密的政府单位无法直接提供业务系统的数据或者无需提供业务数据只需提供相应功能即可,那么针对这种需求,只能通过服务的方式提供系统的接入。 由此为了解决目前的需求,需要在省级平台建立和安装部署ESB产品,并通过ESB的WEB代理方式对外提供服务代理功能。 2.4.1 代理接入模型 此接入模型通过平台中心节点发布新的Web服务应用,业务用户需要通过中心的授权机制,以WebService应用的实现方式接入平台,通过平台的Web服务应用代理访问业务 第 页 数据交换平台总体框架设计方案 部门的相应Web服务应用功能,并通过中心记录代理过程。 2.4.1.1 服务接入方式 平台用户通过平台所在网络,访问省中心交换平台服务库,查找想用Web服务,根据Web服务提供的接口,实现访问Web服务的应用,之后通过向省中心提供的Web服务代理发送请求。省平台中心将请求信息通过平台网络发送到部门前置代理服务器,代理服务器中的平台Web服务代理模块通过前置机桥接进入部门专网,调用部门业务系统,部门业务系统将应答数据返回给部门前置Web服务代理模块,最后将应答消息通过Web服务的方式返回给用户。 此方式的特点: l 用户实现的WebService应用,可以嵌入到自己的业务系统中,不需要额外的人工操作进行访问。 l 提供web服务的业务部门提供针对平台开发统一的一套安全策略,由平台统一提供访问,便于安全管理和系统维护。 l 用户的访问请求和应带请求,对于中心是透明的,所有数据中心均不落地也无法监控。 l 对于中心需单独开发WebService服务库,以便对于用户提供注册、发布、查找的功能。 l 对于中心需单独设计和开发安全和授权机制,用以WebService的访问管理。 第 页 数据交换平台总体框架设计方案 l 对于Web服务的请求用户,需要其针对平台开发WebService应用,用于访问平台Web服务,如不实现则无法访问该业务系统。 2.4.1.2 服务接入模型 此模型需要的工作模块: 1. 需要被代理的业务部门提供自身业务系统的Web服务。 2. 需要通过平台Web服务代理的业务部门需要开发和部署符合WebService技术标准的应用系统。 3. 省中心平台节点需要提供安全、授权管理模块,用以区分不同访问者的身份以及针对不同服务代理的访问权限。 第 页 数据交换平台总体框架设计方案 4. 省中心平台节点提供服务注册库,针对授权和身份认证后的用户可以在平台中查询和检索需要访问的Web服务。 5. 省中心平台节点在数据库中建立用户服务授权、管理以及服务注册、发布的数据库。 6. 省中心要提供服务代理应用系统,并发布到服务注册库中,用以代理客户Web服务。 7. 部门前置系统,通过Web服务代理(ESB)接收请求数据,并代理访问部门Web服务,获得部门应用的处理结果后,将结果通过前置系统发送回省中心平台节点。 8. 省中心通过Web服务代理(ESB),将请求结果返回给代理服务请求者。 3 三级平台的传输通道设计 三级平台数据通道主要是为三级交换中心接点之间,以及各级交换中心接点与各部门前置交换机之间提供安全、可靠、稳定、高效的信息传输通道。从数据纵向和横向传输两个维度对平台中心接点间主干传输通道和单级平台中心与前置传输通道分别进行架构设计; 平台数据通道的架构主要通过在三级中心以及各级委办局的前置机上安装配置TongLINK/Q,并通过TongLINK/Q的队列配置达到数据可靠、高效的传输。在数据的传输过程中,每两个节点间的数据交互必须经过其中1个三级中心节点。在硬件环境允许的情况下,在中心节点TongLINK/Q 第 页 数据交换平台总体框架设计方案 采取双机热备的方式,确保系统的可靠性。 在平台中心接点间主干传输通道队列架构原则如下: Ø 只考虑数据传输过程中的可靠、高效,不对数据传输内容进行处理; Ø 根据业务时效性需求采用不同的数据传输通道进行传输; Ø 数据传输过程中当传输通道阻塞后需要对数据进行备份; Ø 对传输通道尽量复用,减少配置环节的复杂性; 3.1 平台中心节点间主干传输通道 n 省级中心 1)、在省级中心的TongLINK/Q中有2个公用的接收队列,用来接收所有市级中心发送的实时数据和业务数据。 2)、对应每个市级中心都会有2个发送队列,在2个发送队列中,分别向每个市中心发送实时数据和业务数据。 3)、在省中心的TongLINK/Q接点中对应的平台中心节点间主干传输通道队列个数总和是。 N×2+2个公用接收队列 其中N指一个省属的市级中心个数; n 市级中心 1)、在市级中心的TongLINK/Q中有2个公用的接收队列,其中2个用来接收所有县中心的实时数据和业务数据, 2)、对应每个县都会有2个发送队列,在2个发送队列中,分别向每个市中心发送实时数据和业务数据; 第 页 数据交换平台总体框架设计方案 3)、对应省中心,有2个发送队列,2个接受队列,分别从省中心发送和接受实时数据和业务数据; 4)、在1个市中心的TongLINK/Q接点中对应的平台中心节点间主干传输通道队列个数总和是: N×2+2个公用接收队列+4个与省中心交互的队列 其中N指一个市属的县、区中心个数; n 县级中心 1)、在县级中心的TongLINK/Q中有2个公用的接收队列,用来接收所有县委办局的实时数据和非实时数据, 2)、在每个县级中心都有2个发送队列,向市级中心发送实时数据和业务数据; 3)、在1个市中心的TongLINK/Q接点中对应的平台中心节点间主干传输通道队列个数总和是: 2个公用接收队列+2个与市级中心交互的队列 其框架架构图如下: 第 页 数据交换平台总体框架设计方案 其中:红色箭头表示数据流向是:县级中心->市级中心->省中心 黑色箭头表示数据流向是:省中心->市级中心->县级中心 n 为了防止各级中心接收对列的阻塞,采用多线程的方式进行接收;提高接收速度。 n 当向发送队列放入数据失败时,将放入数据库进行存储; 3.2 单级平台中心与前置传输通道 单级平台中心与前置传输通道主要是为各级中心点与所属委办局接入点前置机之间的数据传输通道。 n 各级中心 第 页 数据交换平台总体框架设计方案 1)、在各级中心的TongLINK/Q中有2个公用的接收队列,分别用来接收各委办局向各级中心发的实时数据和业务数据; 2)、对应每个各级中心所属委办局都会有2个发送队列,用来向各级中心所属委办局发送实时数据和业务数据; 3)在1个各级中心的TongLINK/Q接点中对应的单级平台中心与前置间传输通道队列个数总和是: M×2+2个公用接收队列 其中M指各级中心所属委办局个数; n 前置机 1)、在各前置机的TongLINK/Q中都会有2个发送队列,用来向各级中心发送实时数据和非实时数据; 2)、在各前置机的TongLINK/Q中都会有2个接收队列,用来接收从所属委办局发送来的实时数据和非实时数据; 3)、在各前置机的TongLINK/Q接点中对应单级平台中心与前置传输通道的队列个数总和是: 2个发送队列+2个接收队列 l 为了防止各级中心接收对列的阻塞,采用多线程的方式进行接收;提高接收速度。 l 当向发送队列放入数据失败时,将放入数据库进行存储; 方案架构图如下: 第 页 数据交换平台总体框架设计方案 其中:红色箭头表示数据流向是:前置机->中心 黑色箭头表示数据流向是:中心->前置机 4 平台的统一管理 4.1 概述 平台的统一管理是指对运行在平台上的各节点、流程、交换资源数据与平台后续扩展的基础服务等方面进行集中管理的软件系统。通过该系统,可以对节点部署情况、流程部署及流程数量与使用情况、,信息资源的更新、交换情况,信息资源交换的实施、运行情况进行监控和考核,确保信息资源共享的长期稳定运行。 4.2 体系架构 体系架构包括服务层、功能层、数据层三个部分 第 页 数据交换平台总体框架设计方案 服务层:对功能层数据交换功能进行封装,并对外提供提不同的管理服务等。前置节点远程启停服务、交换流程远程启停服务允许外部用户通过此服务接口控制节点、流程的工作状态;通过流程部署接口可以把配置好的交换流程发布到指定的前置节点上;用户授权认证服务实现对来自不同部门的平台用户进行统一的授权控制;交换统计服务可以对外提供交换统计图或统计报表等内容,邮件通知服务对外提供以邮件的方式及时传送报警信息; Web服务对外提供WebService接口的发布信息,方便用户快速找到满足自己需求的Web接口。 功能层:统一管理的核心功能,主要包括交换域管理、平台监管、Web服务管理以及用户授权管理等功能,每项功能由一个子系统具体实现。 数据层:主要包括监管信息、配置管理信息。监管信息是平台运行过程中产生结果信息;配置管理信息是对节点、流程、Web服务以及用户的管理过程中产生的信息。 4.3 系统组成结构与相互关系 相互关系描述: l 交换域建立交换流程与交换资源之间的联系; l 用户授权管理负责配置管理用户访问资源、使用Web服务的权限,只有授权用户才能查看资源信息和Web服务信息; 第 页 数据交换平台总体框架设计方案 l 监控管理负责监管交换域中的节点流程状态、数据传输状态、资源使用情况、Web服务使用情况以及平台用户量以及用户授权情况; 4.4 需求描述 4.4.1 交换域管理 交换域管理是对平台总体交换环境的统一管理,管理的对像包括中心节点、前置节点、节点之间的传输链路以及运行在交换节点上的交换流程。 交换域管理需要基于TI、TongLINK/Q产品提供API接口进行二次开发,从而实现对节点、传输链路以及交换流程的集中管理与控制。 交换域可以分为以管理为核心的交换域与以业务为核心的交换域,拓扑结构图吐下所示: 第 页 数据交换平台总体框架设计方案 4.4.1.1 节点管理 节点管理包括节点注册、节点启停,通过节点注册,建立前置交换节点与政务部门之间的对应关系。以便于按照政务部门管理前置节点。节点启停操作实现对节点运行状态的有效控制与管理,使用户可以根据需求启停节点。 4.4.1.2 交换流程管理 交换流程管理包括流程注册、同表流程配置与部署以及流程启停。通过流程注册建立流程与节点、流程与交换资源之间的关联关系,便于统计交换流程完成的业务交换信息量。同表流程配置允许用户通过b/s界面配置同表交换流程并部署到指定的前置节点中。 第 页 数据交换平台总体框架设计方案 流程启停操作实现对流程运行状态的有效控制与管理,使用户可以根据需求启停某一个交换流程。 4.4.1.3 链路管理 链路管理包括链路配置、链路查看,链路配置是建立前置节点节点之间的传输通道,配置传输参数;链路查看是对链路传输过程进行展示,包括发送队列信息、接收队列信息、传输的信息量等传输过程信息。 4.4.2 用户授权管理 用户是指使用平台的人,包括信息中心业务人员、系统管理人员、委办局业务人员以及相关部门的领导等。 4.4.2.1 用户管理 对平台用户进行增加、修改、删除以及查询。只有成为平台用户,才有可能访问平台提供的各应用系统; 4.4.2.2 部门管理 按照省市政务部门隶属、级别关系实现对政务部门的管理。包括新增、修改删除以及查询导航等。部门管理为资源管理、交换域管理、以及监控管理等提供基础信息。 4.4.2.3 角色管理 每个平台用户都应该具有一种以上的角色,角色不同意味着具有的操作权限不同,管理职责不同; 第 页 数据交换平台总体框架设计方案 角色管理支持增加角色、修改删除角色、查询角色,建立角色与用户之间的对应关系。 4.4.2.4 权限管理 每个角色都需要赋予一定的操作权限,权限管理通过增加权限、修改权限、删除权限实现对角色权限的调整。 4.4.3 Web服务管理 Web服务管理是对平台对外提供的WebService接口按照功能进行归类管理。 4.4.3.1 Web服务注册 对平台提供的WebService接口进行配置,包括设置接口参数、调用示例以及使用权限信息等; 4.4.3.2 Web服务更新 对平台原有的WebService接口进行修改,包括功能调整、权限信息调整、版本信息等,对接口进行日常维护。 4.4.3.3 Web服务发布 Web发布是按照Web服务分类结构来展示展示Web接口信息。平台用户只能查看、使用已发布的Web接口; 第 页 数据交换平台总体框架设计方案 4.4.3.4 Web服务查询 支持通过关键字、权限信息、服务名称等对Web服务进行查询,快速了解Web服务功能介绍以及使用要求等。 4.4.4 监控管理 监控管理是对平台自身的交换管理、用户认证授权和基础信息资源共享系统的工作状态、交换节点、交换流程运行状态进行集中监控管理。 4.4.4.1 交换信息查看 对中心节点、前置交换节点、文件交换流程、数据交换流程的历史运行状态以及Web服务的历史使用日志等进行按关键或日期查询。 4.4.4.2 系统运行信息查看 系统运行信息是指平台各服务的运行信息(如,数据服务器、交换服务器等)、交换产品运行日志信息(如,数据插入数据库失败、文件传输中断等)以及用户操作日志信息等,支持按照关键字或者日期查看系统运行信息。 4.4.4.3 交换情况统计分析 对交换日志信息按照各政务部门进行分类统计分析,得到各政务部门使用共享交换平台的综合情况,如数据交换的次数和数据量、基础信息资源共享次数和数据量、用户认证次数和点击量等,实现对平台交换业务访问情况的总体了解。 第 页 数据交换平台总体框架设计方案 4.4.4.4 信息告警通知 对节点、流程运行过程中的异常情况如,节点停止、传输中断等,以邮件的方式及时通知给相关负责人,帮助相关人员迅速了解共享交换平台的运行情况,诊断、发现并及时解决共享交换平台中的各类故障问题。 5 平台的部署与实施 5.1 硬件部署框架 【部署框架,即中心、前置的服务器的数量及平台系统软件部署的位置】 第 页 数据交换平台总体框架设计方案 服务器 大概配置 产品 软件系统 中心交换服务器 4CPU 红旗LINUX TI25 TLQ63 思创前置系统 中心数据库服务器 4CPU 红旗LINUX 金仓数据库 共享服务器 2CPU 红旗LINUX 达梦数据库 TI25 TLQ63 (或者GTP) 思创前置系统 交换管理服务器 2CPU 红旗LINUX 金仓数据库 TWEB4.8企业版 思创管理系统 5.2 平台模块部署模型 【中心,前置节点的平台模块组成架构】 第 页 数据交换平台总体框架设计方案 全省数据交换平台由省市县三级中心节点构成平台中心的主干架构中心节点通过中心交换通道进行数据交换,省市县三级中心分别与各级委办局业务部门的前置节点通过前置交换通道进行数据交换,构成省、市、县的三级平台数据交换凭平台。 第 页 数据交换平台总体框架设计方案 5.2.1 中心节点的模块部署 交换中心节点的软件模块由监控管理层、服务提供层、交换流程层、传输通讯层以及中心数据源五个部分组成。 中心管理应用以浏览器的形式对外提供服务功能,包括管理代理、数据源管理、监控和统计等监控管理功能,为服务提供层的模块服务功能提供前台的交互应用。 作为中心节点除了通过中心管理应用提供管理功能外,管理代理模块同时提供能中心节点的管理接口,可以通过开发工具、或者上级中心节点进行管理,管理代理模块主要的管理对象是叫交换流程层和传输通讯层。 第 页 数据交换平台总体框架设计方案 中心数据源是中心所有交换业务数据、交换过程信息、管理信息的数据存储区,通过交换流程采集的数据保存在中心资源库,共享数据也从中心资源库中提取,而中心管理库则记录所有中心交换的过程基础信息等。 中心管理监控的主要功能 1. 针对中心数据源管理操作 a) 对于数据源的定义、部署/卸载 b) 数据源配置参数修改 c) 数据源的运行状态监控 2. 中心库中数据资源的管理操作 a) 发布申请、审核 b) 消费申请、审核 3. 交换流程的配置管理监控操作 a) 流程定义、部署/卸载 b) 流程参数修改 c) 流程运行监控 d) 流程运行统计分析 4. 中心节点提供虚拟前置的基本操作 a) 界面数据录入,查询,修改 b) 文件上传,下载 5. 对于本级平台管理功能 a) 平台安装/卸载 第 页 数据交换平台总体框架设计方案 b) 平台备份/回复 c) 平台参数修改 d) 平台运行监控 e) 平台运行统计分析 虚拟前置的主要功能 1. 对中心管理应用的界面录入内容进行解析 a) 获取数据/文件 b) 目的交换节点选择 c) 附加数据/文件处理 d) 发送数据/文件 2. 需要进行的工作 a) 界面/文件源定义 b) 目的节点定义 i. 相邻节点直接发送 ii. 通过中心转发 iii. 依据内容进行判断 c) 附加数据/文件处理定义 第 页 数据交换平台总体框架设计方案 5.2.2 前置节点的模块部署 交换前置节点的软件模块由监控管理层交换流程层、传输通讯层以及中心数据源四个部分组成。 前置交换节点通过管理代理模块提供前置节点的管理接口,可以通过上级中心节点进行管理,管理代理模块主要的管理对象是交换流程层和传输通讯层。 前置数据源是前置节点中所有交换业务数据、交换过程信息、管理信息的数据存储区,通过交换流程采集的数据保存在前置资源库,共享数据也从前置资源库中提取,而前置管理库则记录所有中心交换的过程基础信息等。 前置节点的主要管理功能 1. 前置节点的操作功能 a) 数据源参数修改 b) 数据源运行监控 第 页 数据交换平台总体框架设计方案 c) 流程参数修改 d) 流程运行监控信息采集 e) 流程运行统计分析信息采集 2. 前置平台管理功能 a) 平台安装/卸载 b) 平台备份/回复 c) 平台参数修改 d) 平台运行监控 e) 平台运行统计分析 5.3 平台的实施 平台的实施工作有软件系统实施、平台接入、平台日常运维以及实施工作相关的制度规范的制订四个部分,各部分之间的关系如下图: 5.3.1 实施团队组建与分工 平台实施工作需要有专门的、稳定的实施团队,实施团队的实施任务必须明确、实施流程清晰规范。实施工作由四部分组成,从保障平台稳步建设、稳定运行的角度看,也应该有四个实施团队参与到平台实施工作中。 第 页 数据交换平台总体框架设计方案 软件实施小组:主要由软件技术人员组成,负责平台应用软件系统开发工作; 平台接入小组:主要由熟练使用交换产品的产品技术服务人员组成,负责平台接入工作; 平台运维小组:主要由熟悉平台软硬件环境的技术人员组成,负责平台日常运维工作,保障平台的稳定运行; 制度规范制订小组:主要由熟悉平台的业务人员、技术人员组成,负责平台实施、运行过程中的管理制度办法、实施规范编写、修改直到发布工作; 5.3.2 软件系统实施 软件系统实施工作是平台实施过程中不可缺少的工作内容,近阶段,平台的软件系统实施工作主要侧重在平台监管系统、目录管理系统、目录服务系统以及基础共享库等方面。随着平台应用深度的发展,平台面向社会提供公共服务系统以及业务主题服务等都将是平台软件系统实施工作的重点任务之一。 软件系统实施必须采用严格的项目管理模式来控制开发质量、控制开发周期、控制开发成本、降低开发风险等,确保软件系统能够保质保量的按照预定进度完成。 第 页 数据交换平台总体框架设计方案 5.3.3 平台接入 平台接入的工作内容包括:交换节点的安装部署、交换流程的配置部署; 通过安装交换节点、配置交换流程,可以建立委办局与交换中心之间、委办局与委办局之间的互联互通将委办局提供的政务信息资源共享给其它需求方,并从平台获得需要的信息资源。 平台接入是平台的核心工作,它贯穿在平台的实施阶段与运维阶段,是一个持续性的工作。因此,平台接入团队的稳定显得尤为重要。 5.3.4 平台日常运维 平台日常运维工作重点是保证平台正常运行,其内容包括:保证平台各应用系统的正常运行、保证节点流程的正常工作、保证网络环境的正常工作、保障平台支撑环境的正常运行等等;平台运维工作是一个持续性的例行工作,需要有相应的管理制度规范来指导与约束。 5.3.5 制度规范制订 不同的实施工作需要有不同制度规范来支撑,平台实施过程需要制订的制度规范可以包括以下几个方面: l 前置机数据存储管理命名规则; 包括数据库命名规范、数据表命名规则、文件命名规则、目录路径命名规则等内容; 第 页 数据交换平台总体框架设计方案 l 队列命名规范;包括发送队列、接收队列; l 消息路由命名规则; l 交换节点、交换流程编码规范; l 委办局节点接入、资源交换流程配置管理要求,包括业务协调、技术实现以及资料归档等内容; l 数据交换平台对接指南; l 数据交换平台管理规范 l 前置机数据资源管理制度 l 组织机构编码规范、角色编码规范等 l 平台运维管理制度; l 平台应急处理规范; l 其他 随着平台的逐步建设,原有的制度规范需要及时的修订,新的制度规范涉及到的内容范围也将随之扩展。 6 平台的标准化 6.1 平台的提供的功能 l 提供文件传输功能 对于所有在平台上交换的数据,在传输前,都转为文件。放到固定的目录下。或都者带有路由前缀。建议用后者。 l 提供数据库交换功能 第 页 数据交换平台总体框架设计方案 提供各种数据库间数据交换功能。 6.2 全省机构代码的标准化 采用GB/T2260-2207行政区划编码和组织机构代码共同构成一个机构的代码。国标GB/T2260-2207的行政区划代码如下: 编号 县区 编号 县区 编号 县区 编号 县区 360000 江西省 360424 修水县 360731 于都县 360925 靖安县 360100 南昌市 360425 永修县 360732 兴国县 360926 铜鼓县 360102 东湖区 360426 德安县 360733 会昌县 360981 丰城市 360103 西湖区 360427 星子县 360734 寻乌县 360982 樟树市 360104 青云谱区 360428 都昌县 360735 石城县 360983 高安市 360105 湾里区 360429 湖口县 360781 瑞金市 361000 抚州市 360111 青山湖区 360430 彭泽县 360782 南康市 361002 临川区 360121 南昌县 360481 瑞昌市 360800 吉安市 361021 南城县 360122 新建县 360500 新余市 360802 吉州区 361022 黎川县 360123 安义县 360502 渝水区 360803 青原区 361023 南丰县 360124 进贤县 360521 分宜县 360821 吉安县 361024 崇仁县 360200 景德镇市 360600 鹰潭市 360822 吉水县 361025 乐安县 360202 昌江区 360602 月湖区 360823 峡江县 361026 宜黄县 360203 珠山区 360622 余江县 360824 新干县 361027 金溪县 360222 浮梁县 360681 贵溪市 360825 永丰县 361028 资溪县 第 页 数据交换平台总体框架设计方案 360281 乐平市 360700 赣州市 360826 泰和县 361029 东乡县 360300 萍乡市 360702 章贡区 360827 遂川县 361030 广昌县 360302 安源区 360721 赣县 360828 万安县 361100 上饶市 360313 湘东区 360722 信丰县 360829 安福县 361102 信州区 360321 莲花县 360723 大余县 360830 永新县 361121 上饶县 360322 上栗县 360724 上犹县 360881 井冈山市 361122 广丰县 360323 芦溪县 360725 崇义县 360900 宜春市 361123 玉山县 360400 九江市 360726 安远县 360902 袁州区 361124 铅山县 360402 庐山区 360727 龙南县 360921 奉新县 361125 横峰县 360403 浔阳区 360728 定南县 360922 万载县 361126 弋阳县 360421 九江县 360729 全南县 360923 上高县 361127 余干县 360423 武宁县 360730 宁都县 360924 宜丰县 361128 鄱阳县 361129 万年县 361130 婺源县 361181 德兴市     由于省、市、县各委办局有一定的对应关系,如省工商局、市工商局、县公商局,而每个县的委办局不超过150个,为了节省代码长度,可用一个1000-4293间四位代码统一代表一个委办局,如工商局统一用1002,至于是线工商局还是县工商局,看行政区划,如1002360000就是省工商局,因为1002为工商局代码,而360000为江西省行政区划代码,具体的委办局代码如下: 名称 编号 名称 编号 名称 编号 名称 编号 教育局 1001 工商局 1002 工会 1003 环保局 1004 第 页 数据交换平台总体框架设计方案 人事局 1005 公安局 1006 法院 1007 检查院 1008 社保局 1009 司法局 1010 建委 1011 土地局 1012 交换中心 1013 卫生局 1014 交通局 1015 农业局 1016 如果出现某个县或省特有的机构,从4293倒着往下排,以解决各县的特有部门的编号。 之所以采用1000-4293之间的代码,原因如下: l 可压缩存储和加速计算 因为代码将和行政区划代码一起构成一个4G以内的数,保存时,只用4字节,对比时,只对比一个整数。有利于系统的高速运行。 l 和国家标准组织机构代码(9位)兼容 国家标准组织机构代码为9位,而我们设计的编码为10位,且最高位不为0,所以,将来如果扩充,两种编码同时使用。 6.3 TongLINK/Q节点名及队列名的及大小的标准化 l 交换中心的TongLINK/Q节点命名 C+6位市县的行政区代码 如南昌市的TongLINK/Q节点为C360100 l 前置机TongLINK/Q的命名。 Q+部门代码+6位市县区代码 如南昌市东湖区教育局的代码为Q1001360102,其中1001为教育局编码,360102为南昌市东湖区的行政代码 l 发送队列的命名 第 页 数据交换平台总体框架设计方案 S+部门代码+6位市县区代码_1 S+部门代码+6位市县区代码_2 最后的1或2分别代表了实时队列和业务队列。如,发往南昌市工商局的实时队列为S1002360100_1,S代表发送队列,1002代表工商局,360100代表南昌市,_1代表实时。 发送实时队列的空间为10M,10000条消息。业务队列空间为100M,100000条消息。 l 接收队列的命名 R+部门代码+6位市县区代码_1 R+部门代码+6位市县区代码_2 最后的_1或_2分别代表了实时队列和业务队列。如,南昌市工商局的实时接收队列为R1002360100_1,R代表接收队列,1002代表工商局,360100代表南昌市_1代表实时队列。 接收实时队列的空间为10M,10000条消息。业务队列空间为100M,100000条消息。如为中心接收队列,实时为100M,100000,业务队列为1000M,1000000条消息。 l 前置机使用的TCP端口号的标准化 A. TongLINK/Q统一使用TCP端口10340、10341、10342。 B. GTP统一使用10343、10344、10345。 C. 数据库统一使用10346 l 管理中心使用的TCP端口号的标准化 A. GTP管理中心使用8021、8028、9999,其中8021为GTP应用管理、8028为GTP任务管理,9999为所有的日志中心使用。 第 页 数据交换平台总体框架设计方案 B. 管理中心中,如采用多级GTP,则县或市(相对于本中心来说,是本中心管辖范围内的下级的节点)GTP节点采用10343,10344,10345,而本中心向上级传输的GTP使用的端口号为10446、10447、10448。 C. TI监控代理使用端口统一为10566 D. 前置机网络两端的防火墙上要打开10340、10341、10342、10343、10344、10345、9999、10566等8个端口,管理中心还要多打开10446、10447、10448三个端口。 6.4 TongIntegrator配置命名标准化 6.4.1 路由表数据的命名规则 l 数据库中接收其他共享数据的接收路由表名为: TIROUTE_R l 数据库中将本系统数据共享的发送路由表名为 TIROUTE_S 6.4.2 交换中心的TI配置命名 l 路由配置文件命名: 第 页 数据交换平台总体框架设计方案 LY_6位市县的行政区代码.props 如,南昌市的中心路由配置文件为LY_360100.props。 l 路由表的DOTYPE命名为: ROUTE_TYPE 路由表数据对象中的其他字段名,按照路由表的字段名同名大写处理,如:FSDDM,即表中字段FSDDM(发送端代码)。 6.4.3 前置机的TI配置命名 l 影子表到路由表的业务数据发送配置命名: 表名_TORouteS.props 如,假设工商前置上有业务影子表YWB要共享数据,那么将此业务影子表打包数据到路由发送表的TI配置文件名即为:YWB_TORouteS.props。 l 路由表到影子表的业务数据接收配置命名: RouteRTO _表名.props 如,假设工商前置系统有业务影子表YWB,那么将路由接收表中数据解包到业务影子表的TI配置文件名即为: RouteRTO_YWB.props。 l 影子表数据DOTYPE命名: DO_表名 如,假设工商业务系统有业务表YWB,那么将此业务表打包数据TI配置文件中的DOTYPE名,即为:DO_YWB.props。 l 路由数据发送配置命名 第 页 数据交换平台总体框架设计方案 S+6位市县区代码_1.props S+6位市县区代码_2.props 最后的1或2分别代表了实时队列和业务队列。如,省工商发出路由数据的配置文件名为S360000_1.props,S代表发送路由数据, 360000代表省中心,_1代表实时。 l 路由数据接收配置命名 R+6位市县区代码_1.props R+6位市县区代码_2.props 最后的1或2分别代表了实时队列和业务队列。如,省工商发出路由数据的配置文件名为R360000_1.props,R代表接收路由数据,360000代表省中心,_1代表实时。 l 路由表的DOTYPE命名为: ROUTE_TYPE 路由表数据对象中的其他字段名,按照路由表的字段名同名大写处理,如:FSDDM,即表中字段FSDDM(发送端代码)。 6.5 数据库访问的标准化 6.5.1 表的结构标准化 前置机的表名和省交换中心及市交换中心的表名一样,同时表结构一样。 第 页 数据交换平台总体框架设计方案 6.5.2 前置机上的数据库访问的标准化: l 人大金仓:数据库名为jhptqzk l 登录用户名和密码有两种方式: A、 用固定的用户名和密码 B、 将用户名和密码加密后,写在一个文件内,连接时,读取文件 C、 数据库的用户名为u+代码,密码用户一种方法算出。 l 前置机上数据库访问统一使用jdbc,访问地址统一使用127.0.0.1。 6.5.3 交换中心的数据库访问的标准化 l 人大金仓:数据库名为jhptszxk l 登录用户名和密码有两种方式: D、 用固定的用户名和密码 E、 将用户名和密码加密后,写在一个文件内,连接时,读取文件 F、 数据库的用户名为u+代码,密码用户一种方法算出。 l 前置机上数据库访问统一使用jdbc,地址在安装时配置。 第 页 数据交换平台总体框架设计方案 6.6 业务流程命名的标准化 一个业务流程有可能有几段构成,如果命名不规范,会影响开发人员之间的交流及流程的互想合作,所以,业务流程命名必须提前规范好。 建议用业务流程的全拼来命名,中心有数据库专门记载。 6.7 web服务命名的标准化 Web服务名是对外提供的服务,只有标准化之后,才能对外提供正确的、无岐义的服务。 6.8 安装目录的标准化 前置机上,TongLINK/Q和TI按装的操作系统用户名为tlq,组为jhpt,其中,tlq的用户号为369,jhpt的组号为396,安装目录为/home/tlq。GTP安装所用的操作系统用户名为gtp,组为jhpt,gtp的用户号定为393。 在交换中心TongLINK/Q和TI和第一套GTP的安装方法和前置机相同。但交换中心要安装两套GTP,每二套GTP的安装操作系统用户名为gtpc,组名也为jhpt,gtpc的用户号为363。 交换中心采用HA,TongLINK/Q的四个环境变量TLQMSGDIR、TLQRCVFILESDIR、TLQSNDFILESDIR、TLQLOGDIR所指目录应放到磁盘阵列上,磁盘阵列上应切出100G的空间,mount到/tlq下,再在/tlq别建四个文件夹msg、sndfiles、rcvfiles、log,分别对应 第 页 数据交换平台总体框架设计方案 TLQMSGDIR、TLQRCVFILESDIR、TLQSNDFILESDIR、TLQLOGDIR四个环境变量。 第 页

下载文档到电脑,查找使用更方便

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享文档获得金币 ] 47 人已下载

下载文档