Anwendungskommunikationsmodelle

Anwendungen können die Services eines Brokers nutzen, indem sie Nachrichten an ihn senden und von ihm empfangen; hierzu wird eines der unterstützten Übertragungsprotokolle verwendet.

Die Verfahrensweise hängt vom Protokoll selbst, der verwendeten Programmierschnittstelle und dem angenommenen Kommunikationsmodell ab.

WebSphere Message Broker unterstützt zwei Endbenutzeranwendungs-Kommunikationsmodelle:

  1. Point-to-point
  2. Publish/Subscribe

Eine einzelne Anwendung kann die beiden Stile nötigenfalls kombinieren. In einem gemischten Szenario enthält der Nachrichtenfluss, der die Nachrichten für diese Anwendung verarbeitet, mindestens einen Sende- und einen Veröffentlichungsknoten zusätzlich zu einem oder mehreren Empfangsknoten.

Die Programmierschnittstellen, die Sie in Ihren Anwendungen codieren können, werden in Anwendungsprogrammierschnittstellen beschrieben.

Point-to-point

Point-to-Point-Anwendungen nutzen ein Anforderung/Antwort- oder Client/Server-Modell oder senden eine Nachricht an viele Zielanwendungen mittels Verteilerlisten. Andere Anwendungen senden in eine Richtung mittels Senden ohne Antwort oder per Datagramm-Verkehr. Sie tauschen Informationen mit bekannten Partnern aus. Jede Anwendung bemerkt die Identität der Anwendung(en), mit der/denen sie kommuniziert. Es können Nachrichtenflüsse erstellt und konfiguriert werden, um sowohl Nachrichten mit Senden ohne Antwort als auch Anforderung/Antwort-Nachrichten zu verarbeiten und bei Ihren Brokern zu implementieren.

Der Text und die Diagramme verdeutlichen die Modelle 'Senden ohne Antwort' und 'Anforderung/Antwort'. Bei den Diagrammen wird davon ausgegangen, dass die Anwendungen das WebSphere MQ Enterprise Transport-Protokoll verwenden. Das Modell ist bei anderen Protokollen das gleiche, obwohl die Ressource, über die eine Nachricht gesendet bzw. empfangen wird, dann keine WebSphere MQ-Warteschlange ist.

Beim Modell 'Senden ohne Antwort' sendet eine Anwendung eine Nachricht, erwartet jedoch keine Antwort. Eine andere Anwendung kann optional eine Nachricht aufgrund der von der ersten Anwendung gesendeten Nachricht erhalten. Es ist möglich, dass keine Nachricht vom Nachrichtenfluss gesendet wird (z. B. wenn die gesendete Nachricht gerade eine Datenbankaktualisierung angefordert hat). Im Diagramm reiht der Absender eine Nachricht in die Eingabewarteschlange eines Nachrichtenflusses beim Broker (1) ein. Die Ausgabe des Nachrichtenflusses wird in die Warteschlange des Empfängers (2) eingereiht, von wo dieser sie abrufen kann (3).


Der Text über diesem Diagramm beschreibt den entsprechenden Inhalt.

Beim Anforderung/Antwort-Messaging sendet der Empfänger nach Erhalt einer Anforderungsnachricht dem Absender eine Antwort. Die Anforderungsnachricht wird bearbeitet, wie bei Nachrichten des Typs 'Senden ohne Antwort' beschrieben. Für die Antwort gibt es zwei Möglichkeiten:

  1. Der Empfänger sendet die Antwortnachricht direkt an den Absender zurück, ohne den Broker dabei einzubeziehen. Die Nachricht wird an ReplyToQ des Nachrichtendeskriptors (MQMD) der Anforderungsnachricht gesendet, die unverändert vom Broker weitergeleitet wird. (Falls Ihre Anwendungen WebSphere MQ nicht nutzen, müssen Sie einige andere Verfahren verwenden, um das Antwortziel zu bestimmen.)

    Im untenstehenden Diagramm reiht der Absender eine Nachricht in die Eingabewarteschlange eines Nachrichtenflusses beim Broker (1) ein. Die Ausgabe des Nachrichtenflusses wird in die Warteschlange des Empfängers (2) eingereiht, von wo dieser sie abruft (3). Der Empfänger sendet die Antwort direkt zur ReplyToQ des Absenders (4), von wo dieser sie abrufen kann (5).


    Der Text über diesem Diagramm beschreibt den entsprechenden Inhalt.
  2. Der Empfänger sendet die Antwortnachricht zu einem zugehörigen Nachrichtenfluss im Broker, so dass sie verarbeitet werden kann, bevor sie den Absender erreicht. In diesem Fall muss der Broker ReplyToQ des Absenders im MQMD der angeforderten Nachricht durch den Namen der Eingabewarteschlange des Antwortnachrichtenflusses ersetzen.

    Die Ausgabe dieses Antwortnachrichtenflusses muss an die ReplyToQ des Absenders erfolgen. Wenn der Name nicht fest ist, ist ein Mittel zum Verknüpfen dieser Warteschlange mit der Antwortnachricht erforderlich.

    Sie können hierzu beispielsweise eine Datenbank oder einen Dateneinfügeknoten im ersten Nachrichtenfluss einschließen, der die Antwortzielinformationen speichert, die dann vom zweiten Nachrichtenfluss abgefragt werden können.

    Alternativ hierzu können die relevanten Details im Nachrichtendeskriptor in einen Ordner des MQRFH2-Headers kopiert und mit der Nachricht übertragen werden.

    Im untenstehenden Diagramm reiht der Absender eine Nachricht in die Eingabewarteschlange des ersten Nachrichtenflusses beim Broker (1) ein. Die Ausgabe des Nachrichtenflusses wird in die Warteschlange des Empfängers (2) eingereiht, von wo dieser sie abruft (3). Der Empfänger sendet die Antwort an die Eingabewarteschlange des zweiten Nachrichtenflusses beim Broker (4). Nach der Verarbeitung der Antwort sendet der Broker sie an die Antwortwarteschlange (ReplyToQ) des Absenders (5), von wo dieser sie abrufen kann (6). (In diesem Fall muss der Sendeknoten den zweiten Nachrichtenfluss der Antwortwarteschlange (ReplyToQ) des Absenders kennen.)


    Der Text über diesem Diagramm beschreibt den entsprechenden Inhalt.

