最顶层的Activity类提供了一个可以供子类重写的InternalExecute()方法：
internal virtual void InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager);
子类可以重写此方法，在此方法中实现各种功能，这个方法在WF4内部非常重要，许多东西都与它相关。
为了方便地供开发者自定义业务处理逻辑，诸如CodeActivity之类最底层的类，另定义了一个抽象的Execute()方法：
protected abstract void Execute(CodeActivityContext context);
当开发者自定义Activity时，就可以直接地重写此方法。
简言之，工作流的运行就体现为Activity对象树中叶子节点Execute方法（或类似的方法，比如DynamicActivity是InternalExecute方法，AsyncCodeActivity是BeginExecute和EndExecute方法）的执行
WF4中工作流的执行原理
首先要明确，在WF4中，如果使用WorkflowInvoker类来启动工作流时：
WorkflowInvoker.Invoke(new Workflow1());
工作流Workflow1将在调用者的线程中执行。这种情况下，工作流的执行类似于方法调用，是最简单的执行模式。
然而，如果使用WorkflowApplication启动工作流，工作流实例将在调用者线程之外的另一个线程中运行：
WorkflowApplication wpp = new WorkflowApplication(new Workflow1());
wpp.Run();
而且，这个“另外的工作线程”是线程池中的线程。
不管是由哪个线程负责执行工作流，有一个原则是很重要的：
单个工作流实例是单线程执行的，哪怕诸如Parallel Activity给你一个多分支“并行”运行的假象。
事实上，Parallel Activity采用在单线程中“轮换执行”各分支。当一个分支进入空闲“Idle”时，工作流调度器调度下一分支投入运行。所果所有分支都不包括使本分支进入Idle状态的Activtity（比如有一个Delay Activity或创建了书签），则Parallel Activity按从左到右的顺序执行各分支。
那么，构成工作流的各个Activity实例是如何执行的？
WF运行时在内部为每个工作流维护了一个工作项队列。然后，创建一个Scheduler类的实例来负责从此工作项队列中取出和追加工作项，并执行之。
这里要说说这个工作项队列，在Scheduler类的代码中可以找到它的声明：
private Quack<WorkItem> workItemQueue;
这里有一个奇怪的Quack<T>泛型类，我仔细看了一下，其实它就是一个泛型队列，但它有一点特殊之处：
Quack<T>泛型类在内部使用一个数组来保存数据：
private T[] items;
初始时，为队列分配可容纳4个T类型对象的内存空间，当不断增加对象而需要扩充空间时，就分配一个“当前所占内存空间*2”的新数组，再将老数组中的内容复制到新数组中。
很明显，在两个数组中复制元素会花费系统资源，我不知道为何WF4的设计者这样设计，估计是他们有其他的考虑。
队列中的WorkItem对象很有趣，它代表一个将被执行的Activity实例，这里暂时放下，一会儿还会介绍它。
Scheduler对象的工作可以简述如下：
它从队列中取出一个WorkItem对象，然后将其委托给线程池中的线程（如果工作流由WorkApplication以异步方式启动执行）或调用者线程（如果工作流由WorkflowInvoker以同步方式启动执行）执行。这些线程 将负责调用WorkItem所封装的Activity实例的Execute()方法（或类似的方法，如前所述）。
深入分析Activity执行的流程
一个Activity实例到底是如何执行的？一切得从WorkItem类开始。
WorkItem是一个抽象基类,提供了几个抽象方法，其中最重要的就是Execute()方法：
internal abstract class WorkItem
{
//……
private ActivityInstance activityInstance;
public abstract bool Execute(ActivityExecutor executor,
BookmarkManager bookmarkManager);
}
上述声明中还有两个很重要的类ActivityInstance和ActivityExecutor。
ActivityInstance代表着正在运行的一个Activity实例，它包容一堆的internal方法可以完成Activity的执行（Execute）取消（Cancel）和放弃(Abort)的功能。 ActivityExecutor则负责调用ActivityInstance中的这些 方法。
WorkItem有一堆的子类，这些子类又派生出“孙”类。比如，其中的一个分支如下：
不管有几个子孙，后代一般都重写了WorkItem所定义的Execute()抽象方法。
我们以ExecuteRootWorkItem类为例，顾名思义，这应该是与工作流中最顶层的Activity相对应的WorkItem。它的Execute()方法如下所示：
public override bool Execute(ActivityExecutor executor, BookmarkManager bookmarkManager)
{
return base.ExecuteBody(executor, bookmarkManager, this.resultLocation);
}
它将调用基类ExecuteActivityWorkItem的ExecuteBody()方法，此方法的关键代码如下：
protected bool ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
{
//……
base.ActivityInstance.Execute(executor, bookmarkManager);
//……
}
可以看到，它直接跳去执行最顶层基类WorkItem所定义的ActivityInstance对象的Execute()方法。此方法的代码如下：
internal void Execute(ActivityExecutor executor, BookmarkManager bookmarkManager)
{
//……
this.Activity.InternalExecute(this, executor, bookmarkManager);
}
注意ActivityInstance实际上封装了一个Activity对象：
public sealed class ActivityInstance : ActivityInstanceMap.IActivityReference
{
public Activity Activity { get; internal set; }
//……
}
所以，ActivityInstance对象的Execute()方法实际上执行的是Activity对象的InternalExecute()方法。再追踪下去：
internal virtual void InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
{
//……
executor.ScheduleActivity(this.runtimeImplementation, instance, null, null, null);
}
注意：上述代码是Acitivity对InternalExecute（）默认的实现方式，它的子类（比如CodeActivity）通常会重写它。
可以看到，在ActivityInstance对象的Execute()方法中，执行流程转给了从前面一路传送过来的ActivityExecutor对象，由此对象的ScheduleActivity方法负责将Activity插入到工作项队列中。
ActivityExecutor.ScheduleActivity方法又进行了一个“倒手”，调用自己的ScheduleBody()方法：
private ActivityInstance ScheduleActivity(……)
{
//……
this.ScheduleBody(scheduledInstance, requiresSymbolResolution, argumentValueOverrides, resultLocation);
}
在ScheduleBody()方法中，“佛祖”终于现出真身，我们看到了Scheduler的身影：
internal void ScheduleBody(ActivityInstance activityInstance, bool requiresSymbolResolution, IDictionary<string, object> argumentValueOverrides, Location resultLocation)
{
if (resultLocation == null)
{
//……
this.scheduler.PushWork(new ExecuteExpressionWorkItem(activityInstance, requiresSymbolResolution, argumentValueOverrides, resultLocation));
//……
}
在上述代码中，Scheduler对象将activityInstance转换为了一个ExecuteExpressionWorkItem，然后将其插入到工作项队列中等待执行。
现在我们看到，默认情况下，对ExecuteRootWorkItem的执行将导致一个新的ExecuteExpressionWorkItem工作项被插入到工作项队列中。
工作项队列中的工作项是如何调度执行的？
Scheduler类负责工作项的调度执行。
在Scheduler类的构造函数中，挂接了一个回调函数OnScheduledWork：
static Scheduler()
{
//……
onScheduledWorkCallback = Fx.ThunkCallback(new SendOrPostCallback(Scheduler.OnScheduledWork));
}
在OnScheduledWork（）函数中，揭露出了任务项调度是如何进行的秘密：
private static void OnScheduledWork(object state)
{
//取出队列中的第一个工作项
WorkItem firstWorkItem = scheduler.firstWorkItem;
if ((scheduler.workItemQueue != null) && (scheduler.workItemQueue.Count > 0))
{
scheduler.firstWorkItem = scheduler.workItemQueue.Dequeue();
}
else
{
scheduler.firstWorkItem = null;
}
//执行这一工作项
continueAction = scheduler.callbacks.ExecuteWorkItem(firstWorkItem);
//……
}
下面是ExecuteWorkItem（）方法的代码，可以看到，最后调度器还是委托activityExecutor来执行Activity的：
public Scheduler.RequestedAction ExecuteWorkItem(WorkItem workItem)
{
Scheduler.RequestedAction objA = this.activityExecutor.OnExecuteWorkItem(workItem);
//……
}
ActivityExecutor的OnExecuteWorkItem（）方法有很多代码，其中关键的就是以下这几句：
internal Scheduler.RequestedAction OnExecuteWorkItem(WorkItem workItem)
{
//……
propertyManagerOwner.PropertyManager.SetupWorkflowThread();
if ((abortException == null) && !workItem.Execute(this, this.bookmarkManager))
{
return Scheduler.YieldSilently;
}
//……
}
我们终于发现了调用工作项的Execute()方法的语句。
有的朋友可能会疑惑，我们的探索之旅从WorkItem.Execute()方法开始，转了一圈怎么又回到了WorkItem.Execute()方法？这样一来，调用工作项的WorkItem.Execute()方法将导致一个工作项被加入到队列中，然后当此工作项被执行时，它又将一个工作项加入到队列中，这会不会引发无限递归？
事实上这正是我们想要的效果。因为一个工作流实例实际上就是一个层层嵌套的递归的结构，这种设计使得执行其顶层Activity对象的Execute()方法时，会将其子Activity所对应的WorkItem加入到队列中加以递归执行。
很明显，对于那些不包容子Activity的Activity，我们应该“打断”这种递归执行的过程。WF4是怎么做到的？
以一个实例来说明更好。 请看以下自定义的Activity:
public sealed class Prompt : CodeActivity
{
public InArgument<string> Text { get; set; }
protected override void Execute(CodeActivityContext context)
{
Console.Write(Text.Get(context));
}
}
注意上述Activity重写了基类CodeActivity的Execute()方法，此方法一执行完毕就会返回。
前面说过，对工作项队列中WorkItem.Execute()方法的调用，最终将转换为对ActivityInstance对象的Execute()方法的调用。而ActivityInstance又包容了最终的Activity对象实例，并将调用转给这一最终对象的InternalExecute()方法，为方便起见，重贴此方法代码如下：
internal void Execute(ActivityExecutor executor, BookmarkManager bookmarkManager)
{
//……
this.Activity.InternalExecute(this, executor, bookmarkManager);
}
在我们的自定义Activity中，没有重写CodeActivity的InternalExecute()方法(事实上也不可能，因为此方法是Sealed的)，所以，被调用的实际上是基类CodeActivity的InternalExecute()方法。以下是CodeActivity的InternalExecute（）方法代码：
internal sealed override void InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
{
//……
this.Execute(context);
//……
}
非常清楚，它应用了多态特性，调用子类重写的Execute()方法，注意，它并没有调用最顶层Activity类所提供的InternalExecute()方法。
所以，问题的关键在于最顶层基类Activity的InternalExecute（）方法，默认情况下，此方法将会通过 ActivityExecutor.ScheduleActivity(）方法的调用将一个工作项加入到队列中，但CodeActivity没调用Activity基类的InternalExecute（）方法而是重写了此方法，所以就打断了“递归”调用链。
小结
不知道朋友们是不是有点昏了，没办法，WF4内部就是有这么多的弯弯绕。
简单地说：
工作流执行时，所有需要被执行的Activity会被封装为一个WorkItem，被放到一个工作项队列中，然后由WF4调度器(其实就是Scheduler类的实例）负责从此队列中取出工作项执行。
工作项的执行可以由线程池中的线程承担。，也可以由调用者线程来承担。
WF4内部的工作原理非常复杂，事实上我们也没有必要了解其每个技术细节。但如果能了解其大致的内部原理还是非常有用的，它能帮助我们避开陷阱，真正地把技术用好。
对于技术，不仅要知其然，还要知其所以然。才能真正拥有了自由。
转载自：http://www.cnblogs.com/bitfan/archive/2009/10/29/1592591.html