skip to content

In WS-Policy 1.5, what does a wsp:ExactlyOne holding two wsp:All alternatives, attached to a WSDL 1.1 binding, tell a client to do?

level: middleimportance: nice to knowfreq 6%

answer

  1. a policy is a set of choices
  2. pick one, satisfy all of it
  3. an empty All is still a choice
  4. port, binding and portType merge

basics

~10 s

It offers two policy alternatives for that endpoint: the client may pick either, must pick exactly one per interaction, and must then satisfy every assertion inside the wsp:All it picked.

solid answer

~40 s

That is WS-Policy's **normal form**: `wsp:ExactlyOne` holds the policy's alternatives, each `wsp:All` is one **policy alternative**, and each child of an `All` is an **assertion**, a requirement or capability such as `wsam:Addressing` or `wsrmp:RMAssertion`. The framework says a requester MAY choose any alternative but MUST choose only one for an interaction, and supports an alternative only by satisfying every assertion in it. An empty `wsp:All` is an admissible alternative requiring nothing; an empty `wsp:ExactlyOne` admits no behaviour at all. Attached to a `wsdl:binding`, the policy applies to the **endpoint policy subject**, whose effective policy is the merge of what the port, the binding and the portType carry. `wsp:Optional="true"` on an assertion is shorthand for two alternatives, with and without it.

code

xml · 25 lines
xml
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:wsp="http://www.w3.org/ns/ws-policy"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
    xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
    xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702"
    xmlns:tns="http://example.com/purchasing" targetNamespace="http://example.com/purchasing">
  <wsp:Policy wsu:Id="OrderEndpointPolicy">
    <wsp:ExactlyOne>
      <wsp:All>
        <wsam:Addressing>
          <wsp:Policy><wsam:NonAnonymousResponses/></wsp:Policy>
        </wsam:Addressing>
        <wsrmp:RMAssertion><wsp:Policy/></wsrmp:RMAssertion>
      </wsp:All>
      <wsp:All>
        <wsam:Addressing>
          <wsp:Policy><wsam:AnonymousResponses/></wsp:Policy>
        </wsam:Addressing>
      </wsp:All>
    </wsp:ExactlyOne>
  </wsp:Policy>
  <wsdl:binding name="OrderSoapBinding" type="tns:OrderPortType">
    <wsp:PolicyReference URI="#OrderEndpointPolicy" wsdl:required="true"/>
  </wsdl:binding>
</wsdl:definitions>

go deeper

for a junior

Recall that WS-Policy lets a service publish what clients must use, such as WS-Addressing or reliable messaging, in a form tools can read from its WSDL.

for a middle

Read the normal form aloud: ExactlyOne means choose one alternative, All means satisfy everything inside it, and Optional expands into a with-and-without pair.

for a senior

Explain effective policy: how port, binding and portType attachments merge, why concrete assertions stay off the portType, and how an empty intersection explains a client that cannot connect.

for a principal

Judge when machine-readable policy pays off: it automates negotiation between capable stacks, but every assertion a partner's tooling cannot process becomes an onboarding obstacle.

