工作流活动实例状态转换的两种实现模式分析

今天和同事chelsea 就活动实例状态的实现思路上进行了讨论。我们两个站在了两个不同的角度来看待，这两个不同的角度也正好眼下最为常见到的两种实现思路：

      Chelsea是从状态角度来看待，当然也完全是从state pattern的角度来思考：状态在达到某个状态的时候，会引起或必须引起活动实例执行什么操作。

       而我是从活动实例的角度来考虑，活动实例的状态只是活动实例的一个属性体，是因为什么行为，造成了什么状态的结果。

<!----><o:p> </o:p>

       这两种观点，没有谁对谁错，也没有谁优谁劣，两者是站在不同的角度来分析同一个问题。其实这两种模式在应用中都是很普遍的，也都是能够很好的解决问题的。不过在现有的workflow引擎实现中，基于活动实例的角度是占绝大多数的，比如obe，shark等等。所以我受这个的影响也是比较深的。

<o:p> </o:p>

       先说说基于活动活动实例的角度的思路吧：

<o:p> </o:p>

       让我下先来看看状态类：

public final class WMActivityInstanceState extends WMObjectState {<o:p></o:p>

   public static final int OPEN_NOTRUNNING_INT = 0;<o:p></o:p>

   public static final int OPEN_SUSPENDED_INT = 1;<o:p></o:p>

}<o:p></o:p>

或者也可以这么表示：<o:p></o:p>

public enum WMActivityInstanceState{<o:p></o:p>

  NOTRUNNIN(0),<o:p></o:p>

  SUSPENDED(1);<o:p></o:p>

  private int code;<o:p></o:p>

  private WMActivityInstanceState(int code){this.code = code;}
  public int getCode(){return this.code}<o:p></o:p>

}

<o:p> </o:p>

       对于活动实例来说，状态只是其一个属性而已：

public class BasicActivityInstance extends BasicAttributedEntity{<o:p></o:p>

private int _state;<o:p></o:p>

    public void setState(int state) {<o:p></o:p>

        _state = state; }<o:p></o:p>

}<o:p></o:p>

或者也可以是<o:p></o:p>

Public void setState(WMActivityInstanceState state)

<o:p> </o:p>

       所以，从活动实例的角度来看，状态之间的关系是平行的。你可以在执行完一些初始化的操作之后，将活动实例的状态设置为Initialized：当然这个操作你必须显示的去设置活动实例（当然，你可以用一些Event去处理），比如调用活动实例的setState方法。至于为什么调用这个方法，或者此时设置的状态是对是错，活动实例并不关心。

<o:p> </o:p>

       下面再来说说基于状态角度的思路吧，这个思路大体可以说就是state pattern的应用。

<o:p> </o:p>

       说道这儿，您可以看看这篇文档：从工作流状态机实践中总结状态模式使用心得 。当然如果您对state pattern不是很了解，那么建议你先看看这篇文档：设计模式之state 。<o:p></o:p>

<o:p> </o:p>

       State模式的着眼点就是状态，以状态的变迁影响实例的行为和动作。其实这就是两个不同的抽象体：state和stateOwner，我们可以看到，活动实例对象就表现为stateOwner。<o:p></o:p>

       State模式的依据是状态之间是有有向连接关系的，这有向连接关系其实就是状态的转换规则：A-B-C-D-A。

       激发状态的变迁，是由外界的事件（Event）影响的：这个事件会告知，当前的活动实例状态要从当前状态往下一个状态变迁。而活动实例并不知道下一个状态是什么，这完全是状态对象负责维护和告知的。

      

       至此，我们可以看出来了，两种方式的不同：

第一种方式（基于活动实例），其外界事件是影响到活动实例，或者说在事件中显示的告知活动实例状态从什么变为什么。

       第二种方式（基于实例状态），其外界事件是影响到活动实例状态对象，至于这个状态的下一个状态是什么，时间并不知道，完全由活动状态之间的关系来维护。