Понимание WS-Policy, часть I: структура политики и составные политики

Контракты на веб-сервисы могут быть расширены с помощью политик, которые выражают дополнительные ограничения, требования и качества, которые обычно относятся к поведению сервисов. Вы можете создавать понятные человеку политики, которые становятся частью дополнительного соглашения об уровне обслуживания, или вы можете определять машиночитаемые политики, которые обрабатываются во время выполнения. Последний тип политики является предметом данной статьи, а технология, которую мы будем исследовать для создания машиночитаемых политик, — это язык WS-Policy и соответствующие спецификации WS-Policy.

Следующая статья является отрывком из новой книги «Разработка контрактов веб-сервисов и управление версиями для SOA» [REF-1] Авторские права Prentice Hall / Pearson PTR и SOA Systems Inc. Обратите внимание, что некоторые ссылки на главы были намеренно оставлены в статье в соответствии с требования от Prentice Hall.

Эта статья написана Умитом Ялкинальпом и Томасом Эрлом и опубликована в журнале SOA в феврале 2009 г.

Введение
Существует множество видов политик, некоторые из которых предварительно определены отраслевыми спецификациями, а другие могут быть настроены разработчиком контракта веб-службы. Например, вы можете использовать политики для выражения функциональной совместимости и ограничений протокола, а также требований конфиденциальности, управляемости и качества обслуживания (QoS). Кроме того, политики могут быть созданы для одной стороны, или они могут применяться к многопартийным взаимодействиям.

С точки зрения архитектурного и контрактного дизайна, политики влияют на все уровни дизайна сервиса. Их можно применять к большинству частей абстрактных и конкретных описаний документа WSDL, и их можно применять в разных областях. Например, одна политика может относиться к определению сообщения, а другая применяется ко всему типу порта WSDL (или интерфейсу).

В этой статье мы сначала рассмотрим основные аспекты политик, а затем познакомим вас с основными частями языка WS-Policy. В главах 16 и 17 продолжено изучение структуры WS-Policy путем документирования ряда расширенных языковых функций и методов проектирования.

Языки XML Schema и WSDL позволяют нам делать чуть больше, чем выражать требования взаимодействия и ограничения веб-службы. Хотя для нас, конечно, принципиально важно делать что-то полезное с веб-сервисом, он не дает нам возможности описать другие аспекты веб-сервиса, такие как:

Структура
политики Словарь WS-Policy относительно прост по сравнению с WSDL и схемой XML в том смысле, что он содержит лишь скромное количество элементов и атрибутов. Тем не менее, политики вводят уникальные структурные соображения, которые отличаются от простого технического интерфейса интерфейса WSDL и XML-схемы. Поскольку политики предназначены для выражения поведенческих качеств, они могут значительно различаться по размеру и характеру содержания политики. Кроме того, гибкость и расширяемость, встроенные в язык WS-Policy, позволяют объединять несколько его элементов и атрибутов в различные сложные конструкции.

Прежде чем мы узнаем больше об отдельных элементах языка WS-Policy, давайте сначала введем некоторую базовую терминологию:

Среди всех этих частей структуры WS-Policy самым основным строительным блоком является утверждение политики.

Новые пространства имен и префиксы

Теперь давайте уделим минуту, чтобы установить некоторые новые пространства имен и префиксы, связанные с языком WS-Policy и общими политиками:

Обратите внимание, что в примерах, приведенных в примерах, мы обычно избегаем отображения ранее перечисленных значений xmlns просто для того, чтобы избежать повторного беспорядка фрагментов кода определения политики.

Утверждения, выражения и элемент политики
Самое важное, что нужно понять о WS-Policy, — это то, что это не технология или язык, используемый для реализации политик. Его единственная цель — предоставить стандартизированный синтаксис для выражения политик (отсюда и термин «выражение политики»).
Утверждения политики

Все начинается с утверждения политики, которое само по себе является просто ссылкой на предопределенный глобальный элемент XML-схемы.

Вот пример простого утверждения политики:

<wsrmp:RMAssertion>>wsp:Policy/>>/wsrmp:RMAssertion>

