工作流引擎

1 绪论 【社会上的需求.】

1.1 课题的研究背景

工作流的概念起源于生产组织和办公自动化领域。它是针对日常工作中具有固定程序的活动而提出得一个概念。它的主要特点是使处理过程自动化，通过将工作分解成定义良好的任务、角色，按照一定的规则和过程来执行这些任务并对他们进行监控，使人以及各种应用工具相互之间协调工作，以完成某项工作，达到提高办公效率、降低生产成本、提高企业生产经营管理水平和企业竞争力的目标。其目的是为了让合适的人或软件在恰当的时间执行正确的工作。在企业信息化的宏观背景下，工作流逐渐成为被业界广泛应用并迅速发展的技术。

自从进入工业化时代以来，研究人员一直致力于优化工作流和有关过程的组织管理，它是企业管理的主要研究内容之一。在全面进入个人PC时代之前，这些工作主要由人工完成。在计算机网络技术普及，分布式数据库与分布式通讯技术迅速发展、多机协同工作技术日趋完善的基础上，于20世纪80年代中期发展起来工作流技术为企业更好地实现这些经营目标提供了先进的手段。

目前，在全球范围内，对工作流的技术研究以及相关产品的开发已经进入了更为繁荣的阶段，如我们熟知的金蝶、用友等注明软件商都推出了相关产品。更多更新的技术被集成进来了，文件管理系统、数据库、电子邮件、移动计算、Internet服务等都已经被容纳到工作流管理系统之中。

工作流产品的市场也以每年两位数字的速度迅猛增长时至今日，工作流管理技术己经成功地运用到图书馆、医院、保险公司、银行等行业，工作流技术的研究应用日益受到学术界和企业界的重视。许多大学和研究机构也致力于工作流技术的进一步发展，开展了一系列的研究项目，取得显著的成果。

为此，本课题试图设计一个能够自定义的，适应性强的工作流。一方面能够与ERP集成，提高业务处理效率，另一方面，作为单独的工作流产品能够满足用户的个性化需求。

1.2 国内外研究概况

自定义工作流管理系统的研究通常集中在两个方面：一个是工作流建模理论的研究，讨论工作流建模方法及相关模型；另一个方面是从实现技术的角度出发，探讨关于如何将新技术使用到工作流上，以提高工作流的执行效率及安全可靠等性能。

工作流模型的主要内容就是提供一套有效的描述业务过程的建模语言，定义出正确的过程模型，完成实际的业务过程到计算机可处理的形式化定义的转化。

自20世纪60年以来，已经开发了许多工作流系统的建模方法。具有代表性的建模方法有：活动网络、状态图、事件驱动的过程链(event-driven process chain，EPC)、语言行为理论、Petri网和统一建模语言(UML)等。从对过程认识论角度可以将建模的方法分为两类：一类是基于通讯的建模方法，另一类是基于活动的建模方法。

由于不同的建模方法各有优缺点，所以越来越多的研究人员在研究和开发新的工作流建模方法时，把充分利用已有的研究成果、综合不同的建模方法作为快速、高效构建工作流模型的一种有效手段。

工作流技术将成为支撑BPM系统的关键核心技术，并正在向应用框架和商用套件等领域扩展，工作流技术在未来将不再是单一技术问题，工作流技术将肩负起解决实际领域、行业业务流程管理的重担。

1.3 主要研究工作

本研究的主要目的就是实现一个高效灵活、面向文档处理的自定义工作流原型，以能够提高业务处理的灵活性和效率。

本文是基于活动的建模，过分为四部分：

第一章介绍了本课题的研究背景，国内外的研究现状，研究的目的、内容和意义。

第二章阐述了工作流的主要理论基础：工作流的基本概念、基本原理，工作流的参考模型和功能结构，以及工作流的形成、发展及应用，试图给出工作流的概貌。

第三章设计了一个各模块联系紧密、高效、智能的工作流框架，框架设计方面突出显示了自定义的特性，实现了自定义工作流框架中各模块。

第四章给出了基于自定义工作流框架，本人实现了文档流转系统，列举了本文创新点和不足，并对以后的进一步研究提出了展望。

2 工作流理论基础概述【目前的主流,框架,功能,自己能完成的某种需求,意义在哪里.通用和特殊 】

2.1 工作流的相关概念

不同的研究者和产品提供商从不同的角度给出了工作流的定义。

(1)世界领先的实时企业应用软件提供商PeopleSoft公司定义工作流为：工作流是一个用来实施经营过程实践的机制。

(2)IBM的Almaden研究中心定义为：工作流是经营过程的一种计算机化的表示模型，它定义了整个过程所需的各种参数。这些参数包括对过程中的每一步骤的定义、步骤的执行顺序、条件以及数据流的建立、每一步骤由谁负责以及每个活动所需要的应用程序。

(3)工作流管理联盟(Workflow Management Coalition，wFMC)定义的工作流为：工作流是一类能够完全或者部分自动执行的经营过程，它根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行。以上概念都传递了一个共同信息即：工作流是经营过程的计算机实现。我们从做什么，怎么做，有谁来做，做的效果这一角度来定义工作流为：工作流就是业务过程的部分或整体在计算机应用环境下的自动化，它主要解决的是使在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行，从而实现某个预期的业务目标或者促使此目标的实现。

2.2 工作流技术的形成与发展

(1)工作流的形成

泰勒首次(一百多年前)提出业务流程的重要性后，西方管理学者和IT专家就再也没有停止过对工作流的思索与实践的步伐。工作流技术起源于二十世纪七十年代中期办公自动化领域的研究，由于当时计算机尚未普及，网络技术水平还很低以及理论基础匾乏，这项新技术并未取得成功。1983年至1985年间，在图像处理领域和电子邮件领域出现了早期的含有工作流特征的商用系统。

