Web-Service-Clients und Richtlinienkonfiguration zur Verwendung der Service-Provider-Richtlinie

Wenn ein Service-Provider seine Richtlinie in seiner WSDL (Web Services Description Language) veröffentlicht, kann die Richtlinienkonfiguration eines Service-Clients in WebSphere Application Server auf der Basis der vom zugehörigen Service-Provider unterstützten Richtlinien dynamisch erfolgen.

Der Service-Provider muss seine Richtlinie im WS-PolicyAttachment-Format in seiner WSDL veröffentlichen, und der Client muss diese Providerrichtlinien unterstützen. Der Client kann seine Richtlinienkonfiguration vollständig auf die Richtlinie des Providers abstimmen oder er kann sie nur teilweise auf die Richtlinie des Providers abstimmen mit den Einschränkungen, die in der Konfiguration des Richtliniensatzes auf dem Client definiert sind.

Ein Client übernimmt die Providerrichtlinie, indem er entweder eine HTTP-Get-Anfoderung oder das Protokoll Web Services Metadata Exchange (WS-MetadataExchange) verwendet, um die WSDL des Providers anzufordern. Die Art und Weise, wie der Client die Providerrichtlinie anfordert kann an dem Endpunkt, an dem die Richtlinie übernommen wird, über die Administrationskonsole oder mit wsadmin-Befehlen konfiguriert werden. Wenn Sie die Richtlinie mit dem Protokoll WS-MetadataExchange vom Provider anfordern, hat dies den Vorteil, dass Sie WS-MetadataExchange-GetMetadata-Anforderungen mithilfe eines geeigneten Systemrichtliniensatzes schützen können.

Wenn die Providerrichtlinie eine WSDL mit mehreren Teilen verwendet, können Sie eine HTTP-Get-Anforderung verwenden, um die Richtlinie des Providers abzurufen, aber Sie können nicht das Protokoll "WS-MetadataExchange" verwenden. Weitere Informationen zu WSDLs mit mehreren Teilen finden Sie im Artikel zu WSDL.

Die Richtlinie auf der Seite des Webanwendungsclients wird berechnet und als Laufzeitkonfiguration zwischengespeichert. Die ermittelte Richtlinie ist die so genannte effektive Richtlinie und wird für nachfolgende abgehende Web-Service-Anforderungen an den Endpunkt bzw. die Operation verwendet, für den bzw. die die Ermittlung durchgeführt wurde. Die ursprüngliche Konfiguration des Richtliniensatzes auf dem Client ändert sich nicht.

Für einen bestimmten Service findet die dynamische Richtlinienkonfiguration standardmäßig nur einmal statt. Es wird davon ausgegangen, dass diese Konfiguration für alle Endpunkte, die einen Service implementieren, gleich ist, weil sie dieselbe WSDL haben. Die Richtlinienberechnungen, die auf dieser WSDL basieren, werden in der Clientlaufzeit zwischengespeichert (sie sind nicht persistent) und mit jedem Zielservice gemeinsam genutzt.

In einer Clusterumgebung bedeutet dies beispielsweise, dass der Client die Providerrichtlinie nicht erneut für jede Endpunktinstanz eines Web-Service anfordert.

In WebSphere Application Server Version 8.0 und höher besteht die Möglichkeit, eine Servicereferenz so zu konfigurieren, dass sie für die WSDL, die für den Clientservice konfiguriert ist, ein anderes WSDL-Dokument verwendet. Standardmäßig übernehmen Servicereferenzen ihre Richtliniensatz- und WS-Policy-Konfiguration von ihrem übergeordneten Service, können jedoch, falls gewünscht, überschrieben werden. Nähere Einzelheiten finden Sie im Artikel WS-Policy für den Austausch von Richtlinien in einem Standardformat verwenden.

Wenn für jede Endpunktimplementierung eine eigene Richtlinienkonfiguration erforderlich ist, müssen Sie für jeden Endpunkt einen neuen Port erstellen. Anschließend können Sie für jeden Endpunkt eine eigene Richtlinienkonfiguration angeben.

