I've been thinking about some fundamental differences between WF and a few 3rd party workflow tools (Metastorm, Bluespring Software and others). In WF, describing a workflow process is conceptually similar to designing a Windows form.  Utilizing the Visual Studio design time capabilities of activity classes we can configure our model. Code-behind implements the configuration and is eventually compiled into a "runnable" workflow. The 3rd party tools I've worked with provide a more explicit seperation of the process description metadata and the workflow engine runtime. Generally a process description tool allows the process to be modelled and published to a persistant store. At runtime, the workflow engine utilizes this metadata to execute an instance of a workflow.

Initially the WF approach seemed flawed. I instictively felt it was Microsoft's bias that everything should be source code and modelled in Visual Studio. But the more I've thought about it the more I l ...

Welcome to my first blog. My intent is to inject some technical ideas and experiences into the general "noise" of technical blogs that permeate the internet. For now I'll assume I'm the only reader (or at the most my Stong Point partners). Currently I've been looking at Windows Workflow and trying to figure out what it is and what it does. I've concluded MSDN is not the place to start. After logging a number of hours browsing MSDN, I realized I'm either getting too old to learn something new or the MSDN topics are an after thought. I purchased a book from Amazon and am relieved that WF is understandable. The book is titled "Windows Workflow Foundation" by K. Scott Allen. It provides a concise and logical discussion of WF and it's application to some basic problems. At this point I expect many of my fut ...