Verwendung des WWF für die ASP.NET-Programmentwicklung

Autor：Eve Cole Aktualisierungszeit：2009-06-30 16:01:52

Einführung

Mit WWF können Sie prozessorflussbasierte Workflows erstellen und diese in jeder Art von .NET-Anwendung bereitstellen. Darüber hinaus werden in diesem Artikel einige einzigartige Probleme erörtert, mit denen ASP.NET-Entwickler konfrontiert sind – Probleme, die durch die Verwendung von Workflows gelöst werden können, z. B. die Aufrechterhaltung des Status und der Seitennavigation.

Im September 2005 stellte Microsoft auf seiner alle zwei Jahre stattfindenden professionellen Entwicklerkonferenz die Windows Workflow Foundation (WWF, Windows Workflow Foundation) vor. Als eine der Säulen der WinFX-API bietet WWF Entwicklern ein gemeinsames Framework für die Entwicklung prozessgesteuerter und Workflow-zentrierter Anwendungen.

Derzeit versuchen einige Organisationen, ganze Geschäftsprozesse zu automatisieren; ihre Standardlösung besteht darin, ein Team von Entwicklern zusammenzustellen, um den entsprechenden Code zu entwickeln. Obwohl dieser Ansatz für diese Organisationen gut funktioniert, gibt es einige inhärente Probleme. Um dieses Problem im Detail zu verstehen, müssen Sie die grundlegenden Merkmale eines Workflows verstehen.

Ein Workflow ist im Wesentlichen eine Methode zur Archivierung der Aktivitäten, die mit der Erledigung einer Arbeitseinheit verbunden sind. Normalerweise „fließt“ die Arbeit während der Verarbeitung durch eine oder mehrere Aktivitäten. Diese Aktivitäten können von Maschinen oder Menschen ausgeführt werden und können so einfach sein wie das Definieren der Reihenfolge von Seiten in einer Internetanwendung oder so komplex wie die Verwaltung eines Dokuments oder Produkts, das von einer beliebigen Anzahl von Personen angezeigt, geändert und genehmigt werden muss. Komplex.

Da so viele Arbeitsabläufe die Beteiligung von Menschen ermöglichen müssen, kann ihre Fertigstellung lange dauern und von einigen Stunden bis hin zu Monaten oder länger reichen. Beispielsweise sind die am Prozess beteiligten Personen möglicherweise nicht verfügbar, nicht vor Ort oder mit anderen Aufgaben beschäftigt. Daher muss der Workflow in allen Phasen der Inaktivität aufrechterhalten werden können. Darüber hinaus können Prozesse, die unabhängig durch Codierung implementiert werden, für technisch nicht versierte Personen schwer zu verstehen und für Entwickler schwierig zu ändern sein. Dies und andere Faktoren sind genau das Ziel generischer Workflow-Frameworks wie Windows WF – die darauf abzielen, die Erstellung, Änderung und Verwaltung von Workflows zu vereinfachen – entweder durch die Bereitstellung einer visuellen Oberfläche oder durch die Definition eines gemeinsamen Satzes realisierter APIs.

Sie können WWF-Workflows in jeder Art von .NET-Anwendung platzieren – einschließlich Windows Forms, Konsolenanwendungen, Windows-Diensten und ASP.NET-Webanwendungen. Jeder Typ erfordert spezielle Überlegungen. Obwohl einige vorhandene Beispiele ausreichen, um zu veranschaulichen, wie Workflows in Windows Forms und Konsolenanwendungen gehostet werden, konzentriert sich dieser Artikel auf die Probleme, mit denen ASP.NET-Entwickler konfrontiert sind, die Workflows in ihre eigenen Anwendungen integrieren möchten.

