WS-Manager-Aliasnamen und -Cluster

DEFINE QREMOTE(YORK) RNAME(' ') RQMNAME(CLUSQM)

YORK kann als Aliasname für den WS-Manager CLUSQM verwendet werden. Wenn eine Anwendung auf dem Warteschlangenmanager, die diese Definition vorgenommen hat, eine Nachricht an den Warteschlangenmanager YORK stellt, löst der lokale WS-Manager den Namen in CLUSQM auf. Wenn der lokale WS-Manager nicht CLUSQM genannt wird, wird die Nachricht in die Clusterübertragungswarteschlange gestellt, die in CLUSQM verschoben werden soll. Außerdem ändert er den Übertragungsheader, um CLUSQM anstelle von YORK zu verwenden.

DEFINE QREMOTE(ROME) RNAME(' ') RQMNAME(PALERMO) XMITQ(X) CLUSTER(ITALY)

Der Befehl ist eine Aliasdefinition des Warteschlangenmanagers. Sie definiert und macht ROME als Warteschlangenmanager bekannt, über den Nachrichten von jedem WS-Manager im Cluster ITALY mit mehreren Hops zu ihrem Ziel in PALERMO gelangen können. Nachrichten, die in eine Warteschlange gestellt werden, die mit dem Namen des Warteschlangenmanagers, der auf ROME gesetzt ist, geöffnet wurde, werden mit der WS-Manager-Aliasdefinition an den Warteschlangenmanager-Warteschlangenmanager gesendet. Dort werden die Nachrichten in die Übertragungswarteschlange X gestellt und von Nicht-Clusterkanälen in den Warteschlangenmanager PALERMO verschoben.

Die Auswahl des Namens ROME in diesem Beispiel ist nicht signifikant. Die Werte für QREMOTE und RQMNAME können beide identisch sein.

Wenn ein WS-Manager eine Nachricht empfängt, extrahiert er den Namen der Zielwarteschlange und des Warteschlangenmanagers aus dem Übertragungsheader. Sie sucht nach einer WS-Manager-Aliasnamendefinition mit demselben Namen wie der Warteschlangenmanager im Übertragungsheader. Wenn er eine findet, ersetzt er den Warteschlangenmanagernamen im Übertragungsheader durch den RQMNAME aus der WS-Manager-Aliasdefinition.

Eine Anwendung kann mithilfe eines WS-Manager-Aliasnamens eine Nachricht an eine Warteschlange in einem anderen Cluster senden. Die Warteschlange muss keine Clusterwarteschlange sein. Die Warteschlange ist in einem Cluster definiert. Die Anwendung ist mit einem WS-Manager in einem anderen Cluster verbunden. Ein Gateway-WS-Manager verbindet die beiden Cluster. Wenn die Warteschlange nicht als Cluster-Cluster definiert ist, muss die Anwendung die Warteschlange unter Verwendung des Warteschlangennamens und des Aliasnamens eines Cluster-WS-Managers öffnen, damit die korrekte Weiterleitung erfolgt. Ein Beispiel für eine Konfiguration finden Sie unter Erstellen von zwei sich überschneidenden Clustern mit einem Gateway-Queue-Manager, dem der in Abbildung 1 dargestellte Antwortnachrichtenfluss entnommen ist.

Das Diagramm zeigt den Pfad, den die Antwortnachricht zurück zu einer temporären dynamischen Warteschlange mit dem Namen RQ nimmt. Die Serveranwendung, die mit QM3 verbunden ist, öffnet die Antwortwarteschlange unter Verwendung des Warteschlangenmanagernamens QM2. Der Name des Warteschlangenmanagers QM2 ist als gruppierter Warteschlangenmanager-Alias auf dem Gateway-Warteschlangenmanager QM1 definiert. QM3 leitet die Antwortnachricht an den Gateway-Warteschlangenmanager QM1 weiter. QM1 leitet die Nachricht an QM2 weiter.

Die Art und Weise, wie das Routing funktioniert, ist wie folgt. Jeder Warteschlangenmanager in jedem Cluster hat eine Warteschlangenmanager-Aliasdefinition auf dem Gateway-Warteschlangenmanager QM1. Die Aliasnamen werden in allen Clustern gruppiert. Die grauen gestrichelten Pfeile von jedem der Aliasnamen zu einem Warteschlangenmanager zeigen, dass jeder Warteschlangenmanager-Aliasname in mindestens einem der Cluster in einen echten Warteschlangenmanager aufgelöst wird. In diesem Fall wird der Aliasname QM2 sowohl in Cluster CL1 als auch in CL2 zusammengefasst und in den realen Warteschlangenmanager QM2 in CL1 aufgelöst. Die Serveranwendung erstellt die Antwortnachricht unter Verwendung des Namens der Empfangswarteschlange für Antworten RQ und des Namens des Antwortwarteschlangenmanagers QM2. Die Nachricht wird an den Gateway-Warteschlangenmanager QM1 weitergeleitet, da die Warteschlangenmanager-Aliasdefinition QM2 auf QM1 im Cluster CL2 definiert ist und der Warteschlangenmanager QM2 nicht im Cluster CL2 enthalten ist. Da die Nachricht nicht an den Zielwarteschlangenmanager gesendet werden kann, wird sie an den Warteschlangenmanager gesendet, der die Aliasdefinition enthält.

Der Gateway-Warteschlangenmanager QM1 stellt die Nachricht in die Cluster-Übertragungswarteschlange zur Übertragung an QM2. Der Gateway-Warteschlangenmanager QM1 leitet die Nachricht an QM2 weiter, da die Alias-Definition des Warteschlangenmanagers auf QM1 für QM2 QM2 als tatsächlichen Ziel-Warteschlangenmanager definiert. Die Definition ist nicht kreisförmig, da die Aliasdefinitionen nur auf reale Definitionen verweisen können. Der Aliasname kann nicht auf sich selbst verweisen. Die tatsächliche Definition wird vom Gateway-Warteschlangen-Manager QM1 aufgelöst, da sich sowohl QM1 als auch QM2 im selben Cluster befinden, CL1. Der Gateway-Warteschlangenmanager QM1 ermittelt die Verbindungsinformationen für QM2 aus dem Repository für CL1 und leitet die Nachricht an QM2 weiter. Damit die Nachricht von QM1 umgeleitet werden kann, muss die Serveranwendung die Antwortwarteschlange geöffnet haben, in der die Option DEFBIND auf MQBND_BIND_NOT_FIXED gesetzt ist. Wenn die Serveranwendung die Antwortwarteschlange mit der Option MQBND_BIND_ON_OPEN geöffnet hatte, wird die Nachricht nicht weitergeleitet und wird in einer Warteschlange für nicht zustellbare Nachrichten nicht mehr angezeigt.

Sie definieren eine Warteschlange mit dem Namen EDINBURGH in mehr als einem Warteschlangenmanager im Cluster. Sie möchten, dass der Clustering-Mechanismus die Auslastung für Nachrichten, die von außerhalb des Clusters in diese Warteschlange einreisen, ausgleichen soll.

Ein Beispiel für den Arbeitslastausgleich von außerhalb eines Clusters finden Sie unter Konfigurieren des Arbeitslastausgleichs von außerhalb eines Clusters