The Road to WF 4.0 (Part 1)

The topic of 4.0 migrations has come up several times over the past week – in e-mail conversations with a few authors and meetings with customers, on a couple articles (e.g., Kathleen Dollard; Aaron Skonnard), and a cross-blog conversation. As such, it seemed a good time to post a couple blog entries on the topic. There will be more specifics coming out on this topic in the near term, but I’ll touch on that at the end of this entry.

As any of the links above will tell you, we announced at PDC that Windows Workflow Foundation (WF) will introduce a new WF workflow model in the upcoming 4.0 release of the .NET Framework, while continuing to carry forward and support the WF 3.0 model. Initially, this was met with great surprise by many folks – on blog entries, on Twitter, and on many a Facebook status update. In the PDC lounge and in the halls at PDC, we had the opportunity to discuss this topic at length – and the direction was also met with understanding and excitement after developers heard why we did it, and what this meant for them going forward.

In this blog entry, I would like to pull from some of those PDC conversations and highlight a few of the reasons why we made this decision to implement a new WF model, and what this means for you as a WF developer. My assumption is that you are familiar with WF 3.x today, and are wondering what this new version means to you. My next entry (probably next week) will highlight the scenarios that open up with WF 4.0 – what becomes possible with WF that had been very difficult in the prior release. I then intend to dive into some of these topics a bit deeper, hopefully drawing out a couple WF program managers to weigh in.

Why was this done?

First, some quick context to set the stage - WF was first released as part of the .NET Framework 3.0. It was released as a set of next-generation .NET namespaces (along with Windows Communication Foundation (WCF) and Windows Presentation Foundation (WPF)) that enabled Windows Vista, Office 2007, and a range of customer solutions to do some amazing things. WF capabilities were extended in 3.5 to enable a more natural integration with WCF and to allow workflows to be service-oriented in a much more natural fashion. The goal of 3.0 was to create a single foundational technology that Microsoft products could build upon, and to ship this technology in the .NET Framework so that ISVs and customers could build upon it as well. This would provide customers with a unifying technology that would allow them to encapsulate and express business logic. And, in this, I think WF 3.0 was tremendously successful – today customers can build activities, and host them in custom WF workflow code, or in SharePoint or Dynamics or Office Communications Server or a variety of third-party ISV applications. And this next year will see even more products betting on the WF platform.

As we were designing WF 4.0, we wanted to address the feedback and pain points that we have gathered over the past few years from the community (via the Connect site, the forum, and discussions at with you at our events and deep dives) and implemented the following improvements:

1. Explicit Activities Data Model: We are providing an explicit, system provided data model for WF 4.0 activities. The activity data model lets you reason about and manipulate workflow data using variables (for storage) and arguments to manage how data flows into and out of activities (for those interested, Matt Winkler did a great PDC session discussing activities in WF 4.0).
2. Fully declarative authoring model: WF 4.0 provides XAML-based workflow capability to provide you with flexibility across deployment, versioning, and tooling - allowing your workflows to express what your business process or application is doing, and allowing your custom activities to handle how the work is actually accomplished.
   In 4.0, workflows can now be written and executed using no-code (for those interested, there was a great PDC session by Kenny Wolf demonstrating this), and this also improves the ability for tooling to read and write WF workflows.
3. Increased performance: Performance was a strong thread in the feedback we received. In the new 4.0 model, we focused on greatly simplifying system demands by the architecture during workflow creation, serialization, and runtime. Performance was increased by factors of 10-100 over our WF 3.0 performance numbers.
4. Deep WCF integration: The next release also provides a rich out of the box hosting environment for WCF workflow services. As we released 3.0, customer feedback highlighted the natural partnership between WCF and WF. The new architecture focuses on making it easier for you to model complex communication patterns in a fully-declarative fashion, providing sophisticated message correlation, the ability to flow transactions, and improved exception handling.

As we expanded WF, it became clear that the WF 3.x architecture just wasn’t created with the above in mind. And while we could incrementally build on top of the existing platform, it would provide a less than optimal experience for developers, and might feel more like death by a thousand cuts. And, given a strong view by the average developer that the technology was already overly complicated, we made the hard choice to rewrite the WF framework and take advantage of what the other WinFX technologies provided.

What does this mean to you?

So that gives you an idea of why we went and ripped up the garden, so to speak. You’re now asking – so do I have to rewrite my applications? The answer is it depends on whether you’re content with what you have now, or if you want to take advantage of the new WF 4.0 capabilities.

If you’re happy with your WF 3.0 workflows today, you do NOT have to rewrite your WF code, they will absolutely continue to work – even if you want to use Visual Studio 2010 and other features of .NET 4.0. We are shipping the 3.x designers and namespaces with .NET 4.0; you can continue to support and develop 3.5 workflows in Visual Studio 2010.

If you want to take advantage of the WF 4.0 capabilities, you can start to move your activities and workflows over as you feel comfortable. We’re including WF 3.x -> WF 4.0 interop capabilities (via a WF Interop activity) with .NET 4.0, which allow your 4.0 workflows to call back to 3.5 workflows and activities. In anticipation of your follow-up question, the Interop activity can only embed 3.x activities in 4.0 workflows; you cannot embed 4.0 activities in 3.x workflows.

