Workflowweise: Grundlegendes zu Windows Workflow Foundation

David Chappell
Chappell & Associates

April 2009

Diesen Artikel herunterladen

• Word-Format-
• PDF-

Einführung in Windows Workflow Foundation

Jeder, der Code schreibt, möchte großartige Software erstellen. Wenn es sich bei dieser Software um eine Serveranwendung handelt, ist ein Teil der großen Skalierung gut, wobei große Lasten verarbeitet werden, ohne zu viele Ressourcen zu verbrauchen. Eine großartige Anwendung sollte auch so einfach wie möglich zu verstehen sein, sowohl für seine Schöpfer als auch für die Menschen, die es pflegen.

Das Erreichen beider Ziele ist nicht einfach. Ansätze, die Anwendungen dabei helfen, sie zu zerbrechen, unterteilen ihre Logik in separate Abschnitte, die schwer zu verstehen sind. Das Schreiben einheitlicher Logik, die sich in einer einzigen ausführbaren Datei befindet, kann die Skalierung der Anwendung jedoch unmöglich machen. Was erforderlich ist, ist eine Möglichkeit, die Logik der Anwendung einheitlich zu halten, wodurch sie verständlicher wird und gleichzeitig die Anwendungsskala skaliert werden kann.

Dies ist ein Hauptziel von Windows Workflow Foundation (WF). Durch die Unterstützung von Logik, die mithilfe von Workflows erstellt wurde, bietet WF eine Grundlage für die Erstellung einheitlicher und skalierbarer Anwendungen. Darüber hinaus kann WF auch andere Entwicklungsprobleme vereinfachen, z. B. die Koordination paralleler Arbeit, das Nachverfolgen der Ausführung eines Programms und vieles mehr.

WF wurde erstmals mit .NET Framework 3.0 im Jahr 2006 veröffentlicht und dann in .NET Framework 3.5 aktualisiert. Diese ersten beiden Versionen waren nützlich, insbesondere für unabhängige Softwareanbieter (ISVs), aber sie wurden nicht mainstream-Technologien für Unternehmensentwickler. Mit der Wf-Version, die Teil von .NET Framework 4 ist, zielen die Ersteller darauf ab, dies zu ändern. Ein wichtiges Ziel dieser neuesten Version ist es, WF zu einem Standardteil des Programmier-Toolkits für alle .NET-Entwickler zu machen.

Wie jede Technologie erfordert das Anwenden von WF, was es ist, warum es nützlich ist und wann es sinnvoll ist, es zu verwenden. Das Ziel dieser Übersicht ist es, diese Dinge klar zu machen. Sie werden nicht lernen, wie WF-Anwendungen geschrieben werden, aber Sie erhalten einen Blick darauf, was WF bietet, warum es so ist, und wie es das Leben eines Entwicklers verbessern kann. Mit anderen Worten, Sie beginnen, die Workflowweise zu verstehen.

Die Herausforderung: Schreiben einheitlicher, skalierbarer Anwendungslogik

Eine einfache Möglichkeit zum Schreiben eines Programms besteht darin, eine einheitliche Anwendung zu erstellen, die in einem einzelnen Prozess auf einem einzelnen Computer ausgeführt wird. Abbildung 1 veranschaulicht diese Idee.

Abbildung 1: Anwendungslogik kann als einheitliches Ganzes erstellt und dann auf einem bestimmten Thread in einem Prozess ausgeführt werden, der auf einem einzelnen Computer ausgeführt wird.

Der einfache Pseudocode in diesem Beispiel zeigt die Arten von Aktionen, die Anwendungen normalerweise ausführen:

• Behalten Sie den Zustand bei, der hier durch eine einfache Zeichenfolgenvariable dargestellt wird.
• Rufen Sie Eingaben aus der Außenwelt ab, z. B. durch Empfangen einer Anforderung von einem Client. Eine einfache Anwendung könnte einfach aus der Konsole gelesen werden, während ein häufigeres Beispiel eine HTTP-Anforderung von einem Webbrowser oder einer SOAP-Nachricht aus einer anderen Anwendung empfängt.
• Ausgabe an die Außenwelt senden. Je nachdem, wie sie erstellt wird, kann die Anwendung dies über HTTP, eine SOAP-Nachricht, durch Schreiben in die Konsole oder auf andere Weise tun.
• Stellen Sie alternative Pfade über Logik bereit, indem Sie Ablaufanweisungen wie "if/else" und "while" verwenden.
• Führen Sie an jedem Punkt der Anwendung geeignete Code aus.

Im hier gezeigten einheitlichen Ansatz verbringt die Anwendungslogik ihre gesamte Lebensdauer auf einem Thread innerhalb eines bestimmten Prozesses auf einem einzelnen Computer. Dieser einfache Ansatz hat mehrere Vorteile. Zum einen kann die Logik auf einfache, einheitliche Weise implementiert werden. Dies hilft Personen, die mit dem Code arbeiten, sie zu verstehen, und es macht auch die zulässige Reihenfolge von Ereignissen explizit. In Abbildung 1 ist beispielsweise ersichtlich, dass die erste Anforderung des Clients dem zweiten vorausgehen muss – der Steuerungsfluss des Programms erfordert ihn. Wenn die zweite Anforderung eingeht, muss nicht überprüft werden, ob die erste Anforderung bereits verarbeitet wurde, da es keinen anderen Pfad durch die Anwendung gibt.

Ein weiterer Vorteil dieses Ansatzes besteht darin, dass das Arbeiten mit dem Zustand der Anwendung einfach ist. Dieser Zustand wird im Arbeitsspeicher des Prozesses gespeichert, und da der Prozess kontinuierlich ausgeführt wird, bis seine Arbeit abgeschlossen ist, ist der Zustand immer verfügbar: Der Entwickler greift einfach auf gewöhnliche Variablen zu. Was könnte einfacher sein?

Dennoch hat dieser grundlegende Programmierstil Einschränkungen. Wenn die Anwendung auf die Eingabe warten muss, sei es von einem Benutzer in der Konsole, einem Webdienstclient oder einem anderen Client, wird dies in der Regel nur blockiert. Sowohl der Thread als auch der verwendete Prozess werden so lange gehalten, bis die Eingabe eingeht. Da Threads und Prozesse relativ knappe Ressourcen sind, sind Anwendungen, die an einem der Beiden halten, wenn sie nur auf Eingabe warten, nicht sehr gut skaliert.

Ein skalierbarerer Ansatz besteht darin, die Anwendung herunterzufahren, wenn sie auf die Eingabe wartet, und sie dann neu starten, wenn diese Eingabe eingeht. Dieser Ansatz verschwendet keine Ressourcen, da die Anwendung nicht an einen Thread oder einen Prozess hält, wenn sie sie nicht benötigt. Dadurch kann die Anwendung auch in verschiedenen Prozessen auf unterschiedlichen Computern zu unterschiedlichen Zeiten ausgeführt werden. Anstatt auf ein einzelnes System gesperrt zu werden, wie in Abbildung 1 dargestellt, kann die Anwendung stattdessen auf einem von mehreren verfügbaren Computern ausgeführt werden. Dies hilft auch bei der Skalierbarkeit, da die Arbeit leichter auf verschiedene Computer verteilt werden kann. Abbildung 2 zeigt, wie dies aussieht.

Abbildung 2: Anwendungslogik kann in Blöcke unterteilt werden, alle gemeinsam genutzten Status, die auf verschiedenen Computern ausgeführt werden können.

