Windows Workflow is a runtime and not an application. A host process must load and launch the workflow runtime before starting a workflow. The host process tells the runtime
the types of workflows to create, and the runtime manages the lifecycle
of the workflows and notifies the host process about important
lifecycle events, like workflow completion and termination. The runtime
isn't particular about the type of host it lives inside. The host
process could be a smart client application running on an office
desktop machine, or an ASP.NET worker process running on a server in
the rack of a data center.
A host can also customize the workflow runtime by layering
additional services on top of the runtime's base feature set. These
services can provide persistence support for long-running workflows,
tracking support for monitoring workflow execution, and more. One
concrete example is the ExternalDataExchangeService we've used in
previous articles. We added this service to the runtime when we needed
communication between a workflow and its host process. Not all
applications will require this feature, so the service is an optional
component we add as needed.
(Source: http://www.odetocode.com/Articles/457.aspx)
