Share via

BizTalk Server 2006 oder WF? Auswählen des richtigen Workflowtools für Ihr Projekt

  • Artikel

Kent Brown

twentysix New York (www.26ny.com)

November 2007

Überarbeitet im Februar 2008

Gilt für:

   Microsoft BizTalk Server 2006

   Windows Workflow Foundation

Zusammenfassung: Dieser Artikel enthält Anleitungen für die Auswahl zwischen Microsoft BizTalk Server 2006 und Windows Workflow Foundation in einer Vielzahl von Anwendungs- und Unternehmensintegrationsworkflowszenarien. (16 gedruckte Seiten)

Inhalte

Einführung

Prozess für die Auswahl des richtigen Workflowtools

Allgemeine Workflowszenarien

Alles auf dem Host

Workflow-Technology Empfehlungen

Future-Proofing

Zusammenfassung

Nachtrag

Danksagungen

Weitere Informationen

Einführung

Der Workflow ist in alltäglichen Geschäftsprozessen allgegenwärtig, sodass ein häufiges Bedürfnis darin besteht, Programmiertools zu finden, die das Erstellen von Workflowlösungen direkt unterstützen. Microsoft BizTalk Server 2006 und Windows Workflow Foundation (WF) sind die beiden primären Tools von Microsoft für die Programmierung von Workflowlösungen. Aufgrund der offensichtlichen Überschneidungen zwischen ihnen haben viele Architekten und Entwickler jedoch Schwierigkeiten zu entscheiden, welche Workflowtechnologie für ihre Zwecke sinnvoll ist.

Dies gilt insbesondere angesichts der Tatsache, dass WF eindeutig als die bevorzugte Workflowtechnologie für die Zukunft identifiziert wurde, während BizTalk Server 2006 immer noch das Premium-Serverprodukt für die Unternehmensintegration ist. Bis BizTalk Server Orchestrierung WF vollständig unterstützt, müssen Architekten und Entwickler sorgfältig auswählen, welche Technologie investiert werden soll.

Eine der Herausforderungen bei der Auswahl der richtigen Technologie für die Implementierung von Workflows besteht darin, dass Workflow viele Dinge bedeuten kann – unter anderem:

  • Fluss von Ui-Bildschirmen, mit denen ein Benutzer interagiert, um eine Aufgabe auszuführen.
  • Ablauf der Geschäftslogik innerhalb einer Anwendung oder eines Diensts.
  • Interaktion mehrerer Menschen, um einen Geschäftsprozess abzuschließen.
  • Koordination mehrerer Nachrichtenaustausche zwischen Systemen zur Verarbeitung einer Geschäftstransaktion.
  • Koordination der Schritte zum Extrahieren, Transformieren und Laden von ETL-Daten in eine Datenbank.

Obwohl das Spektrum der Workflowszenarien breit ist, ist es hilfreich, sie in vier allgemeine Kategorien zu gruppieren: Menschlicher Workflow, Anwendungsworkflow, Unternehmensintegrationsworkflow und Datenintegration Workflow.

Von den vier Haupt-Workflowkategorien sind Anwendungsworkflow und Unternehmensintegrationsworkflow die beiden Bereiche, in denen die Auswahl einer Technologie am schwierigsten ist. Die Szenarien für den menschlichen Workflow und Datenintegration Workflow sind aus Sicht der Toolsauswahl recht einfach. Der menschliche Workflow erfordert eine Benutzeroberfläche und ist häufig dokumentorientiert, sodass Microsoft Office SharePoint Server 2007 die empfohlene Plattform zum Erstellen von Lösungen für den menschlichen Workflow ist. Microsoft SQL Server Integration Services (SSIS) ist das empfohlene Tool für Datenintegration Szenarien.

Dieser Artikel enthält Anleitungen für die Auswahl zwischen BizTalk Server 2006 und WF in Anwendungsworkflow- und Enterprise Integration Workflow-Szenarien.

Die BizTalk Server-Orchestrierungs-Engine

Die BizTalk Server-Orchestrierungs-Engine ist seit jeher eines der überzeugenden Features von BizTalk Server. Als es eingeführt wurde, war es das beste Tool, das von Microsoft für die Workflow-zentrierte Programmierung verfügbar war. BizTalk Server-Orchestrierung bietet eine visuelle Programmierumgebung für die Entwicklung von Komponenten, um komplexe, mehrstufige Nachrichtenflüsse zu steuern, um eine bestimmte Geschäftstransaktion abzuschließen.

Die BizTalk Server Orchestrierungscodeartefakte ähneln stark den Flussdiagrammen oder UML-Aktivitätsdiagrammen (Unified Modeling Language), die ein Business Analyst zur Dokumentation eines Geschäftsprozesses erstellen kann. Diese Artefakte können dann in der Orchestrierungs-Engine-Runtime kompiliert und ausgeführt werden, die Dienste wie lang andauernde Transaktionen und Kompensation, Dauerhaftigkeit, Fehlertoleranz und Notfallwiederherstellung bereitstellt, die für die Erstellung von Systemen entscheidend sind, die unternehmenskritische Geschäftstransaktionen automatisieren.

Eine Workflow-Grundlage für die Zukunft

Obwohl es unterschiedliche Kategorien von Workflowszenarien gibt, gibt es aus Programmiersicht genügend Gemeinsamkeiten zwischen den Szenarien, um zu versuchen, ein gemeinsames Framework für die Workflowentwicklung zu schaffen. Die Orchestrierungs-Engine in BizTalk Server ist leistungsstark, wurde aber nie für die Verwendung außerhalb von BizTalk Server entwickelt. Daher ist es nicht möglich, BizTalk Server Orchestrierung effektiv für die anderen Workflowkategorien zu verwenden.

WF, das in Microsoft .NET Framework 3.0 veröffentlicht wird, führt ein visuelles, workfloworientiertes Programmiermodell in die .NET Framework ein, das so konzipiert ist, dass es allgemein und erweiterbar ist, um in Zukunft in allen workflowbezogenen Szenarien auf der Windows-Plattform verwendet zu werden. Das Team, das WF erstellt hat, konnte die besten Konzepte der BizTalk Server Orchestrierungs-Engine übernehmen, die Anforderungen für den breiteren Bereich von Workflowszenarien berücksichtigen und ein Framework entwerfen, das flexibel genug ist, um sie alle zu unterstützen.

Als Beweis für die Flexibilität von WF verwendet Microsoft Office SharePoint Server 2007 es zum Implementieren von Human Workflow-Lösungen. Die Absicht besteht darin, dass BPM-Drittanbieter ihre Lösungen auch auf WF aufbauen, anstatt eigene proprietäre Workflow-Engines zu erstellen. Mehrere Anbieter haben dies bereits getan. Einzelne Entwickler können WF auch verwenden, um benutzerdefinierte Anwendungsworkflows in .NET Framework Anwendungen zu implementieren. Der Plan sieht auch vor, dass eine zukünftige Version von BizTalk Server die Orchestrierungs-Engine in WF für die Implementierung von Enterprise Integration Workflow-Lösungen implementieren soll.

Abbildung 1. Verwenden des richtigen Workflowtools: BizTalk Server 2006 im Vergleich zu WF

Prozess für die Auswahl des richtigen Workflowtools

Unsere Methode zur Unterstützung der Entscheidung, welches Workflowtool zu Ihrem Projekt passt, besteht darin, die gängigsten Workflowszenarien zu definieren, damit Sie das Szenario oder die Kombination von Szenarien bestimmen können, die am besten zu Ihrem Projekt passen. Anschließend geben wir für jedes Szenario eine spezifische Anleitung, welches Tool – BizTalk Server 2006 oder WF – am besten geeignet ist und warum. Darüber hinaus verwenden wir das APIO-Modell (Application Platform Infrastructure Optimization) – ein Modell zur Bewertung der Reife der Anwendungsplattform und der Entwicklungsfunktionen eines organization –, um organization spezifische Anleitungen in den Szenarien bereitzustellen, in denen beide Tools effektiv verwendet werden können. Schließlich sehen wir uns die Roadmap für BizTalk Server 2006 und WF an, damit Sie die besten Entscheidungen treffen können, um die Anwendungen, die Sie heute erstellen, zukunftssicher zu machen.

Allgemeine Workflowszenarien

Auch nachdem wir unseren Bereich auf die Kategorien "Anwendung" und "Unternehmensintegration" des Workflows festgelegt haben, gibt es noch eine vielzahl von Workflowszenarien, die berücksichtigt werden müssen. Wie Abbildung 2 zeigt, befinden sich auf einer Seite des Spektrums Szenarien, in denen WF eindeutig die richtige Wahl ist. Ein Beispiel hierfür ist die Workflowfunktion innerhalb eines ISV-Produkts (Independent Software Vendor), bei dem die Lizenzierungskosten und die Komplexität der Bereitstellung von BizTalk Server 2006 unerschwinglich wären. In diesem Szenario sind Sie als ISV im Geschäft, kommerzielle Software zu erstellen, und der zusätzliche Programmieraufwand, der erforderlich ist, um WF lizenzfrei zu hosten, ist eine angemessene Investition.

Abbildung 2. Integrations- und Workflowkontinuum

Auf der anderen Seite des Spektrums sind Enterprise Integration-Lösungen, die innerhalb einer IT-Abteilung eines Unternehmens erstellt werden, wobei eindeutig BizTalk Server 2006 die richtige Wahl ist. In diesem Szenario möchten Sie sich auf die Gewinnung von Geschäftswert konzentrieren, anstatt in den Aufbau der "Sanitäranlagen" zu investieren, um Ihre Lösung skalierbar, zuverlässig und verwaltbar zu machen. Die Lizenzierungskosten von BizTalk Server 2006 lohnen sich also aufgrund dessen, was es bietet.

