【翻译习做】 Windows Workflow Foundation程序开发-第一章01

第 1 章    欢迎来到工做流的世界

…思想如蝴蝶般飞到我身边 —— Gossard / Vedder

（译注：Gossard与Vedder是来自Pearl Jam乐队的2名乐手，该句出自他们的歌曲《Even flow》）

 

Windows Workflow可被看做是继COM＋和分布式事务协调器（DTC）以后，Windows平台上最使人瞩目的一款中间件产品。它们之间的区别在于：不是每个软件应用都须要进行分布式事务处理；但几乎每一个软件都要在其内部实现工做流。为了可以领会微软设计Windows Workflow的初衷,让咱们先从一般意义上的工做流谈起。

工做流是什么？简单地说，一个工做流就是为了完成一个特定任务而涉及的一系列步骤、决策和规则。想想你在当地一家比萨饼店点餐这样一个流程。你先跟餐厅招待讲明想要哪款比萨饼。招待把点菜单传给厨师，厨师就着手把原料处理好并放入烤炉。稍后，厨师把烤好的比萨饼交给招待，招待把比萨送到你面前并跟你结帐。至此，整个流程结束。这项工做先“流”向招待，而后“流”向厨师，最后又“流”了回来。

在上述每个步骤中，全部参与者都进行了规则评估并作出决策。厨师在接受点菜单以前要先看看后厨的备料是否够用。在结帐时，要是你拿出了优惠券，招待一定要看看它们是否有效；若是怀疑你用假钞付款，他还要通知餐厅经理。

工做流不必定非要有人参与其中（这点好啊，由于人但是有本事把最简单的过程都给搞复杂了）。一个工做流可能发生在两个分布式应用软件之间。例如，两个内容管理软件可能会在夜间经过应用一系列特定的操做和规则来实现两者间的内容同步。

大部分的工做流都是有状态的，并且常常会须要至关长的执行时间。幸运的是，你点的比萨饼会在30分钟内作好。在这段时间内，点菜单的状态信息，好比你已经点的比萨饼盖头，不能有变化。比萨饼店向供货商定奶酪的流程可跟你点比萨饼的不同。供货商不可能在30个小时内都不把奶酪送来，比萨店也不会在30天内都不向供货商支付货款。在那30天中，对于一个交易来讲，须要某种东西来维持其工做流状态。

一个工做流在其生存期内可能要花费大部分的时间等待来自外部世界的事件信息。在顾客等待上菜，招待等待顾客付款，或者厨师等待比萨出炉的时候，工做流会处于空闲状态。在这种状况下，工做流并不须要任何资源。

一个工做流就是为了完成一项任务而执行的一系列步骤。工做流常常会长时间地运行，并且它是有状态的，时常须要等待事件，并与人进行交互。你会发现工做流无处不在。做为程序员，咱们常常要在本身开发的软件中实现工做流。

1.1         建立工做流解决方案

咱们都有参与一些软件开发项目的经验，启动这些项目的目的就是想经过软件来改进现有的业务流程。这些流程多是关于比萨饼订单的，关于金融交易的，或者是关于医疗保健的。不管如何，每当谈论到这些项目时，咱们都不可避免的要碰到“工做流”这个老朋友。工做流看似简单，但是深刻其中，你就会发现内藏的玄机。为了管理工做流状态，咱们须要数据库表格和数据访问类。咱们须要Email发送组件和队列消息等待组件。咱们还要告诉计算机如何执行工做流。让咱们先来看看理论上工做流是如何实现的：

// 这是一个处理新提交的采购订单的工做流
class PurchaseOrderWorkflow { public void Execute(PurchaseOrder order) { WaitForManagerApproval(order); NotifyPurchaseManager(order); WaitForGoods(order); } … }        

 

假设咱们已经给出了Execute当中三个方法的定义，一个工做流看上去真的会如此简单吗？答案显然是否认的。咱们必需要编写一些代码来实现异常处理、日志记录和诊断功能。咱们须要引起事件并提供挂钩函数以便可以跟踪和取消正在运行的工做流。同时，这个工做流会在大部分时间里处于空闲状态并等待一个外部事件发生，好比说一直在等待供货商把已下单的货物送上门来。在等待到货的时候，咱们不能让运行中的应用程序线程空空等上几天甚至几周。咱们须要提供一种机制，它可以把工做流的执行状态保存到持久化的数据存储介质中，而后将这个正在运行的工做流实例从内存中清除。当有一个重要的事件发生了，咱们还会恢复这个工做流的状态，并让它继续执行下去。

遗憾的是，这样一来，咱们就会在工做流内部和外部添加太多的代码，以致于使本身迷失在工做流之中，很有一种“不识庐山真面目，只缘身在此山中”的困惑。全部这些支持性代码会掩盖住咱们正试图实现的业务流程。一个不懂技术的业务人员将永远没法透过这些代码看清其中的工做流。一个程序员若是不对代码仔细探查一番，也不会理清其中的工做流。

一种改进的工做流设计方法试图把工做流的定义与执行该工做流的引擎和支持性代码相分离。这种方法容许程序员，甚至是业务人员，来描述这个工做流 “应该作什么”，而让工做流引擎来决定“如何”让这个工做流去作。目前，许多工做流解决方案都是在广受欢迎的尖括号中定义工做流。让咱们看看理论上使用XML定义工做流的方法。

<Workflow Name="PurchaseOrderWorkflow"> 
    <Steps> 
        <WaitForTask Event="ManagerApproval"/> 
        <NotifyTask Target="PurchaseManager"/> 
        <WaitForTask Event="Delivery"/> 
    </Steps> 
    <Parameters> 
        <Parameter Type="PurchaseOrder" Name="order"/> 
    </Parameters>
</Workflow>

 

这里再问一句，一个工做流看上去真的会如此简单吗？此次的答案是确定的；咱们还须要一个可以理解这段XML并把它翻译成计算机指令的工做流引擎。这个引擎将包括全部必需的功能，好比异常处理、追踪以及取消执行功能。

 

咱们在前面看到的C#代码是一个命令性编程方式的例子。在这种方式中，咱们经过提供一系列可执行的指令来描述“如何”完成一项任务。上面的XML标记是一个声明性编程方式的例子。在这种方式中，咱们对任务看上去是“什么”样子进行描述，而让其它软件来决定为了完成任务须要执行哪些步骤。软件市场上大部分的商业化工做流解决方案都容许使用声明方式定义工做流，由于这种方式不与异常处理、事件激发等低层次的实现细节搅合在一块儿。

 

使用XML的好处之一就是有大量的工具可以对XML标记码进行读取、修改、建立以及转换操做。也就是说，咱们能够借助工具进行XML开发。与解析C#代码相比，XML标记码解析起来更容易，而且可使用图形框和箭头为工做流生成可视化效果。反过来，咱们也能够先让业务用户使用可视化设计器，经过把一些图形框相连的方式绘制出工做流框图，再从框图中自动生成XML标记码。

咱们到底想从一个工做流解决方案中得到什么？咱们想以声明方式对工做流进行描述，也许还须要一个可视化设计器来帮忙。咱们想把工做流的定义输入到一个工做流引擎中。这个引擎会运行工做流，并对错误、事件、追踪、启用以及停用操做进行管理。

下面该Windows Workflow Foundation登场了。

 

章节连接：
【翻译习做】 Windows Workflow Foundation程序开发

【翻译习做】 Windows Workflow Foundation程序开发-前言