PDC09 – Day Two – Windows Workflow Foundation 4.0 from the Inside out

Bob Schmidt – Program Manager

For WF4:

  • Programs are data
  • Scheduler-based program execution
    • stackless & serializable
  • Runtime-mediated code rendezvous
  • Natural Control flow
    • run it the way you think of it


  • WF is an activity
    • Can author programmatically or using XAML
    • Can contain other activities
    • Separate base classes for activities that return a value
  • WF program is a definition from which many instances can be created
    • Each instance of an activity has a unique environment (visible data values)


  • WF runtime just sees activities and not sequence or parallel or recurrence
    • WF runtime is a referee that enforces the rules of the work
    • CacheMetadata is how an activity describes itself
  • WF runtime knows when an activity is done
  • An activity can schedule the execution of a child activity and be notified upon its completion
    • There can be multiple, distinct method invocations per activity
    • Can Express all kinds of patterns (control flow)
  • There can be multiple paths of invocation …


  • WorkItem represents the invocation of a method
  • WorkItems can be created by:
    • Activity Code
    • External Code
  • Flow of execution
    1. The Activity Code or the External Code Add a WorkflowItem
    2. Them the elements get Pushed or Enqueued for execution
    3. Afterwards the Scheduler will Pop it and execute it
  • Details
    • Scheduler per program instance
    • Manages an ordered list of work items

Threading Model

  • One thread at a time is used to process work items for a program instance
    • Simplifies the programming model of activities
    • Thread may differ work items in the same instance
      • WF runtime uses host-provided SynchronizationContext
      • Standard TLS mechanisms do not apply to WF
        • Instead use WF Execution Properties – names properties visible for a part of a workflow
        • Attached / detached from the current environment by the WF runtime before / after work item invocation
    • Activities should not block this thread


  • Problems
    • What happens when your programs need to wait for input?
    • We want a “Zero footprint” WaitForInput()
  • Bookmark
    • A named resumption point in a WF program
    • Resumption will schedule an activity’s callback method
    • WF runtime mediates resumption – no need for the instance to be in memory
  • WCF Receive activity is built on top of bookmarks in order to give access to this possibility when using Workflow Services


  • lets you pause an instance, save it somewhere & resume it later
    • has no affinity to a WF host instance, CLR instance, thread, process or machine
  • instances of WF are serializable
    • A CLR Stack is not serializable, but in WF program a stack only exists transiently, during work item execution
  • Sometimes you want a “no persist zone”
    • Automatic during execution of an async activity
  • Details of persistence are deliberately separate from the machinery of WF runtime

Serializable Instances

  • Contains
    • Work Item list
    • Bookmarks
    • Data (arg and values)
      • Environment for all executing activity instances
    • Activity instance info (callbacks, execution props)
    • Custom Data from persistence participants
  • Doesn’t contain
    • Workflow Definition
    • Why?
      • several instances can share the same workflow definition
      • management of definitions is responsibility of the host

Leave a Reply

Your email address will not be published. Required fields are marked *