4.用例(购买物品)

　　想象一下你正在在线购物。你已经选择了某项物品，把它放入到购物车中，然后前去结账，给出你的信用卡信息并最终提交购买物品请求(purchase item request)。系统将初始化购买物品流程(Purchase Item process)。

　　先决条件

　　流程必须接收包含物品、账单、配送信息的数据

　　主流程

　　1. 校验物品数量

　　2. 获得贷记授权

　　3. 配送

　　这个流程当前定义了3个活动，如下图所示：　　

　　这个图还显示了不受控制(ungoverned)的活动转移。但实际上，如果物品数量不够会发生什么?“获得贷记授权”活动应该执行吗?“配送”应该随之进行吗?

　　另一个有趣的告诫是：根据条件，贷记授权(credit authorization)可能不会自动完成(授权网络关闭了)，而你或客户服务代表不得不直接打电话给贷记公司以获得认证码。一旦该认证码被获得并输入到系统中，这个流程应该从何处重新开始或继续呢?从头来还是直接进入配送环节?我觉得应该进入配送环节，但是怎样才能做到呢?我们怎么才能从中间重新启动该流程，而不用维护和管理许多执行控制呢?

　　有意思的是，使用AOP我们不需要维护执行控制，也不需要维护流程的流向。它是在通过拦截过滤器链时由框架本身来处理的。我们需要做的一切就是提出一种机制，根据注册事实允许或不允许各个过滤器执行。

　　“校验物品数量”将注册物品数量充足的事实，该事实是“获得贷记授权”的前提。“获得贷记授权”也要注册贷记已授权这一事实，而这又是“配送”活动的前提。存在或缺少事实也将被用来决策何时不执行一个特定活动，这又把我们带回到了“手工贷记审核”场景，怎么才能从中间重新启动流程呢，或者问一个更好的问题： 我们怎样才能重新启动该流程，而不重复该流程上下文中已经执行过的活动?

　　记得吗，共享的数据token(上下文)也代表了流程的状态。这一状态包含了该流程登记的所有事实。这些事实被求值以做出转移决策。因此，在“手工贷记审核”场景中，如果我们从最开始重新提交整个流程，我们的转移管理机制，在遇到第一个活动“校验物品数量”之前，会马上意识到物品数数量充足事实(item available fact)已经注册过了，这个活动不应再次重复，因此，它将跳到下一个活动——“贷记审核”。因为贷记已授权事实也已经注册过了(通过某种手工录入方式)，它将再次跳到下一个活动“配送”，只允许这一活动执行并完成该流程。

　　在我们进入实际例子之前，有一个更重要的话题还要讨论一下，那就是活动被定义的顺序。尽管从一开始好像活动的顺序在(这些活动所定义的)流程转移决策中并不起任何作用。

　　流程中活动的顺序只是代表了流程本身的平衡能力——该策略基于事实的可能性和概率，它们的存在将给下一个活动的执行或不执行创造一个理想的环境。改变活动的顺序永远不应影响整个流程。

　　实例：

　　Legend:

　　d - depends

　　p - produces

　　Process:

　　ProcessContext = A(d-1, 2; p-3) -> B (d-1, 3; p-4, 5) -> C(d-4, 5);

　　按照上面的公式，当流程在给定的ProcessContext内开始时，第一个要考虑的活动是A，在它被调用之前依赖于事实1和2。假定事实1和2存在于 ProcessContext中，活动A将执行并产生事实3。在线上的下一个活动是B，它依赖于事实1和3。我们知道我们的流程在活动A执行之前事实3发生的可能性和概率非常小。可是在活动A被执行之后，事实3存在的可能性和概率则相当高，因此活动B的顺序是跟在A后面。

　　但是如果我们把活动B和A的顺序颠倒一下，会有什么变化?

　　ProcessContext = B (d-1, 3; p-4, 5) -> A(d-1, 2; p-3) -> C(d-4, 5);

　　变化不大。当流程被调用时，维护着事实注册表的ProcessContext将很快断定已注册的事实不足以允许活动B被调用，因此它将跳到下一个活动A。假定事实1和2是存在的，对事实进行评估将确定已注册的事实足以允许调用活动A，等等。活动C也将被跳过，因为它缺少由B产生的先决条件。如果流程再次与同一个的ProcessContext一起被提交，活动B将被调用，因为活动A在流程前一次调用过程中已经注册了活动B所需的事实，满足了B执行的前提条件。活动A将被跳过，因为ProcesContext知道活动A已经做了它的工作。活动C也会被调用，因为活动B已经注册了足够的事实以满足活动C的先决条件。

　　因此，正如你所看到的，变换活动的顺序不会改变流程行为，但可影响流程的自动化特征。