none
状态机工作流和工作流持久化的价值在哪里? RRS feed

  • 常规讨论

  • 我学习WF有一两个月了,对于WF中Workflow和其操作对象WorkItem之间的关系比较疑惑。 感觉WF并没有把问题解决到位,只关注了单条流程的处理,没有关注全局。 对于短时的顺序流,问题不明显。但对与状态机流程和需要持久化的流程,这些问题就比较突出了。

    1. 一个WorkItems就要启动一个Workflow的实例,这中做法对于硬件是不是太残酷了?企业级的应用往往有成千上万个活动对象,这不就意味着成千上万个活动工作流实例吗?

    2. 一般的应用系统,都需要通过一个表格,将所有的工作流对象,比如订单列出来。然后在针对不同的订单,进行不同的工作流处理。在列订单的时候,大部分数据不需要启动工作流,就能从订单数据库表中取到。但像状态这样的信息,从哪里取就成问题了。在状态机流程,Workflow并不向WorkItem写入状态信息。要想取得WorkItem的状态信息,要么手工写代码给WorkItems写入状态信息,要么激活工作流势力,读取当前工作流实例的状态信息。
    激活工作流肯定不合适。手工给WorkItem写状态信息呢,就相当于在WF之外又启动一个状态机。两个状态机之间的同步和名称匹配都得手工进行。手工定义的状态名称一般时枚举型,而WF中的状态时字符串。

    3. 同样以上面的系统为例,当用户订单列表中选择某个订单时,如何确定其可用的流程操作,从而显示相应的按钮呢?状态信息还有可能手工写到WorkItem中去。但可用的流程操作,只有激活了相应的工作流实例才能知道。这么以来,当用户通过键盘向上向下键浏览订单时,就会导致非常频繁的工作流实例加载和钝化。

    4. 工作流持久化的意义何在?工作流的持久化的同时,WorkItem也要持久化才行。但WF仅仅保存了Workflow的一些基本状态信息。它既没有自动保存WorkItem,也没有提供一致的接口让开发人员实现WorkItem的保存。开发人员完全需要自己写代码来保存WorkItems。既然如此,与其做工作流的持久化,不如让工作流支持多个切入点。

    其实,不管用不用WF,WorkItem都必须自带状态属性。我理解中的状态机工作流引擎,应当具备如下几个特点:
    1. 工作流状态与WorkItem的状态属性绑定。无论工作流实例存在与否,用户都可以直接,批量的获取WorkItem的状态信息。
    2. 工作流引擎提供与WorkItems无关的状态机上下文服务。你把一个状态传给工作流引擎,它就告诉你下一步可能的操作时什么。
    3. 工作流实例应当与WorkItem分离。


    Welkin Hu
    2009年4月28日 3:34