Die meisten Projekte liegen irgendwo zwischen diesen beiden Enden des Spektrums. Im Folgenden finden Sie einige häufige Szenarien, in denen die Anforderungen eine Workflowlösung diktieren:

  • UI-Seitencontroller – Eine häufige Anforderung in komplexen Anwendungen besteht darin, die Bildschirmnavigation der Benutzeroberfläche gemäß den Geschäftsregeln des jeweiligen Anwendungsfalls zu erzwingen, der implementiert wird. Das einfachste Beispiel ist ein Assistent, der den Benutzer durch einen vorgeschriebenen Satz von Bildschirmen führt, um eine Aufgabe auszuführen. Häufig handelt es sich um ein komplexeres Diagramm der Bildschirmnavigationsmöglichkeiten, die auf den Aktionen des Benutzers und dem Zustand der Daten basieren.
    Das MVC-Muster (Model-view-controller) ist die klassische Technik zum Abrufen dieser Navigationslogik aus den Formularen selbst, sodass sie einfacher und in verschiedenen Anwendungsfällen wiederverwendbar sind. Der Controller im MVC-Muster ist tatsächlich ein Workflow oder Zustandsautomat. Daher ist es natürlich, bei der Implementierung dieser Arten von Anwendungen nach einem Workflowtool zu suchen.
  • Geschäftslogik mit langer Laufzeit: Wenn viele Schritte erforderlich sind, um eine Geschäftstransaktion abzuschließen, muss der Benutzer möglicherweise mitten im Prozess anhalten oder auf Aktionen von anderen Benutzern oder Systemen warten, bevor er fortfahren kann. Die Möglichkeit, einen Prozess vorübergehend anzuhalten (oder "ruhen") und ihn dann basierend auf externen Ereignissen neu zu starten, ist für die Idee des Workflows von zentraler Bedeutung. Ohne eine Workflow-Engine sind Entwickler gezwungen, die Mechanismen zum Speichern des Zustands eines unvollständigen Prozesses und zum Abrufen dieses Zustands manuell zu entwerfen und zu programmieren, wenn der Prozess fortgesetzt wird. Mit einer gut gestalteten Workflow-Engine wird diese Funktion nativ unterstützt, ohne dass zusätzliche Arbeit für die Entwickler erforderlich ist.
  • Dynamisch aktualisierbarer Prozessfluss: Während es zunächst möglich erscheint, Geschäftsprozesse in klar definierte sequenzielle Schritte zu kodifizieren, müssen Menschen den Flow im Midstream häufig ändern, um reale Situationen zu berücksichtigen. In einem Spesengenehmigungsprozess kann der Vorgesetzte des Mitarbeiters, der die Spesenabrechnung übermittelt hat, der Standardmäßig genehmigende Person sein. Der Vorgesetzte kann sich jedoch entscheiden, die Aufgabe an eine Sekretärin zu delegieren (z. B. weil der Manager auf dem Weg zum Golfspielen ist) oder die Genehmigung an einen Vorgesetzten zu eskalieren (z. B. weil der Manager die Richtlinie für einen bestimmten Aufwand nicht sicher ist). Dem Benutzer zu erlauben, den Flow zu aktualisieren, ist oft einfacher als der Versuch, jede mögliche Permutation des Flows im Voraus zu antizipieren.
  • Abstraktion von Regeln aus der Geschäftslogik: In diesem Szenario ist es Ihr Ziel, die Geschäftsregeln von anderen Geschäftslogiken zu trennen. Ein gutes Beispiel sind Formularvalidierungsregeln. In einem Hypothekenantragsprogramm kann das Kreditantragsformular einen Satz von Feldvalidierungsregeln enthalten, bevor der Benutzer die Schaltfläche Absenden drücken kann, um einen Kreditantrag zu übermitteln. Wenn dasselbe Formular vom Kreditbeauftragten verwendet wird, um den Kredit zu überprüfen und zu genehmigen, sind zusätzliche Validierungsregeln erforderlich, da es sich in einer anderen Phase des Prozesses befindet.
    Durch die separate Implementierung der Validierungsregeln vom Formular wird es einfacher, das Formular in verschiedenen Szenarien wiederzuverwenden und die entsprechenden Validierungsregeln zu erzwingen, indem einfach der entsprechende Satz von Regeln für dieses Szenario ausgewertet wird.
  • Webdienstaggregator: Anwendungen müssen häufig Daten aus verschiedenen Webdiensten aggregieren. In vielen Situationen kann und sollte die Aggregationslogik selbst aus der Anwendung extrahiert und als eigenständiger Dienst verfügbar gemacht werden, der von anderen Anwendungen wiederverwendet werden kann. Diese Dienste werden häufig als zusammengesetzte Webdienste bezeichnet und sind ein wichtiges Element einer ausgereiften dienstorientierten Architektur. Das Webdienst-Aggregatorszenario ist in der Regel synchron und kurz ausgeführt.
  • Lang laufender Geschäftsprozess: Das Szenario für einen lang andauernden Geschäftsprozess wird in diesem Artikel verwendet, um serverbasierte Prozesse zu bestimmen, die mehrere Anwendungen miteinander integrieren, während Geschäftslogik für Logik innerhalb einer einzelnen Anwendung verwendet wird. Die Anforderungen an diese serverbasierten lang laufenden Geschäftsprozesse für Multithreading, asynchrones Verhalten, Persistenz des Prozesszustands, Korrelation von Nachrichten zu Prozessinstanzen, Skalierbarkeit, Zuverlässigkeit, Transaktionsintegrität usw. sind viel höher als für Geschäftslogik innerhalb einer Anwendung.
  • Business-to-Business-Prozess (B2B)-Prozess: Das B2B-Prozessszenario entspricht im Wesentlichen dem Szenario für einen lang andauernden Geschäftsprozess, mit der Ausnahme, dass das erste Szenario zusätzlich zu internen Anwendungen zwischen Organisationen erfolgt. Die Sicherheitsanforderungen sind daher von größter Bedeutung. Darüber hinaus haben Sie noch weniger Kontrolle über das spezifische Datenformat und das Transportprotokoll, da diese möglicherweise von Ihrem Geschäftspartner vorgegeben werden; Daher benötigen Sie die Möglichkeit, eine breite Palette von Formaten und Protokollen zu unterstützen und die Konfiguration der spezifischen Austauschvorgänge für eine große Anzahl von Partnern zu unterstützen.
  • Abstraktion von Regeln aus Geschäftsprozessen: Ähnlich wie das Szenario Abstraktion von Regeln aus der Geschäftslogik gilt dieses Szenario, wenn Sie die Geschäftsregeln vom Standard Code im Szenario für lange Geschäftsprozesse und im B2B-Prozessszenario trennen möchten. Dieses Szenario erfordert ein höheres Maß an Leistung und Skalierbarkeit. Außerdem werden wahrscheinlich Tools benötigt, damit Nichtprogrammierer die Regeln anzeigen und bearbeiten können.
  • Enterprise Rule Repository: In diesem Szenario besteht das Ziel darin, ein zentrales Repository für freigegebene Regeln zu erstellen, das von allen Anwendungen im Unternehmen aufgerufen werden kann. Dies bietet Konsistenz für alle Anwendungen in einer organization für die Anwendung wichtiger Geschäftsregeln. Ähnlich wie beim Szenario Abstraktion von Regeln aus Geschäftsprozessen erfordert dieses Szenario eine hohe Skalierbarkeit und Tools, damit Nichtprogrammierer die Regeln anzeigen und bearbeiten können. Darüber hinaus erfordert dieses Szenario, dass das Regelrepository als eigene Entität im Unternehmen vorhanden sein kann, mit einem eigenen Hostingmechanismus, der von der Workflow-Engine getrennt ist, und mit Komponenten oder APIs zum Ausführen der Regeln aus verschiedenen Anwendungen.
  • Enterprise Service Bus (ESB)/Message Broker: Viele Organisationen wünschen sich eine standardisierte Kommunikationsinfrastruktur für alle Dienste. Die beiden gängigsten Topologien für diese Infrastruktur sind der ESB und der Nachrichtenbroker. Veröffentlichen/Abonnieren von Messaging und Themenbasisrouting sind häufig erwartete Features dieser Infrastruktur.

Optimierungsmodell der Anwendungsplattforminfrastruktur

In einigen Workflowszenarien erfüllen sowohl BizTalk Server 2006 als auch WF die technischen Anforderungen zufriedenstellend. Für diese Szenarien ist es erforderlich, die Lösung den Anforderungen der spezifischen organization anzupassen, um die richtige Workflow-Technologie zu wählen. Für die Zwecke der Empfehlungen, die für Ihre jeweilige organization gelten, verwenden wir das APIO-Modell (Application Platform Infrastructure Optimization), wie in Abbildung 3 dargestellt.

Abbildung 3. APIO-Modell (Application Platform Infrastructure Optimization)

