Anwendungskommunikationsmodelle

Anwendungen können die Services eines Brokers nutzen, indem sie über eines der unterstützten Transportprotokolle Nachrichten an ihn senden und Nachrichten von ihm empfangen.

Die Art und Weise, wie dies geschieht, ist vom jeweiligen Protokoll, von der verwendeten Programmierschnittstelle und vom eingesetzten Kommunikationsmodell abhängig.

WebSphere Message Broker unterstützt zwei Kommunikationsmodelle für Endbenutzeranwendungen:

  1. Punkt-zu-Punkt
  2. Publish/Subscribe

Bei Bedarf kann eine einzige Anwendung beide Modelle kombiniert verwenden. In einem gemischten Szenario enthält der Nachrichtenfluss, der die Nachrichten für diese Anwendung verarbeitet, neben einem oder mehreren Empfangsknoten mindestens einen Sendeknoten und mindestens einen Veröffentlichungsknoten.

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

Punkt-zu-Punkt

Punkt-zu-Punkt-Anwendungen verwenden ein Request/Reply- oder Client/Server-Modell, oder sie senden eine Nachricht mit Hilfe von Verteilerlisten an viele Zielanwendungen. Andere Anwendungen senden Einwegnachrichten nach der Methode Send and forget (Senden ohne Antwort), oder sie senden Datagramme. Sie tauschen Informationen mit bekannten Partnern aus. Jede Anwendung kennt die Identität der Anwendung(en), mit der bzw. denen sie kommuniziert. Sie können Nachrichtenflüsse erstellen und konfigurieren, die sowohl Send-and-forget- als auch Request/Reply-Nachrichten verarbeiten, und diese auf Ihren Brokern einsetzen.

Der Text und die Diagramme unten veranschaulichen das Send-and-forget- und das Request/Reply-Modell. In den Diagrammen wird davon ausgegangen, dass die Anwendungen das WebSphere MQ Enterprise Transport-Protokoll verwenden. Das Modell gilt genauso auch für andere Protokolle, obwohl es sich bei der Ressource, über die eine Nachricht gesendet oder empfangen wird, nicht um eine WebSphere MQ-Warteschlange handelt.

Im Send-and-forget-Modell sendet eine Anwendung eine Nachricht, erwartet jedoch keine Antwort. Eine andere Anwendung empfängt optional möglicherweise eine Nachricht als Ergebnis der von der ersten Anwendung gesendeten Nachricht. Es ist möglich, dass keine Nachricht vom Nachrichtenfluss gesendet wird (z. B., wenn die zu sendende Nachricht gerade eine Datenbankaktualisierung angefordert hat). Im Diagramm stellt der Sender eine Nachricht in die Eingabewarteschlange eines Nachrichtenflusses auf dem Broker (1). Die Ausgabe des Nachrichtenflusses wird in die Warteschlange des Empfängers gestellt (2), aus der dieser sie abrufen kann (3).

Der Text über diesem Diagramm beschreibt dessen Inhalt.

Bei der Request/Reply-Nachrichtenübertragung sendet der Empfänger, nachdem er eine Anforderungsnachricht erhalten hat, eine Antwort an den Absender. Die Anforderungsnachricht wird so behandelt, wie für Send-and-forget-Nachrichten beschrieben. Für die Antwort stehen zwei Möglichkeiten zur Verfügung:

  1. Der Empfänger sendet die Antwortnachricht an den Absender, ohne den Broker einzubeziehen. Die Nachricht wird an die im Feld ReplyToQ im Nachrichtendeskriptor (MQMD) der Anforderungsnachricht angegebene Warteschlange für Antwortnachrichten gesendet. Der Broker leitet die Nachricht unverändert weiter. (Wenn Ihre Anwendungen nicht WebSphere MQ verwenden, müssen Sie ein anderes Verfahren zur Bestimmung der Zieladresse einsetzen.)

    Im unten gezeigten Diagramm stellt der Sender eine Nachricht in die Eingabewarteschlange eines Nachrichtenflusses auf dem Broker (1). Die Ausgabe des Nachrichtenflusses wird in die Warteschlange des Empfängers gestellt (2), aus der sie von diesem abgerufen wird (3). Der Empfänger sendet die Antwort direkt an die Warteschlange für Antwortnachrichten (ReplyToQ) des Absenders (4), der sie dann daraus abrufen kann (5).

    Der Text über diesem Diagramm beschreibt dessen Inhalt.
  2. Der Empfänger sendet die Antwortnachricht an einen Antwortnachrichtenfluss im Broker, so dass sie verarbeitet werden kann, bevor sie den Absender erreicht. In diesem Fall muss der Broker die im Feld ReplyToQ im MQMD der Anforderungsnachricht angegebene Warteschlange für Antwortnachrichten des Absenders durch den Namen der Eingabewarteschlange des Antwortnachrichtenflusses ersetzen.

    Die Ausgabe dieses Antwortnachrichtenflusses muss an die ReplyToQ des Absenders gehen. Wenn der Name festgelegt ist, gibt es kein Problem; andernfalls sind einige Maßnahmen erforderlich, um eine Zuordnung zwischen dieser Warteschlange und der Antwortnachricht herzustellen.

    Zu diesem Zweck können Sie beispielsweise einen Datenbank- oder Dateneinfügeknoten in den ersten Nachrichtenfluss einfügen, der die Zieladressdaten für die Antwort speichert, die dann vom zweiten Nachrichtenfluss abgerufen werden können.

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

    Im unten gezeigten Diagramm stellt der Sender eine Nachricht in die Eingabewarteschlange des ersten Nachrichtenflusses im Broker (1). Die Ausgabe des Nachrichtenflusses wird in die Warteschlange des Empfängers gestellt (2), aus der sie von diesem abgerufen wird (3). Der Empfänger sendet die Antwort an die Eingabewarteschlange des zweiten Nachrichtenflusses im Broker (4). Nachdem er die Antwort verarbeitet hat, sendet der Broker sie an die Warteschlange für Antwortnachrichten (ReplyToQ) des Absenders (5), der sie dann daraus abrufen kann (6). (In diesem Fall muss dem Sendeknoten des zweiten Nachrichtenflusses die ReplyToQ des Absenders bekannt sein.)

    Der Text über diesem Diagramm beschreibt dessen Inhalt.

