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:
Why do I need it?
Why does Microsoft feel it's so important to learn this new WF framework?
What problems does WF make easier to solve to justify the non-trivial ramp up time for my team and me?
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.
Account Creation: The system will allow clients to create accounts either by coming into a branch where an employee can create the account via a thick client application or by allowing the client to create the account via a website.
Income Tax Information Submission: The system will allow clients to submit income tax-related information for review by an accountant either in a branch office or on the Web.
Management of Assigning of Clients to Accountants: The system will allow for the automated assigning of clients to accountants with support for manual updating of assignments.
Managing the Approval Process: The system will allow for managing the review and approval process involved in preparing income tax papers for submission to the IRS, including management of requesting more information from clients, following up with clients, and routing information received from clients to correct accounts.
Notifications: The system will allow for notifying clients of various account and tax submission-related events.
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:
Creating of a client account
Submitting income tax information for an existing account
Querying for income tax submissions assigned to an accountant
Querying for a specific tax submission
Requesting more information from the client about an income tax submission
Approving the information submitted to indicate that the income tax information is complete and ready for an accountant to make an income tax return to be submitted to the IRS
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 receive their information
We approve or reject their information
We need to request more information
We've submitted their taxes to the IRS
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:
Creating accounts
Submitting tax data
Assigning accountants to clients
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:
Build our workflow logic in a unified way
Execute our workflow logic in a distributed way, across several servers
Allow for easy sharing of and persisting of state without having to worry about concurrency
Allow for easily creating events or messages that can drive business logic, including support for scheduling these events or messages
Allow us to track the history of an account
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:
A re-hostable designer to allow us to create administration tools for visualizing and managing our workflow logic
Support for parallel processing of tasks
Support for creating our own workflow constructs (or activities) to allow us to model our own domain-specific languages
An extensible architecture that allows us to provide our own implementations for things such as state persistence, workflow execution tracking, threading, and so on
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