WF4 Beta2 工作原理

最顶层的Activity类提供了一个可以供子类重写的InternalExecute()方法:

internal virtual void InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager);

         子类可以重写此方法,在此方法中实现各种功能,这个方法在WF4内部非常重要,许多东西都与它相关。

         为了方便地供开发者自定义业务处理逻辑,诸如CodeActivity之类最底层的类,另定义了一个抽象的Execute()方法:

protected abstract void Execute(CodeActivityContext context);

         当开发者自定义Activity时,就可以直接地重写此方法。

         简言之,工作流的运行就体现为Activity对象树中叶子节点Execute方法(或类似的方法,比如DynamicActivityInternalExecute方法,AsyncCodeActivityBeginExecuteEndExecute方法)的执行

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;

         初始时,为队列分配可容纳4T类型对象的内存空间,当不断增加对象而需要扩充空间时,就分配一个“当前所占内存空间*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);

}

         上述声明中还有两个很重要的类ActivityInstanceActivityExecutor

         ActivityInstance代表着正在运行的一个Activity实例包容一堆的internal方法可以完成Activity的执行(Execute)取消(Cancel)和放弃(Abort)的功能。 ActivityExecutor则负责调用ActivityInstance中的这些       方法。

         WorkItem有一堆的子类,这些子类又派生出“孙”类。比如,其中的一个分支如下:

       WF4 Beta2 工作原理

不管有几个子孙,后代一般都重写了WorkItem所定义的Execute()抽象方法。

         我们以ExecuteRootWorkItem类为例,顾名思义,这应该是与工作流中最顶层的Activity相对应的WorkItem。它的Execute()方法如下所示:

public override bool Execute(ActivityExecutor executor, BookmarkManager bookmarkManager)

{

    return base.ExecuteBody(executor, bookmarkManager, this.resultLocation);

}

         它将调用基类ExecuteActivityWorkItemExecuteBody()方法,此方法的关键代码如下:

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);

    //……

}

ActivityExecutorOnExecuteWorkItem()方法有很多代码,其中关键的就是以下这几句:

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加入到队列中加以递归执行。

         很明显,对于那些不包容子ActivityActivity,我们应该“打断”这种递归执行的过程。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重写了基类CodeActivityExecute()方法,此方法一执行完毕就会返回。

         前面说过,对工作项队列中WorkItem.Execute()方法的调用,最终将转换为对ActivityInstance对象的Execute()方法的调用。而ActivityInstance又包容了最终的Activity对象实例,并将调用转给这一最终对象的InternalExecute()方法,为方便起见,重贴此方法代码如下:

internal void Execute(ActivityExecutor executor, BookmarkManager bookmarkManager)

{

    //……

    this.Activity.InternalExecute(this, executor, bookmarkManager);

}

         在我们的自定义Activity中,没有重写CodeActivityInternalExecute()方法(事实上也不可能,因为此方法是Sealed),所以,被调用的实际上是基类CodeActivityInternalExecute()方法。以下是CodeActivityInternalExecute()方法代码:

internal sealed override void InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)

{

    //……

    this.Execute(context);

    //……

}

         非常清楚,它应用了多态特性,调用子类重写的Execute()方法,注意,它并没有调用最顶层Activity类所提供的InternalExecute()方法。

         所以,问题的关键在于最顶层基类ActivityInternalExecute()方法,默认情况下,此方法将会通过 ActivityExecutor.ScheduleActivity()方法的调用将一个工作项加入到队列中,但CodeActivity没调用Activity基类的InternalExecute()方法而是重写了此方法,所以就打断了“递归”调用链。

小结

不知道朋友们是不是有点昏了,没办法,WF4内部就是有这么多的弯弯绕。         

简单地说:

  工作流执行时,所有需要被执行的Activity会被封装为一个WorkItem,被放到一个工作项队列中,然后由WF4调度器(其实就是Scheduler类的实例)负责从此队列中取出工作项执行。

    工作项的执行可以由线程池中的线程承担。,也可以由调用者线程来承担。

     WF4内部的工作原理非常复杂,事实上我们也没有必要了解其每个技术细节。但如果能了解其大致的内部原理还是非常有用的,它能帮助我们避开陷阱,真正地把技术用好。

       对于技术,不仅要知其然,还要知其所以然。才能真正拥有了自由。 

转载自:http://www.cnblogs.com/bitfan/archive/2009/10/29/1592591.html 
 

你可能感兴趣的:(工作原理)