Adressierung von Buszielen und IBM MQ-Warteschlangen
Um verstehen zu können, wie der Zugriff auf ein SIB-Ziel (Service Integration Bus) über IBM MQ und auf eine IBM MQ-Warteschlange über einen Service Integration Bus erfolgt, müssen Sie die verschiedenen Konventionen kennen, die die Adressierung dieser beiden Ressourcen steuern.
- Name des Warteschlangenmanagers
- Warteschlangenname
- Busname
- Zielname (Kennung)
In IBM MQ sind der Name des Warteschlangenmanagers und der Warteschlangenname auf jeweils 48 Zeichen beschränkt. Außerdem ist die Verwendung bestimmter Zeichen eingeschränkt. Weitere Informationen hierzu finden Sie im Artikel Namenskonventionen für IBM MQ. Die Äquivalente des Service Integration Bus weisen diese Einschränkungen nicht auf. Deshalb müssen beispielsweise Nachrichten von einer IBM MQ-Anwendung, die an ein Busziel mit einem Namen gesendet werden, der mehr als 48 Zeichen hat, eine Methode haben, den kürzeren Namen (der in IBM MQ verwendet wird) zu verwenden, um den längeren Namen (der im Service Integration Bus verwendet wird) adressieren zu können. Der Service Integration Bus verwendet für die Zuordnung des kürzeren Namens zum langen Namen ein Aliasziel. Es kann auch ein Alias verwendet werden, um eine Nachricht von einer Anwendung von WebSphere Application Server, die einen langen Namen (mit mehr als 48 Zeichen) verwendet, zu senden und an eine IBM MQ-Warteschlange weiterzuleiten. Weitere Informationen zu Aliaszielen finden Sie im Artikel Fremde Ziele und Aliasziele.
Schreibweise der Serviceintegration, Warteschlange@Warteschlangenmanager, für IBM MQ-Warteschlangen
Wenn die Serviceintegration eine Nachricht über einen IBM MQ-Link sendet, muss sie den fremden Bus kennen, der dem Gateway-Warteschlangenmanager bzw. der Gruppe mit gemeinsamer Warteschlange entspricht, und wenn die Zielwarteschlange in einem anderen Warteschlangenmanager oder einer anderen Gruppe mit gemeinsamer Warteschlange (nicht im Gateway) definiert ist, muss die Serviceintegration die Position der Zielwarteschlange kennen, damit sie den richtigen Namen im MQXQH-Feld RemoteQMgrName speichern kann. Eine Möglichkeit, dies zu erreichen, ist die Definition zweier fremder Busse: eines indirekt verbundenen Busses (in dem die Warteschlange definiert ist) und eines direkt verbundenen Busses (Gateway).
Ein diesbezügliches Beispiel finden Sie in der folgenden Abbildung. In der Abbildung ist Q2 im Warteschlangenmanager QM2 die Zielwarteschlange für eine Nachricht. In der Serviceintegrationskonfiguration im lokalen Bus ist QM2 als indirekt verbundener fremder Bus und QM1 als direkt verbundener temporärer Bus definiert. Q2 ist als fremdes Ziel mit dem Busnamen QM2 und dem Zielnamen (Kennung) Q2 definiert. Es ist zu beachten, dass die Serviceintegrationskonfiguration für den lokalen Bus keine Informationen zur Verbindung zwischen QM1 und QM2 enthält.

Auf diese Weise funktioniert der Zugriff auf eine ferne IBM MQ-Warteschlange problemlos. Wenn jedoch sehr viele Warteschlangenmanager oder Gruppen mit gemeinsamer Warteschlange über einen einzigen Gateway eine Verbindung zum Service Integration Bus herstellen, kann es mühsam sein, jeden einzelnen Manager bzw. jede einzelne Gruppe als indirekt verbundenen fremden Bus zu definieren. Deshalb unterstützt die Serviceintegration das folgende Sonderformat für Zielnamen für IBM MQ-Warteschlangen, das den Warteschlangennamen und den Warteschlangenmanagernamen, verbunden mit einem kommerziellen A, (@) enthält: Warteschlange@Warteschlangenmanager. Mit diesem Sonderformat müssen Sie keinen separaten indirekt verbundenen fremden Bus für die Serviceintegration mehr definieren, weil der Name Teil des Namens des Serviceintegrationsziels ist.
Ein diesbezügliches Beispiel finden Sie in der folgenden Abbildung. In der Abbildung ist Q2 im Warteschlangenmanager QM2 die Zielwarteschlange für eine Nachricht. In der Serviceintegrationskonfiguration im lokalen Bus ist QM2 nicht als fremder Bus definiert. Q2 ist als fremdes Ziel mit dem Busnamen QM1 und dem Zielnamen (Kennung) Q2@QM2 definiert. Es ist zu beachten, dass die Serviceintegrationskonfiguration für den lokalen Bus keine Informationen zur Verbindung zwischen QM1 und QM2 enthält.

Automatische Zuordnung des JMSReplyTo-Felds einer JMS-Nachricht
Die JMS-API enthält zwei Felder für die gemeinsame Nutzung von Informationen zum Ziel, an das eine Nachricht gesendet wird (JMSDestination), und zum Ziel, an das Antworten gesendet werden sollen (JMSReplyTo). Das Feld "JMSReplyTo" einer JMS-Nachricht, die von einem Service Integration Bus an IBM MQ (oder von IBM MQ an einen Service Integration Bus) übergeben wird, wird automatisch zugeordnet, so dass eine konsumierende Anwendung in IBM MQ der ursprünglichen WebSphere Application Server-Anwendung antworten kann.