Zehn gute Gründe, warum Windows Workflow Foundation dem Entwickler keinen Spaß macht

Windows Workflow Foundation (WF) ist eine .NET-basierte Klassenbibliothek (eingeführt mit .NET 3.0) zur Erstellung computergestützter Workflows. WF ist weder ein Workflow-Server noch ein Workflow-Client, sondern "nur" eine Klassenbibliothek, die bei der Erstellung einer Workflow-Anwendung hilft. WF hat von Haus aus keine Verwaltungswerkzeuge, Berichte und Überwachungswerkzeuge.

In mehreren Projekten haben wir bzw. unsere Kunden den Einsatz der Workflow Foundation in Erwägung gezogen und sind dabei in mehreren Fällen zu dem Entschluss gekommen, dass WF sich nicht für den jeweiligen Anwendungsfall eignet.

Aber da man ja immer zuerst das Positive nennen soll, hier also eine Liste der fünf Punkte, die aus meiner Sicht WF auszeichnet:

1. Kapselung und Wiederverwendung: Vorgänge werden in wiederverwendbaren Aktivitäten gekapselt. Jeder Entwickler kann auf einfache Weise eigene Aktivitäten definieren.
2. Grafische Modellierung: Die Aktivitäten können mit einem grafischen Werkzeug (Workflow-Designer) angeordnet und verbunden werden. Der Workflow-Designer steht in Visual Studio 2005/2008 zur Verfügung und kann auch in eigene Anwendungen lizenzkostenfrei integriert werden.
3. Persistenz: WF bietet eine Persistierung für Workflows, bei der der ganze Zustand des Workflows in einer Datenbank gespeichert wird. Persistenz kann eingesetzt werden als Wiederherstellungspunkt bei Abstürzen und für langlebige Workflows, die während des Wartens auf Ereignisse keine Ressourcen (RAM/Rechenzeit) verbrauchen sollen. Solche Workflows werden bei Bedarf von der WF-Laufzeitumgebung automatisch reaktiviert.
4. Ablaufverfolgung (Tracking): Die WF-Laufzeitumgebung kann jeden Schritt oder ausgewählte Schritte in einem Workflow in einer Datenbank speichern.
5. Regelkonzept: Durch Regeln, die voneinander abhängig sein können, ist die Modellierung komplexer Bedingungen möglich.

Leider sehe ich inzwischen doppelt so viele Punkte, warum Entwickler keinen Spaß an WF haben:

1. Systemvoraussetzungen: WF ist - ebenso wie .NET 3.0 insgesamt - nicht für Betriebssysteme vor Windows XP verfügbar (also derzeit nur für Windows XP, 2003, Vista und 2008). Als Datenbank unterstützt Microsoft nur den eigenen SQL Server. Provider für andere Datenbankmanagementsysteme sind möglich, aber bisher nicht verfügbar.
2. Wenige Aktivitäten: Mit WF liefert Microsoft nur vergleichsweise einfache Basisaktivitäten (wie Bedingungen, Schleifen, Aufrufe, Ereignisbehandlung). Höherwertige Aktivitäten (z.B. HTTP-Download, FTP, E-Mail oder gar geschäftsnahe Aktivitäten) fehlen bzw. sind nur in WF-unterstützenden Produkten wie SharePoint 2007 und BizTalk 2006 R2 verfügbar.
3. Schlechte Versionierung von Workflows: Man kann eine Workflow-Definition jederzeit ändern, jedoch kann man bestehende Workflows nicht mit der neuen Definition weiterlaufen lassen, sondern nur mit der alten. Wenn Sie bei einem Prozess plötzlich am Ende noch einen Schritt brauchen, können Sie diesen also nicht bei Workflows anwenden, die bereits gestartet sind (auch wenn diese langlebig sind).
4. Keine Kompatibilität zu SSIS-Workflows: Microsoft SQL Server Integration Services (SSIS) bietet eine ähnliche Umgebung wie WF, ist jedoch in keinster Weise kompatibel zu WF. Das Entwicklungsteam von SSIS hat sich aktiv gegen die Verwendung von WF als Basis ausgesprochen (einerseits war SSIS vor WF auf dem Markt, andererseits ist SSIS mehr auf Massendatenverarbeitung fokussiert, dafür wäre WF zu langsam).
5. Hoher Implementierungsaufwand: Einige alltägliche Konstrukte in WF (Dependency Properties, Data Exchange Services) erfordern relativ viel Programmcode.
6. Mängel im Designer: Der Workflow-Designer ist sehr gewöhnungsbedürftig, weil er von den anderen Designern abweichende Bedienungsparadigmen hat. Die Integration des Designers in Visual Studio ist unzureichend (z.B. beim Umbenennen eines Workflows). Der Designer stützt bei komplexeren Workflows relativ häufig ab (siehe dazu "Bugparade" unten).
7. Komplexität: Interne Verarbeitungsschritte der WF-Laufzeitumgebung  sind oft schwer nachvollziehbar. Sicherlich muss man WF als eine Abstraktion akzeptieren, aber einige Vorgänge innerhalb von WF entziehen sich doch sehr dem intuitiven Verständnis eines Entwicklers.
8. Bei großen Workflows wird der Code schnell unübersichtlich: Visual Studio trennt zwar die Deklaration der Aktivitäten vom Programmcode, bei größeren Workflows wird die Codedatei aber dennoch sehr groß und unübersichtlich. Hier ist man gezwungen, in Aktivitäten zu kapseln, auch wenn man das nicht möchte.
9. Schlechte Dokumentation: Die Dokumentation ist eher knapp gehalten (z.B. zum Thema WF in ASP.NET nur sechs Seiten!). Es gibt bisher wenig Fachbücher zu WF.
10. Hohe Leistungseinbußen: WF schluckt sehr viel Leistung. Microsoft  selbst dokumentiert dies in dem Dokument "Performance Characteristics of Windows Workflow Foundation". Einige der Ergebnisse rufen jedoch blankes Entsetzen hervor, z.B:
     

    Test	Average Number of Workflows Completed per Second
    While activity with 1000 iterations	2.4
    Code activity of while loop with 1000 iterations	6449

Dieser Ausschnitt aus dem o.g. Dokument besagt: Das klassische Modellieren einer "klassischen" Schleife mit 1000 Durchläufen mit dem C#-/VB-Sprachschlüsselwort while ist 2687 mal schneller als die Verwendung einer Schleife (WhileActivity) in Window Workflow Foundation (WF). Dass die Abstraktion von WF einen gewissen Overhead bedeutet, ist einleuchtend. Aber bei diesem Overhead sollte sich jeder Entwickler genau überlegen, ob er nicht lieber ein "normales" Programm statt einem WF-basierten Workflow schreibt.

[/einrueckung]

Fazit:

Durch Modellierung, Persistenz und Ablaufverfolgung stellt WF eine Reihe von Funktionen bereit, deren eigene Entwicklung viel kosten würden. Man muss sicher aber sehr bewusst sein, dass WF selbst Zeit kostet, sowohl Arbeitszeit des Entwicklers als auch Rechenzeit zur Laufzeit der Anwendung. Außerdem gibt es zahlreiche technische Einschränkungen, insbesondere in Hinblick auf die Plattformen und die Versionierung. Gerade in Unternehmen, wo (laufende) Prozesse schnell angepasst werden müssen, ist WF ungeeignet, weil sich diese Anpassung immer nur auf neu zu startende Workflows auswirken kann. Um Missverständnissen vorzubeugen: Ich halte die Windows Workflow Foundation nicht für grundsätzlich ungeeignet. Vor dem Einsatz sollte man sich aber der oben genannten Einschränkungen bewusst sein und das Produkt im Detail für den eigenen Anwendungsfall sehr genau prüfen, bevor man hier investiert.

P.S. Zum Abschluss noch die oben angekündigte "Bugparade" des Workflow Designers

()