Re: Behaviour of WS-Policy aware clients

Sergey,

The specification defines an algorithm for assertion intersection.

Umit and I have also drafted a set of guidelines for the group to 
consider(http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0054.html) 
as non-normative text to primarily help assertion authors, but it can also 
be useful more generally, in my opinion.
We originally proposed this as a "primer" (hence the name in the email) 
but the group decided at the F2F last week that this material 
was "guidelines".

The assertions and their behavior need to be defined by the authors of the 
assertions.
WS-SecurityPolicy is an example of how this can be done.
In your example, "oasis" would need to define this assertion and the 
behavior it represents.

Maryann





"Sergey Beryozkin" <sergey.beryozkin@iona.com> 
Sent by: public-ws-policy-request@w3.org
09/20/2006 04:48 AM

To
Maryann Hondo/Austin/IBM@IBMUS
cc
<public-ws-policy@w3.org>, <public-ws-policy-request@w3.org>
Subject
Re: Behaviour of WS-Policy aware clients






Hi Maryann
 
Thanks for your answer.
 
The real motivation behind my question, especially behind the first one, 
is to understand what a requester
should do if it encounters a policy with a single alternative which 
contains a bunch of assertions with no wire manifestations.
 
Consider this example :
 
<wsp:Policy>
   <wsp:ExactlyOnce>
         <oasis:QOSGuarantee>
              <NeverFails/>
              <TheBestServiceInThisCategory verifiedBy="..."/>
         <oasis:QOSGuarantee>
   <wsp/ExactlyOnce>
<wsp:Policy>
 
A (requester) entity may use this policy in order to select this service 
among many other similar services.
The above oasis:QOSGuarantee policy assertion has no wire manifestations, 
it can be used by a requester for a proper services selection only. In 
other words, irrespectively of whether the (requester) entity fails to 
recognize this assertion or not, it can not affect the outcome of the 
communication with a given service as this assertion has no wire 
representations.
 
Hence the question :
 
* should a ws-policy aware (requester) entity fail if it can't support the 
above policy due to the fact its single alternative is not recognized. 
Note that oasis:QOSGuarantee may be a well-known policy expression but 
this given entity's runtime just is not aware of it yet.
 
Cheers, Sergey Beryozkin
Iona Technologies
 
 

Sergey, 
We're currently working on clarifying the text. 
In the interim, I'll give you my opinion. 

First of all, the goal of policy is to have assertions define the 
capabilities and constraints of an "entity" ( we are working on changing 
"requestor" and "provider" to "entity" with an e.g, requestor/provider) to 
enable interoperability of web services. 

So, if a "provider" indicates a constraint ( let's assume its " all 
messages to me must be signed") and you don't know what that means, then 
chances are any attempt to send a message to the provider will fail.  If 
you're really, really lucky, and you always sign all your messages maybe 
you'll guess right on the algorithm and other metadata about signing, but 
its kind of a long shot. 

For 2, again, the idea here is if you are the "provider of a service" you 
probably want people to get messages to you (othewise, why expose a 
service?). 
If you support a whole bunch of options, but don't tell anyone about it, 
chances are a few people may try, but if they try and fail, not many 
people are going to keep trying to send you messages with every possible 
alternative configuration. 
Maybe you have something that people can't live without and they're 
willing to try, try again, but I find there's a point at which they will 
move on to someone who is clear about their expectations thus increasing 
their chance of success.The intent of web services is to enable 
interoperability, if you want to hide why bother exposing your services? 

In order to demonstrate interoperability there are some requirements: 

A requester may choose any alternative since each is a valid configuration 
for interaction with the service, but a requester MUST choose only a 
single alternative for an interaction with a service since each represents 
an alternative configuration. 

If an assertion in the normal form of a policy expression contains a 
nested policy expression, the nested policy expression MUST contain at 
most one policy alternative 

but there is not currently normative text that I'm aware of that says "A 
client MUST not send a message" because I'm not sure how anyone would 
enforce this. 

Maryann 




"Sergey Beryozkin" <sergey.beryozkin@iona.com> 
Sent by: public-ws-policy-request@w3.org 
09/19/2006 12:29 PM 


To
"Sergey Beryozkin" <sergey.beryozkin@iona.com>, <public-ws-policy@w3.org> 
cc

Subject
Behaviour of WS-Policy aware clients








Hello 
  
A couple of questions on the expected behaviour of a WS-Policy aware 
client. 
  
1. Suppose we have a policy with a *single* alternative which a 
policy-aware client can not support 
due to the fact it does not *recognize* its assertions (no intersection is 
involved). 
Is it expected to fail ? Can it attempt to initiate a communication with 
the provider ? 
  
1. Suppose we have a policy which a policy-aware client can not support 
due to the fact an intersection produced an empty set. 
Is it expected to fail ? Can it attempt to initiate a communication with 
the provider ? 
  
Thanks, Sergey Beryozkin 
Iona Technologies