公文流转系统分析与设计论文.doc

学士学位毕业论文
目 录
摘要 1
1 公文流转概述 2
1.1 公文流转的基本概念 2
1.2 公文流转系统的发展历程 2
1.2.1 公文流转系统的现状 2
1.2.2 公文流转系统的发展趋势 3
2 系统所涉及的技术原理 4
2.1多层分布式应用体系 4
2.1.1多层分布式应用体系相关概念 4
2.1.2 多层分布式应用体系主要特点 4
2.1.3 多层分布式应用的开发 5
2.2 中间件 5
2.2.1 中间件的基本概念 5
2.2.2 中间件的分类 5
2.3 ADO技术原理 6
2.3.1 ADO基本概念 6
2.3.2 ADO的企业特性 7
2.4 COM+技术原理 7
2.4.1 什么是COM+ 7
2.4.2 COM+基本体系结构 7
2.5 多线程技术原理 8
3 系统设计分析 9
3.1 系统的可行性分析 9
3.2 系统的总体需求分析 9
3.3 系统的功能分析 9
3.3.1 收文管理 9
3.3.2 发文管理 9
3.3.3 公文审批 10
3.3.4 文档管理 10
3.3.5 公文追踪 10
3.4 系统所需环境的分析 10
3.4.1 硬件环境 10
3.4.2 软件环境 10
4 关键技术和算法 11
4.1 COM+应用系统架构的实现 11
4.1.1 服务器端实现 11
4.1.2 客户端实现 11
4.1.3 管理和分发COM+应用系统 12
4.2 公文动态追踪算法 13
4.2.1 算法设计 13
4.2.2 算法实现 13
4.2.3 运行的结果 15
4.3 公文审批算法 15
4.3.1 算法设计 15
4.3.2 算法实现 15
5 系统实施 17
5.1 登录的实施 17
5.2 主界面实施 18
5.3 公文审批实施 19
5.4 审批意见填写实施 20
5.5 公文追踪实施 20
6 小结 20
参考文献 21

第 32 页
公文流转系统的分析和设计

【摘要】
本文主要阐述有关公文流转的基本概念，公文流转系统的发展历程，以及它的最新发展趋势,并详细介绍多层分布式应用体系、中间件、ADO以及COM+的概念及相关技术实现的原理。介绍了系统的需求分析与功能分析。还详细论述设计中的关键技术与算法：COM+应用系统架构的实现、公文追踪算法的实现、公文审批算法的实现，以及系统的具体实施。

【关键词】
公文流转,COM+,多线程

Document Flow System Analysis and Design

【Abstract】
The disquisition not only tells the conception of document flow, but also introduces the phylogeny and the newest development direction of document flow . meanwhile, it explicates the conception of multitires system、ADO and COM+ ,and the theory of the interrelated technology. It mentions the demand analysis and the function analysis of system and arguments the key technology and arithmetic in the system, such as the implement of COM+、the arithmetic of document track and the arithmetic of document approve and so on.

【Keywords】
Document Flow ,COM+, Multiply-thread

