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

评论

15 楼 itstarting 2009-08-05  

我仔细研究了OSWorkflow，它确实是在维护Entry的状态

它的Entry就是我们一般意义的ProcessInstance

只是代码比较丑陋而已，可以参考其AbstractWorkflow的相关代码（我适当做了注释）：

    /**
     * 流程实例（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等）状态，那怎么办呢？

14 楼 rain2005 2009-08-05  

我的理解是业务实体的状态，并不是实例（如Workitem）的状态。

13 楼 itstarting 2009-08-05  

rain2005 写道

明白你的意思了，最近也一直想过FSM，我觉得最麻烦的地方就在Transition，里面可能要维护很多状态，if判断来决定下一步状态（当然也可以利用多态写多个子类实现，不过类太多了），不知道你有没有什么思路？

可以考虑实现Condition进行，加以OR/XOR/AND等逻辑进行迁移的判断，毕竟对于迁移，需要考虑的还很多。


我现在有一个疑惑点或说理解不透的地方：FSM是用来管理实例（如Workitem）的状态还是用来构建流程的真实环节（Activity）的整体定义？

12 楼 rain2005 2009-08-05  

itstarting 写道

PVM没看过，得学习了

相对而言，还是比较倾向于自己编写更轻量级的引擎，用开源最怕的就是吃不了兜着走，然后还走不远，这可是有血的教训的。

呵呵，我也是和楼主同样的经历，用公司自己的工作流用得太郁闷了，看了下当前开源工作流也是很麻烦，怎么和系统集成就很麻烦，看了ruby的有限状态机实现才得到的灵感。我的目标是的编码简单，清晰。

11 楼 itstarting 2009-08-05  

PVM没看过，得学习了

相对而言，还是比较倾向于自己编写更轻量级的引擎，用开源最怕的就是吃不了兜着走，然后还走不远，这可是有血的教训的。

10 楼 rain2005 2009-08-05  

itstarting 写道

rain2005 写道

不错，其实工作流就应该是这个样子的。

State为什么还要分3种，没有这个必要把，就是一个单纯的状态，或者可以理解为传统工作引擎的节点

还有就是Transition我觉得fromState(source)就可以了，好像没有必要搞toState(target)吧。

过程状态可以很多（比如很多次审批，但流程还在运行），但起始状态只能是一种（比如命名为“new”或者就是“initial”，类型为initial），而结束状态可以有多种（比如命名为“canclled”或“finished”或“aborted”，类型为terminationState）

但从类型来说，总体就是三种——我的观点


另外，Transition务必是从哪儿到哪儿，肯定得有去处。当然了，这种去处可能是一种JOIN，或者是自动活动（比如自动发邮件），但总归有去处，否则路就断了。

明白你的意思了，最近也一直想过FSM，我觉得最麻烦的地方就在Transition，里面可能要维护很多状态，if判断来决定下一步状态（当然也可以利用多态写多个子类实现，不过类太多了），不知道你有没有什么思路？

9 楼 linliangyi2007 2009-08-05  

楼主的思路也是不错的一种，可以参考jbpm4.0啊，它采用PVM来设计的，个人认为是一个更power的FSM。

8 楼 itstarting 2009-08-05  

rain2005 写道

不错，其实工作流就应该是这个样子的。

State为什么还要分3种，没有这个必要把，就是一个单纯的状态，或者可以理解为传统工作引擎的节点

还有就是Transition我觉得fromState(source)就可以了，好像没有必要搞toState(target)吧。

过程状态可以很多（比如很多次审批，但流程还在运行），但起始状态只能是一种（比如命名为“new”或者就是“initial”，类型为initial），而结束状态可以有多种（比如命名为“canclled”或“finished”或“aborted”，类型为terminationState）

但从类型来说，总体就是三种——我的观点


另外，Transition务必是从哪儿到哪儿，肯定得有去处。当然了，这种去处可能是一种JOIN，或者是自动活动（比如自动发邮件），但总归有去处，否则路就断了。

7 楼 rain2005 2009-08-04  

不错，其实工作流就应该是这个样子的。

State为什么还要分3种，没有这个必要把，就是一个单纯的状态，或者可以理解为传统工作引擎的节点

还有就是Transition我觉得fromState(source)就可以了，好像没有必要搞toState(target)吧。

6 楼 itstarting 2009-08-04  

FSM的组件模型：

说明：
1、核心包括State、Transition、Condition、Action等对象，复杂对象（如基于事件的TriggerCondition）可基于这些基对象进行扩展、变化；
2、Transition通过fromState(source)及toState(target)进行状态的变迁，可能会触发Action；
3、State的类型包括initialState、normalState、terminationState三种。

工作项的StateModel:


下一步关注的重点：FSM适用的具体场景

5 楼 itstarting 2009-07-31  

之前我们的工作流也在维护状态，做transition，但更多时候状态只是一个属性，改变了属性后，通过持久化的此属性进行检索什么的，说难听的，我一直称之为工具，不叫引擎。

现在看了workflow patterns，看了FSM/Petri Net，才真是有点感觉，现在的关键是论证，持续的论证

4 楼 rain2005 2009-07-31  

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

3 楼 itstarting 2009-07-30  

没看到过比较“纯粹”使用FSM的工作流产品，我现在也拿捏不准：如果基于FSM来架构，会是什么样子，会不会遇到难以逾越的困难？

看来又得战死很多脑细胞：）

2 楼 eastone 2009-07-30  

如果我没弄错，工作流引擎就是个有限状态机：）

不知道实现起来是否会遇到麻烦，支持这个做法！

1 楼 itstarting 2009-07-30  

这是jfsm提供的使用FSM来做计算器的demo，代码很强很简洁

package org.jfsm.demo.calculator;

import org.jfsm.core.FSMException;
import org.jfsm.core.FSMInput;
import org.jfsm.core.FSMOutput;
import org.jfsm.core.RetSignal;
import org.jfsm.core.SimpleFSM;
import org.jfsm.core.SimpleFSMContext;

class CalcController {

    static public class CalcContext extends SimpleFSMContext {
        int num1, display;
        char op;

        void calculate() {
            switch (op) {
            case '+':
                num1 += display;
                break;
            case '-':
                num1 -= display;
                break;
            case '*':
                num1 *= display;
                break;
            case '/':
                num1 /= display;
                break;
            default:

            }
            display = num1;
        }

        @Override
        public String toString() {
            return "( num1:" + num1 + ", display:" + display + ", op:" + op + " )";
        }
    }

    static public class CalcInputs extends FSMInput<CalcContext> {
        SignalM<Character> key, digit, op;
        Signal backspace, equals;
    };

    private enum State {
        Init, Num1, Op, Num2
    }

    static class CalcFSM extends SimpleFSM<CalcContext, CalcInputs, FSMOutput> {

        @Override
        protected void build(TransitionMap tm) {
            tm.setInitialState(State.Init);

            tm.putDefault(in.key, null, mhKey);

            tm.put(State.Init, in.digit, State.Num1, mhFirstDigit);
            tm.put(State.Init, in.backspace, State.Init, ehClear);
            tm.put(State.Init, in.op, State.Op, mhOp);
            tm.put(State.Init, in.equals, State.Init, null);

            tm.put(State.Num1, in.digit, State.Num1, mhNumAppend);
            tm.put(State.Num1, in.backspace, State.Num1, ehNumBack);
            tm.put(State.Num1, in.op, State.Op, mhOp);
            tm.put(State.Num1, in.equals, State.Init, null);

            tm.put(State.Op, in.digit, State.Num2, mhFirstDigit);
            tm.put(State.Op, in.backspace, State.Op, ehClear);
            tm.put(State.Op, in.op, State.Op, mhOp);
            tm.put(State.Op, in.equals, State.Init, ehEquals);

            tm.put(State.Num2, in.digit, State.Num2, mhNumAppend);
            tm.put(State.Num2, in.backspace, State.Op, ehNumBack);
            tm.put(State.Num2, in.op, State.Op, mhOpOnNum2);
            tm.put(State.Num2, in.equals, State.Init, ehEquals);
        }

        MH<Character> mhKey = new MH<Character>() {
            public RetSignal handle(CalcContext context, Character key) {

                if (key >= '0' && key <= '9') {
                    return in.digit.asNextSignal(key);
                } else if (key == '+' || key == '-' || key == '*' || key == '/') {
                    return in.op.asNextSignal(key);
                } else if (key == '=')
                    return in.equals;
                else if (key == 'D')
                    return in.backspace;
                else
                    return null;
            }
        };

        EH ehClear = new EH() {
            public RetSignal handle(CalcContext ctx) {
                ctx.display = 0;
                return null;
            }
        };

        MH<Character> mhFirstDigit = new MH<Character>() {
            public RetSignal handle(CalcContext ctx, Character key) {
                ctx.display = 0;
                return in.digit.asNextSignal(key);
            }
        };

        MH<Character> mhNumAppend = new MH<Character>() {
            public RetSignal handle(CalcContext ctx, Character key) {
                ctx.display = ctx.display * 10 + (key - '0');
                return null;
            }
        };

        EH ehNumBack = new EH() {
            public RetSignal handle(CalcContext ctx) {
                ctx.display /= 10;
                return null;
            }
        };

        MH<Character> mhOp = new MH<Character>() {
            public RetSignal handle(CalcContext ctx, Character key) {
                ctx.op = key;
                ctx.num1 = ctx.display;
                return null;
            }
        };

        MH<Character> mhOpOnNum2 = new MH<Character>() {
            public RetSignal handle(CalcContext ctx, Character key) {
                ctx.calculate();
                ctx.op = key;
                return null;
            }
        };

        EH ehEquals = new EH() {
            public RetSignal handle(CalcContext ctx) {
                ctx.calculate();
                return null;
            }
        };

    }

    CalcInputs dispatcher;
    CalcContext ctx;

    public CalcController() throws FSMException {
        dispatcher = new CalcFSM().createInstance().getInput();
        ctx = dispatcher.newContext();
    }

}