Workflow, Tomorrow's Application Logic
This chapter is from the book
This chapter is from the book
This chapter is from the book
Chapter 1: Workflow, Tomorrow's Application Logic
In this chapter
-
The Wonder of Flowcharts
-
Today's Workflow Scenarios
-
Introducing Windows Workflow Foundation
-
Windows Workflow Foundation Engine Architecture
At the professional developer conference in September 2005, Microsoft announced Windows Workflow Foundation as a key component of WinFX in conjunction with Windows Communication Foundation and Windows Presentation Foundation. This chapter describes the motivation behind Windows Workflow Foundation and provides an overview of its features.
The Wonder of Flowcharts
Inside classrooms around the planet students often receive their first exposure to computer program design through the concept of a flowchart. The flowchart provides a graphical model that is used to formalize the design of program structure—with squares, diamonds, and triangles representing the various steps in the flow such as activities and decisions. Although the flowchart model is an excellent learning tool, the flowchart is not directly represented in running software. The expense of maintaining a flowchart model in software from a CPU-cycles perspective means that the flowchart is nothing more than documentation. After the concepts of flowchart program design are mastered by students, the flowchart model is forgotten and programs are written directly in code.
Although writing programs directly in code has been the main development paradigm for more than 25 years, and many millions of programs have been created, a pure coding approach is not without issues.
Code written by one developer is often inherently hard to understand by another. Although well-documented or commented code helps, it is often unstructured in approach. Indeed the intellectual property that is the flow of the program often stays in the mind of the original developer and is at risk when that developer moves to a new job or a new role. The flowchart model, if instantiated in code, would certainly provide an additional level of visibility in program design.
Once compiled and executed, code is inherently opaque. The resulting assembly language or intermediary language running on a CPU natively or through a virtual machine executes a predefined set of op-codes to perform a set of activities but does not provide visibility into how these activities are executed. This has some advantages as it protects the intellectual property of the code itself, but it also creates challenges. As programs become larger, visibility into these programs at runtime becomes more important to troubleshoot errors in context of program execution. The flowchart model, if available at runtime, could provide visibility into the program execution.
Code is often grouped into procedures or objects. Encapsulation of code, and indeed data, in these formalisms makes program design more componentized and easier to maintain. On the other hand, it poses some interesting challenges. How does data in one procedure or object move to the next procedure or object? There are fundamentally two approaches. The first is to send a message from one object to another such as a method call from one object to another passing state, or an XML message serializing state. Although this design is functional in many cases, it isn’t elegant as a state needs to be passed through a chain of many objects all through parameters or XML messages. The second approach centralized the shared state in an object. The state can be retrieved, updated, and persisted to the object when required. Examples of this method include web pages on a site that communicate through shared state held in databases that may be session based or otherwise. However, in each case these state management features were custom-crafted because of the lack of a consistent development framework to manage state. Some of the challenges such a framework would face include scalability challenges in managing state over long time periods. A simple flowchart model has the notion of shared state. A variable is often set in the first step of a flowchart and then referred to later in the thread of execution. If this model for accessing state were more accessible to the programmer in a scalable manner then state management could be more efficient.
Although not part of mainstream development, over the past five years instantiating a flowchart as part of a program runtime has proved so useful in certain scenarios that regardless of the CPU cost it has become the preferred method of interaction. Some of these scenarios are described in the following sections.