目标： jBPM-side ProcessDesigner是一个独立的设计器，基于 Flex技术。其目的在于既使得程序开发人员能够基于其进行业务流程的建模，同时业务人员也能够基于其进行简单的建模和修改，例如修改节点的顺序、参与者等操作。此外， jBPM-side ProcessDesigner具有很高的可配置性，在流程定义 scheme变化的情况下，能够很快的做出适配。即其与具体的流程定义语言无关，可以对 jPDL、 XPDL、 BPEL都进行建模。 jBPM-side ProcessDesigner的数据核心是 xml。

功能规划：

一、 图形建模

支持流程模型与图形元素的一一对应，支持通过图形元素来进行流程的建模。流程模型与图形元素之间通过 xml进行互相转换。图形建模方面，支持图形元素的拖拽、定位、复制、粘贴，支持快捷键操作，例如 do/undo、 delete。

二、 流程参与者的适配导入

支持在进行流程建模时，适配导入流程参与者。在进行人工参与节点定义时，选择参与者。进行人员 /部门 /角色的本地建模，提供最简单的必需属性。

三、 图形展现与 xml编辑的互相切换

支持流程图形与 xml编辑的切换，支持 xml定义的本地导入和导出。

四、 流程的分包与版本管理

支持流程定义的分包和版本管理，需要服务器端的支持。

五、 与服务器端的远程调用

在支持服务器端的远程调用之前， jBPM-side ProcessDesigner仅仅是本地 xml的导入导出建模。采用 restful-ws，基于 xml在服务器与设计器之间传递数据。

六、 与业务适配的 DSL

七、 流程的权限管理

支持对流程定义的分类权限管理，不同业务部门对属于自己的流程定义有各自的管理权限。此功能独立与 jBPM-side ProcessDesigner，但是需要通过契约使得 jBPM-side ProcessDesigner对流程定义的展现进行过滤。

在拥挤的公交车上读完《工作流管理(模型、方法和系统)》，自从搬完家，上班的路途突然变得遥远。

这本书确实是按照它的副标题组织的，分别介绍工作流的建模模型、应用工作流开发的方法以及部分商业的工作流产品。
对petri网的介绍是这本书的重点，如果想对petri网有个大概的了解而又不愿意接触深奥的数学，那么可以一读。本书随后分析了如何对流程模型进行分 析，包括对建模正确性与否的定量分析以及对资源运行效率的定性分析。至于介绍的工作流产品，因为年代久远，可读性不高。应用工作流开发的方法就更是理论 了，不过作为一本2000年的书，里面提到的一些原则还是很有敏捷的意思，例如和客户在一起、迭代开发、交流的重要性等等。

读完这本书，加上先前的范玉顺的书，突然就明白为什么BPEL会如此之流行，原因在于它们都非常强调BPR的概念，即业务流程重组。也就是从一开始，工作 流系统就是瞄准BPR这个目标来的，想利用工作流系统将整个企业的业务流程都管理起来。目标如此远大，整合自然是不能避免，整合包括了对人员的整合，也包 括了对IT系统的集成。如此以来，恍然大悟：BPEL这种强调服务集成的执行语言无怪乎会大红大紫了。至于说国内最普遍的工作流应用：将工作流引擎嵌入应 用系统中，分离流程逻辑与业务逻辑，则自然登不了大雅之堂了。一句话说，就是国内应用工作流的层次太低。或者反过来也可以理解：现在的所谓BPM软件都眼 高手低，不太适合国内的应用。

可是问题依旧存在，即BPEL根本上说是一种执行语言，要业务人员理解简直是强人所难，所以BPMN应运而生。好吧，BPMN有了，自然BPMN到 BPEL的映射就出现了，可惜这终究是一厢情愿，一种是业务建模语言，一种是计算机执行语言，中间的代沟比70、80还宽。就像科比，篮筐在他眼里比大海 还广阔。

此外，BPEL的应用还存在一个天然的障碍，即应用集成从来都不是一件轻松的事情。将接口用web service包装一下就SOA了？就面向服务了？这鬼话你也信，那可真是你服务，你全家才服务呢。应用集成不轻松，所谓的企业敏捷性：能够根据外部环境 的变化迅速调整服务编排流程那自然是镜中月，水中花了。君不见，无数程序员们在开口大骂：靠，流程又要调整，早吃屎了？！

