I can’t believe it’s been a few months since my post on the Road to WF 4, and the expected impact of the new workflow model. It’s been a busy few months as the team develops and builds toward .NET 4; as we hosted an MVP Summit here in Redmond; and worked with TAP customers around using WF 4; and a few small scale shuffling around of job roles (one reason why you may not have seen much from me around updates on Channel9 and MSDN). And then, of course, there’s getting ready for TechEd in a couple weeks – we have some excellent presentations in store for Los Angeles, but I’ll circle back to that at the end of this article. All of that being said, I don’t believe you’re here for my digressions
The team has been busy coding away since our conversations at the PDC in October. Soon, we will be releasing a public build of Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF), which will be made available with the beta 1 build of .NET 4 and Visual Studio 2010 <and before you ask: I don’t know when the beta will be posted>. Starting with this release, the WCF and WF builds will be part of the all-up VS2010 public drops, and the new System.Xaml.dll is provided within the box, as opposed to out.
At the highest level, the beta includes a great number of enhancements: additional features have been added; the designer looks and performs better; and the codebase is much more stable. What I’d like to do is take a rather quick walk along the workflow-specific features new to the beta and point out some of the highlights, which we will explore in greater detail as we come upon the beta 1 release. To be clear, this particular entry is geared to the .NET developer that had attended the PDC or had the opportunity to evaluate the WCF/WF/’Dublin’ VPC that was distributed at the PDC and watch the recorded PDC sessions. My next blog entry will talk to the WF 3.x developer, and introduce the new workflow model being released as WF 4.
To begin on the CTP -> Beta 1 delta discussion, let’s start with the building blocks of workflows – activities – and wind our way into the core.
The activity team has made several improvements that will immediately pop to anyone who worked with the CTP bits provided at the PDC: more out-of-the-box (OOTB) activities, clean up of the activities you saw in the CTP, API improvements in the activity object model that make it easy to write custom activities, and support for VB expressions end to end.
Base Activity Library
Out-of-the-box, the new workflow designer in beta 1 will ship with a larger set of OOTB activities than was available in the CTP’s designer palette. These new activities include the following:
- Parallel: The parallel activity, which allows you to interleave the execution of activities along multiple paths, makes a triumphant return with a WF 4 designer. As an aside to those who used the parallel activity in WF 3, it’s important to note that the activity scheduling/queuing behavior changed in WF 4. We’ll get a much more detailed follow-up post on this topic next when Beta 1 comes out.
- ParallelForEach: The beauty of the OOTB activities is they do about what you would expect. In Beta 1, this new activity allows you to perform a parallel series of operations upon an object collection. Unlike the Replicator activity in .NET 3, the ParallelForEach activity (and ForEach activity) allows you to model this behavior in a fully declarative fashion.
- Pick: The pick activity can perhaps be best thought of an equivalent to the listen activity from the current WF model or similar to a BPEL pick. The activity has a series of branches, with a defined trigger/event and execution steps. We expect that the combination of Pick with the WF 4 flowchart model’s capability to define free form activity transitions to become a popular design pattern.
- Collection Manipulation Activities: The Beta 1 release adds four activities (ClearCollection, AddToCollection, RemoveFromCollection, and ExistsInCollection) that allow you to manipulate object collections.
- Service Activities: This will be discussed in a ’What’s new in WCF Beta 1’ blog post that I will try to get out after TechEd, but it’s important to note that we’ve greatly improved the WCF activities in the beta.
In addition to the new activities highlighted above, the beta simplifies the visual presentation of other activities to take up less real estate on the designer. Feedback we received from folks who saw and used the PDC bits was that they didn’t want too much information on the activity shape, so more information for the OOTB activities has been moved back to the property grid to make the workflow designer surface more readable without having to use the resizer.
On the topic around what’s not in the box, there are a number of activities that had been discussed at the PDC that you won’t find in the VS2010 beta 1 download, these include generic activities to interact with resources such as a database, with the file system, and with SharePoint. While it’s pretty clear that these won’t make it into the Framework 4 release, we are trying to find other ways to release them. For example, the beta 1 SDK includes a policy activity to interact with WF 3 rules sets. For those that don’t show up in the SDK, we are evaluating an option of making the activities available as a separate downloade post-Beta 1, but the location and timing of that is still being determined.
Two other major WF 4 activities that were discussed at PDC, a new state machine activity and a new forward chaining ruleset activity, will not be available with the VS2010 beta 1 release – and we will cover each of these topics in greater depth in the next month. At this point, a new forward chaining rules engine won’t be ready for the .NET 4 timeframe, and will probably see a CTP release post-VS2010 to gather feedback and to allow customers the opportunity to evaluate the direction we are considering. It’s important to note that we are working to ensure integration with the WF 3 rules engine will be possible in a number of ways, though; one example of integration back to the WF 3 rules engine is the SDK sample activity I mentioned above, For the state machine, we are unable to include a new state machine activity in WF 4, but our work with TAP customers leads us to expect that using a combination of the new FlowChart + Pick activities should satisfy a large majority of the current scenarios that folks are currently using the state machine activity for (again, we can and will dive into this as a follow-up post), and we look forward to getting customer feedback on the capabilities and limitations of using FlowChart + Pick once the beta is released.
Activity Authoring Experience
The object model has changed between the PDC CTP release and Beta 1. While the core concepts have essentially remained the same, the class names have shifted a bit, and a couple new classes have been added into the mix. For most WF developers, there are really four activity classes that you will work with. Moving from the class with the fewest knobs to turn to the class that gives you full control, the activity classes are as follows:
- Activity: Used when creating a composite activity – an activity who’s execution is entirely expressed as a composition of other activities. Activities that you create from the Activity type can be designed in a declarative fashion (using XAML) and don’t allow for any imperative code. From a conceptual perspective, when authoring a “workflow” (in this case, defined as connecting a series of activities together), you are essentially authoring a derived “Activity” class.
- CodeActivity: Used when creating an activity that implements a custom Execute method, and is designed for short-running chunks of work.
- NativeActivity: Used when creating an activity that has full access to the core of the WF runtime features such scheduling child activities and manipulating bookmarks. This is intended as the type of last resort, and we don’t expect many folks to inherit from this type.
- WorkflowElement: This is the abstract base type that all activities derive from.
The inheritance model among these four classes is presented below. In addition to the above, the beta release adds the generic WorkflowElement<T> class, which is useful for building expression activities (as an example of where this is used – the collection activities, mentioned above, inherit from the CodeActivity<T> class), and this is a topic for another blog post.
For most tasks, you will find that much of the custom activities authoring experience is the same between the CTP and Beta 1 builds. As we’ve been building WF 4, we have been doing usability work with customers and early adopters of WF 4 to improve the custom activity authoring experience (e.g., Beta 1 sees improvements around how developers interact with the ActivityExecutionContext), and look forward to your feedback from Beta 1 to make further refinements as we continue to progress towards RTM.
Before I move on to the designer experience, one other activity class that deserves a quick mention is the DynamicActivity. DynamicActivity allows you to add arguments (both InArgs and OutArgs) around what is essentially loose XAML – and use that within your workflows without requiring the XAML to be compiled – allowing for assembly of activities into a higher-level abstraction without having to create/develop additional custom activities. This is also something that will be worth digging into a bit deeper in a much more technical blog post as we dive in deeper into WF 4 activity development.
Designer Experience for Activities and Workflows
As you sit down and start to work with the beta 1 bits to design activities and workflows, there are a few items that really jump out at you:
- IntelliSense and syntax-coloring: The expression editor within the property grid (and when editing argument and property values on the designer surface) within the Workflow designer experience now supports IntelliSense. As you type out your expressions (in VB), you get drop-downs and auto-complete capabilities as you type out your expressions to work with Strings and TimeSpans. This new expression editor can also be used in your own custom activities!
- Performance: As you would expect between a CTP (alpha build) and a beta 1 release, the experience with the designer is much more stable and much more performant.
- Variable and argument designer: The visual presentation of the variable and argument boxes has changed slightly. Responding to feedback from the CTP designer, the team improved the boxes to make it easier for users to know the scope level of available variables.
- Improved bread crumb trail: Based on feedback on the PDC CTP, as well as feedback from usability studies performed by the team, the breadcrumb trail should now be more intuitive.
The improvements should make the experience much more pleasurable and approachable than that available in the CTP.
Unified XAML Stack
This was a point that received a lot of discussion at PDC. With everything being in one Visual Studio and .NET build, this is now being delivered out of the box!
Tracking and Tracing Improvements
Tracking and tracing in WF 4 has changed quite a bit to improve performance and flexibility. In .NET 4, WCF and WF use much of the same tracking and tracing models, which provide consistency for .NET developers using both technologies, and makes it much easier to develop and host workflow services. WF 4 introduces the capability for WF developers to do use Event Tracing for Windows (ETW). This is an improvement that comes from the unification of the WCF and WF tracking, and is designed to provide more control to the folks managing a WF host at runtime while minimizing the performance overhead when tracking is enabled. This should provide tracking and tracing capabilities that developers and IT Pros can have more control over – specifying what to track, when to track it, and the level of verbosity to track. The beta builds upon the functionality released in the CTP, adding refinement and enhancements to tracking in WF:
- Improved ETW Integration: Beta 1 provides .NET developers with the capability to In WF 4, this adds the ETWTracking Participant to write tracking records to an ETW session. With the addition of this feature, the corresponding SQLTracking participant has been removed from WF 4 in Beta 1
- End to End (E2E) Tracing With WCF: Beta 1 adds support to ensure that traces are emitted to tie together a request from a WCF service to a WF instance, allowing for a unified debugging experience for workflow services.
- Tracking Profile Config Elements: The tracking profile in the .config file now uses the configuration elements instead of XAML.
- OptOut Model: In the PDC bits, developers had to explicitely mark variables and arguments for tracking (opt in model). Based on customer feedback, this has been changed to track all variables/arguments in a workflow unless the workflow or activity developer specifically suppresses tracking for a variable or argument.
- Tracking Filtering: In WF 3, logging was an all-or-nothing event, the new functionality; with WF 4, more control is provided to extend and configure the runtime logging environment.
Work continues as we complete the designer and tighten down performance, but we feel that the code is in a state where customers can begin to seriously prototype their solutions on the new WF model and evaluate if it meets their needs. To help you do that, another big effort with this beta milestone is around helping you understand what the new WF model is, and how you can use it to workflow-enable your applications and services.
Supporting Material – Information You Can Use
Lastly, the team has put in a lot of effort around adding quality documentation and samples. With the CTP bits, the PDC session recordings and the hands on labs were perhaps the best place developers could go while experimenting with the bits. With beta 1, developers evaluating the beta release have a much better experience:
- When you press F1, online help is available to let you know what can be done
- The beta 1 SDK adds 63 new code samples (bringing us up to 88 SDK code samples), which do an excellent job of demonstrating how to accomplish more atomic tasks
- The hands on labs are being updated to beta 1, and they will be incorporating feedback received from those who ran the PDC labs
In addition to the above, we will be releasing a few additional items via the blog and the WF 4 Dev Center: David Chappell is writing a new whitepaper that introduces folks to The Workflow Way in .NET 4, the WF team is working on WF 3.x to WF 4 migration guidance documents that will help WF 3 developers understand the impact and options available with WF 4, and we will start doing blog posts and webcasts in the next month to aide developers in evaluating WF 4 – with some aimed at existing WF developers (discussing how existing WF developers should think about the new WF model) and others assuming no prior WF experience (simply introducing the new concepts and features).
And, at TechEd, there is opportunity for folks to discuss what’s coming:
- There will be some folks from the WCF and WF team showing off WF 4 and VS2010 at the booth – I will be among the motley crew working the station, and would love to catch up
- Aaron Skonnard will be doing a session on WCF and WF in .NET 4
- Michele Leroux Bustamante and Zoiner Tejada will be doing a precon on WCF and WF 4, and the new ’Dublin’technology extensions for Windows Server – enhancements that remove the need for WCF and WF developers from having to building a custom host (how cool is that?)
- Zoiner Tejada will also be doing an interactive theatre session on his company’s experience as a WF 4 TAP customer – and the migration from WF 3.5 to WF 4 using the ’Dublin’ extensions.
Wow! Deep Breath
I really hope that this is useful for you as you start to think about Visual Studio 2010 and .NET 4. I’m in the process of writing a complementary post around the WCF changes between the CTP and beta 1, which I hope to have up and posted by mid-week (May 6th-ish). I’ll then be taking a break from the writing while at TechEd (if you’re at the event, feel free to visit the booth and say hi), and then dive back into the word processor to pull together a ’WF 4 for the .NET 3.5 developer’ to highlight changes since .NET 3.x.
There’s a problem with doing these really long posts – they’re hard to work into the work week. 🙂
Note: Thanks to Jurgen Willis, Kavita Kamani, Vikram Desai, and Bob Schmidt for their invaluable feedback and help on this entry.