Summary

The activity execution model is proof of a well-architected framework that can handle scenarios such as faults, persistence, and compensation. When an activity executes, it does so within the confines of an activity execution context. This context describes the activity’s state during the time in which it executed. Each activity’s execution context can be persisted so that compensation can occur weeks or months after it actually executed.

For activities that have multiple children or that have child activities executing multiple times, you must create separate execution contexts manually using the ActivityExecutionContextManager class, which is available from an ActivityExecutionContext instance. An example ForEachActivity was developed in this chapter to illustrate this concept. Even though this activity has only one child, each time that child executed, it was within a separate context.

The chapter also introduced workflow queues as the conduits for host-to-workflow communication. Instead of applications passing data directly to workflow instances, which may or may not even be in memory, the data is passed to a workflow queue. WorkflowQueueingService allows the creation and deletion of WorkflowQueue instances.

This chapter also introduced the concept of event activities. Event activities rely on input from the outside world to complete. The prime example of this type of activity is the out-of-the-box HandleExternalEvent activity. An example activity that blocks workflow execution until an e-mail arrives was developed to illustrate programming concepts related to event activities. This activity implements the IEventActivity interface, which allows it to be used in other event-specific activities, such as EventDriven and Listen. In addition, special considerations were made to ensure that it would execute correctly outside one of these activities.