Anmerkung des Autors: Der in diesem Artikel bereitgestellte Code wurde mit Windows WF Beta 1 und Visual Studio 2005 Beta 2 erstellt. Informationen zur Installation von Windows WF finden Sie unter www.windowsworkflow.net . Obwohl in diesem Artikel einige Grundlagen von Windows WF erläutert werden, stehen in diesem Bereich auch andere Ressourcen zur Verfügung. Ich gehe davon aus, dass der Leser zumindest ein wenig über Windows WF Bescheid weiß. Der Zweck dieses Artikels besteht darin, Windows WF und ASP.NET eingehend zu analysieren, anstatt Windows WF auf einer hohen Ebene zu diskutieren.

1. Windows WF- und MVC-Muster

Bei der Entwicklung einer ASP.NET-Anwendung können Sie WWF häufig durch die Implementierung eines Model-View-Controller (MVC)-Ansatzes nutzen. Im Wesentlichen besteht das Ziel von MVC darin, die Präsentationsschicht, die Anwendungslogik und die Anwendungsflusslogik zu trennen.

Dies zu verstehen ist bei der Entwicklung einer ASP.NET-Anwendung sehr hilfreich. Bitte ziehen Sie einen Helpdesk-Ticket-Workflow-Standort in Betracht. Angenommen, ein Geschäftsbenutzer initiiert diesen Workflow, indem er ein ASP.NET-Webformular ausfüllt und auf eine Schaltfläche zum Senden klickt. Als nächstes benachrichtigt der Server einen Mitarbeiter über eine Windows Forms-Anwendung und den Helpdesk, dass „ein neues Ticket verfügbar ist“. Der Helpdesk-Mitarbeiter wird dann das Problem bearbeiten und schließlich das Ticket schließen. Wenn Sie Windows WF verwenden, um dieses Workflow-Szenario zu entwickeln, können die gesamte Verarbeitungslogik und der gesamte Verarbeitungsablauf im Workflow selbst enthalten sein, und die ASP.NET-Anwendung muss diese Logik überhaupt nicht verstehen.

Diese Art von Veranstaltungsort liefert einige solide Beweise – die Trennung von Beschreibung und Logik ist eine gute Sache. Da dieser Prozess der Bearbeitung von Helpdesk-Anfragen so banal ist, besteht bei Verwendung von C#- oder VB.NET-Code zur Implementierung dieser Logik in mehreren verschiedenen .NET-Anwendungen die Gefahr, dass der Code dupliziert wird oder, schlimmer noch, völlig anderer Code verwendet wird auf unterschiedliche Implementierungen desselben Geschäftsprozesses. Wenn Sie jedoch WWF verwenden, um diesen Prozess zu implementieren, müssen Anwendungsentwickler, die diesen Prozess benötigen, nur die Schritte an einer Stelle ändern – dem Workflow selbst –, ohne sich um die Änderung der Anwendungslogik kümmern zu müssen. Die Codeduplizierung und die Implementierung dieses Prozesses können durch die Verwendung von Windows WF vereinfacht werden.

Bei der Implementierung einer MVC-Architektur in ASP.NET mit Windows WF sollten Entwickler versuchen, von der Anwendung unabhängige Workflows zu erstellen – während der Workflow weiterhin in der Anwendung gehostet wird. Dadurch bleibt die Logik unabhängig von der Beschreibung und ein hohes Maß an Unabhängigkeit zwischen der Abfolge der Arbeitsschritte und dem Seitenfluss in der Webanwendung bleibt erhalten.

