Toufic Boubez, chief technology officer for XML networking vendor Layer 7 Technologies Inc., sees service-oriented architecture (SOA) moving to a stage where enterprises implementing it need "practical operational governance." Boubez, co-author of the original UDDI specification, has been part of the emergence of Web service and SOA from its genesis. Most recently, he worked as an editor on the W3C working group that completed the WS-Policy specification this past summer. Previous to joining Layer 7, Boubez served in IBM's Emerging Technologies Group back when that group helped to build the foundation for SOA. He was also lead Web services architect, publishing IBM's first SOA toolkit.
Where do things stand with WS-Policy now?
Toufic Boubez: WS-Policy is a W3C recommendation, which means it's done for all intents and purposes. We're very happy about that. It was probably one of the fastest cycles for a standard that I remember. I could be wrong, but it was one of the fastest from the charter of the working group to ratification. It's starting to make its way into products. There are a lot of vendors at the interops for WS-Policy so it's definitely gaining traction. A lot of customers are starting to include WS-Policy on RFPs [Request for Proposal]. I'm going to Europe next week, where several customers, these are end users, have an active interest in having WS-Policy as part of their requirements.
What other trends are you seeing in governance?
Boubez: What we've been doing is moving to what we call operational governance. There's big governance where you have a process for requirements gathering, a process for development and one for QA and so on. That's good for your general governance, but what we are seeing based on customer feedback, which is really important to us, is customers agreeing that big governance is important, but what they want is practical governance when we start deploying applications. So we're calling this operational governance.
What does operational governance include?
Boubez: It includes practical matters such as who gains access to the policies? How do you create policies? How do you deploy a service? How do you provision policies for that service? How do you relate the service lifecycle to the policy lifecycle? That's really important. So we've been working on the policy lifecycle and how you relate it to the service lifecycle. How do you evolve it? How do you deploy them? Who gets access to what part of the policy? How do you virtualize policies so you can deploy them to different services? How do you virtualize services so you can apply the same policies? How do you monitor and audit your policies? There's a whole lifecycle for policies that we call operational governance. So we're adding more features for that in our products and it's resonating in the marketplace. I think people are looking for practical things they can do before they start the big governance thing.
In terms of operational governance what are the best practices there?
Boubez: One of the things – it seems trivial, but it's an important example – is when you deploy a service you need to be able to create policies, whether it's access policies or service level agreement policies, or any policy. Because when you deploy a service, it isn't a reusable service until you can deploy a policy around it. So establishing that requirement as a best practice is very important. But after that, okay you're created a policy, but what does that mean? Is it immediately in effect? There has to be a separation between policy offering and policy deployment. So your architect or your security folks can author a certain policy for access control or service level agreement, but then somebody else has the role of auditing that policy and approving it and then deploying it. It may sound simple, but it is enormously important in real-world operation governance.
Another example is RBAC, or role-based access control. You don't have one person creating all the policies in the real world. It doesn't happen that way. Different areas have different roles. The architect may create transformation policies, but then the security policies for access, encryption, confidentiality need to be done by the security organization. And maybe your routing policies are done by operations. So creating role-based access control for your policy mechanism is very important. Because its not one person creating policies. The operations folks may not understand PKI or encryption or WS-Security, but they do understand service level agreements. So we've created the RBAC model in policies so you have different roles create different aspects of the policies for your services.
So that's the kind of stuff we're doing around operational governance.