MSDN Magazine - December 2008 - (Page 56)

root activity property values using a generic Dictionary keyed by property name. It also allows you to examine root activity property values after activity execution has completed. Even if your activity will ultimately be nested several levels inside a workflow hierarchy and relies on data binding to initialize its property values, you can test the activity in isolation of others and simulate the full range of expected and error conditions for that activity. The WF runtime integrates with any existing threading model, be it single-threaded or multithreaded. WF also plays nicely with more advanced unit testing techniques such as object mocking, where the emphasis is on isolating tested code from its dependencies, as well as validation of expectations on those dependencies (for example, “When executing the code for this test, I expect the Foo() method for this dependency to be called exactly 3 times.”). Here’s an example: // mock the IBanking interface var bankingMock = new Mock (); // specify that you expect AddCustomer to // be called with the customer instance bankingMock.Expect( bank => bank.AddCustomer( customer ) ); // execute WF harness, configuring the mock as a service ExecuteActivity( typeof( AddCustomerActivity ), new List () { bankingMock.Object }, "Customer", customer ); If you’re familiar with unit testing and object mocking, you might have already guessed that WF services are perfect candidates for mocking in tests that target WF activities. WF services are dependencies by their very nature and should be factored out of such unit tests. A Runtime within a Runtime WF is more than a component-based extensible programming environment. It also incorporates an execution engine built on top of the CLR. This engine provides many services useful to workflow programs, such as work scheduling, automatic serialization/deserialization during idle states, and propagation of data from parent to child activities via data binding, among other things. But you must take care to play by the WF rules; naïve workflow implementations can perform poorly in this environment, or not at all. Perhaps the most important thing to understand about the WF runtime is that it imposes no specific threading requirements on its host code. Rather, it’s designed to integrate with any existing threading model, be it single-threaded or multithreaded. Scheduling workflow execution occurs via a service configured against the WF runtime. The DefaultWorkflowSchedulerService executes workflows on the .NET ThreadPool, while the ManualWorkflowSchedulerService allows you to specify exactly which thread you want to use (useful with WF hosts that themselves dispatch work to the ThreadPool, like ASP.NET). Though rarely needed in practice, you also have the option of providing your own custom scheduling implementation. Note that, regardless of threading model, individual workflows never execute on more than one thread at any given moment. This is a conscious design choice in the WF runtime execution model. If you need to invoke multithreaded code within a workflow, your best bet is to do it in a custom WF service. Unlike traditional stack-based programming environments such as C# or Visual Basic, workflows execute asynchronously with respect to their calling code. That is, when a workflow completes execution, control is not automatically returned to the point of invocation of the workflow. Rather, each workflow instance becomes a separate logical fork in your program. Managing state for workflows running in WF introduces the potential for problems without an understanding of the WF runtime. Traditional POCO (Plain Old CLR Objects) programming uses class member fields and properties for data storage. You build WF activities in the same manner, but in the case of episodic workflows configured to persist during idle states, a single logical workflow lifetime might be realized via multiple physical activity graph instantiations (as depicted in Figure 4) and across multiple applications or even multiple machines. While WF supports automatic serialization of activity graphs and state during persistence, it’s important to note that it only works for a subset of data types (no arrays, and limited support for generics). Hand-authored custom serialization is possible via serialization surrogates. You can also override Activity.OnActivityExecutionContextLoad and Activity.OnActivityExecutionContextUnload to do custom processing per activity for each instantiation and teardown of a workflow object graph. Logical Work ow Lifetime Work ow Instance Work ow Serialized Work ow Idle Work ow Deserialized Work ow Instance Work ow Serialized Work ow Idle Work ow Deserialized Work ow Instance Figure 4 Logical vs. Physical Workflow Lifetime, for Episodic Workflows 56 msdn magazine Real-World WF

Table of Contents Feed for the Digital Edition of MSDN Magazine - December 2008

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

MSDN Magazine - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.