In mid-April, WS-Policy, the 3-year-old Web services governance specification supported by rival vendors IBM and Microsoft was accepted into the W3C process. The goal is for it to become an official Web services standard. This month, W3C released a first working draft of its version of Web Services Policy.
One of the editors working on the draft is Toufic Boubez, chief technology officer for XML networking vendor Layer 7 Technologies Inc. Previously he served in IBM's Emerging Technologies Group back when that group helped to build the foundation for service-oriented architecture (SOA) and served as its lead Web services architect, publishing the company's first SOA toolkit. He is also the co-author of UDDI specification. He has long maintained that without a policy standard, true loosely coupled SOA is simply not possible. We asked him to give us an update on WS-Policy as it now moves toward being an official W3C standard.How is the W3C process working?
It's working really well. There's a lot of good progress going on. People are cooperating. All the companies are working to one goal, which is very good to see. Everybody wants to see this done right. I'm very impressed. This is my first time with the W3C. I've usually been on the technical committees on OASIS. I'm very impressed with how the W3C works. Is the working group working toward a deadline when the specification will be ready to use?
Not officially. But we're trying to get this done as soon as possible. The changes that I see as an editor are around clarifications. I have not seen anything substantial that says: "Oh shoot, we need to stop and rethink this mechanism." If someone were looking to implement WS-Policy, would this draft give them a good idea of what they need to do?
Yes. I think so. It's given us (Layer7) and other companies a pretty good idea for an interoperability platform. What's the overall goal you and the other vendors are trying to achieve with WS-Policy?
Here's the fundamental problem. In order for Web services to work, period -- not to work well, not to work better, but just to work -- you need more than the API. The API being the WSDL. The WSDL tells you where to send the SOAP request and what the operations are. But that's not enough for a requestor and a service provider to actually work together. There are a lot of other things that are not API-related -- security mechanisms, credentials, encryption, reliable messaging, etc. -- that cannot be expressed in a WSDL. That's the crux of the issue. How do you express those things so that you can have a requestor and a service provider actually talk to each other? WSDL is just a small, small part of it. It's just the description of the API. It doesn't describe anything else that is around the API. How will WS-Policy change Web services and SOA?
This will make Web services, SOA and loose coupling possible. Up to this point, we've had to hand code a lot of the steps that we're dealing with in WS-Policy right now. Just take as an example, security. If a particular service provider puts out a service, a quote service or an inventory request service, they don't want to make that available to everybody. They want to make it available to a very particular set of identities, and those identities need to present particular credentials. You want to do something very, very simple. To this day, you can't do it without a lot of hand coding. You have to code all that stuff in and then you have to communicate with anybody who wants to use your service to let them know through e-mail or a document or whatever, what they have to do in order to access that service. So the current model breaks with anything having to do with loose coupling. How will WS-Policy change that?
Enter WS-Policy. You'll be able to specify a security policy for your services, and a request or an application that needs to access that service can now automatically get that policy document and say, "Ah, I need to provide a credential using a SAML token or what have you, I need to encrypt this part of the message, etc., etc." And it will get done automatically, just as currently browsers know how to deal with SSL servers. Nobody does anything. It all gets done automatically. To use that analogy, WS-Policy will provide you with that layer of abstraction. And what does that mean for Web services and SOA?
All of a sudden, requestors and services can talk to each other and exchange policy and conform to each other's policy automatically without having to do all the external stuff we do today. Is that why you feel that WS-Policy is so important for Web services and SOA?<
It's crucial. To me, you cannot have Web services without policy. We're wasting our time doing Web services without dealing with policy. If we want loose coupling, and SOA is more than lip service, then you need policy. If it's just lip service to provide marketing buzz, then you can do anything you want. But if you're committed to building service oriented architectures that are loosely coupled, you absolutely cannot do it without policy.
It's a nightmare to develop, to implement, to deploy and to manage because every time you make a change, you're touching the code base. Imagine if every time you wanted to write an application, you have to go in and implement SSL all over again. Or you want to make a change. You want to add some encryption key or change the key length of your SSL handshake, you have to go into every application, and you have and make that change in the code base. Can you imagine something like that? That's in essence what we're asking people to do in Web services today. What about vendors who are essentially ignoring WS-Policy?
I think they're missing the boat. Because when WS-Policy gets implemented in their competitors' products, they will be left out in the cold. They won't be interoperable with anybody else. WS-Policy will be the fundamental mechanism that intermediates all the systems. All the entities within an SOA, whether it's a service or a requestor -- any entity -- in service oriented architecture will have a policy mechanism. People who don't play or won't play will be left out.