1993年8月，第一个工作流技术标准化的工业组织—工作流管理联盟成立。1994年，工作流管理联盟发布了用于工作流管理系统之间互操作的工作流参考模型，并相继制定了一系列工业标准。与此同时，关于工作流技术的学术研究也十分活跃，许多原型系统在实验室里开发出来。

进入二十一世纪以来，工作流技术已被越来越多的人认可，与之相关的标准规范、工作流引擎及商业产品不胜枚举。人们在开发推广工作流产品的同时，更加注重工作流的理论研究，以推动该项技术走向成熟。

(2)工作流的发展

在工作流技术应用日益得到重视的今天，对工作流技术的研究也正在向更深层次进行。工作流技术研究主要分为两方面内容:一是为工作流技术的发展解决理论上存在的问题，探讨工作流模型和语义的形式化表示方法等；二是从工作流实现技术的角度探讨利用先进的技术提高工作流管理系统的性能和可靠性。以下主要讨论工作流实现技术的发展趋势。

1.分布式的系统：分布式的系统可以使分布的计算资源得到有效的利用，平衡系统负荷，减小系统故障带来的损失。分布的子过程或活动可以在分布的系统组件上独立的运行，并在组件之间传递数据和过程的状态。分布式设计不仅要考虑系统分布组件之间的通讯问题，更重要的是给出过程分布的规则，使整个系统的资源利用达到最优。

2.组件化设计，增强系统可伸缩性：先进的工作流管理系统的一项重要特征是在设计和实现阶段始终以允许系统进化的思想为基本理念。要实现企业经营过程的快速重组，企业的应用系统需要按照组件的方式构建或改造。采用组件化的系统设计和面向对象的工作流模型后，用户界面组件、工作流管理组件、工作流过程都可以定制和重用，使它们能快速适应在不同领域中的应用。

3.基于事件：事件为工作流管理系统中（分布）组件之间的异步通讯和互操作提供了一种高效的机制。采用这种机制，组件之间可以松散的组合。对基于事件的设计的更高要求是，组件或用户能够定制自己希望接收的时间消息类型，而不总被无关的事件所打扰。

4.基于Web：未来企业工作流的参与者不仅包括企业的决策者和员工，还将包括企业的供应商、客户、以及供应链上的其他合作伙伴，他们不仅在地理上是分布的，使用着不同的平台，并且各自有着自己的工作方式和时间安排。这些参与者将通过访问共同的工作流组成虚拟工作组，由工作流管理系统相连。www利用Intranet和hitemet提供了一种跨平台的、一致的、简单的数据访问方式。

5.支持动态建模：工作流管理系统需要适应变化的环境，变化的环境经常会引起异常的发生。在长过程的执行过程中，对工作流过程模型的优化将造成对过程模型的修改，在过程的执行中重新分配任务，或为活动的执行者在工作方式上提供更多的选择，以便及时采用最有效的资源和人员部署方案。新的工作流系统需要适应过程执行中的动态修改，并维护过程模型的一致性。

6.异常处理和错误恢复问题：对于制造企业这样的一个复杂的应用系统，出现异常和错误是非常正常的情况，对于工作流管理篆统不仅要求它在正常情况能够发挥作用，更重要的是要求它能够灵活的处理各种异常情况，并且在某个节点发生错误时能够保证整个系统不会发生崩溃。

7.融入事务管理概念：在工作流管理中融入事务管理的概念和模型方法可以显著的提高工作流管理系统处理大规模业务应用的能力，目前这个工作已经得到许多研究人员的重视。

8.应用集成与开放性：工作流管理系统本身是一个完成过程建模和过程管理的软件系统，但是为了在企业的实际业务中得到有效的应用，它必须和企业己有的或购买的其它实现业务应用的软件实现集成，通过集成来提高整个企业的应用水平和应用效率。工作流管理系统是开放的系统，它提供访问其内部各个层次的组件的一致的接口，通过这种方式可以保证系统在未来能与其它工具以系统开发时不能预见的方式集成。

9.支持离线操作：实际企业业务中有很多工作是离线进行的，支持离线操作的工作流管理系统可以有效的降低企业数据一致性的维护成本，并且真正贴近企业应用的实际情况。

10.定制界面:：面向任务的界面和面向最终用户的表示方法对支持跨组织的具有不同能力和经验的参与者具有重要的意义。工作流管理系统把复杂的表示方法隐藏在用户熟悉的图表和抽象之后，不需要用户学习新的使用方法。

2.3 工作流的应用

工作流可以应用到以下行业：消费品行业，制造业，电信服务业，银行证券等金融服务业，物流服务业，物业服务业，物业管理，大中型进出口贸易公司，政府事业机构，研究院所及教育服务业等特别是大的跨国企业和集团公司。

具体应用如下：

(1)关键业务流程：订单、报价处理、采购处理、合同审核、客户电话处理、供应链管理等；

(2)行政管理类：出差申请、加班申请、请假申请、用车申请、各种办公用品申请、购买申请、日报周报等凡是原来手工流转处理的行政表单。

(3)人事管理类：员工培训安排、绩效考评、职位变动处理、员工档案信息管理等

(4)财务相关类：付款请求、应收款处理、日常报销处理、出差报销、预算和计划申请等。

(5)客户服务类：客户信息管理、客户投诉、请求处理、售后服务管理等管理。

(6)特殊服务类：ISO系列对应流程、质量管理对应流程、产品数据信息管理、贸易公司报关处理、物流公司货物跟踪处理等各种通过表单逐步手工流转完成的任务均可应用工作流软件自动规范的实现。

