Fire workflow工作流模型及引擎架构的进一步思考

写代码写得有点累了，今天写写文章。

    在文档《9_fireflow技术原理》中，我将整个系统从工作流的视角划分为“业务子系统”和“工作流子系统”。用Activity刻画业务子系统的行为，用Synchronizer(包括StartNode和EndNode)刻画工作流子系统的行为，用Token和transition刻画控制权在业务子系统和流程子系统之间的转移和转移路径。

    在工作流内部，按照元素的不同属性可以将元素分成两种类型。一种是映射到PetriNet的“工作流逻辑”元素，例如 Activity,StartNode, Synchronizer,EndNode,Transition；另一种是代“表业务逻辑”的元素，目前就是Task。WorkflowProcess是将二者组织在一起的最高层元素，既包含工作流逻辑元素，又包含业务逻辑元素。

    在预览版本的文档中，各个元素的关系如下图1
图1：WorkflowProcess


    后来在网友的反馈中提到“自行重组业务流程”的问题。如果用图1中的元素去实现业务流程重组是比较麻烦的，例如如下场景：某系统上线后，因业务需求变化，需要从流程中去掉一个环节，运行一段时间后，需求再次发生变化，需要将删除的环节恢复。删除一个环节当然非常简单，但是重新恢复一个环节，则有一点工作量，不但需要重新创建一个Activity,还要创建其中的Task，配置Performer、Form Url等等。

    进一步思考，我认为图1中的Activity和Task的组合关系错误地反映了业务逻辑和工作流逻辑的关系。Task不应该是Activity的组成元素，而是WorkflowProcess的组成元素；Activity仅仅是Task运行的容器，即Activity和Task之间是一种聚合关系，如下图2。这种结构关系使得业务流程重组变得更加简单合理。例如：在上述业务流程重组的案例中，删除一个一个环节仅仅是删除Activity，而不是删除Task；恢复环节是创建一个新的Activity,然后把已经存在的Task“组装”到这个Activity即可。
图2：New WorkflowProcess



   Fire workflow Engine由若干个服务组成，同理，这些服务也按照其职责的特性分成两类。一类服务完成业务相关的逻辑，另一类服务完成工作流流转逻辑。如下图3，红色部分属于工作流逻辑服务，蓝色部分属于业务逻辑服务。
图3：Engine


   我们都认为工作流引擎的内核（Kernel）是整个引擎中最重要的部分。通过网友的反馈我发现这个说法现在要稍作修正，Kernel只是整个工作流引擎最重要的部分之一。很多应用逻辑方面的特性如果从Kernel的角度来来解决，既复杂又不好用。例如：投票式的会签，会签并不要每个参与会签的Actor都完成其工单才能往下流转，只要超过一定百分比的人完成其工单就可以结束任务实例并且往下流转。再例如xman和snowfox2008提到的“并发子流程”（http://www.iteye.com/topic/322174?page=9）的问题。虽然这些问题不是常见的工作流模式，但是这些问题解决得好不好对真实的业务系统来说又是非常重要的。

    在Fire Workflow 1.0的版本中，TaskInstanceManager被视为另一个最重要的服务。TaskInstanceManager除了增强其功能外，大大增强其扩展性，以解决五花八门的业务逻辑需求。TaskInstanceManager的主要作用是管理TaskInstance的生命周期。在新的设计中，TaskInstance生命周期分成3个阶段，create阶段，run阶段和complete阶段。在每个阶段，业务子系统都可以提供相应的插件来控制TaskInstance的运行，从而达到定制其行为特性的目的。
   
    例如：在预览版本中，只能通过扩展AbstractTaskInstanceManager的public ITaskInstance createTaskInstance(IToken token, Task task, Activity activity)来产生MyBizTaskInstance。然而在很多业务系统中，每个流程都需要有自己的TaskInstance扩展，上述实现方法对这种需求支持的不是很到位。改进之后，每个流程都可以装配自己的TaskInstanceCreator，多个流程也可以共用相同的TaskInstanceCreator，甚至同一个流程的不同的Task都可以有自己私有的TaskInstanceCreator。这样就给业务系统提供了极大的方便性。

    再例如：业务系统可以给特定的SubflowTask装配一个定制的TaskInstanceRunner，该runner可以为子流程创建多个子流程实例，这样就实现了“并发子流程”的需求。而Fire workflow提供的DefaultSubflowTaskInstanceRunner的默认行为是每个子流程仅创建一个子流程实例。

    再例如：业务系统可以给特定的Task装配定制的TaskInstanceCompletionEvaluator，该扩展可以根据任意规则决定TaskInstance是否可以被终结。当然也能够满足“投票式会签”的需求。


    上述设计变更是1.0中最重要的变化，代码还在编写中，设计思路还待进一步验证。

评论

2 楼 凯旋人生 2009-03-25  

支持非也兄，希望fireworkflow越来越成熟。另外老兄一定要注意版本的兼容性啊。

1 楼 bright82 2009-03-22  

我觉得这里应该是提取一个接口自定义参与者,默认参与者可能是环节中定义的,但是可根据业务获取多个参与者,同时根据参与者集合生成多个task实例