Foreword

As I write this foreword in July 2006, I know something big is about to happen.

Developers are discovering the power of having machine-readable representations of their programs that match their intention. This idea is sometimes referred to using the shorthand phrase code as data.

More importantly, developers are realizing that no runtime architect or language designer is all that qualified to define the schema for that data—a domain expert is the only one who has the right expertise. This idea is sometimes referred to as domain-specific languages.

Systems like Smalltalk, the Java Virtual Machine (JVM), and the Common Language Runtime (CLR) have proven that there is value in having machine-readable representations of type definitions for things such as reflection, serialization, and generative programming. However, the basic representation of a type (e.g., fields, methods, classes) is largely a closed world, which doesn't allow users to model (as data) things such as control flow, concurrency, logic constructs, or domain-specific ideas such as discount policy or dotted whole note except as largely opaque instructions strewn across multiple method bodies.

People are now asking themselves, "If my type definition is available as data, why aren't other design-time constructs as well?"

Fortunately, one of the people asking those questions back in 2003 was my good friend Dharma Shukla, who was then working on the Biztalk Server team.

When the Biztalkers set out to generalize their XLANG orchestration engine as an embeddable platform component, they could have simply taken the language constructs from XLANG and put yet another XML syntax around them (that proposal was certainly on the table). This is the most obvious approach and would have satisfied their charter for building the Windows Orchestration Engine (WinOE) perfectly well.

Fortunately, Dharma had the foresight to know that he wasn't the right guy to define "the one true schema" for all programs and instead decided to "go meta" and steer the project toward building an extensible runtime that allows users to define their own opcodes that match the domain they're working in. Add to this the decision to support defining and composing these opcodes in an XML dialect and you have a system that lets anyone decide what the vocabulary and sentence structure is for describing applications in a given domain.

As Dharma Shukla and Bob Schmidt so aptly show with this book, Windows Workflow Foundation (WF) is an excellent example of a meta-runtime that puts developers in control of how programs are written and how programs execute. The developer defines the schema for a program and then provides an interpretation over that schema to allow it to be deployed and run. It is a simple idea that has huge ramifications.

Like I said, something big is about to happen.

Don Box July 2006, Yarrow Point, WA

Preface

Windows Workflow Foundation (WF) is a general-purpose programming framework for creating reactive programs that act in response to stimulus from external entities. The basic characteristic of reactive programs is that they pause during their execution, for unknown amounts of time, awaiting input.

Reactive programs are, of course, not a new phenomenon. Ever since computers have been organized into networks, it has been useful for programs on one machine to communicate with programs on other machines. Techniques for exchanging data are also applicable to programs running on a single computer. A variety of technologies ranging from sockets to web services has been used over the years to get programs to communicate. Although the interoperability, scalability, and approachability of the programming models at hand have improved greatly over the years, relatively scant attention has been paid to the manner in which developers put reactive programs together. For example, popular web programming models put the burden of enforcing appropriate control flow among operations squarely on the developer. WF attempts to change this.

The focal point of the WF programming model is the concept of an activity—a program statement in a WF program. An activity's execution is inherently resumable and unfolds in an episodic manner, pausing and resuming according to the activity's interactions with external entities. Just as you can stick a bookmark in a page of this book when you are finished reading for the night, it is natural for an activity to bookmark its execution (when it is awaiting input) and then continue right where it left off at a later time (when the relevant input arrives).

WF is a framework, not a fixed set of programming constructs defined by a language grammar. WF's notion of an activity is extensible, which allows the expressiveness and control flow in WF programs to be richer than what is provided by a language like C# or Visual Basic. You can represent WF programs using domain-specific activities and specialized control flow constructs, and thereby capture complex interactions among people and software with a high degree of fidelity to the particulars of the problem being solved.

The WF runtime is a meta-runtime that builds upon the Common Language Runtime (CLR) and manages the execution of WF programs. WF programs naturally pause and resume, and can execute over arbitrarily long periods of time within a distributed (multi-machine) execution environment without any extra work on the part of the programmer. A WF program will neither fail nor cause undue strain on system resources if it sits idle for weeks. The CLR's job, in the context of WF, is to manage objects that transiently represent WF programs while they are in memory. The WF runtime's job is to manage the full lifecycle of WF programs, which can span CLR threads and application domains, operating system processes, and even machines.

In sum, WF provides a programming model for writing and executing reactive programs. WF programs are constructed using domain-specific program statements called activities, which allow domain experts to express their programming intent in the parlance of their domain.

About the Book

There is a simple reason why this book was written. Both of us believe there is a novel synthesis of noteworthy ideas at the heart of WF. These ideas are seeing the light of day for the first time in a mainstream platform. Because WF's activity-oriented programming approach rests on a different set of principles than do today's popular programming paradigms, the best way to learn WF is to focus first on the fundamental ideas around which the WF programming model is built. There is more to becoming an effective WF developer than just familiarizing yourself with the types that reside in the new System.Workflow namespace of the .NET Framework.

To that end, this book does not aim to exhaustively discuss the 350+ types present in the three assemblies that constitute WF. We deliberately disregard some outer layers of WF so as to focus on the essence—the core programming model and runtime feature set. Experience has taught us that learning the capabilities of the framework from first principles is the surest way to becoming a proficient WF developer.

The writing of this book has led us to examine and debate our beliefs and assumptions about the nature of reactive programs and how such programs can be developed. If this book, and WF, provides someone with a fresh idea upon which to build further, we will consider our efforts a success.

The organization of this book is as follows. Chapter 1, "Deconstructing WF," examines the key ideas that underpin the WF programming model: bookmarks, continuations, thread and process agility, passivation, resumable program statements, and a runtime for resumable programs. These ideas are discussed in their barest form, outside the context of WF, to maximize the clarity of the discussions.

Chapter 2, "WF Programs," maps the concepts introduced in the first chapter onto the richer programming surface of WF, and therefore acts as a bridge to the rest of the book. Here we begin developing activities, composing them into simple WF programs, and running those programs.

Chapters 3, "Activity Execution," and 4, "Advanced Activity Execution," discuss detailed aspects of how activities execute including bookmarking, fault handling, cancellation, and compensation. The unifying theme is the activity automaton that describes the lifecycle of all activities. Chapter 5, "Applications," explores how to build applications that host the WF runtime and leverage its points of extensibility. Chapter 6, "Transactions," discusses the critical role of transactions in the execution of WF programs. Chapter 7, "Advanced Authoring," covers a number of advanced topics related to activity and WF program authoring, including validation and compilation, and Chapter 8, "Miscellanea," introduces several feature areas of WF that are built around the previously discussed core concepts.

Appendix A, "Activity Automaton," is a reference for the activity automaton. Appendix B, "Control Flow Patterns," presents the code for several composite activities that are more complex than those developed in the main text. These examples highlight extensibility points of the WF programming model, and demonstrate the capability of composite activities to capture complex control flow patterns.

Our focus in this book is exclusively on Windows Workflow Foundation. We assume prior understanding of C# 2.0 and the basics of the CLR; see The C# Programming Language, Second Edition by Anders Hejlsberg, et al. (Addison-Wesley, ISBN: 0321334434) and Essential .NET, Volume I: The Common Language Runtime by Don Box and Chris Sells (Addison-Wesley, ISBN: 0201734117) for definitive discussion of these subjects. Examples we present in this book are simple—purposefully stripped of scenario noise—so as to minimize distractions from the concepts being discussed. After you learn the ropes, we expect you'll try applying the ideas and techniques explained here to the domain of your choosing.

© Copyright Pearson Education. All rights reserved.