OASIS Reference Model for SOA. Part 8: Core Concepts – Contract and Policy

This post is part of a series. Click here for the ‘home page’

---

According to OASIS:

• A policy represents some constraint or condition on the use, deployment or description of an owned entity as defined by any participant.
• A contract, on the other hand, represents an agreement by two or more parties.

Service Policy
In order to write effective service policies you need to keep just two things in mind:

• Policies are based on assertions and assertions must be measurable.
• An assertion can only be adopted as a policy if it is enforceable.

These examples will help clarify these two points.

Example 1: Valid and Invalid Assertions

An example of a valid (i.e. measurable) assertion is “all messages are encrypted.” This assertion is measurable because the message is either encrypted or it is not.

An example of an invalid assertion is “only small orders will be accepted electronically”. This assertion is not measurable because there is no way of knowing what ‘small’ means. A better assertion would be “only orders valued under $50,000 will be accepted electronically.”

Invalid assertions can never be policies.

Example 2: Valid Assertion and Valid Policy
A valid (i.e. measurable) assertion can be adopted as a policy only if it enforceable.

Continuing on from the above example, we know that “all messages are encrypted” is a valid assertion. It would also make a valid policy because:

• We can measure the assertion: ether the message is encrypted or it is not
• We can adopt the assertion as a policy because we can enforce it: if it is not encrypted the message will be rejected

Example 3: Valid Assertion but Invalid Policy
Just because an assertion is measurable does not mean that it will automatically make a good policy. To make a good policy the assertion must be enforceable.

Here is an example of a valid assertion:
“The value of the orders placed in any given day must not exceed $50000 unless prior arrangements have been made with the sales manager in charge of your account.”

This assertion is valid because:

• We can easily measure the value of orders placed in a given day
• We can measure whether ‘prior arrangements’ have been made – either they have or they haven’t.

Would this assertion make a good policy? It depends. If the service can find out whether ‘prior arrangements’ have been made in real time when an order is placed then it would make a valid policy. However, if the ‘prior arrangement’ takes the form of a phone call between a sales manager and a client and no record of it is made in a repository accessible to the service then clearly the policy is not enforceable.

When developing your service policy you may also want to consider these points:

• Define policies in terms of ‘real world effects’. For example, your policies should:
  • prevent unauthorised actions to be performed
  • invalid states to be entered into
  • business rules to be violated
• Explain the consequences of attempting to violate the policy (e.g. if a client tries to place an order over $50,000 it may be rejected and no harm done, or the account may be disabled)
• Consider whether any ‘compensatory actions’ may be appropriate when policy violations are detected further down the chain (if the service the consumer is interacting with calls other services). It is not always possible to check all applicable policies ‘at the gate’ (the first service). For example:
  • the consumer calls Service A, which in turn calls Services B, C and D.
  • Services B/C alter shared stated used by D.
  • When D is called the request may violate D’s policies, but the violation may not have been foreseeable when A was called.
• Policies should cover BOTH of these areas:
  • Infrastructure (e.g. security, privacy, Quality of Service etc)
  • Business rules

Service Contract
A service contract is an agreement between two parties. A contract is basically a collection of policies. The policies in a contract may be:

• Generic policies that apply to all
• Specific policies that relate only to the agreement/relationship between the parties in a contract.

A contract may be arrived at through:

• Out-of-band process – outside of the SOA environment (e.g. lawyers in a boardroom)
• In-band process – during the course of service interaction (e.g. a service may have a policy that when you interact with it for the first time, you are implicitly ‘signing up’ for a 6 month contract at a set monthly fee)