How I explained Web Services Policy to my child

D: Dad?

F: Yes?

D: What are you working on all the time?

F: It is called "Web Services Policy".

D: That sounds complicated! Explain it so that a ... year old girl like me can understand it. (The author refrains from making the real age of his daughter public.)

F: O.K., I'll do my best ... In short: Web Services is like people doing things together; but it's not people, but machines interacting. Now, Web Services Policy, a technology created for so-called SOAP-based Web Services, helps you to decide if you want to interact with somebody.

D: That sounds simple.

F: It is! For example, let's say you want to buy something in a virtual or "real" shop. Basically, before starting this interaction, you (I will call you the "requester" or "buyer") send your policy to your counterpart (the provider, or "shop owner"). Your policy describes what you can or require from the provider. Such a description, a Policy, can look like this:

<Policy>
 <pm:CreditCardsUsable/>
</Policy>

This policy means: I (the requester) require that I can use my credit card. This is no "real" policy, I just made it up to explain the technology.

D: The "CreditCardsUsable" element, is this part of Web Services Policy?

F: No, it is defined somewhere else, or it would be defined somewhere else if it would be a "real" example. The element "pm:CreditCardsUsable" is called a "policy assertion". It describes capabilities and requirements for an interaction in a specific area, a so-called domain. You can think of "pm:CreditCardsUsable" as an assertion from a domain for payment modalities. We use the namespace prefix "pm" to make this clear (I assume that my daughter understands XML namespaces). There are all kinds of policy assertions for various domains, and more will be built in the future.

D: So is Web Services Policy only about names of assertions?

F: No, you can provide more than the element name of the policy assertion in a policy. Have a look at this policy:

<Policy>
 <All>
  <pm:CreditCardsUsable wsp:Optional="true"/>
  <ExactlyOne>
   <tt:OutdoorToys/>
   <tt:IndoorToys/>
  </ExactlyOne>
 </All>
</Policy>

Using the so-called policy operators "All" (the "All" element) and "ExactlyOne" (the "ExactlyOne" element), this policy says: You should fulfil "All" the following requirements: allow for using credit cards (as something optional), and "ExactlyOne" of these: provide outdoor toys or indoor toys - I assume that you buy only one toy ;) . The latter requirement is expressed by two assertions from a different domain, let's say the "toy type" domain.

Spelling everything in this Policy out, leaves you with four so-called "policy alternatives". Each contains alternative requirements for an interaction:

1. Allow for credit cards and provide outdoor toys
2. Allow for credit cards and provide indoor toys
3. Provide outdoor toys
4. Provide indoor toys

D: I see ... so, how do we decide now with these policies if we interact or not?

F: You (the requester) send your policy to the provider. The provider uses his policy and yours to do policy intersection. That means:

• Checking for compatible policy alternatives, that is: alternatives which have the same policy assertions, and
• Checking for compatibility of the two policies, that is: there must be at least one compatibly alternative in both policies.

After policy intersection, the requester gets all compatible alternatives from the provider (if there is one!) back. Now he can choose one to start the interaction - or not.

Let' s imagine the provider has the following policy:

<Policy>
 <All>
  <pm:CreditCardsUsable wsp:Optional="true"/>
  <ExactlyOne>
   <tt:IndoorToys/>
  </ExactlyOne>
 </All>
</Policy>

This reads as "I have indoor toys and you can use your credit card". Doing an intersection with the requester policy leads to two policy alternatives which say:

• Allow for credit cards and provide indoor toys
• Provide indoor toys

D: So I see the result of intersection and decide what to do? I.e., if I buy indoor toys with or without a credit card?

F: Exactly. Web Services Policy is only the basis for that decision. Which policy alternative you choose is up to you.

D: What else do I have to understand about Web Services Policy?

F: These are the most important bits. In addition, you can:

• Build more specific assertions using attributes or nested assertions, that is, assertions within other assertions. For example, inside the "pm:CreditCardsUsable" assertion, you might nest other assertions to specify further characteristics of the credit card.
• Mark an assertion as "ignorable", which means: "I tell you something FYI", but it does not concern our interaction (e.g., I'm logging our interaction);
• Attach policies to all kinds of parts in a web services interaction.

D: Like what?

F: For example, a whole web service or only a specific interaction between requester and provider. If you interact with your bank, you don't need security for all interactions, but only the ones which transmit the bank account number. Hence, you describe the policy only for that specific interaction.

D: So, who needs to know all this stuff?!?

F: People who develop Web Services might not see a Policy at all. Their tools possibly hide them behind some nice user interface. Of course, tool implementers deal with policies, and there are also the authors of policy assertions who are experts in their specific domain.

D: Do you think I will ever have to do with Web Services Policy?

F: Depends on the job you will choose some day ...