数据交换中心的方案设计.docx

数据交换中心的方案设计.docx

《数据交换中心的方案设计.docx》由会员分享，可在线阅读，更多相关《数据交换中心的方案设计.docx（6页珍藏版）》请在冰豆网上搜索。

数据交换中心的方案设计

数据交换中心的方案设计

中关村在线【转载】作者：

2005年01月29日01:

41

   城市电子政务系统是构筑在各个政府部门（局委办）的信息系统之上，是把各个局委办的数据库作为其共享的一部分。

而我国政府的信息系统是在不同时期、由不同的公司、利用不同的工具、在不同的开发平台开发出来的，并且运行在不同的操作系统和不同的数据库平台之上。

这就是"信息孤岛"造成的主要原因。

要建立跨各政府部门的办公平台，实现异构系统之间、新老系统之间的信息的透明交换是基础性工作。

建立安全、稳定、高性能、跨平台、跨系统、跨应用、跨地区的信息交换平台是最重要的软件平台，各行业各部门的系统将统一通过这一平台进行信息交换，以达到整个电子政务网内资源共享互通的效果。

4.3.1信息交换的需求分析

电子政务中信息交换按交换对象分为三大类：

基于政府外网之上的政府部门之间的信息交换

基于政府内网之上的政府内部之间的信息交换

基于Internet网和政府外网之上的政府同企业、市民之间的信息交换

例如，一个城市财政局办理"行政事业性收费"立项的流程可描述如下：

由上图可见，它涉及"事业单位-------政府（财政局）"；政府部门之间，"综合处-------付局长------局长"；政府之间，"财政局------物价局"，"财政局-----财政厅"之间的信息交换。

一个城市的政府机关达几十个（例如武汉市的委局办就有139个）甚至100多个，他门之间的数据交换呈网状交换，如下图所示：

很明显，以局的信息系统即所谓信息孤岛为单位设计同其它局交换的信息交换，其代价、技术的复杂度是相当高的。

这种集成的方式是用手工编程，对每一个单位都要开发一个接口。

如果有N个应用系统需要集成，就需要建立N（N-1）/2个接口程序。

如果一个政府有100个部门，其接口程序的开发工作量是可想而知的。

如果某个单位的信息系统发生变化，则相应的接口都会要进行调整。

根据一项调查，世界上每年花费在应用接口上的维护费就占企业IT投资的30%----40%。

相对这种数据传递接口的方法，最近几年，人们提出了安全总线法和适配器法。

其概念模型描述如下：

在总线上，点之间交换是对等的，若某个节点有故障不影响其它节点之间的通讯。

适配器、总线、控制器一起构成了信息交换平台。

它集中了所有的数据交换接口，进行所有的信息交换及其管理工作，有人也把它叫作政府总线（BUS）。

在可信信息总线拓扑结构中，连接的数量与要连入的应用个数相等。

增加一个节点，增加的连接也只有一个。

通过总线，应用之间的维护、安全控制、信息过滤都变得非常容易。

它不需要的遗留系统进行大的修改或重新开发。

由于个人、企业、政府部门都是用已有的工具或系统设计表格、填写表格、审批表格，所以信息的格式、描述方法、传递方式都是不一样的，常见的记录、传递方式有：

txt,doc,wps,rtf,ppt,xml,htp,pdf,rm,bmp等等。

所以在这种环境下，要进行信息交换是十分困难的。

由于总线思想、XML的出现，计算机系统之间实现统一的信息交换成为可能。

其信息交换可转换成统一的格式，可描述如下：

要进行透明的信息交换要解决一系列技术问题，信息的格式、信息的安全、信息的封装与解码、信息的语义的统一解释，这就是信息的可信交换平台的设计问题。

归纳起来，在设计数据交换时，要解决以下课题：

1}信息交换的语义识别

数据格式、语法所描述的信息应该有效，各种系统在传递、读取、解析和使用文档中的信息时不会产生二义性。

表达的内容、格式能满足所有政府部门各项业务的要求

2}传输的要求

数据格式易于传输，能够实现各个应用系统之间的同步/异步信息交换。

格式技术兼容各种网络系统和通讯协议。

3）安全方面的要求

交换的数据文档需要基于应用系统之间约定的规则进行验证。

要能建立数据格式、数据内容、网络传输等不同层面的安全防护机制。

4）非功能性要求

格式稳定性高，易于管理，有良好的可扩展性和可增长性。

使用该格式可降低政府部门的运作成减少人力资源。

4.3.2信息交换原理

1、信息交换模型

信息交换是通过网络进行的，而网络信息交换有国际公认的OSI（OpenSystemInterconnect）七层模型。

