Interoperation mit IBM MQ: Schlüsselkonzepte von IBM MQ

Falls Sie mit den grundlegenden Konzepten von „ IBM MQ “ nicht vertraut sind, informieren Sie sich unter IBM MQ über die Objekte, die für die Zusammenarbeit mit WebSphere® Application Server wichtig sind.

Warteschlangen und Topics

Eine Warteschlange ist eine Datenstruktur zum Speichern von Nachrichten. Anwendungsprogramme können JMS- oder „ IBM MQ “-API-Aufrufe verwenden, um Nachrichten in „ IBM MQ “-Warteschlangen abzuspeichern. Andere Anwendungen können die Nachrichten aus den Warteschlangen abrufen.

Ein Topic ist das Subjekt der Informationen, die in einer Publish/Subscribe-Nachricht veröffentlicht werden. Anstatt eine Nachricht in eine bestimmte Warteschlange zu stellen, können Anwendungsprogramme eine Nachricht in einem Topic veröffentlichen. Andere Anwendungen subskribieren ein bestimmtes Topic, um alle Nachrichten, die in diesem Topic veröffentlicht werden, zu erhalten.

Wenn eine Anwendung eine Nachricht in eine Warteschlange stellt, gibt es nur eine Kopie der Nachricht. Selbst wenn mehrere Anwendungen Nachrichten aus der Warteschlange abrufen können, kann nur ein Konsument alle Nachrichten empfangen. Wenn eine Anwendung jedoch eine Nachricht in einem Topic veröffentlicht, können beliebig viele Subskribenten eine Kopie der Nachricht empfangen.

Warteschlangenmanager und Gruppen mit gemeinsamer Warteschlange

Jede „ IBM MQ “-Warteschlange wird von einem Warteschlangenmanager verwaltet. Der Warteschlangenmanager ist verantwortlich dafür, die Warteschlangen, deren Eigner er ist, zu verwalten und alle Nachrichten, die sie empfängt, in die richtigen Warteschlangen zu stellen. Anwendungsprogramme stellen eine Verbindung zu einem Warteschlangenmanager her, wenn sie Nachrichten in Warteschlangen stellen möchten. Warteschlangenmanager können Nachrichten aber auch während des normalen Betriebs in Warteschlangen stellen.

Ab „ IBM MQ “ Version 7 wird jedes Thema in „ IBM MQ “ ebenfalls von einem Queue-Manager verwaltet. Der Warteschlangenmanager empfängt Nachrichten von Publishern und Subskriptionen von Subskribenten. Der Warteschlangenmanager ist verantwortlich dafür, die veröffentlichten Nachrichten an die Subskribenten weiterzuleiten, die sich für das Topic, dem die Nachrichten zugeordnet sind, registriert haben. In früheren Versionen von „ IBM MQ “ wird die Publish/Subscribe-Kommunikation von einem Publish/Subscribe-Broker und nicht von Queue-Managern abgewickelt.

Unter IBM MQ for z/OS® können Sie gemeinsame Warteschlangen einrichten, auf die mehrere Warteschlangenmanager in einem Sysplex zugreifen können. Nachrichten, die in gemeinsam genutzte Warteschlangen gestellt werden, werden in einer „ zSeries “ Coupling Facility in Listenstrukturen gespeichert, während die Nachrichtendaten großer Nachrichten in einer gemeinsam genutzten „ DB2® “-Tabelle abgelegt werden.

Die Warteschlangenmanager, die auf dieselbe Gruppe gemeinsam genutzter Warteschlangen zugreifen können, bilden eine sogenannte Gruppe mit gemeinsamer Warteschlange. Jedes Mitglied der Queue-Sharing-Gruppe stellt eine Verbindung zu einem „ DB2 “-System her, um auf gemeinsam genutzte Definitionen für „ IBM MQ “-Objekte, darunter Warteschlangen und Kanäle, zuzugreifen. Jeder Warteschlangenmanager in der Gruppe kann die Nachrichten, die in einer gemeinsam genutzte Warteschlange gehalten werden, abrufen. Daher kann eine Anwendung, die auf eine der gemeinsam genutzten Warteschlangen zugreifen möchte, eine Verbindung zu einem beliebigen Warteschlangenmanager in der Gruppe mit gemeinsamer Warteschlange herstellen, damit die Anwendung nicht von der Verfügbarkeit eines bestimmten Warteschlangenmanagers abhängig ist.

Lokale Warteschlangen, ferne Warteschlangen und Cluster

In einem Netzwerk mit „ IBM MQ “ erfolgt die Kommunikation durch das Senden von Nachrichten von einem Queue-Manager oder (bei „ IBM “ MQ for z/OS ) einer Queue-Sharing-Gruppe an einen anderen.

IBM MQ Anwendungsprogramme können Nachrichten in eine lokale Warteschlange stellen, d. h. in eine Warteschlange des Warteschlangenmanagers, mit dem die Anwendung verbunden ist. Ein Warteschlangenmanager hat für jede seiner Warteschlangen eine Definition. Ein Warteschlangenmanager kann auch Definitionen für die Warteschlangen anderer Warteschlangenmanager haben. Aus der Perspektive des lokalen Warteschlangenmanagers betrachtet, mit dem die Anwendung verbunden ist, sind diese anderen Warteschlangen ferne Warteschlangen, und die Warteschlangenmanager, die ihre Eigner sind, sind ferne Warteschlangenmanager.