Vorhandene Anwendungen, die Sie mit dem Punkt-zu-Punkt-Modell geschrieben haben, können unverändert in einer WebSphere Message Broker-Umgebung ausgeführt werden, wenn sie eines der unterstützten Protokolle für die Kommunikation mit dem Broker verwenden.

Sie können die vorhandene Anwendungsfunktion mit Hilfe der Funktionen des Brokers verbessern und erweitern, um zusätzliche Partner einzuschließen. Beispiel: Eine Anwendung, die ähnliche Daten in unterschiedlichen Formaten handhabt, kann teilnehmen, da die ursprüngliche Nachricht durch einen Nachrichtenfluss im Broker ins erwartete Format konvertiert werden kann, ohne dass die absendende oder empfangende Anwendung geändert werden muss.

Wenn Sie eine Nachricht identifizieren, die eine zusätzliche Anwendungsverarbeitung erfordert, können Sie eine weitere Kopie der Nachricht im Nachrichtenfluss erstellen und an eine neue Anwendung senden, die für diese Verarbeitung entwickelt wurde. Die Ursprungsanwendungen bemerken die neue Aktion bezüglich der Nachricht nicht und führen unverändert ihre Arbeit fort.

Publish/Subscribe

Das Anwendungskommunikationmodell 'Publish/Subscribe' bezieht Anwendungen, die als Bereitsteller bekannt sind, und Anwendungen, die als Subskribenten bezeichnet werden, mit ein. Bereitsteller publizieren Nachrichten zu bestimmten Themen. Subskribenten erhalten Nachrichten, indem sie bestimmte Themen subskribieren. Eine einzelne Anwendung kann sowohl Bereitsteller als auch Subskribent sein.

Nachrichten, die von einem Bereitsteller publiziert wurden, können von beliebig vielen Subskribenten empfangen werden. Subskribenten können ebenfalls Nachrichten zu gleichen oder unterschiedlichen Themen und von beliebig vielen Bereitstellern empfangen.

Im unten stehenden Diagramm kann der Bereitsteller dem Broker 'Publish'- (Publizieren) oder 'Delete Publication' (Publizierung löschen)-Nachrichten senden. Der Broker leitet die Publish-Nachricht an Subskribenten weiter, die eine entsprechende Subskription aufweisen. Der Subskribent kann dem Broker Nachrichten des Typs 'Register Subscriber' (Subskribent registrieren), 'Deregister Subscriber' (Registrierung zurücknehmen) oder 'Request Update' (Aktualisierung anfordern) senden. Optionale Antwortnachrichten des Brokers werden dem Bereitsteller und dem Subskribenten gesendet.


Der Text über diesem Diagramm beschreibt den entsprechenden Inhalt.

Wenn Sie Endbenutzeranwendungen haben, die zum Publish/Subscribe-Modell geschrieben werden (z. B. mittels MQI oder AMI), können Sie diese wahrscheinlich in eine WebSphere Message Broker-Brokerdomain ohne Änderungen integrieren.

Sie können diese Anwendungen ebenfalls modifizieren oder neue schreiben, um den Vorteil fortgeschrittener Publish/Subscribe-Verarbeitung insbesondere für Subskribenten zu nutzen.

Das Publish/Subscribe-Modell und die von WebSphere Message Broker bereitgestellte Verarbeitung werden komplett in weiteren Themen beschrieben, die über die unten stehenden Links aufgerufen werden können.

Zugehörige Konzepte
Publish/Subscribe
Anwendungsprogrammierschnittstellen
Zugehörige Tasks
Nachrichtenflüsse entwickeln
Publish/Subscribe-Anwendungen erstellen
Zugehörige Verweise
Unterstützung von Endbenutzeranwendungen
Integrierte Knoten
Publish/Subscribe
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2005 Letzte Aktualisierung: Nov 17, 2005
ac00450_