而电子政务信息交换则只注重应用层、表示层，如下图：

在这个模型中，应用系统之间按应用层协议进行通讯，应用系统内部依靠接口提供服务。

而在网络中，为了保证应用系统能理解信息传输的要求，在传输者、接收者之间是以XML作为媒介。

2、政务系统中的信息交换结构

在每个交换节点上，从OSI七层网络模型分析数据交换平台主要是解决应用层和表式层的内容。

为了确定设计交换平台的功能，把表式层按功能划分为内容管理层、数据交换层、数据传输层。

电子政务系中不同局之间的数据交换，由逻辑上同构的许多数据交换节点以对等的方式进行。

在接口系统中定义了每个节点的标准数据交换平台的功能和逻辑表现。

其意义是指：

一方面，它满足接口规范的要求，以规定的接口提供相应的功能；另一方面，在工作过程中需要与另一个结点进行互操作时，另一个结点上的标准数据交换平台也同样是符合规范要求的，双方在对应的协议层次上进行对话。

应用层也是OSI中的应用层。

电子政务系统中的业务应用系统都处在应用层，它们是平台的使用者，它们通过数据交换获得数据，再加工和决策。

数据交换平台把本属各部门的异构数据联结起来，为每个单为的应用系统提供了全局的、透明的数据交换和共享。

在交换平台的支撑下，每个应用系统都可以在统一的接口的基础之上，对政务系统中每一个部门的数据库进行授权访问。

OSI中的表式层在次分为：

内容管理、数据交换

1）、内容管理（表示层）

内容管理层是指内容的表示（存储）、操作（传送）和授权管理等功能。

一个标准数据交换平台的任务可以分为两个方面，一个是对遗留业务系统（LegacySystem）的数据进行整合，为交换和共享做准备；另一个是通过规范化的方式对业务系统提供统一的数据访问支持。

这就要求标准数据交换平台遵从统一的数据表示方式,采用标准的XML表示数据，XML的DTD可根据业务不同而定义。

操作集合：

这是数据交换功能的直接体现，应该包括查询、获取、提交等内容。

授权管理：

它用于规定在具体的数据交换过程中，哪些业务数据能够在多大范围内被何种方式访问到。

数据交换规范中需要给出符合实际业务需求的授权模型，并在此模型下定义相应的管理功能和授权逻辑。

内容管理层在工作过程中，如果有需要跟远端其它数据交换结点进行互操作的时候（如获取数据或者提供数据），通过数据交换层来完成。

在内容管理层提供简单易用的界面方便用户轻松定义各种类型的XML格式文件和二进制文本格式文件。

然后该功能模块会生成对应文件格式的Schema（DTD）和模式文件。

此外，提供验证机制用于检验所建立数据格式模型的正确性。

从功能上，这一层还可细分为以下几个部分：

l图形定义及显示模块：

构造树形图，为每个节点分配属性用以定义数据格式的模型，另一方面通过读入模型的XML描述文件显示模型的树状结构。

XML描述文档及schema生成模块：

需要建模的数据文件主要可分为二进制文件和XML文件两种类型。

XML文件，建模的过程实际上是产生它的schema文件的过程。

二进制格式文件，建模的目的是生成这种二进制格式文件所对应的XML格式文件的schema,因此二进制文件的建模过程可分为两个步骤，第一步将二进制的格式信息转化为XML描述文档，第二步将XML描述文档转化为schema。

l模型验证模块：

对于二进制格式文件，用户可以在建模后输入实际的二进制文件查看对应的XML格式文件，验证所建模型的正确与否。

此外用户也可以查看生成的schema的内容。

lXSLT引擎：

提供符合规范的XSLT转换器，其它功能模块通过调用该引擎完成XML文档的转换。

l文本（二进制）文件到XML文件的转换引擎：

利用XML描述文档将文本（二进制）文件转换为XML文件。

其它功能模块通过调用该引擎完成文本（二进制）文件到XML文件的转换。

2）、数据交换（表式层信息服务的支持）

数据交换层的任务是完成不同数据交换结点之间的互操作，功能上应该包括数据的定位和数据包封装。

数据的封装和解封与操作命令一样，是一个标准数据交换平台的规范性的重要体现。

所有在节点之间传送的数据，包括操作命令本身，都要按照规定的格式进行编排，这样才能保证数据交换节点之间的互操作性，以屏蔽底层的物理特性的多样性。

所以要有好的信息服务机制，必须解决以下的问题：

信息的统一封装，即信息的打包和信封的书写功能