2.4 工作流的审批模式

审批流程设置分为两种模式：传统模式和比例计算模式。

传统模式是指对审批流程的每个节点设定相应审批人，只有当该节点上的所有人员都通过审批请求后，才可以进入下一个节。

比例计算模式：对于每个审批流程，在建立时先要为其设定一个介于0-100%之间的通过比例，惟有最终的审批结果等于或大于该比例，该审批才可被认为通过。

 

3 自定义工作流与相关技术  【核心技术(3个  允许部分抄袭): wf, .net技术】

3.1工作流的原理

简单地说，工作流是一系列相互衔接、自动进行的业务活动或任务。我们可以将整个业务过程看作是一条河，其中流过的河水就是待审核的表单。一个工作流包括一组任务（或活动）及它们的相互顺序关系，还包括流程及任务（或活动）的启动和终止条件，以及对每个任务（或活动）的描述。

WF工作流包含两种类型的工作流：顺序工作流和状态机工作流。 顺序工作流提供了一系列有组织的步骤，一般情况下，步骤是逐一执行的。可能有的步骤需要等待某些事件的发生才可以继续执行，但通常情况下顺序工作流一般用于无需人工干预的操作。 状态机工作流提供了一系列的状态。工作流从初始状态开始，到终止状态结束。两个状态之间定义行为进行过渡。通常情况下，状态机工作流对事件作出反应，事件的发生将会使状态发生改变。

与工作流相关的概念及其关系，如图3-1所示

图3-1 工作流相关的概念图

(1)业务流程(Business Process)：是在功能确定的组织结构中，能够实现业务目标和策略的相互连接的过程和活动集。例如：投保过程、项目开发过程等。

(2)过程定义(Process Definition)：是业务流程可被计算机理解的形式化描述，用来支持系统建模和运行过程起始、终止的活动关系网络以及一些关于个体行为的信息，如组织成员与IT相关的应用和数据等。

(3)过程(Process)：是业务流程的规范视图，由一系列为共同目标连接在一起的协同的过程活动组成。

(4)活动(Activity)：指的是工作流中的一个逻辑步骤或环节，是过程执行中可被工作机调度的最小工作单元。它既可以是计算机自动执行，也可以是人来完成。

(5)工作流管理系统(Workflow Management System)：是一种能定义、创建和管理工作流执行的系统。它可通过单个或多个工作机运行，并能存储和解释过程定义。它包含的信息有：开始和结束条件，可参与到此环节中的拥护，完成此活动所需的应用程序或数据，以及关于此活动应如何完成的一些限制条件。

(6)过程活动实例(Process Activity Instances)：指的是实际运行中的一个过程活动。每个实例代表一个能独立控制执行、具有内部状态的线程，可被外界通过标识进行存取。过程实例有工作流管理系统创建、管理、终止、它与过程定义相对应。每个活动实例代表一个活动的一次调用，只和一个过程实例相关，并使用过程实例的数据。一个过程实例可能有若干个活动实例组成，但一个活动实例不能同时属于几个过程实例。

工作流在大多数的实际应用中的情况可以这样来简单地描述：在网络、服务器和多台计算机客户端的硬件平台上，业务过程按照预先设定的规则并借助应用程序和人对相关数据的处理而完成。例如，在日常办公中，当撰写好某份报告之后，可能需要将其提交给领导进行审阅或批示；审批意见可能需要汇集并提交给另外一个人，以便对报告进行进一步的修改。这样，可能会形成同一篇文档在多个人之间的顺序或同时传递。对于这样的情况，我们可以使用工作流技术来控制和管理文档在各个计算机之间自动传递，
而非手工传递。

类似的关于文档的自动化处理只是工作流技术的一种简单应用。事实上，工作流技术在现实生活中能够完成更多更复杂的任务。如企业(或机构)内部的各种数据或信息的自动处理，多种业务流程的整合，企业(或机构)之间的数据交换，借助Internet技术实现跨地域的数据传输和处理等等。

3.2 工作流的功能结构

图3-2 工作流参考模型

（1）工作流服务与工作流建模工具之间的接口—接口一
工作流服务与工作流建模工具之间的接口，包括工作流模型的解释和读写操作。此接口实现了建模环境和运行环境的分离，使用某种建模工具创建的模型可以运行在不同的工作流产品上。此外，它还是得多种工作流产品可以协同工作，构成一个统一的工作流执行服务。

（2）工作流执行服务与客户应用之间的接口—接口二
工作流执行服务与客户应用之间的接口，用来约定所有工作流客户端应用与工作流执行服务之间的操作方式。这些操作包括参与运行的各系统间的通信管理、工作流实例的创建与激起或挂起、过程状态的管理、用户任务列表项的处理、工作流实例的状态监控与信息查询等等。为了完成以上诸操作，WFMC提供一套标准的API集合(及场叭Pl)用来使用户在不考虑实际工作流产品实现平台的情况下以一种一致的方式通过工作流应用客户端访问工作流引擎和任务列表。任务列表时工作流执行期间必须与用户交互的地方，工作流引擎在其
中放置项目以使工作流参与者与工作流实现交互。‘

（3）工作流相关数据设计接口—接口三
工作流引擎直接调用的应用程序接口。在异构产品环境中，为了实现不同的工作流产品间相互调用，WFMC定义了工作流引擎直接调用的应用程序接口。此类接口主要包括以下几个方面的功能:
1.通信建立，建立和断开与应用程序的通信;
2.活动管理，启动、挂起、重新激活、结束活动，查询活动状态以及产生及响应各种事件;
3.数据处理，提供工作流相关数据或数据访问地址。在较复杂的情况(如异构环境下的工作流机间的协作)下，该接口可能还需要完成在不同工作楼引擎之间传递激活应用程序所需的数据、传递运行或过程建模完成时的工作流模型数据等其他功能。

