Matt W's Windows Workflow Place : pageflow

Pageflow Sample Update

mwinkle — Thu, 28 Jun 2007 01:48:36 GMT

Updated to version 1.1

Changes

Corrected the install to display the EULA at a more opportune time (thanks to this comment)
Updated to fix the exception being thrown at the completion of a workflow
- NavigationManager.cs
- AspUserInput.cs
- WebHostingModule.cs

To install this, download the bits (same location), uninstall the existing version and install this version.

Other Setup Notes

I got a few pieces of feedback on the setup to get things working, here are some hints to get up and running:

If you extract the samples.zip file in the install directory (Program Files\Windows Workflow Foundation Samples\...) they may be marked as read-only. Mark the whole directory as non-read-only (so you can write) and then you will be able to compile successfully.
To run the sample, you need to set up a persistence database, this will be used to store the state of the workflow while we are not interacting with it
- Then go into the App.config or web.config and find the ConnectionString settings and update it to point to the correct database. On most default VS installs, you can point at localhost\sqlexpress, but it can certainly be any sql install.

Other Notes

For the folks using WCSF, Glenn has a good summary that fills in some of the story on the WCSF side, and sneaks an Eminem reference into the title :-)

Pageflow questions: "What about WCSF / Acropolis / Codename 'foo'"?

mwinkle — Thu, 14 Jun 2007 23:34:02 GMT

So, I got a little bit of feedback from my initial post. First, thanks, it's great to see all of the interest in the technology. I want to use this as the place to answer common questions that arise about the sample.

Here's one that I got internally as well as externally(here, here )

What about WCSF and Acropolis? Does this change how we think about the problem today?

The short answers are "they are still here", "no".

WCSF

There are a lot of people who are using the Web Client Software Factory. It is definitely something you should check out, it is a great toolkit to build composite web applications. Part of what it does, among many other things, is the Pageflow Application Block designed to model navigation. This is what most people are wondering about when they first hear about the pageflow sample we released. Don't they do the same thing? From a functional level, yes, they both provide a nice abstraction to model flow through an application. This is a sample usage of WF to solve a similar problem in a little bit of a different way. The model inside the WCSF is extensible, allowing a different provider of pageflow information, so it is probably even possible to put this pageflow sample inside of the WCSF, I have yet to give that a try.

At a deeper level, there are some differences that stem from the implementation of the Pageflow Application Block as a state machine, which I will get into in my next post.

Acropolis

Acropolis, announced at TechEd last week, is still early on in its lifecycle, as part of the ".NET Client Futures". I haven't spent a lot of time looking at it yet, but it is something else which will have a way to model the flow within an application, in this case between WPF forms.

Conclusion

From a support perspective, it's important to note that this sample is unsupported (save for myself and a few others) as opposed to Acropolis and WCSF which have teams working on them.

It is important to note that both WCSF and Acropolis aim to solve a much larger problem than simple UI navigation. In that sense, in no way does the pageflow sample released represent a wholesale replacement of either of them. The sample that we released aims to illustrate a way to use WF to solve the problem of UI navigation. The important thing to take away from this is that it can be incredibly valuable to model the flow through one's application using a technology which allows separation from the UI. This makes our UI more loosely coupled with the rest of our application, and increases the agility to react to changes in process / data required / need to track infomation.

Also, even if you don't want to use this for pageflow, tune in, because there are some pretty valuable things that any WF developer can learn by taking a look at this sample. I will continue to discuss those as well.

Pageflow Questions: Why not a state machine?

mwinkle — Thu, 14 Jun 2007 18:00:03 GMT

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.