Deploying a Workflow as a Web Service
The Windows Workflow Foundation framework supports Web service interoperability. This includes the ability to expose a workflow as Web service to ASP.NET clients and to other workflows. Windows Workflow Foundation supports publishing a workflow as an ASP.NET Web service on a Web server or server farm running ASP.NET on Internet Information Services (IIS) 6.0. Because Windows Workflow Foundation Web service support is based on ASP.NET 2.0, it inherits most of the features of a standard ASP.NET Web service.
The Windows Workflow Foundation base activity library contains the WebServiceInputActivity and WebServiceOutputActivity activities, which enable a workflow to be used as Web service end points. For information about using these Web service activities, see Using the WebServiceInputActivity Activity and Using the WebServiceOutputActivity Activity.
Workflow Web Hosting
The primary classes used for workflow Web hosting are:
WorkflowWebHostingModule
The WorkflowWebHostingModule class is the default routing mechanism for routing a Web service request to an appropriate workflow instance using ASP.NET cookies. Of course, clients that make these requests are required to support cookies.
Although Windows Workflow Foundation provides this default routing mechanism, you can implement your own custom routing. For example, in cases where enabling cookies in the client is not an option, the client could be configured to create the workflow instance with a specific Id and pass the Id on every Web service request. The request pipeline could be configured with SOAP or HTTP handlers to intercept the call, retrieving the workflow instance Id from the header information, and then set the HttpContext.Current.Items.Add("__WorkflowInstanceId__", workflowInstanceId) to the incoming ID.
ManualWorkflowSchedulerService
The ManualWorkflowSchedulerService class is a specialized implementation of WorkflowSchedulerService that controls the number of threads spawned in an ASP.NET process by reusing the thread that made the ASP.NET Web request to run the workflow instance. This ensures that at any time, the number of active threads in the workflow runtime equals the number of active Web requests in the ASP.NET process.
Limitations of Workflows Exposed as Web Services
Instance routing works based on an ASP.NET session. As a consumer of a Web service it needs to support an ASP.NET cookie.
Even though the receive request-send response can be modeled as asynchronous inside a workflow, the general limitation of ASP.NET applies for the consumer of a Web service, that is, an instance cannot migrate processes between an outstanding request-response operation.
Enabling Cookies to Invoke a Workflow Web Service
A workflow Web service uses cookies to keep track of state. If you publish a workflow as a Web service, you must enable cookies in the client code that invokes it. For example:
CalculatorWorkflow_WebService service = new CalculatorWorkflow_WebService();
service.CookieContainer = new System.Net.CookieContainer();
This enables you to make method calls on the 'service' object.
See Also
Reference
WebServiceInputActivity
WebServiceOutputActivity
WorkflowWebHostingModule
ManualWorkflowSchedulerService
Concepts
Communicating with Other Workflows
Using the WebServiceInputActivity Activity
Using the WebServiceOutputActivity Activity