Pageflow Questions: Why not a state machine?

  • Article

Here's a comment from my initial post introducing the pageflow sample from wleong:

NavigatorWorkflow looks like a state machine to me.  Why create a new workflow type?

Tuesday, June 12, 2007 3:44 AM by wleong

This is a good question.  There a couple of reasons why we create our own workflow type:

  • To more accurately model a process
  • Enable different execution semantics
  • Make development faster by focusing on the model, not the implementation details.

For a little more background on the problem, see my previous post on "Different Execution Patterns for WF (or, Going beyond Sequential and State Machine)" that talks in a little more depth about the trouble one can encounter by only think about the two out of the box models.

For this problem, in particular, all of the reasons are relevant.

Accurately modeling a process

It is very natural to think of UI navigation as a series of places we can be, and a set of transitions from any one of those places to another.  That's what the navigator workflow models.  There is a subtle difference from a state machine that plays to point 3 here.  This model allows me to not worry about putting an IEventActivity at the top of a state, then making some decision and then setting a new state.  We abstract away from defining the events, that's taken care of for us.  This lets us model the process naturally.  In a state machine, one could argue that modeling pageflow with transitions has me place one event and then have an IfElse activity that lets me decide which state to transition to.  This adds mental overhead to the model, moving me much closer to the implementation details (again, point 3).

Enable Different Execution Semantics

This was the primary reason I wrote the original article, my customer was doing some very unnatural acts in order to model their process in a sequential workflow.  In the case of UI navigation, we have the ability to be in multiple interactions at the same time.  The WF state machine has the (very natural) restriction that we can only be in one state at a given time (although there are certainly other state machine models that do not have that restriction). The pageflow sample allows you to be in multiple interactions at the same time, so think about filling out a mortgage application, I can be in the midst of many minor sub processes that all roll up into the larger application process, and I can jump from filling out my salary history to the details of the property I am buying by simply clicking on a tab at the top of the page.

Make development faster by focusing on the model, not the implementation details.

If we decide to use a state machine, we are coupling our model to the implementation and execution details of the state machine, which will cause us to do things that we don't need to do for this application.  The WF state machine is generic, any state can receive n different events and react to each on differently.  In pageflow, we know there is only one event, "GoForward" and then we have a set of rules to operate on that to determine where we transition to.  By spending the time to create our own root activity, we remove the burden of the implementation details from the workflow developer, allowing them to focus on the details of their process, not the configuration of a given activity.