Freigeben über

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

Überarbeitete 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)

Inhalt

Einleitung

Prozess für die Auswahl des richtigen Workflowtools

Allgemeine Workflowszenarien

Alles auf dem Host

empfehlungen für Workflow-Technology

Future-Proofing

Schlussfolgerung

Nachtrag

Bestätigungen

Weitere Informationen

Einleitung

Der Workflow ist in alltäglichen Geschäftsprozessen durchdringend, sodass häufig Programmiertools gefunden werden müssen, 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 Überschneidung 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 in Zukunft eindeutig als bevorzugte Workflowtechnologie identifiziert wurde, während BizTalk Server 2006 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, in 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 – darunter:

  • Fluss von BENUTZEROBERFLÄCHEN-Bildschirmen, mit denen ein Benutzer interagiert, um eine Aufgabe abzuschließen.
  • 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 Daten in eine Datenbank.

Während das Spektrum der Workflowszenarien breit ist, ist es hilfreich, sie in vier allgemeine Kategorien zu gruppieren: Human Workflow, Anwendungsworkflow, Enterprise Integration Workflowund Datenintegrationsworkflow.

Von den vier Hauptworkflowkategorien sind Anwendungsworkflow und Enterprise-Integrationsworkflow die beiden Bereiche, in denen personen es am schwierigsten finden, eine Technologie auszuwählen. Die Szenarien für den menschlichen Workflow und den Datenintegrationsworkflow sind relativ einfach, aus Sicht der Toolsauswahl. Der menschliche Workflow erfordert eine Benutzeroberfläche und ist häufig dokumentorientiert, sodass Microsoft Office SharePoint Server 2007 die empfohlene Plattform zum Erstellen von Human Workflow-Lösungen ist. Microsoft SQL Server Integration Services (SSIS) ist das empfohlene Tool für Datenintegrationsszenarien.

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

Das BizTalk Server Orchestration-Modul

Das BizTalk Server-Orchestrierungsmodul gehört seit jeher zu den überzeugenden Features von BizTalk Server. Als es eingeführt wurde, war es das beste Tool, das von Microsoft zur Durchführung der workfloworientierten Programmierung verfügbar war. BizTalk Server-Orchestrierung bietet eine visuelle Programmierumgebung für die Entwicklung von Komponenten zur Steuerung komplexer, mehrstufiger Nachrichtenflüsse, um eine bestimmte Geschäftstransaktion abzuschließen.

Die BizTalk Server-Orchestrierungscodeartefakte ähneln eng den Flussdiagrammen oder UML-Aktivitätsdiagrammen (Unified Modeling Language), die ein Geschäftsanalyst zum Dokumentieren eines Geschäftsprozesses erzeugen kann. Diese Artefakte können dann in der Orchestrierungsmodullaufzeit kompiliert und ausgeführt werden, die Dienste wie lange laufende Transaktionen und Entschädigungen, Haltbarkeit, Fehlertoleranz und Notfallwiederherstellung bereitstellt, die für die Erstellung von Systemen, die unternehmenskritische Geschäftstransaktionen automatisieren, von entscheidender Bedeutung sind.

Eine Workflow-Foundation für die Zukunft

Obwohl es unterschiedliche Kategorien von Workflowszenarien gibt, gibt es genügend Gemeinsames zwischen den Szenarien, aus Programmierperspektive, um zu versuchen, ein gemeinsames Framework für die Workflowentwicklung zu etablieren. Das Orchestrierungsmodul in BizTalk Server ist leistungsfähig, 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 .NET Framework ein, das allgemein und erweiterbar genug ist, um in allen workflowbezogenen Szenarien auf der Windows-Plattform in Zukunft verwendet zu werden. Das Team, das WF produziert hat, konnte die besten Konzepte des BizTalk Server-Orchestrierungsmoduls nutzen, 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 sie zum Implementieren von Human Workflow-Lösungen. Die Absicht besteht darin, dass BPM-Anbieter von Drittanbietern auch ihre Lösungen auf WF aufbauen, anstatt eigene proprietäre Workflowmodule zu erstellen; Mehrere Anbieter haben dies bereits getan. Einzelne Entwickler können wf auch verwenden, um benutzerdefinierten Anwendungsworkflow in .NET Framework-Anwendungen zu implementieren. Der Plan ist auch für eine zukünftige Version von BizTalk Server vorgesehen, um das Orchestrierungsmodul auf WF für die Implementierung von Enterprise Integration Workflow-Lösungen zu implementieren.

Abbildung 1. Verwenden des richtigen Workflowtools: BizTalk Server 2006 vs. WF

Prozess für die Auswahl des richtigen Workflowtools