全部回复

  • Hi,
    1.除了SharePoint中的工作流之外,WF并没有限制你让Workflow和WorkItem一一对应;
    2.在Workflow的每一步操作发生变化时,更新WorkItem的状态信息,这是最简单的解决方式,SharePoint就是这样做的;
    3.用户应该执行什么样的操作是由你来定义的,你完全可以根据WorkItem的状态信息来决定用户可以执行的操作;为什么要在浏览订单的时候加载工作流呢?这就是WF不和WorkItem紧紧捆绑的优势啊。
    4.WF与具体业务无关,自然也与WorkItem无关,WorkItem应该由你来维护。持久化的意义在于将不活动的工作流从内存中卸载。

    Workflow是流程,WorkItem是数据,流程负责数据的流转,而不对数据的内容负责。
    WF正是这样设计的。

    My blog: http://xiaoshatian.cnblogs.com
    2009年4月28日 8:33
    版主
  • 多谢版主的答复。我学习WF时日不多,感觉有很多东西和我原来的理解很不一样。希望能深入探讨一下。
    1. 我现在看到的绝大部分WF的案例和实现,都是一个Workflow Instance处理一个Work Item。在《Pro WF Windows Workflow in dot NET 3.5》一书中的例子也是一一对应的。版主能否提供一些一个Workflow Instance处理多个WorkItems的例子或设计模式。
    2. “在Workflow的每一步操作发生变化时,更新WorkItem的状态信息。”这个操作是很简单,也非常有必要。但这个操作是应该手工写代码去做呢?还是绑定到Workflow的State,由Workflow自动更新?我觉得应该由Workflow自动更新才正确:我既然再WF的设计图中设计好了状态之间的演变关系,为什么还要有我手工些代码切换状态?在WorkItem的枚举状态值和Workflow的文本状态值之间匹配?
    3. 用户可以执行什么样的操作,在定义WF的状态演变关系时就已经定义好了。所以我才期望能从WF中读到这些信息。加入不管WF的状态机,另外写代码判断,岂不意味着我要维护两套状态演变关系。这就是我为什么质疑WF有状态Workflow的原因——不是做不到,而是做多余了。
    4. 对于这个问题,我的疑问是与其做Workflow的持久化,不如让Workflow支持多个进入点:当一个WorkItem进入Workflow的时候,Workflow可根据WorkItem的当前状态等信息,启动相应的Activity。比如一个新的订单就从审批Activity启动,而一个审批后的订单,就从发货Activity启动。
    Welkin Hu
    2009年4月29日 4:07
  • hi,

    1.WF并没有限定为Workflow Instance和WorkItem之间的“硬绑定”,所以你完全可以用一个Workflow Instance去操作多个WorkItem,既然Workflow中可以写代码,那还有什么不能实现的呢?
    2.WF没有提供默认的状态绑定,需要你自己实现。以SharePoint为例,SharePoint提供了一个活动,名为SetSate(非状态机中的SetState),只需要添加此活动,并设置其属性就可以在SharePoint中显示WorkItem的工作流进度了。
    3.WorkItem的状态确实由Workflow决定,但其状态信息却应该由自身去维护。参考现实中的审批流程,想知道状态如何,拿出审批表就可以知道了,而不是去问“流程”,现实中,这个所谓的“流程”是看不见摸不到的。
    4.你还是在把具体的业务需求强加在WF上,WF是一个框架,是一个Foundation,他不和任何业务相关。那么WF怎么去根据你的WorkItem状态启动Activity呢?WF怎么知道WorkItem的状态是什么呢?是Status属性?还是State属性?还是GetStatus方法?还是说WF要提供一个接口来约束WorkItem必须实现的方法?这样一来,又会有人说WF限制太死。其实目前你也完全可以实现你的需求啊,WF的Workflow是支持输入参数的,你把WorkItem的状态当作参数传入Workflow Instance,那么Workfow不就知道如何进行下去了吗?


    My blog: http://xiaoshatian.cnblogs.com
    2009年4月30日 5:41
    版主
  • 我觉得讨论的方向有点偏了。我所提出的问题,并不是说在WF中做不到,而是觉得绝大部分工作都有程序人员手工做了,WF的价值在哪里?据说Activity的封装能提高重用性和可维护性,这些体现在哪里。还有,版主一直再强调Workflow Instance和WorkItems之间没有硬绑定。这是事实,但WF在处理这两者之间的关系的原则是什么呢?我特别想知道一个Workflow Instance处理多个WorkItem的企业级模式是什么样的。


    Welkin Hu
    2009年5月1日 8:47
  • “参考现实中的审批流程,想知道状态如何,拿出审批表就可以知道了”
    这个说法也是对的,但问题在于我不断想知道状态,更想知道它下一步可能演变成什么状态,从而提供相应的Activity命令按钮。这个信息是不是应该从WF的状态机中得到?只有这样,在修改流程时的改动才是最小的。
    “WF怎么知道WorkItem的状态是什么呢?是Status属性?还是State属性?还是GetStatus方法?还是说WF要提供一个接口来约束WorkItem必须实现的方法?”
    这种方法其实完全可行,而且并不会带来额外的限制。解决的办法很多,比如在现有Stateful Workflow的基础上,再扩展一类Acitivty, 强制要求Workitem有Status属性。说实话,我有计划这么做——如果找不到合适的Workflow instance和Workitem分离模式的话。

    Welkin Hu
    2009年5月1日 9:07
  • “WF怎么知道WorkItem的状态是什么呢?是Status属性?还是State属性?还是GetStatus方法?还是说WF要提供一个接口来约束WorkItem必须实现的方法?”
    这种方法其实完全可行,而且并不会带来额外的限制。解决的办法很多,比如在现有Stateful Workflow的基础上,再扩展一类Acitivty, 强制要求Workitem有Status属性。说实话,我有计划这么做——如果找不到合适的Workflow instance和Workitem分离模式的话。

    Welkin Hu

     如果你这样做的话,相当于把Workflow Instance和WorkItem硬绑定了。WF甚至连WorkItem是什么都不知道,更无从谈起WorkItem的属性,WorkItem这个东西,也只有开发人员知道而已。
    My blog: http://xiaoshatian.cnblogs.com
    2009年5月6日 1:10
    版主
  • 多思考些吧,wf是太漂亮了,如果你接触过JAVA,再看wf,你会感觉到微软的牛B的


    xiao
    2009年5月15日 11:50
  • 没明白这句话是什么意思。本人做过六年多的Java,只是觉得WF的设计理念完全不一样。但委实找不到好的企业设计模式。


    Welkin Hu
    2009年5月18日 4:59
  • 我只能说,框架,框架,框架。
    My blog: http://xiaoshatian.cnblogs.com
    2009年5月18日 10:26
    版主
  • 我觉的这样的讨论没有意义。我并不是要全盘否定WF,而是找不到没有良好的State Machine使用模式,这和框架根本是两码事。实话实说,我们现在使用的框架,就是我公司和微软美国的专家一起开发的。微软发布在MSDN上的一些HOL示例,就有一些是从我们这个架构中衍生出来的。复用Workflow的Activity,实现高度灵活的工作流编排,是我们架构中的重要目标之一。目前里面所有的工作流都只用顺序Workflow,根本没有State Machine Workflow的一席之地。
    我是看到明明有State Machine的工作流需求,却没有相应的WF模式,才在这里发贴求解。现在看来是无解呀。


    Welkin Hu
    2009年5月19日 8:19
  • 讨论到此为止吧。.Net Framework 4.0中的WF已经没有状态机这个概念了,换成FlowChart了。暂时我也没兴趣研究WF 4.0。
    Welkin Hu
    2009年5月20日 5:29