『听风且吟』技术版

在WF中，调度服务的职责是将工作流安排到线程上来执行。WF提供了两个调度服务：DefaultWorkflowSchedulerService和ManualWorkflowSchedulerService。如果我们不去显式的配置调度服务，Runtime会使用默认的调度器（DefaultWorkflowSchedulerService）。这两个调度器都继承自 WorkflowSchedulerService类。如果我们需要自定义的调度逻辑，也可以从此基类继承，并重写它的虚方法。

在上一篇文章《MOSS多级审批工作流【StateMachine版】》中，有这样一个情景，我创建了两个任务，并且要等到这两个任务都完成后，根据其结果进行一些操作。在这一部分，我遇到一个问题，如何并行的处理这两个任务呢？

Windows Workflow 其实是一个Runtime，而不是应用程序。在启动工作流之前，宿主进程必须先加载并运行工作流Runtime。宿主进程告诉Runtime要创建什么类型的工作流，Runtime则负责管理工作流的生命周期并通知宿主进程重要的生命周期事件，比如工作流的完成和终结。Runtime并不挑剔它的宿主，宿主可以是台式机上的智能客户端应用程序，也可以是机架上的服务器中运行的ASP.NET进程。所有宿主进程需要做的只是加载.NET 3.0工作流程序集而已。

在Windows Workflow中，活动的状态共有六种。这些状态通过ActivityExecutionStatus枚举来表示：Initialized、Executing、Closed、Canceling、Compensating和Faulting。所有活动都从Initialized状态开始，并以Closed状态结束。

从根本上来说,采用组成法或继承法来创建自定义活动并没有太大的差别.之前我们创建的GetUploadActivity就是从SequenceActivity类继承的.组成法和继承法都使用了继承.

本文汇总了《WF编程》系列的所有已翻译文章，并按照原书的章节对号入座，以便大家更有针对性地阅读。

引进依赖属性的最终目标是管理状态.依赖属性并不是Windows Workflow专有的,与WF类似,同样使用XAML来表示的Windows Presentation Foundation也应用了依赖属性.

组合活动就像一个黑盒子,工作流设计器无法获取这个黑盒子内部的属性和事件,除非我们把这些属性和事件曝露给外部世界.属性升级(Property promotion)允许组合活动的设计者去决定属性对于外部世界的可见性.

有两种方式可以创建自定义活动,即通过组合的方式和使用继承的方式.

这一章将会讲述如何编写自定义活动,并且深入研究实现自定义活动的不同方式.我们会讨论如何使用组合的方式创建黑盒活动和白盒活动;如何使用继承的方式来创建自定义活动;如何创建验证和设计时的行为.接着,我们还会讨论一些相关概念,比如依赖性属性(Dependency Property)和执行上下文(Execution Context).在本章的最后,我们将比较组合和继承这两种创建自定义活动方式,并理解创建自定义活动的要点.