复杂的流程引擎会依赖于“流程实例状态”或“活动实例状态”的约束和变迁来进行处理。之所有有时候我们会把一个流程引擎也叫做“状态机”，很大程度上也是这个原因。

4.4 实例对象与执行环境

　每个一个流程实例，必须维护一套属于自己的“运行环境和数据”，而这则是实例对象的责任了。基本上实例对象会包含如下信息：
　（1） 与流程实例的状态或控制信息
　（2） 与活动实例的状态或控制信息。如果某些引擎不支持活动实例，那么必然会有某些其他实例信息，可以当前节点的状或控制信息。
　（3） 一些临时的“执行”信息，便于引擎针对某种情况进行处理

　5 jbpm，“精简”的开源流程引擎

　好的开源工作流引擎不多，jbpm和osworkflow算是其中两个有特色而且比较容易实际应用的。目前一些国内的中小型流程应用项目，就是在jbpm或osworkflow的基础上扩展实现。jBpm采用了Activity Diagram的模型，而osworkflow则是FSM的模型。

　当然，这仅仅是jbpm3之后的事情。自从被Jboss收购之后，jbpm对早先的2.0构架进行了重组，整个结构完全本着“微内核”的思想进行设计。

　现在这里从技术角度来分析jbpm3的优点，简单罗列几个大家都容易看见的：
　（1） jbpm的模型是采用UML Activity Diagram的语义，所以便于开发人员理解流程。
　（2） jbpm提供了可扩展的Event-Action机制，来辅助活动的扩展处理。
　（3） jbpm提供了灵活的条件表达式机制，来辅助条件解析、脚本计算的处理。
　（4） jbpm提供了可扩展的Task及分配机制，来满足复杂人工活动的处理。
　（5） 借助hibernate的ORM的优势，jbpm能够很容易支持多种数据库。

　当然，还有一些优点，是很多开发人员并不太注意的，比如：
　（1） jbpm的Node机制非常灵活，开发人员可以很容易定制“业务化语义的节点”，并满足运行时候处理的需要。

　有很多灵活的优点，当然也少不了存在一些“局限”。
　（1） 很显然，只能有一个start-state。
　（2） jbpm依靠Token来调度和计算，在同一个时刻中，一个ProcessInstance只允许一个Token对象只存在一个Node中（分支当然用Child Token对象处理）。所以本质上就不支持“multi-instance”模式。
　（3） jbpm作为一款开源的工作流引擎，其更多的是关注“如何辅助你更容易的让流程运行完成”，但是并不记录“流程运行的历史和轨迹”。这一点可能是东西方文化的差异性所在，因为国内的流程应用，比较关注“运行轨迹”。

　至于其他的一些局限，比如不支持“回退”、“跳转”等操作，这也是因为东西方文化的差异所在。西方人认为“往回流转的情况肯定也是一种业务规则所定义，那么肯定可以通过分支或条件来解决”，而东方则把“回退作为一个人性化管理和处理的潜在特点”。所以诸如此类的一些“特定需求”，估计只能通过扩展jbpm来实现了，甚至有时候，简单的扩展是无法解决问题的——正如上一节所说的那样，“引擎的抽象”会影响“引擎的应用”的复杂度支持。

　但是，当你试图修改jbpm代码的时候，你会顾虑jbpm的LGPL协议吗？（很多国内企业从来不考虑这个协议问题，寒）。

6 jBpm流程模型与定义对象

　6.1 首先解决如何形式化描述一个流程的问题

　这里说的“定义流程”并不是说jbpm3中那个基于eclipse plugin的图形化建模工具。而是如何去解决“形式化的描述一个流程”的问题。

　形式化的描述流程并不是一个简单的问题，从上世纪七十开始，人们就在探索用各种各样多的模型来描绘流程：Petri Net, FSM, EPC, Activity Diagram, 以及近来的XPDL MetaModel等等，延伸到如今的BPEL,BPMN,BPMD等等。

