- Describing Workflow and Workflow Systems
- .NET Framework 3.0 and 3.5
- Overview of WF
- Standard Modeling Activities
- Multiple Workflow Styles
- Hosting
- Tracking
- Rule Capabilities
- Custom Activities
- XAML Workflows and Serialization
- Dynamic Update
- WF and WCF
- SharePoint Workflow
- Designer Rehosting and External Modeling
- Summary
- Installation Instructions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Hosting
WF is not a standalone application. WF is an engine that executes workflows on behalf of a host application. A Windows Forms, ASP.NET, Windows Service, or other Windows application starts the workflow engine running. The host application is then responsible for managing the life cycle of the workflow engine. The host application must remain active while workflows are running and communicate with the workflow engine. If the host application terminates while workflows are running, they will stop running. The host application needs to know the status of workflows the workflow engine is running on its behalf. It achieves this by subscribing to a number of events the workflow engine makes available to it. Three of the most common are completed, terminated, and idled.
The completed event is fired when a workflow completes processing successfully. The terminated event is fired when the workflow completes unsuccessfully. The idled event means the workflow is not complete but inactive. The workflow in Figure 1.10 would enter the idled state when waiting for a response. In a state machine workflow, the only time the workflow is active is when processing the logic behind an event (Figure 1.12). At other times, it is idle waiting for the next event.
){kind=link}
){kind=link}
How do the workflows receive events if they are idle? This is the job of the workflow engine. It passes the incoming event on to the correct workflow instance. If the workflow is idle, the workflow engine will reactivate it first. This is important because many workflows run for hours, days, or longer. They are generally active only for very short bursts during their lifetime.
In addition to being embeddable in different hosts, the workflow engine must also be configurable to meet the needs of different host applications. For example, when a workflow idles, it should be serialized and stored in a storage medium. If not, a server would hold countless workflow instances over their entire lifetimes. This would devastate scalability and be very risky. If the server went down, the workflows would be lost because they are in memory. This is actually the default behavior of WF because it is not aware of the hosts' needs or capabilities. There may be some scenarios where all workflows have very short life cycles, and no need exists for storage during inactivity. In some environments, such as client scenarios, no SQL Server is available to store the current state of the workflow. For these reasons, WF ships with a number of pluggable services that can be added to the runtime as needed. WF ships with a SQL Server persistence service that can be added. When the persistence service is added, idle workflows are saved to SQL Server. This meets the first criteria—that the service should be available when necessary. It does not meet the second criteria—that the storage medium the workflow is saved to should be flexible. The second option requires extending the base persistence service. It is not available OOB but is an anticipated extensibility point and can be done in a straightforward manner.
Hosting in WF requires starting the engine, choosing which runtime services to add to the runtime, and subscribing to the events you are interested in.
The WorkflowRuntime type in the System.Workflow.Runtime namespace is the workflow engine. The following code demonstrates instantiating the workflow engine (WorkflowRuntime type), adding the persistence service to it, subscribing to the closed event, and starting the workflow engine. This code would be the same regardless of whether the workflow engine was hosted from a Windows Forms, ASP.NET, Windows Service, or other application.
WorkflowRuntime workflowRuntime = new WorkflowRuntime();
workflowRuntime.AddService(sqlPersistenceService);
workflowRuntime.WorkflowCompleted +=
new EventHandler<WorkflowCompletedEventArgs>
(workflowRuntime_WorkflowCompleted);
workflowRuntime.StartRuntime();
Hosting is covered in Hour 3, "Learning Basic Hosting," and Hour 17, "Learning Advanced Hosting."