轻量级工作流引擎的设计与实现

第一章引言1.1轻量级工作流引擎的概念轻量级的工作流引擎指的是从够用、灵活和低成本的设计原则出发，不追求工作 流引擎的功能的完备和复杂，只是实现其中必不可少的功能和特征。在设计工作 流引擎时主要考虑对其数据模型的定义和解释、活动之间的协调以及任务的分配 和控制等功能提供支持，而不支持诸如提供内建（built-in）的应用开发工具、 对应用资料的定义和完整性维护、完善的异常处理以及长事务控制等功能。轻量 级工作流引擎的概念的提出，给开发工作流管理系统的开发人员开辟了一条新的 道路。工作流管理技术本身就是一项抽象复杂的技术，它致力追求从企事业各种 各样的业务中抽取出一个通用的模型，由这个模型去描述所有业务的一致性，以 达到“放之四海皆可用”的程度。不过，要把众多的而又错综复杂的业务都集中 在这个模型中，这是一件非常困难的工作，要经过一段漫长的摸索历程。而轻量 级的概念让我们认识到可以从一般性的而又简单的业务入手，为企事业快速的开 发出一个适应他们本身业务需求的而又带有可扩展性可移植性的信息管理系统， 为他们提高工作效率，并保证在一段很长的时间内满足不断增加的业务需求。1.2工作流管理系统的分类及本文的侧重点根据工作流过程本身的特点、系统建模的方式、所使用的底层支撑技术、以 及工作流过程的执行方式等的不同而对工作流管理系统进行相应的分类。面向文档的与面向过程的前者的侧着点在于将电子形式的文件、图像等在有关的人员之间进行分发， 以便能够得到不同人的处理与审阅。现有的文件管理与映像管理系统均属此类。 在面向过程的WFMS中，工作流被描述成一序列执行环节。与各环节相应都有待 处理的资料对象。各环节的资料对象可以按不同的方式分发到其它环节中去，如 可以将资料对象的值作为控制条件、或者依此资料对象组装成其它的资料对象 等。高端的WFMS 一般都属此类系统。结构化的与即席的结构化工作流指的是在实际工作过程中会反复重复、严格按照某个固定的步 骤进行的业务过程。定义此种工作流所需要的各种类型的信息可以通过对业务过 程进行详细的分析而得到，从而得到完整的过程定义并在以后的应用过程中反复 使用。大量的办公程序，如公文处理、审批等都属此类。即席工作流则是针对那 些重复性不是很强或没有重复性的工作流程的，关于这类流程执行所需的有关参 数（如参加者等）事先无法确定，而必须推迟到过程实例运行时才能确定，同时在 执行过程中间还可能会发生一些意外的情况。这种动态多变的特点在提供更高灵 活性的同时，也为过程的建模与执行带来更多的复杂性。基于邮件和基于数据库前者使用电子邮件来完成过程实例执行过程中消息的传递、资料的分发与事 件的通知。低端的系统所使用的经常就是此种方法，它可以充分发挥电子邮件系 统在广域环境下的资料分发功能，但整个系统将运行于一种松散耦合的模式下。 在基于数据库的WFMS中，所有的资料都保存在某种类型的DBMS中，过程的执行 实际上就是对这些资料的查询与处理。高端的大规模系统所使用的一般都是此种 方法。任务推动的与目标拉动的前者指的是从过程的开始逐步地一个环节一个环节的执行，当某个活动实例 被处理完之后，后续的有关活动将被创建并被激活，由此直至整个工作流程的完 成。这是目前大多数面向过程的WFMS所使用的执行方式。而在目标拉动的WFMS 中，一个业务流程被看成是一个目标。过程实例执行时，该目标将被分解得到多 个相互之间按一定约束条件的关联起来的可执行的多个环节，其中各环节还可以 当成是子目标而进一步进行分解。在各环节均执行完毕之后，整个过程也就完成 了。目标拉动是一种全新的执行方式，下一代的WFMS将具有此种特征。应该说 明的是：上述分类只是从不同的角度入手的。一般来说，后面那些特点将给WFMS 带来更好的灵活性，同时也将成为那些能够支持跨机构的大规模复杂工作流管 理、面向关键任务的WFMS不可缺少的特征。本文的侧重点本文的侧重点不在于完全实现其中一种工作流管理系统的所有功能，更不在 于实现所有种类的工作流管理系统的全部功能，前文已经说过，这是一件非常困 难的事情。那么我们的侧重点在哪里呢？就在于综合以上四种工作流管理系统的 主要特点，是一个面向文件的，基于数据库的，由目标拉动的结构化的工作流管 理系统，并且由此去设计和实现工作流管理系统的核心一一工作流引擎。从一般 性来说，目前大多数的企事业的业务都是事务申请，公文流转，各项通知等等，这些业务或者需要查看，或者需要审批，而这些业务的资料基本上是以文件的形 式保存在计算机上，而其中一些格式化的资料是保存在数据库中，所以面向文件 和面向数据库是轻量级工作流引擎的一个重要特征。业务的发起和结束是一项过 程化的任务，任务又可以分解成一个一个环节任务，而任务是带有目的性的，由 这个目的去拉动这个过程中的一个一个的环节任务，促使环节任务的推进，最终 达到任务完成的目的。这些业务的过程化不是随机的，而是已经严格规定好的， 只有遵循这些过程化的规则和流程环节才能完成整个业务。轻量级的工作流引擎 就组合了以上这些，不追求工作流引擎的功能的完备和复杂，以满足一般性业务 为目的，为企事业快速开发出适合他们业务的工作流管理系统。第二章工作流管理系统参考模型简介的应用编程接口, 下图：过程定义工具接口 1在阐述工作流引擎之前，我们来了解一下工作流技术的基本知识。早在几年 前，为了建立工作流管理系统的相关标准，国际上成立了一个称为“工作流管理 联盟”（简称WFMC）的国际组织。她提出了有关工作流管理系统的一些规范， 定义了工作流管理系统的结构及其与应用、管理工具和其它工作流管理系统之间 也就是工作流系统参考模型。WFMC给出的工作流参考模型如工作流API与交换格式工作流 接口5 管理工具工作流执行服务接口 4其它工作流执行服务工作流机接口 2接口 3工作流客户应用工作流机直接调用 的应用图2.1工作流参考模型从图中可以看出，参考模型包含了五类接口，分别是： 接口 1:过程定义输入输出接口，这是工作流服务与工作流建模之间的接 口，该接口提供的功能包括通信建立，工作流模型操作和工作流模型对象操作。 接口 2：客户端函数接口，这是工作流服务与客户应用之间的接口，这是 最主要的接口规范，它约定所有客户方应用与工作流服务之间的功能操作方式。 包括通信建立，工作流定义操作（对过程模型定义操作），过程实例管理功能， 过程状态管理功能，任务项列表/任务项处理功能，数据处理过程，过程监控功 能，其它的管理功能，应用程序激活。 接口 3：激活应用程序接口，这是工作流引擎和直接调用的应用程序之间 的接口，包括通信建立，活动管理功能，数据处理功能。 接口 4：工作流执行服务之间的互操作接口，这是工作流管理系统之间的 互操作接口，包括连接的建立，对工作流模型和其中对象的操作，对过程实例的 控制和状态描述，对活动的管理，对资料进行处理。 接口 5：系统管理与监控接口，这是工作流服务和工作流管理工具之间的 接口，包括资源控制，角色管理，用户管理，过程实例的管理，状态管理，审核 管理。五个接口以及对应的API函数囊括了工作流管理系统的全部功能。一个完整 的工作流管理系统就是以工作流引擎为中心，向外部部件（应用程序或其它工作 流引擎）提供这五个接口，提供其实现的所有功能。第三章系统分析与设计在所有准备工作完成后，我们就开始进行系统设计和设计，构造一个轻量级 的工作流引擎。轻量级的工作流引擎并不完全实现WFMC所提出的工作流模型包 含的五个接口，特别是接口 4，在分布式工作流管理系统才具有该接口。既然我 们从轻量级的概念出发，我们就不再明显区分各个接口的界限以及其所具有的特 定的功能，以够用、灵活和低成本的设计原则去设计出我们所理解的工作流引擎。 我们运用了面向对象的方法，首先从众多的业务需求中抽取出工作流模型所包含 的对象，再分析各个对象之间的逻辑关系，然后提出一个系统结构，再进行模块 划分，数据库设计，最终完成类的设计。我们当中所用到的建模工具就是ROSE UML。3.1工作流模型的设计对工作流模型的设计是工作流引擎设计的重要组成部分。311工作流模型的对象企事业经营过程就是一项项业务的实现过程，我们从一般业务入手，并对这 些业务进行详细的分析，研究，其结果就是得到一般性的业务对象，从而抽象成 工作流模型对象。3.1.1.1从一个简单的业务实例看业务的需求目前企事业的一项基本事务就是出差管理。它主要是对企事业的人员因为某 种工作上的原因需要到别的地方出差进行的管理。我们可以列出出差的相关步 骤：申请人需要出差，并且他（她）具有出差的权利；申请人填写出差表格，说明因何事出差，出差何处，申请出差金额，何 时回来等等和出差相关的情况；申请人需要其它说明的话，可以将更具体的说明以文档的形式保存下来；申请人确认申请无误后提交申请，等待申请的结果；根据规定，该申请必须先让申请人的上一级审批，那么该申请就会以一 项工作项的形式交给该级领导处理； 处理该申请的领导对该申请进行处理，他（她）会先查看该申请所有的 资料，包括出差申请表和与之相关的其它文档，然后对其进行审批，审批的结果 是同意那么该次申请会交给再下一级领导处理；审批的结果不同意，该申请被打 回，通知申请人申请不通过的结果。等所有需要审批的领导都审批通过了，该申 请就成功完成，通知申请人申请通过的结果； 申请人得到申请的结果，如果审批通过则准备出差，如果审批不通过则 根据审批结果对该申请进行修改，重新提交申请；申请事务结束。这是一个简单的业务实例，对该实例进行分析我们可以得到该业务的一些对 象：申请人：他（她）属于该企事业的某个部门的成员，并且具有启动该业 务的权利； 审批领导：他（她）也属于该企事业的某个部门的成员，并且具有对该 业务进行处理的权利；出差表格：它是该业务规定的格式化资料，并且是必须的出差具体说明：它是该业务附加的资料，可以不要的申请人已经填写好的出差表格：它是出差表格的实例化，代表一个具体 的应用 审批同意和不同意：它们是对该业务的处理，遵循一定的业务规则申请：这是一个过程，不是一个动作，需要时间和人的活动才能完成 审批：这是一个活动，是过程的一部分，并且可以向另外一个活动转化其它应用程序：申请人要填写出差具体说明时要调用相应的外部应用程 序编辑该说明并以一定的格式保存下来，审批领导要查看出差具体说明时也要调 用相应的外部应用程序打开该说明并以一定的格式显示出来。从这些业务对象，再利用工作流技术，我们可以得到工作流模型的一些基本 对象：用户：正如申请人，审批领导，他们就是工作流管理系统的用户，由他 们去使用该系统的各种功能，并且直接参与业务活动，促使业务的完成。角色：有些人可以申请出差，有些人对出差申请可以审批，这两种不同 的人可以作为两个不同的角色。角色是具有某种使用系统特定功能的权利的一个 人员或多个人员的组合。 工作流应用资料：出差申请表格，出差具体说明，这些就是对应某个具 体业务（这里是出差管理）的相关资料，根据这些业务资料我们可以对该业务进 行处理。需激活的应用程序：在需要其它应用程序提供支持的时候，会去激活这 些应用程序。 流程：整个出差申请的过程就是一个流程，它从整体去描述一个业务。 环节：又称活动，它反映了业务流程的局部情况，通常业务流程是由一 个一个的环节组成。 流程实例：将该出差申请这个业务流程实例化，就得到一个流程实例。环节实例：将流程的其中一个环节实例化，就得到一个环节实例。 业务规则：业务的开始和结束需要一定的条件，在处理业务的过程中必 须按照一定的规则，这些都是业务规则，只有严格遵循业务规则，业务才能完成。3.1.1.2工作流对象的具体分析和说明通过一个具体的业务我们可以得到工作流模型的一些对象，那么我们再对其 他一般性业务进行分析，研究，我们就会找到它们的共同点，并归纳出基于这些 业务的公共的对象，这些公共的对象的组合，就是一个通用的模型，也就是工作 流模型，这个模型能去描述每个业务，是我们追求轻量级工作流引擎的最终成果。用户：业务的执行者和参与者，对应于企事业的每一个雇员，是一个独 立的、具有一定行为能力和一定技术能力的人的实体；角色：以技能为前提，能够完成某项功能的人员的总称；部门：对应于企事业的静态结构划分，由企事业的实际部门设置情况来 决定，可以是传统的面向职能的，也可以是现在流行的面向过程与客户的； 职位：以行政责任为前提，代表了管理上的等级关系；工作组：以执行某一任务为目标而动态组建的、跨部门划分的一种组织 结构； 流程：对应于一个业务过程，表示一个业务由发起、处理、结束的一个 过程；流程实例：对应于一个业务流程具体应用，是业务流程实例化的表现形 式； 环节：对应于业务流程中一个单一的业务操作，是流程按照业务要求的 细化；环节实例：对应于一个环节的具体应用，是环节实例化的表现形式； 工作流定义主信息：描述一个工作流模型的主要信息，从整体来描述工 作流模型；(11) 工作流附件信息：描述一个工作流模型所用到的附件信息，也就是工作 流应用资料，或者叫业务资料。按照WFMC提出的工作流模型，这不是工作流模 型所包含的对象，可是我们对其进行格式化，把它抽取成一个模型对象，用来规 定了工作流模型在具体应用时所需业务资料的格式，我们把它分为两类： 表格类型：这是以表格的形式保存附 件信息，可以用关系结构来定义附件信 息，并保存在数据库中，每一条记录就 是一个该附件的实例； 文档类型：只是以文件形式保存附件 信息，可以是work文档，也可以是文 本文件，它的实例化是就是一个一个带 有对应某个业务应用标志的文件，保存 在硬盘上(12) 工作流实例信息：描述一个工作流模型实例化的信息，也作为启动一个 工作流的信息，它记录该业务流程随着时间和人员的参与处理的不断变化，直到 整个业务的结束；(13) 工作项信息：描述参与某个业务应用时被分配到的一项任务，这就体现 了参与人员和系统交互的典型特征；(14) 业务规则：描述业务在运行的过程中必须要遵守的规定和原则，也是业 务活动得以向另一个活动推进的规则。我们把它分为四类规则，分别是： 自动型：它主要描述一些只给参与人员查看业务信息的业务规则，例如 通知、公文流转等等业务。该类业务不需要参与人员去审批或其它人为 上的处理，只需要参与人员去查看其中的内容就足够，整个业务流程的 完成是全自动的。 与聚合：业务活动的完成是需要参与该活动的所有人员都进行人为处理, 其中有一个人员没对其进行处理，整个活动只能停在原地，等待所有人 员的处理，当最后一个参与人员执行了处理工作，它才能完成。 或聚合：在参与某一业务活动的人员当中只要有一个对其进行处理，整 个活动就可以完成。 投票聚合：统计参与该活动的参与人员的处理结果，当满足一定条件该 活动才能完成。(15) 转换条件：描述流程、活动状态改变时需要的条件，用于业务运行过程 中的约束。例如流程的完成必须等待所有活动的完成才能完成，活动的完成必须 按照业务规则去完成等等；(16) 需激活的应用程序：工作流管理系统需要其它应用程序的支持，例如编 辑和查看文本文件信息等等；(17) 日志信息：描述工作流中所有的状态改变、事件和控制流相关资料的变 化，工作流实例和环节实例的启动、结束、挂起和激活等等信息都会记录下来, 以便对其进行管理。对象之间的逻辑关系在找出工作流模型的对象后，我们就开始分析它们之间的业务逻辑关系。3.1.2.1对对象进行分类以及各个分类中对象之间的关系到此为止，我们有必要对工作流模型对象进行一下分类，根据工作流对象对工作 流管理系统所起的作用我们可以分成以下几类：组织模型组织模型描述了企事业的组织机构关系，包括的对象有用户，部门，职位， 角色，工作组，它们的关系可以用下图表示：图3.1组织模型结构从图中可以看到它们之间的关系，用户是基本的单位，部门是由用户组成， 每个用户对应一个职位，负责该职位所要求的职能，用户凭着某种资格赋予一种 角色，工作组也由用户组成，也可以由角色组成。这几个基本的对象以及其关系 所构成的组织模型，已经可以满足轻量级工作流引擎对组织模型的需要了。工作流定义模型工作流定义模型描述了工作流模型的定义信息，包括工作流定义主信息，流 程定义信息，环节定义信息，工作流附件信息，业务规则。它们之间的关系如下 图：图3.2工作流定义模型结构流程是包含若干环节的，而环节遵循一定的业务规则，再加上工作流主信息 和附件信息，共同构成工作流定义模型。工作流实例模型工作流实例模型描述了工作流模型实例化时的信息，通过这些信息我们可以 知道实例过程中的各种状态变化和最终的结果，因而得到一个业务具体应用的情 况。它包括流程实例，环节实例，工作流实例信息，工作项信息和转换条件，它 们之间的关系如下图：图3.3工作流实例模型结构转换条件影响工作流实例，流程实例，环节实例和工作项的状态，并由转换 条件去决定它们的状态转变，工作流实例信息T流程实例信息T环节实例信 息T工作项信息，自上而下逐层细化，不但从全局了解业务运行情况，而且从 局部了解业务运行的细节情况。而它们的状态改变都会记录在日志中，用以追踪 工作流实例的运行情况。外部支持模型外部支持模型在本文只包括一个对象，就是需激活的外部应用程序，严格来 说这不是工作流模型的一部分，可是提供接口去激活所需的外部应用程序为工作 流管理系统提供支持是工作流模型的功能之一。有了这些外部应用程序的支持， 我们的工作流管理系统的功能才变得更完善。3.1.2.2各个模型之间的逻辑关系不但模型中各个对象有一定的逻辑关系，而且各个模型之间也有一定的逻辑 关系，如下图所示：图3.4模型之间的关系组织模型的用户定义工作流定义模型；工作流定义模型使用组织模型的角色 和工作组，用来规定工作流模型的启动条件和任务分配条件，因为工作流模型的 启动和任务的分配必须由一定的角色或工作组完成；工作流实例模型依赖工作流 定义模型，同时使用组织模型的所有对象，并且调用外部支持模型为其提供支持。工作流实例，流程实例，环节实例和工作项的状态转换工作流实例，流程实例，环节实例和工作项从不同的层次去描述业务运行过 程的具体情况，不同级别的用户可以看到业务运行的不同方面，创建工作流实例 的用户可以看到工作流实例信息以及其状态转换，参与该工作流实例的用户可以图3.6流程实例状态图任务分派 任务分派是工作流引擎的一个重要功能。当环节实例产生时，就会以一定的准则 把需要处理的工作当作一项任务项（工作项）分派给参与该环节实例的所有用户， 而这些用户是同属一个角色或者工作组的。我们又把角色和工作组进行细化，可 以得到以下准则： 基于部门的：这就是说把任务分派到某个部门的所有人员，该部门的所有人 员都参与了该项任务，因而会为该部门的所有人员都产生一个工作项；基于职位的：这就是说把任务分派到某个职位的所有人员，同属该职位的所 有人员都被分配到一项工作项； 基于部门职位的：这就是说把任务分派到某个部门的某个职位的所有人员， 同属该部门的该职位的人员都被分配到一项工作项；基于所有人的：这就是说把任务分派到该企事业的所有人，该企事业的所有 人都被分配到一项工作项；基于工作组的：这就是说把任务分派到该企事业的某个特定的工作组上，同 属该组的所有人员都被分配到一项工作项。基于部门的，基于职位的，基于部门职位的和基于所有人的这四种类型，其 实是基于角色的细化，通过这些准则的分类，我们尽量做到系统与企事业有较强 的适应性，以及使系统在任务分派时有较大的灵活性。转换条件的满足工作流实例，流程实例，环节实例和工作项的状态转换有各自特定的条件， 分别如下：工作流实例的转换条件工作流实例从整体看业务运行过程，工作流实例被用户创建后就进行初 始化并提交给工作流引擎，由工作流引擎去处理，此时实例处于运行状态；在运 行过程中，它会根据流程实例的状态而不断进行本身的状态改变；当管理员由于 某种原因要挂起它时，它就处于挂起状态，直到管理员重新激活它使它处于运行 状态或者终止它使它非正常结束；当它被正常处理完毕后，就正常结束。流程实例的转换条件流程实例也从整体看业务的运行过程，流程实例在工作流实例初始化时 就开始它的工作。在运行过程中，它会根据各个环节的完成程度来改变自己的状 态，当所有环节实例都正常完成它就正常结束；管理员可能要挂起它使它处于挂 起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常结束。环节实例的转换条件环节实例从某个方面看业务的运行过程，环节实例在流程实例运行时就开始 它的工作处于处理中状态。之后环节实例的状态由两方面决定，一是工作项的处 理结果，一是业务规则的规定。 如果业务规则是自动型的，不管工作 项的处理结果怎样，当系统把任务项分 派（给特定用户）完毕后，该环节实例 就正常完成处于正常结束状态； 如果业务规则是与聚合的，系统分派 完任务项后，当所有参与人员都正常处 理完该环节各自的工作项后，该环节才 正常完成处于正常结束状态；在处理过 程中，只要有一个工作项是非正常处理 的，该环节就非正常完成处于非正常结 束状态；在处理过程中，有工作项还未 被处理并且没有一个工作项被非正常 处理，那么环节实例仍然处于处理中状 态； 如果业务规则是或聚合的，系统分派 任务后，只要有一个工作项是正常处理 的，该环节实例就正常完成处于正常结 束状态；如果所有同属该环节实例的工 作项都被非正常完成，那么该环节实例 就处于非正常结束状态； 如果业务规则是投票聚合的，系统分 派任务后，统计工作项的完成程度，当 正常完成的工作项数量达到一定数量 时，该环节实例就正常完成处于正常结 束状态；当正常完成的工作项数量不达 到规定的数量时，该环节就非正常完成 处于非正常结束状态；当所有工作项还 没处理并且正常完成的工作项还没达 到规定数量时，该环节实例仍然处于处 理中状态。工作项的转换条件工作项从更细节的方面看业务运行过程，工作项的状态转换要看参与人员对 各自的工作项的处理情况和业务规则的规定。我们把与聚合，或聚合和投票聚合 这些要人工干预的规则统称为人工型规则。 如果业务规则是自动型，同属该规则 的工作项的状态就只有正常处理后的 正常结束状态，当然如果对该工作项还 没被处理则处于处理中状态，可这不对 环节实例等产生影响； 如果业务规则是人工型，就会有正常 处理和非正常处理两种情况，正常处理 该工作项则使到该工作项处于正常结 束状态，非正常处理该工作项则使到该 工作项处于非正常结束状态。3.2系统结构本着基于轻量级工作流引擎的原则，我们已经对工作流模型进行了详细的分 析和详细的设计，在这里我们就提出一个系统结构，如下图所示:组织定义接口工作流定义接口工作流实例接口z组织定义器组织定义数据_工作流定义器7组织 管理器任务管理器工作流解析器实例调度中心7X*任务分派器启动控制器日志 数据工作流实例数据状态转换器工作流 定义数 据 一图3.6工作流引擎系统结构图从图中可以知道，系统提供了三类接口：组织定义接口、工作流定义接口和 工作流实例接口。这三类接口实现了工作流模型的接口一，接口二，接口三和接 口五规定的主要功能；系统有一个实例调度中心，这是一个很重要的部件，它控 制工作流实例的运行，通过工作流解析器对该工作流模型进行解析其含义，通过 任务分派器按照一定的分派准则把任务项分派给参与该工作流实例的用户，通过 任务管理器管理各个任务项的信息，通过启动控制器控制工作流的启动权利和启 动信息，通过状态转换器控制工作流实例、流程实例、环节实例和工作项的状态 转换；组织定义器定义企事业的组织结构；工作流定义器定义工作流模型信息， 并通过组织管理器得到组织定义信息，为工作流模型提供组织支持。各个部件处 理的相关信息都保存在数据库中。3.3系统模块的划分根据功能实现的不同我们进行模块的划分如下：用户管理模块：对用户信息的管理，包括注册用户信息，注销用户信息， 查询用户信息等功能；（2）部门管理模块：对企事业部门结构信息的管理，包括增加部门信息，删 除部门信息，查询部门信息等等功能；职位管理模块：对企事业职能信息的管理，包括增加职位信息，删除职 位信息，查询职位信息等等功能；角色管理模块：对企事业某种技能信息的管理，包括新增角色信息，删 除角色信息，查询角色信息等等功能；-工作流模型管理模块：对工作流定义模型信息的管理，包括定义新的工 作流模型信息，删除旧的工作流模型信息，查询工作流模型信息；工作流实例管理模块：对工作流实例信息的管理，包括启动一个新的工 作流实例，查询工作流实例信息，按照一定的业务规则生成新的环节实例信息， 为用户分派工作项，管理工作项信息，按照一定的转换条件为工作流实例、环节 实例转换状态等等功能；系统监控模块：为工作流实例，环节实例等的状态转换信息加入日志， 挂起、激活工作流实例，强制结束工作流实例，为迟迟不对自己的工作项进行处 理的用户发出提醒或警告信息，查看各个工作流实例的完成程度等等功能。功能模块的划分，为系统的实现做好充分的准备。3.4数据库设计基于轻量级的工作流引擎的特点之一就是把系统相关的资料，如工作流模型 定义信息，工作流实例信息，组织模型定义信息等等，都以特定的实体形式保存 在关系型数据库中。工作流定义主信息表（workflowTable）静态定义工作流主要信息，包括该工作流的标识ID （可以定义为以” WORKFLOW_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x 是自动生成的序号）， 工作流名称，工作流描述，工作流类型（工作流的类型有自动型，人工型和混合 型，自动型不需要人工参与，由工组流引擎自动执行，人工型需要人工参与，混 合型包含了自动型和人工型），工作流创建日期，工作流创建者ID（即用户ID）， 工作流创建人名称（即用户名），工作流生命周期（每个工作流实例都有它的生 命周期期限，在该期限内还没完成它的工作就直接死亡），目前该工作流实例数 目（记录当前工作流实例数目），工作流启动者角色（指明该工作流可以由哪个 角色发起，属于该角色的用户都可以启动该工作流模型对应的实例）。工作流重 要信息还包括两方面，一是工作流附件，因为在工作流进行过程中，肯定会带有 一些信息，这些信息对于出差申请来说就是出差申请表，对于公文流转来说就是 以word文档形式的公文，对于通知来说可能就是以文本文档形式的通知书，等 等；一是工作流流程描述，包括若干个环节（act ivi ty）,这些环节有一定的顺 序，表现工作流顺序执行的特征。把工作流附件和工作流流程描述从工作流定义 分离出来，是基于工作流附件和工作流流程描述对于不同工作流有不同形式和数 量的原因，有利于工作流附件和工作流流程描述的扩展。工作流附件信息表（workflowAttachmentTable） 静态定义工作流所需要的附件，包括附件ID （可以定义为以”Attachment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 形式,x是自动生成的序号），工作流ID （标识属 于哪个工作流），附件类型（表或文件），附件名 称（如果类型是表，则为该表的名称，如果是 word 文档，则为该文档名称，如果是文本文档，则为该 文件名称），其它信息（如果类型为表格，该字段 以一定的格式保存该附件表格的所有字段的各种 信息，包括字段名称，字段数据类型，数据类型长 度，字段描述）。 工作流流程描述表（workflowProcessTable） 静态定义工作流的流程，由若干环节（activity）组成，一个环节为一条记录，包括工 作流ID （环节所属工作流ID），环节ID （可以定 义为以” ACTIVITY_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形 式,x是自动生成的序号），环节名称（即该环节 名称），环节描述（对该环节的具体描述），参与 者角色ID （将相同权限的用户作为一个集合，在 数据库以同一个角色操作数据库特定操作，该项标 识角色ID），环节任务分派规则，上一个环节ID（保存上一个环节的ID，由这项可以判断该环节 是否整个流程的开始环节，或者该环节的任务没有 完成（审批不通过，或没在其生命周期期限内完成） 时作回滚处理的重要数据项，根据这个数据项可以 回滚到上一个环节），下一个环节ID （保存下一 环节的ID,由这项可以判断该环节是否整个流程 的结束环节，或者该环节的任务完成了，根据这个 数据项可以启动下一环节，继续向前推进）。 工作流实例启动描述（workflowinstanceStartUpTable）动态定义工作流实例启动信息（其实这也是工 作流实例信息表）启动者在产生一个工作流实例之 前必须根据工作流的定义做好准备工作，这些准备 工作的信息就填入该表中，然后交付给工作流引 擎。该描述包括工作流ID （所属工作流ID）,工 组流实例ID （标识该工作流实例，可以定义为以” WORKFLOWINSTANCE_xxxxxxxxxxxxxxxxxxxxxxxxxx xxxxx”形式,x是自动生成的序号），工作流实例 描述，工作流实例创建时间，工作流实例创建者 ID （启动者ID），工作流实例创建者名称，当前 工作流状态（标识当前工作流实例的状态，启动者 在创建后却没提交给工作流引擎前的状态为“initialized”初始化状态，之后的状态要视工 作流类型而定），当前状态具体描述，当前操作者 ID （当前工作流要被谁操作），当前操作者名称。 工作流实例完成标志（标识该工作流实例的完成）， 工作流实例完成时间，当前工作流状态和当前操作 者ID和当前工作流状态具体描述三项在工作流实 例的运行过程中，可以动态追踪该工作流实例的运 行，而这三项再加上工作流完成标志和工作流完成 时间，可以知道该工作流实例的完成情况。工作流实例过程描述 （workflowInstanceProcessingTable） 以环节为单位动态描述工作流实例的处理过 程，启动者创建工作流实例后，提交给工作流引擎 后，工作流实例就根据工作流定义的流程进行运转 了。包括工作流实例ID，工作流实例所对应环节（工 作流流程就是由一系列的环节组成，按照预定义的 流程一个环节过渡到另一个环节），当前该环节所 处状态（这标识着该环节在处理过程中的状态，最 终状态表示该环节的完成状态），当前操作者（对 应的是角色），当前状态具体描述。 工作项描述（workItemTable）动态描述已经参与该工作流实例处理的参与者 （对应已处理环节的角色的每个用户）的工作情 况。包括工作项ID （可以定义为以”WorkItem-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 形式,x是自动生成的序号），工作项名字，工作项 描述，工作流实例ID （该工作项所属的工作流实 例），该环节任务分派规则（继承环节的任务分派 规则，用于判断该环节任务完成方式），当前该工 作项所处状态（根据不同的工作流类型有不同的状 态，根据这些状态可以在参与者接口上显示不同的 工作项列表），执行动作（记录执行者会对该工作 项执行怎么样的动作，如果是申请事务则是审批通 过或审批不通过），执行时间（记录该执行动作的 时间），用户ID （标志该工作项是属于谁的。用户描述（UserTable）该表描述所有用户的资料，包括用户ID （可 以定义为以” User-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形 式,x是自动生成的序号），用户名称，用户密码， 用户所属部门，职位等等信息，级别是该用户的系 统权限，包括普通职员，高级职员和系统管理员。 日志信息描述（LogTable）描述用户的工作日志，便于对各种操作进行追 踪。包括日志ID （可以定义为以” Log-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 形式,X 是自动生成的序号）等等，其中有一项是相关工作 项ID，这是当参与者对原始工作项进行执行操作 动作时的工作项。 角色信息（RoleTable）描述角色的信息，包括角色ID （可以定义为以”Role_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x 是自动生成的序号），角色 名称，部门名称，职位名称，角色描述。角色由部门和职位组成。 部门信息（DepartmentTable）描述部门的信息，包括部门ID （可以定义为以”Depatment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x 是自动生成的序号）， 部门名称，部门其它信息。（11）职位信息（PositionTable）描述职位的信息，包括职位ID （可以定义为以”Position_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x 是自动生成的序号）， 职位名称，职位其它信息。除了以上这些主要表以外，还有一些我们是在定义工作流模型的时候才加入 数据库的，如对应工作流附件类型为表的表格。为了减少网络流量和提高系统的 运行速度，我们把一些有关联的数据库操作写成存储过程：删除工作流模型存储过程：删除一个工作流模型，必须删除它的工作流 定义主信息，同时删除对应的附件信息，附件为表的表格，环节信息；创建附件类型为表的表格：定义附件信息时已经把该表格的字段信息保 存在该附件信息的其它信息字段中，并且有一定的格式，那么我们从该字段中按 照一定的格式还原表格的字段信息，并根据这些信息在数据库中创建该表格。3.5类的设计用面向对象的方法和UML建模工具，再根据系统结构图，模块的划分和数据 库的设计，我们把对象转化成类，进行类的设计。我们把整个系统的类分成三部 分，一是实体类，二是业务类，三是接口类。实体类的设计工作流模型的对象就是一个一个的实体，实体类又分为数据库访问类和值对 象类。数据库访问类是对存储在数据库的实体信息进行访问（插入，删除，更新， 查询）的类，值对象类是在客户端和服务器端之间交换资料的实体信息类。3.5.1.1数据库访问类 数据库连接类：该类是其它数据库访问类的父类，管理数据库的连接， 负责从数据库连接池找可用的数据库连接给其它数据库访问类使用，使用完毕后 负责放回连接池，类图如下图：说明：属性只有一个connection，它代表数据库的一条连接，类型为Connection,方法有一个构造函数workflowDAO()和一个关闭连接的函数 closeConnection()。WorkflowDAO()实现从数据库连接池找一个可用连接并赋值 给属性connection, closeConnection()负责把连接放回数据库连接池。工作流定义主信息访问类：对应数据库的工作流定义主信息表，该类封 装了对该表格记录的各种操作，就是插入或删除一条工作流定义主信息，查询特 定工作流定义信息或者所有工作流定义信息，类图如下图：说明：构造函数WFDefineMainInfoDAO()调用父类构造函数，从数据库连接 池中找一个可用的数据库连接(其它数据库访问类也一样)。 工作流流程信息访问类：对应工作流流程描述表，该类封装了对该表格 记录的各种操作，流程是由若干环节组成，就是插入或删除一条环节信息，查询 同属于一个流程的环节信息等等，类图如下图：说明：findWorkflowFirlstActivitylnfo()函数负责找该工作流模型的第一 个环节的信息，findWorkflowNextActivitylD ()负责根据当前环节ID找下一环 节的信息。 工作流附件信息访问类：对应工作流附件信息表，该类封装了对该表格 记录的各种操作，就是插入或删除一条工作流附件信息，查询同属于一个工作流 模型的附件信息。类图如下：工作流附件类型为表的信息访问类：对应工作流附件类型为表格的信息 表，该类封装了该表记录的各种操作，就是插入或查询一条工作流附件类型为表 格的具体信息，类图如下： 工作流实例启动信息访问类：对应工作流实例启动信息表，该类封装了 该表记录的各种操作，就是插入或查询一条工作流启动信息，查询同属于一个用 户的工作流实例启动信息，更新部分字段信息，类图如下：说明：selectFinishedWorkflowInstanceStartUpInfoV0()负责查询特定用 户启动的并且已经完成的工作流信息，selectNotFinishedWorkflowInstanceStartUpInfoV0()负责查询特定用户启动 的并且还没有完成的工作流信息，updateWFInstFinishedFields()负责在工作流 实例结束时更新特定的字段信息，updateWFInstProcessingFields()负责在工作 流实例运行工程中更新特定的字段信息。工作流实例过程信息访问类：对应工作流实例过程信息表，该类封装了 该表格记录的各种操作，每一条记录实际上是一个环节实例，就是插入、删除或 查询一条环节实例信息，查询指定工作流实例的所有环节信息，更新部分信息字 段，类图如下：说明：SetWFInstProcessingCurrentPerformerNumField()负责更新已经处 理该环节实例对应的工作项的参与该环节实例的用户数目， updateWFInstProcessingFields()负责在环节实例处理过程中更新特定的字段 信息。 工作项信息访问表：对应工作项表，该类圭寸装了该表格记录的各种操作, 就是插入或删除一条工作项信息，查询工作项信息，更新工作项信息，类图如下:说明：selectFinishedWorkItemV0()负责查询特定用户已经处理完毕的工作 项信息，selectNotYetFinishedWorkItemVO()负责查询还没有处理的工作项信 息，updateWorkItemFields()负责更新工作项在处理过程中的特定字段信息， isPerformedInWorkItemByUser()负责判断该工作项是否已经处理完毕。用户信息访问表：对应用户信息表，该类圭寸装了该表格记录的各种操作, 就是插入、删除或查询一条用户信息，查询特定角色对应的用户信息，类图如下:说明：selectCountRS（）负责统计同属于一个角色的用户数目。角色信息访问类：对应角色信息表，该类封装了该表记录的各种操作,就是插入、删除或查询一条角色信息，查询所有角色信息，类图如下：（11）部门信息访问类：对应部门信息表，该类封装了该表记录的各种操作,就是插入、删除或查询一条部门信息，查询所有部门信息，类图如下：（职位信息访问类：对应职位信息表，该类封装了该表记录的各种操作,就是插入、删除或查询一条职位信息，查询所有职位信息，类图如下：(13)日志信息访问类：对应日志信息表，该类圭寸装了该表记录的各种操作, 就是插入、删除一条日志信息，查询特定的日志信息，类图如下：3.5.1.2值对象类值对象类其实是一种数据结构，用于客户机和服务器之间的数据交换，也用 于对象实例的数据传递，它有若干属性，可是很少方法，实例化后就对应数据库 表的一条记录。工作流定义主信息值对象类：可以保存工作流主信息表的一条记录信息, 类图如下：工作流流程信息值对象类：可以保存工作流流程信息表的一条记录信息, 类图如下：工作流附件信息值对象类：可以保存工作流附件信息表的一条记录信息, 类图如下：说明：SetOtherlnfo ()负责以一定格式把工作流附件类型为表的表格字段信 息保存在Otherlnfo中，GetOtherInfo()负责从Otherlnfo中以一定的格式还原 工作流附件为表的表格字段信息。工作流附件类型为表的信息值对象类：可以保存工作流附件类型为表的 信息表的一条记录信息，类图如下：说明：tableName就是工作流附件类型为表的表格名称，fieldValue就是对 应该表的一条记录的各个字段值，用可变长数组Vector保存下来。 工作流实例启动信息值对象类：可以保存工作流实例启动信息表的一条 记录信息，类图如下：工作流实例过程信息值对象类：可以保存工作流实例过程信息表的一条 记录信息，类图如下：工作项信息值对象类：可以保存工作项信息表的一条记录信息，类图如下：用户信息值对象类：可以保存用户信息表的一条记录信息，类图如下角色信息值对象类：可以保存角色信息表的一条记录信息，类图如下 部门信息值对象类：可以保存部门信息表的一条记录信息，类图如下(11)职位信息值对象类：可以保存职位信息表的一条记录信息，类图如下(12) 日志信息值对象类：可以保存日志信息表的一条记录信息，类图如下（13）信息集合值对象类：可以保存各种信息的一个集合，当需要返回多条记 录信息的时候可以使用该类，类图如下:说明：只有一个属性，是一个可变长数组，可以存放不定数量的记录信息。业务类的设计业务类，其实就是边界类，它根据系统的需求按照一定的方式把各个实体类 联系起来，以实现系统的各种功能。按照实现功能的不同我们可以分为用户管理 类，角色管理类，部门管理类，职位管理类，工作流模型管理类，工作流实例管 理类，系统监控管理类。用户管理类：负责用户的注册，注销，检测合法性，查找用户信息，类 图如下：角色管理类：负责新增加角色，删除角色，查找角色信息，类图如下:部门管理类：负责新增加部门，删除部门，查找部门信息，类图如下:职位管理类：负责新增加职位，删除职位，查找部门信息，类图如下: 工作流模型管理类：负责工作流模型的定义，解析，类图如下: 工作流实例管理类：负责工作流实例的创建，维护各种实例的状态信息, 分派任务给用户，用户处理工作项等等的工作，类图如下：说明：uploadAttachmentToServer()负责把工作流附件类型为文档的文档上 传到服务器特定目录下。系统监控管理类：是一个综合类，主要通过调用其它管理类的功能来实现 本身的功能，就是查看工作流实例的过程状态，完成程度，根据一定的条件有必 要控制实例的挂起，激活，结束，查看各个参与用户的工作情况，在出现工作误 时、意外、异常等等情况时采取一定的措施保证整个实例的完成。而所有这些都 保存在日志中。接口类的设计接口类是工作流引擎提供给外部应用的类，应用系统通过调用这些类，来实 现一定的应用功能。我们在接口类的设计上，采取格式统一、隐藏系统复杂性、 功能调用方便的原则，尽量为外部应用系统提供简洁、易懂的功能调用接口。因 而我们把这些类都设计成只有一个业务类实例，一个ToDoWhat()方法的类，并 且每一个业务类对应一个接口类。在这些接口类中，业务类实例作为它的一个数 据成员，ToDoWhat()方法有两个参数，toDoCode (工作代码)和object (数据 交换对象)，工作代码表示要调用的功能的标识，数据交换对象表示功能调用要 处理的数据（应用数据）。从本质上来说，就是根据不同的工作代码调用业务类 实例的不同方法，对各种应用数据进行处理。第四章系统实现系统的实现主要包括关键问题的解决方案和一个工作流管理应用系统的实 践。首先提出关键问题，然后给出解决方案，最后提出一个应用架构，利用J2EE 技术和数据库技术实现一个基于轻量级工作流引擎的简单工作流管理应用系统。4.1关键问题的解决方案在实现工作流引擎的时候，有一些关键问题，例如启动工作流实例，推动工 作流实例的进程，类型为文档的附件的处理等等，都是要重点解决的。启动工作流实例当根据各种业务需求创建了对应的工作流模型，根据结构组织情况创建了组 织模型后，用户就可以创建工作流实例并启动它。用户把工作流实例的信息提交 给工作流引擎，那么工作流引擎如何工作呢？工作流引擎其实做了一系列的工 作，其处理过程如下：工作流引擎得到用户创建的工作流实例数据，记录在工作流实例启动信 息表中；工作流引擎解析对应该工作流实例的工作流模型的含义，获得必要信息 提供给工作流实例使用；工作流引擎根据这些必要信息找到工作流模型对应流程的第一个环节信 息，并生成该工作流实例的第一个环节实例，记录在工作流实例过程描述表中；工作流引擎根据任务分派原则开始把任务项分派给参与该环节实例的所 有用户；工作流引擎根据该环节定义的参与者角色，找出所有同属于该角色的所 有用户，为各个用户都生成一个工作项，记录在工作项信息表中，工作项要继承 该环节定义的业务规则，完成任务的分派； 工作流引擎根据该环节定义的业务规则，如果该环节是自动型的，则为 该环节的参与用户分派完任务后立刻就根据该环节信息去找下一个环节的信息， 进行下一环节实例的处理；如果该环节不是自动型的，是需要人工参与处理的， 则工作流引擎暂停该工作流实例的处理工作，等待参与用户处理的结果；启动工作流实例的工作结束。推进工作流实例的进程如果上一环节定义的业务规则是自动型的，则立刻根据当前环节信息查 找下一环节； 如果上一环节定义的业务规则是不是自动型的，则等待参与用户对各自 的工作项进行处理，当每一个用户处理完后，工作流引擎都要判断该环节实例是 否结束，结束的条件是业务规则的规定和用户的处理结果。 如果业务规则是与聚合，当当前用户 的处理结果是非正常处理的话，该环节 实例就结束，并且该工作流实例也结 束，通知其他还没处理的用户该环节已 经结束，并记录在相应的数据库表中； 当当前用户的处理结果是正常处理的 话，则再判断是否所有参与的用户都处 理完毕，如果是则结束该环节，通知其 他用户该环节已经结束，并记录在相应 的数据库表中，然后查找下一环节，如 果不是则等待其他还没处理的用户的 处理结果。 如果业务规则是或聚合，当当前用户 的处理结果是正常处理的话，该环节的 实例就结束，并且该工作流实例也结 束，通知其他参与还没处理的用户该环 节实例已经结束，记录在相应的数据库 表中，然后查找下一环节；当当前用户 的处理结果是非正常的话，则等待其他 还没处理的用户的处理结果。 如果业务规则是投票聚合，当当前用 的处理结果是正常处理的话，则使统计 正常处理结果的计数器加一，然后判断 该统计数量是否已经达到规定的数量， 如果是则结束该环节实例，并通知其他 还没处理的用户该环节实例已经结束， 记录在数据库表中，然后查找下一环 节；当当前