基于XML 的政府电子公文交换系统规范与设计实现(手抄版).doc

基于XML 的政府电子公文交换系统规范与设计实现摘 要 公文的上传下达是我国各级政府和大型企事业单位中长期依赖的一种工作手段和重要工作内容，传统的公文交换方式主要采用邮递和直接送达方式传递红头文件，但具有速度慢、易泄密、易丢失、成本高等不足，所以，现在已经有许多政府机关和大型企事业单位采用了各种各样的电子公文交换系统，实现公文传递的电子化和即时化，从而大大提高办公效率。本规范以及最终系统的实现都是基于深圳市政府办公厅电子公文交换的需求的设计开发的。通过对Sax、Web Service、Reflection、CA 以及异步引擎等关键技术的充分利用，较成功的解决了系统集成性、数据的安全保密性、电子印章与电子认证的统一以及良好的可扩展性与互联性等问题。 本文首先将描述该规范的制定背景、设计思想、特色以及部分规范样例，然后再描述该交换系统的功能特色、开发模式、系统结构以及关键技术。 关键词：XML，Sax，Web Service，反射，消息队列，CA，异步引擎，委托 The Design and Implementation for XML-based government Electronic Document Exchange System Specification Abstract In Governments at all levels in China and units of large enterprises, Upload documents and the issuance are long-term dependence on a working tool and important element of the work. The traditional official document exchanges a way to mainly adopt postal delivery with directly send to a way to deliver a red head a document, but have shortage of speed slowly and easily divulge a secret, easily throw to lose, cost too much and etc. So, there has been many electronics official documents that the governments and enterprises agencies used various each kind exchanging system now, carry out official document to deliver of electronically with immediately turn, thus greatly improved office efficiency. This instruction and ultimately systems are based on the achievement of the Office of the city government of Shenzhen exchange electronic documents for the needs of the design and development of. We get a more successful solution of system integration, data security and confidentiality, electronic seals and electronic authentication unity and good scalability and connectivity issues by Sax, Web Service, Reflection, CA and asynchronous engines and other key technologies fully utilized. This article will first describe the background of the formulation of the standards, design, features and some normative sample, and then describes the characteristics, development patterns, system architecture and key technologies of the exchange system. Key Words: XML, Sax, Web Service, Reflection, Message Queue, CA, Asynchronous Engine, Delegate xx 目 录1绪论 1.1 课题背景 1 1.2 课题目前研究情况及存在问题 1 1.3 本文结构 2交换网络 2.1 网络构成 2.2 公文交换流程 2.3 交换模式分析 3XML 传输规范 3.1 通用数据传输模型 3.1.1 模型结构 3.1.2 模型组成要素 3.1.3 模型架构图 3.2 基于XML 的电子公文格式规范 3.2.1 业务流转编号规范 3.2.2 附件集定义 3.2.3 公文交换指令 3.2.4 公文业务回执指令 3.2.5 交换回执指令 4系统开发与实现 4.1 开发环境与工具 4.1.1 .NET Framework 开发环境介绍 4.1.2 ORACLE 数据库介绍 4.2 交换系统模块组成 4.3 交换流程 5关键技术 5.1 XML 解析之SAX 5.2 公文收发之Web Service 5.3 系统调度之Reflection小结 致谢 参考文献 1绪论 1.1 课题背景 近年来，随着计算机技术的发展和国内电子政务市场的成熟，越来越多的政府部门开始部署和实施电子政务项目，当前，我国的很多政府部门都上了OA 办公自动化系统，但这也引发了一些问题，如电子公文的安全性、单位与单位之间电子公文如何交换、不同单位之间的电子公文识别等，从全国的角度来看，各个单位之间如何实现电子公文的交流以及电子公文交流的安全性，是关系到电子政务能否在我国成功实施的关键。因此，推行电子政务，实现电子公文交换是国家政府信息化建设的重要组成部分。可以解决传统公文处理中效率低下的“文件批阅”、“文件旅行”现象，使公文处理全自动化真正达到提高办公效率、降低办公成本。这里，既要在电脑网络上实现公文处理全程电子化和无纸化，又要形成对上(中央、国家机关、上级政府)、对下(分支机构)、对左右(兄弟单位)的互联互通。 电子公文交换系统的建设目的，就是按照统一的标准，在不同的政府部门之间进行电子公文的传输，并保证公文在传递过程中的安全性和有效性。采用XML 及相关标准作为电子公文交换的核心表现，融入CA 认证和数字签名、传输加密等多种安全防范措施，构建安全、可靠、标准、开放的电子公文交换系统。 电子公文交换系统建立在政府机关专网和政府已有的内部网络环境之上，连接各区、各委办局已经建立的内部网络办公系统和业务信息系统，构建覆盖跨部门的传输与交换平台。电子公文交换系统依托CA 认证、电子印章、传输加密等技术，实现安全可靠的政府信息交换，把全市甚至全国的政府机关各类应用系统联接起来，发挥更大的作用，提高办公效率，推进政务信息化建设。 1.2 课题目前研究情况及存在问题 “公文管理”是政府机构日常办公的重要业务。在传统的手工作业的公文流转中，存在着低效率、少监督、缺管理的严重弊端，因此，依靠信息技术建立一个高效的电子公文交换系统，对政府公文进行高效有序的电子化处理，成为我国电子政务建设亟待解决的问题。但是，建设一个高效的电子公文交换系统，面临统一文件格式和文件安全传输的现状。 与传统的政府信息化建设相比，当前我国电子政务建设充分强调统一标准、互连互通，以免造成“信息孤岛”。在这种应用背景下，XML1-5的出现给政府公文交换带来了一场革命。根据我国政府的规定，政府电子公文将采用统一的格式，并以XML 来进行描述和交换。因此，电子公文交换系统对XML 电子公文的处理和交换能力便成为整个系统成败与否的关键所在。 但由于目前国内缺少统一的电子公文交换规范，导致许多机构之间的公文无法实现互联互通。当前的电子交换系统的主要问题体现在： 一、 系统功能单一，层次划分不明确； 二、 存在安全隐患，数据传输中要防止数据被截获、解密、窜改； 三、 规划滞后，标准不统一； 四、 电子公文与传统公文传输的并存问题； 五、 电子印章、电子认证与传统印章的统一； 六、 系统的兼容性、可拓展性以及是否可以跨平台等问题。 1.3 本文结构 绪论部分介绍本系统的背景以及目前的研究情况和存在的问题。 第2 章介绍电子公文交换网络、交换模型以及CA。 第3 章介绍通用数据传输模型以及电子公文交换的指令规范。 第4 章介绍交换系统的功能特色、开发模式、系统结构以及关键技术。 第5 章介绍系统开发过程应用到的几点关键技术以及性能评价。 最后总结整个开发过程中的体会与认识。 在附件中，本文还将给出一个电子公文交换的XML 样例以及其他交换指令的规范，以供参考之用。2交换网络 2.1 网络构成 整个电子公文交换网络的由五类交换子系统组成：各OA 的交换系统（OA 交换）、各OA 的前置交换系统、核心的交换接口系统、核心交换系统、CA 认证系统。 2.1 交换网络结构图OA 交换：即各单位 OA 上部署的交换系统，同时也是本文主要论述的交换系统。该系统主要负责为OA 提供电子公文交换的收发文以及相关子服务，属于OA 的子系统，通过OA 前置的Web Service 接口与自身的Web Service7,8接口互联以实现对交换网络挂的接，因此并不属于交换网络的核心组件。 OA 前置：即为 OA 交换提供直接通讯服务的交换系统。该系统仅负责为所连接的 OA 交换提供数据传输服务，其一端通过Web Service 与OA 交换连接，另一端则通过消息队列以及Web Service 两类接口与交换接口连接，属于交换网络的边缘组件。交换接口：即核心交换系统所提供的外接接口系统。该接口连接的两端都同时拥有消息队列（异步交换）或是 Web Service（同步交换）两类接口，其一端与一定区域的 OA 前置通过相连，并为这些 OA 前置提供交换服务以及核心查询服务，另一端则与核心交换相连。交换接口的存在不仅可以保护核心交换不被暴露，同时也可以减轻核心交换的网络压力，属于交换网络的核心组件。 交换核心：即整个交换网络的核心交换系统。该系统为交换网络提供交换路由服务、交换单位管理、交换人员管理、交换跟踪服务、交换指令分析应答服务、交换数据分解合并服务、核心传输服务以及CA 的加解密、数字签名验证等服务。 CA 认证系统：该系统为各单位提供数字签名服务以及数据的加解密服务。该系统仅与核心交换系统相连，所有与CA 认证系统的通讯都必须经由交换网络传送。 图2.2 深圳市政府电子公文交换系统物理结构图2.2 公文交换流程 图2.3 电子公文交换流程结构图电子公文交换的流程可以分为交换数据的生成、数据的签名加密、数据的传输、数据的验签解密、数据入库五个主要步骤。整个交换流程细述如下： 1、OA 端在需要发送电子公文的时候，通过自己的电子公文交换系统（OA 交换）生成原始的交换对象，OA 交换则通过 CA15-18认证系统对该交换对象里的有效数据进行数字签名，并对需要加密的数据区域进行加密。在得到加密后的交换对象后就可以生成交换的XML，并通过Web Service 接口向OA 前置提交该交换数据。 2、OA 前置在收到 XML 后，根据调用类型（同步调用或是异步调用），以相应的交换通道（消息队列或 Web Service）向交换接口提交交换数据，交换接口根据接收的数据，转给交换核心去处理。 3、交换核心在收到交换数据后，分析交换路由，并将密文解成明文。然后将交换数据分成N 份（N=接收单位各数），依次以不同的单位进行数据加密后，将各单位的交换数据向相应的交换接口转发。 4、交换接口在收到交换核心来的数据后，将指定单位的数据发往指定的OA 前置。 OA 前置通过Web Service 最终提交给OA 交换。 以上 4 步即实现了从 OA1 到其他 OA 的公文交换过程，但是这样的交换并不能让 OA1 知道自己的交换是否已送到目标单位、目标单位是否能看到该交换件了。所以在上述的4 个步骤之后，还有交换系统的回执过程： 5、OA 前置在成功提交数据给OA 交换后，会自动反方向的发送一个交换送达的回执。这样，最初的发送方便可以通过这个交换送达的回执知道哪些单位已成功送达。而如果整个交换过程中有任一环节出现问题，那么它的前一个系统则会自动反向发送一个交换失败的回执。 6、即使我们能够知道哪些单位已经送达，哪些单位交换失败了，但我们无法确认这些已送达的单位中，对方的工作人员是否一定可以看到该公文。所以，OA 交换解析了收到的来文并将之入库后，会自动向原发文单位发送一个成功解析入库的回执；而如果解析失败、解密失败、验签失败或是入库失败，则都会向原发文单位发送一个解析失败的回执。 以上6步基本实现了一个电子公文在交换网络中的从传输到最终确认其是否送达以及是否可阅的过程。 2.3 交换模式分析 在交换网络中，数据交换的模式主要有两种：异步交换与同步交换。 异步交换：异步交换最大的特色便是无须等待交换的返回，因此可以进行大数据的传输。以图 2.4 来说明，OA1 首先生成交换的 XML，并通过异步文件传输接口提交给 OA1 前置，此时 OA1 前置在分析完 XML 后便会返回。而数据在交换网络中通过消息队列通道传输到OA2 后，OA2 会返回相关交换回执。OA1 则在收到交换回执后便可以知道OA2 是否已成功收到该文。 1 - 电子公文发送（ W e b S e r v i c e ） 2 - 数据传输（消息队列） 3 - 数据传输（消息队列） 4 - 数据传输（消息队列） 5 - 数据传输（消息队列） 6 - 电子公文发送（ W e b S e r v i c e ） 7 - 交换回执（ W e b S e r v i c e ） 8 - 交换回执（ W e b S e r v i c e ） C同步交换：同步交换最大的特色便是可以立即知道接收单位是否已响应，即整个过程都是即时发生的，因此同步交换在处理大文件时难免会发生响应超时问题（这个在后面将介绍的指令规范中有限定）。以图2.5 来说明，OA1 首先生成交换的XML，并通过同步文件传输接口提交给OA1 前置，此时OA1 在分析完XML 后却没有立即返回，而是继续通过Web Service 通道将数据在交换网络中传输到OA2，OA2 在解析该XML 后会通过该Web Service 层层返回相关数据。OA1 则在收到返回的数据后便可以知道OA2是否已成功收到该文以及OA2 的响应数据了。 1 - 电子公文交换（ W e b S e r v i c e ） 2 - 数据传输（ W e b S e r v i c e ） 3 - 数据传输（ W e b S e r v ic e ） 4 - 数据传输（ W e b S e r v ic e ） 5 - 数据传输（ W e b S e r v i c e ） 6 - 电子公文交换（ W e b S e r v i c e ） 3XML 传输规范 3.1 通用数据传输模型 3.1.1 模型结构 如图3.1 所示，数据传输对象的根节点为POWER_EXCHANGE 表示创智传输对象模型。它包含五类节点： a) EXCHANGE_SERIAL_NO：数据传输序号节点，通过此序号，可以对此次交换的信息进行查询、跟踪以及数据传输之间的关联； b) ROUTER：路由节点，此节点的信息用于数据交换时使用，它包含四个节点： i. SENDER：发送者； ii. SEND_TIME：发送时间； iii. RECEIVERS：接受者，包含多个NODE 节点，每个节点代表一个接受者。 NODE 的属性RID，表示接收编号； iv. RECEIPT：是否需要自动发送回执。（YES/yes/1/TRUE/true：表示需要回执，反之NO/no/0/FALSE/false 不需要回执）； c) OBJECT ：业务数据对象，传输业务数据的载体。一个传输对象 POWER_EXCANGE 可以包含至少一个业务数据对象。OBJECT 包含两个属性： i. NAME：此业务数据对象的名称，是业务数据对象的标示；ii. VERB：业务对象指令或业务动作。用来规范数据交换双方的行为。根据此 VERB，接受方作相应处理。 iii. ENCRYPTED：可选的，缺省值为false OBJECT 包含任意多个ITEM节点，ITEM包含三个属性： i. NAME：ITEM的名称； ii. TYPE：ITEM的类型（包括STRING，INTEGER，DOUBLE，BASE64（base64 编码类型），DATE（类似2008-09-09），TIME（类似16:28:01)，DATETIME（类似2008-09-09 16:28:01)，XML（为XML 结构字符串），ROW行； iii. ROWS：如果类型为行（ROW）时，代表行的数目。如果 ITEM 的 TYPE 属性等于ROW时，那么ITEM节点包含子节点ROW，ROW有一个属性SEQ，代表行的序号。ROW包含任意多的ITEM节点。 iv. FILE：如果类型为BASE64 编码时，代码传输的文件为base64 转码后的文件，那么ITEM节点包含子节点FILE，FILE 有两个子节点，分别为文件名FILE_NAME、扩展名EXT_NAME d) RELA_SERIAL_NOS：与此数据传输对象相关联的数据传输对象编号集合，它们之间用半角逗号(,)格开 e) DIGITAL_SIGN：数据签名信息，它包含四个节点信息： i. SIGN：签名人 ii. SIGN_TIME：签名时间 iii. SIGN_DATA：签名数据 iv. NOTES：备注 图3.2 通用数据传输对象示例3.1.2 模型组成要素 对于该通用数据传输模型，其包括的基本组成要素如表3.1 所示： 因业务需求变化，只需要在通用数据传输模型的基础上拓展具体的指令类型，无需要更改通用数据传输模型的定义 3.1.3 模型架构图 通用数据传输模型由三个部分ROUTER、OBJECT 和DIGITAL_SIGN 组成，其架构模型见图：3.2 基于XML 的电子公文格式规范 3.2.1 业务流转编号规范 1. 业务流转序号编码规则： 业务流转序号（Biz_Exchange_NO）表示同一业务中业务发起方与业务响应方之间数据交换时数据包的匹配序号。该序号由业务发起方生成，业务响应方在序号的基础上加1。其采用32 个字节长的可见字符串，构成方式为： 单位源ID+年+月+日+时+分+秒+毫秒+随机数+发送累加数+往返累加数 SSSSSSSSYYYYMMDDHHMMSSmmmRRRsstt 其中单位源 ID 为业务发起方组织机构代码。随机数为十进制表示的小于 999 的随机产生数字，累加数起始为01 。 如一个业务发起方的源 ID 为 20061001，当前时间为 2003 年 12 月 26 日 09 点 38 分20 秒103 毫秒，随机数为123、累加数为01， 则产生的流转序号为20061001200312260938201031230101；同样响应方产生的消息序号为20061001200312260938201031230102。 2. 全市大办文环境下的业务流转序号增长规则： 1. 往返累加数增长原则： 在任何情况下，凡该文为回复相关指令（如公文回执指令、公文回复指令），则该文的业务流转序号应该为所回复件的业务流转序号的往返累加数加1。如： OA1 发往OA2 的来文为：20061001200312260938201031230101；那么OA2 的回执与回复序号为：20061001200312260938201031230102。 2. 发送累加数增长原则：若该发文是针对同一原件（如同一公文或同一会议通知），则每次发送的时候发送累加数加1（重复发送的不算）。需要注意的是，这里的多次发送并不包括以对以打包的XML 的重复发送，而应该为补发某些单位或原件有修改后的重发等有变动的情况。如： 首次发送该件为：20061001200312260938201031230101；那么第二次发送为：20061001200312260938201031230201。 3. 重发不变原则： 若是一个公文发送失败，无论是系统的自动重发还是人为的手工重发，该件的序号不做修改，确切的说是该件的任何部分都不应做修改。如有修改（如公文重新生成）则参照原则2 更改序号。 3.2.2 附件集定义 附件集在通用数据传输模型中一般是一个单独的 OBJECT 节点（在后文中，此类 OBJECT 节点按企业规范简称为BO），每个BO 节点都有3 个属性，分别是NAME(BO 的名称)、VERB（指令名称）、ENCRYPT（是否传输加密）。 在附件集的指令规范中，定义其BO 的属性为：NAME= Accessories, VERB 与 ENCRYPT继承当前指令的值。 3.2.3 公文交换指令 普通公文交换指令是在发送电子公文业务时使用。接收方应需对指令做来文解析处理。无论数据解析入库是否正常，都应给原发文方返回一个解析回执。而在第一次查看该公文后，应返回一个公文接收回执。其他后续指令视业务需求而定。 公文交换指令规范中，定义其 BO 的属性为：NAME = Document ，VERB = Send_Document，ENCRYPT 的值视业务需求而定。 3.2.4 公文业务回执指令 公文业务回执指令是在是在首次查看收到的电子来文时使用。此时，原公文的接收方需根据业务决定是否接收该公文，而原公文的发送方在收到该公文的业务回执后，系统会根据业务流转号判断出该指令所回执的原公文并做出相应的处理。 公文业务回执指令规范中，定义其 BO 的属性为：NAME = Document，VERB = Receipt_Of_Send_Document，ENCRYPT 的值视业务需求而定。 3.2.5 交换回执指令 交换回执指令是交换网络针对其网络上所注册的各类异步业务指令做出的一种确认指令。通过该指令，原异步业务指令发送方可以知道其所发送的指令是否成功送达到目的地。 交换回执指令规范中，定义其 BO 的属性为：NAME = Exchange，VERB = Receipt_Of_Exchange，ENCRYPT = False。4系统开发与实现 4.1 开发环境与工具 4.1.1 .NET Framework 开发环境介绍 .NET Framework12 是支持生成和运行下一代应用程序和 XML Web services 的内部 Windows 组件。.NET Framework 旨在实现下列目标： 提供一个一致的面向对象的编程环境，而无论对象代码是在本地存储和执行，还是在本地执行但在 Internet 上分布，或者是在远程执行的。 提供一个将软件部署和版本控制冲突最小化的代码执行环境。 提供一个可提高代码（包括由未知的或不完全受信任的第三方创建的代码）执行安全性的代码执行环境。 提供一个可消除脚本环境或解释环境的性能问题的代码执行环境。 使开发人员的经验在面对类型大不相同的应用程序（如基于 Windows 的应用程序和基于Web的应用程序）时保持一致。按照工业标准生成所有通信，以确保基于.NET Framework的代码可与任何其他代码集成。.NET Framework具有两个主要组件：公共语言运行库和.NET Framework类库。公共语言运行库是.NET Framework的基础。您可以将运行库看作一个在执行时管理代码的代理，它提供内存管理、线程管理和远程处理等核心服务，并且还强制实施严格的类型安全以及可提高安全性和可靠性的其他形式的代码准确性。事实上，代码管理的概念是运行库的基本原则。以运行库为目标的代码称为托管代码，而不以运行库为目标的代码称为非托管代码。.NET Framework的另一个主要组件是类库，它是一个综合性的面向对象的可重用类型集合，您可以使用它开发多种应用程序，这些应用程序包括传统的命令行或图形用户界面（GUI）应用程序，也包括基于ASP.NET所提供的最新创新的应用程序（如Web窗体和XML Web services）。.NET Framework可由非托管组件承载，这些组件将公共语言运行库加载到它们的进程中并启动托管代码的执行，从而创建一个可以同时利用托管和非托管功能的软件环境。.NET Framework不但提供若干个运行库宿主，而且还支持第三方运行库宿主的开发。例如，ASP.NET承载运行库以为托管代码提供可伸缩的服务器端环境。ASP.NET直接使用运行库以启用ASP.NET应用程序和XML Web services(本主题稍后将对这两者进行讨论)。Internet Explorer是承载运行库（以MIME类型扩展的形式）的非托管应用程序的一个示例。使用Internet Explorer承载运行库使您能够在HTML文档中嵌入托管组件或Windows窗体控件。以这种方式承载运行库使得托管移动代码（类似于MicrosoftActiveX控件）成为可能，不过它需要进行重大改进（如不完全受信任的执行和独立的文件存储），而这种改进只有托管代码才能提供。下面的插图显示公共语言运行库和类库与应用程序之间以及与整个系统之间的关系。该插图还显示托管代码如何在更大的结构内运行。4.1.2 ORACLE数据库介绍ORACLE19是以高级结构化查询语言（SQL）为基础的大型关系数据库，通俗地讲它是用方便逻辑管理的语言操纵大量有规律数据的集合。是目前最流行的客户/服务器（client/server）体系结构的数据库之一。ORACLE数据库有如下特点：1、 ORACLE7.X依赖引入了共享SQL和多线索服务器体系结构。这减少了ORACLE的资源占用，并增强了ORACLE的 ，使之在低档次软硬件平台上用较少的资源就可以支持更多的用户，而在高档平台上可以支持成百上千个用户。2、 提供了基于角色（ROLE）分工的安全保密管理。在数据库管理功能、完整性检查、安全性、一致性方面都有良好的表现。3、 支持大量多媒体数据，如二进制图形、声音、动画以及多维数据结构等。4、 提供了与第三代高级语言的接口软件PRO*系列，能在C、C+等主语言中嵌入SQL语句及过程化（PL/SQL）语句，对数据库中的数据进行操纵。加上它有许多优秀的前台开发工具如POWER BUILD、SQL*FORMS、VISIA BASIC等，可以快速开发生成基于客户端PC平台的应用程序，并具有良好的移植性。5、 提供了新的分布式数据库能力。可通过网络较方便地读写远端数据库里的数据，并有对称复制的技术。4.2交换系统模块组成OA交换系统主要由九大模块构成：OA（WEB层）、OA数据交换层、交换对象层、数据转换层、交换数据服务层、交换数据库、交换引擎、交换接口（Web Service）以及交换管理（WEB层）。交换系统的九大模块的相互调用关系以及各自的主要功能可由图4.1看出。1、 OA(WEB层)：这一层其实就是OA系统与电子公文交换有关的表现层，也可以直接理解为OA系统。该层负责了电子公文的草拟、编辑、审批、报送、套红、核稿、签发等一系列的前期准备工作，同时也可以通过交换的接口获取与具体公文相关的所有交换信息，并对之进行相关管理。2、 OA数据交换层：这是OA与交换系统进行电子公文交换时的衔接层，它直接引用了交换系统的交换对象层。在发送电子公文的时候，通过对具体交换指令的调用，该层初始化一个具体的交换指令对象，并从OA的数据库中获取与交换有关的数据完成对交换指令对象的填充；而来文时，该层在收到交换对象层发射过来的交换指令对象后，负责将交换指令对象里的数据写入OA的数据库并完成相关公文的关联以及对相关当事人的通知等业务。上面介绍的两个层都是各单位自己的OA为了与交换系统连接所必须添加的层，其具体实现都不属于电子公文交换系统。电子公文交换系统真正负责的是剩下的七大模块，这七大模块实现了电子公文交换系统的核心功能以及部分拓展，并为各OA预留了大量扩展接口，并通过反射技术与OA进行衔接，使得该系统可以与大多OA进行整合，从而使OA实现电子公文的收发。3、 交换对象层：该层完成了对当前所定义的所有交换指令的编码，使各种指令在程序中表现为具体的交换指令对象，使得编码人员无需了解具体的公文交换业务与交换指令规范，大大方便了开发人员的编码。所有这些交换指令对象都是通过继承通用数据传输对象来实现的，这在一定程度上方便了交换系统与OA的集成，同时也满足了OA对交换指令的扩展需求。4、 数据转换层：在这一层里，定义了一个XML的Sax读写的模块BussinessObjectHelper,简称BOHelper。该模块实现了通用数据传输对象与符合指令规范的XML之间的相互转换，是整个系统的核心模块之一。之所以选用操控性远不如DOM的Sax，是因为Sax可以以很小的内存消耗解决超大XML的读写问题，这样的做法不仅可以为服务器有限的资源节省更多的内存，同时也保证了指令规范中对大文件以及大附件传输的需求。而另外的一个模块就是各业务指令对象与通用数据传输对象之间的相互转换了。因此我们可以想象，在发文的时候，其实从交换对象层传来的业务指令交换对象首先被转换成了通用数据传输对象，然后再被转换成具体的XML传输数据；而来文时，这一过程刚好反过来了。在进行数据转换工作的同时，一组记录了与此次转换有关的交换数据的交换记录对象也被生成，并与转换后的对象一起传送到下一层。5、 交换数据服务层：这是整个交换系统的核心部分。这层不仅衔接了整个交换系统的各层，使之能够顺利的完成各种电子公文交换任务，同时也提供了与交换有关的所有交换服务。包括交换单位与单位编码的转换与识别、交换序号与业务流转序号20的产生于识别、交换记录的查询与处理、交换指令的分析、业务资料的管理、业务的调度、交换配置的动态管理、日志的管理、交换数据的同步、数据的格式化服务、文件管理服务以及反射服务等。正是这些基础服务的存在，不仅支撑了交换系统的正常运行，同时也使得交换系统拥有了良好的可配性以及扩展性，能够满足许多严苛的需求。6、 交换数据库层：对交换系统而言，定义了四个主要的交换表，分别是交换主表（负责记录所有发生的交换记录）、交换分发表（记录了每个交换记录所涉及的交换单位的交换状态以及与其交换有关的所有业务状态）、单位信息同步表（记录了当前交换核心下的交换网络上的所有交换单位信息）以及交换日志表（记录各交换记录产生的交换日志）。而这一层则是提供对这些表的访问所需的所有接口以及这些交换表的维护服务。7、 交换引擎：这一层提供了交换系统的时钟引擎服务6,交换系统的各种同步任务以及数据维护任务都得在这注册，同时也提供对各种扩展任务的注册。而这一层的核心功能却是对交换的异步调度9。大家都知道，当一个交换数据如果达到很大，比如800MB的时候，那么这样的一个数据如果要进行交换则是一件非常消耗时间的事情。操作人员不可能也不愿意长时间的盯着操作界面以等待结果，操作人员真正关心的是，它最终交换成功了吗？如果交换失败了，失败原因是什么？因此像这样的大型数据或者是消耗时间的调度都是在这一层进行异步调度的。这一层定义了3大交换队列：等待队列、工作队列以及失败队列。所有的调度任务都是从等待队列进入，在当前还有剩余工作线程的情况下，等待的任务将进入工作队列，并开始执行。一旦调度出错，则将该任务投入失败队列等待下次调度，直到该任务彻底失败或是成功。8、 交换接口（Web Service）：这是交换系统与交换网络上的OA交换前置的连接层10。该层提供了大文件的异步收发接口、大文件的校验接口以及同步调用的收发接口。其中，通常情况下的收文接口都是通过交换管理的WEB层上的Web Service页面来实现数据接收的。9、 交换管理（WEB层）：该层主要是为交换系统管理员以及OA的交换开发人员提供的一个WEB11界面。该层提供了交换引擎管理、交换队列管理、单位同步管理、交换记录管理、交换日志管理以及交换配置管理这六大主要的管理功能。能够满足大多数情况下的交换状态监控以及开发调试任务。4.3交换流程从交换的调度方式上，交换可以分为两类流程：异步调度流程与同步调度流程；而从交换方向上又可以分为：发文流程与收文流程。以发文流程为例：从公文签发开始，OA数据交换层收到OA的电子公文发送指令，此时OA数据交换层完成对电子公文指令对象的业务数据填充，然后交换系统的数据转换层会为传来的电子公文指令对象填充必要的交换信息-从交换数据服务层提供的服务获取。指令对象在数据填充完毕后会被转换成相应的XML数据，并生成与之有关的一组交换记录后，这些数据被传入交换数据服务层。此时交换数据服务层会先将数据存入交换数据库，然后分析该交换的类型，选取调度方式。凡异步调度的则投入到交换队列，由交换引擎去管理最终的发送过程，而同步调度的则直接通过调用交换接口，将数据向外发送，并将返回的数据层层返回给OA界面。收文流程基本上可以看作是发文流程的反向过程，区别在于最终是在OA的数据交换层完结。上面介绍的仅仅是发送一个公文或是接收一个公文，其实真正一个公文的收发过程远没有这么简单。对于一个完整的公文交换过程是：首先OA1向OA2发送公文（这里仅取一个接收单位），OA2在接收到OA1的公文后，OA2的前置会向OA1发送交换回执，表示OA2已经收到该文，否则OA1将收到一个由交换网络发来的交换失败回执；在OA2成功将来文解析并入库后，OA2的交换系统会返回一个解析回执给OA1，表示来文一切正常。此时，OA1的发文过程才算真正完成，但对于该公文的交换过程却还不算结束。根据业务需求，OA2在首次打开该电子公文的时候，需要回一个业务回执给OA1；OA2在处理完该公文后需要给业务回复；OA1可以通过办文状态查询指令查询OA2的办文状态；OA1可以在OA2超期后进行催办督办等。5.关键技术在本次系统开发的过程中，先后应用到了许多关键技术。其中最突出的几大技术有：Sax、Web Service、反射、消息队列、异步引擎、委托等。这几项技术不仅成功的与交换系统融为一体，而且还特别针对本次系统进行了二次开发，更使得这些技术别具特色。比如：1、 Sax与通用数据传输模型的整合而成的BOHelper，更具指令通用特性；2、 在Web Service上进行超大文件的传输、数据校验、多线程的单任务并发、单点扩散、流量控制、性能控制等；3、 反射技术的应用使得交换系统能够成功的与各类OA进行整合而无需二次开发；4、 消息队列的自定义的外封事务大大减少了仅依靠原事务所带来的内存压力；5、 异步引擎与委托则在系统性能与任务并发之间做到了良好的平衡，在解决了许多系统前台不方便处理的任务的同时，还良好的支持了自定义任务的注册等。在这一章里，将会特别介绍XML解析所用到的Sax技术、交换网络数据传输所用到得Web Service以及使交换系统更具通用性的反射机制。5.1XML解析之SAXSAX是Simple API for XML的缩写，它并不是由W3C官方所提出的标准，可以说是“民间”的事实标准。实际上，它是一种社区性质的讨论产物。虽然如此，在XML中对SAX的应用丝毫不比DOM少，几乎所有的XML解析器都会支持它。与DOM比较而言，SAX是一种轻量型的方法。我们知道，在处理DOM的时候，我们需要读入整个的XML文档，然后在内存中创建DOM树，生成DOM树上的每个Node对象。当文档比较小的时候，这不会造成什么问题，但是一旦文档大起来，处理DOM就会变得相当费时费力。特别是其对于内存的需求，也将是成倍的增长，以至于在某些应用中使用DOM是一件很不划算的事（比如在applet中）。这时候，一个较好的替代解决方法就是SAX.SAX在概念上与DOM完全不同。首先，不同于DOM的文档驱动，它是事件驱动的，也就是说，它并不需要读入整个文档，而文档的读入过程也就是SAX的解析过程。所谓事件驱动，是指一种基于回调（callback）机制的程序运行方法。在XMLReader接收XML文档，在读入XML文档的过程中就进行解析，也就是说读入文档的过程和解析的过程是同时进行的，这和DOM区别很大。解析开始之前，需要想XMLReader注册一个ContentHandler，也就是相当于一个事件监听器，在ContentHandler中定义了很多方法，比如startDocument（），它定制了当在解析过程中，遇到文档开始时应该处理的事情。当XMLReader读到合适的内容，就会抛出相应的事件，并把这个事件的处理权代理给ContentHandler，调用其相应的方法进行响应。前文已经介绍过，Sax加入的最大优势就是降低了服务器的内存消耗，同时使得交换系统能够支持对大文件的交换。5.2 公文收发之Web ServiceWeb Service是一个应用组件，它逻辑性地为其他应用程序提供数据与服务。各应用程序通过网络协议和规定的一些标准数据格式（HTTP、XML、SOAP）来访问Web Service，通过Web Service内部执行得到所需结果。Web Service结合了基于组件开发各个方面的特点、网络技术和.NET程序模型的基础。Web Service是一种构建应用程序的普遍模型，它可以在任何支持网络通信的操作系统中实施运行。Web Service可以接受和生成Message（消息），Message的形式严格定义了Web Service接口。只要用户能生成和使用Web Service接口所规定的Message，便可以在任何平台上通过程序化语言来执行Web Service。当构建和使用Web Service时，会遇到几个关键的技术和规则：1、 XML:描述数据的标准方法。2、 SOAP:一种普遍、扩展的Message格式，是表示信息交换的协议。一方面定义了怎样使用XML表示数据的规则；另一方面规定了扩展的Message格式。用SOAP Message格式来表示远程调用的公约，并和HTTP协议绑定在一起（微软公司预测SOAP将成为Web Service通信的标准Message格式，且可与其他的协议进行交换）。3、 WSDL:用于编写Contracts，是一种普遍、扩展的服务性语言。4、 Disco：发现并找到某个特定网站的服务方法。5、 UDDI:找到服务器驱动器（Service provider）的方法。WSDL是以XML为基础的一种契约语言，是由微软公司与IBM公司联合开发的。Disco定义的是一种找到已知URL的服务方法协议。UDDI是在不知道URL时，UDDI规定了服务驱动器（Service Provider）向网上广播的机制，能向网上的应用程序提供服务驱动器中已有的服务。在核心结构中，Web Service是标准网络协议规定的一种开放性事务结构处理函数，它起中心纽带作用。Web Service可通过防火墙通信，因为采用了HTTP传输机制，在一个简单的网络应用中可构造多个Web Service。当然Web Service还有安全机制，可采用Secure Socket Layer（SSL）协议技术或标准的验证网络技术。中心纽带功能：1、 利用HTTP作为传输协议，透过企业的防火墙允许远程请求。2、 为了安全性，应用支持SSL协议的技术和标准的网络验证技术。3、 不需要特别的组件技术或对象调动机制。即任何语言编写的程序，使用了任何组件模型，在任何操作系统上运行，均可访问Web Service。大体上说，Web Service是一种可作为服务传递的简单应用程序，这种服务还可以通过Internet标准与其他Web Service相结合。也就是说，Web Service是一种URL地址资源，通过URL可程序化地把信息返回给需要获取这种资源的客户端。Web Service的一个重要特点是客户端不需要知道服务端是怎样运行的。Web Service包含了黑匣子的功能，能被反复调用，而不必考虑服务器是怎样运行的。Web Service提供了被称为契约的接口，其中描述了Web Service提供的服务。开发者可以结合远程服务、本地服务和习惯编码来组装应用程序。例如：公司可以形成一个在线的存储库，使用身份验证服务、微软的护照服务或网页个性化服务来组建。与现有组建技术不同的是：Web Service使用特别的对象模型协议（DCOM,RMI），不需要服务器和客户机有特定的、同类的外部结构。它采用一个不同的方法，通过已存在的网络协议和数据格式（HTTP、XML）进行通信，只要系统支持网络标准，它就支持Web Service。Web Service模型所要求的基础结构至少要确保能在任何平台、以任何技术和任何程序语言执行。Web Service兼容性的关键只依靠Web标准。然而，如