Unsere Methode zur Bereitstellung von Anleitungen, mit denen Sie entscheiden können, welches Workflowtool zu Ihrem Projekt passt, besteht darin, die am häufigsten verwendeten Workflowszenarien zu delineieren, damit Sie das Szenario oder die Kombination von Szenarien bestimmen können, die am besten zu Ihrem Projekt passen. Anschließend geben wir spezifische Anleitungen für jedes Szenario an, 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 Entwicklungsfunktionen einer Organisation – um organisationsspezifische Anleitungen in den Szenarien bereitzustellen, in denen beide Tools effektiv verwendet werden können. Schließlich werden wir uns die Roadmap für BizTalk Server 2006 und WF ansehen, damit Sie die besten Entscheidungen für die zukünftige Prüfung der Anwendungen treffen können, die Sie heute erstellen.

Allgemeine Workflowszenarien

Auch nachdem wir unseren Umfang auf die Kategorien "Anwendung" und "Unternehmensintegration" des Workflows übertragen haben, gibt es noch eine breite Palette von Workflowszenarien, die berücksichtigt werden müssen. Wie in Abbildung 2 dargestellt, sind auf einer Seite des Spektrums Szenarien, in denen WF eindeutig die richtige Wahl ist. Ein Beispiel hierfür ist die Workflowfunktion innerhalb eines unabhängigen Softwareanbieters (ISV), bei dem die Lizenzierungskosten und die Bereitstellungskomplexität von BizTalk Server 2006 unertragbar wäre. In diesem Szenario, als ISV, sind Sie im Geschäft, kommerzielle Software zu machen, und der zusätzliche Programmieraufwand, der zum Hosten von WF-Lizenzfrei erforderlich ist, ist eine angemessene Investition.

Abbildung 2. Integration und Workflowkontinuum