统一编址，应支持一套统一的、简单易用、易扩展、易管理的地址编码体系

信息的可靠传输

传输的效率

可管理性，要对传输的过程进行全程监控，提供日志、审计、会话管理、传输优先级设定、流量负荷分析

2）安全的数据传输（表示层）

数据传输层用于实现数据交换结点之间的数据传输。

在软件层面，重要的一点就是要采用成熟的传输协议，譬如HTTP或SOAP。

HTTP协议具有简单、完备、轻量级、扩展能力强等特点。

较小的传输开销可以保证较强的传输性能，完备的协议规程可以保证传输的稳定性。

同时，通过适当的扩展，可以提高可靠性和安全性。

安全性可以通过引入基于PKI（PublicKeyInfrastructure，公钥体系）的CA（CertificateAuthority，认证中心）体系来解决。

4.3.3数据交换中心的设计

要设计一个数据交换中心，实现政府部门之间的数据的透明交换。

在设计中要考虑三个方面的问题：

信息的统一表示

完整的消息服务能力

功能完备的交换平台软件系统

1、信息的统一表示

要实现信息共享，实现异构系统之间的互联互通，信息的统一表示是关键。

信息的表示应独立于系统、平台。

为了实现这一目标，在进行平台开发、应用系统开发时要制定或遵循六个方面的信息标准：

1）、元语言标准

元语言是描述其它语言的语言。

电子政务的信息表示语言采用XML元语言标准。

该标准用来对政务信息的语言的语法、编码、令名进行行式化描述。

该标准可采用W3C制定的XML元语言标准，设计者应根据电子政务中的信息表示的需求进行裁剪。

2）信息编码标准

该项标准对字符的编码、字符集定义、字符引用、字体的表示进行了规定。

一般采用W3C制订的XML1。

0为基础，以GB13000为缺省的字符集，同时也能支持GB18030字符集标准

3）元数据标准

元数据是描述电子数据的数据，制定该标准是为了方便政府信息资源有效的保存、查询、再利用。

在XML标准中，元数据的表示采用了"词汇表"、"命名空间"、"文档类型定义（DTD）"、XMLSchema等方式实现。

在异构关系数据库之间还可通过建立元模型、元元模型统一数据的语义。

3）显示标准

在电子政务系统中，要将数据和数据的显示分开。

这样就把数据的加工同不同的输出、显示分开处理，而不会造成HTML中文档结构的复杂性。

显示在不同设备上，但内容只有一个。

显示标准一般采用W3C推荐的层叠式样单CSS、可扩充式样单语言XSL。

4）解析、转换和封装标准

要实时共享交换的各种信息，必须具备效率高的数据结构封装、解析、转换的功能，因此必须有相应的标准。

2、完整的消息服务能力

电子政务平台是一个中间件软件，它在信息交换过程中要进行频繁的信息封装、控制信息的同步/异步交换、排队处理等。

所以它要有好的信息服务机制，这就必须解决以下的问题：

信息的统一封装：

信息的打包和信封的书写功能

统一编址：

应支持一套统一的、简单易用、易扩展、易管理的地址编码体系

信息的可靠传输：

将信息可靠的传输到目的地

路由管理：

在多个信息交换节点时，实现信息的准确传递。

传输的效率：

采用信息的表示与交换分开、专用的交换设备、信息压缩等方法提高传输的速度。

可管理性：

要对传输的过程进行全程监控，提供日志、审计、会话管理、传输优先级设定、流量负荷分析

2、信息交换平台的体系结构

实现信息的交换根据环境的不同有三种方式：

1）具有相同数据库管理系统（DBMS）的分布式系统的数据交换，可直接用

相应系统的有关功能：

在ORACLE系统中，可以利用快照技术实现表数据的交换；

在SYBASE系统中，可以利用复制服务器实现数据的交换；

2）利用已有的消息中间件服务器：

IBM的MQSerries、BEAMESSAGE（）以及JAVA的消息服务JMS来实现。

利用IBM的MQSerries进行交换可描述如下：

方案采用IBM著名的Websphere、MQSeries等系列中间件产品构建基于Browser/WebApplicationServer/TransactionServer/Database模式的三层次/多层次应用体系结构，如图所示把交换器配置成IBM的MQSerries。

业务分为实时交换和非实时（脱机）交换处理。

软件配置分为实时交易处理和脱机交易处理两个部分。

实时处理业务通过Websphere及Txseries/CICS交易服务器实现，非实时的业务通过MQSeries的互连，达到安全可靠地交换数据和异步交易处理的目的。

实时处理部分