Diese Beispielanwendung enthält dieselbe Logik wie zuvor, ist aber jetzt in separate Blöcke unterteilt. Wenn die erste Anforderung des Clients empfangen wird, wird der entsprechende Block geladen und ausgeführt. Nachdem diese Anforderung verarbeitet und eine zurückgesendete Antwort gesendet wurde, kann dieser Block entladen werden– es bleibt kein Speicher mehr erforderlich. Wenn die zweite Anforderung des Clients eingeht, wird der Datenblock geladen und ausgeführt. Wie in Abbildung 2 dargestellt, kann dieser Block in einem anderen Prozess ausgeführt werden, der auf einem anderen Computer als dem ersten Block ausgeführt wird. Sobald sie die Anforderung verarbeitet hat, kann dieser zweite Block auch entladen werden, wobei der verwendete Arbeitsspeicher freigegeben wird.

Ein gängiges Beispiel für eine Technologie, die auf diese Weise funktioniert, ist ASP.NET. Ein Entwickler implementiert eine ASP.NET Anwendung als Eine Reihe von Seiten, die jeweils einen Teil der Logik der Anwendung enthalten. Wenn eine Anforderung eingeht, wird die richtige Seite geladen, ausgeführt und dann erneut entladen.

Eine in diesem Stil integrierte Anwendung kann Computerressourcen effizienter als eine anwendung verwenden, die mit dem zuvor gezeigten einfacheren Ansatz erstellt wurde, und daher wird sie besser skaliert. Dennoch haben wir für diese verbesserte Skalierbarkeit mit Komplexität bezahlt. Zum einen müssen die verschiedenen Codeabschnitte irgendwie den Zustand teilen, wie in Abbildung 2 dargestellt. Da jeder Block bei Bedarf geladen wird, ausgeführt und dann heruntergefahren wird, muss dieser Zustand extern gespeichert werden, z. B. in einer Datenbank oder einem anderen Persistenzspeicher. Anstatt nur auf gewöhnliche Variablen zuzugreifen, wie das in Abbildung 1 gezeigte Szenario, muss ein Entwickler jetzt spezielle Aufgaben ausführen, um den Zustand der Anwendung zu erwerben und zu speichern. In ASP.NET Anwendungen können Entwickler beispielsweise den Zustand direkt in eine Datenbank schreiben, auf das Session-Objekt zugreifen oder einen anderen Ansatz verwenden.

Eine weitere Kosten dieser verbesserten Skalierbarkeit besteht darin, dass der Code keine einheitliche Ansicht der allgemeinen Logik des Programms mehr bietet. In der in Abbildung 1 gezeigten Version ist die Reihenfolge, in der das Programm Eingabe erwartet, offensichtlich – es gibt nur einen möglichen Pfad durch den Code. Bei der Version von Abbildung 2 ist dieser Kontrollfluss jedoch nicht erkennbar. Tatsächlich muss der Codeabschnitt, der die zweite Anforderung des Clients verarbeitet, möglicherweise zunächst überprüfen, ob die erste Anforderung bereits durchgeführt wurde. Für eine Anwendung, die jede Art von bedeutendem Geschäftsprozess implementiert, kann es schwierig sein, den Steuerungsfluss über verschiedene Abschnitte hinweg zu verstehen und richtig zu implementieren.

Die Situation ist dies: Das Schreiben einheitlicher Anwendungen macht das Leben des Entwicklers einfach und der Code ist einfach zu verstehen, aber das Ergebnis wird nicht gut skaliert. Das Schreiben von blockigen Anwendungen, die den externen Zustand gemeinsam nutzen, z. B. ASP.NET Anwendungen, ermöglicht Skalierbarkeit, macht jedoch die Verwaltung des Zustands schwieriger und verliert den einheitlichen Kontrollfluss. Was wir möchten, ist eine Möglichkeit, beides zu tun: Schreiben sie skalierbare Geschäftslogik mit einfacher Zustandsverwaltung, haben aber dennoch eine einheitliche Ansicht des Steuerungsflusses der Anwendung.

Dies ist genau das, was der Workflow bereitstellt. Im nächsten Abschnitt wird gezeigt, wie das geht.

Die Lösung: Der Workflowweg

Um zu verstehen, wie eine WF-Anwendung diese Probleme (und andere) löst, müssen Sie die Grundlagen der Funktionsweise von WF durchgehen. Auf dem Weg werden wir sehen, warum diese Technologie für Entwickler in einer überraschend großen Anzahl von Fällen das Leben verbessern kann.

Erstellen einer einheitlichen Anwendungslogik

Eine workflowbasierte Anwendung, die mit WF erstellt wurde, führt die gleichen Arten von Dingen wie eine normale Anwendung aus: Sie verwaltet den Zustand, ruft Eingaben ab und sendet Die Ausgabe an die Außenwelt, stellt den Steuerungsfluss bereit und führt Code aus, der die Arbeit der Anwendung ausführt. In einem WF-Workflow werden jedoch alle diese Dinge durch Aktivitäten ausgeführt. Abbildung 3 zeigt, wie dies aussieht, wobei der einheitliche Codeansatz zusammen mit vergleichsweise dargestellt wird.

Abbildung 3: In einem WF-Workflow werden alle Arbeiten eines Programms durch Aktivitäten ausgeführt.

Wie in Abbildung 3 dargestellt, weist jeder Workflow eine äußerste Aktivität auf, die alle anderen enthält. Hier wird diese äußerste Aktivität als Sequence bezeichnet, und wie ein normales Programm kann sie Variablen aufweisen, die ihren Zustand beibehalten. Da Sequence eine zusammengesetzte Aktivität ist, kann sie auch andere Aktivitäten enthalten.

In diesem einfachen Beispiel beginnt der Workflow mit einer ReceiveMessage-Aktivität, die Eingaben von außen abruft. Dies folgt einer If-Aktivität, die (nicht überraschend) eine Verzweigung implementiert. Wenn es sich auch um eine zusammengesetzte Aktivität handelt, die andere Aktivitäten (hier mit der Bezeichnung "X" und "Y") enthält, die die für jede Verzweigung ausgeführten Arbeit ausführen. Auf die If-Aktivität folgt eine SendMessage-Aktivität, die über diesen Workflow hinaus eine Ausgabe an die Welt sendet. Als Nächstes wird eine weitere ReceiveMessage-Aktivität angezeigt, die mehr Eingaben erhält, gefolgt von einer While-Aktivität. Enthält zwar eine weitere Aktivität, Z, die die Arbeit dieser Schleife ausführt. Der gesamte Workflow endet mit einer endgültigen SendMessage-Aktivität und sendet das Endergebnis des Programms.

Alle diese Aktivitäten entsprechen funktional verschiedenen Teilen eines typischen Programms, wie die übereinstimmenden Farben in Abbildung 2 vorschlagen. Anstatt jedoch integrierte Sprachelemente zu verwenden, ist jede Aktivität in einem WF-Workflow tatsächlich eine Klasse. Die Ausführung des Workflows wird von der WF-Laufzeit ausgeführt, einer Komponente, die weiß, wie Aktivitäten ausgeführt werden. In Abbildung 4 ist diese Idee dargestellt.

Abbildung 4: Die WF-Laufzeit führt Aktivitäten in der vom Workflow festgelegten Reihenfolge aus.

Wenn sie mit der Ausführung eines Workflows beginnt, führt die WF-Laufzeit zunächst die äußerste Aktivität aus, bei der es sich in diesem Beispiel um eine Sequenz handelt. Anschließend wird die erste Aktivität innerhalb dieses Ausgeführt, die hier "ReceiveMessage" ist, gefolgt von der nächsten Aktivität usw. Genau welche Aktivitäten in einer bestimmten Situation ausgeführt werden, hängt davon ab, welcher Pfad durch den Workflow ausgeführt wird. Beispielsweise kann das Abrufen einer Eingabe in der ersten ReceiveMessage-Aktivität dazu führen, dass die Aktivität "Aktivität X" ausführt, während eine andere Art von Eingabe dazu führen kann, dass aktivität Y ausgeführt wird. Es ist genauso wie jedes andere Programm.

