JBPM工作流引擎分析.doc

JBPM工作流引擎分析周光昭(清华大学 软件学院，信息系统与工程研究所， 北京 10084)摘要：本文以JBPM 3.2.2为蓝本，分析了JBPM工作流管理系统的基本体系结构，对其核心的工作流引擎做了流程定义、流程解析、流程调度、组织模型等基本功能的分析，并修改了源代码增加了部分在JBPM 3.2.2 自带WebConsole未实现的功能。关键词：JBPM 工作流 引擎1. 引 言JBPM，全称Java Business Process Management，是一个基于J2EE的轻量级柔性可扩展工作流管理系统，最新版本为3.2.2。作为Red Hat旗下开放源代码软件公司JBOSS的企业中间件平台的一个组成部分，JBPM提供了强大的业务流程管理功能。JBPM是一个开源软件，遵循LGPL开源协议；它以纯Java编写，适用于不同的操作系统；采用自定义的JPDL(JBoss JBPM Process Definition Language)语言描述业务流程，同时提供对BEPL的支持；数据持久层以Hibernate为依托，几乎支持目前所有的数据库管理系统；采用面向图的编程（Graph Oriented Programming）思想，架起业务人员和系统分析人员间沟通的桥梁，实现了业务流程建模到具体实现的平滑过渡。2. JBPM体系结构JBPM工作流管理系统包含3个主要组件：核心组件JBPM工作流引擎，封装成Java类库，可以被方便的调用；可视化流程定义组件JPDL Designer，是一个图形化工具，以Eclipse插件的形式存在，方便不懂编程的业务人员或业务分析师设计业务流程；应用组件JBPM Web Console，以JSF为表示层，提供流程实例与用户的任务交互界面，同时作为流程管理和监控的控制台。下展示了组件间的依赖关系，及其和WfCM标准工作流系统体系结构的对应关系。 图2.1 JBPM工作流管理系统体系结构作为核心的工作流引擎又可以进一步分解为以下组件：流程定义装载，负责流程定义的语法验证和解析；流程执行服务，负责流程的实例化，以及流程实例的执行调度、资源分配等；请求处理器，将客户端传递给流程执行服务；日志管理器，记录引擎运行的日志信息；状态管理器；交互服务，提供引擎与遗留系统的交互。下图展示了组件间的依赖关系。本文着重分析JBPM工作流引擎的核心功能：流程解析和流程调度。图2.2 JBPM流程引擎体系结构3. JBPM流程定义要对流程进行解析，首先必须定义流程。JBPM提供了可视化流程设计器方便用户进行业务流程的定义，在流程定义中借用了的UML的状态图和活动图的思想，使流程更加直观易懂。下图展示了JBPM中的流程定义图和UML活动图的对比。图3.1 JBPM流程定义图和UML活动图流程定义保存在一个XML文件中，主要由下面七个部分组成：1. swimlane，泳道，它们被用于任务分配，一个泳道可以被视为一个参与者在这一流程中的角色名称。2. start-state，流程的起始状态，所有的流程实例都是从这个状态开始的，没有起始状态的流程是合法的，但不能被执行；3. node-elements，包含一系统流程定义的节点，这些节点类型包括end-state|state|node|task-node|process-state|super-state|fork|join|decisiontransition作为node-elements的一个子元素存在4. action-elements，全局定义的动作，可以在事件和变迁中引用，为了被引用，这些动作必须被指定名称；包括 action|script|create-timer|cancel-timer5. event，事件，服务于动作的流程事件，作为action-elements的容器；6. task，任务，和用户交互；7. exception-handler，异常处理器，用户定义的流程异常处理程序。3.1 JPDL流程定义的对象及其关系从图3.1我们可以看出，JBPM流程定义中最基本的对象就是节点(Node)和变迁(Transition)，节点表示不同的业务处理逻辑，变迁指出节点间的执行顺序。JBPM在节点和变迁的基础上又抽象了一层，称之为图形元素(GraphElement)。同时为了表达节点和变迁事件的具体执行逻辑，引入了动作(Action)的概念。图形元素有5个主要属性：名称(name)、描述(description)、所属流程定义(processDefinition)、可触发事件(events)、异常处理器(exceptionHandler)。除了前面提到的节点和变迁，还有流程定义(ProcessDefinition)和任务(Task)也继承了图形元素。所有在流程图上可表达的节点，如开始节点、分支节点、汇合节点等，都继承了Node对象。下图展示了基本对象间的继承关系。图3.2 JBPM流程基本对象间的继承关系除了基本对象外，JPDL还定义了action、event等辅助的元素，下图展示了一个流程定义中对象的关系：图3.3 JBPM流程定义中对象的关系3.2 JPDL中的主要节点类型JPDL的主要节点类型为以下8个：任务节点（task node）、自动节点(node node)、状态节点（state node）、决策节点(decision node)、分支节点(fork node)、汇聚节点（jion node）、开始节点(start node)、结束节点(end nod)。这些节点是业务流程定义中最常用的，下面分别说明不同节点的功能：任务节点 ：一个任务节点可以包含一个或多个任务，任务的完成需要和用户进行交互（一般通过表单形式）。当流程执行到一个任务节点的时候，任务节点上的任务被实例化并插入相应用户(组)的任务列表中。然后，流程进入等待状态，直到用户完成任务。任务的完成将触发流程实例的继续执行，即触发标记（token）。表单和任务的绑定通过froms.xml文件实现。自动节点 ：自动节点包含由计算机自动完成的任务，用于显示表达业务分析中相对重要的自动任务。一般来说，该节点包含一个名为动作（action）的子元素，其内容是一个Java类（实现ActionHandler接口），用于实现所需的API调用。对于那些不需要在流程中显示表达的API调用，可以把动作（acition）隐含在节点的事件（event）属性内实现。（工作流引擎调用外部系统的API）状态节点 ：状态节点实际上就是一个等待状态状态，与任务节点不同之处在于它不会在任何用户的任务列表插入任务实例。状态节点用于等待外部系统的响应，例如：当流程执行到该任务节点时，流程进入等待状态；直到外部系统发回一个响应消息时，标记被触发，流程继续执行。（外部系统调用工作流引擎的API，一般是触发标记）决策节点 ：决策节点即单一选择路由节点，有3种方式指定决策标准。最简单的是使用决策表达式，返回一个出向变迁名。另一种方法是给决策节点的每个出向变迁附上一个布尔表达式，当流程执行到决策节点时，工作流引擎将按流程定义文件中的顺序依次计算每个变迁上的布尔表达式，选择第一个为真的变迁向下执行流程。最后一种方式，也是最灵活的方式是使用决策处理程序：一个实现DecisionHandler接口的java类，该类返回决策结果的变迁名，例如调用规则引擎按照事先定义好的业务规则执行决策。这3种决策方式命名为：表达式决策、变迁条件决策、接口决策。分支节点 ：分支节点即并行路由节点，把当前流程的执行路径分为多个并行的执行路径。当流程执行到该节点时，标记（token）停留在fork节点作为父标记，同时产生与分支数相同个数的子标记，子标记沿各自分支向下传递。汇聚节点 ：汇聚节点必须与上述分支节点成对使用，所有到达汇聚节点的子标记应由同一个父标记产生。当子标记到达汇聚节点时，子标记自动结束。当最后一个子标记到达汇聚节点时，父标记将传递到汇聚节点，并沿汇聚节点的唯一出向迁移向下传递。在这之前汇聚节点一直处于等待状态。开始节点 ：一个流程定义只能有一个开始节点，它没有入向迁移，只有出向迁移，作为流程的开始标记。开始节点最多只能包含一个任务。开始节点可以不进行人员选派，默认的任务执行人为流程实例的发起者。结束节点 ：结束节点表示流程的终止，它仅有入向迁移，一个流程可以有一个以上的结束节点。3.3 JPDL中的辅助节点类型作为主要节点类型的补充，JPDL中还定义了以下4种节点：Email节点 ：在流程中显示的表达发送Email给指定用户的节点，完全可以用自动节点加上适当的参数代替它。ESB服务节点 ：企业服务总线（ESB，Enterprise Service Bus）是JBoss新推行的一个SOA平台，通过服务封装企业遗留系统的应用，达到企业应用集成的目的。ESB服务节点就是用于调用ESB提供的服务的，可以用自动节点加上适当的参数代替它。（注：JBPM已经被集成到JBossESB系统中）流程状态节点 ：调用一个子流程。超态节点 ：超态是一组节点的集合，可以用来在流程定义中产生一些层次，例如，一个应用可能要把流程中的所有节点按阶段进行分组。3.4 JPDL流程定义文件的XML文档结构及其校验JBPM的流程定义保存在部署包的processdefinition.xml文件中，JPDL的XML Schema描述对该文件做了限定。一个XML Schema通常是一组为了描述一类给定的XML文档而预先定好的规则。它定义了可以在指定XML文档中出现的各个元素以及和某个元素相关的若干属性。jPDL的XML Schema包括3个不同的版本的文件：/jbpm/xsd/jpdl-3.0.xsd/jbpm/xsd/jpdl-3.1.xsd/jbpm/xsd/jpdl-3.2.xsd可以在jbpm-jpdl.jar包的orgjbpmjpdlxml目录下找到，其中jpdl-3.0.xsd有详细的注释。附件的schema.rar里也有图形化的说明。所以这里不在赘述。4.JBPM对流程定义的解析JBPM对流程定义的解析是直接对processdefinition.xml文件进行解析，提取其中的元素和属性，生成一套对应的对象，这套对象的结构反映了流程定义的结构。解析流程定义的类为orgjbpmjpdlxmlJpdlXmlReader.java，总体流程如下图所表示。进行流程定义语法校验和解析时，调用的是开源XML解析包dom4j。下面一一介绍各个部分的详细解析过程。图4.1 JPDL流程定义解析总体流程4.1 解析泳道（Swimlane）泳道解析调用函数readSwimlanes(root)，其中root是经过dom4j解析后生成的doc树根，函数声明如下：protected void readSwimlanes(Element processDefinitionElement)该函数获取processDefinitionElement中的所有swimlane元素，按下图中的流程解析，生成对应的对象。从下面的解析流程图中可以看出，泳道的表达式分配使用的委托程序属于identity包，这个包是独立于引擎核心的。如果不使用identity包就无法使用表达式分配。图4.2 JPDL泳道解析流程图4.2 解析动作（Action）jbpm-jpdl.jar包中的org/jbpm/graph/action/action.types.xml文件定义了5种默认Action类型和对应的处理类： JBPM处理的时候使用一个Map types = new HashMap()来保存Action类型和对应的处理类。解析动作调用函数readActions(root, null, null)，函数声明如下：public void readActions(Element eventElement, GraphElement graphElement, String eventType)该函数获取eventElement中的所有元素，按下图中的流程解析。图4.3 JPDL动作解析流程图4.3 解析事件（Event）解析事件调用函数readEvents(root, processDefinition)，函数声明如下：protected void readEvents(Element parentElement, GraphElement graphElement)该函数获取parentElement中的所有event元素，按下图中的流程解析。图4.4 JPDL事件解析流程图4.4 解析节点（Node）解析节点调用函数readNodes(root, processDefinition)，函数声明如下：public void readNodes(Element element, NodeCollection nodeCollection)该函数获取eventElement中的所有元素，按下图中的流程解析。图4.5 JPDL节点解析流程图下图是对节点的定时器(Timer)元素的解析过程：图4.6 节点定时器解析流程图4.5 解析异常处理器（ExceptionHandler）解析异常处理器调用函数readExceptionHandlers(root, processDefinition)，函数声明如下：protected void readExceptionHandlers(Element graphElementElement, GraphElement graphElement)该函数获取graphElementElement中的所有exception-handler元素，按下图中的流程解析。图4.7 异常处理器解析流程图4.6 解析任务（Task）解析任务调用函数readTasks(root, null)，函数声明如下：public void readTasks(Element element, TaskNode taskNode)该函数获取element中的所有task元素，按下图中的流程解析。该解析函数是流程解析中最复杂也是最重要的函数，不仅在流程根节点的任务解析中用到，更主要是的在TaskNoe节点的解析中使用。图4.8 JPDL任务解析流程图图4.9 readTaskTimers流程图图4.10 Task任务分配解析流程图图4.11 Task任务通知解析流程图图4.12 Task任务变量解析流程图4.7 解析变迁（Transition）解析任务调用函数resolveTransitionDestinations()，该函数对节点解析过程中最后一步生成的未解析变迁列表进行操作。列表中的元素以Object nodeElement, node的形式成对出现，每对占List中的一个位置。解析时逐对取出未解析的变迁，调用resolveTransitionDestinations(nodeElement.elements(transition),node)，该函数再对每个变迁元素调用resolveTransitionDestination(transitionElement, node)函数进行解析。下面的流程图显示resolveTransitionDestination的流程。图4.13 JPDL变迁解析流程图4.8 匹配引用动作（actionReferences）引用动作的匹配是对Acion解析过程中未做处理的的ref-name类型的动作进行匹配，未处理引用动作列表以成对的new Object actionElement, action 形式保存在一个List中。匹配函数为resolveActionReferences()，对于列表中的每个对，做下面流程中的处理：图4.14 JPDL匹配引用动作流程图4.9 泳道人员选派验证（verifySwimlaneAssignments）泳道人员选派验证是对任务管理定义中的泳道逐个检查其是否能够在流程实例运行时执行人员选派操作。图4.15 JPDL泳道人员选派验证流程图5.JBPM流程实例调度机制分析5.1 流程实例推进机制JBPM的流程实例调度借鉴了Petri网的思想，采用与token类似的execution标示使能节点，用execution的转移表示流程的推进。为了统一思想，我们还是用token这个词。流程启动时，JBPM根据流程定义实例化一个流程，并在流程实例的开始节点放置一个根token。流程实例的推进有两种方式：一是强制执行流程实例的signal操作，二是执行任务实例的end操作。这两个操作实际上都是通过当前token的signal操作来实现的，如下图所示：图5.1 流程实例的推进方式Token的signal操作表示：实例需要离开当前token所在的节点，转移到下一个节点。因为节点间是通过变迁连接的，在转移过程中会把token放入相应的变迁中，由变迁把token传递给下一个节点。JBPM还提供了一个执行上下文对象(ExecutionContext)来维护当前token运行环境信息，可以把ExecutionContext看做一个token，因为其主要对象就是token。signal操作实际调用的是token所在节点的leave操作，leave操作的的参数为当前执行上下文和出向变迁。出向变迁通过执行上下文获取token，并将token传递到出向变迁指向的节点。最后执行所在节点的下图展示了token传递的流程。图5.2 token传递的流程简单的看，流程实例的推进就是按顺序执行以下函数：Token.signal(Transition) /将Token封装到ExecutionContext中 Node.leave(ExecutionContext,Transition) /ExecutionContext离开当前节点 Transition.take(ExecutionContext) /ExecutionContext传递到变迁 Node.enter(ExecutionContext) /ExecutionContext到达下一节点 Node.execute(ExecutionContext) /执行下一节点对于并行流程，当流转到并行分支（fork）节点时，token停留在fork节点，作为父token。同时，按分支数生成对应个数的子token，子token仍按照上述规则推进。token的父子结构形成了一个token树。当子token到达汇聚（join）节点时，子token结束并等待其他子token的到达。当所有子token都到达汇聚节点后，父token直接跳转到汇聚节点，并继续推进。实际上JBPM把Petri网的库所和变迁合并表示到了一个JBPM节点，下图展示了JBPM流程定义图和Petri网间的对照。executiontoken 图5.3. JBPM流程定义图和Petri网对照5.2资源分配机制JBPM采用TaskMgmtDefinition扩展过程定义，该对象包含了流程定义中的泳道和任务的列表，实现了任务管理的定义。在流程实例生成ProcessInstance对象的同时，也生成一个TaskMgmtInstance对象，该对象包含流程实例的泳道实例映射表和任务实例集合。当Token转移到一个Task Node时，执行该Task Node的execute方法，该方法调用TaskMgntInstance的createTaskInstance方法，该方法实例化Task Node下的任务对象，接着调用TaskInstance的assign方法。assign根据输入参数，调用不同的分配委托解析输入的参数，设置TaskInstance的Actor或PooledActors。图5.4 JBPM资源分配流程5.3 JBPM的event-action机制JBPM中大量采用了事件动作（event-action）机制，例如：token的signal操作就依次尝试触发(fire)以下事件： EVENTTYPE_BEFORE_SIGNAL EVENTTYPE_NODE_LEAVE EVENTTYPE_SUPERSTATE_LEAVE EVENTTYPE_TRANSITION EVENTTYPE_SUPERSTATE_ENTER EVENTTYPE_NODE_ENTER EVENTTYPE_AFTER_SIGNAL事件和动作间是一对多的关系，事件表示触发某个或某些动作的条件，动作是一段java代码。JBPM在流程解析时，将事件和动作进行关联，再绑定到特点的图形元素（流程定义、节点、变迁等）上。在流程运行的不同时期、不同位置，触发特定的事件执行关联的动作。JBPM提供这些动作的底层接口，而开发者可以根据这个接口，来实现具体的执行体。org.jbpm.graph.def包里的Event.java类定义了JBPM支持的16个事件类型，如下所示。如果用户要自定义事件类型，则必须修改JBPM的原代码，添加相应的处理。public static final String EVENTTYPE_TRANSITION = transition;public static final String EVENTTYPE_BEFORE_SIGNAL = before-signal;public static final String EVENTTYPE_AFTER_SIGNAL = after-signal;public static final String EVENTTYPE_PROCESS_START = process-start;public static final String EVENTTYPE_PROCESS_END = process-end;public static final String EVENTTYPE_NODE_ENTER = node-enter;public static final String EVENTTYPE_NODE_LEAVE = node-leave;public static final String EVENTTYPE_SUPERSTATE_ENTER = superstate-enter;public static final String EVENTTYPE_SUPERSTATE_LEAVE = superstate-leave;public static final String EVENTTYPE_SUBPROCESS_CREATED = subprocess-created;public static final String EVENTTYPE_SUBPROCESS_END = subprocess-end;public static final String EVENTTYPE_TASK_CREATE = task-create;public static final String EVENTTYPE_TASK_ASSIGN = task-assign;public static final String EVENTTYPE_TASK_START = task-start;public static final String EVENTTYPE_TASK_END = task-end;public static final String EVENTTYPE_TIMER = timer;6.JBPM工作流模式支持6.1 过程模式支持在43种工作流过程模式中，JBPM完全支持的有13种，下面举例介绍这些支持的模式：1、Sequence模式：使用一个变迁连接两个单独的任务节点就形成了顺序模式。下图展示了“客户输入订单后，开始审核订单”的Sequence模式。图6.1 Sequence模式2、Parallel Split模式： JBPM中有两种表达Parallel Split模式的方法，一是显示表达：用Fork节点进行过程分支，每个分支可以有一个或多个任务；二是隐式表达：用一个包含多个任务的任务节点表达，适用与每个分支只有一个任务情况。下图展示了“客户付款后，开发票和打包的活动可以并行执行”的并行模式。图6.2 Parallel Split模式3、Synchronization模式： JBPM中有两种表达Synchronization模式的方法，一是显示表达：用Join节点进行分支过程同步，每个分支可以有一个或多个任务；二是隐式表达：用一个包含多个任务的任务节点表达，适用与每个分支只有一个任务情况。下图展示了“开发票和打包货后，才能送货”的Synchronization模式。图6.3 Synchronization模式4、Exclusive Choice模式：JBPM中可以通过使用Decision node由程序根据过程变量自动判断选择分支。下图展示了“根据客户选择的送货方式，自动选择快递或平邮方式送货”的Exclusive Choice模式。图6.4 Exclusive Choice模式5、Simple Merge模式：JBPM中可以通过使用有多个入向变迁的Task node表示汇聚。下图展示了“快递或平邮发货后，才能进行客户确认收货”的Simple Merge模式。图6.5 Simple Merge模式6、Multi-Merge模式：当有多个控制流到达一个Task Node时，JBPM可以自动实现Multi-Merge模式。下图展示了“每个配件送达后都要签收”的Multi-Merge模式。图6.6 Multi-Merge模式7、Arbitrary Cycles模式：通过反向变迁可以实现。下图展示了“重复修改，直到订单合格”的Arbitrary Cycles模式。图6.7 Arbitrary Cycles模式8、Implicit Termination模式：没有节点可执行时，JBPM的流程实例自动停止执行。下图展示了JBPM对该模式的支持。图6.8 Implicit Termiantion模式9、Multiple Instances without Synchronization模式：通过Fork节点和循环可以实现。下图展示了“需要采购新配件”的Multiple Instances without Synchronization模式。图6.9 Multiple Instances without Synchronization模式10、Deferred Choice模式：通过有多个出向变迁的Task Node，让用户选择流程实例要走哪个分支实现。下图展示了“根据客户选择的送货方式，手动选择快递或平邮方式送货”的Deferred Choice模式。图6.10 Deferred Choice模式11、Cancel Activity模式：通过在控制台强行删除流程定义或在任务列表中强制结束任务可以实现该模式。下图展示了这两个界面的内容。图6.11 Cancel Activity模式12、Transient Trigger模式：使用JBPM的State node可以支持该模式。下图展示了“等待银行支付系统返回支付成功信息”的Transient Trigger模式。图6.12 Cancel Activity模式13、Generalised AND-Join模式：JBPM的Join Node提供了该模式的语义。下图展示了“付款，开发票且打包后才能发货”的Generalised AND-Join模式。图6.13 Generalised AND-Join模式对于其他30种过程模式，JBPM无法完全支持，但是可以通过在节点增加辅助代码来完全实现或部分实现，有待进一步研究。6.2 数据模式支持流程变量，即用户自定义和输入的业务数据。JBPM支持byte、string、double、long、date这5种基本数据类型，足以满足大多数应用，还支持用户自定义的long和string类型数据。JBPM可以在流程定义中直接定义流程变量(controller)，也可以在任务实例执行过程中根据任务表单或用户代码动态生成流程变量。变量绑定到Token，根Token上的绑定的变量视为流程实例全局变量。每个流程实例有一个对应的ContextInstance，用于维护该流程实例中的所有流程变量。ContextInstance维护两个映射表，一个是tokenVariableMaps，用于维护变量和Token的映射表的映射表；一个是transientVariables，用于临时变量名和数据的映射表。根Token绑定的变量作为流程全局变量。每个变量实例对应一个VariableInstance对象，每个对象对应JBPM_VARIABLEINSTANCE表中的一条记录。这样给系统带来了很大的灵活性，用户可以动态的插入和删除流程变量。但是也给流程实例的数据统计带来了一定的困难。JBPM完全支持的数据模式有5种，部分支持的数据模式有6种，下表对这些模式的支持情况进行了总结。模式支持说明Task Data部分由于JBPM的流程变量和任务变量之间是一一对应的关系，从这个角度上不支持该模式；但是，节点允许执行java代码，代码中又可以使用局部变量。Case Data完全JBPM支持的典型数据模式，所有变量都是全局可访问的。Enviroment Data部分JBPM不直接支持外部环境中的数据，但是用户可以通过编写Java代码来访问外部资源或服务来访问外部数据。Task to Task完全JBPM通过全局变量实现任务间的数据交互。Case to Case部分JBPM不直接支持实例间的数据交互，但是可以通过编写自己的Java代码，让所有实例访问同一个数据共享区来实现Task to Enviromnet- push-Oriented部分JBPM不直接支持该模式，但是，通过在任务节点的完成事件或出口变迁上绑定相应的Java代码，可以实现任务变量到外部环境的写操作。Environment to Task - Pull-Oriented部分JBPM不直接支持该模式，但是，通过编写Java代码调用外部API或服务，可以实现从外部环境获得任务变量Data Transfer - Copy In/Copy Out完全JBPM在执行一个工作项时，从流程实例的全局变量从选取需要的变量，复制一份到当前工作项，工作项完成后再把变量写回全局变量中去。Data Transformation - Input完全通过在任务节点的node-enter事件上编写数据转化脚本可以实现Data Transformation - Output完全通过在任务节点的node-leave事件上编写数据转化脚本可以实现Data-Based Routing部分通过Decision node可以实现Exclusive Choice的Data-Based Routing模式，但是不支持Multi-Choice的Data-Based Routing模式表6.1 JBPM数据模式支持6.3资源/组织模式支持JBPM提供了一个默认的企业组织模型，如下图所示。用户(User)代表一个具体用户或服务，组(Group)是用户的集合，关系(Membership)描述的了组和组以及用户和组之间的从属关系，权限(Permission)还未具体实现。为了保持最大的灵活性，该组织模型独立于JBPM核心引擎之外，JBPM仅通过actorID来识别用户和分配任务。这样，用户可以不使用默认组织模型，而是采用自己定义的组织模型。图6.14 JBPM默认企业组织模型JBPM中的组分为两种类型：安全组（security-role）负责权限的校验，组织组（organisation）负责组织管理。通常我们可以给每个部门建立一个组织组，对复杂企业还可以使用组织组的嵌套实现组织的层次关系模型。在组织内，使用安全组给不同级别的用户定义不同的系统访问权限。JBPM的默认的安全组分为3个级别：user、manager和admin。WEB-INF目录下的perties文件定义了安全组的访问权限，通过在xhtml页面文件使用ga:checkRole标签校验对应的安全组即可实现粗粒度的访问控制。如果需要实现新的安全策略（如，增加一个新的安全组），则需要重新配置perties文件并修改所有涉及到的xhtml页面。下面的代码表示只有manager和admin安全组的用户才能访问发布流程页面菜单。perties文件片段depolyproc.xhtml页面文件片段cess.deploy=manager,admin 下面是添加一个普通用户zhougz的操作，主要分为增加用户和配置安全组2个阶段： 使用manager登录系统 点Identities菜单切换到用户管理页面 点Add a new user链接打开添加用户界面 输入用户名zhougz，密码123456，Email地址，提交。 系统自动切换到Uers列表界面，我们可以看到用户zhougz对应的Memberships栏是空的。点击对应的Examine链接，系统切换到Membership页面。 在Add a Membership表的Group Name列输入user，点Add Membership按钮完成操作。通过上面的步骤就添加了一个用户名为zhougz，密码为123456的用户，用户权限为启动流程和查看自己的任务列表（注意退出再登录时，如果发现页面是空白的，要点一下Processes或Tasks菜单）。JBPM实现了资源的“推”模式和“拉模式”分配。分配方式可以分为2类：将资源直接分配到任务；将资源与泳道绑定，再将泳道分配到任务。任务和泳道都继承了Assignale类，其共有的资源分配方式有4种：表达式（expression）分配，通过表达式计算，将任务分配给执行人。个人分配，通过actor_id指定任务的固定执行人；候选人分配，通过pooled_actors指定任务的一组候选人；通过用户自定义的资源分配委托程序实现资源分配，该程序必须实现AssignmentHandler接口。任务比泳道多了一个将任务分配给泳道的资源分配方式。在流程执行过程中，还可以在控制台手工指定任务的执行人。下表对JBPM支持的资源模式进行了分析：模式支持说明Direct Allocation完全在任务中直接使用或表达式可以实现Deferred Allocation完全通过在前驱任务中使用流程变量保存后续任务的执行人ID，然后在后续任务中使用任务分配委托读取该变量并指定任务的执行人实现。（有争议）Retain Familiar完全通过使用可以实现Automatic Execution完全通过在Node node可以实现自动任务Distribution by Offer - Multiple Resources完全通过绑定角色的泳道可以实现，或者使用表达式实现，或者使用实现Distribution by Allocation - Single Resource完全通过绑定单个用户的泳道可以实现，使用，或者使用表达式可以实现Distribution on Enablement完全JBPM中当任务工作项使能时就开始资源分配Resource-Initated Execution - Allocated Work Item完全对于分配的任务，用户可以直接开始执行Selection Autonomy完全用户可以自由选择任务列表中的任意任务开始执行Suspension/Resumption完全JBPM中用户可以挂起和恢复任务表6.2 JBPM资源/组织模式支持7. JBPM常用API接口1、 JbpmConfigurationJbpmConfiguration作为一个配置工厂，提供了JBPM实例的配置信息，默认载入org/jbpm目录下 default.jbpm.cfg.xml文件的配置信息，这些配置信息告诉JBPM如何建立流程执行所需要的服务。使用下面的语句从jbpm.cfg.xml生成一个默认JbpmConfigurationJbpmConfiguration jbpmConfiguration = JbpmConfiguration.getInstance();使用下面的语句生成用户自定义的JbpmConfiguration：String myXmlResource = myjbpm.cfg.xml;JbpmConfiguration jbpmConfiguration = JbpmConfiguration.getInstance(myXmlResource);2、 JbpmContextJbpmContext将JBPM和特定的运行环境隔离，用于支持流程的一些高层操作。实际上都是调用基础类GraphSession 、TaskMgmtSession 、LoggingSession的方法实现的。JbpmContext可以从JbpmConfiguration.createJbpmContext()获得，代码示例如下：JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext(); try ProcessInstance processInstance = . .do your process operations. / in case you update a process object that was not fetched / with a .ForUpdate method, you have to save it. jbpmContext.save(processInstance); finally jbpmContext.close(); 下表列出该类的一些常用API用途函数发布流程定义public void deployProcessDefinition(ProcessDefinition processDefinition)按指定流程定义名生成流程实例public ProcessInstance newProcessInstance (String processDefinitionName)获取当前用户的任务列表public List getTaskList()获取指定用户的任务列表public List getTaskList(String actorId)获取一组用户的工作列表public List g