My side project TextFlow is coming along nicely... I've still got a lot of work to do there, but it's surprisingly functional for something I've only been tinkering around with for a few weeks.

TextFlow is (among other things) a language compiler that generates Windows Workflow programs from a text-based language syntax. Those familiar with WF will know that ordinarily you create WF programs from code, or using XAML. I like the idea of using a language syntax as yet another means to define workflows... some potential workflow authors will be comfortable neither with code or XAML; the graphical WF designer can help here, but even that requires either Visual Studio, SharePoint Designer (which has a crippled graphical workflow designer, and is SharePoint-specific to boot), or you need to host the WF designer in your own app.

WF is a somewhat under-utilized and misunderstood technology, IMO. There are several reasons for this... confusion with Biztalk, lack of prescriptive guidance on implementing systems using WF, the fact that once you get beyond the graphical designer the sexiness factor goes way down (but that's precisely when a technology like WF starts to shine). It's plumbing, and plumbing isn't very sexy.

Another difficulty with WF adoption is audience. WF is plumbing, and is ideally used to provide higher-order abstractions through which business users can express intent. But those business users can't express their intent without the abstractions in place; waiting for programmers to recognize this deficiency on their own and do something about it is mostly a non-starter. You get what we have today... most higher-order workflow logic is expressed as low-level control flow in languages like C# or Java. Enter TextFlow.

TextFlow is (hopefully) one example of these higher-order abstractions. It's intended to be more approachable and business-user-friendly than writing .NET code (certainly) or interacting with the workflow designer (hopefully). It's also intended to be more powerful and general-purpose than the SharePoint Designer.

As I've said, the key characteristic of TextFlow is that it compiles down to a WF program, instead of a "raw" CLR assembly. What this means is that, when a TextFlow program is compiled, the output is an in-memory .NET object graph that represents the logical sequence of actions described by the original syntax. This in-memory graph can be executed, serialized into XAML, or even displayed in the WF designer.

So one obvious question is "why would you compile to WF, instead of the CLR itself?" Great question!

Advantages of compiling to WF

1. WF allows you to work at a higher level of abstraction when writing your compiler. For example, control flow is built into WF via a set of pre-canned atomic elements (activities); if your language syntax has looping or branching constructs (as most will), its trivial to use WhileActivity or IfElseActivity (among others) to realize these. To do the same in MSIL is entirely possible, but arguably more difficult and tedious (though admittedly well documented). In effect, the WF "opcodes" (activities) more directly translate to procedural language constructs than do IL opcodes.
2. The CLR is a huge leap forward for language designers and compiler writers because of the set of built-in services; garbage collection, a unified type system, a ubiquitous security model, etc. Platforms can leverage these services instead of writing them over and over again. The WF infrastructure leverages the basic CLR services, but also provides an array of services above and beyond the CLR that are powerful and easily leveraged from your own WF-targeting language:
   • inherent support for transactions and compensation
   • inherent support for long-running workflows, where periods of inactivity (waiting for human input, etc.) result in automatic serialization of the workflow to a persistent store
   • the ability for workflow execution to load-balance across multiple machines, so that a single workflow instance might hop from machine to machine during its lifetime
   • the ability to pause or cancel running workflows
   • the ability to modify the inherent logic of a running workflow
3. The extensibility model of WF is a big win for compiler writers, too. The atomic unit of execution in WF is an Activity; there are many pre-defined Activities shipped with WF, but it's trivial to create your own, too. In essence, if you're writing a compiler that targets WF, you can extend the set of opcodes that your compiler supports! Try that with MSIL! Another great thing about this is that the built-in activities have no special significance to the WF runtime; they don't leverage any "hidden" APIs that are unavailable to yours, etc.

Disadvantages of compiling to WF

1. WF doesn't offer much help if you want to expose a user-extensible type system from your language. As I mentioned above, you can certainly create your own custom Activity types and execute them in WF; but definition of your Activities is done via traditional subclassing of the .NET Activity class. WF has no magical CreateNewActivityType() method to help you here. So, WF is most appropriately targeted by procedural languages where the emphasis is on control flow and sequences of actions, as opposed to more pure OO-style languages (for the record, I think targeting WF with an OO language is possible... you've just got more typing ahead of you ).
2. I hesitate to mention this, because most obsessing over software performance is misguided and misinformed... but it's true that WF will impose some performance tax on your code, relative to execution of equivalent logic directly against the CLR. I have no numbers to quote you (and wouldn't do it even if I did), but it stands to reason that since WF is in essence a virtual machine running on the CLR, there will be some performance penalty, even if small. That said... if you're launching the space shuttle or doing DirectX 3D graphics, you probably shouldn't be running on WF anyway. For true workflow-style programs that interact with external systems and (gasp!) actual users, whatever performance penalty may exist is totally dwarfed by the benefits provided by the platform. If your workflow program sends an email to a user and waits two weeks for a response before then proceeding with execution, who cares if the email was sent in 50ms or 5 seconds???
3. One final thing to note... to truly take advantage of WF by compiling to it from your language, you'll obviously need a firm grasp of the semantics and underpinnings of the WF runtime and ancillary services. And since WF runs atop the CLR, you really need a similar grasp of the basic CLR services, too. So in all fairness, the barrier to entry isn't small; but neither is it insurmountable. In fact, I would venture to say that if you're capable of designing a language and writing a compiler, then grokking WF isn't going to seem like a big deal.

There's more to say, but that's a start. I highly recommend Essential Windows Workflow Foundation by Shukla and Schmidt as the definitive guide to WF and its underpinnings.

And if you're intrigued by any of this, I invite you to take a closer look at TextFlow... let me know what you think!