（4）工作流执行服务间的互操作接口—接口四
接口四是不同的工作流引擎之间进行协作的接口规范，此接口WFMC定义的不是很详细，不同厂商的工作流引擎直接进行协作也存在大量的困难，因此实现此接口规范的工作流引擎产品也极少(前文提到的XPDL是其中一个)。

（5）工作流管理与监控设计—接口五
为了多种不同的管理应用于工作流引擎相互交互，需要在工作流引擎中设定一个公共的接口完成其与不同应用间的逻辑转换。这种逻辑转换最终也将通过一系列的认叭Pl来实现。接口五的WAPl包括以下几个方面的内容：

1.用户管理操作:创建、删除、暂停、修改用户或用户组的权限;
2.角色管理操作:定义、删除、修改角色以及设计定角色属性;
3.审核管理操作:查询、打印、删除、开始新的审核跟踪日志;
4.资源控制操作:设置、取消、修改过程或活动实例的并发层次;
5.过程监控管理:初始化过程实例、改变过程实例或活动状态、终止过程实例;
6.过程状态管理:查询过程或活动实例的运行状态。

4 自定义工作流与其相关技术

4.1 自定义工作流的含义与应用

工作流可以分为两类：一类是固定工作流，流程的基本设定和用途己经确定，用户可自定义的内容很少，基本上是直接应用。各种企业信息系统内集成的处理常见工作事务的模块都可以算做固定工作流。另一类是自定义工作流，系统只提供工作流设计和运行的环境以及基本元素，将流程定义独立出来，不和具体业务绑定，由企业内的系统管理员根据企业自身需求，用这些元素组合出各种各样的流程。

表4-1 纸面流程、固定工作流与自定义工作流的比较

	纸面流程	固定工作流	自定义工作流
表单设计可变性	好	差	好
流程步骤可变性	好	差	好
办理人身份识别	纸面签名	用户名/密码或更高级	用户名/密码或更高级
异地/移动办公	不支持	支持	支持
海量数据检索效率	很低	很高	较高
数据统计	不方便	方便	方便
流程制作维护人员	不需要	开发方（软件公司）	系统管理员（企业内部）

表4一1列出了纸面流程、固定工作流和自定义工作流的对比，自定义工作流在很多地方都具有明显优势。由于固定工作流的数据库为某流程专用，而自定义工作流的数据库往往需要同时被多个工作流共享，其结构也须能通用，因而自定义工作流在海量数据检索方面效率略低于固定工作流。正因此差别，固定工作流主要应用于大型企事业单位或特定行业中，流程固化且数据量集中的场合；而自定义工作流的完全可自主设计性使其能够适应多变的需求，也便于实现流程的个性化，尤其被要求灵活的中小型企业所青睐。

4.2 自定义工作流的特点

自定义工作流基本符合WFMC提出的标准结构，用户定义与任务执行完全分离。整个工作流的表单和流程步骤都是由系统管理员预先设计好的，办理时每个步骤的操作人员在限定的区域操作，完毕后选择下一分支与经办人进行转交，如此一步步流转直至结束流程。用户可定义部分包括如下部分：

1.表单设计
作为工作流数据的载体，表单力求易编辑、易操作和美观。管理者可以根据需要来设计满足需要的表单。

2.控件使用
用户可操作的就是表单上的控件，因此表单上可以使用的控件类型直接决定了工作流中可以存放哪些形式的数据，基本空间类型包括标签、文本输入、下拉菜单、单选列表，复选列表，日期等。优秀的工作流还提供诸如公式计算，SQL查询语句之类的高级控件，能够设计出功能更强大的表单。随着工作流技术的进步，控件的类型势必越来越丰富，在不久的将来，我们可能看到新的控件，如自动统计，手写审批等。

3.图形化流程设计
图形化的流程表述已经取代了传统的列表方式，这给设计者和使用者提供
了很大方便。并能提供更多直接显示的内容，如转向条件等。

4.流程转向控制
工作流转交时，往往同时有多个方向可以选择，流程转向控制即是根据已有条件自动判断出该往那个方向进行，或者允许往哪个方向进行。这一控制减少了使用者误操作的概率，提高了工作流的自动化程度。使用者可以直接设定转向条件，根据条件，流程会实现自动的转向。

5.统一步骤多人办理
转交时设定一个主办人，其他人只能在限定的区域书写自己的看法。这就是确定主办权的模式。同时交多人，谁先接谁办理(或谁先借谁主办)。用于有多人处理相同的事物，不必指定由谁办理的场合。这其实是自动分配主权的模式。多人会签，所有人都办理完(或已开始办理)才能结束本步。此功能用于一件事物需要多人审批的场合，避免了逐一传递工作的繁琐步骤。这可以算是没有主办权的模式。理想的工作流应该同时支持上面三种模式，以适应现实工作中的不同需

4.3 .NET平台

.NET就是微软的用来实现XML，Web Services，SOA（面向服务的体系结构service-oriented architecture）和敏捷性的技术。对技术人员，想真正了解什么是.NET，必须先了解.NET技术出现的原因和它想解决的问题，必须先了解为什么他们需要XML, Web Services 和 SOA。技术人员一般将微软看成一个平台厂商。微软通过技术平台，而技术人员在这个技术平台之上创建应用系统。从这个角度，.NET也可以如下来定义：.NET是微软的新一代技术平台，为敏捷商务构建互联互通的应用系统，这些系统是基于标准的，联通的，适应变化的，稳定的和高性能的。 从技术的角度，一个.NET应用是一个运行于.NET Framework之上的应用程序。（更精确的说，一个.NET应用是一个使用.NET Framework类库来编写，并运行于公共语言运行时 Common Language Runtime之上的应用程序。）如果一个应用程序跟.NET Framework无关，它就不能叫做.NET程序。比如，仅仅使用了XML并不就是.NET应用，仅仅使用SOAP SDK调用一个Web Service也不是.NET应用。

