jump to navigation

The Economics of Authority – Windows Workflow and Why You Should Cash In Before Rolling the Dice January 18, 2010

Posted by ActiveEngine Sensei in ActiveEngine.
Tags: , , , ,

Although many measure their success by their salaries, bonuses and bank accounts, this report card can be a limiting factor when starting a new endeavor. If you follow this train of thought too closely your creative muscles will atrophy and very likely you will be unable to capitalize on opportunities as they arise. Or worse yet, you will be unable to recognize the need for you to break out of mold.


Sometimes you can obtain a payment of a different kind from struggling with a new idea: authority, recognition, reputation, knowledge, and maybe skill. For those of you who are feeling limited by your development environments , flexing your creative muscles can be an even greater challenge. There is also a danger for a great many of those who are too comfortable, as they are so accustomed to their current development frameworks they don’t know that they are “out of shape”.

It is too easy to become a subject matter expert, drink the cool aid and parrot every podcast that you hear that technology X is the leading edge solution. Going to the next client offers a new opportunity to build a solution based on the gibberish that was misconstrued as leading edge. If it’s new enough then there is a chance that few others will be able to actually challenge the new silver bullet’s validity as a viable solution. In software we do this all the time. It is a form of lying. While in the short term it may appear that you are enhancing your authority by bringing new solutions to a client, in reality you are diminishing your authority.

2635045177_ab5d39ee34Getting out the big guns for a fight, Sensei is taking a stand as he recently repudiated the recommendation to use Windows Workflow Foundation.

Consultants mindlessly repeated the vapid corporate mantra that since MOSS 2007 is built with WF, you can simply host workflows in Sharepoint and should become the defacto development platform for all workflows. Yeah, simply transfer it in and it works. State machines, no problem. Persisting long running workflows, no problem. It’s Microsoft, they’ve worked on the product and it’s mature now that Sharepoint is built on the framework.

Well, there are plenty of issues when hosting state machines in Sharepoint, and given that the terminology is rather obtuse – correlation token, scoped activity – what… really? – it will sap the strength from the hardiest of you. To get data in and out of the workflow will take 3 projects in your solution. 3. K Scott Allen has by far the simplest tutorial but consider that you’re team will want to master the technology without becoming an astronaut. Getting data in and out from the workflow requires extra work via interfaces and event handlers. This is fine, but then this, too, can be an obstacle when trying to wade through the materials learning the framework. Next, add the complexity of hosting long running workflows and debugging the persistence operations with the database. In the end it is a long haul to get an understanding of how this technology should , but this is not the same as knowing how the technology will work in your scenario. Having read the white papers, heard the podcasts, etc., will mis lead you. This is complexity that will keep you up at night and will not help you make your deadlines. As an aside, Microsoft has completely overhauled the framework and will be releasing WF 4.0. Obviously something was wrong. As the King says, “All this aggravation ain’t satisifaction in me!”

jtkirk003ffpra“Alllll rightly then, Mr. Wining-ActiveEngine-Sensei, what did you do?”

Sensei hunted far and wide, traversing the multiverse know as the Hive-Mind Collective and queried: Is there is an open source library that simply can represent a state in a state mchine, integrate with an existing database schema, not require multiple projects to run, and support long running processes? Will is be .Net compatible, will it require a series of baggage that will cause a headache?

Such a framework exists and Sensei wants to introduce it to. It’s called Stateless and it is by Nicholas Blumhardt, creator of Autofac. It rocks. Like 1968 Elvis no drug trip karate kick ass rock. Here is a sample from the project and Sensei hopes to post more in depth later.

How about creating a State Machine like this?

var phoneCall = new StateMachine<State, Trigger>(State.OffHook);

    .Permit(Trigger.CallDialed, State.Ringing);

    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.CallConnected, State.Connected);

    .OnEntry(() => StartCallTimer())
    .OnExit(() => StopCallTimer())
    .Permit(Trigger.LeftMessage, State.OffHook)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.PlacedOnHold, State.OnHold);

// ...


Very expressive. No sign of correlation tokens and other confusion. Just these lines. Now to answer Sensei’s challenge of hosting a long running workflow. You see, the state is can be simply retrieved from an external source as Nicholas illustrates:

var stateMachine = new StateMachine<State, Trigger>(
    () => myState.Value,
    s => myState.Value = s);

Restore the state of your workflow on the same thread as your Asp.Net page on the constructor. You can represent your state as an integer, string, what ever you want. Simple. Intense. In a pinch what would you bet on? Take it on out with the King and “satisfy me!”


1. A'braham Barakhyahu - February 25, 2010

looking forward to hearing more about your experiences with Stateless. I haven’t found many who talk about it or use, but I agree it’s a better fit than WF in many instances. One of my projects wanted the workflow to be behind a service, be able to go back and forth in workflows, etc. Seems like Stateless will be more maintainable, even though you have some more coding to do. Not afraid of that, rather more coding then more maintenance hassle.

2. ActiveEngine Sensei - February 25, 2010

Thanks for reading and I’m glad you find the topic of interest. Stateless is a great piece of work, and it’s creator Nick Blumhardt has created something really elegant.

With Stateless you have very little coding to do. Primarily the code you write is centered around the configuration like the sample shown in the post. Essentially your code will be the configuration of the transitions from the states to their respective target states.

This is more code as there is no designer for you to use to configure the targets, but remember that the designer in WF has a code behind, and in the end this will contribute the overall code base of your solution.

The one thing I like the most about Stateless is the fact that creating a new workflow follows these simple steps:

1. Identify all you your states.
2. Identify those triggers to move the workflow from state to state.

I end up with two list lists. Already your mind is clear with what you have to do. Once the transitions from state to state are written, testing can begin. No clutter from other interfaces, multiple projects, etc. Within a day I can have a fully functioning workflow tested and in production.

I’m trying to get my sample workflow together to post. I’m very happy to share more with you. Thanks again for reading the blog.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: