Introduction to Workflow

Why Workflow?
As developers, our job is to solve real business problems. The type and complexity of the problems will vary broadly depending on the nature of the business. But regardless of the complexity of any given problem, we tend to solve problems in the same way: we break the problem down into manageable parts. Those parts are further divided into smaller tasks, and so on.

When we’ve finally reached a point where each task is the right size to understand and manage, we identify the steps needed to accomplish the task. The steps usually have an order associated with them. They represent a sequence of individual instructions that will yield the expected behavior only when they are executed in the correct order.

In the traditional programming model, you implement a task in code using your chosen development language. The code specifies what to do (the execution instructions) along with the sequence of those instructions (the flow of control). You also include code to make decisions (rules) based on the value of variables, the receipt of events, and the current state of the application.

A workflow is simply an ordered series of steps that accomplish some defined purpose according to a set of rules. By that definition, what I just described is a workflow.
It might be defined entirely in code, but it is no less a type of workflow. We already use workflows every day we develop software. We might not consider affixing the workflow label to our work, but we do use the concepts even if we are not consciously aware of them.

Workflows Are Different
To a developer, the word workflow typically conjures up images of a highly visual environment where complex business rules and flow of control are declared graphically. It’s an environment that allows you to easily visualize and model the activities (steps) that have been declared to solve a problem. And since you can visualize the activities, it’s easier to change, enhance, and customize them. But there is still more to workflows than just the development environment. Workflows represent a different programming model. It’s a model that promotes a clear separation between what to do and when to do it. This separation allows you to change the when without affecting the what.

Workflows generally use a declarative programming model rather than a procedural one. With this model, business logic can be encapsulated in discrete components. But the rules that govern the flow of control between components are declarative.

General-purpose languages such as C# or Visual Basic can obviously be used to solve business problems. But the workflow programming model really enables you to implement your own domain specific language. With such a language, you can express business rules using terms that are common to a specific problem domain. Experts in that domain are able to view a workflow and easily understand it, since it is declared in terminology that they understand.

For example, if your domain is banking and finance, you might refer to accounts, checks, loans, debits, credits, customers, tellers, branches, and so on. But if the problem domain is pizza delivery, those entities don’t make much sense. Instead, you would model your problems using terms such as menus, specials, ingredients, addresses, phone numbers, drivers, tips, and so on. The workflow model allows you to define the problem using terminology that is appropriate for each problem domain.

Workflows allow you to easily model system and human interactions. A system interaction is how we as developers would typically approach a problem. You define the steps to execute and write code that controls the sequence of those steps. The code is always in total control. Human interactions are those that involve real live people. The problem is that people are not always as predictable as your code. For example, you might need to model a mortgage loan application. The process might include steps that must be executed by real people in order to complete the process. How much control do you have over the order of those steps? Does the credit approval always occur first, or is it possible for the appraisal to be done first? What about the property survey? Is it done before or after the appraisal? And what activities must be completed before you can schedule the loan closing? The point is that these types of problems are difficult to express using a purely procedural model because human beings are in control. The exact sequence of steps is not always predictable. The workflow model really shines when it comes to solving human interaction problems.

Source of Information : Apress Pro WF Windows Workflow in dot NET 3.5


Subscribe to Developer Techno ?
Enter your email address:

Delivered by FeedBurner