Thoughts on Waiting until 20xx for WF

Usual msblog disclaimer applies, this represents my opinion!

While I was on break, a number of folks pinged me asking me about this blog post by Tad Anderson.

I find the investment in time to learn how to use 3.0/3.5 has been a complete waste time. So we have release 1.0 and 1.5 of WWF becoming obsolete in favor of version 2.0. These are the real release numbers on these libraries, and that is how they should have been labeled. They are not release 3.0 and 3.5.

First, your investment in the existing technologies is not a "waste of time."  The idea of modeling your app logic declaratively, via workflows doesn't change, nor do the ideas surrounding how one builds an application with workflows.  What we are fixing is that we are making it substantially easier to use, and enabling more advanced scenarios (like implicit message correlation). What you will not be able to re-use is some of the things you did the first time and thought, "hmmm, I wonder why I have to do that [activity execution context cloning, handleExternalEvent, I'm looking at you]."  From a designer perspective, your not going to have to keep remembering the quirks of the v1 designer.  I think about this similarly to the way we went from ASMX web services to WCF.  The API's changed, but the underlying thinking of building an app on services did not.  Regarding version numbers, all of our libraries are versioned to the version of the framework we ship with (see WPF, WCF, etc).  Internally we struggled with what we call the thing we're working on now and decided to stick with framework version (so WF 4.0, rather than WF 2.0). 

Secondly, it's important to note, we're not getting rid of the 3.0, 3.5 technologies.  We're investing to port them to the new CLR, and work to make the designers operate in VS 2010.  If you get sufficient return by using WF in your apps today, use WF today. If WF doesn't meet your needs today, and if we're fixing that by something that we're doing in 4.0, then it makes sense to wait.   Note, I'm not defining "return" for you.  Depending upon how you define that, you may reach a different conclusion that someone in a similar setting. 

Thirdly, activities you write today on 3.0/3.5 will continue to work, even inside a 4.0 workflow by way of the interop activity.  Much as WPF has the ability to host existing WinForms content, we have the ability to execute 3.0-based activities. 

There is a larger issue of how we (the big, Microsoft "we") handle a combination of innovation, existing application compatibility, and packaging of features.  I'm not sure how we avoid the fact that inevitably, any framework in version n+1 will introduce new features, some of which will not be compatible with framework version n, some of which may do similar things to features in framework version n.  Folks didn't stop writing WinFroms apps when WPF was announced (they still write WinForms apps).  As I mentioned, this is a big issue, but not one I intend to tackle in this post :-)

The feedback we got from customers around WF was centered around the need for a few things:

  • Activities and Workflows
    • A fully declarative experience (declare everything in XAML)
    • Make it easier to write complex activities (see my talk for the discussion on writing Parallel or NofM)
    • Make data binding easier
  • Runtime
    • Better control over persistence
    • Flow-in transactions
    • Support partial trust
    • Increase perf
  • Tooling
    • Fix Perf and usability
    • Make rehosting and extensibility easier

Most of these would require changes to the existing code base, and breaking changes would become unavoidable.  The combination of doing all of these things makes the idea of breaking all existing customers absolutely untenable.  We're doing the work to make sure that your WF apps you write today will keep on working, and with services as the mechanisms to communicate between them, one can gradually introduce 4.0 apps as well.  Given the commitment we have to our v1  (or netfx3) customers, we don't want to introduce those kinds of breaking changes.

Kathleen's article summarizes this very nicely, and rather than be accused of cherry-picking quotes, I encourage you to read the whole article.

Questions, comments, violent flames, post 'em here or mwinkle_at_largeredmondbasedsoftwarecompany_dot_com