Es ist wichtig zu verstehen, dass die WF-Laufzeit überhaupt nichts über die Internen der ausgeführten Aktivitäten weiß. Eine "If" von einer ReceiveMessage kann nicht angezeigt werden. Das einzige, was es weiß, wie eine Aktivität ausgeführt wird, und führen Sie dann das nächste aus. Die Laufzeit kann jedoch die Grenzen zwischen Aktivitäten sehen, was, wie wir sehen, eine nützliche Sache ist.

Ein wichtiger Aspekt ist, dass WF keine bestimmte Sprache für die Beschreibung von Workflows definiert – alles hängt von den Aktivitäten ab, die ein Entwickler verwenden möchte. Um das Leben zu vereinfachen, enthält WF eine Basisaktivitätsbibliothek (Base Activity Library, BAL), die eine breite Palette von Aktivitäten bietet. (Alle hier verwendeten Beispielaktivitäten stammen aus dem BAL, tatsächlich.) Entwickler können jedoch alle anderen Aktivitäten erstellen, die ihnen gefallen. Sie können sogar entscheiden, den BAL vollständig zu ignorieren.

Hier gibt es eine offensichtliche Frage: Warum gehen Sie zu all diesen Problemen? Das Erstellen eines Programms mit Aktivitäten unterscheidet sich von den verwendeten Entwicklern. Warum sollten sie sich also stören? Warum nicht nur gewöhnlichen Code schreiben?

Die Antwort ist natürlich, dass dieser Ansatz uns dabei helfen kann, besseren Code zu erstellen. Beachten Sie beispielsweise, dass der Workflow dem Entwickler einen einheitlichen Steuerungsfluss verleiht. Genau wie im einfachen Fall in Abbildung 1 wird die Hauptlogik des Programms in einem kohärenten Datenstrom definiert. Dies erleichtert das Verständnis und da die Logik nicht in Blöcke unterteilt ist, müssen keine zusätzlichen Prüfungen durchgeführt werden. Der Workflow selbst drückt den zulässigen Kontrollfluss aus.

Dies stellt die Hälfte unseres Ziels dar: die Erstellung einheitlicher Anwendungslogik. WF-Anwendungen können aber auch die zweite Hälfte erreichen und skalierbare Anwendungen mit einfacher Zustandsverwaltung erstellen. Im nächsten Abschnitt wird erläutert, wie der Workflow dies ermöglicht.

Bereitstellung von Skalierbarkeit

Um skalierbar zu sein, kann eine Serveranwendung nicht in einen einzelnen Prozess auf einem einzelnen Computer gesperrt werden. Wie auf ASP.NET Seiten jedoch wird die Anwendungslogik explizit in Blöcke unterteilt, was ein einheitlicher Kontrollfluss sein soll. Außerdem wird der Programmierer gezwungen, explizit mit dem Zustand zu arbeiten. Was wir wirklich möchten, ist eine Möglichkeit, unsere Logik automatisch in Blöcke unterteilt zu haben, die in verschiedenen Prozessen auf verschiedenen Computern ausgeführt werden können. Wir möchten auch den Zustand unserer Anwendung für uns verwalten lassen, daher müssen wir nur Zugriffsvariablen ausführen.

Genau dies ist die Bereitstellung von Workflows. Abbildung 5 zeigt die Grundlagen, wie WF diese Dinge erreicht.

Abbildung 5: Die WF-Laufzeit entlädt einen Workflow, während er auf die Eingabe wartet, und lädt ihn dann erneut, sobald die Eingabe eingeht.

Wie jede Anwendung blockiert ein WF-Workflow, der auf die Eingabe wartet. In Abbildung 5 wird der Workflow beispielsweise bei der zweiten ReceiveMessage-Aktivität blockiert, die auf die zweite Anforderung des Clients wartet (Schritt 1). Die WF-Laufzeit bemerkt dies und speichert den Status des Workflows und zeigt an, wo der Workflow in einem Persistenzspeicher fortgesetzt werden soll (Schritt 2). Wenn die Eingabe für diesen Workflow (Schritt 3) eingeht, findet die WF-Laufzeit den persistenten Zustand und lädt den Workflow dann neu, und nimmt die Ausführung dort wieder auf, wo er unterbrochen wurde (Schritt 4). All dies geschieht automatisch – der WF-Entwickler muss nichts tun. Da die WF-Laufzeit im Workflow zu sehen ist, kann sie alle diese Details selbst verarbeiten.

Ein offensichtlicher Vorteil dieses Ansatzes besteht darin, dass der Workflow nicht im Arbeitsspeicher hängen bleibt, der einen Thread blockiert und einen Prozess verwendet, während er auf die Eingabe wartet. Ein weiterer Vorteil ist, dass ein beibehaltener Workflow möglicherweise auf einem anderen Computer als dem neu geladen werden kann, auf dem er ursprünglich ausgeführt wurde. Aus diesem Gründen können unterschiedliche Teile des Workflows möglicherweise auf verschiedenen Systemen ausgeführt werden, wie in Abbildung 6 dargestellt.

Abbildung 6: Ein Workflow kann in verschiedenen Threads, in verschiedenen Prozessen und auf verschiedenen Computern während seiner Lebensdauer ausgeführt werden.

Nehmen wir in diesem Beispiel an, dass der Workflow die erste Clientanforderung in einem Prozess auf Computer A verarbeitet. Wenn die zweite ReceiveMessage bewirkt, dass der Workflow das Warten auf eingaben blockiert, entlädt die WF-Laufzeit den Status des Workflows in einen Persistenzspeicher, wie gerade beschrieben. Wenn die zweite Anforderung des Clients eingeht, ist es möglich, dass dieser Workflow in einen Prozess auf Computer B neu geladen wird. Anstatt in einem bestimmten Thread in einem bestimmten Prozess auf einem bestimmten Computer gesperrt zu werden, kann ein WF-Workflow nach Bedarf verschoben werden. Und der Entwickler erhält diese Flexibilität kostenlos – es wird automatisch von WF bereitgestellt.

Es empfiehlt sich, darauf hinzuweisen, dass die WF-Laufzeit nicht darauf achtt, wie lange der Workflow auf die Eingabe warten muss. Es kann ein paar Sekunden nach dem Beibehalten des Workflows, ein paar Minuten später oder sogar ein paar Monate später ankommen. Solange der Persistenzspeicher weiterhin im Status des Workflows gespeichert ist, kann dieser Workflow neu gestartet werden. Dies macht WF zu einer attraktiven Technologie für die Erstellung von Anwendungen, die lange laufende Prozesse implementieren. Denken Sie an eine Anwendung, die beispielsweise einen Einstellungsprozess unterstützt, der alles umfasst, von der Planung anfänglicher Interviews bis hin zur Integration eines neuen Mitarbeiters in die Organisation. Dieser Vorgang kann wochen- oder monatelang dauern, und daher ist es sinnvoll, den Status der Anwendung mithilfe von WF zu verwalten. Obwohl WF mit dieser Art von lang andauerndem Prozess durchaus nützlich sein kann, ist es wichtig zu verstehen, dass dies nicht der einzige Zweck ist. Jede Anwendung, die einheitliche, skalierbare Logik erfordert, kann ein guter Kandidat für WF sein.

