Unfortunately, Dharma and I didn't get a chance to present at PDC this year. However, I think this proposed dialog/script provides an insight into

• why workflow matters
• why custom activities are so important
• some of the key tenets of Windows Workflow Foundation

Dennis: Do you remember one of our first conversations? I asked what "workflow" meant to you...

Dharma: Yeah I remember, one of the things I said was that a Workflow is an organization of activities.

Dennis: But why is a workflow is an organization of activities?

Dharma: Well, a workflow is a hierarchy of activities that in turn describes the control flow of the application in an explicit way. Control flow in an application are things While, IfElse, ForEach etc.

So, tied to this control flow is the declarative representation of the flow of data and other behaviors. You see, each node of the control flow is an activity.

Dennis: Right. so the arrangement of activities creates the control flow of the application. Why should the control flow be explicit? What is the value in making this explicit?

Dharma: Well, the more explicit the control flow is, the more a framework can reason over it. You see, one of the key things CLR enabled the type information explicit and ubiquitous. Today, you can walk up to any assembly and reflect on it and get the type information in a consistent way.

But you still do not have a way to reflect over the control flow of the application. The way the data flows. The way the application interchanges messages with the external world. Or the way the application does exception handling or deals with concurrency. All of which is buried and lost in some opaque code.

Dennis: Ok, but why should a runtime required to reason over the applications control flow or other behaviors?

Dharma: The simple answer is developer productivity. The more explicitly and declaratively you and I as programmers can express our intent to the underlying runtime, the more semantics we can push it down to the platform. For instance, I can ask the runtime to manage my state, I can have the runtime to take care of transactions, concurrency control and so on.

Dennis: How about this for an analogy: Today, an application expresses its intent to the .NET runtime in terms of CLR metadata and IL opcodes. These are the lexicons that the CLR understands. So, as long as you write your app in terms of the CLR metadata and IL, CLR will provide a certain set of execution guarantees and a managed execution environment.

In the same way, so long as you express your program semantics in terms of activities, the underlying WWF runtime can provide managed execution and can provide certain guarantees to your workflow. The Workflow Foundation runtime provides program durability, state management, transaction and compensation, concurrency control etc. to your application. Is that a fair analogy? Is that right?

Dharma: Exactly! Except, unlike IL, the vocabulary which you use to describe the semantics of the workflow is extensible. That is by design because we could not predict all the ways you could describe the control flow of you application.

Dennis: So clearly, this session is all about extending the workflow vocabulary.. or in other words, writing custom activities