WF from Getting started to mastering (19th Chapter): Publishing Workflows as Web services

After completing this chapter, you will learn:

1. Learn how each workflow activity is designed to be used to expose your workflow to XML Web services

2. Understand what it takes to host workflows in asp.net

3. See how error (Fault) is handled in workflows based on XML Web services

4. Configure your workflow for xml-based Web services for a variety of situations

In the previous chapter, "Invoking Web Services in your workflow", you saw how to invoke an XML Web service using the Invokewebservice activity provided by WF from the workflow on one side of your client. However, the XML Web service in that chapter of the application paradigm is a typical asp.net XML Web service-nothing special.

In this final chapter, you will learn how to process workflows and automatically expose workflows to XML Web services for customers to use. This is not as simple as creating a workflow assembly library and referencing it from a Web service project, but then again, once you understand some basic concepts and look at the implementation in an application paradigm, it is not difficult to do so.

Note: The focus of this chapter is on using WF as an XML Web service to integrate into ASP.net. However, when exposing XML Web services you should be aware of a number of key issues, the biggest problem being security. The full discussion of security goes well beyond what I can do here, but the link below should help you: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ Dnnetsec/html/thcmch12.asp. If you want to expose your workflow to an XML Web service, I strongly recommend that you look at best practices for asp.net security, especially around XML Web services.

Exposing a workflow to an XML Web service

Part of the reason you can't execute workflows directly in a asp.net environment in fact, as you've already learned in this book, the workflow runtime executes the workflow instance asynchronously by default. In fact, this is a very important feature when working with workflows in non-web applications.

But in a web-based environment, this poses a problem. If a asp.net request is sent, whether it is an XML Web service or a asp.net Web page, the workflow instance starts to execute and returns control to the ASP.net when it is run. Your XML Web service or ASP.net page will immediately and continuously prepare the output and may end before the workflow instance completes. Because the workflow instance is asynchronous, it executes in parallel with your asp.net application, so your asp.net code may quickly complete and return a response result that the workflow process has not completed.

Tip: Executing a workflow instance correctly on a asp.net web page is actually a call to the ASP.net asynchronous Web page, which is beyond the scope of this book. But here's a link to give you some specific details: http://msdn.microsoft.com/msdnmag/issues/05/10/WickedCode/.

This problem will at least bring us two challenges. First, we need to disable, or at least modify, the way our workflows are executed asynchronously. We need them to execute synchronously, as if they were using the same thread as our page or XML Web service, so that the Web application does not return the response results to the caller until we are finished. Of course, this does not solve the problem of long-running workflows, which is the second challenge we will need to overcome.

The challenges posed by long-running workflows are tightly linked to the nature of web-based applications. In this final chapter you know that Web applications are inherently stateless. The requests sent in milliseconds to disconnect are completely unaware of each other unless we create a framework to provide this capability. Web applications are also executed on a Web server, which is often a very expensive system designed to serve many clients. If a workflow takes a lot of time to complete, it will completely occupy the Web server and reduce the scalability of the application (referring to the ability to provide services for more and more client requests).

The solution is to perform state management and to persist long-running workflows. If your workflow is to be completed after more than one web-based call (ASP.net page request or XML Web service), you must persist the workflow instance and reload it during the next execution cycle. That's why I mentioned in the "Long-running XML Web Service" section in the previous chapter that the reason for regenerating the cookie that saved the session state was raised. Because the client must also be aware of this possibility and consider having more than one request-response situation.

Internet Information Services (IIS) are particularly adept at conserving system resources. In a typical client application, in every application you've seen so far in this book, the workflow runtime is started and runs through the lifecycle of the application as the application begins to execute. However, IIS will reclaim the server's resources. As a asp.net programmer, that means the next two things.

First, we have to decide in some way where and how to start the Workflow runtime. Different requests in the same ASP.net application are placed on different threads for processing, but they are executed in the same application domain (AppDomain). As you may recall, in every AppDomain can only have one WF workflow runtime instance in execution. So it's not as simple as creating an instance of a workflow runtime every time your ASP.net application receives a request. Doing so may cause the workflow to run with an exception.

Second, we need to find a way to let our workflows execute in a synchronized fashion. Or, if our workflow takes a long time to run, we have to synchronize when we start executing the workflow instance, when we stop executing, when we persist the workflow instance, and when we return the current state of the workflow to the client. To do this, we need to replace the thread scheduling service for the default workflow runtime. To replace the thread scheduling service, we need to reconfigure the workflow runtime.