Muster des Nachrichtenaustausches für WS-Addressing

In der W3C-Spezifikation Web Services Addressing (WS-Addressing) werden die wichtigsten WS-Addressing-Eigenschaften für die durch WSDL 1.0 definierten Muster des Nachrichtenaustausches explizit definiert. Diese Muster des Nachrichtenaustausches werden in diesem Artikel aufgeführt, wobei für jedes Muster die erforderlichen WS-Addressing-Eigenschaften dargestellt werden.

Unidirektionaler Nachrichtenaustausch

Dies ist eine direkte unidirektionale Nachricht, die in WSDL 1.0 als Eingabeoperation definiert ist. Das WSDL-Fragment für diese Operation hat das folgende Format:
<operation name="myOperation">
  <input message="tns:myInputMessage"/>
</operation>
Die folgenden WS-Addressing-Nachrichtenadressierungseigenschaften (Message Addressing Properties, MAPs) werden dem Nachrichtenheader einer unidirektionalen WS-Addressing-Eingabenachricht automatisch von der Clientlaufzeit des Anwendungsservers hinzugefügt, um Konformität mit der WS-Addressing-Spezifikation sicherzustellen.
Tipp: Sie können diese Werte mithilfe der IBM proprietären WS-Addressing-SPIs überschreiben.
Tabelle 1. Eigenschaften für die Nachrichtenadressierung mit WS-Addressing, die ein Client dem Nachrichtenheader einer unidirektionalen WS-Addressing-Eingabenachricht hinzufügt. In dieser Tabelle sind die verschiedenen Nachrichtenadressierungseigenschaften (MAP, Message Adressing Properties) namentlich aufgelistet und beschrieben.
Abstrakter WS-Addressing-MAP-Name in der Notationskonvention des W3C-XML-Informationssets Beschreibung einer unidirektionalen Eingabenachricht
[action] Die WS-Addressing-Aktion, die gemäß der verwendeten Version der WS-Addressing-Spezifikation generiert wird.
[reply endpoint] Der WS-Addressing-Antwortendpunkt, der anzeigt, dass keine Antworten auf diese Eingabenachrichten erwartet werden. Der Wert dieser Nachrichtenadressierungseigenschaft (MAP, Message-Addressing Property) ist abhängig von der verwendeten Version der WS-Addressing-Spezifikation.
[message id] Eine eindeutige, generierte Nachrichten-ID. Obwohl dieser Wert durch die Spezifikation nicht vorgegeben wird, wird er von der Laufzeit von WebSphere Application Server automatisch festgelegt.

Obwohl die WSDL-Operation für diesen Nachrichtenaustausch keine Antworten spezifiziert, können zugehörige Nachrichten als Teil eines anderen Nachrichtenaustausches gesendet werden. Insbesondere können Anwendungen die WS-Addressing-MAPs [reply endpoint] (Antwortendpunkt) und [fault endpoint] (Fehlerendpunkt) verwenden, um dem Ziel der unidirektionalen Nachricht mitzuteilen, wohin zugehörige Nachrichten gesendet werden sollten. Zur Weitergabe eines Antwortendpunkts oder eines Fehlerendpunkts ordnen Sie dem Anforderungskontext des JAX-WS-Objekts "BindingProvider" oder dem JAX-RPC-Stub- oder -Aufrufobjekt die geeignete Eigenschaft zu, um die Standardwerte zu überschreiben (siehe hierzu den Artikel Eigenschaften für die Nachrichtenadressierung mit den IBM proprietären Web-Services-Addressing-SPIs angeben und abrufen).

Bidirektionale Anforderungs-Antwort-Operation

Dies ist die Anforderungs-Antwort-Operation gemäß der Definition in WSDL 1.1. Der Teil der Operation, der die Antwort enthält, kann als Ausgabenachricht und/oder als Fehlernachricht definiert sein. Die folgenden Auszüge aus dem WSDL-Code zeigen die unterschiedlichen Definitionsformen für eine solche Operation:
<operation name="myOperation">
  <input message="tns:myInputMessage"/>
  <output message="tns:myOutputMessage"/>
  <fault="tns:myFaultMessage"/>
</operation>
<operation name="myOperation">
  <input message="tns:myInputMessage"/>
  <output message="tns:myOutputMessage"/>
</operation>
<operation name="myOperation">
  <input message="tns:myInputMessage"/>
  <fault="tns:myFaultMessage"/>
