Saturday, November 8, 2008

Microsoft rewrites Workflow Foundation from the scratch

In a keynote at the PDC 2008 conference the speaker Kenny Wolf announced that Microsoft is rewriting Windows Workflow Foundation from the scratch. The basic concepts will be retained but the implementation and all components will change fundamentally. It will be shipped with .Net 4.0 and will not be compatible with current Workflow Foundation Code.

One of my next articles in this blog would have been titled "Why I do not believe in Windows Workflow Foundation". I think I can skip this article now, as Microsoft obviously has come to the same conclusion.
First of all. If you want to do workflow driven development, the current Microsoft strategy is a mess in itself. Do I use Workflow Foundation, Workflow Foundation for Sharepoint, Biztalk or what? Currently we have 3 products offering more or less the same. But even even if you get behind the point of simply chosing Workflow Foundation things do not lighten up.
If you look closer at the word "Workflow" you will soon encounter some philosophic problems.
What is a workflow? Are we talking about program level workflow, about technical workflows or do we even talk about interactive workflows, are we talking about business processes, do I store my business object in the workflow object, when do I use sequential workflows or state machines....
Workflow Foundation fails to answer any of these questions and hence gives you no clear strategy what WF is aimed at. For me it felt like getting a tool box tossed at my head with a sticker on it saying "Find out what it's good for".
To the point where I used Workflow Foundation in technical workflow, things where working out but when I got to the point where I tried to implement an interactive workflow with just 4 states things were getting messy.
The whole communication concept with workflows is a mess, the Workflow controller is unbearable slow, the workflow designer shipped with Visual Studio 2008 was ***unusable*** before service pack 1. If you want to user persistence or tracking you end up rebuilding the database frequently, because errors come up that can not be solved differently.
The WCF-WF integration example published by Microsoft definitely belongs into the Hall of Shame. A calculator that needs a Start() and Stop() Method before/after it does calculate something. Jeeeez. Who dared publishing something like that? It clearly shows that both techniques where designed independently and were never designed to interact.

But with the new approach am looking forward to see what the result will be. I definitely believe that the future of development will be workflow driven. Software definitely needs to get to the point where my business process reflects in software. There and only there I benefit from workflow driven development.

"In einem Vortrag auf der PDC 2008 offenbarte Sprecher Kenny Wolf, dass Microsoft die Windows Workflow Foundation (WF) noch einmal von Grund auf neu schreiben wird. Die Konzepte einer Laufzeitumgebung, die aus einzelnen verbundenen Aktivitäten bestehende Workflows ausführt, bleiben zwar bestehen. Auch die Workflow-Dienste wie Persistierung und Ablaufverfolgung wird es weiterhin geben.
Die Implementierung und alle Bausteine (Laufzeitumgebung, Aktivitäten und Dienste) werden sich jedoch in der kommenden Version fundamental ändern. Die neue Ausgabe wird nicht mehr kompatibel sein zu den derzeit am Markt verfügbaren Versionen." (Heise)


Anonymous said...

Good article, spoilt by bad spelling. I don't know why it bugs me so - other than 'definately' seems to be becoming the norm. But it's 'definitely'.. :)

elLoco said...

Sorry for the incorrect spelling. The blogspot spellchecker is broken and I found no way to enable the Firefox spellchecker in my local version.

BlackWasp said...

I don't feel so bad for never getting around to learning it now!

elLoco said...

I found an interesting response to this article.

Below the comment I left on his article.

Hi, it’s me the guy with very little knowledge about WF. ;-)

Well, I can tell you what it means if I decide to rewrite something from the scratch ;-).
I don't agree. They are all 3 BPM solutions, but which for which scenario? It's like communication in .Net 2.0. Before .Net 3.0 we had web services, remoting, queues... All communciation technologies for different scenarios. Now we have just WCF what is pretty much straight forward.
MS should try the same thing for their BPM as well.
3.) Not sure. I tried some program level workflow with WF but imo this is definitly not what WF is aimed at.
4.) BusinessData is an integral part of a business process right? If you have have a paper based workflow, you will move the paper to the workers instead of keeping the paper in a central place and let every worker run for it, or?
For me it doesnt make any sense at all to use BPM and keep the business data elsewhere. It's because have to implement everything twice. First I code my businessprocess then I have code the logic that keeps my businessdata up to date. I can't just change my process, because I might need a different logic to update business data.
This would contradit the whole BPM approach.
5.) I would limit this further. If you have keep business data in your workflow, and your process waits for an external event, I think you should never use sequential workflows.
The problem? What if the event never occurs? Now your workflow will hang forever and you have absolutely no way to access the business data encapsulated in the workflow.
So for me it turned out, that you almost never you should use sequential workflows.
6.) I had frequently problems with SQL server based persistence. I worked for quite a while, but at a certain point in time it simply stopped working. The same for tracking. So if long running processes are in the focus of WF persistence should be rock solid. But it's not.
7.) For every bit of data you want to send to a workflow you have to create a class that derives from ExternalDataEventArgs and create an appropriate event. If you use Event for inbound communication why you do delegate based communication on the other way?
8.) You can't even arrange the connectors! As soon as you try to rearrange the second connector the first snaps back to its old position. :-(
9.) I frequently had the situation where I outperformed my workflow by clicking buttons too fast, although the activities were really doing nothing but to update a value in the encapsulated business data.
10.) No, I mean it. After an hour every ***click*** in my designer took 10 to 15 seconds. And in WF you do quite some clicking.
11.) And in production?
12.) No, it’s a calculator with integrated time bomb behaviour. No user of a web based calculator will press a "Stop" button. After 20 minutes the session expires and then most workflows will never be terminated. How much workflows the workflow controller can handle simultaneously? 100, 1000, 100000000? You will sure find out.

Other things that drove me nuts.
A.) There is absolutely no way by default to find out in what state a workflow is in.
B.) If the workflow waits for an event that is never going to occur, you have no way to get access to the encapsulated business data. You better hope it wasn't important.

No, I personally think that WF is nowhere near a production ready technology.

Good solutions need controversy!


Anonymous said...

Who knows where to download XRumer 5.0 Palladium?
Help, please. All recommend this program to effectively advertise on the Internet, this is the best program!