1 公文流转概述
1.1 公文流转的基本概念
公文就是各部门实施领导,处理公务的具有特定效力和规范格式的文书,一般分为内部公文和外来公文,而公文流转就是指从公文起草、请办、批办、传阅、签办、办理、催办、会签、下发、归档、查询、一直到统计这一系列流动过程。一般的公文流转流程主要分为四个公文处理过程。它们分别是：收文管理、发文管理、案卷管理、文件处理统计。而公文流转系统又主要分为两个版本的，分别是企业版和政府版。
1.2 公文流转系统的发展历程
1.2.1 公文流转系统的现状
众所周知，公文流转是办公自动化的重要组成部分。办公自动化（OA，Office Automation），是70年代中期发达国家为解决办公业务量急剧增加而对企业生产率产生巨大影响问题的背景下发展起来的一门综合性技术[1]。它的基本任务是利用先进的科学技术，使人们借助各种设备解决对一部分办公业务的处理，达到提高生产率、工作效率和质量、方便管理和决策的目的。OA的知识领域覆盖了行为科学、管理科学、社会学、系统工程学等学科，并且OA体现了多学科的相互交叉、相互渗透性，所以OA的应用是企业管理现代化的标志之一。
中国的办公自动化软件系统起源于政府的公文和档案管理。由于计划经济体制的影响，政府对企业的管理出了依靠法律、法规之外，还有大量的行政指令和指示。企业在进行许多决策的时候，也经常需要向主管的政府部门请示汇报。另外，当时的政府官员和企业领导经常是你来我往难以分辨，并且存在着比较严格的对应关系，即企业领导和政府官员行政级别挂钩，因此在企业应用红头文件就比较自然。
此时的办公自动化系统的特点：以公文处理、档案管理为核心的办公管理系统。其实办公其实就是办文。其主要的功能包括：
收文管理、发文管理、会议管理、档案管理等内容。管理的中心内容是依据国家的公文管理办法和档案管理法规以及各部委或者行业的档案管理规定的需要存档的文件以及企业内部的其他文件等。
各地政府机关和企业主管部门一般根据国务院下发的关于公文管理的行政法规制作出相应的执行措施，基本保持系统内的一致性，规范了办公中的公文处理和档案管理流程。同时也起到了的内部信息沟通、上行下达以及和上级主管部门的沟通作用。因为采用电脑和网络进行处理，提高了工作效率，减少了纸张浪费。
尽管如此，由于大部分企业的组织架构都有明显的层级结构，传统的办文程序，从文件起草、审阅、会签、签发、下发到归档、借阅等各个环节，存在流程复杂，流转时间长，导致办公效率低，决策缓慢等问题。
由于在机构和流程上很难作很大的改动，因此解决之道就是采用先进的计算机和网络技术，不仅将办公内容电子化，而且实现整个办公过程电子化，从根本上改变了传统的工作模式。办公者可随时了解文件到达哪里，办理的情况怎样，对逾期没有办理的文件，可以自动催办，文件办理完毕，可以自动归档，归档后的文件可供借阅和调阅等，消除手工工作过程中的存在流转时间长，文件去向不明以及不便于跟踪等问题。
虽然公文流转系统随着办公自动化系统的发展得以明显的进步，其基本功能都实现了，但是在某种程度上说现在公文流转系统还都不是那么完善，还有许多不足，还需要不断改善。
1.2.2 公文流转系统的发展趋势
事实上，现在的办公已经不再是简单的文档处理，不再是单纯的行政事务了。现代办公的任务是提高整个企业的运作效率，进而提高企业的核心竞争力。 知识管理可以帮助企业解决知识共享和再利用的问题。知识管理是一个系统工程，目标是帮助企业发现潜在知识、定位拥有专门知识的人、传递知识和有效利用知识。知识管理意味着在恰当的时间，将正确的知识传给正确的人，使他们采取最适合的行动，避免重复错误和重复工作。知识管理关注在如何获取、组织、利用和传播散布在企业信息系统和人们头脑中的知识。实际上，无论实时交流、信息集成还是门户建设都是指知识管理。因此将来的办公自动化系统的核心是知识，实现的基础技术是知识管理。
同样现在以及未来的公文流转系统，也需要在现有的办公自动化系统的发展基础上得以进一步的发展。综观现在国内外的公文流转系统以及办公自动化系统中的公文流转，能够轻易的发现未来的公文流转系统朝着以下几方面发展：
(1)集成。现代企业和许多政府除了拥有公文流转系统之外，还有许多其他的管理系统。由于大量的信息孤岛式的建设，他们之间很少能够紧密协调起来。就前端来说，经常需要进行退出一个系统然后再进入另一个系统，并且发现数据常常不一致，可以比较肯定地说，目前中国具有信息系统的企业和政府绝大部分都是这种情况。他们往往具有多个供应商提供的多个系统，但很少集成。也有少数企业采用ERP套件，集成了其中的一部分，全部集成的企业凤毛麟角，也可能正在产生之中。因此，现在或者未来所需的公文流转系统是需要一个能够集多种功能于一体的系统。
(2)完全基于WEB。从目前用户的使用技能和接受程度以及系统的维护成本考虑，WEB界面最容易接受。另外从集成方面来讲，必须采用人人支持的web标准如HTML，JavaScript，Activex，IIOP，DHTML，XML,JAVA等才能在一个界面下容纳，否则的话，技术难度就会导致集成不可能实现。
(3)流程优化。对于流程，熟悉公文流转系统的人就会想起收发文的流程。那是非常完善的、符合层级结构的、效率低下的流程。对于如何优化该流程，如果基于原有的思维模式和知识领域，就无法获得更多。必须基于现代的流程管理思想对目前的业务流程进行重组。
(4)基于知识。进入知识经济时代，人人都是知识工作者，要求公文流转系统必须具有知识内涵，或者说是基于知识。提供知识管理所需的最基本的IT工具，知识存储库和知识交流场所，更高级的意义上提供，基于知识的岗位要求和评估体系。
2 系统所涉及的技术原理
2.1多层分布式应用体系
2.1.1多层分布式应用体系相关概念
所谓多层体系构架，就是把一个应用程序按功能划分成不同的逻辑组件，具有特定功能的应用程序中的一部分称为一层。典型的多层体系一般为把一个应用程序分为三层[2]：
数据服务层：实现数据定义、存储、备份、检索等功能，主要由数据库系统实现。通常，它可以是一个R D B M S，如Microsoft SQL Server 、O r a c l e或I n t e r B a s e。
业务处理层：业务层负责从数据层获取适当格式的数据并执行最后的合法性检查(也叫做执行业务规则)。实现客户的全部业务逻辑，由于在中间，也叫中间层。
用户服务层：提供信息浏览，服务定位。主要是实现用户界面，并保证用户界面的友好性、统一性，所以也叫做G U I层 ，它总是与业务处理层打交道，它从不直接与数据服务层打交道。
2.1.2 多层分布式应用体系主要特点
安全性：中间层隔离了客户直接对数据服务器的访问，保护了数据库的安全；
稳定性：对于要求24*7工作的业务系统，多层分布式体系提供了更可靠的稳定性：1、中间层缓冲Client与数据库的实际连接，使数据库的实际连接数量远小于Client应用数量。当然，连接数越少，数据库系统就越稳定。2、Fail/Recover机制能够在一台服务器当机的情况下，透明地把客户端工作转移到其他具有同样业务功能的服务上。
易维护：由于业务逻辑在中间服务器，当业务规则变化后，客户端程序基本不做改动；
快速响应：通过负载均衡以及中间层缓存数据能力，可以提高对客户端的响应速度；
系统扩展灵活：基于多层分布体系，当业务增大时，可以在中间层部署更多的应用服务器，提高对客户端的响应，而所有变化对客户端透明。
2.1.3 多层分布式应用的开发
分布式多层体系的开发主要考虑三方面的技术，首先是开发环境，开发人员需要一种创建新组件、并将已有组件加以集成的开发环境。其次是应用程序的集成，开发人员需要集成各种应用程序，以创建出更强大的应用。第三是应用程序的配置，分布式多层体系的开发需要配置平台的支持，以便在用户剧增时能有效地扩展，并保持系统的稳定。
目前多层分布应用的开发，比较重要的有三种规范，既COM+、CORBA以及JavaBean。同时，随着分布式应用的发展，旧的硬件/软件平台的不断更新，跨硬件平台、网络环境、操作系统以及跨不同数据库的应用系统不断出现，使传统的开发工具越来越陷入尴尬境地，因此中间件应运而生。
2.2 中间件
2.2.1 中间件的基本概念
中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。中间件位于客户机服务器的操作系统之上，管理计算机资源和网络通信。中间件也是一类软件，它的首要任务是实现应用与平台无关的互操作，其次能够合理的管理网络通信资源。
从理论上讲，中间件有以下的工作机制：客户端上的应用程序需要从网络中的某个地方获取一定的数据或服务，这些数据或服务可能处于一个运行着不同操作系统和特定查询语言数据库的服务器中。客户/服务器应用程序中负责寻找数据的部分只需访问一个中间件系统，由中间件完成到网络中找到数据源或服务，进而传输客户请求、重组答复信息，最后将结果送回应用程序的任务。
2.2.2 中间件的分类
(1) 远程过程调用.
远程过程调用是一种广泛使用的分布式应用程序处理方法。一个应用程序使用RPC来“远程”执行一个位于不同地址空间里的过程，并且从效果上看和执行本地调用相同。事实上，一个RPC应用分为两个部分：server和client。server提供一个或多个远程过程；client向server发出远程调用。server和client可以位于同一台计算机，也可以位于不同的计算机，甚至运行在不同的操作系统之上。它们通过网络进行通讯。相应的stub和运行支持提供数据转换和通讯服务，从而屏蔽不同的操作系统和网络协议。在这里RPC通讯是同步的。采用线程可以进行异步调用。
在RPC模型中，client和server只要具备了相应的RPC接口，并且具有RPC运行支持，就可以完成相应的互操作，而不必限制于特定的server。因此，RPC为client/server分布式计算提供了有力的支持。同时，远程过程调用RPC所提供的是基于过程的服务访问，client与server进行直接连接，没有中间机构来处理请求，因此也具有一定的局限性。比如，RPC通常需要一些网络细节以定位server；在client发出请求的同时，要求server必须是活动的等等。
(2）面向消息的中间件
MOM指的是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可在分布环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。目前流行的MOM中间件产品有IBM的MQSeries、BEA的MessageQ等。
(3) 对象请求代理
随着对象技术与分布式计算技术的发展，两者相互结合形成了分布对象计算，并发展为当今软件技术的主流方向。1990年底，对象管理集团OMG首次推出对象管理结构OMA(Object Management Architecture)，对象请求代理（Object Request Broker）是这个模型的核心组件。它的作用在于提供一个通信框架，透明地在异构的分布计算环境中传递对象请求。CORBA规范包括了ORB的所有标准接口。1991年推出的CORBA 1.1 定义了接口描述语言OMG IDL和支持Client/Server对象在具体的ORB上进行互操作的API。CORBA 2.0 规范描述的是不同厂商提供的ORB之间的互操作。
(4) 事务处理监控
事务处理监控（Transaction processing monitors）最早出现在大型机上，为其提供支持大规模事务处理的可靠运行环境。随着分布计算技术的发展，分布应用系统对大规模的事务处理提出了需求，比如商业活动中大量的关键事务处理。事务处理监控界于client和server之间，进行事务管理与协调、负载平衡、失败恢复等，以提高系统的整体性能。它可以被看作是事务处理应用程序的“操作系统”。
2.3 ADO技术原理
2.3.1 ADO基本概念
ADO是Microsoft目前主要的数据存取技术。ADO是Microsoft提出的各种数据存取技术的演化结果，因为随着数据日益复杂，数据存取技术也必须不断地进步以适应应用系统的需求。
ADO主要是让应用程序或Web应用程序存取各种不同的数据源[4]。ADO封装了OLE-DB复杂的接口，以及为简单的COM接口存取数据。事实上ADO就是COM对象。
2.3.2 ADO的企业特性
ADO在其实际运行中得到了很高的评价，具有内存覆盖、线程安全、分布式事务支持、基于Web的远程数据访问等多种功能。作为Microsoft UDA 策略的一部分，ADO试图成为基于跨平台的、数据源异构的数据访问的标准模型。随着时间的流逝，它将取代其他模型。
2.4 COM+技术原理
2.4.1 什么是COM+
COM+并不是COM的新版本，可以把它理解为COM的新发展，或者为COM更高层次上的应用[3]。COM+的底层结构仍然以COM为基础，它几乎包容了COM的所有内容。有一种说法这样认为，COM+是COM、DCOM和MTS(Microsoft Transaction Server)的集成，这种说法有一定的道理，因为COM+确实综合了这些技术要素。但更重要的一点是，COM+倡导了一种新的概念，它把COM组件软件提升到应用层而不再是底层的软件结构，它通过操作系统的各种支持，使组件对象模型建立在应用层上，把所有组件的底层细节留给操作系统，因此，COM+与操作系统的结合更加紧密，这也是COM+非得等到Windows 2000发布才能面世的主要原因。
COM是个开放的组件标准，它有很强的扩充和扩展能力，从COM到DCOM，再到MTS的发展过程也充分说明了这一点。对COM有使用经验的读者一定可以感觉到，虽然COM已经改变了Windows程序员的应用开发模式，把组件的概念融入到Windows应用中，但是由于种种原因，DCOM和MTS的许多优越性还没有为广大的Windows程序员所认识。MTS针对企业应用和Web应用的特点，在COM/DCOM的基础上又添加了许多功能和特性，包括事务特性、安全模型、管理和配置等，MTS使COM成为一个完整的组件体系结构。由于历史的原因，COM、DCOM和MTS相互之间并不很融洽，难以形成统一的整体，不过，这种状况很快就要结束，因为COM+将把这三者有效地统一起来，形成一个全新的、功能强大的组件体系结构，并且把DCOM和MTS的各种优势以更为简捷的方式带给Windows 2000程序员和用户。
2.4.2 COM+基本体系结构
COM+的基本结构并不复杂，简单说起来，它把COM和MTS的编程模型结合起来，同时又增加了一些新的特性。从COM的发展角度来看，COM最初作为桌面操作系统平台上的组件技术，主要为OLE服务。但是随着Windows NT与DCOM的发布，COM通过底层的远程支持使组件技术延伸到了分布式应用领域，充分体现了COM的扩展能力以及组件结构模型的优势。MTS为COM增添了许多新的内容，弥补了COM和DCOM的一些不足，它注重于服务器一端的组件管理和配置环境。COM+进一步把COM、DCOM和MTS统一起来，形成真正适合于企业应用的组件技术。图1就能更好的说明COM、DCOM、MTS以及COM+之间的区别。

图1 COM+体系结构
COM+不仅继承了COM、DCOM和MTS的许多特性，同时也新增了一些服务，比如负载平衡、内存数据库、事件模型、队列服务等。COM+新增的服务为COM+应用提供了很强的功能，建立在COM+基础上的应用程序可以直接利用这些服务而获得良好的企业应用特性。以下是对COM+新增的一些服务进行分析[3]：
负载平衡：分布式COM+应用程序可能潜在地拥有成千上万的客户。在这种情况下，即时击活和对象缓冲技术都不适应提供应用程序所需要的扩展能力。因而，客户负载应当分布到网络上的多个服务器上。采用COM+就在组件级别实现了负载平衡。
内存数据库: 内存数据库也是一种服务，它为中间层机器上的后台数据提供了自动的内存缓存功能。它可以极大地加快对数据表访问速度，通常这些数据表以读访问为主，而不是以写为主，比如邮购目录。
事件模型: 采用COM+可以在分布式事务处理中创建自动参与事务处理的组件。通常的情况下，事务处理大多应用于数据库访问场合。在跨应用、跨企业的情况下，维护企业应用数据的完整性是非常重要的，同时也是非常困难的任务。为此，微软特意提出了分布式事务处理的概念，并且已经成为WINDOWS2000的集成服务。多数COM+对象声明为既需要事务处理也需要支持事务处理。
队列服务: 队列组件是COM+的一个关键特性，它是基于包含在WINDOWS 2000的Microsoft消息队列服务器的。队列组件是指一种通讯机制，它允许COM客户对COM对象的调用即使当对象所在的服务器并不能通过网络到达的时候也可以进行，例如在客户机与服务器断开连接操作的过程中。所有的调用被一个系统工具记录下来，然后通过异步协议传递到服务器，当服务器又回到正常运行状态时再通过另一个系统工具将其调用到服务器的COM对象。
2.5 多线程技术原理
进程是应用程序的执行实例，每个进程是由私有的虚拟地址空间、代码、数据和其他各种系统资源组成的。而线程是进程内部的一个执行单元（如可以是一个函数或一个活跃的类对象等）。系统创建好进程后，实际上就启动执行了该进程的主执行线程。主执行线程终止了，进程也就随之终止。
每一个进程至少有一个线程（即主执行线程，它无需由用户去主动创建，是由系统将应用程序启动后创建的），用户根据需要在应用程序中创建其他线程，多个线程并发地运行在同一个进程中。一个进程中的所有线程都在该进程的虚拟地址空间中，使用这些虚拟地址空间、全局变量和系统资源，所以线程之间的通讯要比进程之间的通讯容易得多。所谓的多线程技术就基于此。
3 系统设计分析
3.1 系统的可行性分析
随着中国进入WTO，政府机构体制改革的更加深入，提高政府办公的效率，提升政府的社会服务形象，建立一个安全、可靠、高效的政府办公信息化系统的要求已经正式成为全国政府政务信息化工作的中心任务。正是为此，公文流转系统在国内有着非常大的发展潜力。在未来几年内，将是发展公文流转系统的黄金时期。因此，设计一个好的公文流转系统将有一个非常好的市场。
3.2 系统的总体需求分析
《公文流转系统》共有七个子摸块，它们分别是收文管理、发文管理、公文审批、文挡管理、公文动态追踪、审批路径设定以及系统的设置。
(1) 收文管理：主要有对新收公文的管理和对历史公文的操作。
(2) 发文管理：新建一个公文并请求审批、把一个已经存在的公文请求审批以及编辑被弃审的公文并重新要求审批。
(3) 公文审批：审批公文并填写意见或者弃审公文并填写意见。
(4) 文档管理：按文件的类型分别显示出公文，并提供按公文的编号和公文的名称进行查询
(5) 公文动态追踪：主要提供查询某一个公文现在所在的地方。
(6) 审批路径设定：提供添加审批路径和公文类型的两个平台。
(7) 系统设置：对员工、部门进行添加、删除修改。
3.3 系统的功能分析
3.3.1 收文管理
(1) 新收公文：主要是对个人今天所收公文进行查看、删除、以及归档(如果他是系统管理员)
(2) 历史公文：主要是查看过去所收公文。
3.3.2 发文管理
(1) 新建一个公文：新建一个公文，选择公文的类型以及公文的正文是用word 还是excel。编辑完之后可以选择请求审批。
(2) 请求审批公文：查询数据库中存在的已经写好但没有审批的公文，并可以把这些公文请求审批。
(3) 编辑弃审公文：查询被弃审公文，进行编辑。编辑之后可以进行请求审批。
3.3.3 公文审批
(1) 确审公文：查看公文并填写审批意见，并传到下一个审批人的手中。
(2) 弃审公文：查看公文并填写弃审原因，并把公文传回到拟文人。
3.3.4 文档管理
(1) 分类显示文档：按文件的类型查询所有文档，并显示出来。
(2) 文档查询：按文件的编号或者文件的名称对某一个公文进行查询，并显示出来
3.3.5 公文追踪
输入一个公文编号，能够把该公文所对应的审批路径以图的形式显示出来。并且能够通过图我们知道该公文现在审批到何处。
3.4 系统所需环境的分析
3.4.1 硬件环境
数据库服务器，中间层服务器：因为服务器为数据库服务器，且要完成高密度的运算量，所以应采用较高档的服务器。考虑到与软件的兼容性，建议采用Intel Pentium Ⅲ 多处理器系统、256MB RAM、40GB以上硬盘。
客户机：采用Intel Pentium Ⅳ 多处理器系统、128MB RAM、20GB以上硬盘。
网络配置：100M 网络带宽 、100Mb/s网卡、16口交换机。
3.4.2 软件环境
(1) 操作系统的选择：数据库服务器，中间层服务器：采用Windows2000 Professional 或 Windows2000 Server。客户机：采用Windows2000 Professional。
(2) 数据库的选择：我们使用的是Oracle数据库。
(3) 开发工具的选择：我们选用的是Delphi7。
4 关键技术和算法
4.1 COM+应用系统架构的实现
4.1.1 服务器端实现
首先新建一个新的ActiveX Library项目，然后点选Multitier页次中的MTS Data Module 图像。在此ActiveX Library项目中建立一个新的MTS/COM+数据模块。在弹出的对话框中输入类名，并要求其支持事务处理。
设定之后，在这个数据模块中使用ADO组件来连接并且存取数据。并且我们可以根据客户端的需要添加方法对数据进行存取。这样我们就可以在所对应的Unit里面找出相应的代码。如下是相应的部分代码所示：
type Twf = class(TMtsDataModule, Iwf) //wf 是类名
adoQryLogin: TADOQuery;
ADOConnection1: TADOConnection;
dspLogin: TDataSetProvider;
private
{ Private declarations }
protected
class procedure UpdateRegistry(Register: Boolean; const ClassID, ProgID: string); override;
function login(const susername, spassword: WideString): Shortint; safecall; //用于登录系统的方法
设定完MTS/COM+数据模块中组件的特性值之后，这个MTS/COM+数据模块对象已经完成。接着我们就可以在组件服务中注册。这样一个最简单的服务端已经建好。
4.1.2 客户端实现
要使用刚才开发的MTS/COM+数据模块对象并取得数据是非常容易的事情，因Delphi提供了MIDAS组件可以直接封装远程数据。但是要调用远程服务器端的方法就不那么容易，就必须在客户端通过调用COM+体系结构中的一个方法，把远程的服务器的对象本地化。进而客户端就能自如的调用服务器端的方法。
首先把服务器端所产生的TLB文件加载到客户端的单元里，然后通过调用CreateRemote(MachineName) 创建一个远程对象。其部分代码如下：
//创建一个远程对象，其中wf为类名，Iwf为这个接口的名称
class function Cowf.CreateRemote(const MachineName: string): Iwf;
begin
Result := CreateRemoteComObject(MachineName, CLASS_wf) as Iwf;
end;
{调用CreateRemote(MachineName)方法创建对象，和调用远程对象的一个方法}
var RServer:OleVariant; //定义一个变量，用于接受远程对象
begin
Rserver:=Cowf.CreateRemote(computername);
result:=RServer.login(username,password);
//调用服务器的一个方法
end;
4.1.3 管理和分发COM+应用系统
当开发完成COM+应用系统之后，就必须分发应用系统，这样COM+应用系统才能够再用户的环境中正常工作。分发COM+应用系统包含了两个部分,第一个是分发包含COM+组件的套件组件，然后安装套件组件到用户服务器中。第二个部分是分发客户端的安装程序[5]。为了让基础客户端能够调用远程COM+ 组件，COM+会自动产生客户端的安装程序，必须在每一个要调用COM+组件的客户端机中执行由COM+产生的客户端的安装程序。这样基础客户端应用程序才能够顺利调用远程COM+组件。由COM+自动产生客户端的安装程序包含了在客户端机器中注册远程COM+组件的接口、Type Library以及一些DCOM的设定。
具体的实施方法：首先激活组件服务，找到相应的组件应用程序的名称。右击选择导出,紧接着Windows 2000会询问是要汇出服务器端的应用程序，还是汇出客户端安装程序。选择之后，就会产生两个文件分别是*.mis和*.cab。然后我们可以分别在服务器端安装服务器应用程序，和客户端应用程序。

图2 COM+组件的分发
4.2 公文动态追踪算法
4.2.1 算法设计
目的：该算法主要是为了更好的说明某个公文所对应的审批路径，以及该公文所处在审批路径的那一个路段上，从而知道现在该谁审批。这样用户就能更好的管理公文。并且通过图表示能给用户清晰感觉。
设计思想：首先在客户端输入公文编号，调用服务器端方法qryfileexist，查询该公文在数据库中是否存在。如不存在，则在客户端弹出一个消息框提示“该公文不存在”。如果存在，则通过调用方法qrystatenum查询该公文所对应的审批路径中路段的数目。然后把这个数目设置下面循环的数目。在循环中，首先通过方法qrysvoid查询公文审批路径的每个路段是否审批，如果审批完成则设置所对应的椭圆为红色，如果没审批则设置颜色为白色。同时通过调用方法qrystatename查询每个路段的名称，并控制每个椭圆的尺寸，以及位置。
4.2.2 算法实现
客户端部分实现代码：
fileNo:=edtFileNO.Text;
count:=RServer.qryfileexist(fileNo);//查询公文是否存在
if count>=1 then
begin
statenum:=RServer.qrystatenum(fileno);
//查询公文所对应路径的路段数目
for i:=1 to statenum do
begin
s:='00'+inttostr(i);
result:=RServer.qrystatename(fileno,s);
//查询公文所对应路径的每个路段名称
cdscommon.Data:=result;
cdscommon.Active:=true;
statename:=cdscommon.FieldValues['PathstateName'];
j:=Rserver.qsexist(fileno,s);
if j>=1 then
begin
result:=RServer.qrysvoid(fileno,s);
//查询公文所对应路径的某个路段是否审批
cdscommon.Data:=result;
cdscommon.Active:=true;
svoid:=cdscommon.FieldValues['Void'];
if svoid='T' then
Image5.Canvas.Brush.Color:=clRed //设置画刷的颜色
else
Image5.Canvas.Brush.Color:=clwhite;
end
else
Image5.Canvas.Brush.Color:=clwhite;
l:=30+(i-1)*150;
right:=130+(i-1)*150;
with Image5 do
begin
Canvas.Brush.Style := bsSolid;
Canvas.Ellipse(l, 167, right,217);//画一个椭圆
canvas.TextOut(l+25,187,statename);
if i<statenum then
begin
Canvas.MoveTo(right,192);
Canvas.LineTo(right+50,192);//画一条直线
end;
end;
end;
end
else application.MessageBox('该公文不存在或者已经审批完成','提示',MB_OK);
end;
服务器端部分实现代码：
//查询某个路段的名称
function Twf.qrystatename(const fileno, stateno: WideString): OleVariant;
begin
with adoQryLogin do
begin
close;
SQL.Clear;
SQL.Add('select PathstateName from WF.PAPath a,WF.PADetail b,WF.FSRoll c where c.FileNo='''+fileno+'''');
SQL.Add('and c.SendFileStyleNo=b.SendFileStyleNo and b.PathApproveNo=a.PathApproveNo');
SQL.Add('and a.PathstateNo='''+stateno+'''');
end;
try
adoQryLogin.Open;
result:=dspLogin.Data
except
exit;
end;
end;
4.2.3 运行的结果
输入某一个公文编号，所得结果如下图2所示：

图3 公文追踪运行结果
4.3 公文审批算法
4.3