A simple application may be implemented as shown in the following figure.

Figure 1: Simple unified logic that runs in a single process and thread (Courtesy MSDN).

The above pseudo-code takes input from the client and based on the input executed different paths. Note that the input is taken at different points in the code. The state of the application/process is represented here by a simple string. Although this application development style is simple and easy to understand, it is not scalable. Imagine you are using such application logic for a hiring process where the inputs can come after days and even weeks. Your server would have to keep the process alive and running for this whole period. Imagine how much resources it would take to cater for thousands of users. What if the server fails during this period?

Considering these problems, lets look at another solution. This time round we separate the application logic at the freezing points (the input). Breaking the application logic allows the application to run as two different threads. This can solve a few of the problems described above.

Figure 2: Breaking the application logic (Courtesy MSDN).

Note that this time round the state is stored outside of the process in a database. The reason is that whenever the second process starts it needs to get the current state from some “persistent” store. Also note that the two application parts can now run on two different machines. Can you see a problem with this? The problem comes from the fact that it is hard for the second process to know whether the if was executed in the first part or the else (of course you would have to make this a part of the state). The point here is that the state becomes complex and we have to introduce a number of checks in the second part of the application.

The first figure is how our usual desktop applications run. they have their state stored in some memory variables that vanish as soon as the application ends. The applications which remember what you did last time have to save this state in some persistent storage. The second example is how ASP.NET applications work. The application logic is implemented in a distributed manner (on different pages). This not only makes it difficult for people to understand the process but also the programmer has to perform a series of checks whenever a page loads. It is also to be noted that the first type provides us unified logic whereas the second provides us scalability.

The Solution

Using windows workflows can help us solve these problems. WF function just as a normal program providing mechanism for input, output, control flow etc. However, all these are done with the help of activities, see diagram below.

Figure 3: In a workflow all the things are done with the help of activities (Courtesy MSDN)

As you can probably already see that unified logic is provided by workflows, let us see how WF solve the problem of scalability. All the work in the WF is done using activates, and as seen the WF provides all the elements of a usual programming language. The difference however is that all these activities are classes themselves, and they are executed on a WF Runtime which knows how to run these classes (activities).

Figure 3: WF Runtime executes activities in order (Courtesy MSDN).

When it begins the workflow runtime executes the outer most activity first, which in this case is a sequential workflow. Then it executes the activities one after the other in order determined by the workflow. One thing to note here is that the activities are objects, and therefore can be described in any language, making the workflow independent of the language. Also that the WF Runtime does not know anything about the internals of the activity it is executing, allow the programmer to fill in what is to be done. WF provides a Base Activity Library (BAL) from which you can pick activities to include in your workflow. You can also create activates of your own, called custom activities.

The big question arises, why go through all this pain? The first answer to this question has already been answered, it provides unified logic. However, to be scalable the server application cannot be stuck with one process. One solution to this is the ASP.NET way, i.a. to break the application logic down into small chunks, however this is something we are trying to avoid. Moreover, the programmer than has to explicitly deal with state. As you can probably notice this WF is already broken down into chunks, this allows the WF to persist (not block waiting for an event). When at the start of our example workflow, the workflow is waiting for input the WF Runtime realizes this and stores the state of the WF in a persistent storage (we say the WF persists). This allows for the server resources to be used elsewhere. When the input arrives the WF Runtime wakes up the WF.

Figure 5: The workflow can persist (Courtesy MSDN).

Another advantage of the workflow being broken down from the perspective of scalability is the ability of the WF to be run on different machines when it resumes, as shown in the following diagram.

Figure 6 Different parts of a workflow can run on different machines

Other Benefits

Other benefits of using windows workflows include the following

Coordinating Parallel Work

The WF allows you to coordinate parallel work in a better way by using the parallel activity which is part of BAL (More on this in later articles).

Figure 7 Workflows can run parallel activates (Courtesy MSDN).

Providing Tracking

Tracking processes is an important part of any business application. WF makes it extremely easy to do this by providing tracking services. The tracking services are extremely closely linked to persistence (state maintenance) because the state of the WF has all the information one needs for tracking a WF.

Figure 8 You can track the WF using tracking services (Courtesy MSDN).

Creating custom activities

WF allows you to create custom activities that you can re use as is suited to your business application, allowing to use OO concepts in WF.

Figure 9 You can create custom activities (Courtesy MSDN).

Fully Declarative Language

WFs are fully declarative as each workflow is represented by a corresponding XAML file.

Figure 10 WFs are fully declarative (Courtesy MSDN).

Related articles

http://msdn.microsoft.com/en-us/library/dd851337.aspx

Share on Facebook