Using WWF for ASP.NET program development

Author：Eve Cole Update Time：2009-06-30 16:01:52

Introduction

Using WWF, you can create Processor Flow-based workflows and deploy them in any type of .NET application. In addition, this article discusses some unique problems faced by ASP.NET developers - problems that may be solved through the use of workflows, such as maintaining state and page navigation.

In September 2005, Microsoft unveiled Windows Workflow Foundation (WWF, Windows Workflow Foundation) at its biannual professional developer conference. As one of the pillars of the WinFX API, WWF provides developers with a common framework on which to develop process-driven and workflow-centric applications.

Currently, some organizations are trying to automate entire business processes; their standard answer is to assemble a team of developers to develop the corresponding code. Although this approach works well for these organizations, there are some inherent problems. In order to understand this issue in depth, you need to understand the basic characteristics of a workflow.

A workflow is essentially a method for archiving the activities involved in completing a unit of work. Typically, during processing, work "flows" through one or more activities. These activities can be performed by machines or humans, and may be as simple as defining the order of pages in an Internet application, or as complex as managing a document or product that must be seen, changed, and approved by any number of people. complex.

Because so many workflows must allow for human involvement, they can take a long time to complete, ranging from a few hours to months or longer. For example, the people involved in the process may not be available, are not local, or are busy with other tasks; therefore, the workflow must be able to persist itself during all periods of inactivity. Furthermore, processes implemented independently through coding may be difficult for non-technical people to understand and difficult for developers to change. This and other factors are exactly the goal of generic workflow frameworks such as Windows WF - which aim to make it easier to create, change and manage workflows - either by providing them with a visual interface or by defining a common set of APIs. realized.

You can place WWF workflows in any type of .NET application - including Windows Forms, console applications, Windows services, and ASP.NET Web applications. Each type requires specialized considerations. Although some existing examples are sufficient to illustrate how to host workflows into Windows Forms and console applications, this article will focus on the issues faced by ASP.NET developers who want to integrate workflows into their own applications. .

Author's Note: The code provided in this article was created using Windows WF Beta 1 and Visual Studio 2005 Beta 2. You can find information about installing Windows WF at www.windowsworkflow.net . Although this article discusses some of the basics of Windows WF, there are other resources available in this area. I assume that the reader knows at least a little bit about Windows WF. The purpose of this article is to analyze Windows WF and ASP.NET in depth, rather than discuss Windows WF from a high level.

1. Windows WF and MVC patterns

When developing an ASP.NET application, a common way you might use WWF is to implement a model-view-controller (MVC) approach. In essence, the goal of MVC is to separate the presentation layer, application logic, and application flow logic.

Understanding this will be very beneficial when developing an ASP.NET application, please consider a help desk ticket workflow venue. Assume that a business user initiates this workflow by filling out an ASP.NET Web form and clicking a submit button. Next, the server notifies an employee using a Windows Forms application and the Help Desk that "a new ticket is available." The help desk employee will then work on the issue and finally close the ticket. If you use Windows WF to develop this workflow scenario, then all the processing logic and flow can be contained in the workflow itself, and the ASP.NET application will not need to understand this logic at all.

This kind of venue provides some solid evidence - separating description from logic is a good thing. Because this process of handling help desk requests is so mundane, if you use C# or VB.NET code to implement this logic in several different .NET applications, you will run the risk of duplicating coding or worse. --Using completely different code leads to different implementations of the same business process. But if you use WWF to implement this process, application developers who require this process will only need to modify the steps in one place - the workflow itself - without having to worry about changing the application logic. Code duplication and where to implement this process can be eased through the use of Windows WF.

When implementing an MVC architecture in ASP.NET using Windows WF, developers should try to build workflows that are independent of the application - while the workflow is still hosted within the application. This will help keep the logic independent of the description and maintain a high degree of independence between the sequence of work steps and the page flow in the web application.

A new WWF developer might try to develop a workflow with a fixed number of activities in a certain order, and then develop a set of ASP.NET Web forms that flow from one form to another in the same order. Unfortunately, although this seems logical, it is actually very unproductive because you will be implementing the workflow logic again. Web page X does not need to know whether it needs to go to page Y or page Z to implement this workflow step correctly. Instead, the workflow (model) should tell ASP.NET (the controller) what to do next; ASP.NET should then decide which page to display. This way, each page barely needs to understand the entire process; it just needs to know how to complete a different activity and let the workflow take care of how the page flows from one place to another. This separation gives developers a great deal of flexibility when dealing with page flow. For example, if you decide to change the order in which the pages are displayed, you can easily do this from within the workflow without changing a single line of code in the ASP.NET application.

2. A simple workflow MVC example

In order to illustrate this idea, I will show you a simple ASP.NET application and workflow. This oversimplified workflow describes a process that collects some private information from an external application and then displays it. The steps are as follows:

1. Invoke a method - this means requesting a person's name; this workflow uses the InvokeMethod activity (see Figure 1).

2. Wait until an event is fired - this means receiving a name; in this step, the workflow uses the EventSink activity.

3. Obtain an email address from the host using a similar call.

4. Waiting for an event means receiving an address.