Ein neuer WWF-Entwickler könnte versuchen, einen Workflow mit einer festen Anzahl von Aktivitäten in einer bestimmten Reihenfolge zu entwickeln und dann eine Reihe von ASP.NET-Webformularen zu entwickeln, die in derselben Reihenfolge von einem Formular zum anderen übergehen. Obwohl dies logisch erscheint, ist es leider sehr unproduktiv, da Sie die Workflow-Logik erneut implementieren müssen. Webseite X muss nicht wissen, ob sie zu Seite Y oder Seite Z gehen muss, um diesen Workflow-Schritt korrekt umzusetzen. Stattdessen sollte der Workflow (das Modell) ASP.NET (dem Controller) mitteilen, was als Nächstes zu tun ist. ASP.NET sollte dann entscheiden, welche Seite angezeigt werden soll. Auf diese Weise muss jede Seite kaum den gesamten Prozess verstehen; sie muss lediglich wissen, wie eine andere Aktivität ausgeführt wird, und der Workflow kümmert sich darum, wie die Seite von einem Ort zum anderen fließt. Diese Trennung gibt Entwicklern ein hohes Maß an Flexibilität beim Umgang mit dem Seitenfluss. Wenn Sie beispielsweise die Reihenfolge ändern möchten, in der die Seiten angezeigt werden, können Sie dies problemlos im Workflow tun, ohne eine einzige Codezeile in der ASP.NET-Anwendung zu ändern.

2. Ein einfaches Workflow-MVC-Beispiel

Um diese Idee zu veranschaulichen, zeige ich Ihnen eine einfache ASP.NET-Anwendung und einen einfachen Workflow. Dieser stark vereinfachte Arbeitsablauf beschreibt einen Prozess, der einige private Informationen von einer externen Anwendung sammelt und diese dann anzeigt. Die Schritte sind wie folgt:

1. Rufen Sie eine Methode auf – das bedeutet, dass dieser Workflow die InvokeMethod-Aktivität verwendet (siehe Abbildung 1).

2. Warten Sie, bis ein Ereignis ausgelöst wird. In diesem Schritt verwendet der Workflow die EventSink-Aktivität.

3. Erhalten Sie über einen ähnlichen Anruf eine E-Mail-Adresse vom Gastgeber.

4. Auf ein Ereignis zu warten bedeutet, eine Adresse zu erhalten.

5. Nach Erhalt des Namens und der E-Mail-Adresse startet der Workflow eine InvokeMethod-Aktivität, um die persönlichen Informationen an die aufrufende Anwendung zu senden. In einer realen Situation ist dieser letzte Schritt nicht sehr wichtig. Wahrscheinlicher ist, dass Sie einen Webdienst aufrufen, um die Daten an ein anderes System zu senden oder sie in eine Datenbank zu stellen.

Abbildung 1. Beispielworkflow: Dieser Workflow beschreibt den impliziten Prozess in einer ASP.NET-Beispielanwendung

Um diesen Workflow in ASP.NET zu implementieren, benötigen Sie eine Seite zum Sammeln von Personennamen, eine Seite zum Sammeln von E-Mail-Adressen und eine Seite zum Anzeigen persönlicher Daten. Denken Sie daran, dass das Datenanmeldeformular keine Ahnung haben sollte, was davor oder danach passiert ist. Das Gleiche gilt für Anzeigeseiten. Die ASP.NET-Anwendung muss jedoch wissen, welche Seite dem Benutzer angezeigt werden soll. Dies ist der Zweck der Einführung von Controllern. In diesem Beispiel wird ein HTTP-Handler verwendet, um die Lösung zu implementieren. Dieser benutzerdefinierte Handler namens WorkflowController ist für die folgenden Aufgaben verantwortlich:

· Erhalten Sie einen Verweis auf die Zeit, zu der der Workflow ausgeführt wird.

· Besorgen Sie sich einen Verweis auf eine vorhandene Workflow-Instanz oder starten Sie eine neue Workflow-Instanz (dies hängt davon ab, ob eine Workflow-Instanz gestartet wurde).

·Stellen Sie die Kommunikation zwischen Controller und Workflow her.

·Verarbeiten Sie Ereignisse aus diesem Workflow.

·Teilen Sie ASP.NET mit, welche Seite angezeigt werden muss, je nachdem, welche Ebene im Workflow gerade ausgeführt wird.

