- 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 UTC