WS-Policy will rock the world of web services

WS-Policy is the most important thing which happened in the world of Web Services since their invention (since SOAP, for better or worse, depending on what your appreciation of it is, came to the scene).

One will see complex specifications like WS-Security and WS-BusinessActivity, touted as being the cause of interoperabilty problems, coming to life, with UI tools completely hiding the details from developers and with client runtimes getting closer to requiring very little if any configuration at all.

Policies are obviously not specific to SOAP-based web services. One can do, for example, a message-level security for RESTful services, no probs. And yes, these services may want to advertise their runtime capabilities so that the client tools can ensure no manual coding is done. Look no further, WS-Policy language is simple yet powerful to cover a lot of ground in the world of policies.

By the way, a short off-topic statement on WS-Security, SOAP and REST. Yes, HTTPS just works and yes one can do a message-level security for RESTful services. WS-Security may offer a way too many options but there'll always be some customer out there whiich will find the use for all of those options. The thing about SOAP is that it makes it easier to productise something like WS-Security. Once a customer will get it working, with the help of WS-SecurityPolicy at the start and those SOAP headers at runtime, it will be a tough decision to make to drop it because the underlying protocol (SOAP) is considered to be a way too complicated especially after all SOAP nodes will learn how to reply to GETs.

It can also be tough to describe that a message-level security is done on a per-resource basis. It's the multitude of resources which can make it difficult to do something like message-level security on all or some of them, by describing such requirements in advance for example. A policy language like WS-Policy can help here too by facilitating the auto-discovery of requirements.