W3C home > Mailing lists > Public > public-ws-policy@w3.org > September 2007

Re: potential issues for WS-Policy Primer and Guidelines

From: Maryann Hondo <mhondo@us.ibm.com>
Date: Fri, 21 Sep 2007 16:32:51 -0400
To: Ken Laskey <klaskey@mitre.org>
Cc: public-ws-policy@w3.org
Message-ID: <OF561EC502.1ECA5AA8-ON8725735D.0070908B-8525735D.0070D6D4@us.ibm.com>
Ken,
Thanks for your detailed comments on the Primer and Guidelines.

The working group discussed these on our last call and we have prepared 
the following replies to your specific questions
which we hope you find useful.   Please let us know if there is any  more 
clarification required.

Policy WG [penned by Maryann Hondo]

------------------------------------------------------------------------------------------------------Q 
1a from Ken 
---------------------------------------------------------------------------
 1. [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.")
      a. This is quite an expansion of the word “policy”.  It seems to now
      include all description that is not specifically covered by WSDL
 
--------------------------------------------------------------------------------------------------------Response 
 1 
a---------------------------------------------------------------------------
Policy is an overloaded term.
There are many ways that the information not covered by WSDL can be 
expressed.
For example, the SAWSDL group has worked with the policy WG to try to 
elaborate
on the role of policy and the role of SAWSDL and we recommend you take a 
look at section  5.3.3 of the Guidelines document 
which is titled "Self Describing Messages".  In this section we try to 
differentiate between WSDL semantics and policy.
The WG has done its best to clarify its description of policy through 
clarifying our definitions of terms in
"terminology" sections of the specifications [ i.e, Section 2.4 in the 
Framework http://www.w3.org/TR/2007/REC-ws-policy-20070904/].

-------------------------------------------------------------------------------------------------------- 
Q1b  from Ken 
---------------------------------------------------------------------------

        b. 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 
a
        currently defined, but how is this used for non-service entities? 
        [Note, there are numerous other places where this comment 
applicable.]
 
--------------------------------------------------------------------------------------------------------Response 
1b 
---------------------------------------------------------------------------
Section 3 of the Guidelines [ section cited below ]  "What is an 
assertion?", attempts to describe what kind of metadata makes a good 
policy assertion as well as identifying that policy represents behaviors 
between Web service participants. We encourage you to review this section.

"Policy assertions representing shared and visible behaviors are useful 
pieces of metadata to enable interoperability and tooling for automation. 
The key to understanding when to design policy assertions is to have 
clarity on the characteristics of a behavior represented by a policy 
assertion. Some useful ways to discover relevant behaviors are to ask 
questions like the following: 
Is this behavior a requirement? 
Is the behavior visible? ....."

--------------------------------------------------------------------------------------------------------- 
Q 2 from Ken 
---------------------------------------------------------------------------


2. [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.
 
--------------------------------------------------------------------------------------------------------Response 
 
2--------------------------------------------------------------------------

The WG decided that in order to ground the Primer and Guidelines in 
reality, that we would present examples from existing policy domains. 
Unfortunately we did not have an example of this type of business policy 
to use. If you are aware of one, we would welcome any pointers, and would 
be willing to consider augmenting the Primer examples as a last call 
update.


--------------------------------------------------------------------------------------------------------- 
Q3 from Ken 
---------------------------------------------------------------------------


3. [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.

 
--------------------------------------------------------------------------------------------------------Response 
 3 
---------------------------------------------------------------------------
The Policy WG felt that specific details on tooling was an implementation 
detail that implementers should provide, and was out of scope of
the Primer and Guidelines.


 
-------------------------------------------------------------------------------------------------------- 
Q 4 from Ken 
---------------------------------------------------------------------------

4. [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.
 
--------------------------------------------------------------------------------------------------------Response 
 
4---------------------------------------------------------------------------
Again, the number and type of client requestors may vary, and therefore 
how a client generates or stores its policy is an implementation choice.

------------------------------------------------------------------------------------------------------- 
Q5 from Ken 
---------------------------------------------------------------------------

5. [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. 
        a. 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?

        b. 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.

 
-------------------------------------------------------------------------------------------------Response 
5a & b 
---------------------------------------------------------------------------
Negotiation is out of scope for the current policy WG, and we have an 
existing issue [ 3616 ] that is marked as a v-next topic. 
Also your case b. (b) appears to be a client side implementation detail.

--------------------------------------------------------------------------------------------------------- 
Q  6 from Ken 
---------------------------------------------------------------------------

6. [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.
 
--------------------------------------------------------------------------------------------------------Response 
 
6---------------------------------------------------------------------------
This seems to be a question of the granularity of discovery and this was 
again considered out of scope by the current working group but could be a 
v-next issue. Is there any other action you suggest? 

----------------------------------------------------------------------------------------------------Q7 
from Ken 
---------------------------------------------------------------------------

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.
-------------------------------------------------------------------------------------------------------Response 
 
7---------------------------------------------------------------------------

Section 3 of the Guidelines [ section cited below ]  also includes a 
description of visible behavior, that the WG has agreed to [ with some 
clarification cited in bold/italic].

Is the behavior visible? 
A visible behavior refers to a requirement that manifests itself on the 
wire. Web services provide interoperable machine-to-machine interaction 
among disparate systems. Web service interoperability is the capability of 
disparate systems to exchange data using common data formats and protocols 
supporting characteristics such as messaging, security, reliability and 
transaction. Such data formats and protocols manifest on the wire. 
Providers and requesters rely on wire messages conforming to such formats 
and protocols to achieve interoperability. 
If an assertion describes a behavior that does not manifest on the wire 
then the assertion will not impact the interoperability of wire messages, 
but may still be relevant to enabling an interoperable interaction. For 
example, a provider may not wish to interact unless a client can accept an 
assertion describing provider behavior. An example is an assertion that 
describes the privacy notice information of a provider and the associated 
regulatory safeguard in place on the provider's side. For cases where the 
provider does not intend the assertion to impact interoperability it may 
mark it as ignorable. 
If an assertion has no wire or message-level visible behavior then the 
interacting participants may require some sort of additional mechanism to 
indicate compliance with the assertion and to enable dispute resolution. 
Introducing an additional non-repudiation mechanism adds unnecessary 
complexity to processing a policy assertion. 

Received on Friday, 21 September 2007 20:33:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:53 GMT