写代码写得有点累了,今天写写文章。
在文档《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中最重要的变化,代码还在编写中,设计思路还待进一步验证。
- 大小: 52.3 KB
- 大小: 44.4 KB
- 大小: 56.1 KB
分享到:
相关推荐
由我们的联盟成员---国内著名的开源工作流项目FireWorkflow的作者非也同志开发的基于pt网的开源工作流系统。。。。。。。。。。
缺乏严密的理论做支撑,工作流模型大多千篇一律地照搬WfMC 的xpdl, b. 因为缺乏理论支撑,所以工作流引擎的算法有点七拼八凑,扩展性也比较差。 c. 没有好的设计器,应用比较困难 最近研究并应用了一下JBoss 的...
Fire Workflow工作流开发程序包
FireWorkflow_3_各种工作流模式的实现整理.pdf
详细介绍了FireWorkflow的设计思想和理论依据,同时对比了现行工作流的优缺点。
99_FireWorkflow工作流原理、设计与应用
FireWorkFlow的Silverlight工作流设计器
Windows Workflow Foundation(以下简称WWF)提供了一个编程框架和工具以开发和执行各种不同的基于工作流的应用程序,比如文档管理、线型的商业应用、贸易单据流程、IT管理、B2B应用以及消费者应用。 有状态的、...
使用Fire-WorkFlow开发的某银行贷款审批流程和某商场送货流程的例子说明书中所有设计到的源代码
workflow 工作流引擎c#版本源码,含数据库
fireworkflow配,操作手册,Fire Workflow由模型,引擎,设计器(包含模拟器)三部分组成,如流程(WorkflowProcess),活动(Activity),转移(Transition),开始节点(startNode),结束节点(EndNode),同步器(Syncharonizer).模型...
Fire Workflow 1.0用户手册
工作流模型分析建模,说明工作流引擎的几种模型; workflow mode v1.1
针对现有工作流模型的分析,主要是根据业务模型的分析。推荐给大家。
fireworkflow集成到myeclipse中 由于给的代码都有ecipse中,换成myeclipse挺不习惯的。弄了一下下,此例是根据fireworkflow官方提供的请假流程代码改的。
WinFrom的Workflow工作流的Hello World简单实例
疯狂workflow工作流高清内容,实时下载,用最好的资源换取几分
Workflow是EBS的基础架构技术之一,系统中大部分流程性的通知和审批控制、账户按规则自动生成都是通过Workflow实现的;R11i之后,模块间的协调,有一小部分也是通过Workflow的Business Event完成的。
WorkFlow工作流配置手册.docWorkFlow工作流配置手册.docWorkFlow工作流配置手册.docWorkFlow工作流配置手册.docWorkFlow工作流配置手册.docWorkFlow工作流配置手册.docWorkFlow工作流配置手册.docWorkFlow工作流配置...