</operation>
Die Clientlaufzeit des Anwendungsservers stellt sicher, dass der SOAP-Header der abgehenden Anforderungsnachricht die relevanten WS-Addressing-Nachrichteninformationsheader enthält. Die WS-Addressing-Header müssen nicht von der aufrufenden Anwendung festgelegt werden. Es wird eine Antwort erwartet. Deshalb müssen Sie in der Anforderungsnachricht einen [reply endpoint] (Antwortendpunkt) oder einen [fault endpoint] (Fehlerendpunkt) angeben.
Tipp: In der Spezifikation 2005/08 ist ein unbestimmter Antwortendpunkt gültig, weil er standardmäßig auf eine Endpunktreferenz gesetzt wird, die den anonymen URI enthält.
Die folgende Tabelle enthält eine Zusammenfassung der MAPs, die das Produkt in einer Web-Service-Anforderung, die das Protokoll "WS-Addressing" verwendet, standardmäßig festlegt. Sie können diese Werte mithilfe der IBM proprietären WS-Addressing-SPIs überschreiben.
Tabelle 2. Eigenschaften für die Nachrichtenadressierung, die einer Web-Service-Anforderung hinzugefügt werden, die das Protokoll "WS-Addressing" verwendet. In dieser Tabelle sind die verschiedenen Nachrichtenadressierungseigenschaften (MAP, Message Adressing Properties) namentlich aufgelistet und beschrieben.
Abstrakter WS-Addressing-MAP-Name in der Notationskonvention des W3C-XML-Informationssets Beschreibung der Eingabenachricht einer Anforderungs-Antwort-Operation
[action] Die WS-Addressing-Aktion, die gemäß der verwendeten Version der WS-Addressing-Spezifikation generiert wird.
[message id] Eine eindeutige, generierte Nachrichten-ID.
Die folgende Tabelle enthält eine Zusammenfassung der MAPs, die das Produkt in einer WS-Addressing-Antwort oder -Fehlernachricht standardmäßig festlegt.
Tabelle 3. Eigenschaften für die Nachrichtenadressierung, die einer WS-Addressing-Antwort oder -Fehlernachricht hinzugefügt werden. In dieser Tabelle sind die verschiedenen Nachrichtenadressierungseigenschaften (MAP, Message Adressing Properties) namentlich aufgelistet und beschrieben.
Abstrakter WS-Addressing-MAP-Name in der Notationskonvention des W3C-XML-Informationssets Beschreibung der Eingabenachricht einer Anforderungs-Antwort-Operation
[action] Die WS-Addressing-Aktion, die gemäß der verwendeten Version der WS-Addressing-Spezifikation generiert wird.
[relationship] Ein Beziehungssatz, der eine Antwortbeziehung zu der in der Anforderungsnachricht übergebenen Nachrichten-ID enthält.
[message id] Eine eindeutige, generierte Nachrichten-ID. Obwohl sie durch die Spezifikation nicht vorgegeben wird, wird sie von der Laufzeit des Anwendungsservers automatisch erstellt.

Synchrone Anforderungs-Antwort-Operation

Standardmäßig, d. h., wenn Sie den Antwortendpunkt oder den Fehlerendpunkt nicht über die IBM proprietäre WS-Addressing-SPI festlegen, wird der Antwortteil einer bidirektionalen Nachricht entsprechend dem zu Grunde liegenden Protokoll zurückgegeben. Insbesondere im Fall einer HTTP-Anforderung wird die Antwort synchron for der HTTP-Antwort zurückgegeben.
Der Client sendet eine Nachricht an den Web-Service. Der SOAP-Header enthält das Element <wsa:To>http://example.com/fabrokam/acct</wsa:To>. Der Web-Service gibt eine synchrone Antwort zurück.

Wenn Sie für synchrone JAX-WS-Aufrufe den Antwortendpunkt oder den Fehlerendpunkt setzen, muss die von Ihnen definierte Endpunktreferenz den anonymen URI verwenden. Wenn die Endpunktreferenz den anonymen URI nicht verwendet, wird eine Ausnahme vom Typ "javax.xml.ws.WebServiceException" ausgelöst. Obwohl die Endpunktreferenz den anonymen URI verwendet, können Sie in der Endpunktreferenz Referenzparameter verwenden, um den Antwort- oder Fehlerendpunkt zu bestimmen.

