Windows Workflow provides the following functionality out of the box:
A visual method of constructing your applications similar to our flowchart in Figure 6-1. This visual approach is more intuitive, can be easier to debug, is easier to unit test with changes in this release (a controversial idea discussed in the following sections), and can be understood by nontechnical users. Of course, developing an application entirely in code has its advantages as well—it is generally easier to test, and developers won't have to learn new ways of writing applications.
More efficient use of server resources. Inactive workflows "sleep" and are "rehydrated" when needed.
Coordination and synchronization. Workflows that make calls to external services may take weeks to receive a reply. By using correlation, we can ensure that returned calls are automatically directed to the correct instance of a workflow, which can then "wake up" and resume its work.
Workflow state that can be persisted even during system downtime and resumed automatically.
The ability to host the workflow designer within your applications for customization and configuration by end users.
Rich debugging and monitoring support.
A common framework for workflow development on the Windows platform. WF is already utilized in flagship products such as Microsoft SharePoint and Dynamics (note these use WF3 at the time of writing). You can even host your workflows in Microsoft's cloud computing platform, Windows Azure (at the time of writing this is not available, but should be in the future).
The ability to assist you with versioning and updating issues (although for the foreseeable future this is never going to be that easy).
Hopefully I have convinced you that workflow is something that you should be interested in. Let's take a closer look.
3.149.247.132