BOSTON -- One of the promises of Web services was that developers would be able to build loosely coupled applications. Toufic Boubez thinks that promise has been broken.
Addressing a packed room at the Web Services Edge 2005 show, Boubez, chief technology officer of Vancouver, British Columbia-based Layer 7 Technologies Inc. and co-author of the universal description, discovery and integration specification, expressed his frustration with the limitations of the Web Services Description Language (WSDL).
"WSDL is really just an API [application programming interface]," Boubez said. "It's totally inadequate to address many of the policy rules such as who can access a Web service. In order to describe Web services, you need more than just an API. Why would I want to expose my back-end systems to the Web when there are issues such as security, privacy and reliability?"
The fact that SOAP messages contain transport URLs, user information in the header and need to know how to interact with the WSDL API creates three levels of tight coupling, according to Boubez.
By refactoring the policy of a Web service into a formalized policy document, the WSDL can more flexibly bind to a policy at runtime. The policy and decision enforcement point works in conjunction with a policy registry, which takes care of sending the WSDL document to the client.
Nevertheless, the client is still coupled to the policy details.
"[Tight coupling between the client and the policy] has slowed down the adoption of Web services," Boubez said.
To solve this problem, he introduced another point into his architecture diagram that sat right in front of the client, known as the policy application point. The policy application point acts as a proxy for policy details and allows the client to focus on programming to the WSDL body. The policy application point handles all the details of the WSDL document and the signed policy document.
"[We've created] a buffering approach on both ends," Boubez said. "This is a closer step to decoupling systems."
The flexibility of policy allows for more dynamic Web services based on the runtime needs of the client.
"While Web services make SOA possible, governance makes SOA practical," Boubez said. "SOA governance enables definition, deployment, management, enforcement and compliance audit of corporate policies."
In a separate presentation, Brent Carlson, vice president of technology at Pittsburgh-based LogicLibrary, said businesses need to manage what his company calls software development assets. SDAs come in two forms, Carlson said -- knowledge assets, such as architectures; best practices, patterns and executable assets; such as Web services, components and applications.
In addition, SDAs are composed of meta data describing software artifacts or how an SDA relates to other assets.
SOA governance involves the effective management of these assets throughout the service development lifecycle, using an asset management repository.
Carlson outlined three core SOA governance principles: managing the development lifecycle of services, aligning services development and deployment infrastructure, and providing operational feedback to service developers on a timely basis.