工作流引擎是否应该建立在有限状态机（Finite State Machine, FSM）引擎之上？
最近一直在研究工作流。
工作流的种类：
1、侧重人机交互的工作流，以WFMC规范为重点参考；
2、侧重服务整合和应用自动化的工作流，以BPEL规范为重点参考。
无论哪种，陷进去都是一个坑。我关注前者，研究思路和方法：
1、了解规范：看WFMC的资料，了解5个接口模型，了解XPDL；
2、了解开源产品：研究OSWorkflow（这个我花了些力气，也在整理学习笔记）、Shark、OBE；
3、适度看看当前强大的商用工作流，以ULTIMUS为重点。
研究了几天，总觉得应该工作流应该基于Event-Driven FSM才是引擎的微内核，也更贴近WFMC所描述的概念与状态模型，而Petri Nets总觉得有点怪怪的。
于是又google翻这些资料，得看大师的文章：
http://en.wikipedia.org/wiki/Finite_state_machine
http://en.wikipedia.org/wiki/Event_driven_finite_state_machine
……
也找到了一些java FSM的实现，但还没深入研究。
这时候我想试问一下了：工作流是否应该建立在有限状态机（Finite State Machine, FSM）引擎之上？
还希望大家切磋、指导。 /** * 流程实例（Entry）是否可变更的判断 * @ejb.interface-method */ public boolean canModifyEntryState(long id, int newState) { try { WorkflowStore store = getPersistence(); WorkflowEntry entry = store.findEntry(id); int currentState = entry.getState(); boolean result = false; switch (newState) { case WorkflowEntry.COMPLETED: //ACTIVATED->COMPLETED：可以 if (currentState == WorkflowEntry.ACTIVATED) { result = true; } break; case WorkflowEntry.CREATED: //ACTIVATED->CREATED：不可以 result = false; case WorkflowEntry.ACTIVATED: //CREATED->ACTIVATED或SUSPENDED->ACTIVATED：可以 if ((currentState == WorkflowEntry.CREATED) || (currentState == WorkflowEntry.SUSPENDED)) { result = true; } break; case WorkflowEntry.SUSPENDED: //ACTIVATED->SUSPENDED：可以 if (currentState == WorkflowEntry.ACTIVATED) { result = true; } break; case WorkflowEntry.KILLED: //CREATED->KILLED或ACTIVATED->KILLED或SUSPENDED->KILLED：可以 if ((currentState == WorkflowEntry.CREATED) || (currentState == WorkflowEntry.ACTIVATED) || (currentState == WorkflowEntry.SUSPENDED)) { result = true; } break; default: //默认不可以 result = false; break; } return result; } catch (StoreException e) { log.error("Error checking state modifiable for instance #" + id, e); } return false; }
但是工作流里面有很多实例（ProcessInstance、ActivityIntance、Workitem等）状态，那怎么办呢？ 16 楼 rain2005 2009-08-05 为什么当前工作流要维护实例状态，是因为当前工作流目标是做到具体业务无关，无法做到业务实体的状态管理，转而实现业务流程的管理。
以前看到论坛里面有人说 工作流应该是主要复杂业务实体的状态管理，兼具管理流程的功能。 17 楼 itstarting 2009-08-05 rain2005 写道无法做到业务实体的状态管理，转而实现业务流程的管理。
我们可以举个简单例子来说明几个概念：
比如，会议申请-会议审批-会议室安排-会议纪要-结束
我的看法：
1、业务实体的状态与工作流的状态是两个概念。
1）业务的状态只有：是否启动、运行中、结束；
2）流程的状态包括：当前在什么环节（Activity），谁（Participant）在参与，此时出现的实例就包括了:ProcessInstance、ActivityInstance、Workitem；
2、业务要看目前什么状态了，只能看到是否启动、运行中、结束；要进一步看流程状态，则交给工作流引擎来做
此时又回到了原来的话题，FSM到底管什么？
大家可以谈谈自己的看法 18 楼 rain2005 2009-08-05 会议申请-会议审批-会议室安排-会议纪要-结束才是真正的业务状态，这才是我们需要关心的，我不清楚你为什么需要这个流程的状态，我认为这个是与有限状态机完全没有关系的一个东东。
有了有效状态机，就不用在考虑什么工作流引擎了。 19 楼 itstarting 2009-08-05 我们是关心业务状态，但是我们需要工作流引擎，这是两回事吧
FSM是工作流引擎的微内核，这两者应该不是互斥关系，就好比Apache pluto与Apache Jetspeed2，前者是Portlet容器，后者才是真正的Portal。 20 楼 nychen2000 2009-08-05 我认为用FSM描述工作流引擎不适合。
状态机主要描述一个对象的状态及其转换规则，通常我们把要用FSM描述的“对象”设定为流程图中的环节，然而工作流通常并不是只有一个环节，而是由多个环节互相影象和制约。
我认为很难用状态机的规则来刻画汇聚环节如何进入“起始状态(Initialized)”，即复杂汇聚的实现用FSM是无能为力的。
所以，我认为用PetriNet来建模工作流引擎更适合。具体请参阅我的拙作Fire workflow，附有文档《Fire workflow工作流原理、设计与应用》。
我最近重新从头研究了一便jbpm4及其pvm，总体感觉pvm的设计并不好，像较与Fire workflow的微内核设计逊色很多。我计划写一系列的帖子从理论、模型、设计等各方面比较一下这两个产品。
大家可以可以做一下实验，fire workflow流程实例中的复杂分支和汇聚在jbpm4中是无法实现的。例如：jbpm4的decision分支只能多选1；而fire workflow可以多选一、多选多，任意组合。
再例如：jbpm4的Fork和jion必须互相配合，就像程序语言中的括号必须配对一样。而Fire workflow没有这个要求，Synchronizer智能地处理一切分支汇聚。
为什么会出现这样的差异？关键是工作流模型、算法和设计不一样。。。 21 楼 itstarting 2009-08-05 nychen2000 写道我认为用FSM描述工作流引擎不适合。
状态机主要描述一个对象的状态及其转换规则，通常我们把要用FSM描述的“对象”设定为流程图中的环节，然而工作流通常并不是只有一个环节，而是由多个环节互相影象和制约。
我认为很难用状态机的规则来刻画汇聚环节如何进入“起始状态(Initialized)”，即复杂汇聚的实现用FSM是无能为力的。
所以，我认为用PetriNet来建模工作流引擎更适合。具体请参阅我的拙作Fire workflow，附有文档《Fire workflow工作流原理、设计与应用》。
我最近重新从头研究了一便jbpm4及其pvm，总体感觉pvm的设计并不好，像较与Fire workflow的微内核设计逊色很多。我计划写一系列的帖子从理论、模型、设计等各方面比较一下这两个产品。
大家可以可以做一下实验，fire workflow流程实例中的复杂分支和汇聚在jbpm4中是无法实现的。例如：jbpm4的decision分支只能多选1；而fire workflow可以多选一、多选多，任意组合。
再例如：jbpm4的Fork和jion必须互相配合，就像程序语言中的括号必须配对一样。而Fire workflow没有这个要求，Synchronizer智能地处理一切分支汇聚。
为什么会出现这样的差异？关键是工作流模型、算法和设计不一样。。。
JBPM没太多研究，没有发言权
FSM实现聚合JOIN和分支FORK其实也没什么难的，无非是有些逻辑需要判断，结合OR/XOR/AND等综合考虑
但我也是越来越觉得FSM更适合描述单实例状态转换，确实不适合并行多实例多状态的场景
正在拜读nychen2000的大作，希望有所启示 22 楼 mysyche 2009-08-05 今年来我也用空闲时间，写个简单的工作流（还末完成），算是对这几年来，自己对工作认识的总结吧。我是比较赞同nychen2000 的说法。建议楼主去买一本<<工作流街管理－模型、方法和系统>>，王建民 等译 清华大学出版社。 23 楼 ronghao 2009-08-05 nychen2000 写道
大家可以可以做一下实验，fire workflow流程实例中的复杂分支和汇聚在jbpm4中是无法实现的。例如：jbpm4的decision分支只能多选1；而fire workflow可以多选一、多选多，任意组合。
再例如：jbpm4的Fork和jion必须互相配合，就像程序语言中的括号必须配对一样。而Fire workflow没有这个要求，Synchronizer智能地处理一切分支汇聚。
严重误导！当前PVM实现多选多是没有问题的(需要扩展)，但多个Fork对应一个Join一点问题没有.
24 楼 nychen2000 2009-08-05 ronghao 写道nychen2000 写道
大家可以可以做一下实验，fire workflow流程实例中的复杂分支和汇聚在jbpm4中是无法实现的。例如：jbpm4的decision分支只能多选1；而fire workflow可以多选一、多选多，任意组合。
再例如：jbpm4的Fork和jion必须互相配合，就像程序语言中的括号必须配对一样。而Fire workflow没有这个要求，Synchronizer智能地处理一切分支汇聚。
严重误导！当前PVM实现多选多是没有问题的(需要扩展)，但多个Fork对应一个Join一点问题没有.
"就像程序语言中的括号必须配对一样",可能这句话表达不严格吧，大家用一用Fork和Join就知道有多么别扭了，呵呵。
Join如何才能实现正确的汇聚呢？在jbpm4中需要指定一个参数(multiplicity)说明有几个execution到达后，join才执行（默认是所有的输入的数量），也就是说设计join的时候必须要考虑前面的Fork的执行状况。如果这个流程在某种状态下join节点到达的execution是2，另一流程实例的状况下到达的Execution是1，那么join怎么处理呢？
（不知道我的理解对不对） 25 楼 RCFans 2009-08-05 我的想法是，在Activity实现有限状态机之外，还对Activity本身进行新活动的业务替换。这个好像是目前的工作流引擎中未采用的一种设计方法。 26 楼 andyyehoo 2009-08-06
rain2005 写道做了两年的工作流开发得出的一个结论，当前的工作流产品还不如一个简单的有效状态机，代码简单直观。
同意，osworkflow基本上就是一个基于FSM的微型工作流引擎，扩展性也很不错，可惜很久都没新版本了。
Shark是个典型学院派的作品，JBpm相对好一点，别的不想多说，反正自己中小项目如果有工作流需求，而不需要强悍图形化设计工具的话，osworkflow是最好的选择，不要自己往死胡同钻。除非是：
1）要写论文研究，怕太简单凑不够字数
2）外部项目打标，要忽悠人
3）大型公司内部用，需要技术亮点压阵
否则就不要了，记住KISS原则，看看Shark的源代码数量和XPDL规范的臃肿,都不是一个真正实用的东西 27 楼 itstarting 2009-08-06 mysyche 写道建议楼主去买一本<<工作流街管理－模型、方法和系统>>，王建民 等译 清华大学出版社。
谢谢指点，这可是清华的教科书 28 楼 itstarting 2009-08-06 andyyehoo 写道
3）大型公司内部用，需要技术亮点压阵
否则就不要了，记住KISS原则，看看Shark的源代码数量和XPDL规范的臃肿,都不是一个真正实用的东西
不幸言中，正在策划研发一个大型系统，工作流作为其中的子系统一并提升。
赞同对XPDL的鄙视，繁琐嗦
研究了几天FSM，感觉路子不对，Petri Nets开始有点反感，现在发现可能这才是正道。
OSWorkflow确实很简单，即便“动刀子”也方便，跟我之前的工作流感觉很像，遗憾的是里面有一些“潜规则”，如果要用，肯定得动刀子，另外，维护这产品的人员休假也太长了，版本一直没大动静。 29 楼 sht_123 2009-08-07 ?????? 30 楼 sht_123 2009-08-07 如果一个状态结点，参与者很多，逻辑很复杂（比如80%的参与者处理后则进入下一结点），就需要用workitem了。
如果有workitem，就肯定需要持久化，因为这是跟人工操作有关的。
状态变迁、过程流转，如果涉及人工结点，就会伴随着workitem的分配、取消、查询计算等操作，但workitem代表的是授给一个人的任务，更贴近业务，与状态机本身无关（所以通常作为外接模块）。
一个流程的流转，可以认为是用token驱动的：一个串发流程在流转过程中，始终只有一个token向下传递，无论那个结点可能有几个参与者。
split-join从一个token生成了多个子token，最终又将其合并。
复杂的流程就是用token树驱动的，而不是workitem驱动。 －－忘了这个观点从哪看来的，是不是与jbpm还是PetriNet有关了，我在工作流的理论上研究的不深。
[color=green]
一个串发流程在流转过程中，始终只有一个token向下传递，无论那个结点可能有几个参与者。
一个结点有多个参与者，也只有一个token，怎么进行驱动的？
基于FSM的引擎也可以用token进行驱动[/green] 31 楼 itstarting 2009-08-11 已经放弃FSM了
可能是个人悟性不足还是有偏见，我对FSM的理解和结论是：
１、ＦＳＭ更适合单状态下的复杂状态变迁管理；
２、其概念和应用场景不合适作为工作流的微内核引擎。