Sehen Sie sich in Abbildung 6 einen anderen Blick an. Sieht es nicht ähnlich aus wie In Abbildung 2, was zeigt, wie eine blockige Anwendung (z. B. eine, die ausschließlich mit ASP.NET erstellt wurde) Skalierbarkeit erzielt hat? Und tatsächlich weist Abbildung 6 nicht auch eine starke Ähnlichkeit mit Abbildung 1 auf, die eine einheitliche Anwendung zeigt, die mit einem linearen Steuerfluss erstellt wurde? WF erreicht beides: Der Steuerungsfluss der Anwendung wird verständlich, einheitlich ausgedrückt, und die Anwendung kann skaliert werden, da sie nicht auf einen einzelnen Prozess auf einem einzigen Computer gesperrt ist. Dies ist die Schönheit des Workflows.

Und das ist nicht alles; Die Verwendung von WF hat auch andere Vorteile. Sie kann die Koordination paralleler Arbeit vereinfachen, z. B. bei der Nachverfolgung des Fortschritts einer Anwendung und mehr. Im nächsten Abschnitt werden diese Aspekte der Technologie behandelt.

Weitere Vorteile der Workflow-Methode

Ein WF-Workflow besteht aus Aktivitäten, die von der WF-Laufzeit ausgeführt werden. Während das Verständnis der WF-Welt einige Anstrengungen erfordert, erleichtert das Schreiben von Anwendungslogik in diesem Stil eine Reihe häufiger Programmierprobleme, wie im nächsten Schritt beschrieben.

Koordination paralleler Arbeit

Der WF BAL umfasst Aktivitäten, die mit vertrauten Programmiersprachenanweisungen übereinstimmen. Aus diesem Gründen können Sie Workflows schreiben, die sich ähnlich wie normale Programme verhalten. Das Vorhandensein der WF-Laufzeit ermöglicht jedoch auch das Erstellen von Aktivitäten, die mehr als eine herkömmliche Programmiersprache bieten. Ein wichtiges Beispiel hierfür ist die Verwendung eines Workflows, um die Koordination paralleler Arbeit zu vereinfachen.

Lassen Sie sich nicht verwechseln: Der Fokus liegt hier nicht auf dem Schreiben von parallelem Code, der gleichzeitig auf einem Multi-Core-Prozessor ausgeführt wird. Denken Sie stattdessen an eine Anwendung, die beispielsweise zwei Webdienste aufrufen muss, und warten Sie dann auf beide Ergebnisse, bevor Sie fortfahren. Das parallele Ausführen der Aufrufe ist deutlich schneller als die sequenzielle Ausführung, aber das Schreiben von herkömmlichem Code, der dies tut, ist nicht einfach. Und während .NET Framework verschiedene Ansätze für die asynchrone Durchführung dieser Aufrufe bietet, sind keine von ihnen besonders einfach. Dies ist eine weitere Situation, in der der Workflowweg glänzt: WF macht dies einfach. Abbildung 7 zeigt, wie das geht.

Abbildung 7: Aktivitäten, die in einer parallelen Aktivität enthalten sind, werden parallel ausgeführt.

Diese Abbildung zeigt einen einfachen Workflow, der ähnlich dem vorherigen Beispiel ist. Der große Unterschied besteht darin, dass jetzt zwei Webdienste aufgerufen werden, und wartet dann auf eine Antwort von beiden, bevor sie fortfahren. Um diese Aufrufe parallel auszuführen, hat der Ersteller des Workflows beide Paare von SendMessage- und ReceiveMessage-Aktivitäten innerhalb einer parallelen Aktivität umschlossen. Parallel ist ein Standardteil der WF-Basisaktivitätsbibliothek, und genau das, was der Name vorschlägt: führt die darin enthaltenen Aktivitäten parallel aus. Anstatt den Entwickler mit der Komplexität der Handhabung zu befassen, führen die WF-Laufzeit und die Parallel-Aktivität die schwere Hebearbeitung durch. Alle Entwickler müssen die Aktivitäten nach Bedarf anordnen, um ihr Problem zu lösen.

Bereitstellen der automatischen Nachverfolgung

Da die WF-Laufzeit die Grenzen zwischen den Aktivitäten eines Workflows sehen kann, weiß sie, wann jede dieser Aktivitäten beginnt und endet. In diesem Fall ist die automatische Nachverfolgung der Ausführung des Workflows einfach. Abbildung 8 veranschaulicht diese Idee.

Abbildung 8: Die WF-Laufzeit kann die Ausführung eines Workflows automatisch nachverfolgen.

Wie in diesem Beispiel gezeigt, kann die WF-Laufzeit einen Datensatz der Ausführung eines Workflows in einen Nachverfolgungsspeicher schreiben. Eine Option besteht darin, Aktivitäten zu protokollieren, wobei jedes Mal ein Datensatz geschrieben wird, wenn eine Aktivität beginnt und die Ausführung beendet. Im Moment, der in der Abbildung gezeigt wird, ist beispielsweise der Workflow dabei, mit der Ausführung der If-Aktivität zu beginnen, und daher schreibt die WF-Laufzeit ein Ereignis, das dies angibt. Es ist auch möglich, bestimmte Variablen zu verfolgen, d. h. workflowstatus, die Werte an verschiedenen Stellen in der Ausführung des Workflows aufzuzeichnen.

Wie bei anderen Aspekten von WF erfordert diese automatische Protokollierung im Wesentlichen keine Arbeit am Teil des Entwicklers. Er kann einfach darauf hinweisen, dass tracking geschehen soll, die Ebene angibt, an der er interessiert ist, und WF kümmert sich um den Rest.

Erstellen wiederverwendbarer benutzerdefinierter Aktivitäten

Die Aktivitäten im WF BAL bieten eine Vielzahl nützlicher Funktionen. Wie bereits gezeigt, umfasst dieser integrierte Satz beispielsweise Aktivitäten für den Steuerungsfluss, das Senden und Empfangen von Nachrichten, die parallele Arbeit und vieles mehr. Das Erstellen einer echten Anwendung erfordert in der Regel jedoch das Erstellen von Aktivitäten, die aufgabenspezifisch für diese Anwendung ausführen.

Um dies zu ermöglichen, ermöglicht WF das Erstellen benutzerdefinierter Aktivitäten. Beispielsweise sind die Aktivitäten mit der Bezeichnung "X", "Y" und "Z" in den zuvor gezeigten Workflows tatsächlich benutzerdefinierte Aktivitäten, wie In Abbildung 9 angegeben.

Abbildung 9: Benutzerdefinierte Aktivitäten ermöglichen es einem Workflow, anwendungsspezifische Aufgaben auszuführen.

Benutzerdefinierte Aktivitäten können einfach sein, nur eine Aufgabe ausführen, oder sie können zusammengesetzte Aktivitäten sein, die willkürlich komplexe Logik enthalten. Und unabhängig davon, ob sie einfach oder komplex sind, können benutzerdefinierte Aktivitäten auf viele verschiedene Arten verwendet werden. Beispielsweise kann eine geschäftsspezifische Anwendung, die mit WF erstellt wurde, anwendungsspezifische Logik als eine oder mehrere benutzerdefinierte Aktivitäten implementieren. Alternativ kann ein Softwareanbieter, der WF verwendet, eine Reihe von benutzerdefinierten Aktivitäten bereitstellen, um das Leben seiner Kunden zu vereinfachen. Mit Windows SharePoint Services können Entwickler beispielsweise WF-basierte Anwendungen erstellen, die mit Personen über die Standardlisten von SharePoint interagieren. Um dies zu vereinfachen, enthält SharePoint benutzerdefinierte Aktivitäten zum Schreiben von Informationen in eine Liste.