　jBpm采用了Activity Diagram的模型语义：其将用Start State、State、Action State（Task Node）、End State、Fork、Join、Decision、Merge、Process State这几个“元素”的组合来描述任何一个流程。其中Action State是Activity Diagram中的标准语义，在jBpm为了便于大家理解和使用，jBpm采用了TaskNode这个语义。

　在WfMC的Workflow Reference Model中，对流程引擎的功能描述，其中就包含一项：解析流程定义。如果想满足这这功能，前提条件就必须有最基本的两个：

　（1） 有一套形式化的描述语言（通常为xml格式）。利用这个描述语言可以描述一个流程的定义。比如WfMC所提出的XPDL这个描述语言。当然，jBpm也有自己的一套，名为jPDL，也是一个xml格式的。
　（2） 有一套对象集可以反映流程的定义模型和结果，一般叫做定义对象。流程引擎就需要把“xml格式的流程定义”解析为一套对象，而这套对象的结构则反映了流程的结构。

　我们暂且不去探讨jPDL那个形式化的xml语言，而把重心放在jBpm那套定义对象中。因为这个定义对象是属于Engine Kernel的一部分。

6.2 抽象的节点（Node）和转移（Transition）

　面向对象的继承性、多态性可以让我们从最抽象的部分来描述对象。那么这套定义对象也需要从最基础的“抽象”说起。
process的本质就是“节点”和“有向弧”，当然你也可以说是Node和Link，或者Node和Transition，或者Activity和Transition等等之类的。jBpm采用的是Node和Transition来表示“节点”和“有向弧”。于是乎，在jbpm中你可以看到这样的结构关系：

 
　对于一个节点来说，从定义角度，其只关心几个事情：
　（1） 这是个什么类型的节点。这个节点可能是start state，也可能是一个task node，或者是一个fork。
　（2） 这个节点的转入Transition和转出Transition。

　可能有的人会说，还需要关心节点的转入转出的类型，比如And Splite或者Xor Join之类。这个并没有错，因为很多流程模型的节点元素需要考虑这个，比如WfMC的XPDL模型。但是jBpm的节点是没有这样的属性的，或者说的更准确些，是Activity Diagram模型的节点没有这样的特性。活动图是采用“Fork”、“Join”这样的节点来解决“分支”问题。

6.3 流程：节点与转移的组合

　仅利用节点和转移的组合，就可以表达一个“过程（Process）”。当然这个流程只能告诉人们“大概的业务过程”，当然不包括很复杂的信息。如下图所示：
 
　这是一张非常标准的“活动图”，如果我们用jbpm的设计器，看看这样一张“流程图”：
 
　不论你如何绘画，改变不了这张图的本质：它就只有两个基本元素：节点和转移。只是有的节点是start-state，有的是task-node，有的是join，有的是end state而已。

6.4 节点的类型和扩展

　我们可以通过定义自己的Node节点对象，来补充jbpm自定的节点对象。只需要extends Node，并重写读写xml的read和write方法，重写负责执行的execute方法，在org/jbpm/graph/node/node.types.xml中配置即可，当然，你可以写的更加复杂，更加业务化的节点。

　7 jBpm的过程调度机制

　7.1 吸纳自Petri Net思想

　jBpm的过程调度机制是吸纳了Petri Net的一些思想。

　jBpm采用Token来表示当前实例运行的位置，也利用token在流程各个点之间的转移来表示流程的推进，如下图所示：

 
　当jbpm试图去启动一个流程的时候，首先是构造一个流程实例，并为此流程实例创建一个Root Token，并把这个Root Token放置在Start Node上。

　以下截取部分代码实现，仅供参考。手头有jbpm3相应开发环境的朋友，可以打开ProcessInstance和Token这两个类。（注：以下所有参考代码，为了突出主题，都已经将实际代码中的event,log等处理删除）

public ProcessInstance( ProcessDefinition processDefinition ) {
this.processDefinition = processDefinition;
this.rootToken = new Token(this);
 

文章出处：http://www.diybl.com/course/3_program/java/javajs/2008325/107306_2.html