WCF Workflow Service applications are a new type of project in VS2010 that makes it very easy to create workflows for sending and receiving data. They essentially provide a declarative WCF service defined using workflow activities. WCF Workflow Service applications have all the benefits of WF, such as support for long-running services, a GUI interface, and the additional benefit that they are declared declaratively, so they're easy to deploy and version.
VS2010 comes with a WCF Workflow Service Application template that you can adapt for your own needs. The sample application simply echoes a number you send to it back to you. Let's take this for a spin now.
Create a new WCF Workflow Service project called Chapter6.WFService. The template will contain a sequential activity that looks very similar to Figure 6-15.
This sequential activity is defined in the file Service1.xamlx. If you open this up with the XML editor, you will see the XAML that defines this service (boring bits removed as it's pretty long):
<p:Sequence DisplayName="Sequential Service" sad:XamlDebuggerXmlReader.FileName="D:wwwrootookChapter6_WFChapter6.WFServiceChapter6. WFServiceService1.xamlx"> <p:Sequence.Variables> <p:Variable x:TypeArguments="CorrelationHandle" Name="handle" /> <p:Variable x:TypeArguments="x:Int32" Name="data" /> </p:Sequence.Variables> <Receive x:Name="__ReferenceID0" DisplayName="ReceiveRequest" OperationName="GetData" ServiceContractName="contract:IService" CanCreateInstance="True"> <Receive.CorrelationInitializers> <RequestReplyCorrelationInitializer CorrelationHandle="[handle]" /> </Receive.CorrelationInitializers> <ReceiveMessageContent> <p:OutArgument x:TypeArguments="x:Int32">[data]</p:OutArgument> </ReceiveMessageContent> </Receive> <SendReply Request="{x:Reference Name=__ReferenceID0}" DisplayName="SendResponse" > <SendMessageContent> <p:InArgument x:TypeArguments="x:String">[data.ToString()]</p:InArgument> </SendMessageContent> </SendReply> </p:Sequence> </WorkflowService>
Click OK.
Save the project.
Now add a new console application to the solution called Chapter6.WFServiceClient.
Leave the namespace as ServiceReference1.
In Chapter6.WFServiceClient, modify Program.cs to the following:
ServiceReference1.ServiceClient client = new ServiceReference1.ServiceClient(); Console.WriteLine(client.GetData(777)); Console.ReadKey();
Set Chapter6.WFServiceClient as the startup project and press F5 to run. You should see the message "777 sent from WF Service" outputted to the console.
If you wanted to deploy this service, you could simply copy the Service1.xamlx and Web.config files to a web server or even host them using Dublin.
A number of new activities are introduced in WF4, and some activities from WF3 have been dropped. Note that the Microsoft upgrade documents mentioned at the start of this chapter contain more detail on these changes and suggest an upgrade path.
Some existing WF3 activities have now been dropped. The suggested replacements are listed below:
IfElse becomes If or Switch.
Listen becomes Pick.
Replicator becomes ForEach or ParallelForEach.
CodeActivity is gone; you should instead use activity customization as described previously.
WF4 introduces a number of new activities.
These are activities for working with collections in yourworkflows.
Assign allows you to assign values to variables and arguments, and has been used extensively in the previous examples.
CancellationScope allows you to specify activities to be run should an activity be cancelled. The body section surrounds the code you may wish to cancel, and the cancellation handler section specifies code to run if an activity is cancelled. See Figure 6-16.
This is an advanced activity used for long-running workflows that allows you to define compensation, confirmation, and cancellation handlers for an activity. This is used in conjunction with the compensate and confirm activities.
DoWhile continues to run code until the condition specified is true. The code inside it will be run at least once. See Figure 6-17.
This is an activity for looping round a collection.
Interop allows you to use your existing WF3 activities and workflow in a WF4 application. Interop can wrap any nonabstract types inherited from System.Workflow.ComponentModel.Activity. Any properties are exposed as arguments to WF4. Interop can help migration from WF3 or allow you to use existing WF3 workflows you don't possess the source to.
InvokeMethod allows the calling of an existing static method. You can pass generic types, pass parameters by reference, and also call it asynchronously.
The Parallel activity was present in WF3, but didn't truly run activities in parallel (it used time slicing). In WF4, the Parallel and ParallelForEach activities now run truly in parallel (subject to suitable hardware).
Persist allows you to persist the workflow instance using the current workflow configuration settings. You can also specify areas where state should not be persisted with no-persist zones.
Pick provides functionality for using events and replaces WF3's Listen activity.
WF4 improves support for messaging scenarios by introducing a number of new activities for sending and receiving data between applications, and improves support for correlating messages.
WF4 introduces the ReceiveAndSendReply (Figure 6-18) and SendAndReceiveReply (correlated versions of Send and Receive) activities, which allow you to specify code to run between the initial send or receive.
These are advanced activities, so please see the WF SDK for an example of their usage. The messaging activities can operate with the following types of data:
Message
MessageContracts
DataContracts
XmlSerializable
TryCatch allows you to specify activities to be performed should an exception occur and code that should always run in a Finally block, similar to C# or VB.NET. See Figure 6-19.
Switch<T> is similar to the switch statement in C# and contains an expression and a set of cases to process. FlowSwitch is the flowchart equivalent of the switch statement. See Figure 6-20.
In the preview versions of WF4, you may have seen PowerShell, SharePoint, and Data activities. These are now moved to the workflow SDK because Microsoft has the sensible rule for framework development that .NET should not have any dependencies on external technologies.
3.144.114.223