实时交易处理部分中采用以WEB应用服务器WebsphereApplicationServer、交易服务器Txseries/CICS等中间件为核心的多层次体系结构，以确保系统在大笔交易量情况下的可靠性和快速响应速度。

为了防止交换高峰期间对WEB应用服务器压力过大造成该部分处理能力的瓶颈，数据中心同时配置了多个WebsphereApplicationServer组成群集（Cluster）结构，共同承担来自于前台的业务处理请求，并通过该软件内置的CICSClient接口调用交换服务器的远程调用（RPC）。

在各应用服务器之前配置了WEB负载平衡服务器，WebspherePerformancePack软件包作为负载平衡服务器，统一接受来自于前台的实时数据处理请求，并均匀分配给各WEB应用服务器。

脱机交换处理：

对于所有脱机交易处理，在数据中心配置MQSeriesIntegrator和MQSeries数据传输中间件作为全系统的数据交换中心，承担全系统数据交换的统一平台。

运行在MQSeries基础传输系统之上的MQseriesIntegrator作为全系统数据收发/转发的'网关'和'邮局'，专门用于负责整个网络环境下的数据传递，并作为批量处理系统的前置机接收各下级单位数据交给主业务服务器处理。

考虑到在整个系统需要和税务、公安、卫生等系统实现数据交换，可能包含多个应用子系统，涉及各种不同的具体应用，而各个分布的子系统又需要有数据交换，需要一定程度的数据共享，是典型的松耦合结构（Loosely-coupled），在这样一种架构下，每个子系统的数据结构都不统一，因此需要MQSeriesIntegrator这样的产品，具有能简单灵活地集成各个数据库子系统并自动实现数据采集和分发的功能。

而MQSeriesIntegrator正是具备这一功能的产品。

在数据交换中心除了配置MQSeriesIntegrator和MQSeries之外，同时配置一个数据库专门存放整个系统中各子系统的数据格式描述，数据智能路由的规则描述，这些信息都可以通过MQSeriesIntegrator提供的可视化管理工具动态修改，灵活配置。

此外，各子系统均通过MQSeries与其相连，规范了编程接口，使系统具备最大的可连接能力，在实际应用系统中，各子系统通过MQ编程接口，把自身的数据作为数据源传输至MQSeriesIntegrator，MQSeriesIntegrator采集到该数据后，根据客户自己定义的规则智能地分发给需要该数据的应用子系统，数据的传输依然是基于MQSeries，其它子系统接收到的数据已经是经过MQSeriesIntegrator的格式转换，能直接处理的数据。

所有需要与政务数据中心进行脱机交易、批量数据处理、数据交换的系统均安装MQSeries与数据交换中心相连接（可以是拨号连接、ISDN、DDN、帧中继等任何连接方式），实现与政务数据中心和其他系统的可靠数据交换。

这些系统可能包括政府系统的各个部门。

3）、通用的数据交换器的结构：

在电子政务系统中，多数情况是异构数据库之间的信息交换。

一般要在各单位的服务器上加上工作站适配器（Adapter）实现异构数据交换、安全认证、传输前后的打包、解包等功能。

下图中每一个信息交换平台即为一个适配器。

而适配器间的协调监控由注留在中间件服务器上的相关控制器完成。

3）自成体系的交换平台

利用多层结构体系、J2EE+XML、WebService、数据库等技术，构造数据交换、数据流引擎和数据中心系统，数据交换、数据流引擎与数据中心统一构造为"可信信息交换平台"实现电子公文与政务综合信息的共享和交换，为并联审批等业务提供支持。

本方案有一个数据交换平台和一个任意可装配的适配器组成。

原理图如下

适配器的主要功能设计：

1）信息交换器：

实现不同格式的文件向XML的转换或反之，对大容量文件进行拆分或合并。

2）SOAP服务：

按SOAP格式打包或拆包

3）安全认证：

调用相关API进入CA认证

4）密码服务：

加密、解密或压缩

5）DB访问代理：

对典型数据库提供访问接口（JDBC、ODBC）

6）工作流引擎：

为工作流引擎的同步/异步、协同工作提供服务

平台管理器的主要功能设计：

1）消息管理：

管理消息队列，同中间件服务器中的消息管理协调工作

2）用户管理：

管理联接到服务器的用户，设置访问权限

3）模型管理：

管理根据应用中的表格以及各种表格的转换模型

4）监控管理：

运行状态、运行流量、负载能力、日志等的管理

数据的透明交换涉及数据格式、数据结构、数据语义的统一定义，涉及传输的路由、数据传输的同步/异步、数据传输的负载均衡等技术问题，需在设计时根据具体情况而定。