Wie Sie gesehen haben, übernimmt dieser benutzerdefinierte Handler im Wesentlichen die gesamte Arbeit im Zusammenhang mit WWF und Seitensteuerung – er sorgt dafür, dass einzelne ASP.NET-Seiten über die im Hintergrund ablaufenden Aktionen „still“ bleiben. Das Einzige, worüber sich ein Webformular kümmern muss, ist die Ausführung der spezifischen Aufgabe und die Weitergabe der erforderlichen Daten an den Controller.

Standardmäßig arbeitet WWF in einem asynchronen Modell. Dies bedeutet, dass die Kontrolle sofort an den Host zurückgegeben wird, wenn ein Anwendungshost eine Workflow-Instanz startet, während der Workflow weiterhin in einem anderen Thread ausgeführt wird. Dies kann in einer Windows Forms-Anwendung nützlich sein, wo eine kontinuierliche Reaktionsfähigkeit der Benutzeroberfläche äußerst wünschenswert ist. Durch die Verwendung dieses asynchronen Modells kann der Workflow im Hintergrund ausgeführt werden, während der Benutzer die Anwendung weiterhin bedienen kann. In einer Webanwendung ist ein solches Verhalten jedoch möglicherweise nicht zu erwarten, da die Kontrolle normalerweise erst an den Benutzer zurückgegeben wird, nachdem der Server eine Arbeitseinheit abgeschlossen hat. Dies ist genau die Verkörperung der Skalierbarkeit von Windows WF. In Windows WF können Entwickler „Laufzeitdienste“ verwenden oder erstellen, um die Workflow-Laufzeit zu überwachen und sogar zu ändern. Beispiele hierfür sind:

· Persistenzdienst – speichert den Workflow-Status zwischen Ausführungs- und Leerlaufzeiten

· Ablaufverfolgungsdienst – gibt Informationen über die Workflow-Ausführung auf einigen Medien aus

· Transaktionsdienst – hilft bei der Aufrechterhaltung der Datenintegrität während der Workflow-Ausführung

Darüber hinaus ermöglichen Threading-Dienste Entwicklern die Steuerung, wie Workflow-Instanzen ausgeführt werden werden ausgeführt. Wie bereits erwähnt, führt die Workflow-Laufzeitumgebung die Instanz standardmäßig asynchron in einem vom Host unabhängigen Thread aus. Da dies jedoch höchstwahrscheinlich nicht das ist, was ASP.NET erwartet, müssen Sie den Standard-Workflow-Thread-Dienst austauschen. Glücklicherweise hat Microsoft eine Lösung dafür bereitgestellt: ASPNetThreadingService. Um diese Änderung zu implementieren, können Sie entweder ASPNetThreadingService durch manuelle Codierung zum Workflow-Laufzeitdienst hinzufügen oder diese Aufgabe in der Datei web.config ausführen. Die Beispielanwendung in diesem Artikel verwendet den Konfigurationsmodus. Fügen Sie im Workflow-Runtime/Services-Abschnitt von web.config (siehe Listing 1) eine Zeile ähnlich der folgenden hinzu:

3. Implementieren Sie die Controller-Logik.

Als Nächstes müssen Sie die Controller-Logik mit einem HTTP-Prozessor implementieren. Um diesen Controller zu erstellen, müssen Sie lediglich eine Klasse namens WorkflowController-Handler erstellen, die die IHttp-Handler-Schnittstelle implementiert. Bisher haben Sie nichts Besonderes an Windows WF gesehen – dies ist eine spezifische Funktion von ASP.NET (lesen Sie weiter).