5. After receiving the name and email, the workflow starts an InvokeMethod activity to send the personal information to the calling application. In a real-world situation, this last step is not very important. More likely, you will call a Web service to send the data to another system, or put it into a database.

Figure 1. Sample workflow: This workflow describes the process implicit in a sample ASP.NET application

To implement this workflow in ASP.NET, you need a page to collect people's names, a page to collect email addresses, and a page to display personal data. Remember, the data login form should have no idea what happened before or after it. The same goes for display pages. However, the ASP.NET application must know which page to display to the user; this is the purpose of introducing controllers. This example uses an HTTP handler to implement the solution. This custom handler, called WorkflowController, is responsible for the following tasks:

· Obtain a reference to the time when the workflow is running.

· Obtain a reference to an existing workflow instance or start a new workflow instance (this depends on whether a workflow instance has been started).

·Establish communication between controller and workflow.

·Handle events from this workflow.

·Tell ASP.NET which page needs to be displayed, depending on which layer in the workflow is currently being executed.

As you've seen, this custom handler essentially handles all the work related to WWF and page control - keeping individual ASP.NET pages "silent" about the actions going on in the background. The only thing a web form needs to worry about is performing the specific task at hand and passing the necessary data to the controller.

By default, WWF works in an asynchronous model. This means that when an application host starts a workflow instance, control is immediately returned to the host while the workflow continues executing on another thread. This may be useful in a Windows Forms application - where continued responsiveness of the user interface is highly desirable. By using this asynchronous model, the workflow can be executed in the background while the user can continue to operate the application. However, in a web application, this type of behavior may not be expected, since control will typically only be returned to the user after the server has completed a unit of work. This is exactly the embodiment of the scalability of Windows WF. In Windows WF, developers can use or create "runtime services" to monitor and even modify the workflow runtime. Examples include:

· Persistence service - stores workflow state between execution and idle times

· Tracing service - outputs information about workflow execution to some media

· Transaction service - helps maintain data integrity during workflow execution

In addition, threading services allow developers to control how workflow instances are executed. As discussed earlier, the workflow runtime will by default run the instance asynchronously on a thread independent of the host. But since this is most likely not what ASP.NET expects, you'll need to swap the default workflow thread service. Fortunately, Microsoft has provided a solution for this-ASPNetThreadingService. To implement this change, you can either add ASPNetThreadingService to the workflow runtime service by hand coding, or complete this task in the web.config file. The sample application in this article uses configuration mode. In the workflow runtime/services section of web.config (see Listing 1), add a line similar to the following:

3. Implement the controller logic

Next, you need to implement the controller logic with an HTTP processor. In order to build this controller, all you need to do is create a class called WorkflowController handler - which implements the IHttp handler interface. So far, you haven't seen anything special about Windows WF - this is a feature specific to ASP.NET (read on).

In this WorkflowController processor class, the IHttp processor interface method named ProcessRequest handles a Web request from the ASP.NET application. Here, you need to obtain a reference to a static workflow runtime instance, create event handlers for the workflow, and initiate workflow execution. Before starting a workflow instance, you need to check whether the request's query string value contains a GUID that represents a workflow instance ID. If this ID is present, you know there is already an instance running so you can get a reference to that instance and continue execution. If this ID does not exist, you need to create a new instance and start the execution process by calling the Start Workflow method at the workflow runtime.

After an instance is started, event handlers manage communication in and out of the workflow. Since the purpose of this article is not to discuss local communication services, I will not discuss this topic in detail here, but will analyze its high-level implementation techniques and discuss again how this works in an ASP.NET application. To facilitate communication processing, you will need several .NET interfaces - used to describe information in and out of the workflow and host. You will find these in the WorkflowClassLibrary project source code attached to this article. You will also find classes that implement these interfaces and the corresponding functionality necessary to implement the workflow mechanism.

Let's take another brief look at the web.config file. Note that near the ASPNetThreadingService element discussed earlier, we used three elements to describe the communication service class:

<add type="Workflow.RuntimeServices.GetNameService,
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/>
＜add type="Workflow.RuntimeServices.GetEmailService,
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/>
＜add type="Workflow.RuntimeServices.SendDataService,
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/>

There is also an element here that instructs the workflow runtime library to use the SqlStatePersistenceService. This additional service stores the persistence of a workflow state in a SQL server database between page requests. . You must create this database manually in advance, but Microsoft provides a SQL script to do this. You will find it in the C:WINDOWSMicrosoft.NETFrameworkv2.0.50215Windows Workflow FoundationSQL folder. Like model services, you can add these services programmatically, but you can also implement it in the configuration, which will greatly reduce the amount of code to write and provide flexibility - even after the code is produced. There is a line in the config that adds an HttpModule - which supports the Windows WF runtime library in ASP.NET; there is also a line that sets the Http handler controller discussed earlier. As you can see in this configuration. There are many things in it.

As a conclusion, Windows WF provides an extremely easy-to-use and extensible framework for developers to develop workflow-based applications. It has become and will continue to become an important application. Technology. Unless you are a technology services company or ISV, software must provide business and operational processes. By using tools such as Windows WF, developers can make the development process easy and flexible.