Re: WS-Policy theme - [was: RE: Starting our discussions]

I am looking at WS-Policy (and related assertions) to see what 
guidance and/or constraints should be provided for US Air Force and 
the broader DoD and intelligence community.

I am concerned about the lack of clear requirements for a 
"policy-aware client" and the things that are out-of-scope for the 
WS-Policy WG, but are certainly in-scope for enterprises that want to 
use WS-Policy.

For example, policy retrieval for PolicyReference/@URI (which 
"identifies" a policy expression) is out of their scope.

I provided an example for the Primer last call working draft using a 
UDDI key as the identifier.

The WS-Policy Attachment REC specifies how to attach policies to WSDL and UDDI.

There is also mention of WS-MEX (Metadata Exchange), which has not 
yet been formally submitted to a standards organization, but is 
another player in this arena.

Some organizations that I deal with are using Systinet 2, which has 
policy management support.  Systinet 2 is also a repository and has 
support for RSS feeds.  There may be an RSS feed with links to 
WS-Policy expressions.
I can also bookmark some links to WS-Policy expressions in something 
like del.icio.us, and get an RSS feed of those.  So, I can have 
something like <PolicyReference URI="http://example.org/myrssfeed" />.

I can envision a "policy-aware client" that is given a WSDL with the 
above PolicyReference.  How does this policy-aware client know that 
@URI is the URL of an RSS feed, and that policy retrieval should  be 
done by getting the RSS feed, then get the associated policy 
expressions that the feed points to.

What if I bookmark the links to XML representations of UDDI tModels 
that in turn point to WS-Policy expressions.  In this case, @URI 
still points to an RSS feed, but the policy-aware client must first 
retrieve each UDDI tModel, then follow the overviewURL to retrieve 
the policy expression.

You may argue that the @URI should point directly to a policy 
expression (stored in a repository like Systinet 2, or some other 
content management system, SVN, or any simple HTTP server).  I may 
put PolicyReference in WSDL and point directly to the policy 
expression.  However, for other reasons, I may also want to publish 
UDDI tModels that point to the policy expression.  So I have both 
UDDI and WSDL pointing to a policy expression.  Now, if I want to 
change the policy, I have several ways I can do it.  I can author a 
new policy expression and store it at the same URL as the old policy, 
so I would not need to change the @URI in WSDL or the overviewURL in 
the UDDI tModels.  If on the other hand I want to keep the old policy 
at the old URL, then my new policy needs a new URL, and I need to 
change the @URI in all WSDL that point to the old policy, and also 
change the overviewURL in the UDDI tModel.  I may want to have the 
WSDL reference the UDDI tModel to avoid the need to change all WSDL 
that need to point to the new policy expression, and I can change 
only the overviewURL in the UDDI tModel.

As you can see, there are numerous ways to organize all this stuff, 
and a "policy-aware client" may need a way to figure out which way 
that my organization has arranged it, which could be different from 
the way that your organization arranges it.
I had suggested adding a "policy retrieval algorithm" attribute which 
would hold a URI/IRI that "identifies" the pattern for policy 
retrieval.  The WS-Policy WG pushed back on that because policy 
retrieval was out of scope.  I was not suggesting that they define 
how to retrieve the policy expression, but I was hoping that they 
would define a place to put an identifier that policy-aware clients 
would be able to use to figure out how (of possibly many different 
ways) it should retrieve the policy expressions that it needs to work 
as intended.

If I buy a policy-aware client from vendor X, what is the chance that 
it will know how to retrieve the policy expressions that are 
referenced from the PolicyReference elements that it is given to 
process?  Pretty slim.  If I can't buy a policy-aware client that can 
retrieve my policies, why should I bother with WS-Policy at all?  I 
am concerned that the capabilities of particular policy-aware clients 
will dictate how I need to organize my policy information, rather 
than organize the policy info in a way that makes sense to my 
enterprise, then have policy-aware clients that can be easily 
configured to work in my environment (and yours).

