Workflow Hosting Architecture
Applies to: SharePoint Foundation 2010
The workflow functionality in Microsoft SharePoint Foundation 2010 is built on the Microsoft Windows Workflow Foundation (WF), a Windows platform component that provides a programming framework and tools for development and execution of workflow-based applications. Specifically, SharePoint Foundation 2010 uses two components provided by Windows Workflow Foundation: the Visual Studio 2010 Workflow Designer and the WF runtime engine.
Visual Studio Designer for Windows Workflow Foundation
The Visual Studio 2010 Workflow Designer is hosted within Microsoft Visual Studio and enables developers to create their own custom workflows and workflow activities. Windows Workflow Foundation provides a workflow model to allow developers to describe the flow of a business process. Workflows can be authored using graphical construction, XML specification, code, or a combination of these. The Visual Studio 2010 Workflow Designer provides an intuitive, graphical design surface that developers can use to easily assemble and configure predefined activities into a custom workflow. Workflow authors use and extend the workflow model in the same way they use and extend other elements of theMicrosoft .NET Framework.
For more information, see Visual Studio Designer for Windows Workflow Foundation Overview.
Windows Workflow Foundation Runtime Engine
The WF runtime engine manages workflow execution and allows workflows to remain active for long periods of time and survive machine reboots. Run-time services provide core services, such as transactions and persistence, to the run-time engine. WF allows any application process or service container to run workflows by hosting WF; that is, loading WF within its process. When you author Microsoft SharePoint Foundation 2010 workflows, SharePoint Foundation 2010 is the host for WF.
The WF runtime engine provides the services that every workflow application needs, such as sequencing, state management, tracking capabilities, and transaction support. The WF engine serves as a state machine responsible for loading and unloading workflow templates, as well as managing the current state of any workflows that are running.
SharePoint Foundation 2010 hosts the WF runtime engine. In place of the pluggable services that are included with WF, SharePoint Foundation 2010 provides custom implementations of the following services for the engine: transaction, persistence, notifications, roles, tracking, and messaging. Developers can then create workflow solutions based on SharePoint Foundation 2010.
For more information about using Windows Workflow Foundation technologies, visit the Windows Workflow Foundation Developer Center.
Workflow Persistence
One of the most important services SharePoint Foundation 2010 provides the WF workflow engine is that of persistence. Workflows that include human interaction are inherently long running; even in ideal circumstances, humans take a relatively long time to complete work compared to machines. In many scenarios, workflows can typically take days or even weeks. Consider the example workflow that routes documents for approval. It might take several days for the approver to get to the task of reviewing the document.
Clearly, leaving each running workflow in memory for the entire duration of its execution is not feasible; very soon the resources required by accumulated long-running workflows would bring the system to a halt.
Instead, with Windows Workflow Foundation, when a workflow instance has reached a point at which it is waiting for user input, SharePoint Foundation 2010 unloads that workflow instance from memory and persists its data. Then, when an appropriate event occurs that requires that the workflow instance to start again, such as when a user enters input, , SharePoint Foundation 2010 re-instantiates the workflow instance by using persisted data, so the workflow instance can receive and handle the event as necessary.
So, while there may be numerous workflow instances running at any specified time, only a fraction of those workflows may actually be in memory and using system resources.