In my last blog entry about WSIT project, I tried to explain WHAT policy means in context of web services. In this follow-up I will try to bring more light to the question HOW does it all work.
How does Web Services Policy work?
WS-Policy specification defines these key concepts:
- assertion – which is a construct that defines a single requirement or description of a single property of the web service behavior
- policy alternative – represented by a set of assertions. Each policy alternative describes single communication contracts a client needs to meet in order to communicate with a service.
- policy expression – defined as a set of policy alternatives.
- operations – such as merge and intersection of policy expressions play a major role in automated policy expression processing.
The mere fact that policy expression is a set of policy alternatives is one of the key factors that makes policy really powerful. This means that a web service may define more than one communication contract, for example to meet different capabilities of different clients. Client does not need to support every contract that web service defines. In order to successfully communicate with a service, a client just needs (using intersection and merge operations) to pick one policy alternative that describes communication requirements the client is able or willing to meet. This was maybe most obvious example how to exploit the concept of multiple policy alternatives. There are many more use cases of course. Multiple policy alternatives may be used for example to support web service versioning, client request routing etc. We do not even need to stay in the field of web services and SOA – this concept may be applied in other IT domains as well.
Sun has it’s own implementation of a web service stack that supports WS-Policy
processing. It is developed as a part of project WSIT
also known as the “Project Tango”. Anybody who ever tried to develop a client that communicates with a secured web service would agree that it is a quite painful process one needs to go through to get all the information about security aspects of the web service to be able to manually setup the secured communication channel between the service and the client. Well, with WSIT
it is no longer an issue. As part of the automated policy processing client application automatically configures the communication channel according to the policies attached to the service. And this works even if the policy on the service is changed – there is no need to change implementation or configuration of the client application anymore. In case you want to know more, Fabian
has a cool blog
that explains some more details about WSIT
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.
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:
- How does the service’s interface look like?
- What is the format of the message payloads the service claims to understands?
- 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
In my last blog I discussed the rise of a new era in SOA development with the use of Java Web Services technology powered by the implementation of WS-* specifications. Today, I would like to write few lines about policy metadata – the real core of these new technologies.
Policy language and its usage is described in two separate specifications (which have already been submitted for standardization by W3 Consortium):
These two specifications bind all other WS-* specifications together into one complex solution.
The main goal of the WS-Policy specification is to introduce a flexible and extensible way of expressing and understanding the capabilities, requirements and general web service properties. In other words, WS-Policy provides a web services policy language together with domain-neutral rules as to how to process and interpret these policies. To complement the WS-Policy specification – which is strictly focused on defining policy language – WS-PolicyAttachment completes the whole picture by defining the means of attaching actual policy expresions to policy subjects to which these expressions apply. This second specification also describes the way how to use policies in the context of web services description mechanisms – WSDL and UDDI.
WSIT introduces its own policy engine and I am a part of a team working on its design and implementation. We do our best to make sure the implementation is interoperable and – of course – fully compliant with WS-Policy and WS-PolicyAttachment specifications. Currently, we are still in a development phase and there’s much to be tested and polished yet. But we have already achieved success in supporting all main use case scenarios as well as having demonstrated our ability to interoperate with policy engines from other vendors at several Interoperability workshops.
…and if you want to know even more about policy, don’t forget to check the blogs of Jakub and Fabian – my project Tango team-mates.