Reasons to Use Workflows
Why would you want to use workflows for programming? One answer is: You might not. For simple programs that run for a brief time, there may be no good reason to use workflows. However, as the complexity of programs increases, code usually becomes correspondingly harder to understand and maintain. Workflow diagrams are typically much easier to understand than source code. If you extend the idea one step further, and make the diagrams executable artifacts rather than mere documentation, you gain not only the advantages of a simpler format and easier maintenance, butunlike old-fashioned flow chartsyou can rely on executable diagrams to be current.
State machines can be quite complex to program by hand. Furthermore, there's a disconnect between "application time" and "human time." Machines typically process instructions extremely quickly, but in a business process controlled by humans, the various states involved in the application may persist unchanged for days or weeks. Moreover, state transitions typically require human input and approval. A workflow engine that automatically saves and restores persistent states as needed and solicits human input and approval automatically and securely can save a tremendous amount of programming time and make the entire process more reliable.
Other Workflow Languages and Engines
The Business Process Execution Language (BPEL) is a widely supported standard for workflow description at the "orchestration" level, meaning that it is for "programming in the large." About 30 vendors, including Microsoft, IBM, Oracle, SAP, and Sun, have implementations of BPEL. Microsoft's current BPEL product is BizTalk Server 2006. A future version of BizTalk Server will incorporate Windows Workflow Foundation.
Other workflow languages include Workflow OSID , Job Definition Format , YAWL , BPML , SWSL , and XPDL . Several of these are based on Petri nets. Workflow languages remain an active research and development area, especially for scientific applications in areas like bioinformatics and particle physics.
Defining Windows Workflow Foundation
Windows Workflow Foundation is a development framework that enables you to embed workflows in .NET Framework applications. It's not a language, per se, as much as a framework. It directly supports a workflow markup language based on XML, as well as C# and Visual Basic. Other .NET languages can be used as well, but currently the Visual Studio designer supports only C# and Visual Basic.
Goals and Characteristics of WWF
WF was designed to meet four major goals. It should:
- Provide one workflow execution engine for any application that runs on Windows.
- Support a wide range of workflow scenarios.
- Add workflow to the .NET Framework in a natural, easily learned way.
- Enable reusable workflow component development.
WF, unlike BizTalk, is an in-process
workflow engine. It manages the flow of a .NET program, which lets any .NET AppDomain host WF, whether it's a console application, a Windows application, or an ASP.NET Web application. The basic unit in a workflow is called an activity
. WF has about 40 built-in activities and full support for custom activities. Some of the built-in activities provide the equivalents of a programming language's control flow statements: Sequence
, Conditioned Activity Group
, and Delay
. Other built-in activities support interactions with the host program, such as listening for events, or invoking Web services.
WF has several built-in runtime services that support running workflows, including scheduling, compensating transactions, persistence, and tracking operations. WF also has a plug-in model that allows you to extend the existing base services or create your own new custom services.
Types of Workflows
The three major types of WF workflows are sequential, state machine, and data-driven. In a sequential workflow, as in the flowchart shown in Figure 1, the workflow is in control.
In a state machine workflow, events cause transitions between states, so the workflow is not in control. Instead, the external environment is in control, which often means that users determine the flow by their actions. For example, in the accounts payable example described earlier, users make decisions that affect the process flow, so that's a natural candidate for a state machine.
In a data-driven workflow, some data controls the flow; this often happens within some part of a larger sequential or state-machine workflow, using a Constrained Activity Group, and/or a Policy activity. For example, the Accounts Payable example would check whether the invoice is connected to a valid purchase order and perform a check for sufficient funds, both of which would typically be database lookups.