工作流引擎是否应该建立在有限状态机（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）引擎之上？
还希望大家切磋、指导。

评论

35 楼 fei33423 2017-09-26  

流程引擎的流转比状态机要复杂太多了把. 我觉得你即可以看成平行(流程引擎是复杂版的状态机),也可以看成上下层的关系(流程引擎是基于状态机的,比如每个流程节点都要维护一个状态).

34 楼 c601097836 2016-03-06  

为什么你们都说FSM,而不是UML State machine.

33 楼 ronghao 2014-05-24  

di1984HIT 写道

类似啊，我现在也有这个困惑、

我的工作流新书出版了，欢迎指导：http://book.douban.com/subject/25883177/

32 楼 di1984HIT 2014-05-16  

类似啊，我现在也有这个困惑、

31 楼 itstarting 2009-08-11  

已经放弃FSM了

可能是个人悟性不足还是有偏见，我对FSM的理解和结论是：
１、ＦＳＭ更适合单状态下的复杂状态变迁管理；
２、其概念和应用场景不合适作为工作流的微内核引擎。

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]

29 楼 sht_123 2009-08-07  

??????

28 楼 itstarting 2009-08-06  

andyyehoo 写道

3）大型公司内部用，需要技术亮点压阵

否则就不要了，记住KISS原则，看看Shark的源代码数量和XPDL规范的臃肿,都不是一个真正实用的东西

不幸言中，正在策划研发一个大型系统，工作流作为其中的子系统一并提升。
赞同对XPDL的鄙视，繁琐啰嗦

研究了几天FSM，感觉路子不对，Petri Nets开始有点反感，现在发现可能这才是正道。

OSWorkflow确实很简单，即便“动刀子”也方便，跟我之前的工作流感觉很像，遗憾的是里面有一些“潜规则”，如果要用，肯定得动刀子，另外，维护这产品的人员休假也太长了，版本一直没大动静。

27 楼 itstarting 2009-08-06  

mysyche 写道

建议楼主去买一本<<工作流街管理－模型、方法和系统>>，王建民 等译 清华大学出版社。

谢谢指点，这可是清华的教科书

26 楼 andyyehoo 2009-08-06  

rain2005 写道

做了两年的工作流开发得出的一个结论，当前的工作流产品还不如一个简单的有效状态机，代码简单直观。

同意，osworkflow基本上就是一个基于FSM的微型工作流引擎，扩展性也很不错，可惜很久都没新版本了。

Shark是个典型学院派的作品，JBpm相对好一点，别的不想多说，反正自己中小项目如果有工作流需求，而不需要强悍图形化设计工具的话，osworkflow是最好的选择，不要自己往死胡同钻。除非是：

1）要写论文研究，怕太简单凑不够字数
2）外部项目打标，要忽悠人
3）大型公司内部用，需要技术亮点压阵

否则就不要了，记住KISS原则，看看Shark的源代码数量和XPDL规范的臃肿,都不是一个真正实用的东西

25 楼 RCFans 2009-08-05  

我的想法是，在Activity实现有限状态机之外，还对Activity本身进行新活动的业务替换。这个好像是目前的工作流引擎中未采用的一种设计方法。

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怎么处理呢？

（不知道我的理解对不对）

23 楼 ronghao 2009-08-05  

nychen2000 写道

大家可以可以做一下实验，fire workflow流程实例中的复杂分支和汇聚在jbpm4中是无法实现的。例如：jbpm4的decision分支只能多选1；而fire workflow可以多选一、多选多，任意组合。

再例如：jbpm4的Fork和jion必须互相配合，就像程序语言中的括号必须配对一样。而Fire workflow没有这个要求，Synchronizer智能地处理一切分支汇聚。

严重误导！当前PVM实现多选多是没有问题的(需要扩展)，但多个Fork对应一个Join一点问题没有.

22 楼 mysyche 2009-08-05  

今年来我也用空闲时间，写个简单的工作流（还末完成），算是对这几年来，自己对工作认识的总结吧。我是比较赞同nychen2000 的说法。建议楼主去买一本<<工作流街管理－模型、方法和系统>>，王建民 等译 清华大学出版社。

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的大作，希望有所启示

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智能地处理一切分支汇聚。

为什么会出现这样的差异？关键是工作流模型、算法和设计不一样。。。

19 楼 itstarting 2009-08-05  

我们是关心业务状态，但是我们需要工作流引擎，这是两回事吧

FSM是工作流引擎的微内核，这两者应该不是互斥关系，就好比Apache pluto与Apache Jetspeed2，前者是Portlet容器，后者才是真正的Portal。

18 楼 rain2005 2009-08-05  

会议申请-会议审批-会议室安排-会议纪要-结束才是真正的业务状态，这才是我们需要关心的，我不清楚你为什么需要这个流程的状态，我认为这个是与有限状态机完全没有关系的一个东东。

有了有效状态机，就不用在考虑什么工作流引擎了。

17 楼 itstarting 2009-08-05  

rain2005 写道

无法做到业务实体的状态管理，转而实现业务流程的管理。

我们可以举个简单例子来说明几个概念：
比如，会议申请-会议审批-会议室安排-会议纪要-结束

我的看法：
1、业务实体的状态与工作流的状态是两个概念。
   1）业务的状态只有：是否启动、运行中、结束；
   2）流程的状态包括：当前在什么环节（Activity），谁（Participant）在参与，此时出现的实例就包括了:ProcessInstance、ActivityInstance、Workitem；
2、业务要看目前什么状态了，只能看到是否启动、运行中、结束；要进一步看流程状态，则交给工作流引擎来做


此时又回到了原来的话题，FSM到底管什么？
大家可以谈谈自己的看法

16 楼 rain2005 2009-08-05  

为什么当前工作流要维护实例状态，是因为当前工作流目标是做到具体业务无关，无法做到业务实体的状态管理，转而实现业务流程的管理。

以前看到论坛里面有人说 工作流应该是主要复杂业务实体的状态管理，兼具管理流程的功能。