所以结论有三:
1、国内的嵌入式工作流应用还是什么适用就用什么吧，和XPDL\BPEL都无关；
2、一心要SOA、要BPEL。那别指望它能减少工作量，也别指望流程能够迅速修改；
3、要对企业流程进行敏捷管理，那就考虑文档化，别考虑执行。

       大概花了三天的时间读完这本书，书本身也不厚，读起来很快。这本书出版于2001年，所以对它也没有抱有很大的期望，但是还不错，特别是前三章，很有些惊喜。后面关于工作流仿真的描述也很到位。但是关于技术实现，则大都略过了。

        总结一下里面个人觉得不错的部分。

        第一章很不错，强调为什么需要工作流管理系统。

        企业经营环境的变化：过去企业市场竞争主要围绕着如何提高生产率进行，现在则是围绕新产品的竞争而展开。新产品的价格总是高于其价值，通过竞争，价格才逐渐接近价值，产品失去独占期，同时也意味着产品生命周期的结束。与产品生命周期缩短所对应的，是客户定制产品数量的增加。

        在这种情况下，传统串行的产品研制会延长产品的上市时间，同时串行过程也是在企业以功能为核心划分组织机构下的必然产物。

        敏捷制造提出的背景：用户需求多样化、个性化，所有企业都将处于一种连续改变、不可预见的市场环境中，此时问题的核心在于是否抓住机遇、快速响应市场、开发新产品。敏捷制造的基本思想是，企业能够对持续变化、不可预测的市场需求做出快速反应，强调面向市场的敏捷性。实现敏捷制造的关键是对企业进行敏捷化改造和重组。其中企业组织结构发生重大的变化，传统的企业组织结构是功能部门制，即按照不同的功能和职能设立不同的部门，上下级之间形成一个树型的结构。这种结构的缺点在于：每个单元都由上一级的功能单元进行管理，出现问题时，每一级都会把责任推到上一级，这样会造成部门职责不清。柔性底，一个生产流程往往跨越多个部门，部门之间的协调成本很高，扯皮。需要建立起面向流程的组织机构，按照企业要实现的主要业务流程来配置组织机构，以项目来组织人员，减少内部不必要的沟通协调成本，提高对市场的响应速度。

        由此，需要工作流系统来对企业的流程进行分析和梳理。然后围绕这些流程来进行企业的业务重组和改造。

        第二章的亮点在于如何实施工作流系统。

        工作流的实施不同于普通的业务处理系统，它首先需要在战略层次上对企业的业务目标进行分析，确定企业的战略目标和组织要求，然后再进入到具体的实施阶段，分为三个阶段：模型建立阶段、模型实例化阶段和模型执行阶段。实施工作流的目的在于提高企业的柔性，能够根据市场的变化不断改进其业务流程。其中作者强调了工作流的两个重要职责：集成和仿真。工作流系统本身是一个完成流程建模和流程管理的软件系统，但是为了在企业的实际业务中得到有效的应用，它必须和企业已有的或购买的其他业务系统实现集成，通过集成来提高整个企业 的应用水平和应用效率。

        第三章分析工作流系统的组成以及WFMC定义的五个接口。很清晰。

        第四章到第八章描述具体商业产品的大概技术实现、XPDL规范和分布式的工作流，由于现在已经是B/S软件的天下，所以里面的分布式在这里显得理所当然。这部分可以跳过。

        第九章讲述作者实现的一个工作流系统CIMFlow。亮点在于分布式工作流机的设计方案。

        核心思想是：多个工作流机分配给多个部门，与这个部门相关的流程或流程节点就由这个部门专属的工作流机执行，部门可以各自独立修改这些流程或流程节点。另外为了集中管理，再设置一个主控工作流机，集中管理这些部门工作流机。这样可以提高流程的柔性。很赞的思想，但是实现无疑复杂了。

        第十章讲如何在企业流程重组中应用工作流。偶觉得，这本书一旦上升到企业运营的层次讲解工作流，马上就很赞了，O(∩_∩)O~。其中关于流程仿真部分很是好看，颠覆了自己对流程仿真的观点。以前认为是流程仿真是确保流程建模的逻辑正确，属于软件测试的范畴。这里的仿真却是为企业决策提供数据。需要注意的是对资源的定义。资源包括了人、业务系统、运营成本等等，很广义的概念。

        最后一章再次强调工作流集成能力的重要意义。不禁让我想起了BPEL。

        合上书，我想，这是在讲工作流吗，( ⊙o⊙ )?，咋和我印象中的工作流不一样哩。我想，作者更强调的应该是一种高端的业务流程管理，它既不是现有的工作流、也不是BPM软件，然而又不是BPG，因为它管理的流程是可以马上执行的。只能这么想，作为7年前作者对工作流的理解，期望太多。

        如果有电子版，值得一读，如果买纸版，就没有必要了。

一、        从用户的角度分析工作流系统的组成

这里的用户分为两类：一类是应用系统开发人员（以后简称开发人员），一类是应用系统的最终用户（以后简称最终用户）。对于最终用户而言，工作流系统往往是不能直接使用的，它需要由IT部门的开发人员嵌入到应用系统中。开发人员才是工作流系统的直接使用者，这造成了问题：工作流系统更多关注于开发人员的需求，例如如何快速开发、如何更好的嵌入业务逻辑等等，而最终用户的需求被或多或少的忽略了。

这里从最终用户的角度进行分析。

1、                    面向开发人员的流程设计器

最终用户通过流程设计器对业务流程进行描述，实际是一个流程建模的过程。理论上，业务分析师完成这个业务流程建模的过程，并且业务分析师往往被假定为非技术人员。对于业务分析而言，流程建模通常是抽象的，一定程度上是模糊的，建模的目的在于通过图形的形式向其他人解释一个业务的过程，图形只是一种方式，采用它只是它更易于理解和易于沟通，实际类似于DSL。实际上企业的规章制度、文字描述的执行流程都是对业务流程具体的描述方式。

对于工作流而言，这个建模所产生的流程是需要被引擎执行的。这就要求流程中每一个节点的定义都是要有明确含义的，它需要被计算机明确而准确的解释。同时，出于集成业务系统的需要，流程模型定义往往带有很多额外的属性。

所以现实中的流程设计器往往属性配置繁多。导致最终用户在打开设计器后根本无从修改和建模，他需要关注很多与业务无关的配置，无意中的修改往往产生流程无法运行的后果。

2、                    工作项列表

即任务列表。工作流系统通过工作项列表进行人工任务的分配。最终用户通过该列表签收、处理每天的工作，工作以工作项的形式展现。对于工作项，用户有着多种业务操作：签收、完成提交、收回、回退等等。对于分配给他人的工作项，也存在着多种业务操作：催办、提醒、时间限定等等。

3、                    流程追踪

用户在处理工作项时，对该工作在流程中所处的位置进行查看，了解当前流程的状态和执行情况。一般情况下，流程追踪以图形化的方式展现。用户通过不同的图标和标示来区分流程中各个节点的状态和参与者信息。

4、                    流程实例管理

包括流程实例、节点实例、工作项实例的管理。改变状态，包括了挂起、重新启动、终止、跳转等等。主要目的在于对流程人为执行错误进行人工干预以及对流程信息的监控。

二、        系统架构

从用户的角度分析完工作流系统的组成，这里从开发人员的角度分析工作流系统的架构。系统架构里的每一部分是如何与用户使用的部分进行对应，以及每一部分在实现时需要注意的事项。

1、                    整体构成

如图，各模块分层组织，位于上层的模块依赖于底层的模块。正如你所看到的，流程定义模型位于整个工作流系统的最低层，因为它是整个工作流系统的基础。

