less is more

I just brought this Marshall half stack home.

It sounds so much sweeter in my living room than my garage. So, at least for today, it will stay there .

My neighbors are in for a treat.

In case you live nearby, the weekend set will definitely include:

1) Sunshine of your love (Cream)
2) Ride On (AC/DC)
3) Blue Jean Blues (ZZ Top)
4) When a Blind Man Cries (Deep Purple)

:-)

Sergey Chub,developer on the WF Designer team, is blogging.

WF blurs the line between design time and runtime authoring/editing of programs. Sergey’s Workflow Manager Application shows the dynamic editing aspects in action.

One of the common requirements for hosting WF in UI apps is to be able to have explicit control of the thread on which the WF program (aka workflow) executes. Applications built using technologies like Windows Forms, WPF or even ASP.NET usually require that the WF program execution must happen under the purview of the System.Threading.SynchronizationContext associated with the specific application thread.

The WF runtime allows the host application to provide a custom threading policy in terms of a scheduler service. The WF runtime asks the scheduler service to run the WF scheduler (which drives the program execution forward) to run the dispatch loop on a thread of its choosing. To that end, WF defines an abstract type System.Workflow.Runtime.Hosting.WorkflowSchedulerService and also provides two concrete implementations of this type. The key point to note is that the host application can provide a custom implementation suitable to the threading model of the overall application. The WF runtime does not treat its own OOB implementations any differently than yours.

Of the two scheduler services the WF provides in the System.Workflow.Runtime.Hosting namespace,
1) DefaultWorkflowSchedulerService relies on the CLR thread pool to service WF’s dispatch loop. This is clearly not ideal for WPF/ASP/WinForms based apps since it requires the host application to manually do the job of switching the synch contexts while interacting with the workflow.
2) ManualWorkflowSchedulerService exposes a method called RunWorkflow which the host application calls explicitly to run the WF dispatch loop on a specific host thread. This option works great with the UI applications. However, the host application has to call the ManualWorkflowSchedulerService.RunWorkflow explicitly.

Following snippets show of a synchronization context aware implementation of WF scheduler service which tries to address these issues. Currently all three programming models – Windows Forms, WPF and ASP.NET provide an implementation of CLR’s SynchronizationContext. (WinForms and WPF set it on the UI thread and ASP on the request thread).

using System;
using System.Threading;
using System.Workflow.Runtime.Hosting;
using System.Collections.Generic;

namespace EssentialWF.Services {

public sealed class SynchronizationContextSchedulerService : WorkflowSchedulerService {
    bool synchronousDispatch = true;
    Dictionary<Guid, Timer> timers = new Dictionary<Guid, Timer>();
    SynchronizationContext originalContext = null;
    public SynchronizationContextSchedulerService() : this(true)  {}
    public SynchronizationContextSchedulerService(bool synchronousDispatch) {
      this.originalContext = SynchronizationContext.Current;
      this.synchronousDispatch = synchronousDispatch;
    }
    public bool SynchronousDispatch {
      get { return this.synchronousDispatch; }
    }
    protected override void Schedule(WaitCallback callback, Guid
             workflowInstanceId) {
       //if the captured context on the thread that created the WF  
       //runtime is null, try obtaining the Synch Context of
       //the current thread
      SynchronizationContext ctx = this.originalContext != null ?
          this.originalContext : SynchronizationContext.Current;
      if (ctx != null) {
        if (this.SynchronousDispatch)
          ctx.Send(delegate {callback(workflowInstanceId);
                }, null);
        else
          ctx.Post(delegate {callback(workflowInstanceId);
                }, null);
      }
      else //run the scheduler’s dispatch loop w/o a synch context
        callback(workflowInstanceId);
    }
    protected override void Schedule(WaitCallback callback, Guid
      workflowInstanceId, DateTime whenUtc, Guid timerId) {
      DateTime now = DateTime.UtcNow;
      TimeSpan span = (whenUtc > now) ?
                  whenUtc - now : TimeSpan.Zero;
      this.timers.Add(timerId, new Timer(delegate
        {this.Schedule(callback, workflowInstanceId);},
          timerId, span, new TimeSpan(Timeout.Infinite)));
    }
    protected override void Cancel(Guid timerGuid) {
      ((IDisposable)this.timers[timerGuid]).Dispose();
      this.timers.Remove(timerGuid);
    }
    protected override void OnStopped() {
      foreach (Timer timer in this.timers.Values)
        ((IDisposable)timer).Dispose();
      this.timers.Clear();
      base.OnStopped();
    }
  }
}
Finally, you need to add the service to the WF runtime container, like so:

using (WorkflowRuntime runtime = new WorkflowRuntime()) {
  runtime.AddService(new SynchronizationContextSchedulerService());
  …
 
  WorkflowInstance handle = runtime.CreateWorkflow(readerXoml);
  handle.Start(); //this call will block, since we chose synch dispatch
       
   …
}

Enjoy!

p.s. Thanks to Jon Flanders for testing the code out.

Earlier this year, during the book writing process (inspired from an all time favorite of mine), I collected code snippets with a view to use them as quotes at the beginning of each chapter. Each snippet represented a time in the WF project history or a specific design discussion or a bug.

Eventually, during the final editing of the book we decided to take them out. But here they are:

1)
class Program {
  static void Main() {
    Document doc = new Document(@”c:\winoe programming model.doc”);
   
    send(”cookie”, doc);
    Document feedback = receive(”cookie”);
    …
  }
}
  –Anonymous, July 28 2003, Redmond, WA

2)
public sealed class Runaway: Activity {
  protected override ActivityExecutionStatus
    Execute(ActivityExecutionContext aec) {  
     return ActivityExecutionStatus.Executing;
  }
}
  –Anonymous, March 15, 2004 Redmond, WA 

3)
public sealed class Stuck: Activity {
  protected override ActivityExecutionStatus
        Execute(ActivityExecutionContext context) {
      throw new InvalidOperationException();
  }
  protected override ActivityExecutionStatus HandleFault(
        ActivityExecutionContext context, Exception exception) {
     
      Console.WriteLine(exception.InnerException.Message);
      return ActivityExecutionStatus.Closed;
  }
}
  –Anonymous, August 15 2005, Bellevue, WA 

4)
public sealed class WorkflowRuntime :
       ServiceContainer {…}

  –Anonymous, December 1 2004, Redmond, WA

5)
namespace EssentialWF.ProgramStatements {
    [Serializable]
    public class CallCC: CompoundProgramStatement {…}
}
  –Anonymous, May 31 2006, Sammamish, WA

6)
 [DesignerSerializer(typeof(CLANGSilenceSerializer),
      typeof(CLANGSerializer))]
 public class Silence: Activity {}
  –Anonymous, November 21 2003, Redmond, WA 

7)
    [Check(EnforcementTarget.Children,
         @”activity.Parent.EnabledActivities.IndexOf(activity) > 1 &&  
            (activity.Parent.EnabledActivities
             [activity.Parent.EnabledActivities.IndexOf(activity) - 1].

             ExecutionStatus == ActivityExecutionStatus.Closed)”)]
    protected override ActivityExecutionStatus
       Execute(ActivityExecutionContext executionContext) {
            …
    }
    …
  –Anonymous, December 2005, Redmond, WA 

8)
public sealed class MythicalRuntime : ServiceContainer {
    …
  public ProgramHandle ActivateInstance(Uri blueprint){…}
  public ProgramHandle RestoreInstance(Guid durableHandle){…}
}
  –Anonymous, February 2004, Sammamish, WA