Overview of windows workflow foundation architecture

Introduction:

Whenever I came to know about Windows Workflow Foundation (WWF) a very basic question comes up in my mind, "Why Windows Workflow foundation?"

If you look at different products of Microsoft they have more or less workflow capabilities or at least support. For example Share point portal server, BizTalk Server etc. Especially BizTalk Server includes sophisticated workflow capabilities.

Anyhow later on I have concluded that all these workflow solutions have deficiencies. For example BizTalk Server does not have runtime workflow definition support which is normally required in BPM or even in System to System workflow solutions. Rather than enhancing all these products again and again Microsoft has decided to come up a highly flexible Workflow solution so that they can meet versatile workflow development requirements.

What are the common workflow requirements?

Following are the major workflow requirements which are striking in my mind right now.

• Application workflows for example leave approval.
• Document Life cycle management.
  
• Business process management.
  
• Web Application page flows.
• Integrating different systems.
  

Now what is an effective workflow solution?

I think an effective workflow solution involves not only process modeling and business rules, but also monitoring and analytics in order to respond to exceptions and other note worthy events. It should also enable the business user to define new workflows and business rules on the fly and also editing existing ones without the involvement of software developers.

Windows workflow foundation is an attempt to entertain all these real time rich workflow requirements through one common framework. So that organizations and individuals can enhance and reuse their workflow solutions in different applications.

WWF is a framework not a specific product. It is part of .net framework and it provides a foundation for developing machine to machine workflows to highly people centric workflow applications.WWF addresses all above common requirements. The idea behind WWF is component based development. A component in WWF is Activity which needs to be inherited from the base activity class. In the world of WWF, activity is execution unit which can be composite or standalone.

WWF is based on highly flexible layered architecture. WWF is comprises of following three layers. See figure 1 for reference.

1. Workflow Design.
   
2. Workflow Runtime.
   
3. Workflow Hosting.
   
   
   

   

Workflow Design

At this layer workflows are developed using activities. You can define sequential, state machine and flow chart types workflow. I will further iterate all these in next posts. You can also write business rules policies and can use these policies with in your workflows. Custom workflow models can also be developed using the base framework if required.
In sequential workflow actions are executed through predefined order. For example for getting register for a course you will follow a sequence of steps. In State machine workflow order of actions is not predefined. It is implemented through set of states and transition between states is made based on events. For example in a banking application messages between banks may be send through different mediums for instance Swift, Fax, Signed email etc.

Workflow Runtime

The runtime layer is heart of windows workflow foundation. It contains critical services from workflow framework point of view. The execution service is responsible for scheduling activities, Event handling, exception, tracking etc. Tracking service creates tracking events and passes these events to hosting layer. State management manages states that can also be persisted. Scheduler service schedules execution of activities. Rules service for business policy execution.

Workflow Hosting

Workflow hosting includes default implementation of following services, custom services can also be developed both to replace existing services and to add new ones if required.

1. Persistence
2. Tracking
3. Transaction
4. Communication
5. Threading
   
6. Timer

All above services are obvious requirement of a workflow solution. Persistence is required for long running workflows. If a workflow process takes days or weeks to complete for example student's admission process, a workflow engine can't retain instances of workflows for such longer period in memory. Tracking is required for the visibility of system at runtime. Communication is required to communicate with different components and services within application and with external world as well. Likewise Timer for calculating event triggering time, Threading for performance and responsiveness and Transactions for reliability and integrity. All these services are pluggable you can develop your own for your specific scenario and requirements.

From execution point of view WWF runtime is responsible for execution of workflow instances. It creates and raises events those are further handle through appropriate interfaces at host layer. This is a brief introduction of WWF architecture, in my next post I will try to further excavate in WWF and create an example of sequential workflow.