Transportrichtlinien wie HTTP, SSL und JMS können nicht im WS-PolicyAttachment-Format ausgedrückt werden. Daher kann der Client die Transportrichtlinien nicht vom Service-Provider übernehmen. Wenn der Client Transportrichtlinien benötigt, müssen Sie diese Richtlinien als Teil der Konfiguration des Richtliniensatzes auf dem Client konfigurieren.

Wenn die Zielposition einer HTTP-GET-Anforderung mit dem Endpunkt identisch ist, verwendet die Anforderung dieselben HTTP- und SSL-Transportrichtlinien wie die Anwendung. Ist die HTTP-GET-Anforderung an einen anderen Endpunkt gerichtet, können Sie auch einen Systemrichtliniensatz mit anderen HTTP- und SSL-Transportrichtlinien anhängen.

Bei einer Anforderung vom Typ "WS-MetadataExchange GetMetadata" wird die WS-Security-Konfiguration im angegebenen Systemrichtliniensatz verwendet. Die HTTP-Eigenschaften werden von der Anwendung übernommen.

Ein Client, der für die Verwendung von Security Assertion Markup Language (SAML) konfiguriert ist, kann eine dynamische Richtlinienkonfiguration verwenden. Der Client muss jedoch für die Verwendung allgemeiner Bindungen konfiguriert sein.

Richtlinie in einer Registry

Ein Client kann die Richtlinienkonfiguration eines Web-Service-Providers über eine HTTP-Get-Anforderung aus einer Registry wie WebSphere Service Registry and Repository (WSRR) abrufen.

Die WSDL-Datei für die Richtlinie des Service-Providers und die entsprechenden Richtlinien und Richtlinienzuordnungen werden in einer Registry wie WSRR gespeichert. Diese Richtlinie muss die Richtlinienkonfiguration im WS-PolicyAttachments-Format enthalten. Der Client muss diese Providerrichtlinien unterstützen.

Die Registry muss die Verwendung von HTTP-Get-Anforderungen unterstützen, damit die WSDL-Datei, die WS-Policy-Zuordnungen enthält, z. B. WSRR Version 6.2 oder höher, veröffentlicht werden kann.

Sie können die Providerrichtlinie, die der Client aus einer Registry abruft, auf Service - oder Servicereferenz ebene, aber nicht auf Anwendungsebene anwenden.

Wenn eine sichere Verbindung zwischen dem Client und der Registry besteht, müssen Sie sicherstellen, dass das Vertrauen zwischen dem Anwendungsserver und dem Registry-Server hergestellt ist.

Wenn die Registry eine Authentifizierung erfordert, müssen Sie außerdem eine Richtlinie für die Authentifizierung abgehender Serviceanforderungen an die Registry konfigurieren. Die HTTP- und HTTPS-Berechtigungsnachweise werden standardmäßig für den Web-Service-Endpunkt und die Registry verwendet. Deshalb wird empfohlen, alle Berechtigungsnachweise zu sichern und sicherzustellen, dass diese Berechtigungsnachweise nicht an einen nicht berechtigten Endpunkt gesendet werden. Sie können auch einen Systemrichtliniensatz mit anderen HTTP- und SSL-Transportrichtlinien anhängen.

Übernahme der Richtlinie

Die Providerrichtlinie kann auf Anwendungs- oder Serviceebene zugeordnet werden. Endpunkte und Operationen übernehmen ihre Richtlinienkonfiguration vom relevanten Service.

Berechnung der Richtlinie

