August 25, 2004
This document is a position paper for the W3C Workshop on Constraints and Capabilities for Web Services, and it is focused on one immediately valuable concept within the broader Constraints and Capabilities. This document represents the opinion of webMethods for standardizing WS-CRP Profiles. We extend special thanks to Marc Breissinger, Christopher St. John, Addison Phillips, Harris Reynolds, Ed Saltelli, Linda Nicholson, and Prasad Yendluri.
The term 'Policy' arose in many different contexts associated with Capabilities and Constraints. Some of these contexts overlapped, and some were completely distinct. This phrase is contentious and ambiguous depending on the context in which it is invoked. In light of this contentiousness and ambiguity, this paper will address the underlying concept by using the new phrase "Web Services - Capabilities, Requirements, and Preference Profiles" (WS-CRP Profiles).
Establishment of a CRP Profile that requires multiple exchanges is out of scope. The determination of what Capabilities should be used is also out of scope; this Profile only defines the boundaries of what features should and should not be used.
The declaration of Capabilities, Requirements, and Preferences is a large topic that requires its own specification, but it is not so large that a consensus cannot be reached in a timely fashion. The space around CRP Profiles is fragmented, and the community is divided. There are several candidate solutions already available. Unfortunately, the existing solutions either subset the problem into a piece that does not address the problems we deem important, or they attempt to address subjects which should be built on top of CRP Profiles.
Based on experience gained from implementing our current products, we find that the following concepts are independent and orthogonal to CRP Profiles. Because there is an immediate need for standardization around Capabilities and Constraints, and these concepts are separate and can be layered on top of what is produced for Capabilities and Constraints, the following should be out of scope:
In order to help our analysis of the existing specs, we developed the following six principles to represent the most important requirements for CRP Profiles:
The model should represent a list of related possibilities. Because this model will be used in the context of SOAP and WSDL, it should have an XML representation.
Because one of the key features of the CRP Profiles is the composition model, and several more generic composition models already exist, we oppose creating a new composition model that lacks the mathematical rigor put into existing composition models.*
A CRP Profile target is an entity, or a collection of entities, that is affected by a CRP Profile. For example, profile targets include service, endpoint, binding, interface, operation, input, and output. This target list is a slow growing collection, so we should not limit these profile targets. The core model should not include any references to the target.
To associate CRP profiles to a target, there must be first-class mechanisms to reference, include, or inline CRP Profiles.
Two or more SOAP nodes participate in message exchange processing. Each participating node may have its own CRP Profile. Participating nodes may merge profiles for constructing and transmitting messages. There must be a formal mechanism to merge profiles, and this mechanism should address resulting edge cases such as incompatible profiles, unusable profiles, conflict detection, and profile errors.
There should be an adjunct specification that describes how to associate CRP Profiles to targets for the common use cases. We envision three common uses cases for associating CRP Profiles to targets. They are:
Separate development of an entirely new mechanism does not appear to be required, because existing proposals can address all of the requirements listed here. Adaptation of one of these existing proposals to WS-CRP would permit rapid development of a specification and its adoption as a standard. In particular, we believe the following two proposals are good candidates for this work:
We suggest the following changes to the features, properties, and compositors proposal as it exists in the WSDL 2.0 and WG archives:
The advantage to this proposal is that it is based on what exists in WSDL 2.0 and open proposals in the WSDL WG, and therefore, it should be quickly adaptable.
In this example, security features must be used, and the profile owner indicates its preferences.
<crpp targetNamespace="uri">
<profile name="">
<choice>
<!-------------------------------------------------------->
<feature uri="http://schemas.xmlsoap.org/ws/2002/12/secext"
usage="required" preference="100">
<property uri="#tokenType">wsse:Kerberosv5TGT</property>
</feature>
<!-------------------------------------------------------->
<feature uri="http://schemas.xmlsoap.org/ws/2002/12/secext"
usage="required" preference="1">
<property uri="#tokenType">wsse:X509v3</property>
</feature>
</choice>
</profile>
</crpp>
If WS-Policy is submitted to W3C (we recommend submitting it to W3C), we suggest adding the following:
The advantage to this proposal is that most of the major players support it.
In this example, security features must be used, and the profile owner indicates its preferences.
<wsp:Policy xmlns:wsse="..."> <wsp:ExactlyOne> <!---------------------------------------------------------------> <wsse:SecurityToken wsp:Usage="wsp:Required" wsp:Preference="100"> <wsse:TokenType>wsse:Kerberosv5TGT</wsse:TokenType> </wsse:SecurityToken> <!---------------------------------------------------------------> <wsse:SecurityToken wsp:Usage="wsp:Required" wsp:Preference="1"> <wsse:TokenType>wsse:X509v3</wsse:TokenType> </wsse:SecurityToken> </wsp:ExactlyOne> </wsp:Policy>
During our analysis for this workshop, we also considered three other possible solutions around which we could standardize; we have discounted each for various reasons. WS-PL is too target-dependent and is expressed in terms of Rules, not Capabilities and Constraints. CC/PP needs a composition model and a merging mechanism. The IETF Policy Framework does not address merging, it has a code model instead of a data model; it seems primarily geared toward Service Level Agreements, Service Level Specifications, and Business Level Agreements, and it does not have an xml representation.
Profiles and capabilities are important to the development of interoperable Web services that rely on composed features and attributes. Several potential solutions exist. These should be quickly reconciled and a generally agreed-upon solution developed. For policies and profiles to be effective, there must be a consensus on a single standard. Therefore, we favor adopting a solution quickly. The two options listed above are technically equivalent for addressing the six principles outlined, so either is acceptable as long as there is a consensus.
A: XACML has had a formal analysis of its declarative semantics performed, and it describes the ambiguities and the undesirable interpretations within the specification. This provides a known set of problems. Any new composition model will surely have similar issues, which are unknowns.
Last Modified 08/27/2004 09:47:18 AM -0400