Das APIO-Modell ist ein Verfahren zum Profilieren der Reife eines organization in Bezug auf die Anwendungsinfrastruktur, die Architektur und die Entwicklungsmethoden. Das Ziel dieses Modells besteht darin, Organisationen einen Weg zu geben, um ihre Agilität bei der Bereitstellung von IT-Lösungen zu optimieren, um die Anforderungen des Unternehmens zu erfüllen.

Das APIO-Modell verwendet die folgenden vier Profile der Reife eines organization:

  • Basic: Organisationen behandeln Software als Kosten. Sie verfügen über weitgehend isolierte Anwendungen mit wenig Integration oder Wiederverwendung. Die Anwendungen, über die sie verfügen, können sich auf einer Vielzahl von Plattformen befinden. Sie verfügen nicht über einheitliche Standards für Infrastruktur- oder Entwicklungstechniken; sie haben keine konsistente architektonische Vision.
  • Standardisiert: Organisationen behandeln Software immer noch als Kosten, aber sie haben Schritte unternommen, um die Effizienz zu verbessern. Sie haben eine architektonische Vision und versuchen, Möglichkeiten zur Wiederverwendung zu berücksichtigen. Sie haben begonnen, einige Anwendungen zu integrieren, aber es handelt sich meist um Punkt-zu-Punkt-Integrationen.
  • Erweitert: Organisationen behandeln Software als Geschäftsaktivierer. Sie haben engagierte Architekten und eine klare architektonische Vision. Sie verfügen über viele Dienste und erzielen ein hohes Maß an Wiederverwendung. Alle zentralen Geschäftsprozesse werden automatisiert und überwacht. Sie verwenden eine zentralisierte, gepackte Integrationsplattform.
  • Dynamisch: Organisationen behandeln Software als strategische Ressource. Sie haben eine sehr ausgereifte SOA in Vision und Implementierung. Sie verfügen über klare Prozesse für die dynamische Versionsverwaltung und erneute Bereitstellung von Diensten. Die kann sich schnell an Geschäftliche Anforderungen anpassen und kann schnell in neue Geschäftspartner integriert werden.

Es ist nicht nur der Ort, an dem Sie sich befinden, sondern auch, wo Sie hingehen

Ein wenig implizit im APIO-Modell ist die Vorstellung, dass jeder organization zum dynamischen Profil wechseln möchte. In Der Realität hängt es von der Art des Unternehmens und der Philosophie des Managements in Bezug auf Technologie ab. Einige Unternehmen sind möglicherweise vollständig zufrieden, um im Profil "Basic" oder "Standardized" zu bleiben.

Sie sollten das aktuelle Profil sowie die kurzfristigen und langfristigen Ziele berücksichtigen, wobei das kurzfristige Ziel das wichtigste ist. Ein organization im Profil "Basic" mit dem Wunsch, schließlich im dynamischen Profil zu sein, kann sich mit Bedacht dafür entscheiden, sich zunächst auf das standardisierte Profil zu konzentrieren. Daher sollten seine Technologieentscheidungen größtenteils mit dem standardisierten Profil übereinstimmen.

Im Allgemeinen wird BizTalk Server 2006 besser in Organisationen passen, die sich im erweiterten oder dynamischen Profil befinden oder ein kurzfristiges Ziel haben. Ein organization im Profil "Basic", das in diesem Profil relativ zufrieden ist, hat möglicherweise weder die strategische Motivation, BizTalk Server 2006 zu übernehmen, noch die Fähigkeiten, es effektiv zu nutzen. Wenn sich jedoch ein organization im Profil "Basic" entschieden hat, sich aggressiv auf das Erweiterte Profil zubewegen, kann die Übernahme BizTalk Server 2006 ein strategischer Schritt in diese Richtung sein.

Der Punkt der Einführung des APIO-Modells in die Diskussion ist, dass eine gute Vorstellung von den aktuellen und gezielten APIO-Profilen der organization bei der Entscheidung zwischen WF und BizTalk Server 2006 helfen wird, wenn das technische Szenario von beiden Technologien gut unterstützt werden könnte. Zwei verschiedene Organisationen treffen möglicherweise unterschiedliche Entscheidungen – jede trifft die richtige Wahl für ihr Organisationsprofil.

Es ist alles im Host

Einer der wichtigsten Aspekte, die Bei der Auswahl zwischen BizTalk Server 2006 und WF zu berücksichtigen sind, sind die Hostinganforderungen für Ihre Workflows. Im Gegensatz zu BizTalk Server 2006 bietet WF kein out-of-the-box-Hosting. Sie müssen einen Host implementieren, der den Windows-Prozess festlegt und die Workflowlaufzeit-Engine startet, in der Ihre Workflows ausgeführt werden.

Um ein Framework zu erstellen, das das gesamte Spektrum von Workflowszenarien realistisch unterstützen kann, abstrahiert WF die Kernverhaltensweisen, die eine Umgebung wie BizTalk Server 2006 bietet, sodass verschiedene Hosts das spezifische gewünschte Verhalten für diese Dienste bereitstellen können.

Die wichtigsten Dienste, die ein WF-Workflowhost bereitstellt, sind die folgenden:

  • Terminplanungsdienst: Erstellt und verwaltet die Threads, die von der Runtime-Engine zum Ausführen von Workflowinstanzen verwendet werden.
  • Committen des Arbeitsbatch-Diensts: Verwaltet die Transaktionen, die von der Laufzeit-Engine für Datenbankvorgänge verwendet werden.
  • Persistenzdienst: Verarbeitet die Persistenz des Workflows instance, wenn er von der Laufzeit-Engine dazu angewiesen wird. Dieser Dienst ist optional. Wenn sie nicht bereitgestellt wird, werden die Workflowinstanzen nicht beibehalten, und sie müssen während ihrer gesamten Lebensdauer im Arbeitsspeicher ausgeführt werden.
  • Nachverfolgungsdienst– Ermöglicht das Aufzeichnen von Nachverfolgungsereignissen innerhalb von Workflows. Dieser Dienst ist optional.

Was zum Erstellen eines Workflowhosts erforderlich ist

Abhängig von Ihrem Workflowszenario und den Diensten, die Sie für Ihre Workflows bereitstellen müssen, kann das Erstellen eines WF-Hosts trivial oder unerschwinglich sein. Für die Szenarien, in denen sich der Workflow im Kontext einer Anwendung befindet, ist das Hosten von WF recht einfach. Die Anwendung selbst fungiert als Prozesshost, und es gibt Standardimplementierungen der Kerndienste, die mit minimalem Aufwand konfiguriert werden können.

