Re: [ws-rx] [i021]: a proposal

[Tom Rutt <tom@coastin.com>]

Jacques Durand wrote:

> Umit:
>
>  
>
> I have considered the message-as-Policy-subject option, and maybe it 
> is just a lack of familiarity with the Policy attachment rules  that 
> led me to propose the other option, which I initially thought as 
> simpler. I am quite willing to reconsider if my concerns were unfounded.
>
>  
>
> Let me explain my reserve on using the message-level attachment:
>
>  
>
> 1- I observe some reluctance to associate RM policies with portType 
> (WS-RM Policy, section 2.3) , the rationale being that RM assertions 
> specify a concrete behavior that should not be directly associated 
> with an abstract definition. But if we follow that line, Message is 
> also part of this abstract definition in WSDL, and I believe subject 
> to the same reserve that led to NOT attach to portType:
>
you can attache message subject level at message Binding , just as you 
can attach
bound port for endpoint subject level

>  
>
> "...For WSDL type definitions (portTypes and messages), the [Effective 
> Policy] for a WSDL
>
> type definition is considered an intrinsic part of the type definition 
> and applies to all uses
>
> of that type, in particular, to every implementation of that WSDL 
> portType.
>
> In the case of policies that apply to deployed resources (services or 
> ports), the [Effective
>
> Policy] applies only to the deployed resource itself...."
>
>  
>
> PolicyAttachment seems to clearly distinguish policies that apply to 
> the deployed resource, from policies that are inherently associated 
> with the definition of the service. That we might now attach RM 
> assertions on either kind of artifact was my main concern, given the 
> prohibition in WS RM Policy. (if we want message-level granularity, 
> maybe should we attach * inside*  a binding?)
>
>  
>
> 2. If we attach at message-level granularity, we need to be explicit 
> about possible inheritance conflicts - or about just conflicts (say 
> between binding and message, or port and message, as I am not sure if 
> we can talk of inheritance in such cases - I guess we can). 
> PolicyAttachment seems to discourage any form of overriding ("...It is 
> RECOMMENDED that additional policies at lower levels only further 
> qualify inherited policies....") And there is no clear statement of 
> what is the Effective Policy in case of conflicting assertions.
>
>  
>
>  On the other hand, I do not think the policy scoping solution is 
> requiring a change in WS Policy framework: only in RMAssertion schema 
> which this TC controls. But I concede such a change may call for a 
> generalization that goes beyond RM. (and instead of the notion of 
> "scope", the notion of "role" might be more common in  Policy dialects)
>
>  
>
> Anyway, open to more discussion on this - but wanted to point out that 
> there is no easy answer here.
>
> We may also decide to leaving out the "scoping" issue and just keep 
> for now the first clarifying statement about the endpoint to which the 
> Policy is attached,  always acting in the role of the Destination w/r 
> to this policy.
>
>  
>
> Regards,
>
> Jacques
>
>                                                                                                                                                 
>
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
> *Sent:* Tuesday, October 11, 2005 2:21 PM
> *To:* Jacques Durand; ws-rx@lists.oasis-open.org
> *Subject:* RE: [ws-rx] [i021]: a proposal
>
>  
>
> Hi Jacques,
>
>  
>
> I am somewhat baffled with your conclusion to arrive to a finer 
> granularity of policies and trying to solve the problem within the 
> functionality already available from policy attachment perspective.
>
>  
>
> Instead of introducing a scoping mechanism to the assertion itself, it 
> seems to me that allowing the assertion to apply to either Message 
> Policy Subject (scope=input/scope=output) or Endpoint Policy Subject 
> (scope=in-out), you will get what is needed instead of reinventing the 
> wheel. I observe that the scope that you have defined is not adequate 
> for MEPs that may have multiple inputs and outputs in the same 
> operation. I realize that such MEPs are not common today, but the 
> scoping mechanism proposed appears to be very restrictive. Message 
> Policy Subject will not have the same problem. We could restrict 
> attachment to either Endpoint Policy Subject or Message Policy Subject 
> and further disallow putting the RM assertions to 
> wsdl:portType/wsdl:operation/wsdl:{input/output} in order for the 
> assertions not to appear at the portType level in our spec so that 
> message level granularity is only achieved in the binding.
>
>  
>
> Further, we will not be changing the WS-Policy Framework if it is 
> going to be used. By inventing a scope, it seems to me we are 
> reformulating the attachment to a Message Context with your proposal, 
> but maybe I am missing something since I can not follow how you came 
> to the conclusion of introducing the scope is a better solution rather 
> than the one I described above. Perhaps you could clarify.
>
>  
>
> Thanks.
>
>  
>
> --umit
>
>  
>
>      
>
>     ------------------------------------------------------------------------
>
>     *From:* Jacques Durand [mailto:JDurand@us.fujitsu.com]
>     *Sent:* Tuesday, Oct 11, 2005 11:45 AM
>     *To:* ws-rx@lists.oasis-open.org
>     *Subject:* [ws-rx] [i021]: a proposal
>
>     Proposal for i021:
>
>      
>
>     Instead of the finer-granularity attachment of policies (e.g. at
>     message level) option, would propose the other option that is more
>     in line with the intuitive scoping of policies, which are
>     generally understood as applying to messages sent to the endpoint
>     (and not sent by).
>
>      
>
>     After Line 187 in Oct 6^th WS-RM Policy doc:
>
>      
>
>     "As seen above, elements of an RM Policy assertion may concern the
>     behavior of either an RM Source (e.g.
>     wsrm:BaseRetransmissionInterval), or of an RM Destination (e.g.
>     wsrm:AcknowledgementInterval). When attached to a service
>     endpoint, although the endpoint may alternatively act as a Source
>     and a Destination for operations that use both input and output
>     messages, an RM Policy assertion will by default only apply to
>     this endpoint in its Destination role. By default, any client to
>     this endpoint must comply with the RM Policy assertion elements
>     that concern the Source role."
>
>      
>
>     That would be the minimal update needed to remove ambiguity.
>
>      
>
>     Other side of the issue 021: how do we attach a policy to a
>     service endpoint that governs output messages - say, a service
>     endpoint is requiring its clients to use RM protocol and send back
>     Acks with some AcknowledgementInterval T (possibly different from
>     the policy assertions that govern the input messages)?
>
>      
>
>     Proposal is to add an attribute to wsrmp:RMAssertion element: @scope.
>
>     - If @scope="in" (default) then the assertion applies to input
>     messages only (service endpoint acting as RM Destination)
>
>     - If @scope="out" then the assertion applies to output messages
>     only (service endpoint acting in RM Source role).
>
>     - if @scope="inout" then the assertion applies to both input and
>     output messages.
>
>      
>
>      
>
>     I'll draft the formal proposal for that schema update after
>     getting some feedback on the idea.
>
>      
>
>     -Jacques
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133