Grundlegendes zur dienstorientierten Lösung
Die dienstorientierte Lösung stellt eine als Dienst entworfene Anwendung zur Ermittlung des Kreditkartenkontostands dar. Die Anwendung verwendet zum Abrufen der für die Ermittlung des Kontostands benötigten Informationen drei Back-End-Anwendungen, die ebenfalls als Dienste zur Verfügung gestellt werden.
Als Ansatz weist die dienstorientierte Architektur (Service Oriented Architecture, SOA) einige Gemeinsamkeiten mit dem Erstellen verteilter Systeme auf. Ein dienstorientierter Ansatz zeichnet sich durch mehrere Merkmale aus:
Lose Verbindung. Die Geschäftslogik der Anwendung ist von der Logik zur Handhabung des Diensts getrennt.
Erkennbarkeit. Es sollte einen Mechanismus geben, mit dem Anwendungen den Dienst ausfindig machen können.
Vertrag. Die Schnittstelle zu dem Dienst implementiert den Vertrag zwischen den Benutzern und dem Dienst.
In Veröffentlichungen zum Thema werden dienstorientierte Ansätze häufig als mit Webdiensten identisch dargestellt, doch dies ist nicht unbedingt der Fall. Mit Webdiensten lassen sich dienstorientierte Lösungen gut implementieren, zum Erstellen von Diensten können aber auch andere Technologien, wie z. B. .NET-Remoting, verwendet werden.
Hinweise zur weiteren Lektüre
In der Dokumentation für diese Lösung wird davon ausgegangen, dass Sie mit BizTalk Server und Microsoft Visual Studio vertraut sind. Vorausgesetzt wird außerdem, dass Sie die grundlegenden Konzepte der Integration von Unternehmensanwendungen und von Webdiensten kennen.
Darüber hinaus sollten Sie zum Lesen und Befolgen der Entwicklerdokumentation mit dem Erstellen von Anwendungen mithilfe von Visual Studio und mit der Ausführung der folgenden Aufgaben vertraut sein: Erstellen von Projekten, Festlegen von Verweisen sowie Debuggen und Testen von BizTalk-Lösungen.
Ermitteln des Kreditkartenkontostands bei der Woodgrove Bank
Bei der dienstorientierten Lösung für die Woodgrove Bank handelt es sich um einen Dienst zum Ermitteln des Kreditkartenkontostands. Die Bank ist zwar fiktiv, das Szenario basiert jedoch auf einer tatsächlich bereitgestellten Kundenanwendung.
In diesem Szenario wird der Kreditkartenkontostand von zwei Quellen angefordert:
Einer IVR-Anwendung (Interactive Voice Response, interaktive Sprachantwort)
Einem interaktiven Client wie einer Webseite oder einer benutzerdefinierten Clientanwendung
Anforderungen von der IVR-Anwendung empfängt die Lösung über MQSeries. Anforderungen vom interaktiven Client werden mithilfe von HTTP und SOAP über einen Webdienst verarbeitet.
Neue Anwendungen mit dienstorientierter Architektur werden häufig zusammen mit älteren Anwendungen eingesetzt, die ältere Technologien nutzen. Gleichzeitig müssen sie mit modernen Anwendungen wie Websites zusammenarbeiten, die Webdienste verwenden. Das Szenario modelliert diese praktischen Anforderungen: Die IVR-Anwendung stellt eine ältere Anwendung dar, die Kundendienst-Clientanwendung eine moderne.
Die Anwendung der Woodgrove Bank verwendet zum Beantworten von Anforderungen Daten aus drei Back-End-Legacysystemen:
Einer Anwendung, in der der Kreditrahmen angegeben ist. Hierbei handelt es sich um ein SAP-System auf einem Großrechner.
Einem System für ausstehende Transaktionen, das die Gesamtsumme der ausstehenden Transaktionen für das Konto meldet. Bei diesem System handelt es sich um einen Großrechner oder ein AS/400-System. Zur Kommunikation mit dem Großrechner bzw. AS/400-System werden in der Lösung ein Webdienst und Microsoft Host Integration Server (HIS) verwendet.
Einem Zahlungsüberwachungssystem, das die zuletzt geleistete Zahlung im System zurückgibt. Die Kommunikation mit dem Zahlungsüberwachungssystem erfolgt mithilfe von MQSeries.
Nachdem die Informationen aus den Legacysystemen erfasst und zusammengestellt wurden, sendet die Lösung die Antwort an die Anwendung, von der die Anforderung ausging, und somit an den Kunden.
Geschäftliche Anforderungen
Da die Anwendung zur Ermittlung des Kreditkartenkontostands in Echtzeit auf Kundenanforderungen reagiert, ist eine geringe Latenzzeit unerlässlich, damit die Anforderungen schnell verarbeitet werden. Außerdem muss es möglich sein, eine große Anzahl gleichzeitiger Anforderungen zu verarbeiten. Da die Lösung mit vertraulichen Informationen arbeitet und eine öffentliche Schnittstelle aufweist, ist die Sicherheit von großer Bedeutung. Schließlich muss der Dienst auch zuverlässig sein.
Informationen dazu, wie die Lösung diese Anforderungen erfüllt, finden Sie unter Entwickeln einer dienstorientierten Lösung.
Leistungsmerkmale
Das Szenario weist die folgenden Leistungsmerkmale auf, um die Geschäftsanforderungen zu erfüllen:
Dauerhafter Durchsatz von 40 eingehenden Anforderungen pro Sekunde
Spitzendurchsatz von 100 eingehenden Anforderungen pro Sekunde
90 Prozent der Zu bearbeitenden Anforderungen (in und außerhalb BizTalk Server) in unter 1000 Millisekunden.
95 Prozent der Zu bearbeitenden Anforderungen (in und aus BizTalk Server) in unter 2000 Millisekunden.
Verarbeitung (Durchlaufen von BizTalk Server) von 100 Prozent der Anforderungen in weniger als 5.000 Millisekunden
Hinweis
In diesen Zeitangaben sind die Latenzzeiten der Back-End-Systeme nicht enthalten.
Drei Versionen
Es gibt drei Versionen der Lösung:
Bei der Stubversion werden alle Back-End-Systeme durch Softwarestubs ersetzt. Die Stubs simulieren die Back-End-Systeme. Mit dieser Version lässt sich die Lösung schnell auf einem einzigen Computer bereitstellen und ausführen.
In der Adapterversion werden BizTalk-Adapter zum Herstellen von Verbindungen mit den Back-End-Systemen verwendet. Diese Art der Implementierung ist auf den ersten Blick besonders nahe liegend. Das Senden von Nachrichten an die Back-End-Systeme mithilfe der Adapter erhöht jedoch die Latenzzeit der Antworten erheblich. Die Adapter selbst zeichnen sich zwar durch sehr niedrige Latenzzeiten aus, aber aufgrund der verteilten Architektur von BizTalk Server müssen die Adapter über die MessageBox mit den Hostinstanzen der Orchestrierung kommunizieren. Die Nachrichten durchlaufen also die Datenbank, was sich negativ auf die Latenzzeiten auswirkt.
Bei der Inlineversion werden die Adapter durch Inlinecode ersetzt, der direkt mit den Back-End-Systemen kommuniziert. Die Inlineversion der Lösung zeichnet sich daher durch die niedrigsten Latenzzeiten und den höchsten Durchsatz aus.
Das Bereitstellungshandbuch enthält Anweisungen zum Erstellen und Bereitstellen aller drei Versionen der Lösung. Außerdem wird erläutert, wie in allen Versionen die Verbindung mit dem System für ausstehende Transaktionen über HIS simuliert werden kann. Informationen zum Erstellen und Bereitstellen der Lösung finden Sie unter Bereitstellen der dienstorientierten Lösung.