．NET平台的优势：

1．标准集成：XML、SOAP及其它
过去，微软的体系结构建立在COM/DCOM基础上，COM/DCOM是进程间通信的二进制标准。虽然这个标准本身没有什么失误，但是它与微软以外的领域格格不入。也就是说，这个标准成了实现与其它软件平台互操作的瓶颈。
除此之外，数据也是一个问题。虽然ADO简化了数据访问，但是把数据从一个地方传送到另外一个地方就成了问题。ADO Recordset（记录集）对象是一个存储了数据的二进制结构，而这种二进制格式对于非微软的平台没有任何意义。
.Net弥补了这些缺陷，因为它完全基于标准。比如，数据用XML的格式通过进程边界，而这个数据有一个到XSD的连接，所以任何客户端都可以正确地转化数据。
SOAP基于XML，用于与Web服务的通信。集成SOAP以后，不管客户端运行的是不是微软的操作系统，都可以实现简单的可编程访问。
2．简化应用
COM所面临的一个头痛的问题就是应用。COM利用Windows注册表来定位机器上的组件。这个想法是不错的：每个注册的组件只有一个实例，所有的应用程序都使用相同的版本。COM具有向后兼容性，也就是说新版本兼容老版本，但是开发人员可能会破坏这种兼容性。
.Net则采用了不同的方法：它根本就没有使用注册表。相反，微软的建议是每个应用程序使用自己局部的组件（在.Net称为“assembly”）。利用这种方法，用于应用程序Foo的Assembly X如果发生变化，Assembly X的Application Bar不会受到任何影响。这种方法听起来好象以前一台机器上同一个DLL的多个拷贝，的确是这样。不过你不会遇到应用程序查找Windows\System32目录的问题。
由于.Net不使用注册表，很多应用都可以用简单的拷贝命令来完成，通常没有必要开发安装程序。此外，应用程序不会琐定assembly，所以升级DLL的时候不必关闭应用程序。
3．Web服务支持
在流行的Web服务方面，微软发挥着重要的作用，而.Net为开发Web服务带来了前所未有的便利。用Notepad就可以建立简单的Web服务，甚至不必利用编译器，只要对它们进行简单的调用即可，因为.Net会对它们进行编译，甚至提供一个测试页供用户检验其功能。.Net 拥有所有必需的渠道，可以生成用户所需的所有文件，比如WSDL文件。
.Net也是一个聪明的Web服务使用者：只要设置了指向某个Web服务的索引，你就可以把它当作本地的assembly。你可以获得完整的Intel许可和功能实现帮助。
Web服务对于发送数据是非常重要的，感谢ADO.Net，Web服务可以利用简单或者复杂的数据，并以XML格式把它们发送到任何客户端，最后设置一个链接，指回到一个描述数据模式的XSD。
4．用于所有.Net语言的标准工具集
最终，你会拥有一个适用于所有语言的集成工具集。你会拥有一个统一的IDE、调试工具以及其它类似的工具。因此，其它公司可以把他们的语言嵌入IDE环境，并获得.Net工具所有的支持。比如富士通开发了netCOBOL .Net，它已经直接集成到IDE中，因此可以用 COBOL编写Web服务和Windows应用并获得微软提供的调试和profiling（监管）工具。
.Net是个开放的架构，所以其它厂商也可以提供自己的工具。比如Borland，该公司已经宣布其下一版Delphi将具有建立.Net应用的功能，同时它也保证，Delphi会拥有自己的IDE，不会嵌入Visual Studio .Net。
5．对移动设备的支持
Visual Studio .Net发布不久，微软就推出了移动Internet工具包（Microsoft Mobile Internet Toolkit ，MMIT），以便用.Net构建移动应用。该工具包提供了可视化功能，你可以直观地拖动和下拉面向移动设备的窗体和控件。该工具包有利于正确书写标记语言（比如WML、WAP等等）。
.Net简化架构（.Net Compact Framework）不久就会面市，它是.Net架构的缩略版，设计用于Pocket PC设备。有了这个架构，开发人员就可以开发出丰富的Pocket PC计算机应用。你可以编写一个运行于小型设备上的应用，比如用于Pocket PC设备或者具有Web功能的手机。事实上，MMIT包含了很多仿真程序，它们使用了真正为这类设备编写的ROM代码，所以在你的应用程序投入使用之前，可以首先测试其用于此类设备时的性能。
6．代码管理
.Net管理用户的代码，从很多方面看，这一点都是很重要的，比如减少bug以及构建更多可扩展的应用。.Net可以处理以下操作：内存分配和回收，进程及线程的创建和终止，以及运行代码的访问许可。
VB开发人员先前面临的问题——比如内存管理、线程和进程创建——现在都可以由.Net来处理。而C++程序员可以转向C#，.Net代替他们处理这些操作后，内存泄露和其它bug出现的可能性将大大减少。拥有了被管理的代码，你可以访问.Net所有跨语言的能力。
7．平台独立
虽然.Net是为微软的操作系统创建的，但是微软的确为ECMA标准委员会发布了一部分框架和C#。比如，Mono project实现了Linux的.Net，包括架构和C#编译器。这意味着很多应用（特别是基于Web的应用）一次编写完成后就可以运行于多种平台上。
8．充足的学习资源
.Net的学习曲线非常重要，可能.Net的方面的书要比其它所有编程技术的书都多。此外，微软和第三方团体开设了很多课程，可以让开发人员很快就上手。最后，很多网站为开发人员员学习.Net提供了技术和指导。
9．现代化语言
VB.Net和C#都是现代化的语言。它们完全是面向对象的，设计的时候消除了很多VB 和C++的矛盾。这两种语言使用了多层式架构 （n-tier），这是一种基于组件的方法。
比如，C#取消了指针和其它一些结构，它们曾经给C++程序员（特别是新手）带来很多严重的问题。代码由.Net架构管理后，VB.Net 和C#都从中受益。这个架构还包括一些基础的对象，它们是开发多线程、支持XML等应用所必须的。
10．跨语言标准基本类型
VB开发人员曾经面临一个致命的问题：VB中的字符串与C++中的字符串不同，所以调用Windows API函数的时候会出现一些问题。.Net确定了所有类型的标准定义，所以VB中的字符串和C#中的字符串相同，也和netCOBOL .Net中的字符串相同。这意味着你再也不必担心语言A中的整型数据是32位而语言B中只有16位。你可以确信不同语言的数据类型都相同，可以更好地进行跨语言集成。

