摘要
工作流可用于解决业务问题。这里，我们将了解和研究在工作流平台上构建应用程序的思想。工作流平台支持主要工作流概念，并且为使用这些概念构建结构化应用
程序（包括迄今为止所了解的工作流产品）提供了基础。我们将考察一系列应用程序，以探讨工作流平台的必要特征，进而论述在工作流平台上构建应用程序的潜在
好处。我们还要讨论
Windows Workflow
Foundation，它是在实践中实现这些好处的手段。
工作流的概念已经存在很长时间了，作为解决业务问题的一种方法，它一直很让人感兴趣。作为工作流方法应用对象的问题通常表现出下列三个特点：所提供的关键
业务价值是“协作”，例如，组织多份稿件以准备报价书或者推动文档审阅。有关的每个业务流程实例都是“长期”的，经常以天、星期或月而不是分钟为度量单
位。业务流程中具有“人力”参与者，通常人力的贡献占工作成果的大部分。
然而，在具有这些特点的业务问题中，只有一小部分是使用工作流方法解决的。更常见的情况是，业务流程根本没有被记录为可机读的信息。相反，参与业务流程的
每个人都是在与不了解业务流程整体语义的业务系统（如客户信息系统）交互，并且通过与内容无关的通信渠道（如电子邮件）与其他人力参与者交互。每个人力参
与者都按照他在整体业务流程中的角色心理模型来确定他们的行为。
创建业务流程（即工作流）的可机读模型的吸引力并不难以想象。工作流模型可以带来的三个主要优点为洞察力、监视和优化。可以使用一组相关的工作流模型来获
取对经过组织的工作流的“洞察力”。对于“监视”，当试图了解成本和工作量时，了解哪些人为哪个业务流程工作是非常有用的。
对于“优化”，拥有正在实施的工作的模型，并且能够使用该模型来解释行为，将两者结合起来就可以推导出如何优化业务流程。
工作流模型
既然有这些引人注目的优点，那么为什么工作流模型没有得到更广泛的使用呢？最有可能的原因是使用它们的成本过高。这些成本包括：“产品”成本，即购买工作
流产品的直接成本；“集成”成本，其中，建模成工作流的过程需要集成为较大业务系统的一部分；“标准化”成本，其中，大型组织很难在单个工作流技术基础上
进行标准化。工作流产品的变化还带来了技能和模型可移植性的问题。
让我们考察一下通过在这样一种工作流平台上构建应用程序来解决这些障碍的可能性：该工作流平台的特点是低成本、使用广泛、统一并且易于集成到应用程序中。
请弄清楚，我们的想法不是要取代工作流产品。相反，本文假设将对一些核心工作流概念的支持分解到一个既可以构建工作流产品又可以构建其他应用程序的平台中
的做法是有用的（参见图
1）。
工作流是一个“模型”，这表示它是一个可机读的、非代码的业务行为说明。稍后，本文将以工作流平台的价值为背景讨论此概念的含义和
好处。
工作流模型描述“工作单元”的组织。例如，假设文档审阅流程指定由Joe
撰写该文档，然后由 Fred
进行审阅。这里，第一个工作单元是撰写文档，第二个工作单元是审阅文档，其组织是一个任务必须跟在另一个任务的后面。此概念并非一个不同寻常的想法。对两个子例程进行连续调用的代码就是此概念的一个令人信服的示例。我们的兴趣在于此组织所采取的形式。
为测试工作流平台假说，我们将考虑一系列实际应用程序，以探究一个行之有效的工作流平台所应具备的特点。
“文档审阅”流程以一组 [审阅者, 角色]
对作为输入参数，该值对描述了工作流所涉及的人员及其角色。角色的可能值为：必需、可选、最终审批者和所有者。然后，审阅流程继续进行，直到所有审阅者都履行了分配给他们的角色并且将结果通知了所有者。
这里，工作项目是由审阅流程组织的文档审阅。有三个应该重点强调的有趣的特点，即：多个交互点、人力和自动化活动以及需要处理动态更改。
工作流协定
工作流具有多个交互点，即协定。首先，存在与审阅者之间的协定。此协定涉及请求审阅者审阅文档、接受裁定意见以及任何审阅批注；如果审阅被取消，或者已有
足够的审阅者投票通过，还要通知审阅者不再需要输入意见。协定还可能允许审阅者委托审阅。这时与最终的审批者之间就存在另一份协定，它是审阅者协定的特殊
化形式。第三，存在一个与审阅的所有者之间的协定，该协定允许所有者取消审阅以及得到审阅的结果。最后，存在一个与审阅流程的发起人之间的协定，发起人对
审阅进行实例化并提供所需的参数。
通过各种协定连接多个参与方是工作流的典型特点（参见图
2）。文档审阅工作流在本质上是一个协调程序，它通过一个协定启动，并通过一个或多个其他协定对各种参与者进行协调。
“文档审阅”工作流驱动人力活动。但是，它也可以驱动自动化的活动，如随着审阅的进行，在储存库中存储文档的各个版本。从工作流角度来看，不存在本质的不
同。通常，可以将工作流视为通过协定与服务之间的通信。服务的一个特例是另一个工作流。另外一个特例是人力。在许多方面，人力是原始的异步服务：人们永远
不知道人力何时或者是否会响应。
这种类型的工作流的一个特点是：参与者在执行过程中可能会要求对工作流进行更改。例如，审阅者可能将审阅任务委托给同事，或者与下属分担审阅任务中涉及的工作。
有两种办法可以满足这一要求。一种办法是在工作流的构建过程中考虑到所有可能发生的更改情形。此时，委托请求只是工作流与审阅者之间的另一个协定函数。另
外一种可能是将更改看作是从工作流分离出来的东西，更改是作为更改工作流模型的外部函数实现的。在此方法中，委托的结果是构建一个新的工作流模型，该模型
与一开始就将审阅任务分配给代理时的模型相同。
要求额外的审批步骤时会向工作流模型中添加一个新的审批任务，工作流模型的原始形式可能根本不包含任何审批步骤。工作流不再必须预料
所有可能的修改；它最多只牵涉到限制模型的可更改范围。
这两种方法都有用。在构建工作流的过程中考虑各种变化的方法易于建模和理解。因为要概括各种操作，这使得建模过程更加复杂，但是模型
更加强大和灵活。
在后一种方法的一种极端而有趣的情况中，工作流开始执行时仅有一点内容甚至没有内容，并且由参与者在工作流中动态添加所需的行为。这
里，可用于修改工作流的操作成为一个词汇表，用户可以随着工作流的进行用它来构建所需的行为。
问题 —
解决协作
为了考察“问题 —
解决协作”应用程序的特定示例，请考虑一个库存不足的情况。一条装配线正在制作一个小配件，计算机指示有足够的库存小部件可供使用。但是，当仓库管理人员去取小部件以将其传送到装配线时，发现缺少
10 个部件。
需要仓库管理人员、客户帐户管理人员、供应部门以及生产经理协作来解决该问题。协作中的每一个角色都可能采取特有的操作。供应部门可
以订购更多的小部件，并且或许通过从不同的供应商进货，或者向现有供应商多付款来加快货物的传送。帐户管理人员可以与客户沟通，请求延迟交货，或者分两批
交货并承担额外的运输费用。生产经理可以挪用其他客户订单中的小配件。仓库管理人员可以搜索他或她的实际库存，尝试找到丢失的小部件。任何给定的操作都可
能被执行多次。
一个很明显的约束是只有通过上述操作的某种组合解决短缺问题后，协作才算完成。业务约束也经常存在。例如，可能有绝不允许推迟向黄金级客户交货的时间这样
的规则。而且，操作将对双方都造成影响。例如，可能有一个策略规定，纠正操作所增加的总成本不能超过原出厂成本的百分之五。因此，以更高的价格下订单以加
速供应可能避免分批运输的情况。
在这种情况下，工作项目就是各种参与者在寻求解决存货不足的问题时可以采取的操作。但是，这种组织与文档审阅中要
求的组织不同。参与者不是接受指令进行操作；相反，他们选择要执行的操作以及执行这些操作的时间。但是，这些选择受到工作流的组织的约束，它包含两个方
面：1)
这些操作专注于达到一个目标；在此情况下是解决库存不足问题。在开始解决问题时创建了一个有界协作空间，该空间直到目标达到后才被关闭。2)参与者不能随
便执行任意操作。相反，可用的操作由参与者正在执行的角色以及协作状态来确定。可用的操作集合由与目标相关的策略和全局策略（例如，有关缺货的黄金级客户
的约束）确定。可用的操作随着协作的进行而不断变化。
参与者的体验不再是执行分配的任务。相反，参与者查询自己当前可用的操作，不执行任何操作或者执行这些操作之一，然后重复该周期。
因此，这里的主要新要求与工作项目的组织形式有关，该组织形式本质上是由数据状态和目标驱动的。还有一个要求，即支持与工作流参与者
之间的查询/行动式协定。
脚本化操作
“脚本化操作”就是使用脚本撰写的一组操作。桌面工具就是一例，它使用户可以定义和执行一系列常见的任务，如复制文件和给文件加批注。一般不考虑为此目的
使用典型的工作流产品。但是，它非常适合由模型组织起来的一组工作单元的工作流平台模式。在这种情况下，模型是一个序列，可能带有对循环和条件执行的支
持。因此，如果工作流平台的成本足够低并且应用广泛，则可能会考虑将它应用于这一类的问题。这样做会增加价值吗？
脚本化操作目前的典型实现未能体现的一个特点就是数据流问题。一个操作所需的数据是前面某些操作的输出，这是常见的，但是在脚本中没
有对此信息进行典型建模。因此，当创建尚未提供任务的前提数据的脚本时，使用桌面工具装配任务的用户可能不会得到通知，而只能在运行脚本时发现该错误。可以描述这些数据依赖性的工作流模型将给脚本作者带来明显的价值。
一个方法是简单地在工作流模型中包含数据流结构。基本工作流模型是否需要包含基础的结构功能（如顺序、条件和循环），这一点非常有争
议；但是，数据流是否足够普遍，以至于需要由模型的第一类因素表示，这一点还不清楚。
另一种方法是在可扩展的基本工作流之上，将对数据流的支持进行分层。可以用适合于各种问题域的抽象加以充实的工作流模型非常吻合工作
流平台的概念。在基本模型中包含专门针对不同问题的各种语义结构会产生复杂性，而将工作流模型限制到一组固定的结构又会导致局限性，使用此方法则既避免了复杂性，又避免了局限性。
现在，让我们考察一个“导引用户”应用程序。一个示例是交互式语音应答系统
(IVR)，另一个示例是通过支持或销售脚本指导话务员的呼叫中心系统。这些应用程序的本质是引导用户进行一系列的操作以便达到他们的目标。这些操作的组
织通常用都是于驱动面向用户的演示，无论它是生成的语音还是表单上的一组启用和禁用的命令按钮。这种类型的应用程序的一个特点是：工作流是应用程序中更改
最频繁的部分。另外，此系统的业务发起人往往会频频指示更改，从而有必要提供一种明确而且高效的方式，以便
IT 员工和业务人员就更改问题进行交流。
一个能够表达此应用程序的核心业务目标，而且除去了任何不相关技术因素的工作流模型就是实现这种交流的有效方法。
这些应用程序还要求工作流的结构具有一定的灵活性。在 IVR
应用程序中，用户通常受到很大的约束，只能在一组层次结构化的菜单中移动。但是，还将有出口命令
— 例如，“返回到根菜单”或“跳出当前子树”。呼叫中心应用程序将比
IVR
应用程序更为灵活，它能够根据订单状态或客户的输入更改提供给用户的选项，例如，如果客户开始消极反应，则跳过销售提示。
这种应用程序要求支持多种工作项目组织结构方式，将顺序、循环和“一个能够表达此应用程序的核心业务目标，而且除去了任何不相关技术因素的工作流模型就是在
IT 人员和业务人员之间实现通信的有效方法”状态跳转条件以及在问题 —
解决协作中看到的那种数据驱动行为进行不
同的组合。
规则和策略
正如前面所讨论的那样，工作流方法藉以提供价值的一个方法是在应用
程序中隔离更改的焦点。通常，此焦点在于构建工作项目所采用的方式，
但是在某些应用程序中，更改的焦点在于与变动相对较慢的结构相关的
表达式。
这种焦点的一个示例是保险单报价系统，其中，使用一组经常更改的
计算来驱动报价过程中的决策。要求工作流对这些表达式进行建模，这有
两个主要好处：第一，因为此模型提供了很强的沙盒来限制可能的更改范
围，所以测试和部署成本要远远低于将表达式写为代码时通常会引起的成
本。第二，了解表达式的业务意义，但不具备理解技术代码（被写为代码的
表达式不可避免地需要嵌入到其中）的技能的人员也可以进行更改。
模型 — 视图 — 控制器 (MVC) 模式经常用于将 UI
连接到基本对象模
型（参见图 3）。“模型”代表系统的行为，它独立于任何特定的 UI
表示形式。
“控制器”是 UI 层的一部分，用于将 UI
生成的事件映射到驱动模型所需的
方法调用中。因而，UI
本身没有受到任何关于基本模型的假设的影响。
从这一观点看来，迄今为止所考虑的工作流都属于 MVC 意义上的“模
型”类别。但是，也可以将控制器视为工作流。它所组织的工作项目是“模
型”对象提供的方法。控制器还通过定义良好的协定与 UI
和模型交互。这
种类型的模型经常称为“页面流”。
与脚本化操作一样，现在不会使用典型的工作流产品来实现页面流。考虑使用工作流平台构建页面流有两个原因。首先，模型很容易以可视化方式表示，这有助于开发人员和分析人员表达和交流行为需求。其次，如果页面流经常更改，则将页面流抽象为模型可增加灵活性。
如果要使用工作流平台解决此问题，则有两个主要要求。工作流运行库必须是轻量级的（因为页面流可能在桌面上的小型应用程序中运行），并且所支持的协定必须包括
UI 特有的基于事件的协定以及由“模型”公开的对象 — 方法协定。
现在，让我们考察一个“测试记录/重放”应用程序示例。最后这个示例的目的是测试工作流平台假说的适用性的限制。
这里的应用程序是一个工具，用来测试作为一组服务构建的应用程序。此工具使用截获机制来记录在手动执行应用程序测试用例的过程中，各
服务之间发生的所有交互。随后可以重放此记录过程。在重放过程中，外部消息的生成无需手动干预，构成该应用程序的一组服务之间的消息则需根据原始记录检查顺序和内容。
工作流是测试用例，它组织了参与服务的工作单元。工作流既是主动的，又是被动的，前者是因为它模拟源于外部的消息的行为，后者是因为它监视服务之间的交互。
此应用程序的一个独特特征是：工作流是由程序（而不是开发人员和用户）作为记录测试用例的行为的一部分写入的。工作流模型的创建过程
必须是完全可编程的。还有对于可扩展性和动态更新的要求。
要求可扩展性的原因在于结构语义非常丰富。例如，没有必要因为在记录过程中两个消息相继到达服务，就意味着需要在重放过程中保留此顺
序。如果消息之间没有因果依赖性，则颠倒消息顺序的重放是正确的。因此，用于记录测试用例的模型中的顺序语义需要包含因果关系概念，而它不太可能是顺序的核心工作流模型的特征。
要求动态更新的原因在于，在重放过程中会发生人力与该模型的交互。在重放过程中发现的已记录的行为和已观察的行为之间的差异会显示
在测试者面前。如果差异的原因是消息包含一个随运行而变化的时间戳，则测试者应该更新模型以便将此字段标记为“不关心”。如果在回归测试中发生的差异是由于软件已经更改，则测试者可以批准更改并更新测试，以期在所有后续运行中出现新行为。
工作流平台价值
按定义，工作流平台不具有如今的典型工作流产品所提供的全套功能。相反，这里考虑的工作流平台专注于支持作为工作项目组织模型的工作流概念。我们已经看到，工作项目组织的这一概念确实可以应用于一系列广泛的应用程序中，但是工作流平台可以使用的事实并不意味着应该使用它。
必须提出下列两个问题：工作流平台方法还会衍生其他哪些价值？这种方法切实可行吗？工作流平台方法的这种价值必须来自于将工作的组织
结构表示为模型，我们稍后将对其进行讨论。让我们概括一下实用且有效的工作流平台必须表现出的特征。