Die erforderliche Raffinesse des Hosts steigt jedoch dramatisch, wenn Sie in hochgradig skalierbare, serverbasierte Szenarien einsteigen. Tabelle 1 zeigt eine Liste der möglicherweise benötigten Hostdienste, von denen die meisten in BizTalk Server 2006 bereitgestellt werden.

Tabelle 1. Hostdienste

  • Konfiguration für dezentrales Skalieren
  • Lastenausgleich
  • Failover
  • Drosselung
  • Threadverwaltung
  • Speicherverwaltung
  • Dienstisolierung
  • Ausnahmekonfiguration
  • Verwaltung von Fehlerhaften Nachrichten
  • Nachrichtenüberwachung
  • Archivierung und Löschvorgang
  • Identitäts- und Identitätswechsel
  • Bereitstellungsmodell mit mehreren Umgebungen
  • Systemüberwachung
  • Auslastungs-/Leistungsnachverfolgung
  • Zustandsverwaltung für zusammengesetzte Prozesse
  • Skripterstellung
  • Notfallwiederherstellung
  • Compliance
  • Konfigurationsverwaltung

In welchem Geschäft sind Sie trotzdem tätig?

Wenn Sie mit der Erstellung einer bestimmten Anwendung mit engen Fristen beauftragt sind, möchten Sie wahrscheinlich nicht, dass Ihr Team durch die Erstellung eines komplexen Hosts abgelenkt wird, wenn es sich auf die Implementierung der erforderlichen Geschäftslogik konzentrieren sollte. In diesem Fall lohnt es sich, BizTalk Server 2006 einen robusten Workflowhost zu kaufen, anstatt zu versuchen, einen stabilen Workflowhost zu erstellen. Wenn Sie Teil des zentralen Architekturteams eines großen Unternehmens sind, können Sie in die Erstellung eines Hosts investieren, der im gesamten organization verwendet werden könnte. Dennoch sollte dieser Aufwand nicht leicht gemacht werden.

Workflow-Technology Empfehlungen

Für Szenarien innerhalb einer Anwendung: WF

Für alle Szenarien, die in einer Anwendung enthalten sind – einschließlich Ui Page Controller, Geschäftslogik mit langer Ausführung, dynamisch aktualisierbarer Prozessfluss, Webdienstkomposition und Abstraktion von Regeln aus Geschäftslogik – ist WF die richtige Wahl für Workflow-Technologie.

In den meisten anwendungsorientierten Szenarien erfordert das Verwendungsmuster eine synchrone Interaktion mit geringer Latenz zwischen der Anwendung und dem Workflow, was nicht die Stärke von BizTalk Server 2006 ist. BizTalk Server 2006 wäre aus Leistungsgründen für diese Szenarien nicht geeignet; BizTalk Server Orchestrierungen auf dedizierten BizTalk-Servern ausgeführt werden und sie von einer Clientanwendung aufgerufen werden, erfordert eine Rundreise über das Netzwerk. Darüber hinaus führt der Entwurf von BizTalk Server 2006 zum Beibehalten jeder Nachricht in der MessageBox-Datenbank zur Dauerhaftigkeit zu einer zusätzlichen Latenz, die im Kontext einer interaktiven Benutzeroberfläche möglicherweise nicht akzeptabel ist, wenn der Workflow synchron aufgerufen werden muss.

WF eignet sich besser für diese Szenarien. es erfüllt die Workflowanforderungen und ist einfacher und kostengünstiger als BizTalk Server 2006. Die Messagingfunktionen von BizTalk Server 2006 , z. B. die Zuordnung und adapter, sind in diesen Szenarien nicht erforderlich. Die Anforderungen für Hostingdienste sind bescheiden, sodass das Hosten der WF-Runtime in der Anwendung keinen unerschwinglichen Aufwand erfordert.

Für die meisten Business-Process Szenarien: BizTalk Server 2006

Für die meisten Szenarien, die serverbasierte Geschäftsprozesse umfassen, ist BizTalk Server 2006 die richtige Wahl. Dazu gehören B2B-Prozess, Abstraktion von Regeln aus Geschäftsprozess, Enterprise Rule Repository und Enterprise Service Bus (ESB)/Message Broker.

Diese Szenarien erfordern eine hohe Skalierbarkeit. Außerdem benötigen sie die Möglichkeit, ausgeführte Prozesse anzuzeigen und sie zu beenden und neu zu starten. Schließlich benötigen sie Unterstützung für das Horizontalskalieren auf mehrere Server. In diesen Szenarien sind die erweiterten Hostingfunktionen von BizTalk Server 2006 erforderlich und die Investition lohnt sich.

Basic Standardisiert Fortgeschrittene Dynamisch

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Abbildung 4. Geschäftsprozessszenario mit langer Ausführung

BizTalk Server 2006 wird in der Regel die beste Plattform für das Szenario mit langen Geschäftsprozessen sein. Diese Prozesse sind in der Regel asynchron, langwierig und zustandsbehaftet. Diese Prozesse sind häufig unternehmenskritisch für die organization und erfordern daher Hochverfügbarkeit, Transparenz, Sicherheit und Verwaltbarkeit. Mit der Gruppen- oder Farmtopologie von BizTalk Server 2006 können Sie ein Array von Servern verwalten, um Skalierbarkeit und Redundanz zu gewährleisten.

Der Persistenzmechanismus von BizTalk Server 2006 zum Speichern des Prozesszustands verfügt über eine robuste Sicherheit, die zum Schutz der Privatsphäre des persistenten Zustands integriert ist, was aus regulatorischen Gründen wichtig sein kann. Die Geschäftsaktivitätsüberwachung (BAM) von BizTalk Server 2006 bietet auf sichere Weise einen angemessenen Einblick in die ausgeführten Prozesse auf Unternehmensebene. Schließlich erfordern diese Szenarien häufig Unterstützung für heterogene Nachrichtenformate und Transportprotokolle, einschließlich Legacysystemen.

