Most businesses require processes to function properly. There are different types of processes. Some processes are human-intensive, others machine-intensive, and the last type is a combination of the first two. Some examples of business processes are payroll, new product introductions, new employee hiring, etc. In most cases, these business processes require intervention from multiple entities and thus, are normally long running.

 Workflow is one of the mechanisms used by businesses to express their business processes as a series of self-contained activities. Business Process Management (BPM) systems provided an environment for developers to create, execute, and manage workflows. These workflows are normally expressed using Finite State Machine (FSM), Unified Modeling Language (UML) Activity Diagrams, UML Swim Lanes, or Flow Charts.

Microsoft announced at PDC the unveiling of the Microsoft Windows Workflow Foundation (WF) technology. This technology complements the .NET Framework with a group of workflow-related components that allow developers the ability to define, compile, instantiate, debug, and track workflows. This technology will become part of WinFX together with Windows Presentation Foundation, and Windows Communication Foundation.

Development Paradigm
Using Workflow Foundation (WF) workflows, developers can incorporate concepts like scheduling, task coordination, and escalation into their existing applications for free. WF provides the base platform where ISVs can develop process-rich applications. While Microsoft Visual Studio is not required to develop WF workflows, it provides some really cool capabilities such as a visual designer, Visual Studio workflow templates, and visual debugging, which make it easier to develop workflow-rich applications. WF workflows are developed using markup (XML as shown in Figure 1), just code (C# and Visual Basic.NET as shown in Figure 2), and markup with code separation (C# and Visual Basic.NET as shown in Figure 3). They are packaged into an assembly i.e., workflow library when compiled and require a host application in order to be executed. Host applications can vary from console applications (exe), Windows services, HTTP modules, or server applications like SharePoint Services 12. Other products such as Microsoft BizTalk Server and Microsoft Dynamics AX plan to use the WF platform in future releases.

WF workflows are composed using activities. Activities represent discreet pieces of functionality that are used to run specific business activities. There are two types of activities: composite and individual activities. Composite activities are used to express control statements (i.e., While, For, If-Then-Else, Case, etc.) and for grouping activities that share behavior (i.e., Sequences, Conditioned Activity Groups, etc.). Also, these activities are used to develop reusable sub-processes or sub-workflows. On the opposite side, individual activities provide a mechanism for expressing single pieces of work that need to be executed in the same step in the workflow. Activities in general can have properties and handlers. Handlers are executed synchronously or asynchronously, depending on their definition. Activities represent the smallest building block available to developers to extend the workflow framework. WF provides a base activity library set that can be used by developers to build new applications, or as the baseline for creating new activities. This library represents the minimum set of extensible activities required to build workflows.

The workflow run time is responsible for taking workflow definitions and instantiating them. The life cycle of the workflow instances are managed by the workflow runtime. It is responsible for creating, executing, threading, persisting, tracking, communicating execution events, and coordinating transactions. These functions are managed by the workflow run time via services. There is a set of default services that the run time uses to manage all of its workflow instances, threading, transactions, tracking, state management, etc. Application developers responsible for integrating workflows into their existing applications can overwrite these services. Using this service model, developers are able to expose their existing hosting infrastructure to the workflow library. The framework provides a set of out-of-box services that allow developers to quickly start using the environment without worrying about having to write complicated code. The out-of-box services are instantiated and registered directly with the run time as shown in Figure 4.

Developer Types
These system boundaries give way to three types of developers: host, activity, and workflow developers as shown in Figure 5. Host developers are responsible for providing an execution environment that uses the workflow run-time components to instantiate workflows. Host applications need communication contracts in order to define local protocols between the host application and the workflow library. Also, host developers are responsible for registering workflow services with the workflow run time and for registering out-of-box services with the workflow run time. However, there are situations in which out-of-box services do not suffice for the required needs of host applications. These services establish the quality of services shared by workflow instances. For that reason, the workflow framework provides a mechanism to create new services through inheritance.

Activity developers create self-contained logical components that are intended for use by workflow developers to create workflow libraries. Activities can be designed to work on multiple host applications or could be tailored to a specific host. These components can be self-contained (i.e., black boxed) or could allow code-separation handlers to be defined by workflow developers. Activities tailored to a specific host normally take advantage of local communication protocols and specialized services defined by the host application.

Workflow developers leverage the work of activity and host developers to construct workflows. They are responsible for using out-of-box activity libraries and custom activity libraries to create workflow definitions. The majority of these developers leverage graphical tools to construct workflow graphs. However, the types of development environments could range from non-code environments like Microsoft FrontPage to code-rich environments like Microsoft Visual Studio.

Framework Capabilities
Support for long-running workflows is another major feature of Microsoft Windows Workflow. WF provides the required infrastructure to support the execution of long-running workflows. These workflows rely on persistence, transactions, tracking, and host processing to fulfill their tasks. When the workflow is idle, waiting for information from users or systems, it is automatically persisted and removed from memory to reduce resource consumption.

The persistence services provide a default state management services for Microsoft SQL Server (i.e., SqlStatePersistenceService class). Schemas and store procedures are provided for these services and allow the service database to live in another database. The reason for these services is to facilitate the long-running nature of these applications and to provide an automated persistence level to the workflow state.

Timer services are also provided to support management of date-base triggers. Persisting timers ensures that date/time triggers can be relied on for execution if the time hasn't expired. The out-of-box timer services also leverage the Microsoft SQL Server database (i.e., SqlTimerService class). Imagine a scenario where you want to escalate a message after four hours have passed without any intervention and the system goes down before the time has expired. Using persisted timers together with state persistence enables the developer to not have to worry about losing timers and not worry about having to fire events when timers expire.

Tracking provides a default mechanism for generating audit trails and recording historical information. This information can be in-memory or persisted to the database. The out-of-box tracking service also leverages a Microsoft SQL Server database to manipulate the tracking information (SQLTrackingService). The tracking information captures the activity name, times the activity that was executed, and when the various states of the activities are executed. Tracking profiles can be defined to capture a subset of the tracking data. This information can be tailored to capture specific activity status changes, activity property information, and workflow instance data.