Another concern ...
I don't have a good-enough handle on the different roles that may be 
associated with a policy ecosystem.
The WS-Policy WG has Guidelines for Assertion Authors.  There are 
roles other than "assertion author", which can be grouped under the 
umbrella of "policy assertion users".
The last call WD of the Guidelines note had some distinctions that I 
did not fully grok.
http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070928/
It talked about "expression authors" as a role that is different from 
the "providers of policy expressions."
The WG members seemed to clearly understand the distinction, but I 
did not quite see the distinction myself.
http://www.w3.org/2007/10/24-ws-policy-minutes.html#item12


Paul


At 11:28 AM 2007-10-20, Casassa Mont, Marco wrote:
>Hi Ashok and all.
>
>Ashok, welcome to this mailing list! In your previous e-mails, you 
>introduced a theme on WS-Policy. Specifically, you asked the communities for:
>
>1. examples of usage of WS-Policy in various areas along with use 
>cases where WS-Policy capabilities have been stretched/revealed their limits
>
>2. any further work (in addition to the ones you mentioned) around 
>integration of XACML with WS-Policy
>
>3. any concerns about the fact that policy assertions are not 
>ordered and use-cases/examples where ordering of these assertions is required
>
>Would anybody in this mailing list like to share their view and/or 
>experience with WS-Policy?
>Is any of you currently using or experimenting with WS-Policy?
>
>Please feel free to share your comments and opinions.
>
>Marco
>
>
> >-----Original Message-----
> >From: public-pling-request@w3.org
> >[<mailto:public-pling-request@w3.org>mailto:public-pling-request@w3 
> .org] On Behalf Of ashok malhotra
> >Sent: 17 October 2007 19:01
> >To: public-pling@w3.org
> >Subject: Starting our discussions
> >
> >
> >Hello:
> >My name is Ashok Malhotra and I work for Oracle in the area of
> >Web Services Policy.
> >I have spent several years working on WS-Policy.  Now that
> >WS-Policy is a W3C Recommendation, I predict people will start
> >to use it for many different purposes, not just for screwing
> >with message headers and message bodies which is what
> >WS-Policy was designed for.
> >
> >As they start using WS-Policy for different purposes they will
> >stretch and perhaps break its capabilities.  I am looking for
> >examples where this happens so that we can start thinking
> >about extension to WS-Policy or a new policy framework, whatever!
> >
> >I am also, of course, interested in the use of WS-Policy in
> >interesting, unusual areas so we can spread the word and offer
> >guidance to other folks with similar needs.
> >
> >I'll be sending out a couple of follow-up notes with  specific
> >requests.
> >--
> >All the best, Ashok
> >
> >
>
>----------
>Marco Casassa Mont
>Senior Researcher
>Hewlett-Packard Labs
>
>+44 117 3128794 Phone
>+44 117 3129250 Fax
><mailto:marco_casassa-mont@hp.com>marco_casassa-mont@hp.com
>http://www.hpl.hp.com
>
>External Web Page: 
><http://www.hpl.hp.com/personal/mcm/>http://www.hpl.hp.com/personal/mcm/
>Blog: 
><http://h20325.www2.hp.com/blogs/mcm>http://h20325.www2.hp.com/blogs/mcm
>  'All points of view are my own and not necessarily HP's as well'
>Hewlett-Packard Limited registered Office: Cain 
>Road,      Bracknell,  Berks RG12 1HN Registered No: 690597 England
>
>The contents of this message and any attachments to it are 
>confidential and may be legally privileged. If you have received 
>this message in error, you should delete it from your system 
>immediately and advise the sender.
>
>To any recipient of this message within HP, unless otherwise stated 
>you should consider this message and attachments as "HP CONFIDENTIAL".
>
>----------
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Received on Friday, 26 October 2007 14:25:42 UTC