Aus diesen Gründen ist BizTalk Server 2006 in der Regel die beste Wahl für Organisationen, die auf standardisierte, erweiterte und dynamische Profile abzielen. Diese Organisationen betrachten das Szenario für lange Geschäftsprozesse in der Regel als sehr wichtig für das Unternehmen und sehr häufig im Unternehmen; Daher kaufen sie BizTalk Server 2006 speziell, um eine standardisierte Plattform für sie zu schaffen.

WF ist jedoch möglicherweise eine bessere Wahl für Organisationen, die sich im Basic APIO-Profil befinden. Diese Organisationen möchten in der Regel nicht in den Aufbau einer standardisierten Anwendungsplattform investieren. Stattdessen versuchen sie, die Kosten zu minimieren, und die Lizenzierungs- und Hardwarekosten von BizTalk Server 2006 könnten unerschwinglich sein. Die Ausnahme von dieser Anleitung besteht, wenn Anforderungen an eine hohe Skalierbarkeit, Überwachung und Unterstützung für eine Vielzahl von Nachrichtenformaten und Transportprotokollen bestehen. In diesem Fall ist der organization zwar zögerlich, in seine Anwendungsplattform zu investieren, aber die Kosten für die Erstellung der Hosting- und Messagingfunktionen von Grund auf würden wahrscheinlich die Kosten von BizTalk Server 2006 überschreiten.

Basic Standardisiert Fortgeschrittene Dynamisch

WF

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Abbildung 5. Webdienstaggregatorszenario

Sowohl BizTalk Server Orchestrierungen als auch WF-Workflows bieten eine starke Unterstützung für externe Webdienste aus einem Workflow und für die Offenlegung des Workflows als Webdienst. Daher wird für die Erstellung von Webdienstaggregatorlösungen genau wie bei Lösungen für lange Geschäftsprozesse die Wahl durch das Organisationsprofil und die Hostinganforderungen bestimmt.

Wenn der Aggregierungswebdienst nur andere Webdienste aggregieren soll, ist die Fähigkeit von BizTalk Server 2006, heterogene Nachrichtenformate und Transportprotokolle zu unterstützen, wenig Wert. Wenn der Dienst jedoch auch Daten aus Legacyumgebungen aggregieren soll, die nicht als Webdienste verfügbar gemacht werden, würde BizTalk Server 2006 einen Mehrwert bieten.

Da das Verwendungsmuster schnelle, synchrone Anforderungs-/Antwortaufrufe ist, ist die Von BizTalk Server 2006 bereitgestellte Nachrichtenbeständigkeit in der Regel nicht wichtig. Tatsächlich ist die Latenz, die durch die Persistenz für die MessageBox verursacht wird, tatsächlich eine Haftung. Der Standard Wert, der BizTalk Server 2006 für dieses Szenario bietet, ist die Möglichkeit, die Bereitstellung über viele Server hinweg zu verwalten und ausgeführte Instanzen zu überwachen. Die BAM-Funktion von BizTalk Server 2006 kann auch nützlich sein, um zu überwachen, dass Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) eingehalten werden.

Aus diesen Gründen ist WF eine sehr gute Wahl für die Implementierung von Webdienstaggregatoren, insbesondere in Organisationen in den Profilen "Basic" und "Standardized". Ein Beispiel, in dem BizTalk Server 2006 vorteilhaft sein kann, ist ein Beispiel, in dem Sie eine große Anzahl von Endpunkten für verschiedene Clientorganisationen verwalten müssen. Die Konfiguration des Empfangsports und des Empfangsspeicherorts von BizTalk Server 2006 behandelt dies speziell. In diesem Fall können Zertifikate ebenfalls wichtig sein, und die Unterstützung von BizTalk Server 2006 zum Konfigurieren und Verwalten von Zertifikaten und deren Anwendung auf die Verschlüsselung/Entschlüsselung kann hilfreich sein.

Future-Proofing

Sie möchten sicherstellen, dass Ihre Investitionen in Softwarelizenzierungskosten, in das Erlernen einer Workflowtechnologie und in die Erstellung bestimmter Workflowkomponenten Ihnen in Zukunft den größtmöglichen Nutzen bieten. Neben der Auswahl des richtigen Workflows für Ihr spezifisches Workflowszenario und organization müssen Sie auch die Produktroadmaps für BizTalk Server 2006 und WF berücksichtigen. Dafür gibt es keine einfache Antwort. Die folgenden Kommentare sind kein starkes Argument für die Wahl einer der beiden Technologien. Stattdessen sind sie Datenpunkte, die Bei Ihrer Entscheidung unterstützen.

Was BizTalk Server 2006 R2 hinzufügt

BizTalk Server 2006 R2 werden zwei Features hinzugefügt, die sich auf die Auswahl der Workflowplattform auswirken können: die WCF-Adapter und die BAM-Interceptors für WCF und WF.

WCF-Adapter

Wenn Ihr Team Windows Communication Foundation (WCF) als Standardtechnologie für die Implementierung von Diensten bei der Erstellung Ihrer SOA verwendet hat, hat die Tatsache, dass BizTalk Server 2006 keine WCF-Unterstützung hatte, es möglicherweise als Plattform zum Erstellen und Hosten zusammengesetzter Webdienste disqualifiziert. Dies hat Sie möglicherweise in Richtung WF getrieben, auch wenn BizTalk Server 2006 ansonsten gut zu Ihren Szenarien und Ihrem APIO-Profil passte.

Glücklicherweise ist dies mit der Einführung der großartigen WCF-Integration in BizTalk Server 2006 R2 kein Problem mehr. BizTalk Server 2006 verfügt jetzt über eine starke Integration in WCF und ist eine hervorragende Plattform, um zusammengesetzte Dienste aus granulareren Diensten zu erstellen und diese zusammengesetzten Dienste als WCF-Dienste verfügbar zu machen.

BAM Interceptor für WF

Das zweite relevante BizTalk Server 2006 R2-Feature ist die Einführung des BAM-Interceptors für WF. Wenn die Überwachung von Geschäftsaktivitäten ein wichtiges Feature Ihrer Lösung ist, wurden Sie möglicherweise dazu gedrängt, BizTalk Server 2006 zu verwenden – nur um die Vorteile von BAM zu nutzen –, da WF sonst besser für Ihr Szenario geeignet war. Mit dem BAM-Interceptor für WF können Sie WF auswählen, wenn es sich um die richtige Workflowtechnologie für Ihr Projekt handelt, und trotzdem BAM als Lösung für die Überwachung von Unternehmensaktivitäten verwenden.