## Assertions, alternatives and policies WS-Policy 1.5 (a W3C Recommendation, with its companion WS-Policy Attachment) gives SOAP endpoints a machine-readable way to state requirements and capabilities. - A **policy assertion** is one requirement, capability or property of a behaviour: `wsam:Addressing` (use WS-Addressing), `wsrmp:RMAssertion` (use WS-ReliableMessaging), `wsat:ATAssertion` (flow an atomic-transaction context), or WS-SecurityPolicy assertions such as `sp:SignedParts` and `sp:EncryptedParts`, which together state which message parts must be protected. - A **policy alternative** is a collection of assertions, possibly empty. - A **policy** is a collection of alternatives, possibly empty. ## Reading the normal form | Element | Meaning | |---|---| | `wsp:Policy` | a policy expression | | `wsp:ExactlyOne` | the collection of alternatives | | `wsp:All` | one alternative: every assertion inside applies | | empty `wsp:All` | an admissible alternative that specifies no behaviour | | empty `wsp:ExactlyOne` | no admissible alternative: no behaviour is acceptable | The framework's rules for a requester: it **MAY choose any alternative**, because each is a valid configuration, but it **MUST choose only one** for an interaction. An entity supports an alternative only if it supports every assertion in it, and supports the policy if it supports at least one alternative. Alternatives are not ordered; preference between them is outside the specification. Two compact forms normalise into this shape: 1. `wsp:Optional="true"` on an assertion is shorthand for two alternatives, one containing the assertion and one without it. 2. A nested `wsp:Policy` inside an assertion qualifies it, as `wsam:Addressing` containing `wsam:NonAnonymousResponses` does. An assertion whose type requires a nested policy but needs no qualifiers MUST carry an empty `<wsp:Policy/>`. ## Attaching it to WSDL 1.1 WS-Policy Attachment maps WSDL 1.1 elements to four **policy subjects**: | Policy subject | WSDL 1.1 elements | |---|---| | service | `wsdl:service` | | endpoint | `wsdl:port`, `wsdl:binding`, `wsdl:portType` | | operation | `wsdl:portType/wsdl:operation`, `wsdl:binding/wsdl:operation` | | message | `wsdl:message`, and an operation's input, output and fault in the portType or binding | The **effective policy** of an endpoint is the **merge** of what is attached to its port, its binding and its portType. A merge wraps each attached policy in a `wsp:All` under a new `wsp:Policy`, so all of them apply together. Because one portType can serve several bindings, only abstract, binding-independent assertions are RECOMMENDED there, and some assertion specifications go further: the WS-Addressing Metadata specification says a policy containing `wsam:Addressing` MUST NOT be attached to a portType, and WS-AtomicTransaction says the same of `wsat:ATAssertion`. The policy is usually placed as a child of `wsdl:definitions` and referenced with `wsp:PolicyReference URI="#..."`; the `wsp:PolicyURIs` attribute exists for WSDL 1.1 elements where the original restriction on extension elements must be kept. The reference SHOULD be marked `wsdl:required="true"`, so a consumer that cannot process policy fails instead of silently ignoring it. ## A worked reading Take an endpoint policy with two alternatives. The first holds `wsam:Addressing`, qualified by a nested `wsam:NonAnonymousResponses`, plus `wsrmp:RMAssertion`: use WS-Addressing with replies sent to a real callback address, and use WS-ReliableMessaging. The second holds only `wsam:Addressing` qualified by `wsam:AnonymousResponses`: use WS-Addressing with replies on the same exchange. - A client that cannot expose a callback endpoint picks the second alternative and gets plain synchronous request-response. - A client that wants reliable delivery must take the first alternative whole, which means it must also host a callback endpoint, because both requirements sit in the same `wsp:All`. - A client that satisfies neither alternative in full does not support the policy, whatever it shares with each. ## Matching a client to a service **Policy intersection** is OPTIONAL. Two assertions are compatible when they have the same type (and compatible nested policies); assertion parameters are left to domain-specific processing. In **strict** mode every assertion on each side must find a compatible partner; in **lax** mode assertions marked `wsp:Ignorable="true"` may go unmatched. The result is the set of compatible alternatives, and it can be empty, which means the two sides cannot agree on any configuration. ## Common misreadings - Treating alternatives as a priority list: they are unordered. - Satisfying most of an alternative: support requires every assertion in it. - Mixing assertions from two alternatives: the requester picks one whole alternative. - Reading `wsp:Optional` as "may be ignored": ignorability is `wsp:Ignorable`, a different attribute with a different effect.

  • What is the difference between wsp:Optional and wsp:Ignorable in WS-Policy 1.5?
    `wsp:Optional="true"` is authoring shorthand: it expands into two alternatives, one with the assertion and one without, so a requester may choose either. `wsp:Ignorable="true"` leaves the assertion in its alternative but lets lax-mode intersection disregard it when matching; it marks behaviour that need not be engaged for successful interoperation. One creates choices; the other relaxes matching.
  • Why should concrete assertions such as wsam:Addressing stay off a WSDL 1.1 portType?
    A portType is abstract and can be shared by several bindings, so a policy on it lands in the endpoint scope of every one of them. WS-Policy Attachment RECOMMENDS only binding-independent assertions there, and the WS-Addressing Metadata specification goes further: a policy containing `wsam:Addressing` MUST NOT be attached to a portType, because the assertion specifies concrete behaviour.

saying these in an interview costs you the question

  • A requester must satisfy every alternative listed under wsp:ExactlyOne.
  • Alternatives are listed in order of the provider's preference.
  • An empty wsp:All means the policy forbids every behaviour.
  • wsp:Optional means the assertion may be ignored during policy matching.
  • A policy attached to the port replaces the one attached to its binding.