Workflow 4.0 Is Disappointing

Well, to me it is vastly disappointing. Back in January, I said that I thought Workflow 4.0 would be the most important feature of .NET 4.0. I was completely wrong. WF 4.0 will be a rather uneventful part of the .NET 4.0 release.

My initial projection was partly because .NET 4.0 will (thankfully) be a rather quiet release at core with only limited new language features so the competition was never all that steep. But it was also because the WF in the CTP represented an important change to Workflow. Microsoft screwed up WF 3.0 and 3.5. It was excessively complex for the marketplace. They implicitly acknowledged this when deciding to scrap the entire thing and start over with WF 4.0. While some people do have deployed applications, WF 3.0 and 3.5 could not be the ubiquitous WF I think we all need in our toolbox. I was hoping WF 4.0 would be that tool.

The bad news is that WF 4.0 probably won’t be. WF 4.0 suffers from two problems, one implied by the other. The first problem is that it has no state machine. At least it’s not in the beta and I have heard no contradictory announcement. The second is that if they could not even provide basic functional parity with WF 3.0/3.5 how could they possibly have had their development act together/sufficient resources/fill in the blank to produce a great 1.0 product. Remember, with the rewrite, WF 4.0 is really a 1.0 product.

I hope I’m wrong on the second part of this and that they’ve covered an adequate range of real world scenarios that it will at least be solid. And WF 4.0 will probably be an interesting tool in the core scenarios, particularly those around WCF integration. I’m not saying it’s useless by any means. I’m just saying it’s probably not going to change your world.

I’m still angry about the lack of a state machine. Certainly WF 3.0/3.5 state machines will still work as well as it ever has, and if you can manage deployment and avoid the layout being trashed by the IDE (hint, keep your layout files ready for restore from source control or edit them to find your lost states). But I’m angry because you and I can’t give our customers new products that just ignore half the scenarios for the old product. We can’t toss out all the work our customers have done (interop is present but limited). We just can’t do stuff like this!

I know the WF team has been working hard and that there are really smart people on the team. I don’t know what went wrong, but the problems with WF 4.0 became the problems of the early adopters, and shafting early adopters (especially when two years still involves “early adoption”) is very bad business.

In fairness, they offered a flowchart solution which will on paper accommodate some of the scenarios where state machines made sense. It’s just the wrong solution, and a horrible decision to do something new while ignoring previous functionality – state machine should have had a higher priority.

The vast majority of non-trivial workflow scenarios are best solved with a state machine. It’s based on a quick analysis. Theoretically all state machines can be expressed in flowchart terms and all flowcharts can be expressed as state machines. So in theory as long as you have either you’re covered. But it doesn’t quite work out that way. Business systems have non-trivial numbers of states. As the number of states increase, the number of legal paths between them increases. The theoretical increase is huge, but unimportant because many states are illegal. However, a sufficient number of legal states remain that as systems become more complex, the number of paths in a flowchart increases very fast. Paths are added more often than states (paths are the most common unexpected side cases). Thus, the system also remains more stable if the initial analysis is against states, not paths. Finally in many business systems, thinking of the problem in terms of states simplifies analysis.

The good news is that WF isn’t the only new thing in .NET 4.0 and in my next couple of posts, I’ll talk about what I now think are some of the most important features of the next release.

16 thoughts on “Workflow 4.0 Is Disappointing”

  1. Thanks for sharing

    In my opinion it is better sooner than later, but still shame on M$. :-(
    Especially as it will impact quite a few MOSS instances.

  2. Ugh – really? No state machine in WF 4.0… darn!

    I keep wanting to really love me some WF but it is so hard especially when MS keeps reinventing it and that 3rd parties typically don’t want to compete with a MS framework solution.

    If you have any suggestions, though, on alternatives, or news regarding a possible state machine inclusion, please keep us posted!

    Regards,

    Paul

  3. So, I guess it would make sense to trod through WF 3.x, since 4.0 is not a game changer. I considering WF for approval process part of an application.

  4. Hmm.. Not sure I get this. Doesn’t WCF operate on a state machine? If they wipe state machine from the 4.0 framework, does that mean a total rework of how wcf proxies work? Well, hopefully they have at least put in a dispose method that will abort connections on a service fault rather than closing and failing, but still I am a little puzzled…

    Admittedly, though, I have not played with the 4.0 framework yet. So much to do.. *sigh*

  5. Here is the quote
    First of all, you should definitely not interpret the planned lack of a StateMachine Activity in .NET 4.0 as a long term value judgement on the StateMachine or a long term plan to not support such an orchestration style. We plan to provide a rich eco-system of activities in the years to come and State Machine is at the top of the list. The lack of StateMachine in .NET 4.0 is only a statement on that release.

    To specifically answer your question, “Why was StateMachineWorkflow dropped out of WF4 …. “. When you release any very large product like .NET 4 there is a trade off between getting the new product to customers so they can start using it, and waiting to add more features in. We feel that the value we are adding with the new WF runtime and the modeling styles we have is very compelling and we wanted to get this to customers as soon as possible so they could start taking advantage of this value prop. It was a very hard decsion but it was determined that the earlier time to market for the product out-weighed the StateMachine activity. That said, we have gotten strong feedback on the value of the StateMachine activity from a number of customers.

    Thanks
    Bob– WF Team.

    And here is the url where quotation comes from
    http://social.msdn.microsoft.com/Forums/en-US/wfprerelease/thread/25e4fc38-24b2-4727-a552-cd7c06d2e55a

    I agree with you and stic. Lack of state machine is a shame of M$. How can M$ let down developers and customers like that? But good news, as indicated above, is hopefully we can get this feature sometime (well, probably not with the final release of VS2010). I guess what we can do is just waiting and praying.

  6. Very disappointing. MS always does this. I do not know who makes these decisions over there. STATE Machine was the most important part of the wf that most developers used and MS did not care about that.
    Hopefully MS wf team can relase a new version of WF4 quickly which has all the wf feature 3.0 and 3.5 had plus whatever they want to add on top.

  7. For the Comments on lack of state machine, the WF 4.0 allows you to .Persist in an extension allowing for the logic to save state, the rest is handled in xaml.
    It also has custom components That allow you to reuse the old workflows or capture part of them. The new tools allow me to completely do away with SSIS, so all in all it is a good release.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>