Where are We?

This chapter introduced the activity automaton, which describes the lifecycle of any activity in a WF program instance. Our foray into custom activity development introduced the service-chaining capabilities of the WF runtime, as well as the use of bookmarks (and associated WF program queues) as a mechanism by which activities can receive stimulus from external entities.

We turned to composite activities next and discussed threeSequence, Interleave, and PrioritizedInterleavethat provided insights into the flexibility of WF's model for control flow. Control flow patterns are a theme that will be continued in the next chapter.

We discussed the WF execution model and threading model, and specifically examined how the WF scheduler works. By looking at how the execution of various WF programs unfolds, we saw the nuts and bolts of how the scheduler performs its role as an intermediary for the dispatch of resumed bookmarks. As well, we learned that the WF runtime enforces the activity automaton and also protects the integrity of the containment relationships between activities in a WF program. Pseudo-concurrency within a WF program instance is caused by the interleaving of WF threads of execution.

The next chapter is a continuation of this one (feel free to bookmark it now). We will examine the Canceling, Faulting, and Compensating states of the activity automaton, and also introduce the WF programming model's support for explicit management of activity execution contexts.