Windows Workflow 4 – A New Product with an Old Name

Posted by Jonathan Allen on Jan 21, 2010

Sections

Development

Topics

.NET ,

.NET Framework

Tags

.NET Framework 4.0 ,

Windows Workflow Foundation

Windows Workflow 4 is a major rewrite of the library. While it has the same goal, to provide a modeling language for long-running tasks, there are some significant differences coming out of what is essentially a complete rewrite.

First a note on backwards compatibility. There is none. You can use the Interopt activity to call a WF3 workflow from WF4, but there are significant restrictions. For example you cannot use WF3 Send and Receive activities, nor can you suspend the workflow or invoke other workflows.

Rewriting a WF3 workflow in WF4 can be a daunting task. WF4 uses pure XAML to define workflows, which makes them much easier to programmatically generate but also means you lose the ability to leverage Code activities. State Machine workflows are not supported in WF4, so anything based on them will have to be redesigned. The way it handles errors is also significantly different, hence the reason the Suspend and Terminate activities are gone. Many of the other activites also changed name and/or semantics. Matt Milner’s change list from July seems to the most up to date.

If you are new to Windows Workflow and don’t have anything invested in the legacy version you are in for a treat. WF4 claims to greatly simplify hosting workflows, managing data, and creating custom activities. Gone is the requirement to use dependency properties to flow data between activities.

A key selling point for Windows Workflow 4 is its integration with Windows Communication Foundation and Windows AppFabric. Microsoft envisions developers building message passing applications in a “WCF on the outside, WF on the inside” style with Windows Server AppFabric providing the hosting.

1. Back to top

   Never understood the value in WW...

   by Giorgio Galante

   Let's be honest, business users will not be writing their own workflows anytime soon with WW. So what do the consumers (developers) gain from the added complexity, learning curve, etc of using WW rather than just implementing 'workflow' in code? Very little IMO, and a slow runtime to boot (at least in WW3.)
   
   Given the above opinion, an extremely large & complicated application would be the only situation where one should consider using WW. Microsoft's decision to 'reboot' WW and throw out backwards compatibility without much consideration makes it a poor choice from a long term viability perspective. Why tie yourself to a technology that will likely be tossed out in 2 years?
   
   Anyone considering a workflow engine/tool for .NET applications should consider alternative 3rd party solutions first.

   Reply

2. Back to top

   Re: Never understood the value in WW...

   by Rafael Costa

   Apparently Microsoft is now putting a lot of efforts in WF4, hence the reason for not showing much respect for the legacy - after all, there were not many people using WF3 anyway.
   
   As for the added complexity vs implementing solutions in code, I can agree that WF is not the most appealing idea for most developers. However, it can provide with a flexibility for quick changing scenarios not requiring a lot of code being rewritten, since that with WF it is mostly a matter of dragging boxes around.
   
   I've been working with WF3 for some pretty hardcore stuff for about a year, and I can say that focus on business people designing solutions is really what it is meant for. I haven't had the chance to play around WF4 in depth yet, but looks like a good job was done this time.

   Reply

3. Back to top

   Re: Never understood the value in WW...

   by Stef Sewell

   As an ISV who has worked deeply with both WF3 and WF4 I hope I give a more positive view of Microsofts workflow technology.
   
   First off, business users are writing their own workflows today using WF3. We have a workflow product that leverages WF3 deeply to provide a business process designer and execution environment. There are a number of gaps in WF3 that we have had to fill to provide an enterprise workflow product but the WF3 runtime is very much at the heart of our product.
   
   There is no question that WF4 is a ground up re-write of workflow. .NET 4 includes the WF3 workflow implementation in the System.Workflow namespace and all of the new WF4 types are in the System.Activities namespace. This means that investment in WF3 is not thrown away, it will still run on the CLR4. There are limitations integrating WF3 and WF4 processes and migration is a difficult problem. Microsoft is well aware of the situation and is providing as much guidance as it can to try to help migrate WF3 to WF4. Just google 'Microsoft WF4 Migration Guidance'
   
   If you looked at WF3 and thought it was too complex or missing features, please take a look at WF4. The programming model is simpler, the flowchart paradigm is much more easily understood by business users, the workflow definition now includes state as a first class concept, the workflow services feature of WF4 + WCF4 is a very compelling approach to write services.
   
   While WF4 can be used to write long running, durable business processes, it can also be used to implement much shorter, in-memory workflows too. If you have a piece of business logic that requires co-ordination of service calls or async operations, workflow is a good option. You can call a workflow directly in .NET code via the WorkflowInvoker class, which also gives you a way to unit test workflows.
   
   The team at Microsoft have spent alot of time looking at the performance of the runtime and believe they have achieved a 10x to 100x improvement in common use cases. Our experience of the WF4 runtime is that it is indeed faster.
   
   I've been working with WF4 for 9 months now and I'm finding it a very compelling technology. It gives you an extensible, declarative programming model with a fully customizable designer. It's easy to write a DSL to capture your business processes and then transform this into an executable workflow. Workflow Services make WCF service authoring a breeze. When combined with AppFabric, it gives an out-of-the-box service hosting story for durable, long running processes that can be load balanced.
   
   WF3 and WF4 are very different beasts, Microsoft has invested very heavily in WF4 - evidence of this is the AppFabric Workflow Services which leverages IIS/WAS as a hosting environment.
   
   Just my two cents.

   Reply

• Older >