OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]