虽然Windows workflow是实施业务流程处理的一个优秀框架，但它却缺乏对人工活动的直接支持。 微软虽然发布了几种方法来解决这个问题，但这些方法却显得不够通用。本文将定义一种完全通用的方法，在WF中实现对人工活动的支持。
支持人工交互的复杂性带来众多的挑战，如下所列，可见一斑：
用户的响应时间（用户活动的执行时间）是不可预知的。
当请求发生的时候用户可以不连接到系统，因此需要存储请求，并当用户登录到系统之时提交给用户。
在不同的机器上可以有多个同时运行的工作流程。但是用户通常需要一个所有任务的统一视图。
业界已经认识到了这些问题，并制定了两个主要的规格来解决这些问题。我们将根据以下思想来构建人工活动的实现，而不是纸面上的规格说明书。
一个解决方案的组件视图
整体解决方案的主要组件如图1所示。
图1 解决方案组件
解决方案的核心是一个工作队列管理器。这是一个集中的服务，负责跟踪系统所有用户的所有任务。任何需要人工交互活动的工作流程（或者服务/应用程序所包含的工作流程），都去调用一个自定义的工作流活动，以通过它将请求提交到工作队列管理器，并对其进行持久化，同时允许系统的其他组件与这些请求一同协作。这样，工作队列管理器就成为了工作流引擎和人工活动执行之间的解耦层。在工作流执行期间，如果用户并不存在于系统中，这种方法同样提供了支持。同时，工作队列管理器通过形成的集中服务，可以将所有任务与指定的用户结合，而不用考虑是从哪里初始化的流程。因为不同的用户任务可以要求不同的输入信息以及产生不同的输出，工作流和人工活动之间的通信采用了XML进行输入输出，从而可以处理任何可能的请求和响应。虽然使用XML似乎会增加实现上的复杂度，但.NET对XML序列化的良好支持，使得XML和对象之间的映射易如反掌。工作队列查看器是一个GUI应用程序，允许用户直观地查看输入的已经准备就绪的所有任务。该应用程序是通用的，仅仅显示了任务的基本要素，包括名称，类型，优先级，创建者等等。根据队列中的这些信息，用户可以决定执行某一项特定的任务。任务的实际处理过程是通过一个在功能上支持给定任务的任务应用程序来完成的。一个工作流队列管理应用程序提供了一个用户界面，用来支持对工作队列管理器的管理。它可以查看和修改现有的人工任务，查看它们的历史记录等。最后，一个人工活动就是一个自定义活动（参看边栏“Windows Workflow Foundation 组件模型”，它实现了与任务队列管理器的通信，并为工作流开发人员展现了一个非常简单的针对人工任务执行的编程模型。从人工交互的角度来看，这与常规的服务调用并无二致。
Windows Workflow Foundation 组件模型
正如[11]所描述的，Windows Workflow Foundation (WWF)的实现不同于当下主流工作流实现的可执行工作流语言（域语言）。在WWF中，“过程图中的活动关联了一个实现该活动运行时行为的组件，组件由一种通用编程语言实现。过程语言中的每一个活动都对应一个实现组件。例如，一个Web服务调用活动，一个人工任务活动或一个电子邮件活动都对应一个实现组件 ”。
因此，我们能够非常容易地通过引入新的活动类型扩展WWF，以实现特定情况下的（在我们的案例中，就是人工任务的活动）运行时行为，通过实现新的活动这种方法，使得构建或者扩展现有的过程语言非常简单。
组件之间的整体交互如序列图所示（图2）
图2 序列图
我们可以看到，上面的整体解决方案里包含两种类型的组件：
通用的，包括人工活动，工作队列管理器和工作队列查看器。这些组件运行于人工任务的“标准”特性（attributes ）之上，并将任务的输入输出视为通用的XML。
特殊的，包括工作流本身和处理业务流程的应用程序，实现了特定业务对象的XML序列化/反序列化，并使用这些对象实现他们的功能。
本文只讨论通用组件的解决方案。
工作队列管理器服务接口和功能
正如我们在前面所定义的那样，工作队列管理器是一个集中的服务。它的功能基于数据契约，如图3所示。
图3 工作队列管理器数据契约