Im Mustercode 'TCPIP Handshake' wird der TCPIPServerInput-, TCPIPServerOutput- und
TCPIPServerReceive-Knoten verwendet.
Im Abschnitt TCP/IP-Übersicht der Dokumentation zu WebSphere Message broker finden Sie eine Übersicht über die Funktionsweise und Konfiguration dieser Knoten.
Die Verwendung dieses Musternachrichtenflusses ist sinnvoll, wenn ein vorhandener TCP/IP-Service durch einen WebSphere MQ-Service ersetzt wurde, aber einige Clients nicht auf den neuen Service migriert wurden.
Der vorhandene Service ist ein TCP/IP-Server, der einen Anfrage/Antwort-Service implementiert. Sowohl auf der Anforderungs- als auch der Antwortseite des Datenaustausches wird ein Dreiwege-Handshake ausgeführt. Der Dreiwege-Handshake bietet dem Client die Möglichkeit, eine Anforderung abzubrechen, deren Verarbeitung zu lange dauert. Da der Handshake in der Anwendungsschicht implementiert ist, kann der Abbruch ohne Unterbrechung der TCP/IP-Verbindung ausgeführt werden.
Anhand folgender Schritte wird der Handshake erläutert:
Anforderung:Während des Prozesses kann es zu Zeitverzögerungen kommen:
Der Client kann die Anforderungen an den folgenden beiden Punkten im Prozess abbrechen.
Das physische Format aller sechs Nachrichten ist als proprietäres Format definiert.
Der neue Service ist ein Anfrage/Antwort-Service von WebSphere MQ, der gemäß der WebSphere MQ-Standardkonvention mithilfe des Feldes Korrelations-ID der MQMD jede Antwort ihrer entsprechenden Anforderung zuordnet. Die Anforderungs- und Antwortnachrichten werden ausschließlich im XML-Format erstellt.
Der Nachrichtenfluss ist nur eine Art Fassade, die den neuen WebSphere MQ-Service in Bezug auf den Ablauf und das physische Format der ausgetauschten Daten wie den ursprünglichen TCP/IP-Service erscheinen lässt.
Der Nachrichtenfluss 'TCPIPMQVeneer' besteht aus drei untergeordneten Nachrichtenflüssen:
Mit diesem untergeordneten Nachrichtenfluss wird der Dreiwege-Handshake für den Empfang der Anforderung vom TCP/IP-Client implementiert.
Dieser untergeordnete Nachrichtenfluss ruft die Anforderung von der TCP/IP-Verbindung ab, sendet eine Empfangsbestätigung über dieselbe Verbindung zurück und wartet auf eine Anforderungsbestätigung.
Mit den Daten der Anforderung wird die Nachrichtenbaumstruktur des TCPIPServerInput-Knotens gefüllt. Die Empfangsbestätigung und die Anforderungsbestätigung werden beide in der lokalen Umgebungsbaumstruktur erstellt. Die Anforderungsnachricht wird vom untergeordneten Nachrichtenfluss nicht geändert.
Die Klassen 'MakeRequestAck' und 'CheckRequestConf', die vom MakeAcknowledgement- und CheckConfirmation-Knoten verwendet werden, geben Aufschluss darüber, wie die lokale Umgebung zum Erstellen der Empfangsbestätigung und Verwendung der Anforderungsbestätigung verwendet wird. Diese Klassen erstellen keine neuen Nachrichten vom Typ 'MbMessages'. Alle Änderungen werden an der lokalen Eingabeumgebung vorgenommen, die anschließend weitergegeben wird. Die Eingabenachricht wird nicht geändert. Dies ist aus folgenden Gründen wichtig:
Die Eigenschaft Position für ID ist für den TCPIPServerOutput- und TCPIPServerReceive-Knoten auf $LocalEnvironment/TCPIP/Input/ConnectionDetails/Id eingestellt, um sicherzustellen, dass das Zurücksenden der Empfangsbestätigung und Warten auf die Anforderungsbestätigung über dieselbe Verbindung erfolgt, über die die Anforderung empfangen wurde.
Für den TCPIPServerReceive-Knoten ist die Eigenschaft Zeitlimitüberschreitung bei Warten auf Datensatz (Sekunden) auf 60 Sekunden eingestellt und das Zeitlimitterminal des Knotens ist nicht über eine Wire-Verbindung verbunden. Wenn der Client eine Anforderung sendet, jedoch nach der Empfangsbestätigung des Servers nicht innerhalb von 60 Sekunden eine Anforderungsbestätigung sendet, wird vom TCPIPServerReceive-Knoten eine Ausnahmebedingung ausgelöst. Wenn die Anforderungsbestätigung nicht den erwarteten Wert enthält, wird in der Java-Klasse 'CheckRequestConf' des CheckConfirmation-Knotens von einer negativen Anforderungsbestätigung ausgegangen und die Anforderung wird an das Alternativterminal weitergegeben, das über eine Wire-Verbindung mit einem Throw-Knoten verbunden ist. Egal ob der Client eine negative Anforderungsbestätigung oder innerhalb von 60 Sekunden keine Anforderungsbestätigung sendet, beides führt zu demselben Ergebnis: Es wird eine Ausnahmebedingung ausgelöst, die zum Abbruch der Anforderung führt.
Mit diesem untergeordneten Nachrichtenfluss wird der Handshake mit WebSphere MQ implementiert, einschließlich der Datenumwandlung in das XML-Format.
Dieser untergeordnete Nachrichtenfluss erfüllt folgende Funktionen:
Entscheidend ist, dass die lokale Umgebung beibehalten oder kopiert wird, um sicherzustellen, dass die TCP/IP-Knoten im untergeordneten Nachrichtenfluss 'sendReply' dieselbe Verbindung verwenden können wie der untergeordnete Nachrichtenfluss 'receiveRequest'.
Der untergeordnete Nachrichtenfluss 'invokeMQService' kann durch den Aufruf eines anderen Servicetyps ersetzt werden, ohne dass die anderen beiden untergeordneten Nachrichtenflüsse geändert werden müssen.
Beispiele für Möglichkeiten zum Ändern oder Ersetzen des untergeordneten Nachrichtenflusses 'invokeMQService':
Anstelle eines MQGet-Knotens können Sie einen MQInput-Knoten verwenden, damit der WebSphere MQ-Service asynchron aufgerufen werden kann. Der Ausgabe dieses untergeordneten Nachrichtenflusses müssen jedoch die richtigen Werte in der lokalen Umgebung zugeordnet werden, damit der untergeordnete Nachrichtenfluss 'sendReply' dieselbe Verbindung wie der untergeordnete Nachrichtenfluss 'receiveRequest' verwenden kann. Daher muss die Zuordnung zwischen der WebSphere MQ-Nachrichten-ID und der Verbindungs-ID gespeichert werden. Der Mustercode 'HTTP Nodes' verdeutlicht, wie Sie diese Zuordnung als Nachrichten in einer anderen WebSphere MQ-Warteschlange speichern können. Darüber hinaus gibt es folgende Möglichkeiten zum Speichern der Zuordnung:
Wenn der TCP/IP-Server durch einen Web-Service ersetzt wird, muss anstelle des untergeordneten Nachrichtenflusses 'invokeMQService' der untergeordnete Nachrichtenfluss 'invokeWebService' verwendet werden. Der untergeordnete Nachrichtenfluss 'invokeWebService' wird mithilfe eines SOAPRequest-Knotens erstellt. Der Mustercode 'SOAP Nodes' veranschaulicht, wie ein Nachrichtenfluss für einen Web-Servicekonsumenten erstellt wird.
Mit diesem untergeordneten Nachrichtenfluss wird der Dreiwege-Handshake für den Sendevorgang der Antwort zurück zum TCP/IP-Client implementiert.
Mit diesem Nachrichtenfluss wird die Antwort gesendet. Dabei wird der Handshake dadurch abgeschlossen, dass zunächst auf eine Empfangsbestätigung vom Client gewartet und anschließend eine Antwortbestätigung zurück an den Client gesendet wird.
Dieser untergeordnete Nachrichtenfluss ist dem untergeordneten Nachrichtenfluss 'receiveRequest' in folgender Hinsicht ähnlich: