Appendix B. Control Flow Patterns
| In Chapters 1 through 8, we developed several useful composite activities in order to illustrate concepts and features of the WF programming model. The purpose of this appendix is to explore different kinds of control flow patterns that composite activities can support. A composite activity effectively has two parts:
The Sequence activity, discussed in Chapter 3, "Activity Execution," schedules the execution of its child activities one by one. Sequence therefore functions like a C# {} program statement block. The ordering of its child activities within the CompositeActivity.EnabledActivities list is metadata that the Sequence activity uses to determine the execution order. The Interleave activity, discussed in Chapter 3, schedules the execution of its child activities all at once, which allows them to execute in an interleaved fashion. Interleave requires no metadata unless we decide to give it an ActivityCondition that governs early completion of the Interleave. Conditions might also be applied (as attached metadata properties) to individual child activities of Interleave in order to make their execution order interdependent (for example, child activity A executes only after child activities B and C are complete) or dependent upon WF program instance state (for example, child activity D executes only if the purchase order amount is greater than $1,000). The PrioritizedInterleave activity is a functional superset of Sequence and Interleave. The ordering and interleaving of child activity execution is made explicit with a Priority property that is attached to child activities. Activities with the same priority execute in an interleaved manner; all activities given a priority n must complete their execution prior to the execution of activities with priority n+1. There are a number of valid designs for composite activities that correspond to familiar branching constructs (such as C# if and switch). These composite activities will generally associate conditions with a number of potential paths of execution that are represented as child activities. Evaluation of the conditions will determine which path is taken. The While activity, discussed in Chapter 4, "Advanced Activity Execution," offers an ActivityCondition that governs how many times its lone child activity (validation logic limits the number of child activities to one) is executed. This is exactly like a C# while loop. It is easy to write a ForEach activity that works like a C# foreach, executing independent instances of a lone child activity (validation logic limits the number of child activities to one) for each item in a collection. In Chapter 4, we discussed a variant, InterleavedForEach, which schedules the instances of the child activity all at once, which allows them to execute in an interleaved fashion. As with Interleave, a condition governing early completion can be offered. Some of these composite activities' functionality maps straightforwardly to the familiar control flow found in languages like C#. If you stick to these constructs, your WF program will read a lot like a C# program. However, the concepts of interleaved execution and early completion clearly go beyond what is offered by the control flow constructs of most general-purpose programming languages, and are indicative of WF's flexible approach to control flow. It is crucial to understand that unlike the approach taken by "workflow languages," the WF runtime does not have any intrinsic bias toward, or knowledge of, any control flow patternseven sequencing. Because of this, the activities that are shipped with WF in the System.Workflow.Activities namespace are not privileged in any way relative to activities that you might develop. If you exploit the power of composite activities and develop control flow constructs that capturewith high fidelitythe patterns in real-world processes, you will have a much easier time modeling those processes in your programs. |
EAN: 2147483647
Pages: 97