Элемент wsrmp: RMAssertion ссылается на элемент расширяемости, определенный в спецификации WS-ReliableMessaging. Поэтому это считается утверждением политики WS-ReliableMessaging.

Схема XML, которая определяет это утверждение, выглядит следующим образом:

<xsd:schema
  xmlns:tns="http://docs.oasis-open.org/ws-rx/wsrmp/200608"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  targetNamespace="http://docs.oasisopen.org/wsrx/wsrmp/200608"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">
  <xsd:element name="RMAssertion">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:any namespace="##other" processContents="lax"
          minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:anyAttribute namespace="##any"
        processContents="lax"/>
    </xsd:complexType>
  </xsd:element>
  ...
</xsd:schema>

Мы называем то, что определено в этой схеме, типом политики . Каждое утверждение имеет базовый тип политики, который может быть предоставлен отраслевым стандартом, таким как WS-Reliable-Messaging, или вы можете настроить его, создав собственную схему. Все, что вам нужно, это глобальный элемент, на который можно ссылаться в синтаксисе утверждения политики.

Помимо предоставления стандартизированного выражения политики, WS-Policy не имеет ничего общего с тем, как на самом деле обрабатываются утверждения политики. Например, то, что происходит, когда элемент wsrmp: RMAssertion встречается во время выполнения, зависит от процессоров, связанных с WS-ReliableMessaging. Все, для чего мы используем WS-Policy, это связать это утверждение с определением WSDL.

Точно так же, если вы создаете свои собственные пользовательские утверждения политики, вам потребуется предоставить базовую логику обработки, которая делает что-то в ответ на обнаружение утверждения политики, обрабатываемого во время выполнения.

Мы собираемся использовать элемент wsrmp: RMAssertion во всех главах WS-Policy. Давайте теперь посмотрим на другой пример:

<wsam:Addressing><wsp:Policy/></wsam:Addressing> 

WS-Addressing предоставляет предопределенный элемент расширяемости wsam: Addressing, который можно использовать в конструкции привязки WSDL для связи WS-Addressing с веб-службой.

Как и в случае с wsrmp: RMAssertion , это утверждение вводит требование, чтобы входящие сообщения поддерживали определенную технологию; в этом случае WS-Addressing.

Выражения политики Сами по

себе предыдущие утверждения политики еще не существуют как отдельные политики. Чтобы создать фактическое выражение политики , нам нужно заключить утверждения в конструкцию wsp: Policy следующим образом:

<wsp:Policy>
  <wsam:Addressing><wsp:Policy/></wsam:Addressing>
</wsp:Policy>
<wsp:Policy>
  <wsrmp:RMAssertion><wsp:Policy/></wsrmp:RMAssertion>
</wsp:Policy>
<wsp:Policy>
  <wsam:Addressing><wsp:Policy/></wsam:Addressing>
  <wsrmp:RMAssertion><wsp:Policy/></wsrmp:RMAssertion>
</wsp:Policy> 

Custom Policy Assertions

Let’s now assume you want to create you own policy expression with an assertion that defines a response guarantee for a particular operation. Let’s first create the XML Schema element that forms the basis of the required policy assertion.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  targetNamespace="http://actioncon.com/schema/respguarantee"
  elementFormDefault="qualified">
  <xsd:element name="responseGuarantee"
    type="ResponseGuaranteeType"/>
  <xsd:complexType name="ResponseGuaranteeType">
    <xsd:sequence>
      <xsd:element name="responseInMilliseconds"
        type="xsd:integer"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>

This is a good example of a custom-created QoS policy that can be added to a service contract so that consumers could retrieve the number of milliseconds within which the service promises to perform a particular task.

If you recall the ActionCon Purchase Order service, an assertion such as this could be used to indicate the amount of time the service will take to generate and return a purchase order document. Depending on the circumstances, the actual value of the assertion may differ, as shown in the following two assertion instances.tax.

Assertion Instance #1

<argt:responseGuarantee>
  <argt:responseInMilliseconds>
    50
  </argt:responseInMilliseconds>
</argt:responseGuarantee> 

Assertion Instance #2

<argt:responseGuarantee>
  <argt:responseInMilliseconds>on.
    30
  </argt:responseInMilliseconds>
</argt:responseGuarantee> 

