Chapter 3. Activity Execution

Because a WF program is just an activity (that typically is the root of a tree of activities), the best way to understand how large WF programs execute is to first understand what happens at the level of a single activity.

The WF programming model codifies the lifecycle of an activity in terms of a finite state machine that we will call the activity automaton. Chapter 1, "Deconstructing WF," introduced a simple three-state version of this automaton for resumable program statements. The lifecycle of activities also follows this basic pattern but adds several additional states that will be discussed in this chapter and the next.

The execution model for activities is fundamentally asynchronous because it is designed to accommodate activities that perform episodic executionshort bursts of execution punctuated by relatively long periods of time spent waiting for external stimulus.

For efficiency reasons, it does not make sense to keep WF program instances in memory while they are idle waiting for data to arrive. When a WF program instance becomes idle, the WF runtime is capable of storing it in a (pluggable) durable storage medium and disposing the program instance. The process of storing the instance state and disposing the instance from memory is called passivation. When relevant stimulus arrives from an external entity, perhaps after days spent waiting, the WF runtime automatically reactivates the program, bringing it out of durable storage (where it had been passivated) into memory, and resuming its execution. Relative to its logical lifetime, a typical WF program instance lives for a short duration in memory.

Supporting passivation requires serialization of not only the program state but also the execution state (managed by the WF runtime). When WF program instances are passivated, they are captured by the WF runtime as continuations. A passivated program instance may be resumed in a different process or even on a different machine than the one on which it ran prior to passivation. This means that WF programs are thread-agile and process-agile. WF programs do indeed run on CLR threads, but the execution model for activities across resumption points is stackless because it does not rely on the stack associated with a CLR thread. The lifecycle of a WF program instance may, in a physical sense, span processes and machines and is distinctly different from the lifetimes of CLR objects (of type Activity) that transiently represent such a program instance while it is in memory.