Table of Contents
Acknowledgments.
Introduction.
Chapter 1: An Introduction to Workflow and Windows Workflow Foundation.
Chapter 2: Hello, Workflow!
Chapter 3: Breaking It Down.
Chapter 4: Workflow Development in Visual Studio.
Chapter 5: Workflow Hosting, Execution, and Communication.
Chapter 6: Activities.
Chapter 7: Runtime Services.
Chapter 8: Advanced Activity Development.
Chapter 9: Rules.
Chapter 10: State-Machine Workflows.
Chapter 11: Dynamic Update and Designer Re-Hosting.
Chapter 12: Exceptions, Faults, and Debugging.
Chapter 13: Windows Workflow Foundation and ASP.NET.
Chapter 14: Windows Workflow Foundation and Connected Systems.
Chapter 15: Window Workflow Foundation and the Microsoft Office System.
Index.
Read a Sample Chapter
Professional Windows Workflow Foundation
By Todd Kitta John Wiley & Sons
Copyright © 2007 John Wiley & Sons, Ltd
All right reserved. ISBN: 978-0-470-05386-7
Chapter One
An Introduction to Workflow and Windows Workflow Foundation
This chapter gives you an overview of how business applications were and are traditionally developed, as well as an introduction to workflow and the Windows Workflow Foundation platform.
A Little Background
Initially, computers were used at universities to solve mathematically complex problems. The use of computing power was limited to the world of academia for a period of time before the world realized computers could be applied to solve business problems. Thus began the era of business applications.
If you are reading this book, you likely have some involvement in the world of business applications. Maybe you write .NET code, C++, Java, SQL, or other language to help businesses achieve strategic or cost savings goals. If so, you play an important role in the success of modern business.
Traditionally, a business decides that a given project involving information technology is worth doing because it will give the organization a competitive advantage, trim operating costs, or automate acomplex manual process. Generally, the project's software developers gather requirements from the business, perform system and software design, and create the source code. Of course, any software development process worth its salt is much more complicated than that, but you get the idea.
The software development process has evolved greatly in the 50-plus years that businesses have been using computers to help solve business processes. In the not-too-distant past, procedural code was the de facto method for implementing software solutions. Over the past 10-15 years, object-oriented code has given developers a great way to build reusable blocks of code that can be mapped to real-world objects. This building-block approach, when used correctly, can lend itself to helping developers build software solutions more efficiently and quickly.
Order processing, new employee processing, and insurance claim processing are just a few examples of the types of business processes that can be automated. These processes are modeled and documented, at which point a software developer creates his or her interpretation of the process with source code. It is very common in the stages before the actual coding begins for a business analyst to capture the steps in a process and represent the process graphically or with a list of tasks that must be completed and in what order. At this point, the perfectly nice list or visual representation is reduced to source code so that a machine is able to perform the process.
This approach might work in many instances, and in reality, it has been working for many years now. That doesn't mean there isn't a better way. Although this book is dedicated to conveying the technical aspects of Windows Workflow Foundation, understanding the problem domain of workflow and business processes can help you, as a developer, relate the technology to its business drivers.
What Is Workflow?
Workflow is a word that means different things to different people. As you may suspect by the name, workflow defines a process flow or a set of tasks that produces a result. Although this is a good general definition, workflow is also commonly discussed in the context of software systems.
Workflow systems are often associated with the domain of document management. In general, document-management systems handle the transfer of documents between people and other software systems according to a set of policies and procedures. Although document management may be the default concept that comes to mind, it is by no means the only area associated with workflow.
In addition, an archetypal feature of workflow is graphical representation. Workflows are frequently shown as a series of shapes and icons that represent discrete actions. Arrows are also commonly used to represent the flow of work from one step to the next. Although document management and visual representation may represent a large part of workflow, they are really so much more.
Before going too deep into workflow, you need to understand why it is important. One of the top priorities of IT organizations in recent years automating and supporting key business processes. Business process management (BPM) is the framework that describes how organizations can achieve these goals.
Business Process Management
BPM has gained a lot of attention in recent years. Essentially, it is a set of activities that organizations can follow to better understand, implement, and monitor business processes. There are many resources available to you that discuss BPM, its traits, and implementation methods. However, in the context of this book, you need only a good understanding of BPM's high-level qualities and how it relates to workflow.
BPM is commonly broken down into discrete phases that take an organization from one level of maturity to the next. You can find many different descriptions of what these phases are by searching online. However, the following phases are generally represented in one form or another:
1. Design
2. Execution/deployment
3. Management/monitoring
4. Optimization
During the design phase, an organization takes a good hard look at the processes that support the business. Emphasis is placed on fully understanding individual processes and the steps they entail. This might sound fairly obvious, but to fully understand a process and determine where there may be efficiency gains, this phase is crucial. The output of this phase is typically documentation that details the design discoveries.
Typically, the next phase in the BPM lifecycle is to implement the processes that were documented in the design phase. This happens by either making personnel behavior modifications or by implementing or updating technical solutions. There are commercial products available to assist in this phase of the BPM lifecycle from vendors such as Microsoft and TIBCO. These systems are specifically geared toward the problem domain of process development, execution, and management.
Process monitoring describes the step in the lifecycle in which processes are tracked and examined during normal day-to-day operations. For example, the business may be interested to know how many orders are currently in the shipping stage of an order fulfillment process. This is a very important quality of a BPM implementation because if you cannot monitor what is going on with business processes, the metrics that the processes generate cannot help an organization learn and improve.
Monitoring is crucial for the last phase: optimization. Monitoring, when implemented effectively, can help expose issues in processes that were not identified during the design and deployment phases. As you might imagine, these phases are not performed just once - this is an iterative cycle of refinement and improvement.
Of course, for an organization to consider implementing BPM, there have to be some benefits to doing so. If a company better understands its processes and process components, the most obvious advantage is a decline in errors related to performing processes throughout the organization. In addition, because processes implemented through the BPM lifecycle produce valuable business metrics, it is much easier to monitor this information with reports, alerts, and other types of human-consumable data. Better yet, this data can be made available in real time so that adjustments to the process can occur much quicker than in the past, saving precious time and money. Overall, BPM can provide organizations with a larger degree of understanding of its processes while lending itself to better decision making and a higher degree of agility.
Workflow Tenets
According to Microsoft, there are four major tenets that architects and developers can use when considering workflow-based applications. Furthermore, a workflow platform, which can be defined as a software framework to assist in the development of workflow-based applications, should embody these features. The tenets are as follows:
Workflows coordinate work performed by people and software.
Workflows are long running and stateful.
Workflows are based on extensible models.
Workflows are transparent and dynamic throughout their lifecycle.
Workflows Coordinate Work Performed by People and Software
This tenet tells us that people play a vital role in the world of software systems related to workflow and processes. Human interaction often occurs through e-mail, web pages, mobile devices, or other front ends. In some instances, the interface between people and software can be part of the normal flow of a process. For example, a workflow might require a human to approve every transaction that comes through an e-commerce website. Human interaction may also be necessary to handle exceptions that cannot be managed in an automated fashion. This scenario may arise when a piece of information necessary for workflow progression is missing.
Because of this requirement, a workflow platform should provide features and infrastructure to effectively handle human interaction and all the issues that come along with it. This includes sending and receiving messages in an untimely manner. People cannot always be relied upon to act quickly or consistently.
Workflows Are Long Running and Stateful
This tenet is important due in large part to the previous one. Because humans are inherently not reliable and tend to interact with software systems on an ad hoc basis, workflows need to be able to run for long periods of time. More specifically, they should be able to pause and wait for input. This could be for hours or months or even longer. Consider a vacation-request workflow at a company. If an employee's manager is out of town, and the employee is requesting a vacation occurring nine months from now, the manager may not respond for weeks.
In addition, a workflow that coordinates software services that are external to an organization cannot rely on instant responses from these peripheral systems. Because of these characteristics, workflows need to be able to run, or at least be waiting to run, for an undetermined amount of time.
The stateful requirement means that the context of a workflow instance should remain intact while the workflow is waiting for feedback. Consider the vacation workflow that goes on for many weeks. If the workflow is not able to save its state, it may be lost forever if the server it is running on is rebooted due to a power outage or other issue.
Workflows Are Based on Extensible Models
The purpose of workflow is to automate a business process, and because each type of business has a wide range of problems, a workflow platform should be extensible at its core. What works for one business problem domain may not apply to another. It is reasonable that a workflow platform cannot account for every kind of activity that needs to occur in every type of workflow. The great thing about a well-architected, extensible system is that developers are able to build the components that were not included out of the box.
To apply this idea to another area, the workflow management architecture should also be extensible. Most workflow platforms provide functionality for persistence, tracking, and dynamic modifications. These areas should be open for extension by developers so that an organization's needs that were not covered in the platform's base functionality can be achieved.
Workflows Are Transparent and Dynamic Throughout Their Lifecycle
This tenet is easier to understand when compared to the traditional software development paradigm. In conventional software, the code itself defines the behavior of the system. As you know, writing and understanding code are very specialized skills that a very small percentage of the business population possesses. Because of this fact, software systems are generally considered to be a black box. People in the business cannot look at a block of code and ascertain what is happening behind the scenes. This can even be difficult for a developer if the code was written by someone else. Workflows should provide the advantage of being able to quickly and easily determine functionality at design time - that is, when the workflow is not running.
Additionally, workflows should be transparent during runtime. This means that a workflow should be able to be queried so that progress can be monitored while it is running. If you take this transparent runtime concept a step further, a running workflow's steps that have not yet occurred should be modifiable. Compare this to traditional code, which, after it is compiled, cannot change itself. This notion of a workflow that can be changed during runtime is very powerful and can open a new set of possibilities related to process automation.
Types of Workflows
At the risk of being too general, there are two types of workflow: ordered and event-driven. Both types provide distinct functionality and would be used in different situations, depending on the requirements of a given system.
Ordered Workflows
When people think of workflow, the first thing that comes to mind is probably an ordered workflow. An ordered workflow represents a process that starts with a trigger and flows from one step to the next in a predefined order. The process likely contains control or decision-making logic that includes if-then statements and while loops.
The steps in an ordered workflow and the order in which they occur are non-negotiable based on the workflow's definition. For example, in an order processing scenario, a customer's credit check always occurs before the order is shipped. It wouldn't make much sense to swap those two tasks.
Event-Driven Workflows
Event-driven workflows, sometimes called finite state machines (FSM), are based on the idea that you start in one state and jump to another state based on a specific activity or event. For example, a light switch starts in the off state. When someone performs the turn on light action the light switch transitions to the on state.
Like ordered workflows, event-driven workflows have rules that describe which states can transition to other states based on some predefined events. It would not make sense for the light switch to transition to the on state if someone unscrewed the face plate.
Workflow Scenarios and Examples
Now that you have a good handle on what traits a workflow platform should possess and what types of workflows exist, the following sections discuss various workflow scenarios and illustrate a few supporting examples.
Human-to-System Interaction
The aforementioned workflow tenets mentioned that human-to-system interaction is vital in the context of workflow-based systems. The importance of this principle cannot be overemphasized.
System-to-System Interaction
As you now know, it is important for workflows to be able to interact with people. It is equally important that systems are able to interact with other systems through a defined workflow. This process of tying external systems together in one cohesive set of steps is sometimes referred to as orchestration. If you are familiar with Microsoft's server product BizTalk, you have probably heard this term.
This type of workflow is commonly associated with service-oriented architecture (SOA). SOA is a large topic that is discussed briefly later in this chapter and in subsequent chapters of the book.
Application Flow
A workflow does not have to be an interaction between entities that are external to each other. A common scenario is defining the order in which to display data entry forms or other interface to a user. Think about a college application website. The order in which pages are presented to the applicant is important and is probably based on the education program to which the user is applying.
(Continues...)
Excerpted from Professional Windows Workflow Foundation by Todd Kitta Copyright © 2007 by John Wiley & Sons, Ltd. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
loading...