工作流引擎是否应该建立在有限状态机（Finite State Machine, FSM）引擎之上？

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

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

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

"就像程序语言中的括号必须配对一样",可能这句话表达不严格吧，大家用一用Fork和Join就知道有多么别扭了，呵呵。

Join如何才能实现正确的汇聚呢？在jbpm4中需要指定一个参数(multiplicity)说明有几个execution到达后，join才执行（默认是所有的输入的数量），也就是说设计join的时候必须要考虑前面的Fork的执行状况。如果这个流程在某种状态下join节点到达的execution是2，另一流程实例的状况下到达的Execution是1，那么join怎么处理呢？

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

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

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

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

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

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

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

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

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

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

??????