Fire Workflow 模型的设计思想

    XPDL、BPMN、BPEL 的流程模型都有一个共同的特点，就是没有区分模型中的工作流逻辑和业务逻辑。

    业务逻辑是指某个具体的业务操作，例如填写一张表单，调用一个WebService 服务，发送一个消息等等。

    工作流逻辑是指对这些业务逻辑的某种编排方案，例如先执行哪个业务操作，然后执行哪个业务操作，哪些可以并行等等。

FireWorkflow 模型的核心思想是将两种逻辑解偶。

    下面以一个请假流程来讲解一下这两种模型的区别，该业务规则如下：

    首先由请假人提出申请；请假申请提交到部门经理处审批；审批通过后到人力资源部登记备案。（暂且不考虑审批不通过的情况。）

    这个业务用XPDL 建模，其流程图如下。这个流程图和UML 中的活动图差别不大，都是从宏观的抽象的层次描述了业务。我认为这种模型便于分析但是不利于执行。其根源在于流程元素的职责划分不清，在XPDL 中，Activity承担了太多的职责，可以代表一个人工活动，也可以代表一个自动的程序调用，还可以代表一个子流程，还可以是一个复杂的路由等等。

图ii-2-1 XPDLworkflow process

    如果用FPDL 建模，则稍有不同。FPDL 认为一个系统是由工作流子系统和业务子系统构成，流程的执行是实际就是控制权在这两个子系统之间转移。如果用圆圈表示工作流子系统的操作，用方框业表示务子系统的操作。那么请假流程如下图。

图ii-2-2FPDL workflow process

该流程图的执行过程描述如下：

    首先，工作流子系统启动一个新的业务流程实例，然后创建一个新的任务实例——“申请”，并将控制权交给业务子系统，业务子系统等待申请人填写表单。

    申请人完成表单后，控制权再次被交给工作流子系统，由它决定下一步的路由。这个工作是由称为Synchronizer 的元素完成的(图中标有"S" 的圆圈)。在这个业务示例中，它通过计算得出下一步操作是“部门经理审批”。于是创建一个名字叫做“部门经理审批”的任务实例，并将控制权交给业务子系统，业务子系统等待部门经理做审批操作。

    部门经理完成后，控制权又被转移到工作流子系统，由工作流子系统决定下一步，如此反复直到流程实例终结。

    上图转换成一般的FPDL 流程图如下

图ii-2-3FPDLworkflow process-2

    FPDL 似乎把问题复杂化了，实际上不是的，FPDL 把是把职责分解了。在FPDL 中，Activity 代表业务活动，完全不关心工作流如何分支、汇聚等工作，所有的工作流相关的运算全部委托给Synchronizer 处理，由他来决定路由。

    FPDL 这种清晰的职责划分在复杂的流程中体现出强大的优势，例如，把上述案例再丰富一下：如果请假天数不大于3天，则部门经理审批即可；如果大于3天，则必须提交给公司经理审批。

    这个流程用XPDL 建模如下图。在这个图中“部门经理审批Activity ”需要执行分支运算，“人力资源备案Activity ”必须执行汇聚运算。

图ii-2-4

    如果用FPDL 建模，流程图如下。在这个流程图中，各个流程元素的职责更加清晰，代表业务活动的Activity 仅完成与业务相关的操作，分支汇聚等工作流运算由Synchronizer 完成，如图中的S1 和S2 。

图ii-2-5

 

 

 

 

 

 

 

 

 

 

 

 

 

转载于:https://www.cnblogs.com/lwzblog/archive/2010/04/04/1704124.html