Auf der anderen Seite des Spektrums sind Enterprise Integration-Lösungen, die in einer IT-Abteilung eines Unternehmens aufgebaut sind, wobei BizTalk Server 2006 eindeutig die richtige Wahl ist. In diesem Szenario möchten Sie sich auf den Produktionswert konzentrieren, anstatt in die Erstellung der "Sanitäranlage" zu investieren, um Ihre Lösung skalierbar, zuverlässig und verwaltbar zu machen; Daher lohnt sich die Lizenzierungskosten von BizTalk Server 2006 aufgrund dessen, was es bietet.

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

  • ui Page Controller– Eine häufige Anforderung in komplexen Anwendungen besteht darin, die Benutzeroberflächen-Bildschirmnavigation gemäß den Geschäftsregeln des jeweiligen Anwendungsfalles 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 Möglichkeiten der Bildschirmnavigation, die auf den Aktionen des Benutzers und dem Status der Daten basieren.
    Das Model-View-Controller (MVC)-Muster ist die klassische Technik zum Abrufen dieser Navigationslogik aus den Formularen selbst, sodass sie in verschiedenen Anwendungsfällen einfacher und wiederverwendbarer sind. Der Controller im MVC-Muster ist wirklich ein Workflow oder Zustandsautomat; Daher ist es natürlich, nach einem Workflowtool bei der Implementierung dieser Arten von Anwendungen zu suchen.
  • Long Running Business Logic– Wenn viele Schritte erforderlich sind, um eine Geschäftstransaktion abzuschließen, muss der Benutzer möglicherweise in der Mitte des Prozesses anhalten oder auf Aktionen anderer Benutzer oder Systeme warten, bevor er fortfahren kann. Die Möglichkeit, einen Prozess vorübergehend (oder "ruhen") anzuhalten und dann basierend auf externen Ereignissen neu zu starten, ist für die Idee des Workflows von zentraler Bedeutung. Ohne ein Workflowmodul müssen Entwickler manuell die Mechanismen zum Speichern des Zustands eines unvollständigen Prozesses entwerfen und codieren und diesen Zustand zurückrufen, wenn der Prozess fortgesetzt wird. Mit einem gut gestalteten Workflowmodul wird diese Funktion nativ ohne zusätzliche Arbeit für die Entwickler unterstützt.
  • Dynamisch aktualisierbaren Prozessfluss– Obwohl es zunächst möglich scheint, Geschäftsprozesse in klar definierte sequenzielle Schritte zu codieren, müssen menschen häufig den Fluss Midstream ändern, um reale Situationen zu berücksichtigen. Bei einem Spesengenehmigungsprozess ist der Vorgesetzte des Mitarbeiters, der die Spesenabrechnung übermittelt hat, möglicherweise der Standardmäßige Genehmigende. Der Vorgesetzte kann sich jedoch entscheiden, die Aufgabe an eine Sekretärin zu delegieren (z. B. weil der Vorgesetzte zum Spielen von Golf geleitet wird) oder die Genehmigung zu einem Vorgesetzten eskalieren (z. B. weil der Vorgesetzte die Richtlinie für eine bestimmte Spesen nicht sicher ist). Das Aktualisieren des Flusses durch den Benutzer ist häufig einfacher, als jede mögliche Permutation des Flusses vorherzusagen.
  • Abstraktion von Regeln aus Geschäftslogik– In diesem Szenario soll die Geschäftsregeln von einer anderen Geschäftslogik getrennt werden. Ein gutes Beispiel hierfür sind Regeln für die Formularüberprüfung. In einem Hypothekenantragsprogramm verfügt das Formular "Kreditantrag" möglicherweise über eine Reihe von Feldüberprüfungsregeln, bevor der Benutzer die Schaltfläche " übermitteln" 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 Überprüfungsregeln erforderlich, da es sich in einer anderen Phase des Prozesses befindet.
    Durch die separate Implementierung der Gültigkeitsprüfungsregeln vom Formular ist es einfacher, das Formular in verschiedenen Szenarien wiederzuverwenden und die entsprechenden Gültigkeitsprüfungsregeln zu erzwingen, indem einfach die entsprechenden Regeln für dieses Szenario ausgewertet werden.
  • Webdienstaggregator– Anwendungen müssen häufig Daten aus mehreren verschiedenen Webdiensten aggregieren. In vielen Situationen kann und sollte die Aggregationslogik selbst aus der Anwendung extrahiert und als Dienst eigenständig verfügbar gemacht werden, die von anderen Anwendungen wiederverwendet werden können. Diese Dienste werden häufig zusammengesetzten Webdienstegenannt, und sie sind ein wichtiges Element einer ausgereiften dienstorientierten Architektur. Das Webdienstaggregatorszenario ist in der Regel synchron und kurz ausgeführt.
  • Long Running Business Process– Das Szenario "Long Running Business Process" wird in diesem Artikel verwendet, um serverbasierte Prozesse festzulegen, die mehrere Anwendungen integrieren, während Geschäftslogik für Logik innerhalb einer einzelnen Anwendung verwendet wird. Die Anforderungen für diese serverbasierten lang ausgeführten 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 (B2B)-Prozess– Das Szenario "B2B-Prozess" ist im Wesentlichen identisch mit dem Szenario "Long Running Business Process", mit der Ausnahme, dass der frühere Prozess zusätzlich zu internen Anwendungen zwischen Organisationen besteht. 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 von Ihrem Geschäftspartner vorgegeben werden können; Daher benötigen Sie die Möglichkeit, eine breite Palette von Formaten und Protokollen zu unterstützen und die Konfiguration der spezifischen Austausche für eine große Anzahl von Partnern zu unterstützen.
  • Abstraktion von Regeln aus Geschäftsprozess-– Ähnlich wie bei der Abstraktion von Regeln aus Geschäftslogik-Szenario gilt dieses Szenario, wenn Sie die Geschäftsregeln vom Hauptcode im Szenario "Long Running Business Process" und dem B2B-Prozessszenario trennen möchten. Dieses Szenario erfordert ein höheres Maß an Leistung und Skalierbarkeit. Außerdem benötigen sie wahrscheinlich Tools, mit denen Nichtprogrammierer die Regeln anzeigen und bearbeiten können.
  • Enterprise Rule Repository– In diesem Szenario soll ein zentrales Repository für gemeinsame Regeln erstellt werden, das von allen Anwendungen im Unternehmen aufgerufen werden kann. Dies bietet Konsistenz für alle Anwendungen in einer Organisation für die Anwendung wichtiger Geschäftsregeln. Ähnlich wie bei der Abstraktion von Regeln aus dem Geschäftsprozessszenario 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 Regel-Repository als eigene Entität im Unternehmen vorhanden sein kann, mit einem eigenen Hostingmechanismus, der vom Workflowmodul getrennt ist, und mit Komponenten oder APIs zum Ausführen der Regeln aus verschiedenen Anwendungen.
  • Enterprise Service Bus (ESB)/Message Broker– Viele Organisationen möchten eine standardisierte Kommunikationsinfrastruktur für alle Dienste. Die beiden häufigsten Topologien für diese Infrastruktur sind die ESB und der Nachrichtenbroker. Veröffentlichungs-/Abonnieren von Messaging und Themenbasisrouting sind häufig erwartete Features dieser Infrastruktur.

Optimierungsmodell für Anwendungsplattforminfrastruktur

In einigen Workflowszenarien erfüllen BizTalk Server 2006 und WF die technischen Anforderungen zufrieden. Für diese Szenarien muss die richtige Workflowtechnologieauswahl die Lösung mit den Anforderungen der jeweiligen Organisation abgleichen. Für die Zwecke der Empfehlungen, die für Ihre bestimmte Organisation 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 eine Technik zur Profilerstellung der Reife einer Organisation in Bezug auf ihre Anwendungsinfrastruktur, Architektur und Entwicklungspraktiken. Ziel dieses Modells ist es, Organisationen einen Fahrplan zur Optimierung ihrer Flexibilität bei der Bereitstellung von IT-Lösungen zu geben, um den Anforderungen des Unternehmens gerecht zu werden.

