第一章
引
言1.1 轻量级工作流引擎的概念 轻量级的工作流引擎指的是从够用、灵活和低成本的设计原则出发，不追求工作流引擎的功能的完备和复杂，只是实现其中必不可少的功能和特征。在设计工作流引擎时主要考虑对其数据模型的定义和解释、活动之间的协调以及任务的分配和控制等功能提供支持，而不支持诸如提供内建（built-in）的应用开发工具、对应用资料的定义和完整性维护、完善的异常处理以及长事务控制等功能。轻量级工作流引擎的概念的提出，给开发工作流管理系统的开发人员开辟了一条新的道路。工作流管理技术本身就是一项抽象复杂的技术，它致力追求从企事业各种各样的业务中抽取出一个通用的模型，由这个模型去描述所有业务的一致性，以达到“放之四海皆可用”的程度。不过，要把众多的而又错综复杂的业务都集中在这个模型中，这是一件非常困难的工作，要经过一段漫长的摸索历程。而轻量级的概念让我们认识到可以从一般性的而又简单的业务入手，为企事业快速的开发出一个适应他们本身业务需求的而又带有可扩展性可移植性的信息管理系统，为他们提高工作效率，并保证在一段很长的时间内满足不断增加的业务需求。
1.2 工作流管理系统的分类及本文的侧重点
根据工作流过程本身的特点、系统建模的方式、所使用的底层支撑技术、以及工作流过程的执行方式等的不同而对工作流管理系统进行相应的分类。
1.2.1 面向文档的与面向过程的
前者的侧着点在于将电子形式的文件、图像等在有关的人员之间进行分发，以便能够得到不同人的处理与审阅。现有的文件管理与映像管理系统均属此类。在面向过程的WFMS中，工作流被描述成一序列执行环节。与各环节相应都有待处理的资料对象。各环节的资料对象可以按不同的方式分发到其它环节中去，如可以将资料对象的值作为控制条件、或者依此资料对象组装成其它的资料对象等。高端的WFMS一般都属此类系统。
1.2.2 结构化的与即席的
结构化工作流指的是在实际工作过程中会反复重复、严格按照某个固定的步骤进行的业务过程。定义此种工作流所需要的各种类型的信息可以通过对业务过程进行详细的分析而得到，从而得到完整的过程定义并在以后的应用过程中反复使用。大量的办公程序，如公文处理、审批等都属此类。即席工作流则是针对那些重复性不是很强或没有重复性的工作流程的，关于这类流程执行所需的有关参数(如参加者等)事先无法确定，而必须推迟到过程实例运行时才能确定，同时在执行过程中间还可能会发生一些意外的情况。这种动态多变的特点在提供更高灵活性的同时，也为过程的建模与执行带来更多的复杂性。 1.2.3 基于邮件和基于数据库
前者使用电子邮件来完成过程实例执行过程中消息的传递、资料的分发与事件的通知。低端的系统所使用的经常就是此种方法，它可以充分发挥电子邮件系统在广域环境下的资料分发功能，但整个系统将运行于一种松散耦合的模式下。在基于数据库的WFMS中，所有的资料都保存在某种类型的DBMS中，过程的执行实际上就是对这些资料的查询与处理。高端的大规模系统所使用的一般都是此种方法。
1.2.4 任务推动的与目标拉动的
前者指的是从过程的开始逐步地一个环节一个环节的执行，当某个活动实例被处理完之后，后续的有关活动将被创建并被激活，由此直至整个工作流程的完成。这是目前大多数面向过程的WFMS所使用的执行方式。而在目标拉动的WFMS中，一个业务流程被看成是一个目标。过程实例执行时，该目标将被分解得到多个相互之间按一定约束条件的关联起来的可执行的多个环节，其中各环节还可以当成是子目标而进一步进行分解。在各环节均执行完毕之后，整个过程也就完成了。目标拉动是一种全新的执行方式，下一代的WFMS将具有此种特征。应该说明的是：上述分类只是从不同的角度入手的。一般来说，后面那些特点将给WFMS带来更好的灵活性，同时也将成为那些能够支持跨机构的大规模复杂工作流管理、面向关键任务的WFMS不可缺少的特征。 1.2.5 本文的侧重点
本文的侧重点不在于完全实现其中一种工作流管理系统的所有功能，更不在于实现所有种类的工作流管理系统的全部功能，前文已经说过，这是一件非常困难的事情。那么我们的侧重点在哪里呢？就在于综合以上四种工作流管理系统的主要特点，是一个面向文件的，基于数据库的，由目标拉动的结构化的工作流管理系统，并且由此去设计和实现工作流管理系统的核心――工作流引擎。从一般性来说，目前大多数的企事业的业务都是事务申请，公文流转，各项通知等等，这些业务或者需要查看，或者需要审批，而这些业务的资料基本上是以文件的形式保存在计算机上，而其中一些格式化的资料是保存在数据库中，所以面向文件和面向数据库是轻量级工作流引擎的一个重要特征。业务的发起和结束是一项过程化的任务，任务又可以分解成一个一个环节任务，而任务是带有目的性的，由这个目的去拉动这个过程中的一个一个的环节任务，促使环节任务的推进，最终达到任务完成的目的。这些业务的过程化不是随机的，而是已经严格规定好的，只有遵循这些过程化的规则和流程环节才能完成整个业务。轻量级的工作流引擎就组合了以上这些，不追求工作流引擎的功能的完备和复杂，以满足一般性业务为目的，为企事业快速开发出适合他们业务的工作流管理系统。
第二章
工作流管理系统参考模型简介在阐述工作流引擎之前，我们来了解一下工作流技术的基本知识。早在几年前，为了建立工作流管理系统的相关标准，国际上成立了一个称为“工作流管理联盟”（简称WFMC）的国际组织。她提出了有关工作流管理系统的一些规范，定义了工作流管理系统的结构及其与应用、管理工具和其它工作流管理系统之间的应用编程接口，也就是工作流系统参考模型。
WFMC给出的工作流参考模型如下图：
接口2
接口3
接口4
接口1
接口5
过程定义工具
工作流API与交换格式
工作流执行服务
工作流机
（工作流引擎）
工作流 管理工具
其它工作流 执行服务
工作流机
工作流客户应用
工作流机直接调用 的应用
图2.1 工作流参考模型
从图中可以看出，参考模型包含了五类接口，分别是：
⑴ 接口1：过程定义输入输出接口，这是工作流服务与工作流建模之间的接口，该接口提供的功能包括通信建立，工作流模型操作和工作流模型对象操作。
⑵ 接口2：客户端函数接口，这是工作流服务与客户应用之间的接口，这是最主要的接口规范，它约定所有客户方应用与工作流服务之间的功能操作方式。包括通信建立，工作流定义操作（对过程模型定义操作），过程实例管理功能，过程状态管理功能，任务项列表/任务项处理功能，数据处理过程，过程监控功能，其它的管理功能，应用程序激活。
⑶ 接口3：激活应用程序接口，这是工作流引擎和直接调用的应用程序之间的接口，包括通信建立，活动管理功能，数据处理功能。
⑷ 接口4：工作流执行服务之间的互操作接口，这是工作流管理系统之间的互操作接口，包括连接的建立，对工作流模型和其中对象的操作，对过程实例的控制和状态描述，对活动的管理，对资料进行处理。
⑸ 接口5：系统管理与监控接口，这是工作流服务和工作流管理工具之间的接口，包括资源控制，角色管理，用户管理，过程实例的管理，状态管理，审核管理。
五个接口以及对应的API函数囊括了工作流管理系统的全部功能。一个完整的工作流管理系统就是以工作流引擎为中心，向外部部件（应用程序或其它工作流引擎）提供这五个接口，提供其实现的所有功能。
第三章
系统分析与设计在所有准备工作完成后，我们就开始进行系统设计和设计，构造一个轻量级的工作流引擎。轻量级的工作流引擎并不完全实现WFMC所提出的工作流模型包含的五个接口，特别是接口4，在分布式工作流管理系统才具有该接口。既然我们从轻量级的概念出发，我们就不再明显区分各个接口的界限以及其所具有的特定的功能，以够用、灵活和低成本的设计原则去设计出我们所理解的工作流引擎。我们运用了面向对象的方法，首先从众多的业务需求中抽取出工作流模型所包含的对象，再分析各个对象之间的逻辑关系，然后提出一个系统结构，再进行模块划分，数据库设计，最终完成类的设计。我们当中所用到的建模工具就是ROSE UML。
3.1 工作流模型的设计
对工作流模型的设计是工作流引擎设计的重要组成部分。
3.1.1 工作流模型的对象
企事业经营过程就是一项项业务的实现过程，我们从一般业务入手，并对这些业务进行详细的分析，研究，其结果就是得到一般性的业务对象，从而抽象成工作流模型对象。
3.1.1.1 从一个简单的业务实例看业务的需求
目前企事业的一项基本事务就是出差管理。它主要是对企事业的人员因为某种工作上的原因需要到别的地方出差进行的管理。我们可以列出出差的相关步骤：
⑴ 申请人需要出差，并且他（她）具有出差的权利；
⑵ 申请人填写出差表格，说明因何事出差，出差何处，申请出差金额，何时回来等等和出差相关的情况；
⑶ 申请人需要其它说明的话，可以将更具体的说明以文档的形式保存下来；
⑷ 申请人确认申请无误后提交申请，等待申请的结果；
⑸ 根据规定，该申请必须先让申请人的上一级审批，那么该申请就会以一项工作项的形式交给该级领导处理；
⑹ 处理该申请的领导对该申请进行处理，他（她）会先查看该申请所有的资料，包括出差申请表和与之相关的其它文档，然后对其进行审批，审批的结果是同意那么该次申请会交给再下一级领导处理；审批的结果不同意，该申请被打回，通知申请人申请不通过的结果。等所有需要审批的领导都审批通过了，该申请就成功完成，通知申请人申请通过的结果；
⑺
申请人得到申请的结果，如果审批通过则准备出差，如果审批不通过则根据审批结果对该申请进行修改，重新提交申请； ⑻ 申请事务结束。
这是一个简单的业务实例，对该实例进行分析我们可以得到该业务的一些对象：
⑴ 申请人：他（她）属于该企事业的某个部门的成员，并且具有启动该业务的权利； ⑵ 审批领导：他（她）也属于该企事业的某个部门的成员，并且具有对该业务进行处理的权利；
⑶ 出差表格：它是该业务规定的格式化资料，并且是必须的 ⑷ 出差具体说明：它是该业务附加的资料，可以不要的
⑸ 申请人已经填写好的出差表格：它是出差表格的实例化，代表一个具体的应用 ⑹ 审批同意和不同意：它们是对该业务的处理，遵循一定的业务规则 ⑺ 申请：这是一个过程，不是一个动作，需要时间和人的活动才能完成 ⑻ 审批：这是一个活动，是过程的一部分，并且可以向另外一个活动转化
⑼ 其它应用程序：申请人要填写出差具体说明时要调用相应的外部应用程序编辑该说明并以一定的格式保存下来，审批领导要查看出差具体说明时也要调用相应的外部应用程序打开该说明并以一定的格式显示出来。
从这些业务对象，再利用工作流技术，我们可以得到工作流模型的一些基本对象：
⑴ 用户：正如申请人，审批领导，他们就是工作流管理系统的用户，由他们去使用该系统的各种功能，并且直接参与业务活动，促使业务的完成。
⑵ 角色：有些人可以申请出差，有些人对出差申请可以审批，这两种不同的人可以作为两个不同的角色。角色是具有某种使用系统特定功能的权利的一个人员或多个人员的组合。 ⑶ 工作流应用资料：出差申请表格，出差具体说明，这些就是对应某个具体业务（这里是出差管理）的相关资料，根据这些业务资料我们可以对该业务进行处理。
⑷ 需激活的应用程序：在需要其它应用程序提供支持的时候，会去激活这些应用程序。 ⑸ 流程：整个出差申请的过程就是一个流程，它从整体去描述一个业务。
⑹ 环节：又称活动，它反映了业务流程的局部情况，通常业务流程是由一个一个的环节组成。
⑺ 流程实例：将该出差申请这个业务流程实例化，就得到一个流程实例。 ⑻ 环节实例：将流程的其中一个环节实例化，就得到一个环节实例。
⑼ 业务规则：业务的开始和结束需要一定的条件，在处理业务的过程中必须按照一定的规则，这些都是业务规则，只有严格遵循业务规则，业务才能完成。
3.1.1.2 工作流对象的具体分析和说明
通过一个具体的业务我们可以得到工作流模型的一些对象，那么我们再对其他一般性业务进行分析，研究，我们就会找到它们的共同点，并归纳出基于这些业务的公共的对象，这些公共的对象的组合，就是一个通用的模型，也就是工作流模型，这个模型能去描述每个业务，是我们追求轻量级工作流引擎的最终成果。
⑴ 用户：业务的执行者和参与者，对应于企事业的每一个雇员，是一个独立的、具有一定行为能力和一定技术能力的人的实体；
⑵ 角色：以技能为前提，能够完成某项功能的人员的总称；
⑶ 部门：对应于企事业的静态结构划分，由企事业的实际部门设置情况来决定，可以是传统的面向职能的，也可以是现在流行的面向过程与客户的；
⑷ 职位：以行政责任为前提，代表了管理上的等级关系；
⑸ 工作组：以执行某一任务为目标而动态组建的、跨部门划分的一种组织结构；
⑹ 流程：对应于一个业务过程，表示一个业务由发起、处理、结束的一个过程；
⑺ 流程实例：对应于一个业务流程具体应用，是业务流程实例化的表现形式；
⑻ 环节：对应于业务流程中一个单一的业务操作，是流程按照业务要求的细化；
⑼ 环节实例：对应于一个环节的具体应用，是环节实例化的表现形式；
⑽ 工作流定义主信息：描述一个工作流模型的主要信息，从整体来描述工作流模型；
⑾ 工作流附件信息：描述一个工作流模型所用到的附件信息，也就是工作流应用资料，或者叫业务资料。按照WFMC提出的工作流模型，这不是工作流模型所包含的对象，可是我们对其进行格式化，把它抽取成一个模型对象，用来规定了工作流模型在具体应用时所需业务资料的格式，我们把它分为两类：
●
表格类型：这是以表格的形式保存附件信息，可以用关系结构来定义附件信息，并保存在数据库中，每一条记录就是一个该附件的实例；
●
文档类型：只是以文件形式保存附件信息，可以是work文档，也可以是文本文件，它的实例化是就是一个一个带有对应某个业务应用标志的文件，保存在硬盘上 ⑿ 工作流实例信息：描述一个工作流模型实例化的信息，也作为启动一个工作流的信息，它记录该业务流程随着时间和人员的参与处理的不断变化，直到整个业务的结束；
⒀ 工作项信息：描述参与某个业务应用时被分配到的一项任务，这就体现了参与人员和系统交互的典型特征；
⒁ 业务规则：描述业务在运行的过程中必须要遵守的规定和原则，也是业务活动得以向另一个活动推进的规则。我们把它分为四类规则，分别是： ●
自动型：它主要描述一些只给参与人员查看业务信息的业务规则，例如通知、公文流转等等业务。该类业务不需要参与人员去审批或其它人为上的处理，只需要参与人员去查看其中的内容就足够，整个业务流程的完成是全自动的。 ●
与聚合：业务活动的完成是需要参与该活动的所有人员都进行人为处理，其中有一个人员没对其进行处理，整个活动只能停在原地，等待所有人员的处理，当最后一个参与人员执行了处理工作，它才能完成。 ●
或聚合：在参与某一业务活动的人员当中只要有一个对其进行处理，整个活动就可以完成。
●
投票聚合：统计参与该活动的参与人员的处理结果，当满足一定条件该活动才能完成。
⒂ 转换条件：描述流程、活动状态改变时需要的条件，用于业务运行过程中的约束。例如流程的完成必须等待所有活动的完成才能完成，活动的完成必须按照业务规则去完成等等； ⒃ 需激活的应用程序：工作流管理系统需要其它应用程序的支持，例如编辑和查看文本文件信息等等；
⒄ 日志信息：描述工作流中所有的状态改变、事件和控制流相关资料的变化，工作流实例和环节实例的启动、结束、挂起和激活等等信息都会记录下来，以便对其进行管理。 3.1.2 对象之间的逻辑关系在找出工作流模型的对象后，我们就开始分析它们之间的业务逻辑关系。
3.1.2.1 对对象进行分类以及各个分类中对象之间的关系到此为止，我们有必要对工作流模型对象进行一下分类，根据工作流对象对工作流管理系统所起的作用我们可以分成以下几类： ⑴ 组织模型
组织模型描述了企事业的组织机构关系，包括的对象有用户，部门，职位，角色，工作组，它们的关系可以用下图表示：
设置
负责
组成
组成
资格
组成
部门
职位
用户
工作组
角色
图3.1 组织模型结构
从图中可以看到它们之间的关系，用户是基本的单位，部门是由用户组成，每个用户对应一个职位，负责该职位所要求的职能，用户凭着某种资格赋予一种角色，工作组也由用户组成，也可以由角色组成。这几个基本的对象以及其关系所构成的组织模型，已经可以满足轻量级工作流引擎对组织模型的需要了。 ⑵ 工作流定义模型
工作流定义模型描述了工作流模型的定义信息，包括工作流定义主信息，流程定义信息，环节定义信息，工作流附件信息，业务规则。它们之间的关系如下图：
图3.2 工作流定义模型结构
包含
包含
包含
包含
遵循
包含
工作流定义
附件信息
主信息
业务规则
环节
流程
包含
流程是包含若干环节的，而环节遵循一定的业务规则，再加上工作流主信息和附件信息，共同构成工作流定义模型。 ⑶ 工作流实例模型
工作流实例模型描述了工作流模型实例化时的信息，通过这些信息我们可以知道实例过程中的各种状态变化和最终的结果，因而得到一个业务具体应用的情况。它包括流程实例，环节实例，工作流实例信息，工作项信息和转换条件，它们之间的关系如下图：
记录
记录
细化
细化
影响
影响
影响
影响
记录
记录
转换条件
环节实例信息
流程实例信息
工作项信息
工作流实例信息
日志信息
日志信息
细化
图3.3 工作流实例模型结构
转换条件影响工作流实例，流程实例，环节实例和工作项的状态，并由转换条件去决定它们的状态转变，工作流实例信息à流程实例信息à环节实例信息à工作项信息，自上而下逐层细化，不但从全局了解业务运行情况，而且从局部了解业务运行的细节情况。而它们的状态改变都会记录在日志中，用以追踪工作流实例的运行情况。 ⑷ 外部支持模型
外部支持模型在本文只包括一个对象，就是需激活的外部应用程序，严格来说这不是工作流模型的一部分，可是提供接口去激活所需的外部应用程序为工作流管理系统提供支持是工作流模型的功能之一。有了这些外部应用程序的支持，我们的工作流管理系统的功能才变得更完善。
3.1.2.2 各个模型之间的逻辑关系
不但模型中各个对象有一定的逻辑关系，而且各个模型之间也有一定的逻辑关系，如下图所示：
调用
依赖
使用
使用角色和工作组
用户定义
工作流实例模型
外部支持模型
工作流定义模型
组织模型
图3.4 模型之间的关系
组织模型的用户定义工作流定义模型；工作流定义模型使用组织模型的角色和工作组，用来规定工作流模型的启动条件和任务分配条件，因为工作流模型的启动和任务的分配必须由一定的角色或工作组完成；工作流实例模型依赖工作流定义模型，同时使用组织模型的所有对象，并且调用外部支持模型为其提供支持。 3.1.3 工作流实例，流程实例，环节实例和工作项的状态转换
工作流实例，流程实例，环节实例和工作项从不同的层次去描述业务运行过程的具体情况，不同级别的用户可以看到业务运行的不同方面，创建工作流实例的用户可以看到工作流实例信息以及其状态转换，参与该工作流实例的用户可以看到工作项信息以及其状态的改变，系统管理员可以看到所有信息以及其状态的转换。
⑴ 工作流实例状态图
创建
管理员
管理员
管理员
Running （运行）
Completed （结束）
正常情况
Suspended (挂起)
terminated (终止)
Initial （初始化）
图3.5 工作流实例状态图
提交
⑵ 流程实例状态图
管理员
管理员
管理员
Running （运行）
Completed （结束）
正常情况
Suspended (挂起)
terminated (终止)
图3.6 流程实例状态图
⑶ 环节实例状态图
处理中
接受
完成
正常处理
没有完成
异常处理
回退处理
提交给下一环节
图3.5 环节实例状态图
⑷ 工作项状态转换图
等待操作
完成
通过
没有完成
不通过
无操作，超时
操作下一工作项
回退处理
已查看
初始化
未审批
未查看
图3.5 工作项状态图
接受
3.1.4 任务分派任务分派是工作流引擎的一个重要功能。当环节实例产生时，就会以一定的准则把需要处理的工作当作一项任务项（工作项）分派给参与该环节实例的所有用户，而这些用户是同属一个角色或者工作组的。我们又把角色和工作组进行细化，可以得到以下准则： ⑴ 基于部门的：这就是说把任务分派到某个部门的所有人员，该部门的所有人员都参与了该项任务，因而会为该部门的所有人员都产生一个工作项；
⑵ 基于职位的：这就是说把任务分派到某个职位的所有人员，同属该职位的所有人员都被分配到一项工作项；
⑶ 基于部门职位的：这就是说把任务分派到某个部门的某个职位的所有人员，同属该部门的该职位的人员都被分配到一项工作项；
⑷ 基于所有人的：这就是说把任务分派到该企事业的所有人，该企事业的所有人都被分配到一项工作项；
⑸ 基于工作组的：这就是说把任务分派到该企事业的某个特定的工作组上，同属该组的所有人员都被分配到一项工作项。
基于部门的，基于职位的，基于部门职位的和基于所有人的这四种类型，其实是基于角色的细化，通过这些准则的分类，我们尽量做到系统与企事业有较强的适应性，以及使系统在任务分派时有较大的灵活性。 3.1.5 转换条件的满足
工作流实例，流程实例，环节实例和工作项的状态转换有各自特定的条件，分别如下：
⑴ 工作流实例的转换条件
工作流实例从整体看业务运行过程，工作流实例被用户创建后就进行初始化并提交给工作流引擎，由工作流引擎去处理，此时实例处于运行状态；在运行过程中，它会根据流程实例的状态而不断进行本身的状态改变；当管理员由于某种原因要挂起它时，它就处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常结束；当它被正常处理完毕后，就正常结束。
⑵ 流程实例的转换条件
流程实例也从整体看业务的运行过程，流程实例在工作流实例初始化时就开始它的工作。在运行过程中，它会根据各个环节的完成程度来改变自己的状态，当所有环节实例都正常完成它就正常结束；管理员可能要挂起它使它处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常结束。
⑶ 环节实例的转换条件
环节实例从某个方面看业务的运行过程，环节实例在流程实例运行时就开始它的工作处于处理中状态。之后环节实例的状态由两方面决定，一是工作项的处理结果，一是业务规则的规定。
●
如果业务规则是自动型的，不管工作项的处理结果怎样，当系统把任务项分派（给特定用户）完毕后，该环节实例就正常完成处于正常结束状态；
●
如果业务规则是与聚合的，系统分派完任务项后，当所有参与人员都正常处理完该环节各自的工作项后，该环节才正常完成处于正常结束状态；在处理过程中，只要有一个工作项是非正常处理的，该环节就非正常完成处于非正常结束状态；在处理过程中，有工作项还未被处理并且没有一个工作项被非正常处理，那么环节实例仍然处于处理中状态；
●
如果业务规则是或聚合的，系统分派任务后，只要有一个工作项是正常处理的，该环节实例就正常完成处于正常结束状态；如果所有同属该环节实例的工作项都被非正常完成，那么该环节实例就处于非正常结束状态；
●
如果业务规则是投票聚合的，系统分派任务后，统计工作项的完成程度，当正常完成的工作项数量达到一定数量时，该环节实例就正常完成处于正常结束状态；当正常完成的工作项数量不达到规定的数量时，该环节就非正常完成处于非正常结束状态；当所有工作项还没处理并且正常完成的工作项还没达到规定数量时，该环节实例仍然处于处理中状态。
⑷ 工作项的转换条件
工作项从更细节的方面看业务运行过程，工作项的状态转换要看参与人员对各自的工作项的处理情况和业务规则的规定。我们把与聚合，或聚合和投票聚合这些要人工干预的规则统称为人工型规则。
●
如果业务规则是自动型，同属该规则的工作项的状态就只有正常处理后的正常结束状态，当然如果对该工作项还没被处理则处于处理中状态，可这不对环节实例等产生影响；
●
如果业务规则是人工型，就会有正常处理和非正常处理两种情况，正常处理该工作项则使到该工作项处于正常结束状态，非正常处理该工作项则使到该工作项处于非正常结束状态。
3.2 系统结构
本着基于轻量级工作流引擎的原则，我们已经对工作流模型进行了详细的分析和详细的设计，在这里我们就提出一个系统结构，如下图所示：
工作流定义器
工作流
解析器
实例调度中心
任务管理器
任务分派器
启动控制器
工作流定义数据
工作流实例 数据
日志 数据
工作流定义接口
工作流实例接口
组织定义
数据
组织定义接口
组织定义器
状态转换器
组织
管理器
图3.6 工作流引擎系统结构图
从图中可以知道，系统提供了三类接口：组织定义接口、工作流定义接口和工作流实例接口。这三类接口实现了工作流模型的接口一，接口二，接口三和接口五规定的主要功能；系统有一个实例调度中心，这是一个很重要的部件，它控制工作流实例的运行，通过工作流解析器对该工作流模型进行解析其含义，通过任务分派器按照一定的分派准则把任务项分派给参与该工作流实例的用户，通过任务管理器管理各个任务项的信息，通过启动控制器控制工作流的启动权利和启动信息，通过状态转换器控制工作流实例、流程实例、环节实例和工作项的状态转换；组织定义器定义企事业的组织结构；工作流定义器定义工作流模型信息，并通过组织管理器得到组织定义信息，为工作流模型提供组织支持。各个部件处理的相关信息都保存在数据库中。
3.3 系统模块的划分
根据功能实现的不同我们进行模块的划分如下：
⑴ 用户管理模块：对用户信息的管理，包括注册用户信息，注销用户信息，查询用户信息等功能；
⑵ 部门管理模块：对企事业部门结构信息的管理，包括增加部门信息，删除部门信息，查询部门信息等等功能；
⑶ 职位管理模块：对企事业职能信息的管理，包括增加职位信息，删除职位信息，查询职位信息等等功能；
⑷ 角色管理模块：对企事业某种技能信息的管理，包括新增角色信息，删除角色信息，查询角色信息等等功能；-
⑸ 工作流模型管理模块：对工作流定义模型信息的管理，包括定义新的工作流模型信息，删除旧的工作流模型信息，查询工作流模型信息；
⑹ 工作流实例管理模块：对工作流实例信息的管理，包括启动一个新的工作流实例，查询工作流实例信息，按照一定的业务规则生成新的环节实例信息，为用户分派工作项，管理工作项信息，按照一定的转换条件为工作流实例、环节实例转换状态等等功能；
⑺ 系统监控模块：为工作流实例，环节实例等的状态转换信息加入日志，挂起、激活工作流实例，强制结束工作流实例，为迟迟不对自己的工作项进行处理的用户发出提醒或警告信息，查看各个工作流实例的完成程度等等功能。
功能模块的划分，为系统的实现做好充分的准备。
3.4 数据库设计
基于轻量级的工作流引擎的特点之一就是把系统相关的资料，如工作流模型定义信息，工作流实例信息，组织模型定义信息等等，都以特定的实体形式保存在关系型数据库中。
⑴ 工作流定义主信息表（workflowTable）
静态定义工作流主要信息，包括该工作流的标识ID（可以定义为以”WORKFLOW_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作流名称，工作流描述，工作流类型（工作流的类型有自动型，人工型和混合型，自动型不需要人工参与，由工组流引擎自动执行，人工型需要人工参与，混合型包含了自动型和人工型），工作流创建日期，工作流创建者ID（即用户ID），工作流创建人名称（即用户名），工作流生命周期（每个工作流实例都有它的生命周期期限，在该期限内还没完成它的工作就直接死亡），目前该工作流实例数目（记录当前工作流实例数目），工作流启动者角色（指明该工作流可以由哪个角色发起，属于该角色的用户都可以启动该工作流模型对应的实例）。工作流重要信息还包括两方面，一是工作流附件，因为在工作流进行过程中，肯定会带有一些信息，这些信息对于出差申请来说就是出差申请表，对于公文流转来说就是以word文档形式的公文，对于通知来说可能就是以文本文档形式的通知书，等等；一是工作流流程描述，包括若干个环节（activity），这些环节有一定的顺序，表现工作流顺序执行的特征。把工作流附件和工作流流程描述从工作流定义分离出来，是基于工作流附件和工作流流程描述对于不同工作流有不同形式和数量的原因，有利于工作流附件和工作流流程描述的扩展。 ⑵ 工作流附件信息表（workflowAttachmentTable）
静态定义工作流所需要的附件，包括附件ID（可以定义为以”Attachment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作流ID（标识属于哪个工作流），附件类型（表或文件），附件名称（如果类型是表，则为该表的名称，如果是word文档，则为该文档名称，如果是文本文档，则为该文件名称），其它信息（如果类型为表格，该字段以一定的格式保存该附件表格的所有字段的各种信息，包括字段名称，字段数据类型，数据类型长度，字段描述）。 ⑶ 工作流流程描述表（workflowProceTable）
静态定义工作流的流程，由若干环节（activity）组成，一个环节为一条记录，包括工作流ID（环节所属工作流ID），环节ID（可以定义为以”ACTIVITY_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），环节名称（即该环节名称），环节描述（对该环节的具体描述），参与者角色ID（将相同权限的用户作为一个集合，在数据库以同一个角色操作数据库特定操作，该项标识角色ID），环节任务分派规则，上一个环节ID（保存上一个环节的ID，由这项可以判断该环节是否整个流程的开始环节，或者该环节的任务没有完成（审批不通过，或没在其生命周期期限内完成）时作回滚处理的重要数据项，根据这个数据项可以回滚到上一个环节），下一个环节ID（保存下一环节的ID，由这项可以判断该环节是否整个流程的结束环节，或者该环节的任务完成了，根据这个数据项可以启动下一环节，继续向前推进）。
⑷ 工作流实例启动描述（workflowInstanceStartUpTable） 动态定义工作流实例启动信息（其实这也是工作流实例信息表）启动者在产生一个工作流实例之前必须根据工作流的定义做好准备工作，这些准备工作的信息就填入该表中，然后交付给工作流引擎。该描述包括工作流ID（所属工作流ID），工组流实例ID（标识该工作流实例，可以定义为以”WORKFLOWINSTANCE_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作流实例描述，工作流实例创建时间，工作流实例创建者ID（启动者ID），工作流实例创建者名称，当前工作流状态（标识当前工作流实例的状态，启动者在创建后却没提交给工作流引擎前的状态为“initialized”初始化状态，之后的状态要视工作流类型而定），当前状态具体描述，当前操作者ID（当前工作流要被谁操作），当前操作者名称。工作流实例完成标志（标识该工作流实例的完成），工作流实例完成时间，当前工作流状态和当前操作者ID和当前工作流状态具体描述三项在工作流实例的运行过程中，可以动态追踪该工作流实例的运行，而这三项再加上工作流完成标志和工作流完成时间，可以知道该工作流实例的完成情况。
⑸ 工作流实例过程描述（workflowInstanceProceingTable） 以环节为单位动态描述工作流实例的处理过程，启动者创建工作流实例后，提交给工作流引擎后，工作流实例就根据工作流定义的流程进行运转了。包括工作流实例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是自动生成的序号），部门名称，部门其它信息。
⑾ 职位信息（PositionTable）
描述职位的信息，包括职位ID（可以定义为以” Position_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），职位名称，职位其它信息。
除了以上这些主要表以外，还有一些我们是在定义工作流模型的时候才加入数据库的，如对应工作流附件类型为表的表格。为了减少网络流量和提高系统的运行速度，我们把一些有关联的数据库操作写成存储过程：
⑴ 删除工作流模型存储过程：删除一个工作流模型，必须删除它的工作流定义主信息，同时删除对应的附件信息，附件为表的表格，环节信息；
⑵ 创建附件类型为表的表格：定义附件信息时已经把该表格的字段信息保存在该附件信息的其它信息字段中，并且有一定的格式，那么我们从该字段中按照一定的格式还原表格的字段信息，并根据这些信息在数据库中创建该表格。
3.5 类的设计
用面向对象的方法和UML建模工具，再根据系统结构图，模块的划分和数据库的设计，我们把对象转化成类，进行类的设计。我们把整个系统的类分成三部分，一是实体类，二是业务类，三是接口类。
3.5.1 实体类的设计
工作流模型的对象就是一个一个的实体，实体类又分为数据库访问类和值对象类。数据库访问类是对存储在数据库的实体信息进行访问（插入，删除，更新，查询）的类，值对象类是在客户端和服务器端之间交换资料的实体信息类。
3.5.1.1 数据库访问类
⑴ 数据库连接类：该类是其它数据库访问类的父类，管理数据库的连接，负责从数据库连接池找可用的数据库连接给其它数据库访问类使用，使用完毕后负责放回连接池，类图如下图：
说明：属性只有一个connection，它代表数据库的一条连接，类型为Connection，方法有一个构造函数workflowDAO()和一个关闭连接的函数closeConnection()。WorkflowDAO()实现从数据库连接池找一个可用连接并赋值给属性connection，closeConnection()负责把连接放回数据库连接池。
⑵ 工作流定义主信息访问类：对应数据库的工作流定义主信息表，该类封装了对该表格记录的各种操作，就是插入或删除一条工作流定义主信息，查询特定工作流定义信息或者所有工作流定义信息，类图如下图：
说明：构造函数WFDefineMainInfoDAO()调用父类构造函数，从数据库连接池中找一个可用的数据库连接（其它数据库访问类也一样）。
⑶ 工作流流程信息访问类：对应工作流流程描述表，该类封装了对该表格记录的各种操作，流程是由若干环节组成，就是插入或删除一条环节信息，查询同属于一个流程的环节信息等等，类图如下图：
说明：findWorkflowFirlstActivityInfo()函数负责找该工作流模型的第一个环节的信息，findWorkflowNextActivityID()负责根据当前环节ID找下一环节的信息。
⑷ 工作流附件信息访问类：对应工作流附件信息表，该类封装了对该表格记录的各种操作，就是插入或删除一条工作流附件信息，查询同属于一个工作流模型的附件信息。类图如下：
⑸ 工作流附件类型为表的信息访问类：对应工作流附件类型为表格的信息表，该类封装了该表记录的各种操作，就是插入或查询一条工作流附件类型为表格的具体信息，类图如下：
⑹ 工作流实例启动信息访问类：对应工作流实例启动信息表，该类封装了该表记录的各种操作，就是插入或查询一条工作流启动信息，查询同属于一个用户的工作流实例启动信息，更新部分字段信息，类图如下：
说明：selectFinishedWorkflowInstanceStartUpInfoVO()负责查询特定用户启动的并且已经完成的工作流信息，selectNotFinishedWorkflowInstanceStartUpInfoVO()负责查询特定用户启动的并且还没有完成的工作流信息，updateWFInstFinishedFields()负责在工作流实例结束时更新特定的字段信息，updateWFInstProceingFields()负责在工作流实例运行工程中更新特定的字段信息。
⑺ 工作流实例过程信息访问类：对应工作流实例过程信息表，该类封装了该表格记录的各种操作，每一条记录实际上是一个环节实例，就是插入、删除或查询一条环节实例信息，查询指定工作流实例的所有环节信息，更新部分信息字段，类图如下：
说明：SetWFInstProceingCurrentPerformerNumField()负责更新已经处理该环节实例对应的工作项的参与该环节实例的用户数目，updateWFInstProceingFields()负责在环节实例处理过程中更新特定的字段信息。
⑻ 工作项信息访问表：对应工作项表，该类封装了该表格记录的各种操作，就是插入或删除一条工作项信息，查询工作项信息，更新工作项信息，类图如下：
说明：selectFinishedWorkItemVO()负责查询特定用户已经处理完毕的工作项信息，selectNotYetFinishedWorkItemVO()负责查询还没有处理的工作项信息，updateWorkItemFields()负责更新工作项在处理过程中的特定字段信息，isPerformedInWorkItemByUser()负责判断该工作项是否已经处理完毕。
⑼ 用户信息访问表：对应用户信息表，该类封装了该表格记录的各种操作，就是插入、删除或查询一条用户信息，查询特定角色对应的用户信息，类图如下：
说明：selectCountRS()负责统计同属于一个角色的用户数目。
⑽ 角色信息访问类：对应角色信息表，该类封装了该表记录的各种操作，就是插入、删除或查询一条角色信息，查询所有角色信息，类图如下：
⑾ 部门信息访问类：对应部门信息表，该类封装了该表记录的各种操作，就是插入、删除或查询一条部门信息，查询所有部门信息，类图如下：
⑿ 职位信息访问类：对应职位信息表，该类封装了该表记录的各种操作，就是插入、删除或查询一条职位信息，查询所有职位信息，类图如下：
⒀ 日志信息访问类：对应日志信息表，该类封装了该表记录的各种操作，就是插入、删除一条日志信息，查询特定的日志信息，类图如下：
3.5.1.2 值对象类
值对象类其实是一种数据结构，用于客户机和服务器之间的数据交换，也用于对象实例的数据传递，它有若干属性，可是很少方法，实例化后就对应数据库表的一条记录。
⑴ 工作流定义主信息值对象类：可以保存工作流主信息表的一条记录信息，类图如下：
⑵ 工作流流程信息值对象类：可以保存工作流流程信息表的一条记录信息，类图如下：
⑶ 工作流附件信息值对象类：可以保存工作流附件信息表的一条记录信息，类图如下：
说明：SetOtherInfo()负责以一定格式把工作流附件类型为表的表格字段信息保存在OtherInfo中，GetOtherInfo()负责从OtherInfo中以一定的格式还原工作流附件为表的表格字段信息。
⑷ 工作流附件类型为表的信息值对象类：可以保存工作流附件类型为表的信息表的一条记录信息，类图如下：
说明：tableName就是工作流附件类型为表的表格名称，fieldValue就是对应该表的一条记录的各个字段值，用可变长数组Vector保存下来。
⑸ 工作流实例启动信息值对象类：可以保存工作流实例启动信息表的一条记录信息，类图如下：
⑹ 工作流实例过程信息值对象类：可以保存工作流实例过程信息表的一条记录信息，类图如下：
⑺ 工作项信息值对象类：可以保存工作项信息表的一条记录信息，类图如下：
⑻ 用户信息值对象类：可以保存用户信息表的一条记录信息，类图如下：
⑼ 角色信息值对象类：可以保存角色信息表的一条记录信息，类图如下：
⑽ 部门信息值对象类：可以保存部门信息表的一条记录信息，类图如下：
⑾ 职位信息值对象类：可以保存职位信息表的一条记录信息，类图如下：
⑿ 日志信息值对象类：可以保存日志信息表的一条记录信息，类图如下：
⒀ 信息集合值对象类：可以保存各种信息的一个集合，当需要返回多条记录信息的时候可以使用该类，类图如下：
说明：只有一个属性，是一个可变长数组，可以存放不定数量的记录信息。 3.5.2 业务类的设计
业务类，其实就是边界类，它根据系统的需求按照一定的方式把各个实体类联系起来，以实现系统的各种功能。按照实现功能的不同我们可以分为用户管理类，角色管理类，部门管理类，职位管理类，工作流模型管理类，工作流实例管理类，系统监控管理类。
⑴ 用户管理类：负责用户的注册，注销，检测合法性，查找用户信息，类图如下：
⑵ 角色管理类：负责新增加角色，删除角色，查找角色信息，类图如下：
⑶ 部门管理类：负责新增加部门，删除部门，查找部门信息，类图如下：
⑷ 职位管理类：负责新增加职位，删除职位，查找部门信息，类图如下：
⑸ 工作流模型管理类：负责工作流模型的定义，解析，类图如下：
⑹ 工作流实例管理类：负责工作流实例的创建，维护各种实例的状态信息，分派任务给用户，用户处理工作项等等的工作，类图如下：
说明：uploadAttachmentToServer()负责把工作流附件类型为文档的文档上传到服务器特定目录下。
⑺系统监控管理类：是一个综合类，主要通过调用其它管理类的功能来实现本身的功能，就是查看工作流实例的过程状态，完成程度，根据一定的条件有必要控制实例的挂起，激活，结束，查看各个参与用户的工作情况，在出现工作误时、意外、异常等等情况时采取一定的措施保证整个实例的完成。而所有这些都保存在日志中。
3.5.3 接口类的设计
接口类是工作流引擎提供给外部应用的类，应用系统通过调用这些类，来实现一定的应用功能。我们在接口类的设计上，采取格式统
一、隐藏系统复杂性、功能调用方便的原则，尽量为外部应用系统提供简洁、易懂的功能调用接口。因而我们把这些类都设计成只有一个业务类实例，一个ToDoWhat()方法的类，并且每一个业务类对应一个接口类。在这些接口类中，业务类实例作为它的一个数据成员，ToDoWhat()方法有两个参数，toDoCode（工作代码）和object（数据交换对象），工作代码表示要调用的功能的标识，数据交换对象表示功能调用要处理的数据（应用数据）。从本质上来说，就是根据不同的工作代码调用业务类实例的不同方法，对各种应用数据进行处理。
第四章
系统实现系统的实现主要包括关键问题的解决方案和一个工作流管理应用系统的实践。首先提出关键问题，然后给出解决方案，最后提出一个应用架构，利用J2EE技术和数据库技术实现一个基于轻量级工作流引擎的简单工作流管理应用系统。
4.1 关键问题的解决方案
在实现工作流引擎的时候，有一些关键问题，例如启动工作流实例，推动工作流实例的进程，类型为文档的附件的处理等等，都是要重点解决的。 4.1.1 启动工作流实例
当根据各种业务需求创建了对应的工作流模型，根据结构组织情况创建了组织模型后，用户就可以创建工作流实例并启动它。用户把工作流实例的信息提交给工作流引擎，那么工作流引擎如何工作呢？工作流引擎其实做了一系列的工作，其处理过程如下：
⑴ 工作流引擎得到用户创建的工作流实例数据，记录在工作流实例启动信息表中；
⑵ 工作流引擎解析对应该工作流实例的工作流模型的含义，获得必要信息提供给工作流实例使用；
⑶ 工作流引擎根据这些必要信息找到工作流模型对应流程的第一个环节信息，并生成该工作流实例的第一个环节实例，记录在工作流实例过程描述表中；
⑷ 工作流引擎根据任务分派原则开始把任务项分派给参与该环节实例的所有用户；
⑸ 工作流引擎根据该环节定义的参与者角色，找出所有同属于该角色的所有用户，为各个用户都生成一个工作项，记录在工作项信息表中，工作项要继承该环节定义的业务规则，完成任务的分派；
⑹ 工作流引擎根据该环节定义的业务规则，如果该环节是自动型的，则为该环节的参与用户分派完任务后立刻就根据该环节信息去找下一个环节的信息，进行下一环节实例的处理；如果该环节不是自动型的，是需要人工参与处理的，则工作流引擎暂停该工作流实例的处理工作，等待参与用户处理的结果；
⑺ 启动工作流实例的工作结束。
4.1.2 推进工作流实例的进程
⑴ 如果上一环节定义的业务规则是自动型的，则立刻根据当前环节信息查找下一环节；
⑵ 如果上一环节定义的业务规则是不是自动型的，则等待参与用户对各自的工作项进行处理，当每一个用户处理完后，工作流引擎都要判断该环节实例是否结束，结束的条件是业务规则的规定和用户的处理结果。
①
如果业务规则是与聚合，当当前用户的处理结果是非正常处理的话，该环节实例就结束，并且该工作流实例也结束，通知其他还没处理的用户该环节已经结束，并记录在相应的数据库表中；当当前用户的处理结果是正常处理的话，则再判断是否所有参与的用户都处理完毕，如果是则结束该环节，通知其他用户该环节已经结束，并记录在相应的数据库表中，然后查找下一环节，如果不是则等待其他还没处理的用户的处理结果。
②
如果业务规则是或聚合，当当前用户的处理结果是正常处理的话，该环节的实例就结束，并且该工作流实例也结束，通知其他参与还没处理的用户该环节实例已经结束，记录在相应的数据库表中，然后查找下一环节；当当前用户的处理结果是非正常的话，则等待其他还没处理的用户的处理结果。
③
如果业务规则是投票聚合，当当前用的处理结果是正常处理的话，则使统计正常处理结果的计数器加一，然后判断该统计数量是否已经达到规定的数量，如果是则结束该环节实例，并通知其他还没处理的用户该环节实例已经结束，记录在数据库表中，然后查找下一环节；当当前用的处理结果是非正常处理的话，则不统计，等待其他还没处理的用户的处理结果。
⑶ 当前环节实例结束后，工作流引擎就找下一环节处理，如果没有下一环节，则结束该工作流实例，记录在数据库表中，如果还有环节，则同样生成环节实例，进行任务分派，等待环节实例的结束。工作流引擎就是这样推进工作流实例进程，从一个实例环节到下一个实例环节，直到工作流实例结束为止。
4.1.3 类型为文档的附件的处理
对于文档形式的附件，我们采用上传文件到服务器的方法，用户编辑好文档后，以规定的文件名上传到服务器中特定的目录中，当用户要查看该文档时，工作流引擎会根据该附件文档对应的信息得到其文件名，用户根据该文件名下载到本地中，同时调用外部应用程序如work2000、记事本打开给用户浏览其内容。
4.2 一个简单工作流管理系统的实现
现在，我们利用J2EE技术把工作流引擎开发出来，并基于该引擎做一个简单的应用系统，以证明系统设计的可行性。我们用Jbuilder9.0做开发工具，用MS SQLSERVER2000做数据库管理系统。 4.2.1 系统应用框架
工作流实例管理器
工作流模型管理器
组织管理器
系统监控器
工作流引擎
应用服务器
数据库
Web界面
文档管理系统
图4.1 系统应用框架
4.2.2 J2EE相关技术的应用
J2EE为多层Web应用系统提供了容器平台，用J2EE技术把工作流管理系统开发成一个多层Web应用系统，是最合适不过了。
4.2.2.1 J2EE核心模式和类的实现
模式是特定问题的可重现的解决方案，使用模式有莫大的好处。模式可以权衡已经被证实的解决方案，为交流提供一个共同的词汇，约束解决方案的范围。J2EE核心模式是在J2EE平台上应用的模式，它在表示层，业务层，集成层都有特定的模式，为基于J2EE平台的开发提供很好的解决方案。对类的实现我们采用了J2EE核心模式，主要运用的核心模式是业务层的ValueObject（值对象）和集成层的DAO（DataAcceObject，数据访问对象）。
⑴ 值对象：基于多层应用架构的系统，客户端和服务器端往往有大量的数据交换，而且客户端调用的方法都是远程的，不是本地的，为了减轻网络负载，提高应用程序的性能，用值对象封装业务数据，在客户端和服务器端进行数据交换。因而我们把所有工作流对象都用值对象表示，像工作流定义主信息值对象类（WFDefineMainInfo）。在这些值对象中，所有属性和方法都是声明为公共的，并且很少方法，很多属性，这些属性就是对应的工作流对象的属性，也对应了数据库中表的某个字段。
⑵ 数据访问对象：基于关系数据库技术的系统，会对数据库进行频繁的访问，数据库表的众多，对某个表操作的方式的众多，如果不对这些表和表的操作方式进行必要的归类，只会造成模块聚合度的降低，代码混乱的后果。我们使用数据访问对象，来抽象和封装对数据库的访问，所有涉及到数据库访问的情况都使用数据访问对象去实现。工作流对象的所有数据都保存在数据库中，我们为每个对象数据的数据库操作都封装在数据访问对象中，像工作流定义主信息访问类（WFDefineMainInfoDAO）。 4.2.2.2 JavaBean技术与类的实现
JavaBean是基于Java技术的软件构件模型，它是Java语言编写的可移植的不依赖于平台的软件构件模块。我们把系统所有的类都实现为一个一个的JavaBean，提高类的可重用性，有利于日后的功能扩展。另外，JavaBean应用到JSP中，可以为JSP应用带来更好的可伸缩性。
4.2.2.3 JBOSS应用服务器和工作流引擎的实现
应用服务器我们采用JBOSS，这是一个免费的产品，它提供数据库访问（JDBC）、命名机制（JNDI）服务等服务，支持数据库连接池、实例连接池，这些为我们的工作流引擎的实现提供了支持，给系统开发带来很大的方便。
⑴ 对数据库访问的支持：JBOSS通过对特定数据库管理系统的配置（XML文件），并实例化对数据库的若干连接，放进数据库连接池中，提供给系统使用。在JBOSS运行过程中，对这些数据库进行有效的管理，减轻了工作流引擎的工作负担。 ①
配置方法 mql-ds.xml文件：
MSSQLDS/* 数据源名字 */
jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=WorkflowDB /* 连接URL，包括服务器
地址，数据库名称 */
com.microsoft.jdbc.sqlserver.SQLServerDriver /* sqlserver驱动 */
workflowUser /* 用户名称 */
123456 /* 用户密码 */
②
调用方法（使用JNDI机制） 部分代码：
InitialContext ctx = new InitialContext(); //初始化上下文
DataSource ds = (DataSource) ctx.lookup(\"java:/MSSQLDS\");
//根据数据源名字查找已经配置好的数据源
Connection conn = ds.getConnection();
//调用该方法可以得到对数据库的一条连接，而这条连接已经被JBOSS初始化，实际上是从数据库连接池中找到一条可用的连接而已，然后通过该连接就可以对数据库进行各种操作，操作完毕后不用显式关闭，JBOSS会自动回收该连接，把该连接重新放入连接池中。
⑵ 对对象实例化的支持
当系统第一次生成某个对象实例时，JBOSS就对该实例进行管理，把该实例放入实例池中，并不释放它，当系统再次要生成该实例时，不再进行该对象的实例化，而是JBOSS从实例池中找到该实例并提供给系统使用，这明显提高系统运行速度。
⑶ 对线程的支持
当不同的用户登陆系统，并且对系统所有功能的使用，JBOSS会为每个用户分配一个线程去为他们工作，这些线程放入线程池中，JBOSS在运行过程中始终对这个线程池进行管理，提高系统的并发性能。
4.2.2.4 Jsp/Servlet技术和系统界面的实现
JSP技术可以方便的建立动态Web页面，提供一个友好的用户界面，并且很方便的调用JavaBean，完成复杂的业务功能；Servlet提供在Web进行请求和响应服务的功能，客户端对服务器提供的服务的所有请求和响应都通过Servlet实现。JSP最终解析为Servlet。
⑴ JSP调用JavaBean
下面是创建工作流定义主信息的JSP页面部分代码：
cla=\"wfsystem.interfacepack.client.workflowManager\" />
„
<%
WFDefineMainInfo wfDefinemaininfo =new WFDefineMainInfo();
„ // 填充工作流定义主信息值对象WFDefineMainInfo 实例
wfManager.ToDoWhat(0,(Object) wfDefinemaininfo);//调用接口类的方法，0对应创建工作流主信息的方法代码
%>
⑵ Servlet请求和响应服务 下面是请求得到表单信息（这些信息就是工作流定义主信息值对象的内容）部分代码：
<%
String workflowname = request.getParameter(\"workflowname\");
String workflowDesc = request.getParameter(\"workflowDesc\");
//request就是请求对象，调用其方法getParameter()可以得到表单的信息
„ //一个一个的得到信息
%>
下面是响应用户的部分代码：
<%
response.sendRedirect(\"defineWorkflowModel-mainInfo.jsp\"); // response就是响应对象，
调用其方法sendRedirect()向用户发送一个页面重定向的应答。
%>
4.2.3 具体编码实现
接下来的工作就是编码工作，以Jbulider9.0作为开发工具，以VSS（Microsoft Visual SourceSafe6.0）作为版本控制工具，进行代码编写，进行单元测试，综合测试，最后得到一个基于轻量级工作流引擎的简单的工作流管理系统。
第五章
系统的不足
本文探讨的轻量级工作流引擎，尽管有很多的优点，可是它从够用、灵活和低成本的设计原则出发，不追求工作流引擎的功能的完备和复杂，所以存在着一些不足：
⑴ 不支持复杂业务：本文探讨的轻量级工作流引擎是从一般业务的需求设计工作流模型，我们只实现了活动的单分支，就是组成工作流流程的活动是一个活动只有一个后续活动，而复杂业务可能一个活动后面出现多分支，有多个后续活动，形成一个树型的结构。所以对复杂业务的不支持是本文探讨的工作流引擎的最大的不足。
⑵ 不支持复杂的组织结构：本文探讨的工作流引擎只是以职能型的机构模型去描述组织结构，主要以部门和职位组成一个角色，任务分配也只是按照部门和职位的不同组合去分配，可是复杂的组织结构模型可以定义多重角色，临时工作组等等。
⑶ 不支持提供内建（built-in）的应用开发工具，例如是可视化工作流建模工具，FORM设计工具，这些在本文探讨的工作流引擎都没有实现一定的接口。
⑷ 在定义应用数据方面不支持所有数据类型和完整性维护，只支持字符型类型和进行一些简单的数据保存工作。
⑸ 没有完善的异常处理功能。对异常的捕捉和处理并不完善，没能及时把错误信息显示给用户。
⑹ 没有完善的事务控制功能。只实现了一些简单的事务控制，没有对复杂事务的控制。
第六章
总
结本文主要探讨了轻量级工作流引擎的设计与实现，首先我们要了解有关工作流技术的相关知识，然后说明开发轻量级工作流引擎的原因，再从企事业一般业务需求入手，抽象出工作流对象，分析其之间的逻辑关系，组成工作流模型，跟着提出一个系统结构，进行模块划分，数据库设计，类的设计，最后利用J2EE技术，用MS SQLSERVER2000作后台数据库，Jbuilder9.0作开发工具，VSS作版本控制，实现工作流引擎的开发，并基于该工作流引擎作一个简单的应用系统，最终实现为一个工作流管理系统。该管理系统的正常运行，充分体现了轻量级工作流引擎在企事业业务的开发过程中的价值。 参考文献[1] 范玉顺著，《工作流管理技术基础》，清华大学出版社 [2] Deepak Alus等著，《J2EE核心模式》，机械工业出版社 [3] 王克红等著，《Java技术教程（中级篇）》，清华大学出版社
[4] Wendy Boggs等著，《UML With Rational Rose从入门到精通》，电子工业出版社
[5] Borland公司著，《Borland Jbuilder实用技术手册》，电子工业出版社 [6] 何清法等著，《基于关系结构的轻量级工作流引擎》，中国科学院计算技术研究所 [7] Joseph L.Weber著，《Java 2 编程详解》，电子工业出版社
本文来自CSDN博客，转载请
标
明
出
处http://blog.csdn.net/hjt79/archive/2004/08/15/75484.aspx
：