Benutzerdefinierte Aktivitäten können direkt in Code geschrieben werden, mit C# oder Visual Basic oder einer anderen Sprache. Sie können auch durch die Kombination vorhandener Aktivitäten erstellt werden, die einige interessante Optionen ermöglichen. Beispielsweise kann eine Organisation benutzerdefinierte Aktivitäten auf niedrigerer Ebene für ihre hochqualifizierten Entwickler erstellen und diese dann in Geschäftsfunktionen höherer Ebene verpacken, damit weniger technische Personen verwendet werden können. Diese Aktivitäten auf höherer Ebene können jede erforderliche Geschäftslogik implementieren, alle in ein wiederverwendbares Feld verpackt.

Eine weitere Möglichkeit, dies zu berücksichtigen, besteht darin, eine bestimmte Gruppe von Aktivitäten anzuzeigen, die von der WF-Laufzeit als Sprache ausgeführt werden. Wenn eine Organisation eine Gruppe von benutzerdefinierten Aktivitäten erstellt, die wiederverwendet werden können, um bestimmte Probleme in mehreren Anwendungen zu lösen, erstellen sie wirklich eine Art domänenspezifischer Sprache (DSL). Sobald dies geschehen ist, kann es für weniger technische Personen möglich sein, WF-Anwendungen mit diesen vordefinierten Blöcken benutzerdefinierter Funktionen zu erstellen. Anstatt neuen Code zu schreiben, um die Funktionen der Anwendung zu implementieren, könnten nützliche neue Software nur durch das Zusammenstellen vorhandener Aktivitäten erstellt werden. Dieser DSL-Stil, der in der Workflowart definiert ist, kann in einigen Situationen die Produktivität der Entwickler erheblich verbessern.

Sichtbarmachen von Prozessen

Das Erstellen von Anwendungen mit einer herkömmlichen Programmiersprache bedeutet das Schreiben von Code. Das Erstellen von Anwendungen mit WF ist in der Regel nicht ganz so niedrig. Stattdessen kann der Hauptsteuerungsfluss eines Workflows grafisch zusammengestellt werden. Um dies zu ermöglichen, enthält WF einen Workflow-Designer, der in Visual Studio ausgeführt wird. Abbildung 10 zeigt ein Beispiel.

Abbildung 10: Der Workflow-Designer, der in Visual Studio ausgeführt wird, ermöglicht es einem Entwickler, einen Workflow durch Ziehen und Ablegen von Aktivitäten zu erstellen.

Wie in diesem Beispiel gezeigt, werden die für einen WF-Entwickler verfügbaren Aktivitäten auf der linken Seite angezeigt. Um einen Workflow zu erstellen, kann sie diese Aktivitäten auf der Entwurfsoberfläche zusammenstellen, um eine beliebige Logik zu erstellen, die die Anwendung benötigt. Bei Bedarf kann der WF-Workflow-Designer auch in anderen Umgebungen erneut gehostet werden, sodass andere dieses Tool in ihren eigenen Angeboten verwenden können.

Bei einigen Entwicklern erleichtert dieser grafische Ansatz das Erstellen von Anwendungen schneller und einfacher. Außerdem wird die Hauptlogik der Anwendung sichtbarer. Durch die Bereitstellung eines einfachen Bilds zu den Aktuellen kann der WF-Workflow-Designer Entwicklern helfen, die Struktur einer Anwendung schneller zu verstehen. Dies kann besonders hilfreich für die Personen sein, die bereitgestellte Anwendungen verwalten müssen, da das Erlernen einer neuen Anwendung gut genug ist, um sie zu ändern, ein zeitaufwändiger Prozess sein kann.

Aber was ist mit benutzerdefinierten Aktivitäten? Muss noch Code geschrieben werden? Die Antwort lautet ja, daher ermöglicht WF auch die Verwendung von Visual Studio zum Erstellen benutzerdefinierter Aktivitäten in C#, Visual Basic und anderen Sprachen. Um zu verstehen, wie dies funktioniert, ist es wichtig zu verstehen, wie der WF-Designer die verschiedenen Teile eines Workflows darstellt. Abbildung 11 zeigt, wie dies in der Regel erfolgt.

Abbildung 11: Der Zustand und der Steuerungsfluss eines Workflows werden normalerweise in XAML beschrieben, während benutzerdefinierte Aktivitäten im Code geschrieben werden können.

Die Zusammensetzung eines WF-Workflows – die darin enthaltenen Aktivitäten und die Art der zugehörigen Aktivitäten – werden in der Regel mithilfe der eXtensible Application Markup Language (XAML) dargestellt. Wie in Abbildung 11 dargestellt, bietet XAML eine XML-basierte Möglichkeit, den Status des Workflows als Variablen zu beschreiben und die Beziehungen zwischen den Aktivitäten des Workflows auszudrücken. Hier enthält beispielsweise der XAML-Code für die äußerste Workflowaktivitätssequenz eine ReceiveMessage-Aktivität gefolgt von einer If-Aktivität, genau wie erwartet.

Diese Aktivität enthält die benutzerdefinierten Aktivitäten X und Y. Anstatt in XAML erstellt zu werden, werden diese Aktivitäten jedoch als C#-Klassen geschrieben. Obwohl es möglich ist, einige benutzerdefinierte Aktivitäten ausschließlich in XAML zu erstellen, wird in der Regel eine speziellere Logik direkt in Code geschrieben. Obwohl es nicht der übliche Ansatz ist, ist ein Entwickler auch frei, Workflows vollständig in Code zu schreiben – die Verwendung von XAML ist nicht unbedingt erforderlich.

Verwenden von Windows Workflow Foundation: Einige Szenarien

Das Verständnis der Mechanik von WF ist ein wesentlicher Bestandteil der Erfassung des Workflows. Es reicht jedoch nicht aus: Sie müssen auch verstehen, wie Workflows in Anwendungen verwendet werden können. Dementsprechend befasst sich dieser Abschnitt mit der Architektur, wie – und warum – WF in einigen typischen Situationen verwendet werden kann.

Erstellen eines Workflowdiensts

Das Erstellen von Geschäftslogik als Dienst ist häufig sinnvoll. Angenommen, auf den gleichen Funktionsumfang muss über ASP.NET, über einen Silverlight-Client und über eine eigenständige Desktopanwendung über einen Browser zugegriffen werden. Die Implementierung dieser Logik als Eine Reihe von Vorgängen, die von einem dieser Clients aufgerufen werden können, d. h. als Dienst, ist wahrscheinlich der beste Ansatz. Durch das Verfügbarmachen von Logik als Dienst kann auch auf andere Logik zugegriffen werden, wodurch die Anwendungsintegration manchmal vereinfacht wird. (Dies ist die Kernidee hinter dem Konzept von SOA, dienstorientierter Architektur.)

Für .NET-Entwickler ist die Flaggschifftechnologie zum Erstellen von Diensten heute Windows Communication Foundation (WCF). Unter anderem ermöglicht WCF Entwicklern die Implementierung von Geschäftslogik, auf die über REST, SOAP und andere Kommunikationsstile zugegriffen werden kann. Und für einige Dienste kann WCF alles sein, was erforderlich ist. Wenn Sie einen Dienst implementieren, bei dem jeder Vorgang allein steht, z. B. kann jeder Vorgang jederzeit aufgerufen werden, ohne dass dies erforderlich ist– das Erstellen dieser Dienste als unformatierte WCF-Dienste ist einfach in Ordnung. Der Ersteller eines Diensts, dessen Vorgänge nur Daten verfügbar machen, können z. B. nur wcf verwenden.

Bei komplexeren Situationen, in denen die Vorgänge in einem Dienst jedoch einen verwandten Satz von Funktionen implementieren, reicht WCF allein möglicherweise nicht aus. Überlegen Sie sich Anwendungen, mit denen Kunden Flugreservierungen buchen oder Online-Shopping durchführen oder einen anderen Geschäftsprozess durchführen können. In solchen Fällen können Sie auch WF verwenden, um die Logik des Diensts zu implementieren. Diese Kombination hat sogar einen Namen: Logik, die mithilfe von WF implementiert und über WCF verfügbar gemacht wird, wird als Workflowdienst bezeichnet. Abbildung 12 veranschaulicht die Idee.

