The new Windows Workflow Foundation technology that ships with .NET Framework 4 represents a major improvement in performance and developer productivity and realizes a goal of declarative application development for business logic. Windows Workflow Foundation (WF) is a Microsoft technology for defining, executing, and managing workflows. This technology was first released in November 2006 as a part of .NET Framework 3.0. The current version (4.0) was released as part of the .NET Framework 4.0. The major refinement of the new version is the tighter integration of WF with Windows Communication Foundation.
As software developers know, writing applications can be challenging, and we are constantly looking for tools and frameworks to simplify the process and help us focus on the business challenges we are trying to solve. Microsoft help to moved from writing code in machine languages such as assembler to higher level languages like C# and Visual Basic that ease our development, remove lower level concerns such as memory management, and increase our productivity as developers. .NET allows the Common Language Runtime (CLR) to allocate memory, cleanup unneeded objects and handle low level constructs like pointers.
Playing around with the idea of modeling business rules as a set of small workflows (Flowcharts in WF4). In the application, this would result in small workflows being called a large number of times. To investigate the performance overhead of invoking a workflow in WF4, the workflow technology in .NET 4. Since Visual Studio 2010 Ultimate, this also seemed like a good opportunity to evaluate the performance profiler included in this edition of VS 2010. For this test implemented a simple application that performs a calculation 10,000 times, then outputs that value to the console. As a reference, I first implemented this in simple C# code as follows:
To determine the performance, I used the Instrumentation Profiler. The simple C# code took approximately 800 milliseconds to execute. Most of the time was spent writing to the console. Some example flowchart sample using wf4.
Next, I implemented the calculation functionality in a simple flowchart workflow. My flowchart has a single InArgument y, and an OutArgument x.
But if we really think about what’s happening here, this performance isn’t that bad. We know that it takes about 1 second to perform the calculations and output the results. That means that the remaining 35 seconds was spent on “workflow” related processing. In that 35 seconds, we were able to create and execute 10,000 workflows. Clearly this is not fast enough to accomplish. After digging through the profiler, we can notice that the application seemed to be spending a large percentage of the time initializing the workflow. This led me to investigate if we could just create the workflow object one time and reuse it whenever we invoke that workflow. It turns out that we can, and the results are dramatic.
The code is as follows:
Notice that I am now passing the input to the workflow using a Dictionary<string,object>. I’m not sure why, but when I tried setting the input using workflow.y = i, the workflow would always use the first value that was assigned to y. In this case, my output was always 0 because the workflow was always using y=0. Passing the workflow inputs as a Dictionary seems to work around this problem. Using this method of invoking the workflow, the total execution time was just over 1.15 seconds. Now this looks much better. By caching the instance of the workflow object, we are able to significantly reduce the overhead of executing a workflow. In this case, we spent just over 1/2 the time calling Console.WriteLine(). That means we were able to execute 10,000 workflows in the remaining .65 seconds. Considering the flexibility this can provide in an application, I would consider this overhead to be minimal. In most real-world applications, the difference in performance will not be noticeable to the end user. When running the application in release mode with no profiler attached, it took 14.48 seconds to execute the workflow 1,000,000 times. That works out to 69,039 workflows per second! Performance profiler in VS 2010 to be useful. While it is much better than no profiler at all, I was a little disappointed. There are much better profilers on the market today.
What’s New in WF4
In version 4 of the Microsoft® .NET Framework, Windows Workflow Foundation introduces a significant amount of change from the previous versions of the technology that shipped as part of .NET 3.0 and 3.5. In fact, the team revisited the core of the programming model, runtime and tooling and has re-architected each one to increase performance and productivity as well as to address the important feedback garnered from customer engagements using the previous versions. The significant changes made were necessary to provide the best experience for developers adopting WF and to enable WF to continue to be a strong foundational component that you can build on in your applications. I will introduce the high level changes here, and throughout the paper each topic will get more in depth treatment.
Before I continue, it is important to understand that backwards compatibility was also a key goal in this release. The new framework components are found primarily in the System.Activities.* assemblies while the backwards compatible framework components are found in the System.Workflow.* assemblies. The System.Workflow.* assemblies are part of the .NET Framework 4 and provide complete backward compatibility so you can migrate your application to .NET 4 with no changes to your workflow code. Throughout this paper I will use the name WF4 to refer to the new components found in the System.Activities.* assemblies and WF3 to refer to the components found in the System.Workflow.* assemblies.
One of the most visible areas of improvement is in the workflow designer. Usability and performance were key goals for the team for the VS 2010 release. The designer now supports the ability to work with much larger workflows without a degradation in performance and designers are all based on Windows Presentation Foundation (WPF), taking full advantage of the rich user experience one can build with the declarative UI framework. Activity developers will use XAML to define the way their activities look and interact with users in a visual design environment. In addition, rehosting the workflow designer in your own applications to enable non-developers to view and interact with your workflows is now much easier.
In WF3, the flow of data in a workflow was opaque. WF4 provides a clear, concise model for data flow and scoping in the use of arguments and variables. These concepts, familiar to all developers, simplify both the definition of data storage, as well as the flow of the data into and out of workflows and activities. The data flow model also makes more obvious the expected inputs and outputs of a given activity and improves performance of the runtime as data is more easily managed.
A new control flow activity called Flowchart has been added to make it possible for developers to use the Flowchart model to define a workflow. The Flowchart more closely resembles the concepts and thought processes that many analysts and developers go through when creating solutions or designing business processes. Therefore, it made sense to provide an activity to make it easy to model the conceptual thinking and planning that had already been done. The Flowchart enables concepts such as returning to previous steps and splitting logic based on a single condition, or a Switch / Case logic.
The WF programming model has been revamped to make it both simpler and more robust. Activity is the core base type in the programming model and represents both workflows and activities. In addition, you no longer need to create a WorkflowRuntime to invoke a workflow, you can simply create an instance and execute it, simplifying unit testing and application scenarios where you do not want to go through the trouble of setting up a specific environment. Finally, the workflow programming model becomes a fully declarative composition of activities, with no code-beside, simplifying workflow authoring.
Windows Communication Foundation (WCF) Integration
The benefits of WF most certainly apply to both creating services and consuming or coordinating service interactions. A great deal of effort went into enhancing the integration between WCF and WF. New messaging activities, message correlation, and improved hosting support, along with fully declarative service definition are the major areas of improvement.
Intro To WF4 Hands On Lab (Visual Studio Gallery)
Intro To WF4 Hands On Lab (MSDN Code Gallery)
Exercise 1 - Hello Workflow (video)
Exercise 2 - Refactoring Workflow (video)
Exercise 3 - The CodeActivity (video)
Exercise 4 - Dynamic Workflows with XAML (video)
Exercise 5 – Testing Activities (video)
Exercise 6 – WorkflowApplication (video)
Exercise 7 – If/Else Logic (video)
Workflow Foundation (WF) in .NET 4 - provides the declarative framework for building application and service logic and gives developers a higher level language for handling asynchronous, parallel tasks and other complex processing. Much of the complexity of an application lives in the logic and processing that goes on behind the scenes. Issues such as asynchronous or parallel execution and generally coordinating the tasks to respond to user requests or service requests can quickly lead application developers back down into the low level coding of handles, callbacks, synchronization etc. We discuss flowchart sample using wf4. As developers, we need the same power and flexibility of a declarative programming model for the internals of an application as we have for the user interface in Windows Presentation Foundation (WPF). What does Workflow Foundation (WF) mean to you?