WF is composed of three main components:
The workflow runtime takes care of instantiating individual workflows and handles persistence and synchronization. The workflow runtime does not exist on its own. It is created inside a host application. The host application can be anything from an ASP.NET web site to a windows service, or even the new "Dublin" or Windows Azure platforms.
In previous versions of WF, the WorkflowRuntime class was restricted to one WorkflowRuntime per app domain, and WorkflowInstance instantiated individual workflows. WorkflowInstance has now been replaced with the class WorkflowInstance, which represents an individual workflow.
This change makes it much easier to attach event handlers and delegates to individual workflows, but also arguably complicates tasks such as recording errors, as they now have to be dealt with on an individual workflow basis.
Workflows are made up of activities. Microsoft provides a number of building block activities providing basic logic and flow statements for you to use, called the Base Activity Library (BAL). You can of course (and should) create your very own activities. Figure 6-3 shows the WF activity hierarchy.
Activities can be created as composites of existing activities, entirely in code or even just using XAML. Activities inherit from the class Activity (unlike WF3 that used SequentialWorkflowActivity or StateMachineWorkflowActivity). We will look at creating customized activities shortly.
The designer (Figure 6-4) is used to piece together your workflow, and contains tools for debugging and monitoring it.
It is even possible to host the workflow designer within your application. For more information on this, please refer to the following links:
http://msdn.microsoft.com/en-us/library/dd489440(VS.100).aspx
http://channel9.msdn.com/learn/courses/VS2010/WCFWF/IntroToWF/Exercise-10-Hosted-Designer
The Trident project (a tool for customizing scientific workflows) used this facility extensively. Take a look at http://connect.microsoft.com/trident.
3.143.5.248