less is more

You can download the sample code for the activities covered in my book here.

Once I get back from vacation, I’ll also create an errata page for the book on this site.

Essential Windows Workflow Foundation is finally available!

I got my copy yesterday. Both Amazon and Barnes and Noble claim that they are shipping it within 24 hours.

Writing this book was truly a labor of love for us. Hope you will like it.

Last week was fun. The after-work time was filled with some old/new technology tinkering.

1) Bought a new iMac 24’’ home. Wrote my first Cocoa/ObjC app.
2) Did a whole bunch of COM programming – ROT, Monikers, custom marshaling… Old habits…
3) Played with WPF/E.
4) Played with Amazon web services.
All this was made even more enjoyable by Gnarls Barkley playing in the background.

Now, back to work.

Chapter 3, “Activity Execution”, is now available for download.

Also, I have created a separate page for all things related to Essential WF.

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.

This weekend, I worked on a little demo that embeds a WF workflow within an Excel app.

The Excel spreadsheet, in my demo, is shared among a set of users. Based on the gestures/actions performed by the users, the embedded WF program instance (i.e. workflow) executes forward. My Excel app hosts the WF runtime.

Upon passivation, the WF program instance state is serialized automatically as a part of the Excel app. I even embdeded the program XAML in the spreadsheet to make it self contained. 

In the process, I played quite a bit with VSTO. I really liked the way it simplifies Office programming and especially liked its cached data feature.

Implementing first class continuations on the runtimes like the CLR and JVM which lack any intrinsic support for it, is a non trivial task (especially saving and reinstalling the stack). The Northeastern Scheme folks have used the CLR’s exception handling machinery to implement continuations on the CLR. Read it here and here. Joe Duffy calls it a “beautiful hack” and I couldn’t agree more.

Download WF and WCF Beta2 today!

You can also deploy apps built with WF/WCF Beta2 bits using the Go Live license.

WF Beta2 is a huge improvement over the previous release in terms of stability, perf and a slew of features including a much refined programming model, tighter execution model, proper alignment with XAML, designer layout-beside file support etc.

The MSDN piece on WF that Don and I wrote will finally be in synch with the publicly released bits.

Enjoy!

The WF piece which Don and I wrote for MSDN Magazine went live today. It’s based on early beta2 of WF. Hope you enjoy it!