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

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: RE: [ws-rx] [i021]: a proposal

Umit:

I find your argumentation quite surprising. I think there is a confusion between scope and role.

Although the Policy framework and Policy attachment define clearly the scope of application of policies related to policy subjects in WSDL, the actual semantics of a particular policy like RM Policy - how it must be interpreted w/r to the policy subject - remains ours.

I fail to see the problem in saying that when RM Policy assertions - which clearly identify two roles, Source and Destination, never even remotely identified in the general Policy framework and therefore relevant only to our specific RM policy domain - are attached to an endpoint, they must be interpreted with this endpoint acting in one of these roles (namely RM Destination)...

Speaking of the Policy framework in general, and of the more general issue of multi-role policies, I clearly understand now that either a major feature is missing in WS-Policy (about representing the quite common notion of role in policies), or a crucial profiling layer is missing above WS-Policy and below WS-RM Policy, that deals with roles and in which role a Policy subject is supposed to act w/r to this policy. But that is another debate, which leads me to withdraw the "scoping" part of my proposal, though.

Regards,
Jacques

-----Original Message-----
From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Tuesday, October 11, 2005 6:37 PM
To: Tom Rutt2
Cc: Jacques Durand; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [i021]: a proposal

 

> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com]
> Sent: Tuesday, Oct 11, 2005 2:37 PM
> To: Yalcinalp, Umit
> Cc: Jacques Durand; ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] [i021]: a proposal
>
> Yalcinalp, Umit wrote:
>
> > 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.
>
> I agree that the second part of Jacqeus proposal is
> unnessary.  We should
> just stick with his minimal update to resolve issue 21.
>
> The issue of finer granularity is issue 008, where in a separate
> proposal I recommend making all finer grained policy
> attachments outside
> the scope of ws-rm ,  treating such attachments as extension points.
>
> tom Rutt
>

Tom,

I am well aware that this is related to i008. One thing I did not make
clear in my response to Jacques is that I disagree with the "minimal"
update that is proposed by Jacques as well. It appears to be actually
breaking the Policy Subject scope without defining the clear semantics.
The scoping he proposed or introducing Message Policy Subject at least
defines the expected behaviour. Either we define it so that we do not
break the policy framework model or do not define it at all. Something
in between does not make sense to me.

--umit

> > 
> > 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
>
>
>