流程定义模型：定义对流程进行描述的所有对象。因为对流程进行描述的本质就是利用这些模型进行建模，所以这些模型对象的实现直接决定着工作流系统对流程的描述能力。

组织结构适配器：工作流系统在与业务系统进行集成时，需要进行组织适配，通过这一过程将业务系统里的组织机构导入到工作流系统里。具体实现时，工作流系统需要建立起自己的组织机构模型（包含在流程定义模型里），要适应多种业务系统，往往需要建立多套模型，根据具体情况进行切换。有多种方式完成这个适配，最简单的方式是利用SQL配置读取数据进行语义转换。

流程设计器：供用户使用的可视化图形工具。每种图形都对应着一种流程定义模型。具体的实现有Swing、SWT，但是基于AJAX的WEB设计器无疑会提供更好的可用性。

流程执行引擎：将流程定义模型解释为流程实例模型。利用这些流程实例模型完成流程的调度和执行。在工作流系统里，执行引擎是整个系统的核心。实现时不仅需要考虑各种流程调度的实现，还要考虑执行的效率、缓存、日志等等。

工作项引擎：解析参与者定义模型和工作项定义模型，生成相应的工作项。对用户对工作项的操作作出响应。

WEB应用：工作流系统的WEB展现。包括了工作项列表、流程追踪以及流程实例管理的操作和显示。

流程仿真：对建立好的流程模型进行运行仿真，模拟流程模型的执行过程。目的在于发现流程建模过程中的疏漏，发现由此导致的流程不能运行。

时间服务：提供对整个流程实例执行时间和任务执行时间的控制，根据规则触发相应的时间事件，例如任务超时、任务预警等等。根据规则自动触发启动新的流程实例。

业务集成：提供工作流系统与业务系统的契合方式。典型的实现包括通过注册事件监听器和提供接口抽象类调用业务系统代码、提供API给业务系统调用、工作项驱动业务表单和脚本引擎执行业务逻辑脚本等等。特定于工作项驱动业务表单，为方便开发，绝大多数的工作流厂商都提供了电子表单的实现。

2、                    基于事件的流程执行引擎

流程执行引擎的主要职责就是负责流程的调度和执行。

首先需要将流程定义模型解释为流程实例模型，在定义模型和实例模型之间建立起对应关系。一个简单的对应关系如下图所示：

执行引擎将流程定义模型的属性读取到相应的实例模型里，由实例模型完成流程的调度和执行。当然，上图只是一个简单的描述，实际情况要复杂的多，特别是节点定义（ActivityDefinition），根据实际应用，往往存在着多种类型，典型的有开始节点（StartDefinition）、任务节点（TaskDefinition）、自动节点（AutoDefinition）、分裂节点（SplitDefinition）、汇聚节点（JoinDefinition）、结束节点（EndDefinition）等等。这些节点的实例根据类型的不同执行不同的逻辑。其中，分裂节点实例和汇聚节点实例负责流程的调度，它们决定流程的流向，通常情况下，它们会调用一个脚本引擎执行一段脚本来决定流程的流向，同时，也会提供对外暴露的接口，由业务系统实现，接口返回的结果决定流程的流向。任务节点实例和自动节点实例则负责流程的执行，为保证流程执行引擎职责的清晰以及对外围设施的松耦合，它们只是发布相关的事件，通过事件发布/订阅机制来触发具体的逻辑执行。

典型的事件有流程启动事件、流程结束事件、进入节点事件、离开节点事件、时间事件等。例如，任务节点实例的进入节点事件将会触发工作项引擎生成工作项（Workitem），并触发时间服务器开始计时。

3、                    基于充血模型的工作项引擎

对最终用户而言，大部分的业务操作都集中在对工作项的操作上。常见的包括工作项的提交、收回、委派、追加和退回。这些操作从系统设计的角度不仅涉及到工作项（Workitem）对象内部状态的变化，而且影响到流程执行引擎的调度以及相关的其他工作项对象状态。

工作项引擎的职责包括两部分。第一，监听任务节点实例的进入事件，生成工作项实例。第二，处理上面提到的各种工作项操作。

实现时，工作项生成器根据任务参与者的执行模式典型的分为四种情况：

竞争参与，当有多个参与者参与该任务时，产生竞争，谁先开始这项工作，就由谁负责完成该工作。此时，工作项生成器生成多个工作项实例，在某个工作项完成时会终止其余工作项。

顺序参与，多个参与者按照指定的顺序完成该工作。A完成之后由B完成，B完成之后再交给C完成。此时，工作项生成器生成多个工作项实例，根据顺序依次激活各个工作项。

共同参与，多个参与者同时对工作进行处理。此时，工作项生成器生成多个工作项实例并全部激活。

智能决策，存在多个参与者的情况下，工作项生成器能够根据一定的指标（由数据分析，例如人员的处理效率，工作负载等等）和规则来决定该节点的参与者并为其生成相应工作项。这里涉及到算法。

对于工作流系统而言，各种流程实例对象都是充血模型。特定于各种工作项操作的处理，此时的工作项对象亦设计为充血模型，将业务逻辑封装到领域模型里，简化领域模型之间的交互，省去频繁的get/set。由领域模型再委派到具体的处理类里。

Client->(Business Facade)->Domain Model->service->Data Access(DAO)

4、                    工作项驱动业务表单的业务集成方式

最终用户对任务的处理，必然由工作项对应着某一业务表单。用户在工作项列表里选择自己需要办理的工作项，由工作项导航到业务表单。

特定于WEB系统，业务表单的导航由url完成。在流程定义模型设计时，将url设置入节点属性，生成工作项时将此url保存在工作项对象属性里。点击工作项详细信息时即打开该url，完成到业务表单的导航。业务表单页面通常需要引入处理工作项逻辑的父页面或者导入定制的js库，这些父页面或js库由工作流产品提供。这样，对于业务表单编写，工作流逻辑是透明的。

一、什么是业务流程

业务流程是一个技术术语，它具有准确的定义：有组织的活动，相互联系，为客户创造价值。