So, all of that being said, 3.x WF developers have three options with .NET 4.0:

• Side by side operation: As I mentioned above, we will be including the namespaces and designers for both WF 3.x and WF 4.0. The team is going through great pains to make sure that WF 3.x developers and customers are not stuck. WF 4.0 uses a different namespace, different [WPF-based] designer, and different persistence schema.
  Doing this delivers on a Framework-wide promise of running prior versions. 3.x workflows can continue to be used, maintained, and supported as long as they need to be. And if your need for 3.x support is defined as ‘we will stay on 3.x and use other aspects of .NET 4.0’, well, that’s an option to…but we really think you’ll like what you see in WF 4.0.
• Interop activity: Current WF customers have created a lot of activity and workflow artifacts. With WF 4.0, we will ship an Interop activity; the purpose of the Interop activity is to enable seamless execution of a 3.x activity/workflow within a 4.0 workflow. As we dive into the design improvements in WF 4.0, it will become clear why you can’t just drop 3.x activities onto a 4.0 workflow, but that’s a much longer discussion for another time.
• Updating your 3.x code: As you would expect, the third option is that of updating your code to take advantage of all that WF 4.0 has to offer. We will be publishing the initial guidance on this with the release of .NET 4.0 Beta 1. Depending on how you wrote your code and markup today, this could be an easy migration or a difficult one.

To help you with getting your head around this, we are putting a large effort around developing resources for migrating mindsets, skill-sets, and code/markup – authored by those close to the code, MVPs, and early-adopting customers that have been working with WF 4.0 and actually working with their WF 3.x code. This information will start being released along with Beta 1 and continue through and beyond RTM of .NET 4.0. Additionally, folks in the community are writing articles on the topic; for example, Kathleen Dollard did a short write-up on writing WF code today with 4.0 in mind in this month’s Visual Studio Magazine; we can’t highlight her #1 suggestion enough – use custom activities instead of using Code activities (and the code-beside they lead to) in your workflows today.

Perhaps the best assurance I can give you here is that we’ve been working with customers in our early-adopter Technology Adoption Program (TAP) and a variety of externals around our 3.x -> 4.0 options and process. And, while I can’t promise it will be painless, I’m hoping you will be pleasantly surprised with our Beta 1 release.

And, for those who adopted WF as part of the .NET Frameworks 3.0 and 3.5; I want to give you a heart-felt thank you! We are taking great pains to ensure that your current investments in WF (both time and code) will continue to add value in 4.0 and beyond. Even within Microsoft, there are at a few large products (internal customers) will launch over the next couple years on WF 3.5 today as they evaluate and work to adopt 4.0 in a future release – so you better believe that the namespace and designer will continue to be supported and serviced.

We really hope that you’ll take a look at WF 4.0 for yourself and see that we have heard your pains loud and clear; as mentioned above, most of the improvements made can be directly mapped back to customer feedback. I’ve been on a couple teams here at Microsoft, and I am personally amazed at how the CFX team handles the customer feedback they receive – going directly into the team’s bug/enhancement tracking system to be grouped and worked. While this may not be the exact way that you envisioned WF evolving, please withhold your ire until you kick the tires with the betas and/or final release.

Note: Thanks to the Kenny Wolf and Bob Schmidt for their invaluable feedback and help on this entry.

Comments

• Anonymous
  January 21, 2009
  Agile/ALT.NET Scott Ambler on Criteria for a Disciplined Agile Team Scott Bellware - Good Design is Easily Learned Mike Cohn on Establishing a Common Baseline for Story Points Hanselminutes Podcast 146 - Test Driven Development is Design - The Last Word

• Anonymous
  January 21, 2009
  Interesting post, we're waiting more news about the future WF platform. Any news about designer rehosting? We've a big customer need: having the possibility to author the WF design in a simple and intuitive manner. Actually, we have applications that makes use of WF for some business process. The WF are modeled in a certain way and customers asks to have a tool (or something similar) for editing the WF structure in order to suite their business needs. Are there plans about this?

• Anonymous
  January 21, 2009
  Thanks Stefano; Have you taken a look at Matt Winkler's PDC session? If not, I would definitely recommend checking it out (http://channel9.msdn.com/pdc2008/TL21/), and tune into the 63 minute mark. The short answer is that the WF team has made it much easier to rehost the designer. Using XAML for WF 4.0 has made it possible to rehost the designer on a WPF form using about three lines of code. This makes is possible to construct your custom designer in Expression; which looks pretty snazzy compared to the rehosted designers of 3.x. Hope this helps, Cliff

• Anonymous
  January 22, 2009
  Thank you for submitting this cool story - Trackback from DotNetShoutout

• Anonymous
  January 28, 2009
  こんにちは。 Tech Days へのご参加、ありがとうございました。 私が担当した WF/WCF/ワークフローサービス 4.0 のセッションについて、セッション後、互換性や移行に関して参加者の方よりご質問を頂きましたので、補足させていただきます。

• Anonymous
  January 29, 2009
  Just some links that I caught up with today that struck me as interesting. Ribbon UI in Silverlight Tim’s

• Anonymous
  June 11, 2009
  By now you must be aware of the significantly enhanced Windows Workflow Foundation (WF) scheduled to