Position Paper for W3C Workshop on Rule Languages for Interoperability
Authors
Chris Swan
Hugh Grant
Contributors
Mark Luppi
Iain Craig
Purpose of this document
To outline a use case for rules within web services governance, and highlight the benefit of a unified rules vocabulary in place of the fragmented approaches presently being taken.
The need for governance
1) To ensure that architectural decisions are actually implemented
- for compliance with corporate standards (e.g. naming, best practices etc.)
- for interoperability between services and clients (e.g. WS-I basic profile)
2) To ensure that run-time policies are followed
- security policies
- SLAs
3) To assist in the change management process for a community of service users
- by providing impact analysis etc.
Examples of governance
Static governance determines the nature of design time artefacts such as XSDs and WSDLs
e.g. "all services must only use schemas that are registered in the corporate data dictionary"
In order to execute static governance rules must be evaluated as key documents move through their life cycle.
e.g. "WSDL files must be validated before being published to a registry"
Dynamic governance defines the behaviour of systems at run time / on the wire, and would be determined by management policies, security policies, SLAs etc.
e.g. "all trade related messages must be secured in accordance with SEC guidelines"
Rules for dynamic governance need to be embedded in policy enforcement points (PEPs) inserted into the message flow (such as Web Services Management proxies/agents and security appliances).
How is this done today?
Most static governance applications work on XSLT/XPath, and WS-Policy appears to have had little practical impact so far. For dynamic governance most PEPs are driven by standardised application specific vocabularies such as XACML or vendor proprietary languages/notations.
Why is this a problem?
The diversity of languages means that a great deal of bespoke integration work is needed to achieve interoperability between a number of components within an enterprise web services framework (e.g. developers workbench - registry and registry - web services management).
How can rules help?
With a standard rules vocabulary in place for description of web services governance it would be natural for the builders of individual components within a framework to migrate towards that standard, and thus reduce the integration necessary for interoperability between components.
This will reduce the cost and time taken to build out/update a web services
infrastructure. It should also allow for consolidation of the tooling required
for defining and editing rules, which can be expected to create a larger mass of
expertise familiar with the practices of working with rules.
Implementation issues to be aware of
Lifecycle - how are rules versioned, and how do we manage working with
multiple versions of the same rule?
Security - do rules need to be signed to show that they are authentic, and how
do we control access to rules?