Abbildung 12: Ein Workflowdienst verwendet WCF, um WF-basierte Logik verfügbar zu machen.

Wie die Abbildung zeigt, ermöglicht WCF das Verfügbarmachen eines oder mehrerer Endpunkte, die Clients über SOAP, REST oder etwas anderes aufrufen können. Wenn der Client den anfänglichen Vorgang in diesem Beispieldienst aufruft, wird die Anforderung von der ersten ReceiveMessage-Aktivität des Workflows behandelt. Als Nächstes wird eine Aktivität angezeigt, die von den enthaltenen benutzerdefinierten Aktivitäten ausgeführt wird, hängt vom Inhalt der Anforderung des Clients ab. Wenn der Vorgang abgeschlossen ist, wird eine Antwort über SendMessage zurückgegeben. Die zweite Anforderung des Clients, die einen anderen Vorgang aufruft, wird auf ähnliche Weise behandelt: Sie wird von einer ReceiveMessage akzeptiert, die von der Logik des Workflows verarbeitet wird, und dann mit einer SendMessage reagiert.

Warum ist die Erstellung serviceorientierter Geschäftslogik auf diese Weise eine gute Idee? Die Antwort ist offensichtlich: Sie ermöglicht das Erstellen einer einheitlichen und skalierbaren Anwendung. Anstatt jede Operation zur Aufnahme von Prüfungen zu verlangen – ist es legal, mich gerade aufzurufen?) dieses Wissen ist in die Workflowlogik selbst eingebettet. Dadurch wird die Anwendung einfacher zu schreiben und, ebenso wichtig, für die Personen, die sie letztendlich beibehalten müssen, einfacher zu verstehen. Und anstatt Ihren eigenen Code für die Skalierbarkeit und Zustandsverwaltung zu schreiben, erledigt die WF-Laufzeit diese Dinge für Sie.

Ein Workflowdienst erhält auch alle zuvor beschriebenen Vorteile, genau wie jede andere WF-Anwendung. Dazu gehören folgendes:

• Das Implementieren von Diensten, die parallel arbeiten, ist einfach: Legen Sie einfach Aktivitäten in eine parallele Aktivität ab.
• Die Nachverfolgung wird von der Laufzeit bereitgestellt.
• Je nach Problemdomäne kann es möglich sein, wiederverwendbare benutzerdefinierte Aktivitäten für die Verwendung in anderen Diensten zu erstellen.
• Der Workflow kann grafisch erstellt werden, wobei die Prozesslogik direkt im WF-Workflow-Designer sichtbar ist.

Die gemeinsame Verwendung von WF und WCF – das Erstellen von Workflowdiensten – war in früheren Versionen von WF nicht so einfach. Mit .NET Framework 4 kommt diese Technologiekombination natürlicher zusammen. Ziel ist es, die Geschäftslogik in diesem Stil so einfach wie möglich zu erstellen.

Ausführen eines Workflowdiensts mit "Dublin"

Ein großes Problem mit Workflows wurde noch nicht diskutiert: Wo werden sie ausgeführt? Die WF-Laufzeit ist eine Klasse, wie Aktivitäten. All diese Dinge müssen in einem Hostprozess ausgeführt werden, aber welcher Prozess ist dies?

Die Antwort ist, dass WF-Workflows in ziemlich jedem Prozess ausgeführt werden können. Sie können ihren eigenen Host erstellen und sogar einige der grundlegenden WF-Dienste (z. B. Persistenz) ersetzen, wenn Sie möchten. Viele Organisationen haben dies getan, insbesondere Softwareanbieter. Das Erstellen eines wirklich funktionalen Hostprozesses für WF, komplett mit Verwaltungsfunktionen, ist jedoch nicht das einfachste in der Welt. Und für Organisationen, die ihr Geld für die Erstellung von Geschäftslogik anstelle der Infrastruktur ausgeben möchten, ist es sinnvoll, diesen Aufwand zu vermeiden.

Eine einfachere Option besteht darin, einen WF-Workflow in einem Von InternetInformation Server (IIS) bereitgestellten Arbeitsprozess zu hosten. Während dies funktioniert, bietet es nur eine Barknochenlösung. Um WF-Entwicklern das Leben zu erleichtern, stellt Microsoft einen Technologiecode namens "Dublin" bereit. Implementiert als Erweiterungen für IIS und den Windows-Prozessaktivierungsdienst (WAS), ist ein primäres Ziel von "Dublin", IIS und WAS als Host für Workflowdienste attraktiver zu gestalten. Abbildung 13 zeigt, wie ein Workflowdienst aussieht, wenn er in einer "Dublin"-Umgebung ausgeführt wird.

Abbildung 13: "Dublin" bietet Verwaltung und mehr für Workflowdienste.

Während WF selbst Mechanismen zum Beibehalten des Zustands, der Nachverfolgung und mehr eines Workflows enthält, bietet es nur die Grundlagen. "Dublin" baut auf der systeminternen Unterstützung von WF auf, um eine nützlichere und verwaltbare Umgebung zu bieten. Beispielsweise bietet "Dublin" zusammen mit einem SQL Server-basierten Persistenzspeicher und einem Tracking-Speicher ein Verwaltungstool für die Arbeit mit diesen Stores. Dieses Tool, das als Erweiterungen für IIS-Manager implementiert wird, ermöglicht es seinen Benutzern, gespeicherte Workflows (z. B. beenden) zu untersuchen und zu verwalten, zu steuern, wie viel Nachverfolgung durchgeführt wird, Nachverfolgungsprotokolle zu untersuchen und vieles mehr.

Neben seinen Ergänzungen zu den bestehenden Funktionen von WF fügt "Dublin" auch weitere Dienste hinzu. Beispielsweise kann "Dublin" die Ausführung von Workflowinstanzen überwachen und jedes Fehlschlagen automatisch neu starten. Das Hauptziel von Microsoft mit "Dublin" ist klar: Die Bereitstellung einer nützlichen Gruppe von Tools und Infrastruktur für die Verwaltung und Überwachung von Workflowdiensten, die in IIS/WAS gehostet werden.

Verwenden eines Workflowdiensts in einer ASP.NET Anwendung

Es ist wahrscheinlich fair zu sagen, dass eine Mehrheit der .NET-Anwendungen ASP.NET verwenden. Wenn Sie den Workflow als Mainstream gestalten, bedeutet dies, DASS WF für ASP.NET Entwickler attraktiv ist.

In früheren Versionen von WF war die Workflowleistung für eine erhebliche Anzahl von ASP.NET Anwendungen nicht gut genug. Für die .NET Framework 4-Version haben die Designer von WF jedoch wichtige Teile der Technologie neu erstellt, wodurch die Leistung erheblich gesteigert wird. Diese Version macht zusammen mit der Einführung von "Dublin" WF-basierte Anwendungen – insbesondere Workflowdienste – eine lebensfähigere Option für ASP.NET-Entwickler. Abbildung 14 zeigt ein einfaches Bild davon, wie dies aussieht.

Abbildung 14: Die Geschäftslogik einer ASP.NET Anwendung kann als Workflowdienst

In diesem Szenario implementieren ASP.NET Seiten nur die Benutzeroberfläche der Anwendung. Die Logik wird vollständig in einem Workflowdienst implementiert. Für den Workflowdienst ist die ASP.NET Anwendung nur ein anderer Client, während der ASP.NET Anwendung, der Workflowdienst sieht wie jeder andere Dienst aus. Es muss nicht beachtet werden, dass dieser Dienst mit WF und WCF implementiert wird.

