WF itself is a programming model, along with an engine and a set of tools for building workflowenabled applications. The programming model is made up of exposed APIs that other programming languages can use to interact with the workflow engine. These APIs are encapsulated within a namespace called System.Workflow. That namespace will be part of the WinFX programming model, but can also be installed as an add-on to the existing .NET Framework 2.0.

The easiest way to interact with the new APIs and namespace is through the Workflow Designers, which you can add onto VS2005. You must download and install WF (more on this in the next section) unless you’re using Windows Vista as your operating system. When you download and install the foundation, WF gets bolted onto the .NET Framework 2.0 and VS2005. Within VS2005, you’ll have new project types and will be able to import and use the System.Workflow namespace. The new Workflow Designer projects allow you to design workflow visually using he same drag-and-drop methods you use for creating Windows or Web-based applications. Within the designers, you build workflow much like you’d create a flowchart with a tool such as Microsoft Visio. WF also allows you to package the designers for reuse. For example, you could build a Windows application that allows business people to create their own workflow libraries. The design tools that become part of VS2005 make up the first component of the overall WF. The next component is the actual workflow. Workflow is made up of a group of activities. These activities facilitate a business process or part of a business process. Activities are a central idea within the concept of workflow and the WF. A single workflow within WF is made up of one or more activities. In the context of the WF, activities are the actual work units necessary to perform a workflow. A number of out-of-the-box activities are provided as part of the WF. These out-of-the-box activities are part of the WF base activity library. You aren’t restricted only to these activities; you can create custom activities and create your own library. You create the custom activities using the VS2005 Workflow Designers.

The next component of the WF is the WF runtime engine. The WF runtime engine executes workflow, made up of activities, and created with the VS2005 Workflow Designers. The runtime engine also includes services such as scheduling, state management, and rules. The scheduling service schedules the execution of activities within a given workflow. The state management service allows the state of a workflow to be persisted, instead of storing that state in another mechanism, such as a database. The rules service executes Policy activities. You can create workflows that are based on business rules and that perform some action when those rules are satisfied. The rules service handles all this. The last component of WF is a host process. WF itself doesn’t have an executable environment. Instead, another process must host the runtime engine and workflows. This host process may be a Windows application or an ASP.NET application. During development, this host process is VS2005. The soon-to-be-released Microsoft Office 12 can also be a host for a workflow created with WF.

Source of Information : Apress Foundations of WF An Introduction to Windows Workflow Foundation

• 0 comments »

If workflows are important, then why use Windows Workflow Foundation? Microsoft has provided this foundation in order to simplify and enhance your .NET development. It is not a stand-alone application. It is a software foundation that is designed to enable workflows within your applications. Regardless of the type of application you are developing, there is something in WF that you can leverage.

If you are developing line-of-business applications, you can use WF to orchestrate the business rules. If your application comprises a series of human interactions, you can use a WF state machine workflow to implement logic that can react to those interactions. If you need a highly customizable application, you can use the declarative nature of WF workflows to separate the business logic from the execution flow. This allows customization of the flow of control without affecting the underlying business logic. And if you are looking for a better way to encapsulate and independently test your application logic, implement the logic as discrete custom activities that are executed within the WF runtime environment.

There are a number of good reasons to use WF, and here are a few of them:

• It provides a flexible and powerful framework for developing workflows. You can spend your time and energy developing your own framework, visual workflow designer, and runtime environment. Or you can use a foundation that Microsoft provides and spend your valuable time solving real business problems.

• It promotes a consistent way to develop your applications. One workflow looks very similar to the next. This consistency in the programming model and tools improves your productivity when developing new applications and your visibility when maintaining existing ones.

• It supports sequential and state machine workflows. Sequential workflows are generally used for system interactions. State machine workflows are well suited to solving problems that focus on human interaction.

• It supports workflow persistence. The ability to save and later reload the state of a running workflow is especially important when modeling human interactions and for other potentially long-running workflows.

• It supports problem solving using a domain-specific model. Microsoft encourages you to develop your own custom activity components. Each custom component addresses a problem that is specific to your problem domain and uses terminology that is common to the domain.

• It provides a complete workflow ecosystem. In addition to the workflow runtime itself, Microsoft also provides a suite of standard activities, workflow persistence, workflow monitoring and tracking, a rules engine, and a workflow designer that is integrated with Visual Studio, which you can also host in your own applications.

• It is infinitely extensible. Microsoft provides a number of extension points that permit you to modify the WF default behavior. For example, if the standard SQL persistence service that is provided with WF doesn’t meet your needs, you can implement your own.

• It is included with Visual Studio and available for use in your applications without any additional licensing fees. Because of this, it has become the de facto standard workflow framework for Windows developers. The growing communities of WF developers frequently share their ideas, custom activity components, and other code.

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

• 0 comments »

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

• 0 comments »

Introduction to 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.

[ Read more ... ]

Why Choose Windows Workflow Foundation
Microsoft has provided this foundation in order to simplify and enhance your .NET development. It is not a stand-alone application. It is a software foundation that is designed to enable workflows within your applications.

[ Read more ... ]

Architecture of Windows Workflow Foundation
WF itself is a programming model, along with an engine and a set of tools for building workflowenabled applications. The programming model is made up of exposed APIs that other programming languages can use to interact with the workflow engine. These APIs are encapsulated within a namespace called System.Workflow. That namespace will be part of the WinFX programming model, but can also be installed as an add-on to the existing .NET Framework 2.0.

[ Read more ... ]

• 0 comments »