MSDN Magazine - December 2008 - (Page 55)

ibility of the WF service model to design well-factored, reusable workflow activities. One feature that makes WF particularly well suited for general-purpose programming tasks is its support for asynchronous, non-blocking work. The very nature of modern Web service- and database-centric applications lends itself to asynchronous invocation, where a request is made to the service and then local resources associated with the requesting call are freed to process other work. Later, when the dispatched work is completed, execution can pick back up where it left off. ASP.NET asynchronous pages are one example of this technique. When first executed by the WF runtime, the activity’s Execute method is invoked. Execute returns ActivityExecutionStatus.Completed if the activity has performed all of its work within Execute. It returns ActivityExecutionStatus.Executing if it reaches a point where it’s done as much work as possible, and is now waiting on Figure 3 A Generic Workflow Test Harness protected Dictionary ExecuteActivity( Type activityType, IEnumerable services, params object[] inputs ) { Dictionary outputs = null; Exception ex = null; using ( WorkflowRuntime workflowRuntime = new WorkflowRuntime() ) { AutoResetEvent waitHandle = new AutoResetEvent( false ); workflowRuntime.WorkflowCompleted += delegate( object sender, WorkflowCompletedEventArgs e ) { outputs = e.OutputParameters; waitHandle.Set(); Episodic Execution }; workflowRuntime.WorkflowTerminated += delegate( object sender, WorkflowTerminatedEventArgs e ) { ex = e.Exception; waitHandle.Set(); some external stimulus, such as a response from a Web service or database call or an e-mail sent to a specific address, to continue. Figure 2 shows the Execute method for an activity that queries an external service for a credit score, given a customer ID. Since credit scoring might take minutes or even hours to complete, the workflow invokes the service asynchronously and then goes idle waiting on a result. Before going idle, the activity registers a delegate to be invoked by the runtime when the stimulus arrives. This delegate is known as a continuation (literally, a “pointer to the rest of the program”) and allows the activity author to define any logic needed to continue activity processing. The lifetime of a single workflow may consist of several such idle-continue state transitions. The runtime receives notice of the external stimulus needed to wake an idle workflow through arrival of an item (any .NET object) on a workflow queue associated with the workflow instance. In the case of an asynchronous Web service call, the code waiting on the response obtains a reference to the queue and pushes any relevant data (presumably whatever was finally received from the Web service) onto the queue. The runtime monitors the queue and invokes the registered delegate; the delegate logic can obtain the queued item and perform any necessary processing. The power of this approach stems from what happens to the workflow during idle time. Activities that return ActivityExecutionStatus.Executing from their Execute method (and are thus considered idle) are obviously doing no work for some period of time. This might be seconds, hours, days or even months of waiting on some external stimulus. During this time, there’s no need for the workflow to remain in memory consuming machine resources that could otherwise be put to better use, so the WF runtime supports the ability to automatically unload such workflows from memory and serialize them to persistent storage using a persistence service, such as SqlWorkflowPersistenceService. When the external stimulus arrives, the WF runtime reloads the workflow and continues execution as normal. }; Unit Testing Is Still Your Friend foreach ( object svc in services ) { workflowRuntime.AddService( svc ); } Dictionary parms = new Dictionary (); for ( int i = 0; i < inputs.Length; i += 2 ) { Debug.Assert( inputs[ i ] is string ); } parms.Add( (string) inputs[ i ], inputs[ i + 1 ] ); WorkflowInstance instance = workflowRuntime.CreateWorkflow( activityType, parms ); instance.Start(); waitHandle.WaitOne(); if ( ex != null ) { Assert.True( false, ex.Message ); return null; } Else { return outputs; } } } Unit testing remains relevant to your life as a programmer targeting WF. In fact, the explicit compositional nature of WF is a natural fit for authoring a battery of comprehensive tests that exercise each piece of your solution in isolation of other pieces. I’ll give you some higher-level information here, but be sure to check out Matt Milner’s Foundations column in the November 2008 issue of MSDN Magazine (msdn.microsoft.com/magazine/dd179724) for a deeper look at unit testing workflows. A common misconception when working with WF is that you can only execute entire workflows (meaning, subclassed instances of SequentialWorkflowActivity). In fact, you can execute any activity instance as a standalone workflow, which makes it easy to use a generic activity test harness to execute and validate activities in isolation or in small subsets of a larger whole. Figure 3 shows such a test harness. The basic state-oriented test pattern of “data in/execute code/ make assertions against data” works just fine for WF with a generic test harness. The WF runtime supports auto-population of December 2008 55 msdnmagazine.com http://msdn.microsoft.com/magazine/dd179724 http://www.msdnmagazine.com

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.