Das APIO-Modell verwendet die folgenden vier Profile der Reife einer Organisation:

  • Basic– Organisationen behandeln Software als Kosten. Sie haben weitgehend isolierte Anwendungen mit geringer Integration oder Wiederverwendung. Die Anwendungen, die sie haben, sind möglicherweise auf einer Vielzahl von Plattformen verfügbar. Sie haben keine konsistenten Standards für Infrastruktur- oder Entwicklungstechniken; sie haben keine einheitliche architekturliche Vision.
  • Standardisierte– Organisationen behandeln Software weiterhin als Kosten, aber sie haben Schritte unternommen, um die Effizienz zu verbessern. Sie haben eine architektonische Vision und versuchen, Möglichkeiten für die Wiederverwendung zu berücksichtigen. Sie haben begonnen, einige Anwendungen zu integrieren, aber sie sind meist Punkt-zu-Punkt-Integrationen.
  • Advanced– Organisationen behandeln Software als Business Enabler. Sie haben engagierte Architekten und eine klare architektonische Vision. Sie verfügen über viele Dienste und erreichen ein hohes Maß an Wiederverwendung. Alle Kerngeschäftsprozesse werden automatisiert und überwacht. Sie verwenden eine zentrale, verpackte Integrationsplattform.
  • Dynamische– Organisationen behandeln Software als strategische Ressource. Sie haben eine sehr reife SOA in Vision und Umsetzung. Sie verfügen über klare Prozesse für dynamische Versionsverwaltung und erneute Bereitstellung von Diensten. Die Anpassung an Änderungen der Geschäftsanforderungen kann schnell und schnell in neue Geschäftspartner integriert werden.

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

Etwas implizit im APIO-Modell ist die Vorstellung, dass jede Organisation auf das dynamische Profil umsteigen möchte. In Wirklichkeit 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 Standard- oder Standardprofil zu bleiben.

Sie sollten das aktuelle Profil sowie die kurzfristigen und langfristigen Ziele berücksichtigen, wobei das kurzfristige Ziel das wichtigste ist. Eine Organisation im Basisprofil mit dem Wunsch, schließlich im dynamischen Profil zu sein, könnte sich sinnvoll entscheiden, sich zunächst auf das standardisierte Profil zu konzentrieren; Daher sollten ihre Technologieentscheidungen hauptsächlich mit dem standardisierten Profil übereinstimmen.

Im Allgemeinen wird BizTalk Server 2006 besser in Organisationen passen, die – oder ein kurzfristiges Ziel haben – im Erweiterten oder dynamischen Profil zu sein. Eine Organisation im Basisprofil, die in diesem Profil relativ zufrieden ist, hat möglicherweise weder die strategische Motivation, BizTalk Server 2006 zu übernehmen, noch die Funktionen, die sie effektiv nutzen können; so würden sie die Investition wahrscheinlich nicht machen wollen. Wenn jedoch eine Organisation im Basic-Profil eine Entscheidung getroffen hat, sich aggressiv auf das erweiterte Profil zu bewegen, könnte die Einführung von BizTalk Server 2006 ein strategischer Schritt in diese Richtung sein.

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

Alles auf dem Host

Einer der wichtigsten Aspekte, die bei der Auswahl zwischen BizTalk Server 2006 und WF zu berücksichtigen sind, ist die Hostinganforderungen für Ihre Workflows. Im Gegensatz zu BizTalk Server 2006 stellt WF kein Host "out-of-the-box" bereit; Sie müssen einen Host implementieren, der den Windows-Prozess festlegt und das Workflowlaufzeitmodul startet, in dem Ihre Workflows ausgeführt werden.

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

Die Kerndienste, die ein WF-Workflowhost bereitstellt, sind die folgenden:

  • Terminplanungsdienst– Erstellt und verwaltet die Threads, die vom Laufzeitmodul zum Ausführen von Workflowinstanzen verwendet werden.
  • Commit-Arbeitsbatchdienst– Verwaltet die Transaktionen, die vom Laufzeitmodul für Datenbankvorgänge verwendet werden.
  • Persistenzdienst-– Behandelt die Persistenz der Workflowinstanz, wenn sie vom Laufzeitmodul dazu weitergeleitet wird. Dieser Dienst ist optional. Wenn sie nicht bereitgestellt wird, werden die Workflowinstanzen nicht beibehalten, und sie müssen für die gesamte Lebensdauer im Arbeitsspeicher ausgeführt werden.
  • Tracking-Dienst– Ermöglicht das Aufzeichnen von Nachverfolgungsereignissen innerhalb von Workflows. Dieser Dienst ist optional.

Was zum Erstellen eines Workflowhosts benötigt wird

Je nach Workflowszenario und den Diensten, die Sie für Ihre Workflows bereitstellen müssen, kann das Erstellen eines WF-Hosts trivial oder unertragbar 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 notwendige Raffinesse des Hosts springt jedoch dramatisch, wenn Sie in hoch skalierbare serverbasierte Szenarien gelangen. Tabelle 1 zeigt eine Wäscheliste mit Hostdiensten, die möglicherweise benötigt werden – die meisten davon werden in BizTalk Server 2006 bereitgestellt.