IBM MQ -Anwendungsprogramme, die mit einem lokalen Warteschlangenmanager verbunden sind, können nicht nur Nachrichten in eine lokale Warteschlange stellen, sondern auch Nachrichten an entfernte Warteschlangen senden. IBM MQ muss die Nachrichten dann an die Remote-Queue-Manager weiterleiten, denen die Remote-Queues gehören. Wenn Nachrichten für eine „ IBM MQ “-Warteschlange auf einem entfernten Warteschlangenmanager bestimmt sind, hält der lokale Warteschlangenmanager sie in einer Übertragungswarteschlange zurück, bis er bereit ist, sie an den entfernten Warteschlangenmanager weiterzuleiten. Eine Übertragungswarteschlange ist eine spezielle Art von lokaler Warteschlange, in der Nachrichten so lange gespeichert werden, bis sie ordnungsgemäß übertragen und im fernen Warteschlangenmanager gespeichert werden können.

IBM MQ Queue-Manager können mithilfe eines beliebigen der auf Ihrer „ IBM MQ “-Plattform verfügbaren Kommunikationsprotokolle zu einem Cluster verbunden werden. Wenn Sie Warteschlangenmanager zu einem Cluster zusammenfassen, werden die Warteschlangen weiterhin von den einzelnen Warteschlangenmanagern bereitgestellt (d. h., sie sind keine gemeinsam genutzten Warteschlangen). Warteschlangenmanager können jedoch, indem sie eine Verbindung zum Cluster herstellen, eine Nachricht an jeden anderen Warteschlangenmanager im Cluster senden und einige oder alle darin befindlichen Warteschlangen als Clusterwarteschlangen für alle anderen Warteschlangenmanager im Cluster verfügbar machen. Es ist nicht erforderlich, in jedem Warteschlangenmanager für jede ferne Warteschlange und für die Verbindung zu jedem fernen Warteschlangenmanager explizite Definitionen zu definieren. Jeder Warteschlangenmanager im Cluster verwendet auch eine einzelne Clusterübertragungswarteschlange, in der Nachrichten für alle anderen Warteschlangenmanager gehalten werden, damit Sie nicht für jeden fernen Warteschlangenmanager eine Übertragungswarteschlange definieren müssen.

Ab der Version 7 v IBM MQ s können Sie auch Queue-Manager v IBM MQ miteinander verbinden, die Themen für Publish/Subscribe-Messaging verwalten. Sie können Warteschlangenmanager, die Eigner von Topics sind, in einem Publish/Subscribe-Cluster zusammenfassen. Die Member können miteinander verknüpft sein oder in einer Publish/Subscribe-Hierarchie mit Eltern-Kind-Beziehungen zwischen den miteinander verbundenen Warteschlangenmanagern angeordnet werden. Veröffentlichungen und Subskriptionen für Topics können von Warteschlangenmanagern im Cluster oder in der Hierarchie gemeinsam genutzt werden.

Nachrichtenkanäle

IBM MQ Nachrichten, unabhängig davon, ob sie in Warteschlangen abgelegt oder an Themen veröffentlicht werden, werden über Nachrichtenkanäle zwischen den Warteschlangenmanagern übertragen. Ein Nachrichtenkanal ist eine unidirektionale Übertragungsverbindung zwischen zwei Warteschlangenmanagern. Er kann Nachrichten, die für eine beliebige Anzahl von Warteschlangen oder Topics in der fernen Warteschlange bestimmt sind, enthalten.

In „ IBM MQ “ können Sie die folgenden Arten von Nachrichtenkanälen definieren:
  • Sender-Empfänger-Kanal
  • Requester-Server-Kanal
  • Requester-Sender-Kanal
  • Server-Empfänger-Kanal
  • Cluster-Sender-Kanal
  • Cluster-Empfänger-Kanal

Wenn Sie z. B. den Nachrichtenkanaltyp "Sender-Empfänger-Kanal" definieren möchten, definieren Sie einen Senderkanal auf der Senderseite, z. B. im lokalen Warteschlangenmanager. Verwenden Sie anschließend denselben Namen, um einen Empfängerkanal auf Empfängerseite zu definieren, z. B. im fernen Warteschlangenmanager. Der Nachrichtenkanal ist unidirektional. Damit Nachrichten in beide Richtungen übertragen werden können, definieren Sie einen zweiten Kanal in entgegengesetzter Richtung zwischen den Warteschlangenmanagern.

Bei Warteschlangenmanagern in einem Cluster ist es nicht erforderlich, Nachrichtenkanäle zwischen jedem Warteschlangenmanagerpaar zu definieren. Stattdessen müssen Sie zwei Nachrichtenkanäle definieren, um jeden Warteschlangenmanager mit dem Cluster zu verbinden: einen Clusterempfängerkanal für das Empfangen von Nachrichten und einen Clustersenderkanal, mit dem der Warteschlangenmanager sich selbst einführt und Informationen zum Cluster erhält. Der Warteschlangenmanager kann dann eine Nachricht an einen anderen Warteschlangenmanager im Cluster senden.

Verwechseln Sie nicht Nachrichtenkanäle und MQI-Kanäle. Die „ MQI “ ist die Message-Queue-Schnittstelle in „ IBM MQ “, über die Anwendungen mit Queue-Managern interagieren. Ein „ MQI “-Kanal ist eine Art von Verbindung, die von einer „ IBM MQ “-Client-Anwendung genutzt wird, um eine Verbindung zu einem Queue-Manager herzustellen, der auf einem anderen System läuft, und um „ MQI “-Aufrufe an diesen Queue-Manager zu senden.