今天和同事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;} } |
<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)影响的:这个事件会告知,当前的活动实例状态要从当前状态往下一个状态变迁。而活动实例并不知道下一个状态是什么,这完全是状态对象负责维护和告知的。
至此,我们可以看出来了,两种方式的不同:
第一种方式(基于活动实例),其外界事件是影响到活动实例,或者说在事件中显示的告知活动实例状态从什么变为什么。
第二种方式(基于实例状态),其外界事件是影响到活动实例状态对象,至于这个状态的下一个状态是什么,时间并不知道,完全由活动状态之间的关系来维护。