强大的有限状态机 - state_machine

恩恩,有道理.问个题外话,工作项,是否需要这个概念,以及他的持久化,我现在所做的工作流,条件判断是用系统中的业务模型来做的,状态存放在单独的表里,每次要想cancel,就需要cancel_event.而真正的工作流,是有几个集中放工作流所用的数据的地方的,也就是所谓的payload(workitem),而对于split,需要把workitem做多个clone,然后分给不同的participation.join则是merge这些workitem.而cancel对于真正的工作流应该更简单,只需要从历史表中提取出payload,并且把状态回退就可以了.现在我这个工作流运行的挺好的,就是和真正的工作流不一样,怕以后出问题.请教一下

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

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

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

好吧,看来我们不需要,总共系统中的角色还没5个呢...一个节点,可能有多个参与者,我现在的做法是通过split来生成多个token,然后每个参与者发一个...

80%的参与者这种情况,现在预见的只有一种:voting.我是这么处理的,用split根据UserGroup的概念分出n个token,每个token结束会检查其子节点是否可以结束,而子节点是个join节点,join的条件是80%的token都已经完成,完成后,系统会cancel掉剩余的token.

刑天的工作流看起来是基于petri网原理了

现在碰到要处理状态机的话,我通通ragel

动作可以嵌入到任意变迁中去,可以分进入变迁,任何变迁,离开变迁,可以用差\并\交这些集合操作

功能强大,效率高(编译成各种形式的代码,譬如直接goto,或者table-driven等等)

状态机 顺序图
   两种方式实现的工作流有什么却别？

不错的贴！
建议楼主向更多的人宣传一下状态机的基础理论，想必有很多兄弟在大学里忽视了编译原理这门课的，呵呵

最近刚好在项目中使用了sm(state_machine)
分享一个设置named_scope小技巧：

class Todo < ActiveRecord::Base
  
  state_machine :status, :initial => :uncompleted do
    event :complete do
      transition :uncompleted => :completed
    end

    event :uncomplete do
      transition :completed => :uncompleted
    end

    # setup named scope with status, for exammple: Todo.completed.count, equals Todo.with_status(:completed).count
    states.each do |state|
      owner_class.named_scope state.name, :conditions=> {attribute  => state.name.to_s}
    end

  end
 
end

看了状态机才知道现在的工作流把概念完全给扭曲了，工作流就是控制流程变迁的，根本没有引入状态的概念，其实我们真正需要的就是一个有限状态机而已。

工作流喜欢用节点替换状态机的状态概念

而且我一直认为工作流应该是与具体业务模型相关联的，状态机提供了最自然的解决方式。good job！