MSDN Magazine Launch Issue - February 15, 2008 - (Page 111) Workflow Services MATT MILNER hen a new version of Visual Studio® is released, the first thing developers typically want to know is what new features they will find in their favorite programming tool. Although Windows® Workflow Foundation (WF) and Windows Communication Foundation (WCF) were released in November 2006 as part of the Microsoft® .NET Framework version 3.0, it is only with the release of Visual Studio 2008 and the .NET Framework 3.5 that people are becoming aware of the great features these technologies provide. Unfortunately, with the .NET Framework 3.0, there was not a very good model for combining the declarative programming model of Windows WF with the simplified yet rich communications model exposed by WCF. What’s compelling about Windows WF in the .NET Framework 3.5 is that it provides true integration with WCF. This integration means that workflows can now more easily consume and coordinate services and be exposed through service endpoints. W What’s Required for Integration When considering the integration of Windows WF and WCF, there are several key areas of focus. The primary components of any workflow are the activities that allow modeling of application logic. In the .NET Framework 3.5 two new activities, Send and Receive, provide a generic model both for consuming services and for implementing service endpoints within a workflow. I will talk more about how to use these activities shortly. In addition to being able to model communication, integration requires a mechanism for hosting the runtimes of both WCF and Windows WF. Because each technology has its own runtime, configuration, and extensibility model, we need a way to host both technologies in a single process. The tools provided in the new framework are based on extensibility points in WCF that allow the workflow runtime to be hosted by the WCF runtime. The final item required for integration is really the crux of the matter: how to marshal WCF messages into workflow instances and map those operations onto activities in the workflow. Again, this feature relies on the WCF extensibility model and is responsible for issues around security, workflow instance management, and marshaling the message bodies as data to activities. A new assembly, System.WorkflowServices.dll, holds the new classes that provide the integration between Windows WF and WCF. This new assembly is specific for .NET 3.5, while the existing 3.0 assemblies remain unchanged except for bug fixes. By using the existing extensibility models of WCF and Windows WF, it was possible to provide integration without having to modify existing components. I will cover the core classes used when integrating these technologies and explain how they fit together. In addition to the new assembly, Visual Studio 2008 comes with a few new project and item templates specifically for building workflows to be published as services. In the new project What’s compelling about dialog, you will find both Windows WF in the .NET the Sequential Workflow Service Library and State Framework 3.5 is that it Machine Workflow Service provides true integration Library projects under the with WCF. WCF category. You will also find new item templates for Windows WF Sequential Service and Windows WF State Machine Service items and their XAML counterparts. Each of these new templates adds the workflow, the interface defining the service contract, and an app.config file that configures the endpoints for the service. The new receive activity is used to model points in the workflow where your process will receive data as part of a WCF service contract. This means that each receive activity in your workflow will need to be configured with the appropriate information related to the service contract and be tied to an operation on that contract. In order to accomplish this binding between the activity and the operation, the activity has a ServiceOperationInfo property. The contract can be declared in one of two ways: using WCF service contract attributes or directly within the workflow. The latter is often referred to as “workflow first” design, in contrast to “contract first” design. When defining the contract directly in the workflow, the contract information is embedded within the workflow definition rather than exposed as a .NET interface, as it is when defining a contract with WCF. When you edit the ServiceOperationInfo property, you are presented with a dialog that allows you to choose the operation, and this is also where you must decide if you are going to use an existing service contract or define a new one. The dialog is shown in Figure 1 and has two buttons in the upper-right corner that allow you to import a service contract or add a new contract. If you choose to launch2008 111 Modeling Communications with Send and Receive Activities
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.