从业务用户的角度理解 Windows Workflow Foundation (WF)
4.29/5 (21投票s)
阅读本文后，您将对 WF 的领域及其提供的基本功能和特性集有一个清晰的了解。
引言
每当微软发布一项新技术时，其造成的轰动效应是如此之大，几乎无法回避。现在，如果我们看看去年发布的 Windows Workflow Framework (WF)，很明显，这项技术由于其自身的领域，将比其他技术受到更多的关注。现在，让我们来谈论更有趣的部分，即这项技术对软件开发人员、业务用户、最终用户/客户等的影响。无论您属于哪个类别，都会看到一定程度的理解不足和模糊性，这主要是由于我们当前的市场趋势，即人们在完全融入一项技术之前就已经将其与相关事物联系起来。对于非开发人员群体来说，这种情况更为普遍，尤其是项目经理和业务用户/利益相关者，他们缺乏尖端的技术知识来彻底理解这项技术。其结果是在市场上产生了一个必须不容忽视的空白。
在本文中，我将尝试彻底解释 Windows Workflow Foundation (WF) 的领域以及业务用户如何与其建立联系。我将尝试重点阐述大多数业务层用户认为非常重要并直接影响他们决策的问题。这包括一般的成本因素、对当前基础设施的更改、资源学习曲线、未来方法等。我希望在阅读本文后，您将对 WF 的领域及其提供的基本功能和特性集有一个清晰的了解。本文的读者应具备处理 IT 项目的丰富经验，特别是使用微软技术的项目。
理解工作流的业务领域
人工驱动的工作流
环顾四周，您会发现人们到处都在参与业务流程，并充当其中的唯一参与者。当您分析这些流程时，您会发现有些任务在执行之前依赖于其他任务。这种情况是人工驱动工作流的典型场景，因为只有人类才能在参与这些业务流程的过程中做出决策。人工工作流的一个重要特征是明确的角色参与，这些角色实际上是现实世界中定义的责任/角色的反映。我们必须理解的关键点是，我们不应忽视这样一个事实：人类的角色/责任在系统中可能以不可预测的方式快速变化，并且这必须在工作流系统中得到智能处理。因此，任何针对人工工作流的工作流系统都必须处理具有延迟和动态变化（包括工作流过程和角色）的长期运行进程。
Windows Workflow Foundation (WF) 应对上述所有要求，并提供了一个非常灵活的模型来实现它们。WF 提供了一个“状态机工作流”，它可以处理事件并根据事件取得进展；此外，还可以通过 WF 中的动态更新等功能来解决这些变化。
总而言之，WF 具备处理涉及人类以及过程中遇到的变化的情况的能力。我们将在后面的部分中看到工作流的详细示例，但在此为了完整起见，让我们来看一个简单的人工工作流场景。在大多数组织中，我们都看到一种处理请假申请的流程。其理念是，每位想要请假的员工都必须提交一份申请，然后该申请将通过批准流程，该流程可能涉及部门主管和运营经理（根据公司的组织层级）。您可以在此工作流中清楚地识别出，某些人类将承担部门主管和运营经理的角色。该过程可以通过下图进行可视化。
系统工作流
系统工作流是一类内在包含自动化元素的流程。与人工工作流相比，这里的关键参与者不是人类，而是服务和应用程序。当今世界，计算机已在从供应链管理到 DNA 建模的各个领域实现了各种形式的自动化。大多数业务流程都利用，甚至构建在服务和企业级应用程序之上。同样，我们也会遇到这些不同的服务以交互方式工作的场景，从而可以定义一个流程。这个流程以及其他被认为是不可避免的通用服务实体（例如通信服务、电子邮件等）构成了系统工作流。尽管在大多数情况下，与人工工作流相比，系统工作流中不存在智能或非正式（思考的真实和字面力量）的元素，但绝非不可能，并且可以在这些系统中利用业务智能来更进一步。
Windows Workflow Foundation (WF) 提供了一个坚实的平台，满足了系统工作流的需求。通过“顺序工作流”以及各种“活动”，WF 提供了一种高度灵活的方式来设计和实现各种系统工作流。WF 对任何单一服务或应用程序都持中立态度（与其他有依赖性约束的微软产品和技术不同），这使其成为实现系统工作流的理想选择。
在继续下一节之前，让我们来看一个理性的工作流场景，“申诉管理系统”（GMS）。GMS 在组织中非常普遍，是客户提出申诉的一种方式。通常，客户登录一个网站或手动拨打电话，然后有人代表这个电话将信息录入 GMS。下图显示了申诉管理系统的整个流程。需要注意的关键点是，与大多数工作流场景一样，GMS 也包含人类元素以及一些系统自动化。这种混合是当今大多数工作流中都可以看到的。
让我们分析上述 GMS，并列出和识别步骤、操作、规则以及负责这些操作的方（人类/系统）。
| 步骤 | Actions | 规则 | 系统/人类 |
| 客户通过登录 ASP.NET 网站或 SharePoint Portal Server 2003 门户来登录。 | 客户输入其申诉的详细信息。 | 客户必须是有效客户，并且有权提出申诉。 | 人类 |
| 客户信息经过验证，并且还会检查之前的历史记录。 | 客户定义的申诉存储在数据库中。对某些关键信息元素（例如客户姓名、会员类型等）进行检查和处理。申诉的优先级也随之设定。最后，为该申诉处理分配一名员工。 |
|
系统 |
| 一名员工处理申诉，并尝试提出一系列纠正措施来解决该申诉。 | 员工采取纠正措施，这可能需要对已提交的申诉进行实际操作。 |
|
人类 |
| 经理审查纠正措施并做出重要决定。 | 经理根据多种因素分析纠正措施，并将纠正措施标记为满意或不满意。然后将其发送到申诉流程管理服务/应用程序。 |
|
人类 |
| 申诉流程管理服务根据经理的输入相应地通知客户。 | 通过电子邮件、电话等方式通知客户，告知其已提交投诉的纠正措施。 |
|
系统 |
Microsoft 工作流策略
微软通过 WF 将工作流带入了主流，这并非偶然。这其中存在明确的需求，并且已被微软分析。在本节中，我们将回顾微软通过发布 WF 而成功掌控的一些领域。
与 Office 12 无缝集成
很难找到不使用 Microsoft Office 应用程序套件的办公系统。微软现在正推出下一代大型 Office 版本（Office 12），这将对当前的办公系统产生巨大影响。微软在 Office 12 上投入巨资，并清楚地认识到，诸如文档审批、任务初始化等业务流程必须极其易于使用，并能与 Office 应用程序无缝集成。对微软而言，重要的一点是，他们希望技术用户和非技术用户都能平等地从他们的系统中受益。
WF 是实现无缝集成的关键构建块，因为它是微软提供的唯一工作流解决方案。我认为举个例子可能会有帮助。考虑一种情况，即业务用户希望针对 Office Word 文档启动一个文档审批流程。现在，这可以通过单击按钮轻松完成，事实上，业务用户将完全不知道后台发生了什么。需要记住的关键点是，有许多 ISV（独立服务供应商）提供了工作流解决方案，并且与产品（尤其是 InfoPath 等）有良好的集成，但 WF 提供的集成级别和规模很难找到。此外，WF 不是产品而是技术这一事实，使其成为构建针对 Office 12 应用程序的工作流的理想选择。因此，如果您计划在未来投资与 Office 12 产品和应用程序集成的工作流，那么从成本、集成和资源消耗方面来看，WF 是一个更好的解决方案（考虑到您的开发人员拥有相同的开发环境和类似的技术范式）。我们将在后面的部分中更详细地讨论 Office 12 和 WF 的集成。
应用程序开发
应用程序开发是软件制造的支柱，工作流解决方案也不例外。我们都知道，应用程序开发延迟会对项目产生严重影响，尤其是在预算超支方面。使用 WF，您可以极大地缩短应用程序开发时间，因为如果您拥有一批已经调整好并且能够基于 .NET 平台进行开发的开发人员，那么 WF 的学习曲线将非常短。这主要是因为微软将 WF 作为一种框架发布，并为开发人员提供了他们熟悉的工具集。例如，如果您的开发人员正在使用 Visual Studio 2005 进行开发，那么他们将从第一天起就完全适应 WF。看看下面的图表。它们是 Visual Studio 的快照。第一个显示了开发人员用于 Windows 开发的应用程序开发环境，第二个显示了开发人员用于 WF 开发的应用程序开发环境。
ISV 的可扩展平台
如果您是或希望成为一家基于微软技术开发解决方案的 ISV，那么您一定会很高兴地得知，WF 可以用作构建企业级解决方案的底层技术。这种可扩展性非常强大，并且由于提供了核心功能，因此为投资打开了大门。像 K2.Net 和 Captaris Template 这样的 ISV 提供了工作流解决方案，它们在其后续版本中采用了 WF 技术作为未来的方法。
总而言之，微软在工作流方面的策略是使其对所有 Windows 用户都易于访问，并提供处理广泛工作流场景的能力。
考察成本因素
成本因素是项目利益相关者的另一个重要因素。特别是当您投资于像 WF 这样的新技术时，分析相关的成本因素非常重要。在本节中，我们将首先了解微软如何打包 WF，以便您能清楚地了解其总成本（如果有）。然后，我们将尝试确定相对于其他产品在完整或部分工作流领域的成本。
Windows Workflow Foundation (WF) 是 WinFX 的核心组件，计划于 2006 年年中发布。WF 是一个框架，而不是一个产品（就像 .NET 是一个框架一样），它是免费的，完全不收取任何费用。这意味着任何人都可以使用它，而无需支付服务器许可证或客户端访问许可证费用。我们应该理解清楚产品和框架之间的区别，并且不应被忽视。以下是影响框架和产品之间成本差异的重要因素列表。
开箱即用的功能
框架通常充当基础砖，我们如何在其上开发产品完全取决于我们。另一方面，产品针对特定领域，并提供特定区域的功能集。WF 产品提供了一些开箱即用的功能，这些功能大多是通用的，并且易于应用。它提供了大量的支持，可以按照您想要的方式进行操作，这使其具有通用性。例如，如果 WF 只为某些应用程序提供开箱即用的支持，那么它的可用性将不如现在。所有这些都会影响成本，这就是为什么开箱即用的功能具有内置成本，并且已嵌入到产品中。
可扩展性
框架高度可扩展，但您必须付出劳动才能利用它。这是与领域特定产品相比的一个关键因素；它们可能不像 WF 框架那样提供高度可扩展性，但通常足够可扩展以满足其领域的需求。
供应商支持
产品符合支持条件。这进一步细分为子类别；支持可能是付费的或免费的，具体取决于其级别。这与大多数其他框架不同，后者支持有限。当发现任何严重的功能缺失时，可能会随着时间的推移提供开发补丁。
WF 与第三方工作流套件
WF 是一个功能丰富的免费框架；其中一些功能由微软提供，另一些则由合作伙伴 ISV 提供以填补空白。由于 WF 是一个工作流框架，并且不针对任何特定产品，因此它成为 ISV 以其为基础构建自己的工作流产品的理想选择。有一些 ISV 正在使用 WF，他们未来的版本也将符合 WF 标准。成本完全取决于其产品提供的功能。例如，一个 ISV 提供具有业务监控功能的工作流，并提供与现有微软产品和技术（例如，Microsoft Office 应用程序套件、ASP.NET、WSS 等）的广泛集成选项。另一些 ISV 则仅提供工作流功能和与单个微软产品和技术的集成（例如 WSS、Share Point Portal Server 2003 等）。
WF 与当前微软基础设施/服务器和客户端应用程序
WF 可以利用现有的微软基础设施；此外，其与微软产品的集成能力为各种利益相关者开辟了广泛的可能性。由于无法提供 WF 与所有微软产品和技术集成方案的概述，我在此选择了两个使用量大的服务器产品，即 Microsoft Content Management Server 2002 和 SharePoint Portal Server 2003，以及一个 Active Directory 实现。
Content Management Server 2002
Microsoft Content Management Server 2002 (MCMS 2002) 今天被组织广泛用于处理组织中发布的大量数据。MCMS 2002 自身有一个简单的工作流，但功能非常有限，大多数时候，组织希望实现模拟其现有业务流程的工作流。WF 可用于弥补这一差距并根据用户需求实现业务流程。但您必须记住，MCMS 2002 仅通过 Service Pack 2 支持 .NET 2.0，而且它不是一个任何人都会轻易使用的直接 Service Pack。此外，MCMS 2002 现在已与 SharePoint Portal Server 2007 合并，如果您的客户要求将您在 MCMS 2002 上的 WF 实现迁移到 SharePoint Portal Server 2007，这肯定会引发许多问题，并且由于 SharePoint Portal Server 2007 目前处于 beta 2 阶段，因此无法实现无缝转换。我们无法做出最终判断，除了 MCMS 2002 的正常功能和 MCMS 2002 数据库迁移将提供这一事实。
Microsoft Office SharePoint Portal Server 2003
Microsoft Office SharePoint Portal Server 2003 (SPP 2003) 构建在 WSS 2.0 之上，是一个用于内部网/互联网的协作平台。文档库、工作区（协作场所）以及与 Office 2003 的顺畅集成等功能使其在大小型组织中广受欢迎。WF 可与 SPS 2003 一起使用，尽管这种用法不如 SPS 2007 那么顺畅快捷。但是，通过明智的投资和高质量的开发，可以利用 SPS 2003 的 WF。需要注意的是，WF 可以执行许多以前通过第三方工作流解决方案或大量自定义开发完成的任务。简而言之，WF 可以驱动 SPS 2003，但具体取决于您希望通过 WF 实现的目标的程度和规模。
Active Directory
WF 可以利用 Active Directory 实现；这可以通过创建和使用与 Active Directory 通信的自定义 WF 活动来实现。同样，这里有（并且将会有）更多此类活动可用。
资源学习曲线
Microsoft WF 可能是一项新技术，但很容易上手。这归因于我们将在稍后看到的一些因素，但关键在于微软尽了一切努力使学习和开发体验尽可能舒适。以下几点将帮助您更好地理解它。
开发人员没有意外
如今，大多数从事微软技术开发的开发人员都使用 Microsoft Visual Studio 进行开发，如果 WF 需要不同的方法，那将是一个巨大的失误。微软明白，如果开发人员发现做事方式与他们习惯的不同，那将是一个非常令人不快的意外。因此，WF 开发可以在 Visual Studio 中进行，就像开发任何其他微软技术一样。这大大缩短了开发人员可能需要的学习曲线（如果不支持此功能）。
Microsoft 网络广播
微软提供网络广播，努力深入了解微软技术。有针对不同受众（从系统架构师到开发人员）的 WF 网络广播。这些网络广播由技术专家亲自主持，因此是极好的学习资源。
此外，Microsoft MSDN 网络是理解新技术的一个绝佳场所。
WF 与未来方法
Microsoft Vista
Vista 是微软下一版本的 Windows。如果您计划在 Vista 上提供工作流解决方案，WF 应该是您的首选。WF 是 WinFX 发行版的核心组件之一，并将于 2006 年中期发布。
Microsoft Office SharePoint Server 2007
Microsoft SharePoint Portal Server 2007 (SPS 2007) 是 Microsoft SharePoint Server 2003 的下一个版本，现在也集成了 Content Management Server 2002 的功能。此版本完全利用了 Office 12。WF 是 SPS 2007 中使用的工作流技术；事实上，有一些工作流场景是开箱即用的（例如，文档/任务反馈）。下图显示了 SPS 2007 中提供的文档/任务反馈工作流的截图。
请注意，在上述截图中，“委派”和“请求更改”等普通业务任务也由 WF 提供。
Microsoft FrontPage 12
FrontPage 12 为业务用户提供了一个场所，让他们可以在不具备 WF 及其技术细节的任何先验知识的情况下，更改 SPS 2007 的布局并创建工作流。以下截图详细展示了非技术用户如何轻松地使用 FrontPage12 定义工作流。
事实上，有大量的 SharePoint Portal Server 2007 内容可供使用，下图显示了这一点（请参阅包含各种 SharePoint Portal Server 2007 内容的下拉框，包括联系人、讨论区、链接等）。
选择要在其上应用工作流的内容后，您可以添加任意数量的步骤。下图显示了添加到工作流中的一个步骤。
定义步骤后，您可以为该步骤添加条件。这些本质上是我们希望评估的业务规则。下图显示了可以添加的简单条件。
接下来，您可以定义当您定义的条件满足时要执行的操作。下图显示了可用的操作。
早期 WF 适配器 ISV
有大量早期采用 WF 的 ISV。下图显示了这一点。它们中的大多数不仅提供工作流解决方案，还提供业务流程建模解决方案。
结论
Windows Workflow Foundation (WF) 是在微软平台上构建工作流解决方案的未来。它是免费的，与微软产品和技术（例如 Office 12）高度集成，丰富的 [功能](https://codeproject.org.cn/Articles/13481/Understanding-the-Windows-Workflow-Foundation-WF-F) 使其成为开发工作流的理想选择。我们考察了几个非技术用户通常觉得模糊并导致他们犹豫做出及时决策的领域。希望本文能帮助您更好地理解 WF 及其领域技术。请随时在此文章的论坛上发帖。如果您想了解更多关于 WF 的信息，请加入这个群组；您可以在这里提出任何疑问，我们将尽力回答。