这句话很好理解。甚至可以说任何企业的活动都是以业务为主线，以流程为线索串联起来的。企业的规章制度、操作手册等都与业务流程有着契合点。

二、业务流程对于企业的意义

业务流程对于企业的意义不仅仅在于对企业关键业务的一种描述，更在于对企业的业务运营有着指导意义，这种意义体现在对资源的优化、对企业组织机构的优化以及对管理制度的一系列改变。这种优化的目的实际也是企业所追求的目标：降低企业的运营成本，提高对市场需求的响应速度，争取企业利润的最大化。

三、业务流程也是一个体系

业务流程通常的表现形式是流程图（不是唯一形式），毕竟图形是最易于理解的一种形式，但似乎我们太关注于流程图本身而忽略了其他。除了流程图之外，业务流程还应该包括目标和指导方针，这才是一个完整的业务流程。在梳理业务使用业务流程描述时首先要想到的是该流程所要达到的目标，能为客户创造什么价值，脱离开业务目标或者说纯粹为描述业务而描述业务是没有意义的。同时在制定业务流程时也要考虑到该业务流程的指导方针，同一个业务可能有很多种业务流程的描述形式，具体哪一种是最合适的，这里就必须有一个指导方针来进行约束。

四、业务流程的特征

1、层次性、逐层抽象

业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。

这样一个层次关系符合人们的思维习惯，有利于企业业务模型的建立。一般来说，我们可以先建立主要业务流程的总体运行过程（其中包括了整个企业的大的战略），然后对其中的每项活动进行细化，落实到各个部门的业务过程，建立相对独立的子业务流程以及为其服务的辅助业务流程。

业务流程之间的层次关系一定程度上也反映了企业部门之间的层次关系。不同层级的部门有着对业务流程不同的分级管理权限。决策层、管理者、使用者可以清晰的查看到下属和下属部门的业务流程。

为使得所建立的业务流程能够更顺畅的运行，业务流程的改进与企业组织结构的优化是一个相互制约、相互促进的过程。

2、以人为本

组织中最重要的部分是人员的工作方式以及构成他们每日操作的工作流程。

人是业务流程的驱动者，组织中的每一个人都会在业务流程中充当一个角色。通过良好的业务流程，每一个人都会有自己清晰的职责，要求具有良好的沟通协作意识和团队意识，明确自己在一个个业务流程中所担当的角色。

同时对于参与其中的业务流程，每个人员都要有自己的反馈。

首先，每个人员都能查看到这些业务流程，他们需要充分理解这些业务流程、流程的业务意义和目的，这些业务流程通过切合他们理解能力的方式（切合业务的图形、说明文字、相应的制度、规范、标准等等）得以展现。

其次，对于流程运行中存在的问题或瓶颈，每个人员都要积极反馈（提出修改的建议，或者在权限范围内直接修改）以促进流程的持续改进，业务流程的管理和变动不仅仅是业务分析人员或管理人员的职责，每一个员工都要参与其中，否则只有失败。管理人员和决策层更重要的职责是制定出业务流程的规则和约束，在这个规则和约束范围内，员工可以根据变化的商业环境对业务流程做出迅速修改，这样不必等到领导了解情况后再做出决策从而失去机会。

3、对流程运行效益的分析

从企业投资者的角度来讲，好的业务流程设计必然是能够为企业带来最高利润的设计。因此，对业务流程的效益分析是评价业务流程的一个重要方面。财务数据是最关键的数据，但这种分析不一定完全是由数据支撑的，有些是不能量化的，比如人员效率等等。

五、业务流程管理

良好的业务流程管理是保证企业灵活运营的关键（业务流程管理又何尝不是一种业务流程？）。

1、业务分析

实际这也是业务流程管理最重要的部分。它需要对企业业务有着强大的分析能力，因为业务分析对企业的运营有着重大的指导意义，只有具备了这样的业务分析能力，才能把握住企业运转的真实流程，而且这种分析能力往往带有对整个行业的深刻理解和前瞻性。没有异议，业务分析在于人，与IT无关。

2、业务流程的持续改进

不仅仅是流程管理人员（管理决策层）根据运行效益的分析和商业环境的分析对流程进行重整。还包括每个员工对其参与的流程的持续反馈和持续改进。柔性的业务流程。

3、IT系统与业务流程的关系

IT系统与业务流程并没有直接的关系。正如06z在SOA帖子里表达的：soa95%以上的工作是在做业务流程的分析解构和重整，技术层面的支持只占5%不到。在落实到技术层面，你觉得一个soa产品究竟应该包括些什么内容呢？这些内容又能有多少是能够辅助大家对业务流程进行分析和测试，对业务元素进行重整和再分配？如果你们真的有这个能力，你们觉得是在这里继续开发软件过苦日子，还是去开拓商业咨询呢？我的观点是：SOA很美好，但是一落地就变成了小丑。所谓的业务流程管理软件同理。

可以这样理解：业务流程管理是一个很大的命题，IT系统通过信息化对它的子集进行支撑，这里的IT系统包括的范围很广泛，包括了所有的企业应用软件（所有的企业应用软件都可以看作是对企业某部分的业务流程进行的描述）。业务流程管理的核心在于业务流程的分析解构和重整，这点是所有软件都不可企及的，关键在于人。至于BPM还是工作流，它们本来就有它们自己的适用范围，硬要把它提升到业务流程管理的高度来宣传，那就真的和小丑一样，滑稽而可笑。

关注下篇：BPM是干什么的

收回是工作流参与者对自己“已办任务”（对已完成的工作项）的一种操作，即参与者主动对已办理过的工作项进行重新办理。

为什么要收回？

参与者完成任务后，发现自己办理有错误等情况后，需要将此任务收回重新办理。

工作项的参与方式

目前有四种方式：共同参与、竞争参与、顺序参与、基于角色的共同参与。

下面会针对这四种方式进行讨论。

工作项收回模式

1、未触发下一节点的工作项的收回

即当前任务节点并未完成，依旧处于执行状态

1.1共同参与

