WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

Richtliniensätze

Mit Richtliniensätzen und Bindungen werden die von WebSphere Message Broker unterstützten WS-Security- und WS-RM-Anforderungen für die SOAPInput-, SOAPReply-, SOAPRequest-, SOAPAsyncRequest- und SOAPAsyncResponse-Knoten definiert und konfiguriert.

Ein Richtliniensatz ist ein Container für den Richtlinientyp 'WS-Security' und den Richtlinientyp 'WS-RM'.

Eine Richtliniensatzbindung ist einem Richtliniensatz zugeordnet. Sie enthält umgebungs- und plattformspezifische Informationen, beispielsweise die Schlüsselinformationen.

Mit Richtliniensätzen und Bindungen können Sie für SOAP-Anforderungs- und SOAP-Antwortnachrichten Folgendes definieren:

Der gesamte Nachrichtentext der SOAP-Nachricht oder Teile des Headers und des Nachrichtentextes können verschlüsselt und signiert werden.

Richtliniensätze und Bindungen werden mit dem WebSphere Message Broker Explorer verwaltet, mit dem Sie Richtliniensätze und Bindungen hinzufügen, löschen, anzeigen und bearbeiten können. Alle Änderungen an Richtliniensätzen oder Bindungen im Toolkit werden direkt im zugehörigen Broker gespeichert. Damit die neuen Konfigurationsdaten wirksam werden, müssen Sie den Nachrichtenfluss stoppen und anschließend erneut starten.

Sie können die Richtliniensätze und Bindungen auch aus einem Broker exportieren und importieren. Richtliniensätze und ihre zugehörigen Bindungen müssen gemeinsam gespeichert und wieder hergestellt werden.

Richtliniensätze werden im Brokerarchiveditor einem Nachrichtenfluss, einem Knoten oder beidem zugeordnet. Sie können die Angaben für Provider und Konsument auch einfach auf Nachrichtenflussebene angeben. Die Angabe des Providers gilt für alle SOAPInput- und SOAPReply-Knoten im Nachrichtenfluss. Die Angabe des Konsumenten gilt für alle SOAPRequest-, SOAPAsyncRequest- und SOAPAsyncResponse-Knoten. Es ist möglich, einzelne Richtliniensätze und Bindungen im Brokerarchiveditor auf Knotenebene zuzuordnen; diese haben dann Vorrang vor den auf Nachrichtenflussebene angegebenen Einstellungen für den Provider und Konsumenten. Die Standardeinstellung ist keine, d. h. keine Richtliniensätze und Bindungen werden verwendet.

Es können auch mehrere Knoten des gleichen Nachrichtenflusses auf denselben Richtliniensatz und dieselben Bindungen verweisen. Der Administrator muss sicherstellen, dass die benötigten Richtliniensätze während der Ausführungszeit zur Verfügung stehen. Wenn der Broker keine zugehörigen Richtliniensätze oder Bindungen findet, wird ein Fehler gemeldet.

Im verbleibenden Teil dieses Abschnitts werden einige Begriffe erläutert, die in Verbindung mit der Konfiguration von Richtliniensätzen und Bindungen verwendet werden.

Standardrichtliniensatz und Standardbindungen

Bei der Erstellung eines Brokers werden ein Standardrichtliniensatz und Standardbindungen erstellt (WSS10Default). Dieser Standardwert enthält eine eingeschränkte Sicherheitsrichtlinie, die vorgibt, dass in (eingehenden) Anforderungsnachrichten an SOAPInput-Knoten im zugehörigen Nachrichtenfluss ein Username-Token vorhanden ist. Darüber hinaus wird der WS-RM-Standardrichtliniensatz 'WSRMDefault' erstellt.

Die standardmäßige Richtliniensatzbindung bezieht sich auf den Standardrichtliniensatz 'WSS10Default', nicht auf 'WSRMDefault'. Beide können nicht bearbeitet werden.

Knoten als Konsument oder Provider

Bei Knoten handelt es sich entweder um Konsumenten oder um Provider.
Knoten als Konsumenten
  • SOAPRequest
  • SOAPAsyncRequest
  • SOAPAsyncResponse
Knoten als Provider
  • SOAPInput
  • SOAPReply

Anforderung und Antwort

Das Konzept 'Anforderung und Antwort' ist ein Muster des Nachrichtenaustauschs (MEP). Darunter versteht man einen Client, der eine SOAP-Anforderungsnachricht an einen Web-Services-Server sendet, der dem Client wiederum eine SOAP-Antwortnachricht zurücksendet. Die Anforderungsnachricht ist immer die vom Client an den Server gesendete SOAP-Nachricht, während die Antwortnachricht immer die vom Server an den Client gesendete Antwort auf die SOAP-Nachricht ist. In der folgenden Tabelle wird dies im Hinblick auf die SOAP-Knoten von WebSphere Message Broker beschrieben:
Knoten Aus der Sicht des Brokers Anforderung Antwort
SOAPInput Ankommende SOAP-Nachricht Ankommende Nachricht Nicht zutreffend
SOAPReply Abgehende SOAP-Nachricht Nicht zutreffend Abgehende Nachricht
SOAPRequest Abgehende SOAP-Nachricht gefolgt von einer ankommenden SOAP-Nachricht Abgehende Nachricht Ankommende Nachricht
SOAPAsyncRequest Abgehende SOAP-Nachricht Abgehende Nachricht Nicht zutreffend
SOAPAsyncResponse Ankommende SOAP-Nachricht Nicht zutreffend Ankommende Nachricht