In dieser WorkflowController-Prozessorklasse verarbeitet die IHttp-Prozessorschnittstellenmethode namens ProcessRequest eine Webanforderung von der ASP.NET-Anwendung. Hier müssen Sie einen Verweis auf eine statische Workflow-Laufzeitinstanz abrufen, Ereignishandler für den Workflow erstellen und die Workflow-Ausführung initiieren. Bevor Sie eine Workflow-Instanz starten, müssen Sie prüfen, ob der Abfragezeichenfolgenwert der Anforderung eine GUID enthält, die eine Workflow-Instanz-ID darstellt. Wenn diese ID vorhanden ist, wissen Sie, dass bereits eine Instanz ausgeführt wird, sodass Sie einen Verweis auf diese Instanz erhalten und mit der Ausführung fortfahren können. Wenn diese ID nicht vorhanden ist, müssen Sie eine neue Instanz erstellen und den Ausführungsprozess starten, indem Sie die Methode „Workflow starten“ zur Workflow-Laufzeit aufrufen.

Nachdem eine Instanz gestartet wurde, verwalten Ereignishandler die Kommunikation innerhalb und außerhalb des Workflows. Da der Zweck dieses Artikels nicht darin besteht, lokale Kommunikationsdienste zu diskutieren, werde ich dieses Thema hier nicht im Detail diskutieren, sondern seine Implementierungstechniken auf hoher Ebene analysieren und erneut diskutieren, wie dies in einer ASP.NET-Anwendung funktioniert. Um die Kommunikationsverarbeitung zu erleichtern, benötigen Sie mehrere .NET-Schnittstellen, die zum Beschreiben von Informationen innerhalb und außerhalb des Workflows und Hosts verwendet werden. Sie finden diese im Quellcode des WorkflowClassLibrary-Projekts, der diesem Artikel beigefügt ist. Sie finden auch Klassen, die diese Schnittstellen und die entsprechende Funktionalität implementieren, die zur Implementierung des Workflow-Mechanismus erforderlich ist.

Werfen wir noch einmal einen kurzen Blick auf die Datei web.config. Beachten Sie, dass wir neben dem zuvor besprochenen ASPNetThreadingService-Element drei Elemente zur Beschreibung der Kommunikationsdienstklasse verwendet haben:

<add type="Workflow.RuntimeServices.GetNameService,
Workflow.Library, Version=1.0.0.0, Kultur=neutral,
PublicKeyToken=c4620ae819b5257e"/>
＜add type="Workflow.RuntimeServices.GetEmailService,
Workflow.Library, Version=1.0.0.0, Kultur=neutral,
PublicKeyToken=c4620ae819b5257e"/>
＜add type="Workflow.RuntimeServices.SendDataService,
Workflow.Library, Version=1.0.0.0, Kultur=neutral,
PublicKeyToken=c4620ae819b5257e"/>

Hier gibt es auch ein Element, das die Workflow-Laufzeitbibliothek anweist, den SqlStatePersistenceService zu verwenden. Dieser zusätzliche Dienst speichert die Persistenz eines Workflow-Status in einer SQL Server-Datenbank zwischen Seitenanforderungen. Sie müssen diese Datenbank manuell erstellen Vorab, aber Microsoft stellt hierfür ein SQL-Skript zur Verfügung. Sie finden es im Ordner C:WINDOWSMicrosoft.NETFrameworkv2.0.50215Windows Workflow FoundationSQL. Sie können diese Dienste programmgesteuert hinzufügen , aber Sie können es auch in der Konfiguration implementieren, was die Menge des zu schreibenden Codes erheblich reduziert und Flexibilität bietet – selbst nachdem der Code erstellt wurde. Es gibt eine Zeile in der Konfiguration, die ein HttpModule hinzufügt – das die Windows WF-Laufzeit unterstützt In ASP.NET gibt es auch eine Zeile, die den zuvor besprochenen HTTP-Handler-Controller festlegt.

Zusammenfassend lässt sich sagen, dass Windows WF eine äußerst benutzerfreundliche Funktion bietet Erweiterbares Framework für Entwickler zur Entwicklung von Workflow-basierten Anwendungen. Sofern Sie kein Technologiedienstleister oder ISV sind, muss Software Geschäfts- und Betriebsprozesse bereitstellen können Entwickler den Entwicklungsprozess einfach und flexibel gestalten.