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

如果一个状态结点，参与者很多，逻辑很复杂（比如80%的参与者处理后则进入下一结点），就需要用workitem了。
如果有workitem，就肯定需要持久化，因为这是跟人工操作有关的。

状态变迁、过程流转，如果涉及人工结点，就会伴随着workitem的分配、取消、查询计算等操作，但workitem代表的是授给一个人的任务，更贴近业务，与状态机本身无关（所以通常作为外接模块）。

一个流程的流转，可以认为是用token驱动的：一个串发流程在流转过程中，始终只有一个token向下传递，无论那个结点可能有几个参与者。
split-join从一个token生成了多个子token，最终又将其合并。
复杂的流程就是用token树驱动的，而不是workitem驱动。 －－忘了这个观点从哪看来的，是不是与jbpm还是PetriNet有关了，我在工作流的理论上研究的不深。



[color=green]
一个串发流程在流转过程中，始终只有一个token向下传递，无论那个结点可能有几个参与者。

一个结点有多个参与者，也只有一个token，怎么进行驱动的？
基于FSM的引擎也可以用token进行驱动[/green]

已经放弃FSM了

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