imported>Trustable: Schreibfehler berichtigt

2017-02-15T22:15:10Z

Schreibfehler berichtigt

Neue Seite

'''WS-Policy''' ist eine Spezifikation des [[World Wide Web Consortium|W3C]] im Rahmen der [[WS-*]]-Spezifikationen, die es dem Serviceanbieter ermöglicht, die Richtlinien bezüglich Sicherheit, Qualität und Version seines Services in Form von maschinenlesbaren [[Extensible Markup Language|XML]]-Daten für den Servicenutzer bereitzustellen. Umgekehrt kann der Servicenutzer seine Anforderungen ebenfalls in Form von XML-Daten spezifizieren. Diese Policies werden dann an entsprechenden Stellen in die [[Web Services Description Language|WSDL]]-Beschreibung des Service (oder auch im [[WS-Business Process Execution Language|BPEL]]-Prozess) eingefügt und gelten als Mindestrichtlinien auch für alle in der Hierarchie tiefer stehenden Elemente. Umgekehrt kann auch ein Servicenutzer seine Anforderung an einen Service in Form von Policies formulieren, so dass dann zur Laufzeit „ausgehandelt“ werden muss, was denn nun die effektive Policy wird.

== Unterspezifikationen ==
Zu WS-Policy gehören mehrere Unterspezifikationen:
=== WS-Policy Assertions ===
WS-Policy Assertions beschreibt eine Menge an Standardrichtlinien, die innerhalb einer Policy verwendet werden können.
=== WS-Policy Attachment ===
WS-Policy Attachment beschreibt, in welcher Form Policies mit bestehenden Technologien aus dem Bereich [[Web Services]] verknüpft werden können. Wahlweise können sie direkt innerhalb des Elements deklariert werden, auf das sie sich beziehen, oder auch separat und nur referenziert werden.

== Aufbau von Policies ==
Eine Policy besteht immer aus einem Element:
<syntaxhighlight lang="XML">
<wsp:Policy xmlns:wsp="someURI">
</syntaxhighlight>
Dieses Element enthält immer eine Auflistung an Alternativen, so könnte beispielsweise ein Bankwebservice vorschreiben, dass die Übertragung verschlüsselt zu erfolgen hat und dabei die konkreten Alternativen [[Data Encryption Standard|DES]] und [[Advanced Encryption Standard|AES]] anbieten. Ein Nutzer des Service müsste demnach, um den Service überhaupt nutzen zu können, die Daten in jedem Fall mit einem der beiden Verfahren verschlüsseln. Ein anderes Verfahren wäre ''nicht'' zulässig. Jede Alternative kann aus beliebig vielen Assertions bestehen.
Eine Auflistung von Policyalternativen besteht immer aus einem Element <code><wsp:ExactlyOne></code> oder einem Element <code><wsp:All></code>. Ersterer Fall bedeutet, dass von allen darin enthaltenen Alternativen ''genau eine'' gelten muss, zweiterer bedeutet, dass ''alle'' darin genannten Alternativen erfüllt sein müssen. Diese beiden Elemente können auch weiter in sich verschachtelt werden. Allerdings hat man sich zur leichteren Verarbeitung von Policies auf eine Normalform geeinigt, so dass sich folgende Struktur ergibt:
<syntaxhighlight lang="xml">
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>

</wsp:All>
<wsp:All>

</wsp:All>
<wsp:All>

</wsp:All>

</wsp:ExactlyOne>
</wsp:Policy>
</syntaxhighlight>

Gibt es nur eine Alternative, so kann das Element <code><wsp:ExactlyOne></code> natürlich entfallen; gleiches gilt für <code><wsp:All></code>, wenn eine Alternative nur aus einer Assertion bestehen würde.

== Nutzungsarten ==
Jede Assertion hat ein optionales Attribut <code>wsp:Usage</code>, was angibt, wie diese Assertion zu verwenden ist. Dabei unterscheidet man folgende mögliche Werte:
* <code>Required</code>: Die Assertion wird in jedem Fall angewendet. Sollte sie verletzt werden, wird ein Fehler ausgelöst.
* <code>Rejected</code>: Die Assertion wird explizit ''nicht'' unterstützt. Sollte sie dennoch gefordert werden, wird ein Fehler ausgelöst.
* <code>Optional</code>: Die Assertion muss nicht angewendet werden, wird es aber, wenn sie vorhanden ist.
* <code>Observed</code>: Die Assertion wird in jedem Fall angewendet.
* <code>Ignored</code>: Die Assertion wird verarbeitet, aber ignoriert, d. h., sie kann angegeben sein, hat aber keinerlei Einfluss auf die Weiterverarbeitung. Sowohl Serviceanbieter als auch -nutzer werden darüber informiert, dass sie ignoriert wird.

== Effektive Policy ==
Sowohl Serviceanbieter als auch Servicenutzer können Policies spezifizieren. Dies hat zur Folge, dass die effektive Policy erst zur Laufzeit ausgehandelt werden kann. Genauere Algorithmen, die auf Basis der beiden Requirements die effektive Policy bestimmen, sind noch Gegenstand aktueller Forschung. Zunächst einmal wird es sich bei der effektiven Policy immer um den "kleinsten gemeinsamen Nenner" der jeweiligen Anforderungen handeln. Allerdings ist noch offen, wie dabei auch eine semantische Auswertung der Policy erfolgen soll, da WS-Policy nur die äußere Form einer Policy festlegt und weder etwas über den Inhalt aussagt noch darüber, wie der Inhalt codiert werden soll.

== Anmerkungen ==
* Eine Policy kann auch leer sein (keine Alternativen enthalten).
* Die Alternativen sind ungeordnet.
* Alternativen in einer Policy können sowohl sehr ähnlich sein als auch völlig verschieden (d. h. die gleiche Assertion kann in mehreren Alternativen vorkommen).
* WS-Policy schreibt vor, wie Policies von Anbieter und Nutzer verbunden werden sollen. Dabei wird die Semantik allerdings ignoriert, bspw. wäre folgende effektive Policy möglich:
<syntaxhighlight lang="xml">
<wsp:Policy>
<SomeAssertion apply="true"/>
<SomeAssertion apply="false"/>
</wsp:Policy>
</syntaxhighlight>

== Geschichte ==
* Dezember 2002 vorgestellt von [[BEA Systems|BEA]], [[IBM]], [[Microsoft]] und [[SAP]]
* Mai 2003 aktualisiert
* September 2004 aktualisiert unter Mitarbeit von [[Sonic Solutions|Sonic]] und [[Verisign]]
* März 2006 erneut aktualisiert
* April 2006 bei [[W3C]] eingereicht, so dass eine Arbeitsgruppe eingerichtet werden konnte
* September 2007 als [[W3C#Entwicklung|W3C-Recommendation]] veröffentlicht

== Weblinks ==
* [http://www.w3.org/TR/ws-policy/ Spezifikation] des W3C
* [http://www.w3c-at.de/wspolicy-pressrelease.php Pressemitteilung] WS Policy

[[Kategorie:Webservice]]

WS-Policy - Versionsgeschichte

imported>Trustable: Schreibfehler berichtigt