RE: NEW ISSUE: New Attribute keyword to identify 'local' policies #3721

Hi Sergey,

> Perhaps we can just use our own custom attribute to mark such assertions and then remove them at the
> point of publishing the WSDL.

I think this sounds like the most reasonable implementation strategy.  Using a custom attribute to strip out the local config assertions reduces noise in the published policies.

> However, it may or may not work, depending on whether a service has a copy of the original wsdl or not.

Why do you need the original WSDL?  You should be able to process the WSDL you are about to publish as long as your custom attributes are preserved.

One of the conclusions of the WS-Policy interop workshop held in Germany was that even if a policy expression contains an unrecognized policy assertion tools can issue a warning and ignore it.  However, these warning are annoying and alarming to customers, so implementers should avoid leaking out local config assertions.

> We feel that a standard wsp:local attribute might provide an easier migration path toward the eventual
> removal of the server configs from a wsdl. First such configs are converted into WS-Policy expressions
> and then they might eventually be removed from the wsdl

How does moving config information from WSDL extensions to policy expressions make removing the config from the interoperable metadata easier?

Daniel Roth
________________________________
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
Sent: Friday, October 06, 2006 2:58 AM
To: Sergey Beryozkin; Frederick Hirsch
Cc: Frederick Hirsch; Yalcinalp, Umit; public-ws-policy@w3.org
Subject: Re: NEW ISSUE: New Attribute keyword to identify 'local' policies #3721

Hi

This is a follow-up message to the previous one where I'd like to describe some scenarious where we feel a wsp:local attribute may be of use.
The legitimate question, given that we see a wsp:local as a means to mark assertions which can only be of use to providers, is this : why, given that WS-Policy is about assertions which can be of use to both requesters and providers, we even offering this attribute for consideration ?

Scenario1.

WSDL is very extensible and customers have written custom plugins, which interpret custom wsdl:extensors as a source of additional configuration for those plugins. We may advise customers that doing so is an antipattern but this can not be enforced. For example, consider this pre-ws-policy wsdl fragmnet:

<wsdl:port>
 <soap:address location="https://foo"/>
 <custom:LogEverySecondRequestToThisPort/>
</wsdl:port>

location attribute has not a very interoperable way to say that HTTPS is requered. Additionally, a customer has written a message interseptor which uses a custom wsdl port extensor to configure it so that it knows that for a given port it should log every second message.

Now we have WS-Policy published and the wsdl is modified something like this :

<wsdl:port>
 <soap:address location="http://foo"/>
 <wsp:Policy>... <sp:HTTPSToken/> </wsp:Policy>
 <custom:LogEverySecondRequestToThisPort/>
</wsdl:port>

<custom:LogEverySecondRequestToThisPort/> is a piece of the server config. <sp:HTTPSToken/> is a good client-oriented assertion, but what is interesting it's a piece of the server config at the same time too. It  may not be easy to convince customers to move their custom expression out of the wsdl.
>From a higher level, <custom:LogEverySecondRequestToThisPort/> is a policy expression too, it'a server(local) policy expression. It's tempting and we believe may be useful to use WS-Policy language to serialize such policies too, so that we can have somethink like this :.

 <wsdl:port>
 <soap:address location="http://foo"/>
 <wsp:Policy>...
   <sp:HTTPSToken/>
   <custom:LogEverySecondRequestToThisPort wsp:local="true"/>
 </wsp:Policy>
</wsdl:port>

Now, we don't want a WS-Policy group to give an approval to putting a server config in the wsdl by giving us wsp:local. Perhaps we can just use out ouw custom attribute to mark such assertions and then remove them at the point of publishing the WSDL. However, it may or may not work, depending on whether a service has a copoy of the original wsdl or not.

We feel that a standard wsp:local attribute might provide an easier migration path toward the eventual removal of the server configs from a wsdl. First such configs are converted into WS-Policy expressions and then they might eventually be removed from the wsdl...

Scenario2. : temporarily mark client-oriented assertions as being not-supported rather than going thropugh the trouble of stripping it out of the policy. For ex, <sp:HTTPSToken wsp:local="true"/> notifies the client that a connection is now unsecure and that everyone can now see what a client sends (this is not the best practical example though :-)).

Scenario3. Haven't invented yet :-)

Cheers, Sergey

Hi Frederick,

Sorry for a late response.

First of all I'd like to draw a line between wsp:optional and something like wsp:local. We do not see any relationship between wsp:optional and wsp:local.

