Partager via

Thoughts on Waiting until 20xx for WF

  • Article

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

Comments

  • Anonymous
    January 06, 2009
    Matt has a great post on WF 3.X and 4.0 – I totally concur.

  • Anonymous
    January 06, 2009
    It seems pretty clear the provisoes to work with WF 3.x are either you're already vested or have an immediate, compelling, and overriding need for WF in an application. Other than that the WF/C 4.0 impedance mismatch appears just too large to start investing in WF 3.x at this late date for anything but learning and familiarity. Also, and as an entirely off-topic note, it would be great if there were an MS Rules Server 2010 and accompanying Enterprise Rules[/Policy] Manager entirely independent of WF / BizTalk / SharePoint and which worked with Oslo's DSL capabilities and repository.

  • Anonymous
    January 06, 2009
    AvaSys.Healy, I think any technology one adopts needs to have a compelling need to the user.  I go back to what I said, if WF provides you with a positive "return" on a project today, go ahead and use it.  The tough part is how you define return.   When I was in evangelism around the time netfx3 shipped (late 2006, 2007), I was working with orgs who were super excited to have just moved to netfx2 and VS2005.  The definitions of immediate, "late date", etc are all relative to the situation one is in.

  • Anonymous
    January 06, 2009
    Great explanation Matt. On the "wish list" for WF 4.0 you published here, I've found at the last position what is one of the main topics we request to MS: Make rehosting and extensibility easier. I think that WF 4.0 adoption could be in creased expecially if you can provide a great and simple WF Designer Rehosting experience. Providing programs that make use of WF technologies with the ability to give the power of "customize" the Workflow to the end user via WF Designer could be really really interesting.

  • Anonymous
    January 07, 2009
    Demy, check out the last few minutes of my presentation at PDC (http://channel9.msdn.com/pdc2008/TL21/ ), not the questions but the very end of the talk right before the questions to see where we're headed.    It's been one of the features I'm responsible for, so I'm excited for folks to see what's going on there!

  • Anonymous
    January 08, 2009
    Matt W. Levels Questions On WF Concerns

  • Anonymous
    January 08, 2009
    WorkflowReferenceLinks: 1.我们能从BPMN2.0期望什么？ 前面的参考引用中提到BPMN不止一次，但是究竟什么是BPMN可能你还不大清楚。所以，还是让我们先...

  • Anonymous
    January 20, 2009
    The topic of 4.0 migrations has come up several times over the past week – in e-mail conversations with

  • Anonymous
    February 26, 2009
    Matt I am curious to know why when re-doing WF BPMN/BPEL standards compliance was not taken into consideration? Is there any plan to support persisting the workflows that are created in BPEL 2.0 or at least provide some capability to export the workflow to BPEL 2.0?

  • Anonymous
    March 26, 2009
    Hi Matt, Glad I found your blog as I am new to WF.  I am on a project where, unfortunately, we cannot wait for 4.0 (as much as I would like to after reading about all of the changes ahead).  I have a question about best practices for coding WFs now that will convert well to 4.0.  I read that dependency properties (either should not or will not?) be used in 4.0.  What should be used in 3.5 in it's place where dependency properties are needed?