Tabelle 1. Hostdienste

  • Skalierungskonfiguration
  • Lastenausgleich
  • Fail-Over
  • Drosselnd
  • Threadverwaltung
  • Speicherverwaltung
  • Dienstisolation
  • Ausnahmekonfiguration
  • Fehlgeschlagene Nachrichtenverwaltung
  • Nachrichtenverfolgung
  • Archivierung und Bereinigung
  • Identität und Identitätswechsel
  • Bereitstellungsmodell für mehrere Umgebungen
  • Integritätsüberwachung
  • Auslastungs-/Leistungsnachverfolgung
  • Zusammengesetzte Prozessstatusverwaltung
  • Skripterstellung
  • Notfallwiederherstellung
  • Einhaltung
  • Konfigurationsverwaltung

In welchem Geschäft befinden Sie sich, trotzdem?

Wenn Sie mit dem Erstellen einer bestimmten Anwendung mit engen Stichtagen beauftragt werden, möchten Sie wahrscheinlich nicht, dass Ihr Team ablenken muss, indem Sie einen komplexen Host erstellen müssen, wenn sie sich auf die Implementierung der erforderlichen Geschäftslogik konzentrieren sollten. In diesem Fall ist BizTalk Server 2006 die Investition wert, um einen robusten Workflowhost zu kaufen , anstatt zu versuchen, einen robusten Workflowhost zu erstellen. Wenn Sie Teil des zentralen Architekturteams eines großen Unternehmens sind, können Sie in die Erstellung eines Hosts investieren, der in der gesamten Organisation verwendet werden kann. Trotzdem sollte dieser Aufwand nicht leicht in Anspruch genommen werden.

empfehlungen für Workflow-Technology

Für Szenarien in einer Anwendung: WF

Für alle Szenarien, die in einer Anwendung enthalten sind – einschließlich UI Page Controller, Long Running Business Logic, Dynamically Updateable Process Flow, Web Service Composition und Abstraktion von Regeln aus Geschäftslogik – ist WF die richtige Wahl für Workflowtechnologie.

In den meisten anwendungsorientierten Szenarien erfordert das Verwendungsmuster synchrone, latenzarme Interaktion zwischen der Anwendung und dem Workflow, was nicht die Stärke von BizTalk Server 2006 ist. BizTalk Server 2006 wäre aus Leistungsgründen nicht gut geeignet für diese Szenarien; BizTalk Server-Orchestrierungen werden auf dedizierten BizTalk-Servern ausgeführt, und das Aufrufen von einer Clientanwendung erfordert einen Roundtrip über das Netzwerk. Darüber hinaus führt der Entwurf von BizTalk Server 2006 zum Speichern jeder Nachricht in der MessageBox-Datenbank zur Dauerhaftigkeit zusätzliche Latenz ein, was 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; sie erfüllt die Workflowanforderungen und ist einfacher und billiger als BizTalk Server 2006. Die Messaging-Funktionen von BizTalk Server 2006 , z. B. die Zuordnung und die Adapter, sind in diesen Szenarien nicht erforderlich. Die Anforderungen für Hostingdienste sind bescheiden, sodass das Hosten der WF-Laufzeit innerhalb der Anwendung keine unertragliche Menge an Arbeit erfordert.

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

Für die meisten Szenarien mit serverbasierten Geschäftsprozessen 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 die Skalierung auf mehrere Server. In diesen Szenarien sind die erweiterten Hostingfeatures von BizTalk Server 2006 erforderlich und die Investition wert.

Grundlegend Genormt Fortgeschritten Dynamisch

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Abbildung 4. Szenario "Langer Geschäftsprozess"

BizTalk Server 2006 wird im Allgemeinen die beste Plattform für das Szenario "Long Running Business Process" sein. Diese Prozesse sind tendenziell asynchron, lang ausgeführt und zustandsbehaftet. Diese Prozesse sind häufig unternehmenskritisch für die Organisation; daher erfordern sie hohe Verfügbarkeit, Sichtbarkeit, Sicherheit und Verwaltbarkeit. Mit der Gruppen- oder Farmtopologie von BizTalk Server 2006 können Sie ein Array von Servern verwalten, um Skalierbarkeit und Redundanz bereitzustellen.

Der Persistenzmechanismus von BizTalk Server 2006 zum Speichern des Prozesszustands verfügt über stabile Sicherheit, um den Datenschutz des permanenten Zustands zu schützen, was aus regulatorischen Gründen wichtig sein kann. Die Business Activity Monitoring (BAM) von BizTalk Server 2006 bietet einen angemessenen Einblick in die laufenden Prozesse auf sicherer Basis. Schließlich erfordern diese Szenarien häufig Unterstützung für heterogene Nachrichtenformate und Transportprotokolle, einschließlich legacy-Systemen.

Aus diesen Gründen ist BizTalk Server 2006 in der Regel die beste Wahl für Organisationen, die auf die standardisierten, erweiterten und dynamischen Profile abzielen. Diese Organisationen betrachten in der Regel das Szenario "Long Running Business Process" als sehr wichtig für das Unternehmen und sehr häufig im Unternehmen; Daher erwerben sie BizTalk Server 2006 speziell, um eine standardisierte Plattform für sie einzurichten.