4.4WWF框架

WF是四项技术之一，其它三项技术为WPF、WCF和Windows CardSpace。这些技术同.NET 3.0框架一起发布。

1. WF提供了一套高度抽象和可视化的商业处理模型。这套模型可以非常容易地使用和被理解。无论使用它的是开发人员或是商业领域专家。

2. WF可以非常容易地改变与之相关的商业处理规则，并且不必重新编译。

3. WF编程模型可以使开发人员建立一套可测试的内核集合，并且可以在多个程序中使用它们。

如果和UML的活动图进行比较的话，WF图表拥有最好的软件构架，我们并不用担心这套构架过时，或是和商业处理逻辑有分歧，因为WF就是商业处理逻辑。WF运行时为我们提供了一个强大的，可扩展的开发执行环境。为了可以长时间处理，当工作流处理空闲状态时，可以被保存在一个数据库中。当一个动作发生时，工作流被激活。

4.5 WCF技术

【若不够，网上的找点资料，炒上去】

4.6AJAX技术

（1）AJAX的定义【若不够，网上的找点资料，炒上去】

（2）AJAX的工作原理【若不够，网上的找点资料，炒上去】

（3）JavaScript【若不够，网上的找点资料，炒上去】

（4）DOM【若不够，网上的找点资料，炒上去】

（5）XML【若不够，网上的找点资料，炒上去】

5 自定义工作流的设计与实现【系统架构,流程图,库表结构、ER图 物理图 . 系统三层图、主要模块设计】

5.1概述

在办公室自动化系统中，几乎所有的业务过程都是工作流，特别是以办公室自动化系统的核心作用——文档流转处理、各种申请处理等，每一项工作都以流程的形式，由发起者（如：文件拟稿人）发起流程，经过本部门以及其它部门的处理（如审批、会签），最终达到流程的终点（如归档入库、终止流程）。

本课题中设计的自定义工作流满足WFMC提出的工作流模型的要求，系统主要涉及的业务内容是资源对象（如：审批单、请假单等）的调度与审批。在本系统中，我们设计了企业办公文件流转系统作为自定义工作流实现的载体，主要实现行政管理类等以文件流转为核心的业务流程的自动化。

5.2系统开发运行环境

系统开发环境的选择对于系统的建立至关重要，恰当的开发环境有助于减轻系统开发的工作量、提高系统性能、降低系统维护工作的困难等。在选择开发环境时，主要考
虑以下因素：扩展性、总体成本、功能、是否容易开发和管理、使用开发技术的先进性。
本文中所开发的文档流转系统的运行环境如下：
服务器操作系统：Microsoft Windows xp；
开发平台：Microsoft Visual Studio．NET 2008；
开发语言：C#；
数据库服务器：Microsoft SQL Server 2005 Enterprise Edition；
Web服务器：Intemet Information Server 6．0。

5.2 系统框架设计

一个工作流管理系统一般结构

通用模型中包含的构件可以分为三类

（1）软件构件：为工作流系统的各种功能实现提供支持的各类软件。
（2）系统控制数据：工作流管理系统中的一个或多个软件构件使用的数据。
（3）外部应用程序与应用数据：他们本身不是工作流产品的直接组成部分，而是属于外部系统和数据，但它们被工作流系统调用完成整个工作流管理系统的功能。

现有的工作流平台提供的功能满足了工作流开发平台的基本需要的最小集，又呈离散状态，相互之间没有很好地联系，缺乏一个智能、高效和安全的核心。

图5一2工作流管理系统的特性

根据工作流管理系统的特性(图5一2)，本文提出的工作流开发平台的主要部件分为可视化建模工具、工作流引擎系统、客户端、监控与管理工具、资源管理系统(后台数据库服务器)。平台通过建模工具，依托工作流引擎、后台数据库服务器实现流程流转，采用基于Web的客户端和监控工具完成对流程的监控。

工作流系统总体框架如图5-3

5.3 流程图

系统的工作流程大致如下：设计者在了解业务流程要求后，使用本课题设计流程设计器把业务流程转换成一个有向流程图，这是自定义工作流设计器使用的重要一步。有向流程图各节点及其关系通过XML的方式存储于数据库中，由定义态引擎进行解析。用户填写相应的表单，然后申请，生成过程实例。过程实例由运行态引擎导航，逐步实现活动的实例化，其中的审批意见均在流程设计器中定义（比如：审批通过、不通过、返回上一步、返回发起人等）。管理者应用监控和管理工具可以实时的控制业务流程的进展，挂起，返回，终止等，除此之外还可以控制设计者定义的流程是否可用。

