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

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.

Getting 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!”

“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);

phoneCall.Configure(State.OffHook)
    .Permit(Trigger.CallDialed, State.Ringing);

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

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

// ...

phoneCall.Fire(Trigger.CallDialled);

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!”