如图：在节点A未结束之前，workitem1、workitem2和workitem3正常完成后可以任意收回。在只产生一个workitem的情况下，不存在未触发下一节点的收回情况。

1.2顺序参与

如图：workitem1、workitem2和workitem3顺序完成，workitem1在workitem2签收（包括挂起和手工终止）前可以收回，同样，workitem2在workitem3签收（包括挂起和手工终止）前也可以收回。在只产生一个workitem的情况下，不存在未触发下一节点的收回情况。

1.3竞争参与

因为只会产生一个workitem，该workitem完成后会立刻触发下一节点，所以不存在未触发下一节点的收回情况。

1.4基于角色的共同参与

与1.1相同。

2、已触发下一节点的工作项的收回

2.1共同参与

问题1：多个工作项时谁可以执行收回操作？

workitem1、workitem2和workitem3都可以执行收回操作。第一个工作项的收回将会导致节点B实例的删除，同时节点A重新恢复执行状态。

问题2：节点B处于什么状态节点A的工作项可以执行收回操作？

由A触发的节点B处于正在执行的状态，节点B所产生的工作项：

a共同参与   工作项均未签收、挂起或手工终止

b顺序参与    第一个工作项未签收、挂起或手工终止

c 竞争参与   工作项均未签收、挂起或手工终止

d角色        同共同参与

问题3：工作项收回产生的影响？

节点A重新执行，收回的工作项重新执行。节点B重新恢复未触发状态，B所产生的工作项全部删除。

2.2顺序参与

问题1：多个工作项时谁可以执行收回操作？

workitem1、workitem2和workitem3根据顺序可以依次执行收回操作。

2.3竞争参与

情况简单，只有一个工作项，所以可以直接收回。

2.4基于角色的共同参与

同2.1

工作流收回模式

后续触发节点只能是人工节点（可以是多个，至少一个），否则不支持收回。目前不支持父子流程之间的收回。

一个典型的同步汇聚情况：

节点1首先执行完毕，但是因为是同步汇聚，所以它不会触发实际的流转；而节点2的完成则会触发节点3的执行。在这种情况下，节点2的工作项可以执行收回操作，而节点1的工作项因为后续没有触发节点而不能收回。

回退（Rollback WorkItem）

回退是工作流参与者对自己“待办任务”（实际是对工作项）的一种操作，即参与者主动回退待办任务列表中的任务到已经执行过的人工节点。

为什么要回退？

参与者接受任务后，发现不应由自己办理此任务或以前的执行者办理有错误等情况后，需要将此接受的任务回退给以前某个节点的执行者重新办理。

回退模式

回退的情况实际上是非常复杂的，其中包括了参与者的重新选择以及回退的条件判断等等。这里先列出常见的回退模式（其实也是我们支持的模式）。

串行

这种情况最为简单，后续节点可以回退到前续任意人工节点。回退后，节点重走。

分支

这种情况也相对简单，实际执行的分支上的节点可以回退到前续任意人工节点（不区分主支和分支）。同样，主支上的节点也可以回退到任意实际执行的分支上的节点。

可能的问题：多次回退后的回退节点选择。例如：第一次流程经过节点2、节点3到达节点5，节点5可以回退到节点1、节点2和节点3的任意一个，此时节点5回退到节点1，节点1重走，这一次流程改为经过节点4到达节点5，节点5回退时如何选择回退节点？此时的策略是以最近实际执行的分支为准，即节点5只允许回退到节点4和节点1，不允许回退到节点2和节点3。（抹去记忆）

并发

对于并发的情况，分支节点只允许在分支的节点间回退。

同理，主支节点也只允许在主支的节点间回退。

多实例汇聚

在这种情况下，节点5会产生2个实例，实际相当于继续并发。节点5根据具体哪个节点触发的它而产生回退节点。同时不允许回退到节点1以及前续的节点去。

子流程

支持子流程到父流程的回退，也支持父流程到子流程节点的回退。需要注意的是子流程节点有可能产生多个子流程实例，在这种情况下不支持父子流程之间的相互回退。

回退节点的参与者选择

默认策略是由原先节点的实际参与者重新处理，比如节点2回退到节点1，则节点1的实际参与者重新处理该节点任务。这也符合大多数实际的业务场景。

在节点任务竞争参与的情况下，提供另一种策略，即让人员重新竞争。

回退的条件判断

对于多人（或者多部门，用户）参与的工作项，提供不同的回退策略

任意人回退即回退，剩余工作项手工终止

最后提交人回退才回退

   流程定义期定义该策略。

   另外流程定义时提供节点可回退列表，由用户在定义期对可回退的节点进行限制。

关于业务补偿

业务补偿是一个很重要的概念，在回退的情况下需要相应的回退部分业务操作。这里由引擎提供统一的接口，返回回退路径，由客户自定义代码进行匹配处理。

关于实现

很多工作流引擎通过流程定义时绘出回退线来显式的支持回退，这种实现在业务复杂的情况下会造成流程图的异常烦琐，但是比较清晰，实现比较容易。隐式实现相比而言优点更多。

一、流程实例的状态

   状态分为5种：实例化、执行中、挂起、手工结束、正常结束。

   状态的变迁如下图：

二、节点实例的状态

状态分为5种：实例化、执行中、挂起、手工结束、正常结束。

状态的变迁如下图：

三、具体节点的状态

   细分：

A、人工节点、等待节点

这两个节点被触发后存在一个执行等待的过程，所以可以被用户直接挂起和手工结束。人工节点的挂起意味着所有未完成工作项的挂起，同时相应时间服务的时间计算的挂起。手工结束会使流程跳过该节点（所有工作项手工结束），继续往后流转。

B、开始节点、结束节点、分支节点、自动节点

这些节点的特点在于被触发后立刻执行和流转，所以不会存在挂起和手工结束的状态。

C、并发节点、汇聚节点

并发节点和汇聚节点不存在挂起的状态，同时不能被用户直接手工结束，它们的状态受流程实例状态和相关节点实例状态的影响。

并发节点和汇聚节点的情况复杂一些，分模式讨论

图1

1、同步汇聚（图1）

根据情况触发节点0、节点1、节点2中的一个或多个，汇聚节点等待所有实际触发的节点完成后再执行流转。中间汇聚节点只会产生一个实例。

1.1、正常流转时的处理策略

当汇聚节点未被触发时（即节点0、节点1、节点2都未执行结束），并发节点处于执行状态，一旦汇聚节点被触发（即节点0、节点1、节点2有一个执行结束），并发节点正常结束并且汇聚节点处于执行状态，所有并发出的节点实例执行结束后，汇聚节点正常结束，流程继续流转。

1.2、用户挂起、手工结束相关节点的处理策略

1.2.1、汇聚节点未激活时

节点0、节点1、节点2的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态）；节点0、节点1、节点2的任一手工结束都会触发汇聚节点，使并发节点正常结束，如果所有并发的节点实例都结束（包括手工结束和正常结束），汇聚节点正常结束，触发流程流转。

1.2.2、汇聚节点已激活时

节点0、节点1、节点2的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态）；节点0、节点1、节点2的手工结束会影响汇聚节点的状态，每个节点实例的手工结束会引起汇聚节点的判断，如果所有并发的节点实例（包括正常结束和手工结束）都结束，汇聚节点正常结束，触发流程流转。

1.3、用户挂起、手工结束流程的处理策略

1.3.1、汇聚节点未激活时

流程的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态），节点0、节点1、节点2会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

1.3.2、汇聚节点已激活时

流程的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态），节点0、节点1、节点2未执行结束的实例会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

2、nOutOfM汇聚（图1）

根据情况触发节点0、节点1、节点2中的一个或多个，汇聚节点等待N个实际触发的节点完成后即执行流转（N>0且N<M，M为实际触发的节点个数），在N<=0和N>=M的情况下即为同步汇聚。中间汇聚节点只会产生一个实例。

2.1、正常流转时的处理策略

当汇聚节点未被触发时（即节点0、节点1、节点2都未执行结束），并发节点处于执行状态，一旦汇聚节点被触发（即节点0、节点1、节点2有一个执行结束），并发节点正常结束并且汇聚节点处于执行状态，N个并发出的节点实例执行结束后，汇聚节点正常结束，流程继续流转，M-N的节点实例被手工结束。

2.2、用户挂起、手工结束相关节点的处理策略

2.2.1、汇聚节点未激活时

节点0、节点1、节点2的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态）；节点0、节点1、节点2的任一手工结束都会触发汇聚节点，使并发节点正常结束，如果N个并发的节点实例都手工结束，并发节点正常结束，触发汇聚节点，汇聚节点正常结束，触发流程流转，M-N的节点实例被手工结束。

2.2.2、汇聚节点已激活时

节点0、节点1、节点2的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态）；节点0、节点1、节点2的手工结束会影响汇聚节点的状态，每个节点实例的手工结束会引起汇聚节点的判断，如果N个并发的节点实例（包括正常结束和手工结束）都结束，汇聚节点正常结束，触发流程流转，M-N的节点实例被手工结束。

2.3、用户挂起、手工结束流程的处理策略

2.3.1、汇聚节点未激活时

流程的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态），节点0、节点1、节点2会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

2.3.2、汇聚节点已激活时

流程的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态），节点0、节点1、节点2未执行结束的实例会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

3、辨别汇聚（图1）

是nOutOfM汇聚的特例，N=1

4、多实例汇聚（图2）

图2

根据情况触发节点0、节点1中的一个或多个，节点0和节点1任意一个执行结束后都会触发汇聚节点产生一个新的实例，汇聚节点实例紧接着触发节点2，节点2也会产生多个实例。

4.1、正常流转时的处理策略

当汇聚节点未被触发时（即节点0、节点1都未执行结束），并发节点处于执行状态，一旦汇聚节点被触发（即节点0、节点1有一个执行结束），汇聚节点会紧接着触发节点2，汇聚节点正常结束。所有并发出的节点实例执行结束后，并发节点正常结束。

4.2、用户挂起、手工结束相关节点的处理策略

节点0、节点1的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态）；节点0、节点1的手工结束会影响并发节点和汇聚节点的状态，每个节点实例的手工结束会引起汇聚节点产生新的实例并触发节点2，同时会引起并发节点的判断，如果所有并发的节点实例都手工结束，并发节点正常结束。

4.3、用户挂起、手工结束流程的处理策略

流程的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态），节点0、节点1、节点2会被全部挂起或恢复；流程的手工结束会引起所有未结束节点的手工结束。

5、隐式结束，没有汇聚节点与并发节点对应（图3）

图3

所有节点结束时（正常结束或手工结束），并发节点正常结束。流程的手工结束会引起所有未结束节点的手工结束。

四、流程实例状态变化对节点实例状态造成的影响

1、流程实例的挂起

   A类节点挂起，B、C类节点不受影响。同时在流程实例恢复执行之前，A类节点不允许用户直接恢复执行。

2、流程实例的手工结束

   所有节点全部手工结束。

五、节点实例状态变化对流程实例状态造成的影响

隐式结束的情况下，节点的手工结束或正常结束都会触发流程的判断，如果所有的节点都已结束则流程结束。

先来看看具体的应用场景。

单表增删改查

这是最简单的情形，也没有流程，对这个情形不加讨论。但是这里会提到表单引擎，VB里的数据控件非常的易用，没有PO，没有DAO，也没有Service，直接与数据库字段进行绑定。我们的表单引擎也可以采用这种方式。

支持表单控件（输入框、文本框、下拉框等）的拖拽，将整个表单与数据库表绑定。

表单控件与数据库字段的绑定。

单表业务+流程

比上面的情况稍微复杂一点点，也就是要在业务里引入流程，其实这也是现在工作流引擎应用最多的地方，比如说政府OA里的收文、发文。

