Microsoft has been putting a lot of resources toward the development of Windows Workflow Foundation (WF). Therefore, before learning this new framework, it's important to understand why Microsoft feels it is so important. For WF 4.0, Microsoft went back to the drawing board and did a complete rewrite of WF technology with the goals of improving WF 3.5 by providing a WF framework that simplifies the development of workflow-based solutions and provides better performance. Microsoft's ultimate goal is to get a higher rate of adoption of WF and to attempt to make WF an essential component of the enterprise developer's tool kit. The questions that most developers and architects, who are first exposed to workflow, will be likely to have are:

These are the questions that need to be answered before you start to learn the details of how to use the WF framework, as learning WF is not a small task and understanding the benefits would go a long way in helping motivate you and your team. This section of the book will help you better understand the "WHYs" of WF and lay the foundation for the rest of the book, which will allow you to hit the ground running by getting up to speed on the "HOWs" of WF. This book consists of short, easy-to-understand examples (or recipes) that show how to take advantage of the many benefits of WF. Your first read will allow you to get familiar with all the various features and extensibility points of the WF 4.0 framework and, as you implement WF 4.0 based solutions, you will find yourself coming back again and again to review these concise, easy-to-understand WF recipes. After reading this short book, you will be ready to simplify your enterprise development architectures by taking advantage of this powerful new workflow framework and all of its built-in, out-of-the-box features.

Let's get to it then… Why workflow? For starters, what kinds of problems does workflow make easier to solve? Let's suppose you need to build a solution for an accounting firm and that firm wants to have a system built to allow them to provide income tax services. This system needs to support the following features.

How would a system like this be built without using a workflow framework? Our first attempt might be to create a set of web services that support:

This income tax process could take several weeks or months to complete and so it's not feasible that we could have a thread on the server waiting for the next input for an account to arrive. For this application to scale and work with any type of realistic enterprise volume, we'd have to persist the state of the account and when each web service request arrives, we'd have to take some kind of identifier (account ID or accountant ID) and retrieve the current state of the account before we could determine if the call could proceed. A client can't submit income tax information before they've created an account and the service for submitting income tax information would have to query our persistence store (database or whatever we are using) to verify this. All of this custom state-management code that would allow for sharing the account data among the various client applications from the various servers would need to be written by the developers including ways to deal with concurrency. We can't allow two clients to update the same data at the same time, so we'd have to provide for that in our implementation.

Assuming we get all that worked out, what about the parts of this process that aren't driven by web-services calls? How are we going to assign clients to accounts after they submit their tax forms? How are we going manage our notifications that will be sent to the clients when:

We'd also need to build a scheduling system and an event routing (or messaging) system to help us satisfy these needs.

How do we deal with scalability? One solution would be to break apart the functional components of the application and deploy each one to a different server or set of servers so that you'd have a server for:

Using this approach would allow us to scale but would make the application logic separated and hard to understand and maintain, as it would be spread over several deployments on different servers.

The ideal solution would be to have a framework that would allow us to:

If we had a framework that allowed for all these things, then it might be worth our time to go out and learn how to use that new workflow framework as it would provide us a lot of built-in benefits that would save us from having to reinvent the wheel over and over again. The good news is that this is only part of what Workflow Foundation provides. In addition to helping solve these problems, WF also provides:

Given all that WF 4.0 brings to the table, it's a worthwhile investment to learn this technology and add it to your enterprise development toolkit, and this book will help to get you up to speed in a very short amount of time.

Ryan Vice

MVP for Connected Systems