potential issues for WS-Policy Primer and Guidelines

I recently did a full read of the WS-Policy specs and I believe I  
have a fairly good understanding of WS-Policy Framework and  
Attachment specs that are now at PR.  However, there appears to be a  
lot implied by those specs and I expected an expanded discussion in  
the Primer and Guidelines drafts, but these do not cover many of the  
gaps that jumped out at me.  In this email, I'd like to raise those  
points for discussion and, as appropriate, could later make concise  
entries in Bugzilla.

The following section summarizes what I feel is lacking and specific  
references illustrating my issues follow after that.

Summary
-------------
The issues could be classified as asking for a clear definition of  
scope and suggestions for how that scope would be accomplished.  It  
also argues for not having too restrictive a scope because this would  
hinder much of the capability needed by policy consumers and not just  
tool developers.

1. The expanded definition for policy [1] at times seems to cover an  
immense amount of the general description space but then the examples  
for use are mostly restricted to the tedious (but necessary for  
message level interoperability) details.  The discussion does not  
support the business use that is needed if services are to accomplish  
more than geek talk.  Even at the wire level, a big gap is how do  
consumers use WS-Policy to express their capabilities and  
requirements that will be used to determine policy intersection.  The  
consumers do not have WSDLs and may have no interest in UDDI.  They  
do, however, want to point to a policy that says you should not sell  
their contact information, i.e. what was carefully exchanged in a  
manner to initially ensure privacy will remain private.

2. The specs do not adequately address support for discovery.  If  
anything, they make discovery very difficult because policy  
attachment is all over the place and the roll up is to the levels of  
finer granularity rather than the service level where most people  
would expect to find it.  Information expressed as policies will  
likely form an important set of the search criteria when looking for  
services (more typically, looking for the business effects that  
result from the service interaction [2]) and there is no guidance  
(and seemingly no consideration) on how such information can be  
effectively used for discovery or any other function besides message  
level protocols.

[1] For example, [Primer, section 2.1] Web Services Policy is a  
machine-readable language for representing the capabilities and  
requirements of a Web service. These are called ‘policies’.  Also,  
consistent text in WS-Policy Framework states, "A policy assertion  
represents a requirement, capability, or other property of a behavior."

[2] Are the "business effects", i.e. what happens when you interact  
with a service, supposed to be expressed as part of "capabilities and  
requirements" covered by WS-Policy?  My initial read was yes, but am  
I reading too much into it?    Again, supporting consumer policies so  
you have something with which to intersect services policies seems to  
be important in the current context.


Specific references
--------------------------

[Primer, section 2.1] Web Services Policy is a machine-readable  
language for representing the capabilities and requirements of a Web  
service. These are called ‘policies’.  (Consistent text in WS-Policy  
Framework states, "A policy assertion represents a requirement,  
capability, or other property of a behavior.")
This is quite an expansion of the word “policy”.  It seems to now  
include all description that is not specifically covered by WSDL  
syntax.  Is this intended?
The Primer later talks to policy intersection but this would require  
policy representation for non-service entities, such as a consumer  
expressing a required privacy policy not to sell my contact  
information.  The Framework and Attachment mechanisms may suffice as  
currently defined, but how is this used for non-service entities?   
[Note, there are numerous other places where this comment applicable.]


[Primer, section 2.7] The wsp:Ignorable attribute allows providers to  
clearly indicate which policy assertions indicate behaviors that  
don’t manifest on the wire and may not be of concern to a requester  
when determining policy compatibility.  This is an example of the  
specs alluding to more general use and then getting lost in WS- 
Minutiae.  The policies likely to be of greatest consumer/business  
interest are the capabilities invoked by a service and the real world  
effects that result.  If WS-Policy is supposed to convey such  
information, the “user specs” (e.g. Primer and Guidelines) need to  
come at least equally from that viewpoint.


[Primer, section 3.3] It is important to understand that a policy is  
a useful piece of metadata in machine-readable form that enables  
tooling, yet is not required for a successful Web service  
interaction. Why? Web service developers could use the documentation,  
talk to the service providers, or look at message traces to infer  
these conditions for an interaction. Developers continue to have  
these options, as they always had.  Again, the overriding perspective  
in tooling and not the non-developer use that most consumers will  
need of policy.  Yes, if most users see this as WS-Minutiae, most  
policy/description will remain in other communications.

[Primer, section 3.4] A provider, like Company-X, and a requester,  
like the policy-aware client used in our example, may represent their  
capabilities and requirements for an interaction as policies...  The  
next section describes how to attach policies to service WSDLs but no  
where does it say where the requester policies go.  Note, saying you  
put them in a UDDI registry is great marketing for UDDI but otherwise  
unacceptable.  In addition, the Attachment spec addresses the  
“technical” rolling up of abstract (tModel) to concrete  
(bindingTemplate) but not the “business” question of how policies on  
businessEntity and businessService combine with Endpoint or each  
other to express business constraints.


[Primer, section 3.4.1] A requester can decide how to process a  
provider's policy to determine if and how the requester will interact  
with the provider. The requester can have its own policy that  
expresses its own capabilities and requirements, and can make one or  
more attempts at policy intersection in order to determine a  
compatible alternative and/or isolate the cause of an empty  
intersection result. The requester can use and analyze the result(s)  
of policy intersection to select a compatible alternative or trigger  
other domain-specific processing options.  This is actually very  
important for several reasons.
It highlights again the intent to have WS-Policy cover a wide range  
of description (e.g. what effects does the requester want), some  
boilerplate and some specific to the interaction.  Where are Primer  
suggestions for requester side of interaction?
Once this negotiation has been done, there is a need to save the  
result for (a) documenting how the interaction occurred, (b) avoiding  
a renegotiation every time the same requester tries to use the same  
service.


[Primer, section 3.5] If multiple policy expressions are attached to  
WSDL elements that collectively represent a policy subject then the  
effective policy of these policy expressions applies. The effective  
policy is the combination of the policy expressions that are attached  
to the same policy subject.  Here I have a fundamental hurt point.  I  
have no argument as described, e.g. if you attach a policy to an  
abstract component, then it should apply to its concrete instance.   
The problem is the roll up goes downward to the finer component  
rather than upward to the service itself.  Yes, the Framework spec  
[Introduction] says it “does not cover discovery of policy”, but how  
do I discover a service if the details of its description can be  
found anywhere in the lowest levels of its WSDL?  Again, the specs  
imply expansive coverage but only really consider the lowest level  
nuts and bolts that are of little interest to most users whose domain  
is policies.

7.  [Guidelines, section 2] A visible behavior refers to a  
requirement that manifests itself on the wire.  This is again much  
too limited to the technical perspective.  A visible behavior is one  
that the participants can see in the real world and will likely have  
nothing directly to do with the message on the wire.


My apologies for not being familiar with possible past discussions  
and I would certainly be willing to catch up if someone can point me  
to the appropriate material in the archives.

I look forward to hearing from the collected wisdom on these questions.

Thanks,

Ken

------------------------------------------------------------------------ 
------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508