Die Schnittmenge der Richtlinien basiert auf dem Vergleich zwischen einer Clientrichtlinie und einer Providerrichtlinie, um festzustellen, ob sie kompatibel sind, und der Berechnung der neuen Richtlinie, die mit den Anforderungen und Leistungsmerkmalen beider übereinstimmt. Wenn Sie eine Richtlinien von einem Serviceanbieter erhalten, können Sie auswählen, ob nur die Providerrichtlinie verwendet werden soll oder die Client- und die Providerrichtlinie. Das Ergebnis der Schnittmenge der Richtlinien sieht wie folgt aus:
  • Wenn Sie lediglich eine Providerrichtlinie angeben, basiert die berechnete Richtlinie auf der Schnittmenge, die sich aus allen vom WAS-Client unterstützten Richtlinien und der Providerrichtlinie ergibt. Die Richtlinie wird somit tatsächlich vom Provider unterstützt, sofern der Client diese Richtlinie unterstützen kann. Die Richtlinienkonfiguration ist verfügbar, wenn der Punkt im Geltungsbereich (die Endpunktoperation), dem die Providerrichtlinie zugeordnet ist, keinem Clientrichtliniensatz zugeordnet ist und keinen zugeordneten Richtliniensatz von übergeordneten Punkten des Geltungsbereichs übernimmt.
  • Wenn Sie eine Client- und eine Providerrichtlinie angeben, basiert die berechnete Richtlinie auf der Schnittmenge von Client- und Providerrichtlinie. Die Richtlinie entspricht somit tatsächlich dem Clientrichtliniensatz, der jedoch durch Providerrichtlinien weiter eingeschränkt sein kann. Die Richtlinie, die für den Client akzeptabel ist, wird entweder durch den Richtliniensatz definiert, der dem Punkt des Clientgeltungsbereichs zugeordnet ist oder durch den Richtliniensatz, den der Punkt des Clientgeltungsbereichs von einem übergeordneten Punkt des Geltungsbereichs übernimmt. Die Richtlinienkonfiguration ist verfügbar, wenn der Punkt im Geltungsbereich (die Endpunktoperation), dem die Providerrichtlinie zugeordnet ist, einem Clientrichtliniensatz zugeordnet ist oder einen zugeordneten Richtliniensatz von übergeordneten Punkten des Geltungsbereichs übernimmt.

Die WS-Policy-Sprache stellt eine Möglichkeit bereit, um die Auswahl mehrerer Richtlinien auszudrücken. Daher könnte die Berechnung der Richtlinie zu mehreren Ergebnissen führen. Beispielsweise könnte der Service-Provider sowohl WS-ReliableMessaging 1.0 als auch WS-ReliableMessaging 1.1 unterstützen. Wenn der Client ebenfalls beide Versionen unterstützt, könnte der Client bei seinen Web-Service-Anforderungen an den Provider jede dieser Versionen verwenden. In dieser Situation, in der mehrere Spezifikationsversionen für den Client und den Provider akzeptabel sind, wird die tatsächliche Richtlinie unter Verwendung der neuesten Version bestimmt.

Verwendete Richtlinie im JAX-WS-Dispatch-Client

Für Aufrufe, die den JAX-WS-Dispatch-Client (javax.xml.ws.Dispatch) verwenden, wird die Providerrichtlinie in der Konfiguration verwendet, wenn dies das verwaltete Verhalten für den Service darstellt. Wenn die Operation für den Aufruf unbekannt ist, verhält sich der Client wie folgt:
  • Der Client befolgt die für die Operation geltende Providerrichtlinie nur dann, wenn sie für alle vom Service bereitgestellten Operationen (sowohl semantisch als auch syntaktisch) identisch ist.
  • Ist die Providerrichtlinie nicht für alle vom Service bereitgestellten Operationen identisch, dann gibt der Client die Ausnahme "JAX-WS WebserviceException" mit der Ursache "WSPolicyException (CWPOL0106E)" und eine entsprechende Fehlernachricht zurück.
  • Wenn für keine der Operationen eine Richtlinie existiert, verwendet der Client die gültige Providerrichtlinie für den Serviceendpunkt.
Für einen JAX-WS-Dispatch-Client, der anstelle der in WSDL oder über Annotationen vordefinierten Ports den mit javax.xml.ws.Service.addPort definierten dynamischen Port verwendet, ist die Aufrufoperation immer unbekannt.
Anmerkung: Die Angabe einer Richtlinie auf Operationsebene für jeden dieser dynamischen Ports im JAX-WS-Dispatch-Client wird nicht unterstützt.

