WS-Reliable Messaging

Die Nachrichtenflüsse werden importiert, ohne dass WS-Reliable Messaging aktiviert ist. Ähnlich wie beim TCP/IP-Monitor mit SOAP über HTTP kann jeder den Web-Service aufrufen und die Nachrichten lesen. Wenn Sie WS-Reliable Messaging aktivieren möchten, lesen Sie den Abschnitt Mustercode 'Address Book' erweitern.

Die Aktivierung von WS-RM ist eine Verwaltungsaufgabe, die auf der WebSphere Message Broker-Ebene ausgeführt wird. WS-RM kann beim Entwickeln der Nachrichtenflüsse nicht konfiguriert werden; Sie müssen die Richtlinie im Broker konfigurieren und sie mit Nachrichtenflüssen in einer Brokerarchivdatei (BAR) verknüpfen.

Vorteile von WS-Reliable Messaging

Im erweiterten Mustercode 'Address Book' haben der Nutzer und der Provider die gleichen Anforderungen an das Reliable Messaging:

  1. Die Zustellung einer SOAP-Nachricht muss bei einem nicht erwarteten Neustart eines Servers gewährleistet sein.
  2. Die Zustellung einer SOAP-Nachricht muss gewährleistet sein, wenn die Verbindung zwischen dem Client und Server beispielsweise aufgrund einer Zeitlimitüberschreitung unterbrochen wird. Der Client sollte in der Lage sein, die Bedingung zu erkennen und die Nachrichtenübertragung zu wiederholen.

Das WS-RM-Protokoll erfüllt diese Anforderungen, indem definiert ist, wie Nachrichten erneut gesendet werden, falls festgestellt wird, dass sie nicht erfolgreich zugestellt wurden. Außerdem verhindert es, dass doppelte Nachrichten an die Zielanwendung zugestellt werden.

Funktionsweise von WS-Reliable Messaging

Das wichtigste Konzept von WS-RM ist die Sequenz. Eine Sequenz in WS-RM ist ein Vertrag zwischen einem Web-Service-Client und einem Web-Service-Provider, in dem vereinbart wird, dass die wechselseitige Nachrichtenübertragung zuverlässig erfolgen muss. Mit der Sequenz wird der Status von gesendeten und empfangenen Nachrichten verwaltet. Die Sequenz selbst gilt speziell für den Endpunkt eines Providers. Wenn ein Client zum ersten Mal eine Nachricht an den Endpunkt eines Web-Service-Providers sendet, wird eine Sequenz für diesen Providerendpunkt erstellt, und alle nachfolgenden Nachrichten von diesem Client zu diesem Providerendpunkt werden in dieser Sequenz zugestellt. Die Sequenz ermöglicht dem client- und providerseitigen WS-RM die Entscheidung, ob Anwendungsnachrichten erneut zugestellt werden müssen, sowie die Erkennung, ob die eingehenden Nachrichten Duplikate sind.

Zur Definition von Sequenzen und Verwaltung des aktuellen Status verwendet das WS-RM des Clients und Providers eine Sammlung definierter Protokollnachrichten, die hin- und hergesendet werden. Im folgenden Diagramm ist ein typischer Nachrichtenfluss bei einem Web-Service des Typs 'Anforderung/Antwort' mit WS-RM dargestellt.

Typische WS-RM-Folge zum Nachrichtenaustausch, die in den unten genannten Schritten beschrieben wird.

Beispielszenario

Anhand der folgenden Schritte wird beschrieben, wie der Mustercode bei aktiviertem WS-RM funktioniert:

  1. Die Protokollvorbedingungen werden eingerichtet. Diese umfassen den Richtlinienaustausch, die Endpunktauflösung und die Einrichtung einer Vertrauensstellung.
  2. Der Nutzer fordert die Erstellung einer neuen Sequenz an.
  3. Der Provider erstellt eine neue Sequenz und liefert ihre eindeutige Kennung.
  4. Der Nutzer beginnt ab der Nachrichtennummer 1 mit der Nachrichtenübertragung in der Sequenz. Da jede vom SOAPRequest-Knoten gesendete Anforderung eine neue Sequenz erstellt, haben alle Nachrichten die Nachrichtennummer 1.
  5. Der Nutzer schließt außerdem einen AckRequested-Header ein, mit dem sichergestellt wird, dass für die Sequenz rechtzeitig eine Bestätigung (SequenceAcknowledgement) empfangen wird.
  6. Der Provider bestätigt als Reaktion auf den Empfang des Headers 'AckRequested' vom Nutzer den Empfang der Nachrichtennummern 1. Falls eine Nachricht aus irgendeinem Grund verloren geht, wird keine Bestätigung an den Nutzer gesendet.
  7. Der Nutzer überträgt die nicht bestätigte Nachricht erneut mit derselben Nachrichtennummer. Dabei handelt es sich aus Sicht des zu Grunde liegenden Transports zwar um eine Nachricht, da sie jedoch dieselbe Sequenz-ID und Nachrichtennummer aufweist, wird sie vom Provider als Duplikat der früheren Nachricht erkannt, falls die ursprünglichen und erneut übertragenen Nachrichten empfangen werden. Da der Nutzer in die erneut übertragene Nachricht einen AckRequested-Header eingeschlossen hat, beschleunigt der Provider die Ausgabe einer Bestätigung.
  8. Der Provider empfängt die zweite Übertragung der Nachricht mit der Nachrichtennummer 1 und bestätigt den Empfang der Nachrichtennummern 1.
  9. Der Nutzer empfängt diese Bestätigung und sendet eine TerminateSequence-Nachricht an den Provider, die darauf hinweist, dass die Sequenz abgeschlossen ist. Die TerminateSequence-Nachricht bedeutet, dass die Nachrichtennummer 1 die letzte Nachricht in der Sequenz war.
  10. Der Provider empfängt die TerminateSequence-Nachricht, die bedeutet, dass der Nutzer keine weiteren Nachrichten mehr senden wird. Der Provider sendet eine TerminateSequenceResponse-Nachricht an den Nutzer und gibt alle Ressourcen frei, die zu der Sequenz gehörten.

Im WS-RM-Richtliniensatz finden Sie nähere Informationen dazu, ob Nachrichten nacheinander zugestellt werden sollen oder nicht. Verwenden Sie das vorige Diagramm als Referenz.

Zurück zur Erweiterung des Mustercodes 'Address Book'

Zurück zum Beginn des Mustercodes