WF ist jedoch möglicherweise eine bessere Wahl für Organisationen, die sich im Standard-APIO-Profil befinden. Diese Organisationen suchen in der Regel nicht in die Erstellung einer standardisierten Anwendungsplattform zu investieren. Stattdessen möchten sie kostenminimieren, und die Lizenzierungs- und Hardwarekosten von BizTalk Server 2006 können unertragbar sein. Die Ausnahme dieser Anleitung besteht darin, dass anforderungen für hohe Skalierbarkeit, Überwachung und Unterstützung für eine Vielzahl von Nachrichtenformaten und Transportprotokollen bestehen. In diesem Fall würde die Kosten für die Erstellung der Hosting- und Messaging-Features von Grund auf wahrscheinlich die Kosten für BizTalk Server 2006 übersteigen, obwohl die Organisation nicht in ihre Anwendungsplattform investieren möchte.

Grundlegend Genormt Fortgeschritten Dynamisch

WF

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Abbildung 5. Webdienstaggregatorszenario

Sowohl BizTalk Server-Orchestrierungen als auch WF-Workflows unterstützen externe Webdienste von einem Workflow und die Bereitstellung des Workflows als Webdienst. Daher wird die Auswahl für die Erstellung von Webdienstaggregatorlösungen wie bei Lösungen für lange ausgeführte Geschäftsprozesse durch das Organisationsprofil und die Hostinganforderungen bestimmt.

Wenn der Aggregatwebdienst nur andere Webdienste aggregiert, bietet bizTalk Server 2006 die Möglichkeit, heterogene Nachrichtenformate und Transportprotokolle zu unterstützen, wenig Wert. Wenn der Dienst jedoch auch Daten aus älteren Umgebungen aggregieren sollte, die nicht als Webdienste verfügbar gemacht werden, würde BizTalk Server 2006 einen Mehrwert hinzufügen.

Da das Verwendungsmuster schnell, synchrone Anforderungs-/Antwortaufrufe ist, ist die Von BizTalk Server 2006 in der Regel bereitgestellte Lebensdauer der Nachricht nicht wichtig. Tatsächlich ist die Latenz, die durch die Persistenz für das MessageBox-Objekt eingeführt wird, tatsächlich eine Haftung. Der Hauptwert, den BizTalk Server 2006 für dieses Szenario bereitstellt, ist die Möglichkeit, die Bereitstellung auf vielen Servern zu verwalten und ausgeführte Instanzen zu überwachen. Die BAM-Funktion von BizTalk Server 2006 kann auch hilfreich sein, um zu überwachen, dass Vereinbarungen auf Serviceebene (Service Level Agreements, SLAs) erfüllt sind.

Aus diesen Gründen ist WF eine sehr gute Wahl für die Implementierung von Webdienstaggregatoren, insbesondere in Organisationen in den Standard- und Standardprofilen. Ein Beispiel, bei dem BizTalk Server 2006 vorteilhaft sein kann, ist eine, in der Sie eine große Anzahl von Endpunkten für verschiedene Clientorganisationen verwalten müssen. Die Konfiguration des Empfangsports und des Empfangsstandorts 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 das Anwenden auf Verschlüsselung/Entschlüsselung kann nützlich sein.

Future-Proofing

Sie möchten sicherstellen, dass Ihre Investitionen in Softwarelizenzierungskosten, beim Erlernen einer Workflowtechnologie und beim Erstellen bestimmter Workflowkomponenten ihnen künftig den größtmöglichen Nutzen bieten. Neben der Auswahl des richtigen Workflows für Ihr spezifisches Workflowszenario und Ihre Organisation 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 machen kein starkes Argument für die Auswahl einer technologie; Stattdessen handelt es sich um Datenpunkte, die Ihnen bei Ihrer Entscheidung helfen.

Was BizTalk Server 2006 R2 hinzufügt

BizTalk Server 2006 R2 fügt zwei Features hinzu, die sich auf Ihre Wahl 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 beim Erstellen Ihrer SOA eingeführt hat, hat die Tatsache, dass BizTalk Server 2006 die WCF-Unterstützung nicht als Plattform zum Erstellen und Hosten zusammengesetzter Webdienste disqualifiziert hat. Dies hat Sie möglicherweise in Richtung WF verschoben, auch wenn BizTalk Server 2006 ansonsten eine großartige Übereinstimmung für Ihre Szenarien und APIO-Profile war.

Glücklicherweise ist dies mit der Einführung einer großen WCF-Integration in BizTalk Server 2006 R2 kein Problem mehr. BizTalk Server 2006 verfügt jetzt über eine starke Integration in WCF, und es ist eine hervorragende Plattform für die Erstellung zusammengesetzter Dienste aus differenzierteren Diensten und die Bereitstellung dieser zusammengesetzten Dienste als WCF-Dienste.

BAM Interceptor für WF

