"Translation Exercises" Windows Workflow Foundation Program Development-Chapter 01

1th Chapter Welcome to the world of workflow

... The mind flies to me like a butterfly--gossard/vedder

(Gossard and Vedder are 2 musicians from the Pearl Jam band, which is from their song "Even Flow")

Windows Workflow can be seen as one of the most compelling middleware products on the Windows platform following the COM + and Distributed Transaction Coordinator (DTC). The difference between them is that not every software application needs to be distributed, but almost every software implements the workflow within it. To be able to understand the purpose of Microsoft's design of Windows Workflow, let's start with the usual sense of workflow.

What is a workflow? Simply put, a workflow is a series of steps, decisions, and rules that are involved in accomplishing a particular task. Think about the process of ordering your order at a local pizza shop. You first tell the restaurant what kind of pizza you want. The waiter handed the menu to the chef and the chef proceeded to dispose of the ingredients and put them in the oven. Later, the chef gives the baked pizza to the hostess and treats the pizza in front of you and settles the bill. At this point, the entire process is over. The work "flows" to the hospitality, then "flows" to the chef, and finally "flows" back.

In each of these steps, all participants conduct a rule evaluation and make decisions. The chef should take a look at the after-the-kitchen preparation before accepting the Point menu. At checkout, if you come up with a coupon, the waitress will have to see if it works, and if you suspect you're paying with counterfeit money, he'll have to inform the restaurant manager.

Workflow doesn't have to be someone involved (that's good, because people have the ability to complicate the simplest process). A workflow can occur between two distributed application software. For example, two content management software might synchronize content between the two at night by applying a series of specific actions and rules.

Most workflows are stateful and often require a considerable amount of execution time. Fortunately, the pizza you ordered will be ready in 30 minutes. During this time, the status information of the point menu, such as the pizza hijab you have ordered, cannot be changed. Pizza Shop The process of setting cheese to suppliers is not the same as the pizza you ordered. The supplier is unlikely to deliver the cheese within 30 hours, and the pizzeria will not pay the supplier within 30 days. During those 30 days, for a transaction, something was needed to maintain the state of its workflow.

A workflow may spend most of its lifetime waiting for event information from the outside world for the duration of its life. The workflow is idle when the customer waits for a serving, waits for the customer to pay, or the chef waits for the pizza to be baked. In this case, the workflow does not require any resources.

A workflow is a series of steps that are performed to complete a task. Work flows over long periods of time, and it is stateful, often waiting for events and interacting with people. You'll find workflows everywhere. As programmers, we often have to implement workflows in the software we develop.

1.1 Creating a workflow Solution

We all have experience in a number of software development projects, and the purpose of launching these projects is to improve existing business processes through software. These processes may be about pizza orders, about financial transactions, or about health care. In any case, whenever we talk about these projects, we inevitably encounter the "workflow" of an old friend. The workflow seems simple, but deep down, you will find the hidden mystery. To manage workflow state, we need database tables and data access classes. We need email to send components and queue message waiting components. We'll also tell the computer how to execute the workflow. Let's start by looking at how the theoretical workflow is implemented:

 //  This is a workflow that processes a newly submitted purchase order class  purchaseorderworkflow{     Public void   Execute (purchaseorder order)    {        waitformanagerapproval (order);        Notifypurchasemanager (order);        Waitforgoods (order);    }           

Suppose we've given the definition of three methods in execute, does a workflow look really that simple? The answer is clearly negative. We have to write some code to implement exception handling, logging, and diagnostic functions. We need to raise the event and provide a hook function to be able to track and cancel the running workflow. At the same time, the workflow is idle for most of the time and waits for an external event to occur, such as waiting for the supplier to bring the placed goods to the door. While waiting for the arrival, we cannot let the running application thread empty for days or even weeks. We need to provide a mechanism that can save the execution state of a workflow to a persisted data storage medium, and then purge the running workflow instance from memory. When an important event occurs, we also restore the state of the workflow and let it go on.

Unfortunately, in this way, we add too much code inside and outside the workflow, so that we lose ourselves in the workflow, and there is a confusion that "does not know the truth, only in this mountain". All of these supporting code will mask the business process we are trying to implement. A business person who does not know the technology will never be able to see the workflow through this code. A programmer will not be able to clarify the workflow if it does not probe the code carefully.

An improved workflow design approach attempts to separate the definition of a workflow from the engine and supporting code that executes the workflow. This approach allows programmers, even business people, to describe what the workflow "should do" and let the workflow engine decide how to make the workflow work. Currently, many workflow solutions define workflows in popular angle brackets. Let's take a look at the theory of using XML to define workflow methods.

<WorkflowName= "Purchaseorderworkflow">     <Steps>         <WaitfortaskEvent= "Managerapproval"/>         <NotifytaskTarget= "Purchasemanager"/>         <WaitfortaskEvent= "Delivery"/>     </Steps>     <Parameters>         <ParameterType= "PurchaseOrder"Name= "Order"/>     </Parameters></Workflow>

One more thing to ask is, does a workflow look really that simple? The answer is yes; we also need a workflow engine that understands this XML and translates it into computer instructions. This engine will include all the necessary features, such as exception handling, tracing, and canceling execution functions.

The C # code we saw earlier is an example of an imperative programming approach. In this way, we describe "how" to accomplish a task by providing a series of executable instructions. The XML tag above is an example of declarative programming. In this way, we describe what the task looks like, and let the other software decide which steps to take to complete the task. Most commercial workflow solutions in the software market allow the use of declarative methods to define workflows, as this approach does not mix with low-level implementation details such as exception handling, event firing, and so on.

One of the benefits of using XML is that there are a number of tools that can read, modify, create, and transform XML markup code. In other words, we can use tools for XML development. XML tags are easier to parse than parsing C # code, and you can use graphics boxes and arrows to generate visualizations for your workflow. In turn, we can let business users use a visual designer, draw out a workflow diagram by connecting some graphics frames, and then automatically generate XML tags from the block diagram.

What exactly do we want to get from a workflow solution? We want to describe the workflow declaratively, and perhaps a visual designer is needed to help. We want to enter the definition of the workflow into a workflow engine. This engine runs the workflow and manages errors, events, tracing, enabling, and disabling operations.

The following is the Windows Workflow Foundation debut.

-[email protected] Blog Park-