BAM ist ein Feature von BizTalk Server 2006, das ein Framework zum Erfassen von Ereignissen und Daten aus BizTalk Server Orchestrierungen und Nachrichtenflüssen bietet und diese Daten in einem Portal darstellt, um dem Geschäftsbenutzer end-to-End-Einblick in den Geschäftsprozess zu bieten. Ein wichtiger Aspekt der Arbeitsweise von BAM für BizTalk Server 2006-Anwendungen ist, dass die BAM-Überwachung konfiguriert (oder "instrumentiert") werden kann, nachdem eine BizTalk Server 2006-Anwendung bereitgestellt wurde, ohne dass Änderungen an den BizTalk Server 2006-Codeartefakten erforderlich sind.

BAM ist als unternehmensweite Lösung zur Überwachung von Geschäftsaktivitäten konzipiert. Daher ist es für Nicht-BizTalk Server 2006-Anwendungen möglich, Ereignisse und Daten in BAM einzuspeisen. Die APIs hierfür erfordern jedoch einiges an Code, um in den externen Anwendungen geschrieben zu werden. Der BAM WF-Interceptor in BizTalk Server 2006 R2 bietet die Möglichkeit, WF-Workflows für BAM einfacher und ohne Codeänderungen zu instrumentieren. Mithilfe der BAM-Interceptors können Sie Ihre Geschäftsprozesse nachverfolgen, ohne Ihre WF- oder WCF-Lösung neu zu kompilieren. Die Integration erfolgt über eine Konfigurationsdatei.

BizTalk Server 2006 Erweiterungen für WF SDK

Das BizTalk Server 2006 Extensions for WF SDK wurde auf der TechEd 2007 angekündigt und vorgestellt. Dieses SDK bietet einen einfachen Mechanismus zum Hosten von WF-Workflows in BizTalk Server 2006. Dieses Tool ist für die Verwendung von .NET-Entwicklern vorgesehen, die heute WF-Workflows erstellen und nach einer einfachen Möglichkeit suchen, um ein robustes, skalierbares Hosting dieser Workflows zu erreichen.

Das SDK bietet zwei benutzerdefinierte WF-Aktivitäten – eine btsReceive-Aktivität und eine btsSend-Aktivität –, die in einem WF-Workflow zum Empfangen und Senden von Nachrichten über BizTalk Server 2006 verwendet werden können. Als Entwickler definieren Sie WCF DataContracts für die eingehenden und ausgehenden Nachrichten und einen ServiceContract , um das Nachrichtenaustauschmuster zu definieren. Im WF-Workflow werden die Aktivitäten btsReceive und btsSend so konfiguriert, dass sie den definierten ServiceContract verwenden, wie in Abbildung 6 dargestellt.

Abbildung 6. btsReceive- und btsSend-Aktivitäten zur Verwendung in definierten ServiceContract

Nachdem der WF-Workflow abgeschlossen und kompiliert wurde, klicken Sie mit der rechten Maustaste auf das Workflowprojekt, und wählen Sie Orchestrierung generieren aus, um automatisch eine Wrapperorchestrierung zu generieren (siehe Abbildung 7), die den WF-Workflow initiiert und BizTalk Server 2006-Nachrichten an und von dort weiterleitet.

Die automatisch generierte Wrapperorchestrierung enthält Schemas für die im ServiceContract definierten Nachrichten. Es enthält auch die BizTalk Server Orchestrierungs-Shapes und Code zum Empfangen einer BizTalk Server 2006-Nachricht, zum Erstellen und Starten der Workflow-instance, zum Übergeben eingehender Nachrichten an den Workflow instance, zum Empfangen der ausgehenden Nachrichten und zum Weiterleiten an die BizTalk Server Messaging-Engine 2006. Um das Hosting Ihres WF-Workflows abzuschließen, müssen Sie nur die Wrapperorchestrierung kompilieren und bereitstellen und sie mithilfe des normalen BizTalk Server 2006-Mechanismus binden.

Abbildung 7. Automatisches Generieren einer Wrapperorchestrierung

Neben der Nutzung des robusten, skalierbaren Hostingmechanismus von BizTalk Server 2006 für WF-Workflows können Sie mit dem BizTalk Server 2006 Extensions for WF SDK auch die BizTalk Server 2006-Messaginginfrastruktur nutzen. Daher können Sie die vielen verfügbaren Adapter für das Abrufen von Nachrichten in und aus BizTalk Server 2006 sowie die Pipelineverarbeitung einschließlich der Zuordnungsfunktionen nutzen.

Das BizTalk Server 2006 Extensions for WF SDK sollte als Tool verwendet werden, damit WF-Entwickler ihre Workflows zusätzlich zu BizTalk Server 2006 bereitstellen können – nicht als Ersatz für Orchestrierungen in Szenarien, in denen wir BizTalk Server 2006 als geeignetes Tool identifiziert haben. Es gibt einige WF-Shapes, die nicht funktionieren, wenn sie in einer Orchestrierung umschlossen werden. Dies liegt daran, dass das Hosten Ihrer WF-Workflows in BizTalk Server 2006 mithilfe des BizTalk Server 2006 Extensions for WF SDK nicht das gleiche Hostingverhalten wie native Orchestrierungen bietet. Das SDK verfügt über eine Faq-Liste (im Schnellstarthandbuch enthalten), in der diese Unterschiede beschrieben werden.

Zusammenfassung

BizTalk Server 2006 und Windows Workflow Foundation sind die wichtigsten Tools von Microsoft für die Implementierung von Workflowlösungen in den Kategorien Anwendungs- und Unternehmensintegrationsworkflow. Um auswählen zu können, welches für Ihr Projekt geeignet ist, müssen Sie zuerst ermitteln, welches der Workflowszenarien Sie als Ziel verwenden.

Verwenden Sie als Nächstes die Tabelle in Abbildung 8, um die empfohlene Workflowtechnologie für Ihr Szenario anzuzeigen. Für Workflows innerhalb einer Anwendung wird WF empfohlen. Für die meisten serverbasierten Geschäftsprozesse und B2B-Szenarien empfehlen wir BizTalk Server 2006.

Abbildung 8. Szenariospezifische Workflowtechnologien