Aktualisierung Providerrichtlinie auf dem Client

Die Providerrichtlinie, die der Client für einen Service bereithält, wird beim ersten Aufruf des Web-Service nach dem Starten der Anwendung aktualisiert. Anschließend wird die Providerrichtlinie jedesmal aktualisiert, wenn die Anwendung erneut startet oder wenn Sie explizit eine Aktualisierung für die Providerrichtlinie aufrufen. Bei der Aktualisierung der Providerrichtlinie wird die gültige Richtlinie neu ermittelt.

Sie können eine Aktualisierung der Providerrichtlinie im Anwendungscode aufrufen. Dies kann nützlich sein, wenn ein JAX-WS-Aufruf scheitert. Bei der Ausnahmebehandlung können Sie eine Wiederholung mit der aktualisierten Richtlinie erzwingen. Sie können folgende (in der Klasse "WSPConstants" der API verfügbare) Eigenschaft im JAX-WS-Client-Proxy festlegen und die JAX-WS-Anforderung anschließend erneut absetzen: "com.ibm.websphere.wspolicy.refreshProviderPolicy".

Wenn die Eigenschaft "com.ibm.websphere.wspolicy.refreshProviderPolicy" festgelegt ist, wird die Providerrichtlinie, die der Client für einen Service bereithält, aktualisiert, und die gültige Richtlinie wird bei der nächsten Anforderung neu berechnet. Nach der Aktualisierung und Neuberechnung wird die Definition der Eigenschaft "com.ibm.websphere.wspolicy.refreshProviderPolicy" zurückgenommen.

Das folgende Codebeispiel für einen Dispatch-Client zeigt, wie eine Ausnahme identifiziert wird, die durch Aktualisierung der Providerrichtlinie aufgelöst werden könnte, gefolgt vom Aufruf der Aktualisierung.

try 
{ 
dispatch.invoke(params); 
} 
catch (javax.xml.ws.WebServiceException e) 
{ 
Throwable cause = e.getCause(); 
if ((cause instanceof NullPolicyException) || (cause instanceof PolicyException) ) 
{
// Die Ausnahme kann auftreten, wenn die Richtlinie des Providers nicht auf dem neuesten Stand ist.
//
// Auf der Konsole wird eine Nachricht beginnend mit den Zeichen "CWPOL" angezeigt,
// die beim Feststellen und Beheben der Fehlerursache hilft.
// Diese Nachricht ist auch verfügbar, wenn
// "String nlsedMessage = cause.getMessage();" verwendet wird.
Map<String, Object> requestContext = dispatch.getRequestContext(); 
requestContext.put(WSPConstants.REFRESH_PROVIDER_POLICY, Boolean.TRUE); 
// Die folgende Methode kann eine weitere Ausnahme beim JAS-WS-Aufruf zur Folge haben.
// Die Ursache dafür kann nach wie vor die Richtlinie sein. In diesem Fall wird
// eine Nachricht in der Konsole ausgegeben.
dispatch.invoke(params); 
}
// Für alle anderen Ausnahmen sollte die normale Ausnahmebehandlung für die Anwendung
// verwendet werden. In diesem Fall kann davon ausgegangen werden, dass keine weiteren
// Ausnahmen vorhanden sind, und die ursprüngliche Ausnahme sollte erneut ausgelöst werden.
// Denken Sie daran, dass die Ursache für die Ausnahme "WebServiceException" eine Ausnahme
// des Typs "WSPolicyAdministrationException" sein kann. In diesem Fall wird eine Nachricht
// in der Konsole ausgegeben, aber das Problem kann nicht dadurch behoben werden, dass
// eine Aktualisierung in der Anwendung erzwungen wird.
throw e;
} 

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_wsp_client_spp
Dateiname:cwbs_wsp_client_spp.html