Aber auch hier ist die große Frage: Warum würden Sie dies tun? Warum schreiben Sie nicht einfach die Logik der ASP.NET Anwendung auf die übliche Weise? Was kauft WF (und WCF) sie? An diesem Punkt sind die meisten Antworten auf diese Fragen wahrscheinlich offensichtlich, aber sie sollten immer noch wiederholt werden:

• Anstatt die Logik der Anwendung auf viele verschiedene ASP.NET Seiten zu verteilen, kann diese Logik stattdessen in einem einzigen einheitlichen Workflow implementiert werden. Insbesondere für große Websites kann die Anwendung erheblich einfacher zu erstellen und zu verwalten sein.
• Anstatt explizit mit dem Zustand in der ASP.NET-Anwendung zu arbeiten, z. B. das Session-Objekt oder etwas anderes, kann der Entwickler die WF-Laufzeit verwenden, um dies zu tun. Die ASP.NET Anwendung muss nur einen Instanzbezeichner für jede Workflowinstanz nachverfolgen (höchstwahrscheinlich eine pro Benutzer), z. B. durch Speichern in einem Cookie. Wenn die Anwendung diesen Bezeichner für "Dublin" bereitstellt, wird die Workflowinstanz automatisch neu geladen. Es beginnt dann mit der Ausführung an der Stelle, an der sie unterbrochen wurde, wobei der gesamte Zustand wiederhergestellt wurde.
• Die anderen Vorteile von WF gelten auch, darunter einfachere Parallelität, integrierte Nachverfolgung, das Potenzial für wiederverwendbare Aktivitäten und die Möglichkeit, die Logik der Anwendung zu visualisieren.

Da ein Workflowdienst nicht an einen bestimmten Prozess auf einem bestimmten Computer gebunden ist, kann er über mehrere Dublin-Instanzen hinweg lastenausgleichen werden. Abbildung 15 zeigt ein Beispiel dafür, wie dies aussehen kann.

Abbildung 15: Eine replizierte ASP.NET Anwendung kann mehrere "Dublin"-Instanzen verwenden, um einen Workflowdienst auszuführen.

In diesem einfachen Szenario werden die Seiten einer ASP.NET-Anwendung auf drei IIS-Servercomputern repliziert. Während diese Seiten die Interaktion mit Benutzern verarbeiten, wird die Geschäftslogik der Anwendung als Workflowdienst implementiert, der mit "Dublin" ausgeführt wird. Zwei Instanzen der "Dublin"-Umgebung werden ausgeführt, jeweils auf einem eigenen Computer. Wenn die erste Anforderung eines Benutzers eingeht, leitet ein Lastenausgleichsmodul sie an die oberste IIS-Instanz weiter. Die ASP.NET Seite, die diese Anforderung verarbeitet, ruft einen Vorgang im Workflowdienst auf, der diesen Abschnitt der Geschäftslogik implementiert. Dies bewirkt, dass ein WF-Workflow in der Instanz "Dublin" auf dem obersten Computer in der Abbildung ausgeführt wird. Nachdem die relevanten Aktivitäten in diesem Workflow abgeschlossen wurden, kehrt der Aufruf zur ASP.NET Seite zurück, und der Workflow wird beibehalten.

Die zweite Anforderung des Benutzers wird an eine andere INSTANZ von IIS weitergeleitet. Die ASP.NET Seite auf diesem Computer ruft wiederum einen Vorgang im (beibehaltenen) Workflow auf einem anderen Computer als dem Computer auf, der ihre erste Anforderung verarbeitet hat. Dies ist kein Problem: "Dublin" lädt nur die Workflowinstanz aus dem Persistenzspeicher, den es mit seinem Mitserver teilt. Dieser neu geladene Workflowdienst behandelt dann die Anforderung des Benutzers und nimmt dort auf, wo er aufgehört hat.

Das Verständnis von WF (und WCF) erfordert dann das Erstellen von Logik in diesem neuen Stil einige Arbeit. Für einfache ASP.NET Anwendungen lohnt sich das Klettern dieser Lernkurve möglicherweise nicht den erforderlichen Aufwand. Jeder, der größere Webanwendungen mit .NET erstellt, sollte jedoch zumindest die Möglichkeit berücksichtigen, seine Logik als Workflowdienst zu erstellen.

Verwenden von Workflows in Clientanwendungen

Der Schwerpunkt liegt bisher ganz auf der Verwendung von WF zum Erstellen von Serveranwendungen. Obwohl die Technologie heute am häufigsten verwendet wird, kann WF auch für Clientanwendungen hilfreich sein. Ihre Skalierbarkeitsaspekte fügen in diesem Fall in der Regel nicht viel hinzu, da Code, der auf Clientcomputern ausgeführt wird, in der Regel nicht viele gleichzeitige Benutzer verarbeiten muss, aber WF kann weiterhin verwendet werden.

Denken Sie beispielsweise an eine Clientanwendung, die ihren Benutzer mit einer grafischen Benutzeroberfläche präsentiert, die mit Windows Forms oder Windows Presentation Foundation erstellt wurde. Die Anwendung verfügt wahrscheinlich über Ereignishandler, um die Mausklicks des Benutzers zu verarbeiten, und verbreitet möglicherweise seine Geschäftslogik über diese Ereignishandler. Dies ähnelt einer ASP.NET Anwendung, die ihre Logik über eine Gruppe von separaten Seiten verteilt, und sie kann dieselben Herausforderungen schaffen. Der Fluss der Anwendung kann z. B. schwer zu erkennen sein, und der Entwickler muss möglicherweise Überprüfungen einfügen, um sicherzustellen, dass die Dinge in der richtigen Reihenfolge ausgeführt werden. Genau wie bei einer ASP.NET Anwendung kann die Implementierung dieser Logik als einheitlicher WF-Workflow dazu beitragen, diese Bedenken zu beheben.

Andere Aspekte von WF können auch auf dem Client nützlich sein. Angenommen, die Anwendung muss mehrere Back-End-Webdienste parallel aufrufen, z. B. oder kann von der Nachverfolgung profitieren. Genau wie auf dem Server kann WF bei der Bewältigung dieser Herausforderungen helfen. Während die meisten WF-Anwendungen heute auf Servern ausgeführt werden, ist es wichtig zu erkennen, dass dies nicht die einzige Wahl ist.

Ein genauerer Blick: Die Technologie von Windows Workflow Foundation

Das Ziel dieser Übersicht ist es, Sie nicht zu einem WF-Entwickler zu machen. Dennoch kann das Wissen über die Technologie von WF bei der Entscheidung helfen, wann es sinnvoll ist, den Workflowweg auszuwählen. Dementsprechend betrachtet dieser Abschnitt einige der wichtigsten Teile von WF genauer.

Arten von Workflows

In .NET Framework 4 wählen WF-Entwickler in der Regel zwischen zwei verschiedenen Workflowstilen aus, indem Sie verschiedene äußerste Aktivitäten auswählen. Diese Aktivitäten sind:

• Sequenz: Führt Aktivitäten nacheinander aus. Die Sequenz kann If-Aktivitäten, While-Aktivitäten und andere Arten von Steuerungsfluss enthalten. Es ist jedoch nicht möglich, rückwärts zu gehen – die Ausführung muss immer vorwärts erfolgen.
• Flussdiagramm: Führt Aktivitäten nacheinander aus, z. B. eine Sequenz, ermöglicht aber auch die Rückkehr des Steuerelements zu einem früheren Schritt. Dieser flexiblere Ansatz, der in der .NET Framework 4-Version von WF neu ist, ist näher an der Funktionsweise realer Prozesse und der Art und Weise, wie die meisten von uns denken.

