What Is Web Services Policy And How Does It Work? [Part 1]

WSIT project Milestone 3 was just released. And that is a great opportunity for me to try to share some thoughts that should help you to find the answer to the question from the title of this blog. Lets apply a divide and conquer strategy so that we can address the two topics the question contains separately. In this blog we would find out what the term web service policy actually means. We would look at how does it work tomorrow in my following blog.

What is web services policy?

More and more often when people speak about web services they would mention also policies. What are they talking about? If we try to look up the word “policy” in an encyclopedia you end up with a definition like this:

A policy is a plan of action to guide decisions and actions. The term may apply to government, private sector organizations and groups, and individuals. The policy process includes the identification of different alternatives, such as programs or spending priorities, and choosing among them on the basis of the impact they will have. Policies can be understood as political, management, financial, and administrative mechanisms arranged to reach explicit goals. (Wikipedia)

If we go on and search for some more explanation in a dictionary, we discover that word “policy” is being described as a “course or plan of action”, “statement of requirement” or “contract”. Well, how does all that apply to our question? What is a policy in context of web services? In my opinion, definition of web service policy might look like this:

Policy is a set of assertions (rules, requirements, obligations) that define properties of contract of web service based communication.

Great! We have our definition! Still, what is this policy good for? The answer is not that difficult. When a client wants to communicate with a web service, first it must get some answers (in a machine readable way) to the following questions:

  1. How does the service’s interface look like?
  2. What is the format of the message payloads the service claims to understands?
  3. What are the other (behavioral) requirements I must meet to be able to talk to the service?

The answer to the first question is obvious – WSDL is the mechanism that provides web service interface description. Within a WSDL file we may also find the answer to the second question – usually nested XSD expressions are used to describe formats of the messages that a web service uses in communication with its clients. So far, so good. And how do we get the answer to the last question? How do we find out whether our web service has some security restrictions for instance? Web services policy language is the answer. A language that defines a way how to express and describe qualities and requirements of a web service in various domains, such as security, transaction, reliability of communication (reliable messaging), message exchange optimization. There are several efforts aimed to define a common and standard language for expressing web service policies in a machine readable way. One of such languages that seems to get lots of attention is the Web Services Policy Framework specification, or simply WS-Policy. This specification, which is currently undergoing the standardization process at W3C defines the common policy language constructs. The means of attaching policies to a web service are described in a separate specification called WS-Policy Attachments.

…and that’s it for today. Do not forget to read my next blog entry tomorrow. And if you want to know more about WSIT project and it’s WS-Policy implementation, check also a very nice article written by Fabian.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>