Windows Workflow Foundation能带来什么

就像通常的工作流平台一样，WF也有几个目标，最突出也是最重要的三个目标是：为Windows系统提供一个通用的工作流基础平台，为多样的工作流应用系统提供一个框架，统一系统与人工工作流。这个的章节要验证每一个目标。

1. 为Windows系统提供一个通用的工作流基础平台

很多由Miscrsoft和其他软件公司创建的Windows应用系统或多或少的包含一些工作流支持。让我们只看看在Miscrosoft软件里，就有BizTalk服务器，Exchange服务器和其他种种都是由工作流技术提供的，这些广泛的应用也说明了工作流技术是多么的有用，但是工作流技术在很多其它的软件体现得不是那么明显，就像其他主流的开发技术，工作流支持会成为Windows操作系统平台的一个组成部分。

这就是WF所要提供的，这种（通过工作流技术）构建软件的方式将对那些需要工作流技术的Windows应用系统会越来越有用，下面的图彪昭示了这个想法：

如图所示，WF对客户端和服务端都是有用的，它可以用于由用户，ISVS和Miscrosoft自身创建的许多应用，尽管这需要花上一段时间，但是WF将会成为Microsoft产品和技术中一个工作流的基础设施平台，最浅显的一个例子是最近发布的Windows SharePoint Services，就提供了基于WF的面向文档的工作流服务。在不久的将来，其他发布的微软的产品，包括BizTalk Server，也会使用WF来应用它们的工作流服务。

有一点必须弄懂的是，WF是做为一个框架来针对开发人员的，而不是一个能被终端用户立即使用的工作流应用(中间件-译者注)。因此，它没有为工作者提供与工作流交互的信息工具。它也没有很酷的管理工具和监视工具，尽管你可以通过开发出这些工具来从工作流中得到信息，WF的目的不是为了成为一个完整的Windows工作流解决方案，相反，它的主要目标是为了让软件开发者更加简单的开发出基于工作流的Windows应用。

2. 各种各样的工作流应用的一个基础框架

为Windows创建一个通用的工作流技术有着一个明显和有挑战性的问题，那就是为使用工作流技术的Windows应用软件提供多样的方法和途径，任何一个工作流解决方案能囊括这一切吗？传统的工作流基础平台产品，往往只是用单一的语言来表达工作流，用单一的图形化工具来定义工作流，很难满足这么广泛的需求，那么，我们需要其他的方法来满足需求。

不同于只提供单一的语言和单一的工具，取而代之的是，WF通过提供一个通用的框架来创建和运行工作流，在WF世界里，一个工作流由一组活动所构成，如下图所示，在工作流里，每一个活动都会运行一些动作：

                                                         

WF内置了一套有着通用目的活动来定义工作流。基础活动库提供了我们一些熟悉的比如If/else，while循环的结构来定义控制流程。它还包含了一个规则引擎，支持通过 Windows Communication Foundation (WCF)和更多的方式与其他软件交互。

尽管这些内置的活动为工作流提供了大量的功能性的支持，开发者也可以自由定制个性化的活动来满足一个特定的问题域，可以这样说，活动所提供的东西就像是工作流的一个组件模型。例如，Windows SharePoint Services提供了以创建面向文档工作流为目标的一套活动集。其他的应用系统，不管是Miscrosoft还是其他公司提供的，都能自由的创建属于他们自己的活动组。比如，Windows SharePoint Services允许工作流赋予工作给用户，理所当然，它就包含了比如CreateTask与CompleteTask诸如此类的活动。 一个基于工作流的健康顾问应用系统能够提供完全不通的一套定制的活动，一个基于工作流的保险应用系统照样可以自己定制。
因为定制的活动与WF提供的活动一样都使用了同样的公共接口，所以工作流可以将定制的活动与基础活动库里的内核融合在一起，定制者可以自由的忽略WF的基础活动库——WF并没有要求一定要使用这些基础活动。WF的目标是更多的开发者通过使用更少的技术开发者定制的面向领域的活动来创建工作流。

WF工作流既可以直接写代码来实现。也可以通过图形化定义，如果有需要，可以再增加代码。为了实现这种可能性，WF提供了一个让开发者创建和修改工作流的内置在Visual Studio中的工作流设计器，设计器左边的工具栏里有基础活动库标示的图标，你可以从工具栏上拖拽活动图标到设计界面上。每一个活动都有让开发者在Visual Studio设置的属性和事件。

工作流设计器可以由其他的环境所内置和定制。ISV可以将设计器工具直接内置在自主开发的工作流产品里，可以让它具有更适合的界面和感官。类似的，组织也需要为信息工作者提供一个将工作流内置的比Vistual Studio更加具有商业友好性的环境来创建和修改工作流。并且，ISV可以自由的创建其他的图形化设计器来与WF工作流平台工作——不是一定要使用工作流设计器。

另外一个挑战是Windows通用工作流平台的宿主：什么样的应用能够跑工作流呢？WF的答案是相当多的Windows进程都可以跑工作流，不仅仅是简单的控制台程序或者Windows Forms应用，由企业或者ISV开发的大型复杂的软件都是可以跑的。目标就是让非常广泛的软件族都能使用WF。

WF的创建者的一个基本目标就是鼓励在这个工作流框架周围形成一个生态系统。特定的活动关注于特定的问题域，内置了工作流的定制环境，能创建所有的能够让WF运行时内置的用于解决特定需求的宿主环境。不管WF如何被使用，核心的程序模式和运行时引擎都是保持一样。图形化开发工具的行为也是相似的。随着时间的流逝，WF使用者的使用体验可能会变得非常的多样化，但是这种体验的基础还是保持共通。

3. 统一系统与人工工作流

即使业务处理流程常常会是人与应用系统共同参与，在软件之间的自动化交互要比在人之间的自动化交互要困难的多。因此，以往的工作流技术往往会有代表性的强调其中的一种或者另一种。WF的主要目标之一就是：通过提供解决这些问题的统一解决方案来结束这样的分裂。

让我们来看看为什么这是一个挑战，想想应用系统之间自动化交互的典型特点。有些时候称之为系统工作流或者管弦乐编曲,应用系统之间的交互常常是可预知和相对静态的。这种交互的逻辑可以一次性的定义好，然后恒而不变的使用。典型的，系统工作流也会交换结构化，有着良好定义的数据，比如XML文档，这种交互在不需要人的干涉的情况下能够由软件高效的处理。

与之不同的在人之间交互的人工工作流，相对于那些只需要与其他交互的应用系统来讲，那些与人的利益相互影响的应用系统需要更多的弹性。人们改变他们的注意，带来了新的点子和异常，出乎意料的决定取消一个流程以及种种其他，这深刻导致了人工工作流需要比系统功过流更加的灵活和动态。因此，支持人工工作流的软件需要一个更多事件驱动的，更有弹性的方式。人工工作流往往要与无结构的，人性化的数据打交道，比如Email和文本文档，而不是系统工作流中使用的结构化的信息。

给出了这两种工作流的不同需求后，你就不会惊讶要在一个单一的技术来解决所有的问题是一个挑战了。WF就是很明确的用统一的方式来解决这些种类的工作流。为了达到这个目的，WF提供了顺序和状态机的方法来定义工作流，有能力为正在运行工作流增加或者修改步骤或者其他事情，我们将在后面章节中一一描述。