Informationen zum Mustercode 'TCPIP Handshake'

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.

Vorhandener Service

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: Antwort:

Während des Prozesses kann es zu Zeitverzögerungen kommen:

Der Client kann die Anforderungen an den folgenden beiden Punkten im Prozess abbrechen.

  1. Nach dem Senden der Anforderung, jedoch bevor der Server mit deren Verarbeitung beginnt. Der Client kann die Anforderung abbrechen, indem er entweder eine negative Anforderungsbestätigung oder keine Anforderungsbestätigung sendet.
  2. Nachdem der Server mit der Verarbeitung der Anforderung begonnen, jedoch bevor er sie abgeschlossen hat. Der Client kann die Anforderung abbrechen, indem er entweder eine negative Antwortempfangsbestätigung oder keine Antwortempfangsbestätigung sendet.

Das physische Format aller sechs Nachrichten ist als proprietäres Format definiert.

Neuer Service

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.

Nachrichtenfluss 'TCPIPMQVeneer'

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.

Nachrichtenfluss 'TCPIPMQVeneer'

Der Nachrichtenfluss 'TCPIPMQVeneer' besteht aus drei untergeordneten Nachrichtenflüssen:

receiveRequest

Mit diesem untergeordneten Nachrichtenfluss wird der Dreiwege-Handshake für den Empfang der Anforderung vom TCP/IP-Client implementiert.

Untergeordneter Nachrichtenfluss 'receiveRequest'

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:

Entsprechend ist für den TCPIPServerOutput-Knoten die Eigenschaft Datenposition auf $LocalEnvironment/Variables/ReplyAcknowledgement/BLOB eingestellt, während für den TCPIPServerReceive-Knoten die Eigenschaft Position für Ausgabedaten auf $OutputLocalEnvironment/Variables/ReplyConfirmation eingestellt ist.

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.

invokeMQService

Mit diesem untergeordneten Nachrichtenfluss wird der Handshake mit WebSphere MQ implementiert, einschließlich der Datenumwandlung in das XML-Format.

Untergeordneter Nachrichtenfluss 'invokeMQService'

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':

sendReply

Mit diesem untergeordneten Nachrichtenfluss wird der Dreiwege-Handshake für den Sendevorgang der Antwort zurück zum TCP/IP-Client implementiert.

Untergeordneter Nachrichtenfluss 'sendReply'

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:

Zurück zum Beginn des Mustercodes