Windows Workflow Foundation (hereafter referred to as WF) is a new API for writing and executing continuation based “reactive” programs. In brief, this means programs that spend most of their time waiting for external stimulus (reactive); sometimes seconds, sometimes months. The applications can also be passivated (having their execution state persisted in some manner and then removed from memory) and continued at a later date in a different process, thread or even machine. As computer software more and more attempts to accurately model real business processes, this type of functionality becomes absolutely necessary. I have to admit that I was skeptical of WF in the beginning (especially since it was a bit of a late comer to the .NET 3.0 clan), regarding whether it would really be able to offer a scalable and extensible solution. I have built at least one workflow engine in my career and know something of the difficulty in doing such a thing. But, after quite a bit of time working with it and studying its architecture, I can say that I am impressed. It’s not perfect, but it goes a long way to help in solving the real world business problems developers are regularly called in to handle. Below is a chart I put together displaying what I consider to be the major features of the WF:
Over the next several weeks I will be discussing most of these items, along with related topic areas. There is a quite a bit to be said about WF, but I will only be able to hit the main points. If there is something in particular that you would like me to cover, please let me know. If you want to jump in right away or are looking for a great resource on this topic, I highly recommend that you pick up a copy of Essential Windows Workflow Foundation. It is the best book on this technology in my opinion. One of the things I like so much about it is its attention to the architecture of the framework itself. After reading this book you are likely to understand how better to use WF because you understand how WF works and is built. To that note, below is a simple diagram illustrating the general architecture of WF:
The first thing to notice is the host process. WF can execute within any CLR process. This means the runtime can be hosted in Windows apps, Web apps, Web Services, etc. offering a great amount of flexibility in its use. On the top layer of the architecture is a set of standard activities. WF has many activities out of the box that you can use. Workflows are created as composites of these activities along with any custom activities that you build. This is the most common point of extensibility in the architecture and you are really only limited to what you can imagine. These composites are built upon and executed by the runtime layer of the application. The runtime is fairly light weight and contains the minimum functionality needed to execute workflows. It acts as a Service Locator, and thus delegates much of its functionality to the runtime services layer. The runtime loads basic services (such as scheduling and threading) when it starts and can load additional services depending on your needs. These runtime services are the second major point of extensibility in WF programs. You can replace all or some of the standard services with your own implementations and can add new services usable by your custom activities. The capability to customize hosts, activities and services lends to your applications a very supple design that you can feel comfortable building upon.
NEXT POST: WF Hosting and Execution
Posted
02-18-2007 9:31 PM
by
Rob Eisenberg