2007-10-28

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

关键字: bpm, java, jbpm ,workflow ,工作流, j2ee

作者:胡长城

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

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

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

 

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

 

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

 

       让我下先来看看状态类：

public final class WMActivityInstanceState extends WMObjectState {

   public static final int OPEN_NOTRUNNING_INT = 0;

   public static final int OPEN_SUSPENDED_INT = 1;

}

或者也可以这么表示：

public enum WMActivityInstanceState{

  NOTRUNNIN(0),

  SUSPENDED(1);

  private int code;

  private WMActivityInstanceState(int code){this.code = code;}
  public int getCode(){return this.code}

}

 

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

public class BasicActivityInstance extends BasicAttributedEntity{

private int _state;

    public void setState(int state) {

        _state = state; }

}

或者也可以是

Public void setState(WMActivityInstanceState state)

 

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

 

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

 

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

 

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

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

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

      

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

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

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


评论
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论

jbpm-x
搜索本博客
最近加入圈子
存档
最新评论