www.wikidata.de-de.nina.az

WS Policy ist eine Spezifikation des W3C im Rahmen der WS Spezifikationen die es dem Serviceanbieter ermöglicht die Rich

WS-Policy

WS-Policy ist eine Spezifikation des 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 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 WSDL-Beschreibung des Service (oder auch im 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 Bearbeiten

Zu WS-Policy gehören mehrere Unterspezifikationen:

WS-Policy Assertions Bearbeiten

WS-Policy Assertions beschreibt eine Menge an Standardrichtlinien, die innerhalb einer Policy verwendet werden können.

WS-Policy Attachment Bearbeiten

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 Bearbeiten

Eine Policy besteht immer aus einem Element: 

<wsp:Policy xmlns:wsp="someURI">

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 DES und 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 <wsp:ExactlyOne> oder einem Element <wsp:All>. 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: 

<wsp:Policy>  <wsp:ExactlyOne>  <wsp:All>  <!--Liste von Assertions-->  </wsp:All>  <wsp:All>  <!--Liste von Assertions-->  </wsp:All>  <wsp:All>  <!--Liste von Assertions-->  </wsp:All>  <!--beliebig viele weitere Elemente vom Typ wsp:All-->  </wsp:ExactlyOne> </wsp:Policy>

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

Nutzungsarten Bearbeiten

Jede Assertion hat ein optionales Attribut wsp:Usage, was angibt, wie diese Assertion zu verwenden ist. Dabei unterscheidet man folgende mögliche Werte:

  • Required: Die Assertion wird in jedem Fall angewendet. Sollte sie verletzt werden, wird ein Fehler ausgelöst.
  • Rejected: Die Assertion wird explizit nicht unterstützt. Sollte sie dennoch gefordert werden, wird ein Fehler ausgelöst.
  • Optional: Die Assertion muss nicht angewendet werden, wird es aber, wenn sie vorhanden ist.
  • Observed: Die Assertion wird in jedem Fall angewendet.
  • Ignored: 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 Bearbeiten

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 Bearbeiten

  • 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:
<wsp:Policy>  <SomeAssertion apply="true"/>  <SomeAssertion apply="false"/> </wsp:Policy>

Geschichte Bearbeiten

  • Dezember 2002 vorgestellt von BEA, IBM, Microsoft und SAP
  • Mai 2003 aktualisiert
  • September 2004 aktualisiert unter Mitarbeit von Sonic und Verisign
  • März 2006 erneut aktualisiert
  • April 2006 bei W3C eingereicht, so dass eine Arbeitsgruppe eingerichtet werden konnte
  • September 2007 als W3C-Recommendation veröffentlicht

Weblinks Bearbeiten

wikipedia, wiki, deutsches, deutschland, buch, bücher, bibliothek artikel lesen, herunterladen kostenlos kostenloser herunterladen, MP3, Video, MP4, 3GP, JPG, JPEG, GIF, PNG, Bild, Musik, Lied, Film, Buch, Spiel, Spiele
Veröffentlichungsdatum:
WS Policy ist eine Spezifikation des W3C im Rahmen der WS Spezifikationen die es dem Serviceanbieter ermoglicht die Richtlinien bezuglich Sicherheit Qualitat und Version seines Services in Form von maschinenlesbaren XML Daten fur 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 WSDL Beschreibung des Service oder auch im BPEL Prozess eingefugt und gelten als Mindestrichtlinien auch fur 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 Inhaltsverzeichnis 1 Unterspezifikationen 1 1 WS Policy Assertions 1 2 WS Policy Attachment 2 Aufbau von Policies 3 Nutzungsarten 4 Effektive Policy 5 Anmerkungen 6 Geschichte 7 WeblinksUnterspezifikationen BearbeitenZu WS Policy gehoren mehrere Unterspezifikationen WS Policy Assertions Bearbeiten WS Policy Assertions beschreibt eine Menge an Standardrichtlinien die innerhalb einer Policy verwendet werden konnen WS Policy Attachment Bearbeiten WS Policy Attachment beschreibt in welcher Form Policies mit bestehenden Technologien aus dem Bereich Web Services verknupft werden konnen Wahlweise konnen sie direkt innerhalb des Elements deklariert werden auf das sie sich beziehen oder auch separat und nur referenziert werden Aufbau von Policies BearbeitenEine Policy besteht immer aus einem Element lt wsp Policy xmlns wsp someURI gt Dieses Element enthalt immer eine Auflistung an Alternativen so konnte beispielsweise ein Bankwebservice vorschreiben dass die Ubertragung verschlusselt zu erfolgen hat und dabei die konkreten Alternativen DES und AES anbieten Ein Nutzer des Service musste demnach um den Service uberhaupt nutzen zu konnen die Daten in jedem Fall mit einem der beiden Verfahren verschlusseln Ein anderes Verfahren ware nicht zulassig Jede Alternative kann aus beliebig vielen Assertions bestehen Eine Auflistung von Policyalternativen besteht immer aus einem Element lt wsp ExactlyOne gt oder einem Element lt wsp All gt Ersterer Fall bedeutet dass von allen darin enthaltenen Alternativen genau eine gelten muss zweiterer bedeutet dass alle darin genannten Alternativen erfullt sein mussen Diese beiden Elemente konnen 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 lt wsp Policy gt lt wsp ExactlyOne gt lt wsp All gt lt Liste von Assertions gt lt wsp All gt lt wsp All gt lt Liste von Assertions gt lt wsp All gt lt wsp All gt lt Liste von Assertions gt lt wsp All gt lt beliebig viele weitere Elemente vom Typ wsp All gt lt wsp ExactlyOne gt lt wsp Policy gt Gibt es nur eine Alternative so kann das Element lt wsp ExactlyOne gt naturlich entfallen gleiches gilt fur lt wsp All gt wenn eine Alternative nur aus einer Assertion bestehen wurde Nutzungsarten BearbeitenJede Assertion hat ein optionales Attribut wsp Usage was angibt wie diese Assertion zu verwenden ist Dabei unterscheidet man folgende mogliche Werte Required Die Assertion wird in jedem Fall angewendet Sollte sie verletzt werden wird ein Fehler ausgelost Rejected Die Assertion wird explizit nicht unterstutzt Sollte sie dennoch gefordert werden wird ein Fehler ausgelost Optional Die Assertion muss nicht angewendet werden wird es aber wenn sie vorhanden ist Observed Die Assertion wird in jedem Fall angewendet Ignored 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 daruber informiert dass sie ignoriert wird Effektive Policy BearbeitenSowohl Serviceanbieter als auch Servicenutzer konnen 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 Zunachst 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 aussere Form einer Policy festlegt und weder etwas uber den Inhalt aussagt noch daruber wie der Inhalt codiert werden soll Anmerkungen BearbeitenEine Policy kann auch leer sein keine Alternativen enthalten Die Alternativen sind ungeordnet Alternativen in einer Policy konnen sowohl sehr ahnlich sein als auch vollig 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 ware folgende effektive Policy moglich lt wsp Policy gt lt SomeAssertion apply true gt lt SomeAssertion apply false gt lt wsp Policy gt Geschichte BearbeitenDezember 2002 vorgestellt von BEA IBM Microsoft und SAP Mai 2003 aktualisiert September 2004 aktualisiert unter Mitarbeit von Sonic und Verisign Marz 2006 erneut aktualisiert April 2006 bei W3C eingereicht so dass eine Arbeitsgruppe eingerichtet werden konnte September 2007 als W3C Recommendation veroffentlichtWeblinks BearbeitenSpezifikation des W3C Pressemitteilung WS Policy Abgerufen von https de wikipedia org w index php title WS Policy amp oldid 162686294