The term workflow is perhaps among the most overloaded words in the realm of software engineering. From Computer Science 101 to the most elaborate business systems, it generally manages to carry weight on many an application design. In the upcoming paragraphs we will address one of the most recent additions to this space -- Windows Workflow Foundation -- and how it will influence service-orientated designs.
Workflows lend themselves to the granular nature of services. In other words, services fulfill a very small unit of work in favor of being reusable for many different scenarios, this in turn creates the possibility of stitching together an innumerable number of outcomes as workflows, so at a very simplistic level a workflow is nothing more than a series of services glued together to fulfill a particular business process.
In the very specific case of services, many approaches have emerged to solve this workflow problem: WSFL (Web Services Flow Language), XLANG (Web Services for Business Process Design) and BPEL (Business Process Execution Language), to name a few.
But while BPEL provides the semantics and depth to orchestrate elaborate Web services scenarios, it's still relegated to a niche status confined to the services world. If you ponder the aspect of creating workflows strictly from services, you will arrive at the very realistic conclusion that workflows in many enterprises require the integration of non-serviceable legacy applications or even non-system human tasks, workflows that would fall beyond the scope of BPEL or any other orchestration technique currently applicable to SOA. In light of this last possibility comes Windows Workflow Foundation.