这里只需要将表单与流程进行绑定，表单引擎的处理方式不变，依然是直接与数据库表进行绑定。表单负责对数据库里的业务数据进行展现，工作流则负责推动这些数据在业务意义上状态的转换，互不影响，并在需要的时候在自动节点上对这些数据进行相应的业务处理。

关于表单权限。这个也是表单与工作流进行绑定时所必须考虑到的问题。其实只是需要在表单引擎里引入权限角色的概念，每个角色对应于一种权限，这种权限具体说来就是表单里每个字段的可见、可编辑等等。然后在人工节点定义时指定表单权限角色即可。这样也实现了流程与表单权限一定程度上的解耦。

其实还有一种更方便的方式，将表单直接与人工节点进行绑定，每个人工节点对应于不同的表单。

复杂一点，多表关联的情况

复杂一点的情况是业务往往是多表的关联。这需要对表单引擎做出扩展，让它可以根据关联字段对关联表做出查询，得到关联表的设计结构，继续映射。这让我想起了ORM，这里很有FRM的意思在里面。其实对于常用的关联查询往往有通用的组件可用，例如根据userid渲染出用户名，根据数据字典的id关联渲染出相应的值，oa里的正文、附件、印章等等。

流程跨越多个业务

流程需要跨越多个业务，一个典型的流程如下：

会议审批会涉及到两张业务表：会议室使用表，会议记录表。在会议申请和领导审批节点，最终用户打开的都是会议申请的表单，对应于会议记录表，对该表进行操作。但是流程运行到会议室管理员安排会议室的节点，该节点最终用户不仅需要看到会议申请的表单同时还要看到会议室使用情况的表单，如果有空闲的会议室，用户登记操作会议室使用表，然后通知申请者；如果没有空闲的会议室，则不用登记直接通知申请者。这个过程中跨越了两个业务，分别是会议室管理和会议管理。表单在各个节点也是不同的。

这其实对工作流引擎提出了比较高的要求。例如如果流程已经结束，会议得到批准，但申请者突然有事要改变会议时间怎么办？回退。这里的回退无疑就需要有业务的补偿，例如要删除会议室的相关记录。

应用集成

一个流程不仅会跨越多个业务，也会跨越多个系统。这里的应用场景很多，重要的是要去其他系统抓取数据和操作数据，仅仅靠数据库表对表单的映射满足不了需求。

对工作流引擎做出改进，与前面相比，需要由引擎来完成对其他系统服务的调用。这里一个很重要的载体就是XML。首先要定义交换数据所用的XML scheme，然后将这个XML scheme再与表单引擎做出映射。实际执行时，工作流的自动节点会在人工节点前调用其他系统的服务，按照XML scheme将数据转换为符合定义的XML，在紧接着的人工节点送给表单引擎，表单引擎渲染。修改数据也是同样的过程，表单引擎将处理后的数据以XML返回，工作流再次做出转换，调用服务的修改功能。

上面五种都是比较常见的应用场景，理想的情况下，开发方式应该是这样的：画出应用流程à定义流程表单à表单与数据库进行映射à对流程进行业务仿真à完成开发。问题是这样的：你的表单引擎是否足够强大？表单与后台是直接用SQL进行交互的，也就是Transaction Script模式，没有业务对象，对于复杂业务逻辑如何处理？如何使用规则引擎来解决业务逻辑的问题？权限如何以一种AOP的方式对数据操作进行横切？

呵呵，纯属个人YY。

对于当前的工作流应用来说，人工节点无疑扮演着一个非常重要的角色。因为无论是传统的协同办公系统还是越来越多的企业应用，都需要有人参与到具体的流程中来。这篇文章着重分析工作流应用中人工节点所涉及到的参与者模式以及与此关联的工作项模式，最后会提供部分的解决方案作为参考。

先简单说说什么是人工节点。

人工节点的概念是与自动节点相对的。顾名思义，人工节点就是需要有人参与的节点，在实际流程中，它体现在产生由人完成的工作项以及由人决定一些决策变量，这些决策变量会对流程的运行产生影响（例如分支的选择等等）。自动节点则是由工作流引擎自己调用完成，不需要人的参与，通常是执行定制的业务操作。相比较而言，人工节点更多的应用在管理流程里，而自动节点更多的则是应用在企业业务流程里。

人工节点的职责有三个：第一是决定该节点的参与者；第二是根据参与者生成需要人来处理的工作项；最后是当工作项被参与者处理完毕时，它将继续触发流程的流转。参与者处理工作项时可以处理相应的业务和设置流程决策变量。

下面我们就按照这三个职责分别对人工节点所涉及到的参与者模式和工作项模式进行分析。

1、  决定参与者模式

换句话说就是决定该节点的参与者，这里有两种模式：引擎自动获取和最终用户指定。
 

1．1引擎自动获取

所谓引擎自动获取就是由引擎在运行期计算实际的节点参与者，不需要最终用户的参与。这个计算基于流程定义时对该节点参与者的定义。

（1）    直接指定人员、部门或角色

这种情况最简单，也最直接，用户定义节点时直接在组织用户树里选定人员、部门或角色，然后在运行期根据定义执行与或者是或的运算。大多数的工作流引擎都支持这种模式。但很明显它也存在着很大的局限性，它是静态的，一旦流程定义完毕参与者也就跟着固定下来，运行期的任何变化都不会对参与者造成影响，一个很简单的需求，请假流程，节点的参与者需要是当前申请者的部门领导，因为申请者在定义期是不确定的，所以根本无法指定节点的参与者，所以这种模式远远满足不了用户稍微复杂一点的需求。

（2）    调用用户定制的计算参与者代码

这种情况通常是由引擎提供一个接口或是父类，用户需要实现或是继承这个接口或父类，然后实现相应的方法。这个方法通常会传递进一个执行上下文的参数，用户代码通过这个上下文可以访问到当前流程实例的信息，例如当前节点状态，工作流变量等等，然后用户可以根据实际业务和当前流程实例信息进行逻辑计算，最后返回一个参与者的ID集合。对于上一个模式里提到的计算当前申请者部门领导的例子，这个模式实现起来非常简单，首先获得当前申请者ID，然后在根据这个ID找出该申请者部门再找出该部门领导即可。

