If attendees in Kenny W's session on WF 4.0 yesterday at PDC 08 are like me, they are both elated, shocked and awed in the lead architect's discussion on major, major changes heading our way in Windows Workflow 4.
When I attended the WCF and WF SDRs in Redmond back in April, Kenny, Ed Pinto and his team talked to us about new workflow types and activities and sought our feedback. It was evident that these improvements that were afoot were positive, and building on a foundation that I had only recently grown to love having been primarily focused on WCF for the last 2 years. In fact, I have pretty much shifted my focus completely from BizTalk Server to WF, WCF and service bus technologies.
Anyway, among the improvements/features discussed were changes to existing workflow types and new workflow styles including sequential, flowchart, state machine and a unification of activities and rules. Also reviewed were improvements to XAML support for modeling and deployment. So, I was very interested to see how far these committed improvements had gone since April, but I was not prepared for such a big surprise.
A framework for writing workflow applications, now in its second release (WF 3.5) is being completely overhauled, from the ground up. Kenny asserted that these drastic changes were necessary to deliver on the changes the team had already been discussing for months, but had expertly kept the details of just what that meant safe within the walls of building 43.
So what does this mean?! This is a question anyone working today with WF is asking. How drastic is the impact to my applications? What should I know about what's coming so that my existing and future investment in WF can be leveraged. Is this another ".NET Remoting has been deprecated" situation?
I couldn't wait for public messaging to address this burning concern, so I talked to Kenny after his session and asked a number of questions, which he was, as usual, very open and willing to answering.
My first question was around the impetus for such a major overhaul. Kenny shared that they focused very, very deeply on key customer requests and opportunities based on earlier versions of the framework. There were 3 feature types that resonated most. First, is delivering a truly model-based framework that allows every aspect of the WF to be represented declaratively. Second, was being able to truly participate in the repository ecosystem, which is key for deployment, management and operations scenarios. And last, but not least was performance.
Earlier in his talk, Kenny cited intriguing improvements, including 10x to 100x performance improvements and persisted workflows becoming essentially "free" with WF 4.0. In our more one-on-one discussion after his talk, he used the analogy of swinging at a baseball with a wooden baseball bat. While the wooden baseball bat is effective, it feels a bit heavy, if not clunky at times. When you pick up an aluminum baseball bat, it is markedly lighter, and feels significantly more aerodynamic. WF 3.0 and 3.5 work, but WF 4 is a new and improved aluminum baseball bat.
While the metaphor was effective, of course, I wanted to know what, specifically I should stop/start doing immediately and ensure my clients receive this guidance. Kenny had partially addressed this earlier in his public talk by pretty much prescribing that WF developers should stop using custom code activities and opt for custom activities instead. In fact, he demo'd a new "Interop" activity that allows your WF 3.0/3.5 custom activities to talk to WF 4.0 activities and workflows. I must admit that this does feel a bit like a P-Invoke for WF, and I don't mean that to be critical, it is just an observation.
Obviously, there are many more questions to be answered, but the first takeaway is to stop using custom code activities and focus existing efforts on developing custom activities, which are really the way we should be developing for WF anyway. To help answer some of the other burning questions we all undoubtedly have, Kenny committed to do his best to provide some prescriptive guidance by the end of the week to fill in the rest of the gaps, or at least provide some early guidance to get begin to prepare.
As soon as I get my hands on it, I will post it, along with any other gems of wisdom here.
On a final note, lest my prose present me as stoic, of course these changes make me nervous. I have yet to appreciate the full impact of these changes, and am eager to learn more. This said, I have to applaud Microsoft CSD for doing what is right, even when it is painful. We've seen this happen before (.NET Remoting) and will likely see it again. It is both the cost and benefit of forward progress in our great field of software engineering.