Initiator und Empfänger

Die am Austausch von SOAP-Nachrichten beteiligten Rollen sind 'Initiator' und 'Empfänger'.
Initiator
Die Rolle, die innerhalb eines Nachrichtenaustausches die Startnachricht sendet.
Empfänger
Die Zielrolle, die die Startnachricht innerhalb eines Nachrichtenaustausches verarbeitet.
In der folgenden Tabelle werden diese Rollen im Hinblick auf die SOAP-Knoten beschrieben:
Knoten Aus der Sicht des Brokers Initiator Empfänger
SOAPInput Ankommende SOAP-Nachricht Externer Client, der eine SOAP-Nachricht an den Broker sendet SOAPInput-Knoten
SOAPReply Abgehende SOAP-Nachricht Externer Client, der die SOAP-Startnachricht an den Broker gesendet hat SOAPReply-Knoten
SOAPRequest (abgehend) Abgehende SOAP-Nachricht gefolgt von einer ankommenden SOAP-Nachricht SOAPRequest-Knoten Externer Provider, der die SOAP-Nachricht empfängt
SOAPRequest (eingehend) Abgehende SOAP-Nachricht gefolgt von einer ankommenden SOAP-Nachricht SOAPRequest-Knoten Externer Provider, der die SOAP-Nachricht empfängt
SOAPAsyncRequest Abgehende SOAP-Nachricht SOAPAsyncRequest-Knoten Externer Provider, der die SOAP-Nachricht empfängt
SOAPAsyncResponse Ankommende SOAP-Nachricht SOAPAsyncRequest-Knoten Externer Provider, der die SOAP-Nachricht empfängt

SOAPInput- und SOAPReply-Knoten

In diesem Diagramm ist der Broker der Empfänger. Ein SOAPInput-Knoten empfängt eine Nachricht von einem Client (dem Initiator). Ein SOAPReply-Knoten schickt eine Antwort. Eingehende und abgehende Nachrichten werden signiert und verschlüsselt.
Diese Abbildung veranschaulicht die Interaktion zwischen dem Nachrichtenbroker und dem Client bei Verwendung von SOAPInput- und SOAPReply-Knoten.
In der Anforderungsnachricht:
  • Der Initiator verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Brokers und signiert sie mit dem eigenen privaten Signaturtoken.
  • Der Broker entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Initiators.
In der Antwortnachricht:
  • Der Broker verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Initiators und signiert sie mit dem eigenen privaten Signaturtoken.
  • Der Initiator entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Brokers.

SOAPRequest-Knoten

Dieses Diagramm zeigt den Broker als Initiator. Über den SOAPRequest-Knoten sendet er eine synchrone Anforderung an einen externen Provider (den Empfänger). Eingehende und abgehende Nachrichten werden signiert und verschlüsselt. Die Verwendung von Token ist ähnlich wie im Beispiel mit den asynchronen SOAP-Knoten oben.
Diese Abbildung zeigt die Interaktion zwischen Nachrichtenbroker und Server bei Verwendung eines SOAPRequest-Knotens.
In der Anforderungsnachricht:
  • Der Broker verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Empfängers und signiert sie mit dem eigenen privaten Signaturtoken.
  • Der Empfänger entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Brokers.
In der Antwortnachricht:
  • Der Empfänger verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Brokers und signiert sie mit dem eigenen privaten Signaturtoken.
  • Der Broker entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Initiators.

Asynchrone SOAP-Knoten

Dieses Diagramm zeigt den Broker als Initiator. Über asynchrone SOAP-Knoten sendet er eine Anforderung an einen externen Provider (den Empfänger). Eingehende und abgehende Nachrichten sind signiert und verschlüsselt.

Diese Abbildung veranschaulicht die Interaktion zwischen Nachrichtenbroker und Server bei Verwendung asynchroner SOAP-Knoten.

In der Anforderungsnachricht:
  • Der Broker verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Empfängers und signiert sie mit dem eigenen privaten Signaturtoken.
  • Der Empfänger entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Brokers.
In der Antwortnachricht:
  • Der Empfänger verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Brokers und signiert sie mit dem eigenen privaten Signaturtoken.
  • Der Broker entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Initiators.
Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:20:25


KonzeptthemaKonzeptthema | Version 8.0.0.5 | ac60110_