Das zweite relevante BizTalk Server 2006 R2-Feature ist die Einführung des BAM-Interceptors für WF. Wenn es sich bei der Überwachung von Geschäftsaktivitäten um ein wichtiges Feature Ihrer Lösung handelt, wurden Sie möglicherweise auf die Verwendung von BizTalk Server 2006 hingeschoben – nur um die Vorteile von BAM zu nutzen – wenn WF andernfalls 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 weiterhin BAM als Unternehmens-Business-Activity Monitoring-Lösung nutzen.

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 präsentiert, um dem Geschäftsbenutzer einen End-to-End-Einblick in den Geschäftsprozess zu bieten. Ein leistungsstarker Aspekt der Funktionsweise von BAM für BizTalk Server 2006-Anwendungen besteht darin, dass die BAM-Überwachung nach der Bereitstellung einer BizTalk Server 2006-Anwendung konfiguriert werden kann, ohne dass Änderungen an den BizTalk Server 2006-Codeartefakten erforderlich sind.

BAM ist als unternehmensweite Unternehmensaktivitätsüberwachungslösung konzipiert; Daher ist es für Anwendungen ohne BizTalk Server 2006 möglich, Ereignisse und Daten in BAM zu feeden. Die APIs hierfür erfordern jedoch einen ziemlichen Code, der in den externen Anwendungen geschrieben werden muss. 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

Die BizTalk Server 2006-Erweiterungen für WF SDK wurden bei TechEd 2007 angekündigt und demoiert. Dieses SDK bietet einen einfachen Mechanismus zum Hosten von WF-Workflows in BizTalk Server 2006. Dieses Tool ist für .NET-Entwickler vorgesehen, die heute WF-Workflows erstellen und nach einer einfachen Möglichkeit suchen, um ein robustes, skalierbares Hosting dieser Workflows zu erreichen.

Das SDK stellt zwei benutzerdefinierte WF-Aktivitäten bereit: 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 kann. Als Entwickler definieren Sie WCF-DataContracts- für eingehende und ausgehende Nachrichten sowie eine ServiceContract- zum Definieren des Nachrichtenaustauschmusters. Innerhalb des WF-Workflows werden die btsReceive- und btsSend-Aktivitäten so konfiguriert, dass die definierten ServiceContract-verwendet werden, wie in Abbildung 6 dargestellt.

Abbildung 6. btsReceive- und btsSend-Aktivitäten für die 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 Wrapper-Orchestrierung zu generieren (siehe Abbildung 7), die den WF-Workflow initiiert und BizTalk Server 2006-Nachrichten an und von ihr leitet.

Die automatisch generierte Wrapper-Orchestrierung enthält Schemas für die nachrichten, die im ServiceContract-definiert sind. Sie enthält außerdem die BizTalk Server-Orchestrierungs-Shapes und den Code für den Empfang einer BizTalk Server 2006-Nachricht, das Erstellen und Starten der Workflowinstanz, das Übergeben eingehender Nachrichten an die Workflowinstanz, empfangen die ausgehenden Nachrichten und leitet sie zurück an das BizTalk Server 2006-Messagingmodul weiter. Um das Hosting Ihres WF-Workflows abzuschließen, müssen Sie nur die Wrapper-Orchestrierung kompilieren und bereitstellen und mithilfe des normalen BizTalk Server 2006-Mechanismus binden.

Abbildung 7. Automatisches Generieren einer Wrapper-Orchestrierung

Neben der Nutzung des robusten, skalierbaren Hostingmechanismus von BizTalk Server 2006 für WF-Workflows können Sie mit den BizTalk Server 2006-Erweiterungen für WF SDK die Vorteile der BizTalk Server 2006-Messaginginfrastruktur nutzen. So können Sie die vielen verfügbaren Adapter nutzen, um Nachrichten in BizTalk Server 2006 sowie die Pipelineverarbeitung zu erhalten, einschließlich der Zuordnungsfunktionen.

So leistungsfähig wie dies ist, sollten die BizTalk Server 2006-Erweiterungen für WF SDK als Tool verwendet werden, damit WF-Entwickler ihre Workflows auf BizTalk Server 2006 bereitstellen können – nicht als Ersatz für Orchestrierungen in Szenarien, in denen wir BizTalk Server 2006 als das richtige Tool identifiziert haben. Es gibt einige WF-Shapes, die nicht funktionieren, wenn sie in eine Orchestrierung eingeschlossen werden. Dies liegt daran, dass das Hosten Ihrer WF-Workflows in BizTalk Server 2006 mithilfe der BizTalk Server 2006-Erweiterungen für WF SDK nicht dasselbe Hostingverhalten wie systemeigene Orchestrierungen bietet. Das SDK enthält eine FAQ-Liste (in der Schnellstartanleitung enthalten), die diese Unterschiede beschreibt.

Schlussfolgerung

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 auszuwählen, welche für Ihr Projekt geeignet ist, müssen Sie zuerst ermitteln, welche workflowszenarien Sie verwenden.

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

Abbildung 8. Szenariospezifische Workflowtechnologien