Während Sequenz- und Flussdiagramm als äußerste Aktivitäten in einem Workflow fungieren können, können sie auch innerhalb eines Workflows verwendet werden. Auf diese Weise können diese zusammengesetzten Aktivitäten beliebig geschachtelt werden.

In den ersten beiden Versionen enthielt WF auch eine weitere Option für die äußerste Aktivität eines Workflows namens "Zustandsautomat". Wie der Name bereits sagt, kann ein Entwickler explizit einen Zustandscomputer erstellen und dann externe Ereignisse auslösen, die Aktivitäten in diesem Zustandscomputer auslösen. WF in .NET Framework 4 ist jedoch eine große Änderung, die die meisten Aktivitäten in den früheren Versionen neu schreiben und einen neuen Designer erstellen musste. Aufgrund des Aufwands werden die Ersteller von WF nicht die Zustandsautomataktivität aus der ersten .NET Framework 4-Version bereitstellen. (Selbst die Ressourcen von Microsoft sind nicht beschränkt.) Dennoch sollte die neue Flussdiagrammaktivität viele der Situationen behandeln, die zuvor mithilfe des Zustandsautomaten erforderlich waren.

Die Basisaktivitätsbibliothek

Ein Workflow kann eine beliebige Gruppe von Aktivitäten enthalten, die ein Entwickler verwendet. Es ist beispielsweise völlig legal, dass ein Workflow nichts als benutzerdefinierte Aktivitäten enthält. Dennoch ist dies nicht sehr wahrscheinlich. In den meisten Fällen verwendet ein WF-Workflow mindestens einige der Elemente, die in der Basisaktivitätsbibliothek bereitgestellt werden. Zu den umfassenderen nützlichen BAL-Aktivitäten von WF im .NET Framework 4 gehören:

• Assign: assigns a value to a variable in the workflow.
• Kompensieren: bietet eine Möglichkeit zum Ausgleich, z. B. das Behandeln eines Problems, das in einer langfristigen Transaktion auftritt.
• DoWhile: führt eine Aktivität aus und überprüft dann eine Bedingung. Die Aktivität wird über und über ausgeführt, solange die Bedingung wahr ist.
• Flussdiagramm: gruppiert eine Reihe von Aktivitäten, die sequenziell ausgeführt werden, ermöglicht aber auch die Rückkehr zu einem früheren Schritt.
• ForEach: führt eine Aktivität für jedes Objekt in einer Auflistung aus.
• If: creates a branch of execution.
• Parallel: Führt mehrere Aktivitäten gleichzeitig aus.
• Persist: fordert die WF-Laufzeit explizit auf, den Workflow beizubehalten.
• Auswahl: Ermöglicht das Warten auf eine Reihe von Ereignissen, und führt dann nur die Aktivität aus, die dem ersten Ereignis zugeordnet ist.
• ReceiveMessage: empfängt eine Nachricht über WCF.
• SendMessage: sendet eine Nachricht über WCF.
• Sequenz: gruppiert eine Reihe von Aktivitäten, die sequenziell ausgeführt werden. Neben der Funktion als äußerste Aktivität eines Workflows ist Sequence auch innerhalb von Workflows nützlich. Beispielsweise kann eine While-Aktivität nur eine andere Aktivität enthalten. Wenn diese Aktivität Sequenz ist, kann ein Entwickler eine beliebige Anzahl von Aktivitäten innerhalb der While-Schleife ausführen.
• Switch: stellt eine multidirektionale Ausführungsverzweigung bereit.
• Auslösen: Löst eine Ausnahme aus.
• TryCatch: Ermöglicht das Erstellen eines Try/Catch-Blocks zum Behandeln von Ausnahmen.
• While: executes a single activity as as a condition as true.

Dies ist keine vollständige Liste – WF in .NET Framework 4 enthält mehr. Außerdem plant Microsoft, neue WF-Aktivitäten auf CodePlex, seiner Hostingwebsite für Open Source-Projekte, verfügbar zu machen. Suchen Sie kurz nach der .NET Framework 4-Version nach Aktivitäten, mit denen Workflows Datenbankabfragen und -updates ausgeben, PowerShell-Befehle ausführen und vieles mehr.

Wie in dieser Liste vorgeschlagen, spiegelt der BAL weitgehend die Funktionalität einer herkömmlichen allgemeinen Programmiersprache wider. Dies sollte nicht überraschend sein, da WF eine allgemeine Technologie sein soll. Wie in dieser Übersicht beschrieben wurde, kann der Ansatz, den sie benötigt – Aktivitäten, die von der WF-Laufzeit ausgeführt werden – manchmal das Leben für Anwendungsentwickler verbessern.

Workflow in .NET Framework 4

Version 4 von .NET Framework bringt erhebliche Änderungen an Windows Workflow Foundation mit sich. Die Aktivitäten im BAL wurden beispielsweise neu geschrieben, und einige neue wurden hinzugefügt. Dies bringt echte Vorteile – viele Workflows werden jetzt viel schneller ausgeführt, aber es bedeutet auch, dass Workflows, die mit früheren Versionen von WF erstellt wurden, nicht von der .NET 4-Version der WF-Laufzeit ausgeführt werden können. Diese älteren Workflows können weiterhin parallel zu .NET Framework 4-Workflows ausgeführt werden, die jedoch nicht entfernt werden müssen. Außerdem können Aktivitäten, die mit älteren Versionen von WF erstellt wurden, einschließlich vollständiger Workflows, in einer neuen Interop-Aktivität ausgeführt werden, die WF in .NET Framework 4 bereitstellt. Auf diese Weise können Logik aus älteren Workflows in neuen Workflows verwendet werden.

Zusammen mit einer besseren Leistung bringt diese neue Version von WF auch andere interessante Änderungen. Beispielsweise enthielten frühere Versionen von WF eine Codeaktivität, die beliebigen Code enthalten kann. Dadurch kann ein Entwickler ziemlich jede gewünschte Funktionalität zu einem Workflow hinzufügen, aber es war eine leicht unlegante Lösung. In .NET Framework 4 wurden die Ersteller von WF zum Schreiben benutzerdefinierter Aktivitäten erheblich vereinfacht, sodass die Codeaktivität entfernt wurde. Neue Funktionen werden jetzt als benutzerdefinierte Aktivität erstellt.

Die Änderungen in der .NET Framework 4-Version sind die wesentlichsten seit der ursprünglichen Darstellung von WF im Jahr 2006. Alle haben jedoch dasselbe Ziel: Entwickler können effektive Anwendungen mithilfe von Workflows einfacher erstellen.

Schlussfolgerung

Windows Workflow Foundation bietet für viele Anwendungen echte Vorteile. In den ersten Versionen hat WF hauptsächlich mit Softwareanbietern eine Akkordung getroffen. Diese ursprünglichen Inkarnationen der Technologie waren nützlich, aber sie waren nicht wirklich für die mainstream-Unternehmensnutzung geeignet. Mit .NET Framework 4 möchten die Ersteller von WF dies ändern.

Indem WF und WCF gut zusammenarbeiten, die Leistung von WF verbessern, einen besseren Workflow-Designer bereitstellen und einen umfassenden Hostprozess mit "Dublin" anbieten, macht Microsoft den Workflow für eine breitere Palette von Szenarien attraktiver. Seine Tage als spezialisierter Spieler im Windows-Anwendungsentwicklungsdrama zeichnen sich zu einem Ende. WF ist unterwegs, um die Bühne zu zentrieren.

Informationen zum Autor

David Chappell ist Principal von Chappell & Associates in San Francisco, Kalifornien. Durch sein Sprechen, Schreiben und Consulting hilft er Menschen auf der ganzen Welt, bessere Entscheidungen über neue Technologien zu verstehen, zu nutzen und zu treffen.