Bestehende Anwendungen, die Sie unter Verwendung des Punkt-zu-Punkt-Modells 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 bestehende Anwendungsfunktion verbessern und erweitern, indem Sie mit Hilfe der Funktionen des Brokers weitere Partner hinzufügen. Beispielsweise kann eine Anwendung teilnehmen, die ähnliche Daten, aber in einem anderen Format bearbeitet, weil die ursprüngliche Nachricht von einem Nachrichtenfluss im Broker in das erwartete Format umgewandelt wird, ohne dass die sendende oder empfangende Anwendung geändert werden muss.

Wenn Sie eine Nachricht identifizieren, für die eine zusätzliche Anwendungsverarbeitung nötig ist, können Sie im Nachrichtenfluss eine Kopie der Nachricht erstellen und sie an eine neue Anwendung, die für die zusätzliche Verarbeitung entwickelt wurde, senden. Die ursprünglichen Anwendungen bekommen von dieser neuen Aktion für die Nachricht nichts mit und setzen ihre Arbeit unverändert fort.

Publish/Subscribe

Das Publish/Subscribe-Anwendungskommunikationsmodell beinhaltet Anwendungen, die als Publisher (veröffentlichende Stellen) bezeichnet werden, und Anwendungen, die als Subskribenten bezeichnet werden. Publisher stellen Nachrichten zur Verfügung, indem Sie Veröffentlichungen zu bestimmten Themen herausgeben. Subskribenten empfangen Nachrichten, indem Sie Themen subskribieren. Eine einzelne Anwendung kann sowohl Publisher als auch Subskribent sein.

Nachrichten, die von einem beliebigen Publisher veröffentlicht werden, können von einer beliebigen Zahl von Subskribenten empfangen werden. Subskribenten können auch Nachrichten, zu denselben oder verschiedenen Themen, von einer beliebigen Zahl von Publishern empfangen.

Im unten gezeigten Diagramm kann der Publisher Nachrichten zum Veröffentlichen (Publish) oder zum Löschen von Veröffentlichungen (Delete Publication) an den Broker senden. Der Broker leitet die Publish-Nachrichten an Subskribenten weiter, die eine entsprechende Subskription eingerichtet haben. Der Subskribent kann Nachrichten zum Anmelden als Subskribent (Register Subscriber), Abmelden als Subskribent (Deregister Subscriber) oder Anfordern einer Aktualisierung (Request Update) an den Broker senden. Optionale Antwortnachrichten vom Broker werden an den Publisher und den Subskribenten gesendet.

Der Text über diesem Diagramm beschreibt dessen Inhalt.

Wenn Sie bereits Endbenutzeranwendungen haben, die für das Publish/Subscribe-Modell geschrieben wurden (z. B. MQI oder AMI verwenden), können Sie diese Anwendungen normalerweise ohne Änderungen in eine WebSphere Message Broker-Brokerdomäne integrieren.

Sie können diese Anwendungen aber auch ändern oder neue schreiben, um die erweiterte Publish/Subscribe-Verarbeitung zu nutzen, die insbesondere für Subskribenten zur Verfügung gestellt wird.

Das Publish/Subscribe-Modell und die von WebSphere Message Broker bereitgestellte Verarbeitung werden in weiteren Abschnitten, auf die Sie über die unten aufgelisteten Links zugreifen können, ausführlich beschrieben.

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