Both assertions have the same assertion element, namely argt:responseGuarantee. However, each instance has a different value.

Composite Policies
In the previous example we created a simple policy assertion. On its own, this one assertion may be sufficient to warrant an entire, self-contained policy expression. However, more often than not, policies need to be assembled out of multiple policy assertions.

In order to combine policy assertion constructs into composite policy expressions, we need to use a new feature of the WS-Policy language known as operators. Specifically, we will need to work with the wsp:ExactlyOne and wsp:All elements and the wsp:optional attribute.

The ExactlyOne Element

This element groups a set of policy assertions from which only one can be used. In other words, it enforces a rule that «exactly one» of the listed assertions must be chosen.

Using the wsp:ExactlyOne element introduces the concept of policy alternatives as part of a policy expression. Each child element within this construct is considered a distinct alternative in the overall policy expression.

Consider the following example:

<wsp:Policy>
  <wsp:ExactlyOne>
    <wsam:Addressing><wsp:Policy/></wsam:Addressing>
    <wsrmp:RMAssertion><wsp:Policy/></wsrmp:RMAssertion>
  </wsp:ExactlyOne>
</wsp:Policy> 

Here, the WS-Policy expression contains two distinct alternatives. Each assertion, wsam:Addressing and wsrmp:RMAssertion, indicates a separate alternative.
The wsp:All Element

The wsp:All operator element is the reverse of the wsp:ExactlyOne element. It imposes a rule that requires that all of the assertions within its construct be applied at the same time.

If we restructure the previous example using this element, it actually looks quite similar.

<wsp:Policy>
  <wsp:All>
    <wsam:Addressing><wsp:Policy/></wsam:Addressing>
    <wsrmp:RMAssertion><wsp:Policy/></wsrmp:RMAssertion>
</wsp:All>
</wsp:Policy>> 

As with the wsp:ExactlyOne construct, it does not matter in what order you decide to place the policy assertion type elements.

The wsp:optional Attribute

The WS-Policy language provides a special Boolean attribute named wsp:optional that allows you to indicate that a policy assertion is not mandatory.

The following example shows this attribute used in conjunction with our previous wsam:Addressing assertion:

<wsp:Policy>
  <wsam:Addressing wsp:optional="true"/>
</wsp:Policy> 

 This attribute is considered a «shortcut» because you can express the same policy logic in a more verbose manner using the previously described operator elements. The wsp:All element is essentially the same as specifying two distinct alternatives in a policy expression, as follows:

<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:All>
      <wsam:Addressing><wsp:Policy/></wsam:Addressing>
    </wsp:All>
    <wsp:All/>
  </wsp:ExactlyOne>
</wsp:Policy> 

In this example, we have a wsp:ExactlyOne construct that houses two wsp:All elements. The second wsp:All element is highlighted. Unlike the first, which establishes a construct with one assertion, this second wsp:All element is empty.

According to the «exactly one» rule, we must choose one of the two alternatives. The first alternative is that the wsam:Addressing assertion is used because in this alternative, the assertion is wrapped in a nested wsp:All construct. The second alternative is that the second wsp:All element be chosen, and because it is empty, the result of this choice is that nothing happens. In other words, the use of the policy assertion is optional, as with the previous example that used the wsp:optional attribute. This last example also hints at the more complex structures that can be built using nested operator elements and various other combinations, as described further in the next section.

Conclusion
Part II of this article series will focus on operator composition rules and techniques for attaching policies to WSDL documents.

References
[REF-1] «Web Service Contract Design and Versioning for SOA» by Thomas Erl, Anish Karmarkar, Priscilla Walmsley, Hugo Haas, Umit Yalcinalp, Canyang Kevin Liu, David Orchard, Andre Tost, James Pasley for the «Prentice Hall Service-Oriented Computing Series from Thomas Erl», Copyright Prentice Hall/Pearson PTR and SOA Systems Inc., http://www.soabooks.com/wsc/

This article was originally published in The SOA Magazine (www.soamag.com), a publication officially associated with «The Prentice Hall Service-Oriented Computing Series from Thomas Erl» (www.soabooks.com). Copyright ©SOA Systems Inc. (www.soasystems.com)