Für die Szenarien "Long Running Business Process" und "Web Service Aggregator" können beide Technologien affektiv angewendet werden. Für diese Szenarien sollten Sie das aktuelle und kurzfristige ZIEL-APIO-Profil Ihrer Organisation bewerten. Organisationen, die sich entweder in den erweiterten oder dynamischen Profilen befinden, sollten BizTalk Server 2006 für diese Szenarien verwenden. Organisationen in den Profilen "Basic" und "Standard" können WF effektiv für diese Szenarien verwenden.

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

Nachtrag

Dispelling Misconceptions About BizTalk Server 2006 vs. WF

Im Folgenden finden Sie einige häufige Fehlverständnissen in Bezug auf WF und BizTalk Server 2006 und die klarstellenden Argumente, die wir verwenden, um sie zu dispeln:

  • WF ist der Ersatz für BizTalk Server 2006.Nein. Da WF das "neueste und beste" Angebot von Microsoft für Programmierworkflows ist, gehen viele, die mit BizTalk Server 2006 anfänglich nicht vertraut sind, davon aus, dass es mit der Veröffentlichung von WF veraltet wurde. Die einfache Antwort darauf, diesen Eindruck zu korrigieren, ist, dass WF ein Low-Level-Entwicklerframework zum Erstellen aller Arten von Workflows ist, während BizTalk Server 2006 ein vollständig geblasenes Serverprodukt mit erweiterten Features für eine bestimmte Kategorie von Workflowszenarien ist: Enterprise Integration. (Siehe Abbildung 1.)
    WF bietet nur eine kleine Teilmenge dieser Funktionalität: Workflow- und Geschäftsregeln. Obwohl WF eine einfachere, kostengünstigere Lösung für Szenarien sein kann, die nicht alle anderen Features erfordern, die BizTalk Server 2006 bereitstellt, ersetzt bizTalk Server 2006 in keiner Weise bizTalk Server 2006 für die wichtigsten Unternehmensintegrationsszenarien, die BizTalk Server 2006 für die Unterstützung entwickelt hat.
  • BizTalk Server geht ab.Nein. Eine ähnliche Fehleinschätzung ist der Eindruck, dass WF als Workflowtool der Zukunft veröffentlicht wurde und BizTalk Server noch nicht umgeschrieben wurde, um WF zu verwenden, Microsoft investiert nicht mehr in BizTalk Server und wird es schließlich durch ein neues WF-basiertes Produkt ersetzen. Dies ist nur nicht der Fall; BizTalk Server ist ein sehr erfolgreiches Produkt, und der Bereich Enterprise Integration, auf den es abzielt, ist weiterhin ein Bereich, den Microsoft unterstützt.
  • Sie müssen BizTalk Server 2006 über .NET Framework auswählen.Nein. Es ist möglicherweise verlockend für .NET-Entwickler, die mit BizTalk Server 2006 nicht vertraut sind, WF über BizTalk Server 2006 zu wählen, nur auf der Grundlage, dass sie lieber "rein" .NET gehen würden. Dies ist jedoch wirklich kein nützliches Kriterium; BizTalk Server 2006 selbst basiert auf .NET Framework.
    In der Tat stellt BizTalk Server 2006 mehr als 2 Millionen Zeilen .NET-Code dar, die auf Ihre Lösung angewendet werden können. So sparen Sie Zeit, Probleme und Kosten für die Entwicklung ihrer Funktionalität von Grund auf neu. Darüber hinaus erfolgt die BizTalk Server 2006-Programmierung innerhalb von Microsoft Visual Studio .NET, und die Komponenten werden als .NET-Assemblys kompiliert und bereitgestellt. Außerdem kombinieren die wichtigsten BizTalk Server 2006-Projekte BizTalk Server 2006-Komponenten mit benutzerdefinierten .NET-Komponenten; Daher sollte die BizTalk Server 2006-Entwicklung als spezialisierte .NET-Entwicklung betrachtet werden, anstatt als fremd oder anders.
    Die eigentliche Frage ist, ob die BizTalk Server 2006-Features genügend Wert für Ihr bestimmtes Workflowszenario bieten, um die Lizenzierungskosten zu rechtfertigen. Sie möchten keinen Ledgehammer verwenden, um Bilder zu hängen; Sie möchten auch nicht den Hammer eines Zimmermanns verwenden, um große Felsen zu zerkleinern.
  • 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-Integrationsbereich ausgerichtet sind. Wenn dies nicht Ihr Zielszenario ist, sind die Featurevergleiche bedeutungslos. BizTalk Server 2006 würde wahrscheinlich gewinnen, in Bezug auf die Anzahl der Feature-Kontrollkästchen; Dies ist jedoch ein Äpfel-zu-Orange-Vergleich, wenn sich diese Features nicht auf das Workflowszenario beziehen, auf das Sie abzielen.

Bestätigungen

Ich danke Paul Andrew und Kris Horrocks und allen, die diesen Artikel überprüft haben.

Weitere Informationen

Über den Autor

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