Sowohl für die Szenarien mit lang andauernden Geschäftsprozessen als auch für die Webdienstaggregatorszenarien können beide Technologien affektiv angewendet werden. Für diese Szenarien sollten Sie das aktuelle und das kurzfristige APIO-Zielprofil Ihrer organization bewerten. Organisationen, die sich entweder in den erweiterten oder dynamischen Profilen befinden oder sich auf diese zubewegen, sollten für diese Szenarien BizTalk Server 2006 verwenden. Organisationen in den Profilen Basic und Standard können WF für diese Szenarien effektiv verwenden.

Schließlich sollten Sie die Veröffentlichungsdaten und die gewünschte Lebensdauer Ihrer Lösung im Verhältnis zum Produktroadmap für BizTalk Server 2006 und WF berücksichtigen. Mithilfe dieses Frameworks und der Anleitung in diesem Artikel sollten Sie in der Lage sein, den richtigen Workflow für Ihr Projekt auszuwählen.

Nachtrag

Falsche Vorstellungen über BizTalk Server 2006 im Vergleich zu WF

Im Folgenden finden Sie einige häufige Missverständnisse in Bezug auf WF und BizTalk Server 2006 und die klärenden Argumente, die wir verwenden, um sie zu vertreiben:

  • WF ist der Ersatz für BizTalk Server 2006.Nein. Da WF das "neueste und beste" Angebot von Microsoft für die Programmierung von Workflows ist, gehen viele, die mit BizTalk Server 2006 nicht vertraut sind, zunächst davon aus, dass es mit der Veröffentlichung von WF veraltet wurde. Die einfache Antwort, um diesen Eindruck zu korrigieren, ist, dass WF ein Low-Level-Entwicklerframework zum Erstellen aller Arten von Workflows ist, während BizTalk Server 2006 ein vollwertiges Serverprodukt mit erweiterten Features für eine bestimmte Kategorie von Workflowszenarien ist: Unternehmensintegration. (Siehe Abbildung 1.)
    WF bietet nur eine kleine Teilmenge dieser Funktionalität: Workflow- und Geschäftsregeln. WF kann zwar eine einfachere und kostengünstigere Lösung für Szenarien sein, die nicht alle anderen Features erfordern, die BizTalk Server 2006 bietet, aber in keiner Weise ersetzt es BizTalk Server 2006 für die kernigen Enterprise Integration-Szenarien, die BizTalk Server 2006 unterstützen soll.
  • BizTalk Server wird weg.Nein. Ein ähnliches Missverständnis ist der Eindruck, dass Microsoft nicht mehr in BizTalk Server investiert, weil WF als Workflowtool der Zukunft veröffentlicht wurde und BizTalk Server noch nicht für die Verwendung von WF neu geschrieben wurde. Dies ist einfach nicht der Fall; BizTalk Server war ein sehr erfolgreiches Produkt, und der Bereich Enterprise Integration, auf den es abzielt, ist nach wie vor ein Bereich, den Microsoft unterstützen möchte.
  • Sie müssen BizTalk Server 2006 gegenüber .NET Framework auswählen.Nein. Für .NET-Entwickler, die mit BizTalk Server 2006 nicht vertraut sind, kann es verlockend sein, WF gegenüber BizTalk Server 2006 zu wählen, nur auf der Grundlage, dass sie lieber "reines" .NET verwenden würden. Dies ist jedoch wirklich kein nützliches Kriterium; BizTalk Server 2006 selbst baut auf dem .NET Framework auf.
    Tatsächlich stellt BizTalk Server 2006 mehr als 2 Millionen Zeilen .NET-Code dar, die auf Ihre Lösung angewendet werden können. Dadurch sparen Sie Zeit, Probleme und Kosten für die Entwicklung der Funktionalität von Grund auf neu. Darüber hinaus erfolgt BizTalk Server 2006-Programmierung selbst in Microsoft Visual Studio .NET, und die Komponenten werden kompiliert und als .NET-Assemblys bereitgestellt. Darüber hinaus kombinieren die wichtigsten BizTalk Server 2006-Projekte BizTalk Server 2006-Komponenten mit benutzerdefinierten .NET-Komponenten. Daher sollte BizTalk Server Entwicklung von 2006 als spezialisierte .NET-Entwicklung betrachtet werden, anstatt etwas, das fremd oder anders ist.
    Die eigentliche Frage ist, ob die BizTalk Server 2006-Features für Ihr bestimmtes Workflowszenario genügend Nutzen bieten, um die Lizenzierungskosten zu rechtfertigen. Sie möchten keine Schlittenhammer verwenden, um Bilder aufzuhängen. Sie möchten auch keinen Schreinerhammer zum Zerkleinern großer Steine verwenden.
  • Die meisten Features gewinnen.Eine schlechte Wahl. Wir könnten eine Featurematrix erstellen, die die granularen Features von WF mit denen von BizTalk Server 2006 vergleicht. Dieser Vergleich wäre jedoch nicht sehr hilfreich; BizTalk Server 2006 verfügt über eine so große Anzahl von Features, die speziell auf den Enterprise Integration-Bereich ausgerichtet sind. Wenn dies nicht Ihr Zielszenario ist, sind die Featurevergleiche bedeutungslos. BizTalk Server 2006 würde wahrscheinlich in Bezug auf die Anzahl der Feature-Kontrollkästchen gewinnen. Dies ist jedoch ein Vergleich zwischen Äpfeln und Orangen, wenn sich diese Features nicht auf das Workflowszenario beziehen, auf das Sie abzielen.

Danksagungen

Ich möchte mich bei Paul Andrew und Kris Horrocks und allen, die diesen Artikel überprüft haben, bedanken.

Weitere Informationen

Informationen zum Autor

Kent Brown ist Direktor und Senior Architect der Enterprise Integration Practice bei twentysix New York, einem Microsoft Gold Certified-Beratungspartner in New York City. Seit seiner Gründung im Jahr 2000 freut er sich auf BizTalk Server und spielt seit sieben Jahren eine evangelistische Rolle rund um das Produkt. Kent ist Mitglied des Microsoft BizTalk Virtual Technical Specialist Teams sowie MVP für Entwickler von Microsoft Connected Systems. Er ist Gründer und Leiter der NYC Connected Systems Users Group (http://www.NYCCSUG.org).