W3C home > Mailing lists > Public > public-ws-policy@w3.org > October 2006

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

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 17 Oct 2006 15:50:01 -0700
Message-ID: <2BA6015847F82645A9BB31C7F9D64165026D1568@uspale20.pal.sap.corp>
To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>, "Daniel Roth" <Daniel.Roth@microsoft.com>, "Frederick Hirsch" <frederick.hirsch@nokia.com>
Cc: "Frederick Hirsch" <frederick.hirsch@nokia.com>, <public-ws-policy@w3.org>
I think Fabian has a valid point here. There are several actors in the
equation. Stripping for one actor may not be appropriate for the other. 
 
I am well aware that a possible view to see this problem is to compile
different set of policy sets visible for different actors. However,
doing so does not necessarily imply that the "behaviors are optional".
Behaviors may be present even if one actor may not need to be aware of
the behaviors. This is why there is a slight problem with the language
that we have in the spec as it is written with respect to behaviors, not
about the necessity to understand the behavior expressed. 
 
--umit
 


________________________________

	From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] 
	Sent: Tuesday, Oct 17, 2006 5:50 AM
	To: Daniel Roth; 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 Daniel
	 
	I agree that we can use a private attribute when we need to
strip a server-only policy assertions which are about the server config
only...
	I'd still like us to think a bit more about possible advantages
of a well-known attribute recognized by every vendor... I like the
example Fabian provided about service brokers which can use wsp:local
assertions as the source for its own configuration... If we strip those
assertions initially then the brokers won't see them...
	I feel we might have some more useful scenarious where a
well-known wsp:local attribute might help. I absolutely agree that a
provider should do its best to strip such assertions. 
	 
	About the noise on the client...I think in case of wsp:local
assertions the client should not even report them as being unrecognized
because wsp:local are not even intended for a client as opposed to those
which are but a client may not be aware about... wsp:local is a hint to
a client : just ignore it, it's not anything to do with you...
	 
	"How does moving config information from WSDL extensions to
policy expressions make removing the config from the interoperable
metadata easier?"
	 
	well, I think I made myself to believe so :-). Perhaps the
client already knows how to deal with configs stored in seperate files
expressed using WS-Policy language. Then moving the a server-side policy
expression from a wsdl into a sep file will be easier because the client
already knows how to deal with policies. Otherwise the client has to
learn how to : move wsdl extensors into their private config format
files and deal with proper wsp:policies at the same time...
	And then again the fact that that proper policies will actually
configure the server service too. So we have sp:HTTPSToken in the wsdl
and some other endpoint specific config elsewhere, it's easier to have
both pieces of info grouped together and strip the latter one when
possible...
	 
	Cheers, Sergey

		
		

		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/
<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
<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
			>>
			>>
			> 
Received on Tuesday, 17 October 2006 22:51:20 GMT

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