Übersetzen der Muster der dienstorientierten Lösung
Dieser Abschnitt beschreibt, wie das Musterdiagramm von der Lösung in BizTalk Server-Elemente konvertiert wird.
Verbindungen und Vollständigkeitsbedingungen
Es kann an vielen Stellen mit dem Konvertieren der Muster in BizTalk Server-Komponenten begonnen werden. Allerdings stellen die Verbindungen zwischen den Komponenten tatsächlich deren Infrastruktur dar und sind deshalb ein empfehlenswerter Ausgangspunkt. Im Falle des Aggregatormusters muss außerdem überlegt werden, auf welche Weise ihm mitgeteilt werden soll, dass alle erforderlichen Informationen vorhanden sind. Dies wirkt sich sowohl auf die Verbindungen mit anderen Komponenten als auch auf den Entwurf des Musters aus.
Die Lösung muss auf bequeme, einheitliche Weise eingesetzt werden können. Über die Dienstschnittstelle wird angegeben, wie sich die Lösung von anderen Anwendungen einsetzen lässt. Weil die Lösung mit einer älteren Anwendung (Legacyanwendung) über IBM WebSphere MQ kommunizieren muss, muss IBM WebSphere MQ Teil der Dienstschnittstelle sein. Bei neueren Anwendungen dagegen scheint eine Webdienstschnittstelle die bessere Wahl zu sein. Eine Webdienstschnittstelle bietet anderen Anwendungen, die den Dienst nutzen, maximale Flexibilität. Hier kann die Flexibilität von BizTalk Server für eine duale Dienstschnittstelle genutzt werden. Informationen zum Verfügbarmachen von Orchestrierungen als Webdienste finden Sie unter Zuordnen von Orchestrierungen zu Webdiensten.
Die anderen Verbindungen sind diejenigen zwischen Dienstschnittstelle und Empfängerliste, zwischen Empfängerliste und Back-End-Anwendungen sowie zwischen Back-End-Anwendungen, Aggregator und Dienstschnittstelle.
Wenn die Verbindung mit der Empfängerliste synchron ist, muss die Lösung nicht mithilfe von Korrelationen sicherstellen, dass alle Nachrichten an die Empfängerliste gesendet und empfangen werden. Die Verbindungen zwischen den Back-End-Anwendungen und dem Aggregator können aus denselben Gründen synchron sein. Der Aggregator benötigt die Antworten aus allen drei Back-End-Anwendungen, um die Abfrageantwort abzuschließen. Die Antwortzeiten sollten kurz sein, damit synchrone Verbindungen geeignet sind und die Lösung vereinfachen.
Das Aggregatormuster enthält in der Regel eine Vollständigkeitsbedingung. Wenn mehrere Back-End-Server und langsame Antwortzeiten vorliegen, könnte von der Vollständigkeitsbedingung beispielsweise mindestens eine Antwort in einem bestimmten Zeitraum empfangen werden. Für diese dienstorientierte Lösung sind alle drei Antworten erforderlich, damit die endgültige Nachricht erstellt werden kann. Folglich empfängt die Vollständigkeitsbedingung hier alle drei Antworten.
Hinweis
Beim Empfangen von Anforderungen über IBM WebSphere MQ fügt die Lösung einen Korrelationsbezeichner hinzu, indem der MQMD_MsgId Wert in den MQMD_CorrelId der Antwortnachricht kopiert wird. Dies geschieht im Rahmen des Standardverfahrens, bei dem der MQSeries-Adapter in einer Anforderungsantwort verwendet wird, um eine mögliche Racebedingung zu vermeiden. Weitere Informationen finden Sie unter Korrelieren von Nachrichten mithilfe von Anforderung-Antwort.
Bestimmen der Orchestrierungsgrenzen
Die Lösung muss Anforderungen aus einer IBM WebSphere MQ-Warteschlange sowie über die Webdienstschnittstelle zulassen. Wenn die Dienstschnittstelle in eine Orchestrierung eingefügt wird, die IBM WebSphere MQ-Eingabe in eine andere Orchestrierung und die Masse der Verarbeitung in eine dritte, bleibt die externe Kommunikation von der Verarbeitung getrennt.
Konvertieren der Komponenten in Orchestrierungsformen
Die in Formen zu konvertierenden Muster sind in der endgültigen Lösung in einer einzigen Orchestrierung enthalten. Es gibt zahlreiche Möglichkeiten zum Erstellen eines inhaltsbasierten Routers in BizTalk Server, darunter das Erstellen von MessageBox-Abonnements. In der Lösung werden vom Routing MessageBox-Abonnements verwendet. Eine Form vom Typ Ausdruck überprüft aus, ob die Nachricht Werte für die Pflichtfelder enthält. Eine Form vom Typ Entscheidung überprüft die in der Form vom Typ Ausdruck festgelegte Variable und wählt den Pfad über die Orchestrierung aus.
Die CustomerService-Orchestrierung verwendet das parallele Shape, um Nachrichten an die Back-End-Anwendungen zu senden und gleichzeitig Antworten zu empfangen. Sie muss nicht warten, dass eine Anwendung beendet wird, bevor sie die nächste Anforderung sendet. Wenn sich die Anzahl der Anwendungen zu häufig änderte oder wenn die Verbindungen mit den Anwendungen unzuverlässig wären, müsste die Orchestrierung das Muster unterschiedlich konvertieren.
In der Lösung muss der Aggregator Elemente aus drei Antwortnachrichten kombinieren. Mithilfe der Form vom Typ Parallel wird sichergestellt, dass die Kommunikation mit den Back-End-Systemen parallel erfolgt. Und weil die Form erst beendet wird, nachdem sie alle Antworten oder ein Timeout empfangen hat, ist dem Aggregator immer bekannt, wann er den Vorgang fortsetzen kann. Die Orchestrierung verwendet eine Form vom Typ Transformation, die Elemente aus den drei Antwortnachrichten des Back-Ends und der ursprünglichen Anforderungsnachricht den Elementen in der Antwortnachricht zuordnet.
Hinweis
Bei der Kommunikation mit den Back-End-Systemen kann auch ein Timeout auftreten. Sie können den Timeoutzeitraum festlegen, indem Sie die Empfangsform in ein Scope-Shape einschließen und die Timeout-Eigenschaft des Bereichs festlegen.
Eine vollständige Liste der Orchestrierungs-Shapes finden Sie unter Orchestrierungs-Shapes.
Weitere Informationen
Muster in der dienstorientierten Lösung
Komponenten der dienstorientierten Lösung