或者下面这个
管理员登陆-->表单模板定义-->设置相关信息

                   -->流程模板定义-->设置相关信息﹜-->工作流流程定义-->发起工作流-->工作流结束

5.4 库表结构

用户模块

表单定义、工作流模板定义、工作流定义模块

5.5 ER图

5.6 主要模块设计

5.6.1 过程设计和定义

如前所述本课题中的自定义工作流是将表单模板、流程模板定义独立出来，不和具体业务绑定。让电子流程能够灵活搭配各模板，适应实际业务流程，根据需要快速定制用户自己的应用。

参照第三章介绍的工作流原理，我们将业务流程划分为过程、主流程、子流程。过程对应于具体的某类审批流程，它由各个主流程组成，主流程对应审批涉及的部门，一个主流程由一个或多个子流程组成，子流程对应于各个部门的科室，活动则为具体人员所需完成的工作。本节就根据这个思想来设计可自定义的流程。

(1)Form表单的自定义
Form表单的设计器(FrmDesign.cs)如图5一4所示:

表单是进行业务处理的主要入口，是数据的直接载体与表现方式。能否设计出控件丰富，功能强大的表单，很大程度上决定了工作流的使用价值。

如上图所示，本课题设计的表单设计器是以winform的方式实现。表单设计主要有四个个部分:菜单栏、控件栏、设计器主窗体和控件属性设计器。
1.控件栏展示了表单设计可供使用的所有控件，从左至右依次为:Label、Button、TextBox、CheckBox、ComboBox、RadioButton、RichTextBox、PictureBox、DateTiePicker、DataGraidView。应用面向对象思想，每个控件对应一个类，其属性的设置将由属性设计器来完成。图中展示了应用Label、Text、ComboBox的情况。ComboBox在生成的XML文件中的代码如下:

< field >
    < text > text >
    < left >160 left >
    < top >155 top >
    < width >97 width >
    < height >20 height >
    < forecolor >Color [WindowText] forecolor >
    < backcolor >Color [Window] backcolor >
    < fontname >宋体 fontname >
    < fontbold >false fontbold >
    < fontsize >9 fontsize >
    < fontitalic >false fontitalic >
    < type >BD_ComboBox type >
    < items >:同意:不同意:退回 items >
    < name >combo_spyj name >
< strong >  strong > field >

2.设计器类似于一个窗体，用来设计控件原型的布局。在生成的XML中的代码如下:

< form >
  < field >
    < type >Form type >
    < name >frm1 name >
  field >
  < field >
    < text > text >
    < left >160 left >
    < top >155 top >
    < width >97 width >
    < height >20 height >
    < forecolor >Color [WindowText] forecolor >
    < backcolor >Color [Window] backcolor >
    < fontname >宋体 fontname >
    < fontbold >false fontbold >
    < fontsize >9 fontsize >
    < fontitalic >false fontitalic >
    < type >BD_ComboBox type >
    < items >:同意:不同意:退回 items >
    < name >combo_spyj name >
  field >
  < field >
    < text > text >
    < left >160 left >
    < top >125 top >
    < width >97 width >
    < height >21 height >
    < forecolor >Color [WindowText] forecolor >
    < backcolor >Color [Window] backcolor >
    < fontname >宋体 fontname >
    < fontbold >false fontbold >
    < fontsize >9 fontsize >
    < fontitalic >false fontitalic >
    < limit > limit >
    < limittype >格式验证 limittype >
    < type >BD_TextBox type >
    < argname >args1 argname >
    < name >txt_sqje name >
  field >
  < field >
    < text > text >
    < left >160 left >
    < top >95 top >
    < width >97 width >
    < height >21 height >
    < forecolor >Color [WindowText] forecolor >
    < backcolor >Color [Window] backcolor >
    < fontname >宋体 fontname >
    < fontbold >false fontbold >
    < fontsize >9 fontsize >
    < fontitalic >false fontitalic >
    < limit > limit >
    < limittype >长度限制 limittype >
    < type >BD_TextBox type >
    < argname >
    < name >txt_sqr name >
  argname > field >
  < field >
    < text >审批意见: text >
    < left >82 left >
    < top >158 top >
    < width >60 width >
    < height >21 height >
    < forecolor >Color [ControlText] forecolor >
    < backcolor >Color [Control] backcolor >
    < fontname >宋体 fontname >
    < fontbold >false fontbold >
    < fontsize >9 fontsize >
    < fontitalic >false fontitalic >
    < type >BD_Label type >
    < name >lb3 name >
  field >
  < field >
    < text >申请金额: text >
    < left >82 left >
    < top >128 top >
    < width >64 width >
    < height >21 height >
    < forecolor >Color [ControlText] forecolor >
    < backcolor >Color [Control] backcolor >
    < fontname >宋体 fontname >
    < fontbold >false fontbold >
    < fontsize >9 fontsize >
    < fontitalic >false fontitalic >
    < type >BD_Label type >
    < name >lb2 name >
  field >
  < field >
    < text >申请人: text >
    < left >83 left >
    < top >95 top >
    < width >63 width >
    < height >14 height >
    < forecolor >Color [ControlText] forecolor >
    < backcolor >Color [Control] backcolor >
    < fontname >宋体 fontname >
    < fontbold >false fontbold >
    < fontsize >9 fontsize >
    < fontitalic >false fontitalic >
    < type >BD_Label type >
    < name >lb1 name >
  field >
form >

控件栏中的各种控件都得到了重写以保证能够在界面正常的拖动，并能够正确的转换成相应的XML文件。以下是winform控件界面转换成xml的代码:

