Workflow services overview
Workflow services are WCF-based services that are implemented using workflows. Workflow services are workflows that use the messaging activities to send and receive Windows Communication Foundation (WCF) messages. .NET Framework 4.5 introduces a number of messaging activities that allow you send and receive messages from within a workflow. For more information about messaging activities and how they can be used to implement different message exchange patterns, see Messaging Activities.
Benefits of using workflow services
As applications become increasingly distributed, individual services become responsible for calling other services to offload some of the work. Implementing these calls as asynchronous operations introduces some complexity into the code. Error handling adds additional complexity in the form of handling exceptions and providing detailed tracking information. Some services are often long running and can take up valuable system resources while waiting for input. Because of these issues, distributed applications are often very complex and difficult to write and maintain. Workflows are a natural way to express the coordination of asynchronous work, especially calls to external services. Workflows are also effective at representing long-running business processes. It is these qualities that make the workflow a great asset to building services in a distributed environment.
Implementing a workflow service
When implementing a WCF service, you define a number of contracts that describe the service and the data that it sends and receives. The data is represented as data contracts and message contracts. Both WCF and workflow services use data contract and message contract definitions as part of service descriptions. The service itself exposes metadata (in the form of WSDL) to describe the operations of the service. In WCF, service contracts and operation contracts define the service and the operations it supports. However in a workflow service, these contracts are part of the business process itself. They are exposed in metadata by a process called contract inference. When a workflow service is hosted using WorkflowServiceHost, the workflow definition is examined and a contract is generated based on the set of messaging activities found in the workflow. In particular, the following activities and properties are used to generate the contract:
Receive Activity
SendReply Activity
TransactedReceiveScope Activity
The end result of contract inference is a description of the service using the same data structures as WCF services and operation contracts. This information is then used to expose WSDL for the workflow service.
Note
.NET Framework 4.6.1 does not allow you to write workflow services using an existing contract definition without some additional tooling support. Workflow service contracts are created by the contract inference process discussed previously. Message contracts and data contracts are fully supported, however.
Workflow services and MSMQ-based bindings
WCF defines two MSMQ-based bindings NetMsmqBinding and MsmqIntegrationBinding. MSMQ-based bindings are often used with workflow services because of the long-running nature of such services. The MSMQ-based bindings have a ValidityDuration property that specifies how long MSMQ messages can assume to be valid. Because of the long running nature of workflow services it is possible that the validity duration of a MSMQ message may elapse before the workflow service can process it. It is therefore very important to set the validity duration of a MSMQ binding to an appropriate value. This value must be chosen based on the workflow and how it processes messages. For example if you have a workflow with a Receive activity followed by a custom activity that takes 10 minutes to run, followed by another Receive activity, the correct value for ValidityDuration would be greater than 10 minutes.
Hosting a workflow service
Like WCF services, workflow services must be hosted. WCF services use the ServiceHost class to host services and workflow services use WorkflowServiceHost to host services. Like WCF services, workflow services can be hosted in a variety of ways, for example:
In a managed .NET Framework application.
In Internet Information Services (IIS).
In Windows Process Activation Service (WAS).
In a managed Windows Service.
Workflow services hosted in a managed .NET Framework application or a managed Windows service create an instance of the WorkflowServiceHost class and pass it an instance of the WorkflowService that contains the workflow definition within the Body property. A workflow definition that contains messaging activities is exposed as a workflow service.
To host a workflow service in IIS or WAS, place the .xamlx file that contains the workflow service definition into a virtual directory. A default endpoint (using BasicHttpBinding) is created automatically For more information, see Simplified Configuration. You can also place a Web.config file in the virtual directory to specify your own endpoints. If your workflow definition is in an assembly you can place a .svc file in the virtual directory and the workflow assembly in the App_Code directory. The .svc file must specify the service host factory and the class that implements the workflow service. The following example shows how to specify the service host factory and specify the class that implements the workflow service.
<%@ServiceHost Factory="System.ServiceModel.Activities.Activation.WorkflowServiceHostFactory"
Service="EchoService"%>