Re: [Bug 6721] New: Attaching policy to implicit operations

Yes, Katy, something along those lines.
Gil is looking at Policy for WS-Eventing and may have other comments.
All the best, Ashok


Katy Warr wrote:
>
> Hi Ashok
>
> I'm sure that I'm mis-communicating and not you!   I'm still not sure 
> where you would attach policy to an implicit operation in the EPR 
> without some sort of pattern.  
>
> Perhaps a real-ish example could help us here: Consider attaching 
> imaginary SecurityPolicy (symmetric binding+Signed supporting tokens) 
> to an Eventing.subscribe message.  
>
> How do you envisage that example looking in EPR metadata?  I think 
> that we could potentially use a similar pattern to that suggested in 
> the issue but applied to the EPR, giving (something along the lines 
> of) this:
>
>  <wsa:Metadata>
>    ...
>    <wsp:Policy>
>       <wsra:WS-Eventing>
>          *  ** <wsra:SubscribePolicy>*
> *                <wsp:Policy>*
> *                   <wsp:All>*
> *                       <sp:SymmetricBinding>*
> *                           ... *
> *                       </sp:SymetricBinding>*
> *                       <SignedSupportingTokens>*
> *                           ...*
> *                       </SignedSupportingTokens>*
> *                    </wsp:All>*
> *                </wsp:Policy>*
> *        **    </wsra:SubscribePolicy>*
>         </wsra:Eventing>
>       <wsra:WS-Mex ws-mex-all ='false' />
>    </wsp:Policy>
>    ...
> </wsa:Metadata>
>
> I'm wondering whether we could find a pattern for implicit operation 
> policy (e.g. like the pattern above - but not necessarily that one) 
> and apply it to both policy passed in WSDL and EPRs?    
>
> Many thanks
> Katy
>
>
> From: 	ashok malhotra <ashok.malhotra@oracle.com>
> To: 	Katy Warr/UK/IBM@IBMGB
> Cc: 	"public-ws-resource-access@w3.org" 
> <public-ws-resource-access@w3.org>
> Date: 	23/03/2009 14:05
> Subject: 	Re: [Bug 6721] New: Attaching policy to implicit operations
>
>
> ------------------------------------------------------------------------
>
>
>
> Hi Katy:
> We may be miscommunicating but let me try and be a bit more explicit in
> what I was proposing.
> The EPR has the following structure:
>
> <wsa:EndpointReference>
>    <wsa:Address>xs:anyURI</wsa:Address>
>    <wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters>?
>    <wsa:Metadata>xs:any*</wsa:Metadata>?
> </wsa:EndpointReference>
>
> Now suppose we wanted to say that the endpoint supports WS-Eventing and
> WS-Mex but does not support the ws-mex-all dialect.  (Just an
> illustration).  Then the Metadata section within the EPR could look like
> <wsa:Metadata>
>    ...
>    <wsp:Policy>
>       <wsra:WS-Eventing/>
>       <wsra:WS-Mex ws-mex-all ='false' />
>    </wsp:Policy>
>    ...
> </wsa:Metadata>
>
> Where wsra:WS-Eventing and WS-Mex are policy assertions we define that
> indicate various properties of the endpoint.  By defining these
> specialzed assertions we can write policies that apply to only a single
> operation supported by the endpoint.
>
> All the best, Ashok
>
>
> Katy Warr wrote:
> >
> > Hi Ashok,
> >
> > I agree that it should be possible to pass the policy in the EPR.
> >  However, this isn't quite answering this issue because it doesn't
> > give a syntax for attaching the policy to the implicit operation (as
> > the scope of the policy in the EPR metadata is the endpoint).  We
> > could state that the implicit operations simply inherit the endpoint's
> > policy but this approach has drawbacks (as mentioned in the issue).
> >
> > Theoretically, implicit operations' policies could be passed in WSDL
> > or EPR (and it would be nice to allow both), but in both cases we'd
> > need a way to indicate that the policy is associated with the implicit
> > operation (rather than the endpoint and all its operations).
> >
> > Incidentally, the WS-Mex GetMetadata verb adds an additional
> > complexity to the implicit operation problem because there is a
> > chicken-egg situation that means that there's no way to get the WSDL:
> >  http://www.w3.org/Bugs/Public/show_bug.cgi?id=6463.  Passing policy
> > in the EPR could be a solution to this problem ... but there is still
> > the question as to how to associate the policy with the actual
> > GetMetadata operation.
> >
> > Best regards,
> > Katy
> >
> >
> > From:                  ashok malhotra <ashok.malhotra@oracle.com>
> > To:                  "public-ws-resource-access@w3.org"
> > <public-ws-resource-access@w3.org>
> > Date:                  19/03/2009 18:59
> > Subject:                  Re: [Bug 6721] New: Attaching policy to 
> implicit operations
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> > Our proposal for attaching policy to endpoints is to include it in the
> > metadata section of the EPR.
> > See http://www.w3.org/Submission/WS-PAEPR
> > All the best, Ashok
> >
> >
> > bugzilla@farnsworth.w3.org wrote:
> > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=6721
> > >
> > >            Summary: Attaching policy to implicit operations
> > >            Product: WS-Resource Access
> > >            Version: PR
> > >           Platform: PC
> > >         OS/Version: Windows XP
> > >             Status: NEW
> > >           Severity: normal
> > >           Priority: P2
> > >          Component: All
> > >         AssignedTo: public-ws-resource-access-notifications@w3.org
> > >         ReportedBy: katy_warr@uk.ibm.com
> > >          QAContact: public-ws-resource-access-notifications@w3.org
> > >
> > >
> > > There are a number of issues already open addressing how we attach
> > policies to
> > > indicate that an endpoint supports virtual (implicit) operations 
> and the
> > > flavour/extent of that support.  For example,issue 6403
> > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=6403 describes policy
> > to indicate
> > > that an endpoint supports enumeration and there are similar issues
> > open for the
> > > other specs (6402,6406, 6407).
> > >
> > > These issues do not discuss how policy should be attached to the 
> virtual
> > > operation (i.e. one that does not appear in WSDL) itself.  They also
> > don't
> > > address what policy should be applied to the virtual operations by
> > default.
> > > One option for default behaviour might be to default to the policy
> > of the
> > > endpoint, but this poses problems as many policies are applied at
> > > operation/message level (and therefore are not available at the
> > endpoint).
> > >
> > > There are a number of possible solutions that we might adopt to
> > solve this
> > > problem.  I suggest that we choose a pattern and re-use that across
> > all the
> > > specs for simplicity and consistency.
> > >
> > > For example, here's a potential pattern:
> > >
> > > <wsp:Policy>
> > >    ... <lots of policy for the endpoint>
> > >
> > >    <wsra policy indicating wsra spec support>
> > >       ...
> > >
> > >       <wsra:VirtualOperationPolicy>
> > >           ...
> > >       </wsra:VirtualOperationPolicy>              
> > >
> > >    </wsra policy indicating wsra spec support>
> > >
> > > </wsp:Policy>
> > >
> > > The VirtualOperationPolicy defines the policy for the implicit
> > operations
> > > relating to the wsra spec support.
> > >
> > > For example, the above pattern applied to eventing MIGHT look
> > something like
> > > this:
> > >
> > > <wsev:WSEventingSupported  ...>
> > >   <wsp:Policy>
> > >     ...
> > >
> > >     <wsev:subscribeOperationPolicy>
> > >         ... policies such as security policy to attach to subscribe
> > request ...
> > >     </wsev:subscribeOperationPolicy>
> > >
> > >   </wsp:Policy>
> > > </wsev:WSEventingSupported>
> > >
> > > If we agree on a pattern to try, the next step might be to take some
> > real
> > > examples (e.g. security policy) in order to check that the pattern
> > works prior
> > > to applying it across the specs.
> > >
> > > This issue is also related to
> > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=6694 which asks when
> > operations
> > > do/don't appear in the WSDL.  
> > >
> > > It's probably best for us to address the other policy issues and
> > 6694 before
> > > this one - but this is an important issue as lack of clear
> > specification in
> > > this area will prevent interoperability and make life hard for
> > implementers.
> > >
> > >
> > >  
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > /
> > /
> >
> > /Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with
> > number 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> > 3AU/
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU/
>
>
>
>
>
>

Received on Tuesday, 24 March 2009 10:45:20 UTC