Share via

Windows Workflow Foundation: Series Conclusion - Final Thoughts & Comparisons

  • Article

By Zoiner Tejada, Hershey Technologies

Articles in this series

Published: October 2009

In this article we conclude the series with a short review of the main points covered throughout in effort to provide a concise reference. In the article introducing this series we stipulated our goal and it is worth revisiting that goal as we summarize the takeaways:

The goal of the series is to provide guidance broken down into a series of articles following a standard format. Each article will consist of a business scenario that guides the development of the user interface and the workflow definition. For each business scenario, the workflow will be implemented twice: once as a Sequential Workflow and once as a State Machine Workflow. A particular technical aspect of WF will be compared between both root workflows to provide insights such as which allows for an easier implementation of the scenario, when the result is a workflow more readable by non-developer users, how the task can be accomplished using both root workflows, and, when an exact translation is not possible, what workarounds exist. By the end of each article, the reader should have a sense for how WF can be applied to a real-world scenario, and also how to accomplish a WF technical task as it is expressed in each out of the box root workflow type.    

Workflow is Adaptable and Flexible to Business Requirements

In the ten articles forming the body of the series we have demonstrated nine business scenarios where Windows Workflow Foundation can be used to implement process logic. We demonstrated sample implementations for various human workflow scenarios where end-user events drove the workflow forward. These included Job Requisition, Software Bug Reporting and Customer Relationship Management. Others demonstrated workflows that once launched were effectively orchestrations handling the coordination of calls to external systems: Blog Monitoring, Merchant Services, Image Archival and Conference Registration were all example scenarios of these. A final group of scenarios demonstrated how WF was well suited to the task of implementing computational workflows- workflows that ran some form of business logic and returned a result: Personnel Scheduling and a process for suggesting coffee selections to customers. Ultimately, the diversity of scenarios that can be implemented with WF is quite broad, and the variance of the scenarios certainly serves to illustrate this point.

Workflow Is Feature Rich

Along with each scenario we presented a particular technical aspect of WF to highlight its functionality.  From the basics of exploring how to build basic Sequential and State Machine Workflows, we explored how to build custom activities (including activities that use workflow queues for communication and remove the need to utilize the ExternalDataExchangeService all together) and custom activity designers. When such an event occurs, the Workflow Runtime resumes the workflow instance and provides the data item to the waiting custom activity

We reviewed how to implement robust workflows by implementing exception handling, as well as how to keep their definitions in synch with changes in the business environment by using workflow instance dynamic update.  We also saw how to use Rules, RuleSets and the PolicyActivity and leverage the rules engines functionality native to WF. We also dived into the infrastructural support for tracking and persistence to understand both how to report on and preserve long running workflows.

Pros and cons - Sequential and State Machines Root Workflows

With each article, we showed how to implement each scenario in using both a Sequential and a State Machine Workflow. Ultimately, we found that both tended to be semantically equivalent in their expressive power, but each had some benefits the other did not. Generally, sequential workflows prove useful for simple and smaller workflow definitions. State machines, by virtue of forcing you to break your logic into states, make for more decomposed layouts whose chunks are individually a little easier for the developer to manage.  This also introduced a verbosity of its own due to the State Machine’s event modeling and reliance on SetState activities.

That said, we were able to show how to create a sequence in a state machine, and that similarity carried through many of our examples. We found that different activities are available to each root workflow type, but the bulk of the out of the box activities are useable by both.

Loops can be created in both. In a sequence, you can use a While activity, a Conditioned Activity Group (CAG), or an Event Handling Scope. In a State Machine you can use While and CAG, but we showed how you can also have a SetState back to the state itself (with the StateInitialization representing the body) to create the loop.

Handling of events is one of the major areas of difference between the two root workflow types.  One can nest states and therefore implement shared event handlers in the State Machine. One can handle multiple events in a single sequence only in a Sequential workflow. We showed that certain event driven activities are particular to each: namely that EventHandlingScope and Listen are used only by Sequential workflows. The difference in event handling is primarily due to the restriction inherent to a State Machine workflow that there can be only one activity that implements IEventActivity, and it must be the first activity in the sequence in the EventDriven sequence of a State.

Exception handling at root workflow level was also a notable source for comparison. Unlike sequential workflows, the root State Machine Workflow has no place to express an exception handler and you can only add exception handlers to sequences of StateInitialization, EventDriven and StateFinalization.

In the end, there is no clear victor of which root workflow one should always use. The decision is based on a collection of requirements including developer preference, availability of activities, as well as desired handling of events and exceptions. There is, however, a general notion the Sequential workflows are a good fit for automated processes which tend to define a straight path to completion and State Machines are well suited to handling situations where the path to completion is non-linear.