Workflow Hosting Architecture
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The workflow functionality in Windows SharePoint Services 3.0 is built on the Microsoft Windows Workflow Foundation (WF), a Microsoft Windows platform component that provides a programming framework and tools for development and execution of workflow-based applications. Specifically, Windows SharePoint Services 3.0 uses two components provided by WF: the Visual Studio 2005 Designer for Windows Workflow Foundation and the WF runtime engine.
Visual Studio 2005 Designer for Windows Workflow Foundation
The Visual Studio 2005 Designer for Windows Workflow Foundation is an add-in hosted within Microsoft Visual Studio 2005 that enables developers to create their own custom workflows and workflow activities. WWF 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 2005 Designer for Windows Workflow Foundation provides an intuitive, graphical design surface that developers can use to easily assemble and configure pre-defined activities into custom workflow. Workflow authors use and extend the workflow model in the same way they use and extend other elements of the Microsoft .NET Framework.
For more information, see Visual Studio 2005 Designer for Windows Workflow Foundation Overview.
Windows Workflow Foundation (WF) 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 Windows SharePoint Services 3.0 workflows, Windows SharePoint Services 3.0 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.
Windows SharePoint Services 3.0 hosts the WF runtime engine. In place of the pluggable services that are included with WF, Windows SharePoint Services 3.0 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 Windows SharePoint Services 3.0.
The figure below illustrates the workflow architecture in Windows SharePoint Services 3.0. Windows SharePoint Services hosts the WF runtime engine within its process, and provides custom implementations of the necessary services. The functionality of the WF runtime engine, as well as the hosting functionality Windows SharePoint Services 3.0 provides, is exposed through the Windows SharePoint Services 3.0 object model.
.gif)
For more information on using Windows Workflow Foundation technologies, visit the Windows Workflow Foundation Developer Center.
Workflow Persistence
One of the most important services Windows SharePoint Services 3.0 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 Office scenarios, workflow will typically take days, if not longer. 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 their execution is not feasible; very soon the resources required by accumulated long-running workflows would bring the system to a halt.
Instead, once a workflow instance has reached a point at which it is waiting for user input, Windows SharePoint Services 3.0 unloads that workflow instance from memory and persists its data. Then, when an appropriate event, such as the user entering input, requires that the workflow instance start again, Windows SharePoint Services 3.0 re-instantiates the workflow instance using the 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 given time, only a fraction of those workflows may actually be in memory and using system resources.