Für JAX-WS-Anwendungen können Sie ein synchrones Nachrichtenaustauschmuster angeben, indem Sie einen WS-Addressing-Richtlinientyp anwenden und konfigurieren. Das Austauschmuster ist besonders im folgenden Szenario nützlich:
  • Web Services Security (WS-Security) ist nicht aktiviert, oder Sie haben kein Assembliertool verwendet, um festzulegen, dass die Elemente "ReplyTo" und "FaultTo" der SOAP-Nachricht signiert werden müssen. In dieser Situation kann ein JAX-WS-Endpunkt dazu verwendet werden, Nachrichten an einen Dritten zu senden und potenziell an einer Denial-of-Service-Attacke beteiligt zu sein. Zur Vermeidung solcher Attacken müssen Sie das asynchrone Nachrichtenaustauschmuster festlegen, und WS-Policy aktivieren, damit die Clients diese Anforderung erkennen können.
  • Ein JAX-WS-Client kommuniziert über eine NAT-Einheit. Die URIs in den Elementen "ReplyTo" und "FaultTo" der SOAP-Nachricht können nicht an eine solche Einheit weitergeleitet werden. In dieser Situation muss der Client den in der Spezifikation WS-Addressing definierten anonymen URI und ein synchrones Nachrichtenaustauschmuster verwenden. Damit sichergestellt ist, dass der Client diese Anforderungen auch dann erfüllt, wenn der Server über WS-Policy einen nicht anonymen URI im Element "ReplyTo" anfordert, müssen Sie auf dem Client das synchrone Nachritenaustauschmuster angeben.
Durch Aktivieren von WS-Policy können Sie sicherstellen, dass die Server und Clients diese Anforderung des synchronen Messaging kennen.

Asynchrone Anforderungs-Antwort-Operation

Das JAX-RPC 1.0-Programmiermodell erlaubt keine asynchronen Antworten oder Fehler für eine bidirektionale Anforderungs-Antwort-Operation.

Antworten auf Anforderungen, die an Endpunkte auf einem WebSphere Application Server gerichtet sind, oder Fehler, die von solchen Endpunkten generiert werden, sind gemäß der WS-Addressing-Spezifikation an den Antwortendpunkt oder an den Fehlerendpunkt gerichtet. Die Verbindung mit dem Anforderungsclient wird mit der Antwort HTTP 202 geschlossen.
Der Client sendet eine Nachricht an den Web-Service. Der SOAP-Header enthält das Element <wsa:ReplyTo>, das selbst wiederum das Element <wsa:address>http://example.com/fabrokam/acct/replyEP</wsa:address> enthält. Der Web-Service sendet eine Antwort an den Antwortendpunkt. Der SOAP-Header der Antwortnachricht enthält das Element <wsa:To>http://example.com/fabrokam/acct</wsa:To>.
Für asynchrone JAX-WS-Aufrufe wird der Antwortendpunkt automatisch für die JAX-WS-Implementierung generiert. Wenn Sie versuchen, einen Antwortendpunkt oder einen Fehlerendpunkt zu definieren, wird eine Ausnahme vom Typ "javax.xml.ws.WebServiceException" ausgelöst.
[Windows]Anmerkung: In Windows-Betriebssystemen muss der vom Client gesendete Name des lokalen Hosts vom Zielservice auflösbar sein. Andernfalls können die Antworten die Clientanwendung nicht erreichen. Alternativ dazu können Sie den Client so konfigurieren, dass er seine Adresse im IP-Format sendet. Dadurch verlieren Sie jedoch die Vorteile von DHCP. Weitere Informationen finden Sie im Artikel JAX-WS-Web-Services asynchron aufrufen.
Es gibt viele verschiedene Möglichkeiten, ein asynchrones Nachrichtenaustauschmuster für JAX-WS-Anwendungen anzugeben. Dieses Austauschmuster ist besonders dann nützlich, wenn ein JAX-WS-Endpunkt eine lange Aufrufzeit hat. Die Verbindung wird zwar mithilfe von Client- und Serverressourcen offen gehalten, aber diese Ressourcennutzung kann unpraktisch sein, wenn der Service eine lange Antwortzeit hat.
Die Konfiguration des Nachrichtenaustauschmusters wird im WSDL-Dokument in Form vom WS-Policy-Zuordnungen ausgedrückt. Clients können auf die Konfigurationsinformationen zu diesem Nachrichtenaustauschmuster zugreifen, wenn mindestens eine der folgenden Bedingungen erfüllt ist:
  • Die gemeinsame WS-Policy-Nutzung ist aktiviert.
  • Die gemeinsame WS-Policy-Nutzung ist nicht aktiviert, aber Folgendes gilt:
    • Das (mit einer Anforderung HTTP GET abgerufene) WSDL-Paket enthält die relevanten Richtlinieninformationen.
    • Im Code wurden @Addressing-Annotationen verwendet. In diesem Fall generiert die Serverlaufzeit ein WSDL-Dokument mit den WS-Policy-Zuordnungen.
Weitere Einzelheiten finden Sie im Artikel Web-Service-Provider und gemeinsame Nutzung der Richtlinienkonfiguration.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_wsa_meps
Dateiname:cwbs_wsa_meps.html