private  void  toolStripButton_Save_Click( object  sender, EventArgs e)
        {
            if  (!IsOkToSave(splitContainer1.Panel1)) return ;
            XElement destiFile = ( new  SerializeDesigner().SerializeControlToXml(splitContainer1.Panel1));
            SaveFileDialog saveFile = new  SaveFileDialog();
            saveFile.InitialDirectory = "D:\\" ;
            saveFile.Filter = "表单文件(*.xml)|*.xml|所有文件(*.*)|*.* " ;
            if  (saveFile.ShowDialog() == DialogResult.OK)
            {
                string  fileName = saveFile.FileName.EndsWith( "xml" ) ? saveFile.FileName : saveFile.FileName + ".xml" ;
                destiFile.Save(fileName);
            }
            //serializedItems = new XElement("Form");
        }

///
        /// 序列化控件,返回自定义格式的xml体
        ///
        ///
        ///
        public  XElement SerializeControlToXml(Control MdiContiner)
        {
            serializedItems = new  XElement( "Form" );
            Getcontrols(MdiContiner);
            return  serializedItems;
        }

        private  void  Getcontrols(Control control)
        {
            foreach  (Control item in  control.Controls)
            {
                GetControlType(item);
                if  (item.Controls.Count > 0)
                    Getcontrols(item);
            }
        }

4.属性设计器同样存在于生成的XML文件中，被封装在每个控件节点中。默认状态下是可用的，如果需要更改控件的相应属性，需要在表单设计界面对控件原型的属性进行设置。

(2)流程模板的自定义

流程模板一般是由一个主流程和一个或多个子流程组成，是工作流模板的自定义中最小的流程单位，一个工作流模板是由一个流程模板和一个表单模板组成。流程模板的设计器，即流程设计器采用类似表单设计器的界面，同样由菜单栏、工具栏、设计器主窗体以及属性栏组成。在这个界面上，可以设计、修改生成图形化的流程图。流程设计器如下图所示：

图中左侧为流程的工具栏，展示了哪些是可使用的流程工具；中间显示的是流程定义的图形化描述，可以看到流程的走向、节点等；右侧显示的是属性设计器，通过点击条件可以设定活动的执行者和通过某节点的条件等。

值得说明的是，在流程模板的设计过程中，可以根据条件产生分叉，这样使得整个业务更为灵活有弹性，适应性更强。

如上图所示，此处以报销流程模板为例，以报销金额为判断标志。发起人发起一条报销流程，当报销金额小于1000时，直接交给财务人员审批；当报销金额大于1000时，则交给老板。图中的判断条件写在ifelse活动组件中的条件属性中。

工作流流程图示

（3）工作流模板的自定义

如下图所示，定义一个工作流模板只需三个步骤：1、选择表单模板 2、选择流程模板 3、填写工作流模板相关信息

(4) 数据处理

数据处理包括数据的保存和读取两大部分。为了使以上三部分的设计能够实现，能否很好地对数据的处理是关键。
1.自定义部分数据的存储载体如图5一8、5一9、5一10所示。

表单模版数据的保存

流程模板数据的保存

工作流数据的保存

2.数据的处理过程

在自定义工作流的整个实现过程中，除了要存储数据，更重要的是能够再现可自定义的页面，即读取存储的页面数据，加载到自定义页面。为了总体的认识，上图展示了数据的整个处理过程。在前文中我们对相关的技术己有介绍，这里再对整个过程作以下简单说明。当保存页面时，在客户端将遍历页面中指定的控件属性和值，生成XML文件并把数据在不刷新页面的情况下存储控件值到数据库中。
5.6.2过程实例化与控制
用户进行业务申请时，用户可以从工作流模板列表中选择指定的模板。在选中的模板中，工作流定义引擎将对整个流程进行解析，使用户可以看到整个流程的走向及相关的判断条件；当用户填写好发起人信息并发起流程，表示工作流实例化成功，工作流引擎根据流程模板定义、发起人填写的参数条件及审批人的权限自动引导整个过程的流向。过程流向如图5一12所示。

5.3.3管理监控与工具

没做

6 展望未来

（1）总结
工作流管理系统的涉及面非常广，包括理论方面的体系、模型与建模语言研究；实现技术方面的事务特性、各种先进软件技术的应用、工作流仿真；应用方面的应用方法、应用软件集成等。本文主要从应用研究的角度出发在工作流管理体系联盟提出的模型基础上进行再设计，给出了自定义工作流系统总体框架模型。

设计一个面向现行政管理类和特殊服务类以文档流转为核心的业务流程的自动化的模型是本文的主要内容，充分运用了WF技术，开发了基于B/S结构的，具有富客户端的工作流原型。从整体看，图形化的流程设置是本系统的一大创新点，用户可以直接自定义所需的流程，可非常方便的添加参数进行流程判断，在实际使用中不断扩展系统的业务功能，而不需要修改任何代码。并且系统的各个构件的祸合度较低，大多数工作流系统共性的结构和构件都已经在设计之前分离出来，可以很方面的重用在其他工作流系统中。

(2)展望
本文设计的工作流模型以后可以在以下几个方面对工作流管理系统作进一步的研究:

1.完全非结构化柔性。
本文工作流模型中提出的建模方法，在建立流程之后，如果流程实例在运行中，将不能对建立的流程进行修改。因此本文实现的实际上是半结构化构建时柔性(build-time flexibility)，与完全非结构化的运行时柔性(run-time flexibility)还有所差距。

2.智能化和数据检索。
为了让系统能够主动地执行并处理执行过程中出现的问题，智能化有待进一步研究。在数据检索方面，自定义的工作流比固定工作流交差，希望能在此方面提高自定义工作流的整体性能。