1. 应对业务规则的变化
比如常见的员工请假流程：如果低于3天提交部门经理，如果多于3天以上，提交总经理审批。这就是一种流程。按照常规代码处理时：
if days < 3
submit to Department Manager
else if days >=3
submit to CEO或许有人会问，既然我代码可用处理，为什么还要用工作流呢？
1). 主要考虑流程的变化因素不可控，比如，公司出来一项新的政策，说是5天以上总经理才去审批，这个时候，如果通过编码的方式就要改代码了，再重新发布，系统的可扩展性太差；
2). 假如有人说我不去把请假天数硬编码，我放在配置文件里面不就可以了吗？
的确是可以的，主要的好处不用重新发布程序。但是这样做，跟流程相关的规则还是零碎的，分散的，不是完整放在一起的。
3). 我们可以认为办法2)就是工作流的萌芽思想，我们将所有跟业务规则有关，任务办理人员有关，任务数据权限有关的信息全部整合的一个配置文件里（相当于流程定义或配置信息），然后在程序运行时，读取这个配置文件，判断流程的执行流转走向，最终结束。
在流程定义文件中，分支节点上的连线可以用来定义规则，可以举例如下：
<Condition type="Expression">
<ConditionText>
<![CDATA[
askDays < 3
]]>
</ConditionText>
</Condition>2. 维护活动节点的资源
继续看员工请假流程的变化，不仅仅是业务规则发生变化（规定的请假天数），活动节点上的资源也会有变化，假如：公司规定，员工请假时，如果部门主管不在的时候，可以直接发送给HR主管：
if days < 3
submit to (Department Manager || HR Manager)
else if days >=3
submit to CEO从第一点我们总结出，工作流就是把所有跟业务规则有关，任务办理人员有关，任务数据权限有关的信息整合在一个配置文件里。此处角色的变化，同样遵循这个原理，角色作为活动资源，绑定到节点上，可以增加或减少。角色资源在流程文件中的定义如下：
<Performers>
<Performer id="3c917748-6752-4bc6-aea8-b85d40521888"/>
<Performer id="8e54c07d-d424-4186-b86c-cec43019bed0"/>
</Performers>3. 控制活动节点的数据权限
应用系统中，单据数据读取或修改权限非常重要，每一个流程步骤的业务数据处理，都会有明确规定，只有具备相应权限的人员才可以修改数据。其关系可以表示为：{ Node, Role, Field }的三元表达式。
比如在请假流程中，只有员工自己可以在“请假申请”节点上修改请假天数，而后续节点的部门经理则不能修改请假天数。数据权限始终要根据节点位置和角色共同来定义。
总结：
以上是对工作流的基本功能职责做以说明，鉴于加入Wf5项目的人员可能对工作流刚接触，特意描述，完整的流程定义文件可以参考项目中的xml文件。此外，后期我们再继续对工作流模式，引擎原理等再做出解释和说明。