实际流程运行到该节点就会调用用户自己定制的计算参与者的代码，方法返回的参与者ID即作为该节点的实际参与者。

这种模式对于工作流引擎的实现而言最为简单，因为它把最大的复杂性都抛给了用户，由用户代码来计算实际的参与者。实际上很多开源的工作流引擎采用的都是这种方式，例如JBPM。但是这种方式给用户带来最大灵活性的同时也带来了复杂和烦琐。特别是当面对一个数量巨大的流程需求时，为每一个流程的每一个人工节点都定义一个参与者计算类是让人头疼的。再加上现在强调业务的敏捷，业务里的改变要迅速反馈到流程的定义里，让最终用户来编写或修改这个参与者计算类不现实也不可能。补充一下，这也是用户在考虑采用开源的工作流引擎还是商业工作流引擎时需要着重考虑的一个方面。

（3）    指定前续节点的参与者

实际上是用户在节点定义时指定参与者为前续某个节点的参与者，当流程运行到该节点，引擎会自动获取所指定的前续节点的参与者作为该节点的实际参与者。

这个模式实现起来并不困难，大多数商业工作流引擎都对该模式进行了支持。它能够满足用户的部分特定需求。

（4）    更为复杂的情况

用户的需求永远是复杂的，引擎所要做得就是尽量降低这种复杂性，流程的变化要能够迅速跟上业务的变化。考虑下面两种稍微复杂一点但是又很常见的需求。需求一：参与者为当前申请者的部门领导且职位为副总；需求二：参与者需要是测试部的所有女同事。这两种需求模式1、3都不能满足，2可以，但是正如提到的那样，模式2可能会非常的烦琐，不能适应业务的敏捷。其实这里的复杂性主要体现在：1、这里的参与者可能是运行期决定的；2、参与者的限制条件可能非常多，而这些条件不是简单的部门、角色或职位所能描述的。

对于一般的工作流引擎而言，它们都会选择模式2的实现，让用户自己实现逻辑。实际在后面的部分解决方案里，我们会看到更为好一点的实现方式。

1.2最终用户指定

   运行期由最终用户来决定节点的参与者。这也是中国国情所独有的特色。这种模式最为常见的就是用户提交工作项时的提交页面，用户在该页面上选定下一节点（多数分支用户选定时）和下一节点的参与者。这种模式本身并不困难，问题在于在提交页面需要给用户提供一个参与者的选择范围，让用户进行选择。而关于这个选择范围，则又回到前面所提到的引擎自动获取的模式，这个范围同样是需要引擎计算的。于是又回到了刚刚讨论过的四种模式。

2、参与者执行模式

   现在，已经获得了节点的参与者。引擎下一步将会根据这个参与者生成工作项，注意，这里的参与者可能是一个人，也可能会是一个人员范围（即多个人）。于是就产生了参与者的执行模式，也可以理解为工作项的生成模式。

2.1竞争参与

当有多个参与者参与这个节点时就会产生竞争参与这个模式。同样一个工作，A可以完成，B也可以完成，于是就产生竞争，谁先开始这项工作，就由谁负责完成该工作。

2.2顺序参与

   多个参与者按照指定的顺序完成该工作项。A完成之后由B完成，B完成之后再交给C完成。

2.3同时参与

   多个参与者同时对工作进行处理，所有参与者均完成后，流程继续向后流转。这个模式其实比较复杂，因为这里同时涉及到一个完成规则：是所有参与者均完成工作项后流程流转，还是有其他规则？例如完成2个工作项即可流转，完成80%的工作项即可流转。稍候会讨论到。

2.4负载均衡

   这也是一个常见的需求。这项工作A和B都可以完成，但是A目前有10个待办工作项，B只有2个待办工作项。于是用户期望该工作交由B来完成。这里需要实现一个简单的负载均衡。其实这种情况只是智能决策的一种最简单的情况，所谓智能决策是指系统能够根据一定的指标（由数据分析，例如人员的处理效率，工作负载等等）和规则来决定该节点的参与者。

3、工作项完成模式

这个模式在参与者执行模式为同时参与时有效。在说到这个模式之前，先简单说说工作项可能存在的几种特殊状态，这些状态包括挂起、人工终止和委派。挂起就是工作项暂时停止执行，挂起会影响到流程的流转，会导致流程的挂起。人工终止则是人工手动改变该工作项的状态，使该工作项终止执行，这个人通常会是管理员。人工终止也会对流程流转产生影响，当除去该工作项之外的所有工作项都完成时，人工终止该工作项会触发流程的流转。委派就是将该工作项委派给他人完成，同时该工作项也就结束了。人工终止和委派是工作项结束的特殊状态。
 

3.1全部完成

当所有工作项都结束时触发节点的结束和流程的流转。

3.2完成规定的个数

节点定义时指定工作项必须完成的个数，当完成的工作项达到这个指定的个数时触发节点的结束和流程的流转。 

3.3完成规定的百分比

节点定义时指定工作项必须完成的百分比，当完成的工作项占所有工作项的比例达到这个指定的百分比时触发节点的结束和流程的流转。
 

其实这里很明显的可以看出不管是所谓的参与者执行模式还是工作项完成模式不过都是一定的规则，既然是一定的规则那必然就限定了应用的灵活性，用户能否自定义规则？根据业务灵活地修改规则？规则引擎+DSL应该是一个不错的选择。

%AXIS_LIB%\jaxrpc.jar;%AXIS_LIB%\saaj.jar;%AXIS_LIB%\log4j-1.2.8.jar;也就是把%AXIS_LIB%下所用JAR文件都导入

三、实验一下

   在%AXIS_HOME%\webapps下找到axis文件夹，将其整个拷贝到%TOMCAT_HOME%\webapps下，启动

  Tomcat,打开浏览器访问http://localhost:8080/axis/，出现以下页面说明你配置成功了。很简单吧：）


四、发布我们的第一个程序

   第一个程序简单的返回HELLO WORLD！