- Describing Workflow and Workflow Systems
- .NET Framework 3.0 and 3.5
- Overview of WF
- Standard Modeling Activities
- Multiple Workflow Styles
- Hosting
- Tracking
- Rule Capabilities
- Custom Activities
- XAML Workflows and Serialization
- Dynamic Update
- WF and WCF
- SharePoint Workflow
- Designer Rehosting and External Modeling
- Summary
- Installation Instructions
This chapter is from the book
This chapter is from the book
This chapter is from the book
WF and WCF
The first subsection in this section provides an overview of WCF and conceptually describes using WF and WCF together. The second subsection discusses the product features that integrate the two.
WF and WCF: Conceptual Overview
WCF, WF's counterpart in the .NET 3.x Framework, is Microsoft's preferred technology for hosting and accessing network endpoints. WCF and WF have a symbiotic relationship. By leveraging WCF's core strengths, WF workflows can be securely and reliably exposed across the network. WF workflows can also access network endpoints. Let's look at a couple of examples. If you have a workflow that performs a credit check, and you want to expose it to clients within and across the firewall, you can expose it as a WCF service. Likewise, if you wanted to access a remote service to receive a client's credit score from a workflow, you would use WCF to access the remote service from the workflow. A workflow hosted by a WCF host is referred to as a WorkflowService.
WCF provides one programming model and runtime for distributed computing on the Microsoft platform. It subsumes all previous Microsoft distributed technologies, including web services, web service enhancements, .NET remoting, and enterprise services. WCF supplies the most thorough web service standard support on the Microsoft platform. WCF can listen for and access network endpoints via HTTP, TCP, named pipes, and just about any other protocol.
WCF services (endpoints) are protocol and host agnostic. For example, a service communicating across the firewall can choose the WCF HTTP binding, which sends standard SOAP over HTTP using basic security. If the service needs additional security, it can use WCF's sibling HTTP binding that includes WS* (special web service security) security. Finally a service communicating behind the firewall can utilize the TCP binding that uses compiled SOAP. Therefore, the same service can support all three communication patterns. There simply needs to be one WCF endpoint created for each communization pattern the service supports.
WCF separates the service (the application logic) from the endpoint. The service can be implemented in standard .NET code or as a WF workflow. It is up to you to choose whether to use standard .NET code or a workflow to provide the service logic. Leveraging WCF, WF could expose the same workflow over HTTP to remote clients and TCP to local clients.
Like WF, WCF can be hosted in any .NET 2.0 plus application domain, such as a Windows Service, IIS, or Windows Activation Service (IIS in Windows Server 2008) process. Unlike WF, there is a WCF project type for IIS that simplifies hosting in IIS. This enables WCF services to take advantage of IIS's message-based activation, security, process pooling, and other capabilities. There really is no reason not to use WCF for distributed computing on the Microsoft platform.
WF and WCF: Integration Specifics
Two activities are designed to support WF-WCF integration: Receive and Send. The first is used when exposing a WF workflow as a WCF endpoint. The second is used to access a remote client from a WF workflow. The Send activity is host agnostic—it can be called from any WF host. The Receive activity is not. It can be used only when WF is hosted by WCF.
There are also two WCF workflow projects in Visual Studio 2008 (Figure 1.22). The first contains a sequential workflow project and a WCF contract (interface). The second holds state machine workflows and an accompanying contract. These project types are relevant when exposing a workflow as a service.
The Send and Receive activities are very powerful. They both provide synchronous and asynchronous communication capabilities. The Send activity has a very similar structure to a method call: expected return type, method to call, and parameters to pass. The Receive activity has a very similar structure to a called method. The WF communication activities made available in the .NET Framework 3.0 do not offer such a natural way to call out from and into a workflow.
)
Figure 1.22 WCF Project types.
Many prefer to host all WF workflows in WCF for the following reasons: the robust communication implementation of the Send and Receive activities, the IIS and Windows Activation Services hosting support offered to WCF, Microsoft's apparent emphasis toward WCF as WF's hosting apparatus, especially going forward and the expectation that WF and WCF will continue to be interweaved until they look like one.
WCF and WF integration is discussed in Hour 19, "Learning WF-WCF Integration."