The differentiator between wsp:local and wsp:optional is simple. wsp:local marks assertions which are only intended for a provider. Provider *should do the best effort to strip such assertions out* of the policy to be published. If such an assertion is leaked then the only thing the client knows about it is that it has to skip it and move on to the next assertion. Client may choose to notice it but there're absolutely no obligations on the provider's behalf as to whether this assertion will be honoured or not.
wsp:local assertions are not the ones WS-Policy framework primer talks about when recommending best practices for policy authors. Good interoperatable policy assertion is the one which is understood and used by both parties involved. So why do we even want to create a noise in the WS-Policy space with wsp:local ? We feel there might some scenarios which I'll address in a follow-up message...

On the contrary wsp:optional and the whole optionality tar ball is about assertions which may be of use for requesters. wsp:local assertions may not be of use for requesters.

Optionality is a hint to a requestor. >From the provider's point view wsp:optional assertions are not optional at all, it guarantees to support them.

Given what I've said I'd like to say that I agree with some parts of your message but here're two parts which I'n not happy about :-) :

> 2) The client can choose to include or not in intersection operation,
> depending on interest.
I don't think wsp:local assertions can be of any interest to a client. I don't think we need a new attribute like wsp:local for assertions which a client may want to do something useful about. Policy alternatives/wsp:optional will do just fine for this to work.

> Without wsp:local/wsp:optional all assertions MUST be included in
> intersection operation.
Please see above. Lets just draw the line between wsp:local and wsp:optional :-)

> 3) This is additional information that a client might wish to consider.
Please see above. If it is of any use to a client then it's not a wsp:local assertion

Thanks, Sergey




> Sergey
>
> It was mentioned by Fabian on the call today that different
> assertions can have different properties, and I think this is where
> we are heading with wsp:local/wsp:advisory (alternative names for the
> same concept and attribute)
>
> In general an assertion present in a policy assertion means that the
> client MUST understand that assertion and that the provider WILL
> support it. This is regardless of whether the assertion has a wire
> implication.
>
> Using wsp:optional enables policy alternatives to be easily created,
> either requiring and asserting the assertion and not.
>
> However there are cases where wsp:optional is not what is desired,
> and where wsp:local/wsp:advisory is needed.
>
> The use case is that a provider should be able to state an assertion
> that will be in effect, but it obeys the following properties:
>
> 1) It can safely be ignored by web service client, even though true.
> The provider is making no obligation to the client. It has no
> essential impact on a contract between client and provider.
>
> An example is an assertion that server logging is performed (e.g.
> clients might not care about it, but it is *not* optional in the
> sense that the server *will* do it).
>
> 1a) Assertions that imply mutual contract between client and provider
> cannot be wsp:local/wsp:advisory. These include
>
> + Assertions that impact wire formats
> + Assertions that define quality of service (service level
> agreements), quality/reliable messaging.
>
> 2) The client can choose to include or not in intersection operation,
> depending on interest.
> Without wsp:local/wsp:optional all assertions MUST be included in
> intersection operation.
>
> 3) This is additional information that a client might wish to consider.
>
> we need to distinguish optional for agreement of a contract with or
> without an asserted requirement/capability and informational items
> that are not necessarily optional.
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
> On Oct 4, 2006, at 4:30 AM, ext Sergey Beryozkin wrote:
>
>> Hi
>>
>> Reference to the thread[1] is misleading IMHO.
>> I was stating from the start that a proposed wsp:local was nothing
>> to do with what is discussed in that thread. The semantics of
>> wsp:local are : mark assertions which *must be ignored* by a
>> requester. That is it, no more semantics...
>>
>> Thanks, Sergey
>> ----- Original Message -----
>> From: Yalcinalp, Umit
>> To: public-ws-policy@w3.org<mailto:public-ws-policy@w3.org>
>> Sent: Tuesday, October 03, 2006 11:44 PM
>> Subject: Re: NEW ISSUE: New Attribute keyword to identify 'local'
>> policies #3721
>>
>>
>> There has been a lot of discussion on Issues 3721 and 3564. I am
>> posting this response to this thread in order to illustrate why
>> there are two separate issues that need to be tackled
>> independently. However, they are NOT the same issue. Utilization of
>> optional assertions is a separate concern and those issues must not
>> be lumped together.
>>
>> Please find some comments in a different thread that explains why
>> there are two separate issues here for the details [1].
>>
>> Thanks,
>>
>> --umit
>>
>> [1] http://lists.w3.org/Archives/Public/public-ws-policy/2006Oct/
>> 0016.html
>>
>> ----------------------
>>
>> Dr. Umit Yalcinalp
>> Architect
>> NetWeaver Industry Standards
>> SAP Labs, LLC
>> Email: umit.yalcinalp@sap.com<mailto:umit.yalcinalp@sap.com> Tel: (650) 320-3095
>> SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
>> --------
>> "First they ignore you, then they ridicule you,
>> then they fight you, then you win." Gandhi
>>
>>
>