Menu
SOA: A Governance Nightmare

SOA: A Governance Nightmare

How do you protect and connect applications as services across departmental and organizational boundaries in a flexible and scalable way?

Boubez says policies are not the sole domain of service providers but should exist both for providers and consumers. As SOA implementations become more dynamic, policy agents for both the Web service provider and the consumer will be able to negotiate terms. This negotiation between policies should lead to the creation of a contract between two entities.

However, he also warns that while policy enforcement points can play a very important part in SOA, that is only half of the equation.

"Let's say your architects and developers are moving towards an SOA and implementing vendor managed inventory and you want to give access to your IT inventory management systems to your partners or to your vendors. If they provide a policy abstraction layer and maybe they buy an XML gateway or an XML firewall they can, using that XML firewall or XML gateway, go and create policies for their Web services, which is great. So now they are doing it right and they've taken all of that stuff out of the hands of developers and put it in that declarative, administrable layer.

"But that's only half of the equation and only solves half the problem, which to my mind is the least interesting half of the problem. There is still the issue for everybody who is writing applications that are going to require those services."

So even more important than policy enforcement is a concept known as "policy application points", Boubez says. CIOs should only go with vendors that offer such policy enforcement points, whether they call them XML firewalls, XML gateways or Web services gateways.

When the policy of a Web service is refactored into a formalized policy document, the WSDL can more flexibly bind to a policy at run-time. The policy and decision enforcement point works in conjunction with a policy registry, which takes care of sending the WSDL document to the client, he says, while leaving the client still coupled to the policy details.

The policy application point acts as a proxy for policy details and allows the client to focus on programming to the WSDL body. The flexibility of policy allows for more dynamic Web services based on the run-time needs of the client.

Boubez says the policy application point at the client side decouples the requester from the security policy requirements, in the same way that the policy enforcement point decouples the Web service itself. The policy application and enforcement points can exchange policy documents and coordinate at run-time to make the whole security mechanism truly loosely coupled.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about Application TechnologiesCornerstoneGatewayImmersionInventory Management SystemsLogicalMicrosoftPromiseUDDI

Show Comments
[]