『听风且吟』技术版

Visual Studio 2010 Tools for SharePoint是未来的Visual Studio 2010中的一个组成部分，这个Tools提供了什么振奋人心的功能呢？

SQL持久化和跟踪服务分别为工作流状态和跟踪信息提供了持久的存储。但是，它们并没有一起工作。具体来说，每个服务都会使用不同的数据库连接来进行操作。工作流Runtime也因此会使用多个数据库连接。如果跟踪服务开启了事务支持，则会导致额外的开销出现。当事务跨越多个连接时，微软分布式事务协调程序（Microsoft Distributed Transaction Coordinator，MSDTC）会接受事务的管理。MSDTC也会造成一些开销。WF为同时使用了SQL持久化和SQL跟踪服务的应用程序提供了优化方案：SharedConnectionWorkflowCommitWorkBatchService类。这个服务允许两个SQL服务共享一个连接（前提是这两个SQL服务的连接字符串是相同的）。

Windows Workflow 提供了可扩展可收缩的跟踪功能来捕捉和记录工作流的执行信息。对于接收到的工作流信息，跟踪服务会使用跟踪配置（tracking profile）来进行筛选。WF Runtime可以发送许多信息，包括工作流事件、活动状态更改、规则判断和我们的自定义检测数据（custom instrumentation data）。跟踪服务有能力决定如何处理接收到的数据，可以把它们记录到日志文件里，也可以保存到数据库中。跟踪服务会参与到工作流Runtime中来，以确保它记录的信息是一致并且持久的。

工作流在长时间运行时难免会遇到一些问题，许多业务逻辑需要花费数日、数周乃至数月。在这段时间中，我们不能让工作流实例一直驻留在内存中（比如，我们需要一份开支报告，而不巧的是对此负责的会计师却在西班牙海滩休假，怎么办呢？）。在Windows Workflow中，可以通过持久化服务来解决长时间运行的工作流可能遇到的问题。

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

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

去年我发布过一个MOSS多级审批工作流，采用顺序工作流模式开发；后来又做了一些改进，用ConditionedActivityGroupActivity取代了繁复的WhileActivity+IfElseActivity嵌套，但仍然是顺序工作流。 在第二篇文章的末尾我曾写道：“审批这样的流程并不适合用顺序工作流来实现，用WF的另外一种工作流-状态机工作流会更好”，为什么这样说呢？

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类继承的.组成法和继承法都使用了继承.