Re: Comments on the preview of the WS-MetadataExchange Working Draft

Doug,

It seems to me that issue 7728 refers (but not explicitly) to a 
submission called WS-PAEPR which would indeed fully address my concern, 
as it both introduces the possibility of directly attaching policies to 
EPRs and defines the endpoint referenced by the EPR as the policy scope 
for the attached policies. Extending section 7 of WS-Mex with the 
approach proposed in this submission would be perfect from my point of 
view.

Cheers

Antoine



Doug Davis a écrit :
>
> Antoine,
>   does http://www.w3.org/Bugs/Public/show_bug.cgi?id=7728  point #1 
> cover at least part of your concern?
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
>
> *Antoine Mensch <antoine.mensch@odonata.fr>*
> Sent by: public-ws-resource-access-request@w3.org
>
> 10/13/2009 04:59 PM
> Please respond to
> antoine.mensch@odonata.fr
>
>
> 	
> To
> 	public-ws-resource-access@w3.org
> cc
> 	
> Subject
> 	Comments on the preview of the WS-MetadataExchange Working Draft
>
>
>
> 	
>
>
>
>
>
> Dear colleagues,
>
> Please find below some comments on the preview of the
> WS-MetadataExchange Working Draft
> (http://www.w3.org/TR/2009/WD-ws-metadata-exchange-20090924).
>
> I. Section 7
>
> This section provides a way to attach metadata to an EPR.  However, the
> spec does not clearly state whether this feature is only intended for
> carrying general metadata about the service exposed through the endpoint
> (as the examples seem to indicate), or whether it could also be used for
> carrying endpoint-specific metadata, such as the endpoint effective
> policy (as defined in WS-PolicyAttachment).
>
> Ideally, there should be an easy way to directly attach an endpoint
> effective policy to the EPR, in order to bypass the usual complex
> algorithm that the client must implement to compute the endpoint
> effective policy, which is not practical for some embedded clients:
> 1) Download the WSDL
> 2) Retrieve the service port corresponding to the EPR (matching the
> address, and hoping that the WSDL is complete, i.e. is dynamically
> generated by the service to contain an up-to-date address, which is
> often numerical in cases of devices).
> 3) Build the endpoint effective policy by merging info extracted from
> the WSDL and possibly an external policy document.
>
> The closest way I can see in the current version of the spec would be to
> use an external policy attachment as metadata section, using the EPR as
> policy scope. So for instance, to express that an EPR supports the DPWS
> requirements for hosted services (as a basic example of policy
> assertion), one could have:
>
> <wsa:EndpointReference
>   xmlns:wsa='http://www.w3.org/2005/08/addressing'>
> <wsa:Address>http://192.168.0.34/myHostedService</wsa:Address>
> <wsa:Metadata>
>   <mex:Metadata xmlns:mex='http://www.w3.org/2009/09/ws-mex'>
>     <mex:MetadataSection xmlns:wsp='http://www.w3.org/ns/ws-policy'>
>         Dialect='http://www.w3.org/TR/ws-policy-attach'>
>       <wsp:PolicyAttachment>
>         <wsp:AppliesTo>
>           <wsa:EndpointReference>
>             <wsa:Address>http://192.168.0.34/myHostedService</wsa:Address>
>           </wsa:EndpointReference>
>         </wsp:AppliesTo>
>         <wsp:Policy>
>           <dpws:Profile
> xmlns:dpws='http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01'/>
>         </wsp:Policy>
>       </wsp:PolicyAttachment>
>     </mex:MetadataSection>
>   </mex:Metadata>
> </wsa:Metadata>
> </wsa:EndpointReference>
>
> Is the above a valid use of the EPR embedded metadata feature?
>
> If so, although much simpler than having to parse a full WSDL, it
> remains a relatively heavy solution for embedded clients. A simpler
> solution could be to have, by specifying that the EPR defines a default
> policy scope, and thus avoiding the external policy attachment construct:
>
> <wsa:EndpointReference
>   xmlns:wsa='http://www.w3.org/2005/08/addressing'>
> <wsa:Address>http://192.168.0.34/myHostedService</wsa:Address>
> <wsa:Metadata>
>   <mex:Metadata xmlns:mex='http://www.w3.org/2009/09/ws-mex'>
>     <mex:MetadataSection xmlns:wsp='http://www.w3.org/ns/ws-policy'>
>         Dialect='http://www.w3.org/TR/ws-policy'>
>       <wsp:Policy>
>         <dpws:Profile
> xmlns:dpws='http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01'/>
>       </wsp:Policy>
>     </mex:MetadataSection>
>   </mex:Metadata>
> </wsa:Metadata>
> </wsa:EndpointReference>
>
> or even better (allowing any predefined WS-Mex dialect to appear in the
> WS-Addressing metadata, as in a Get response)
>
> <wsa:EndpointReference
>   xmlns:wsa='http://www.w3.org/2005/08/addressing'>
> <wsa:Address>http://192.168.0.34/myHostedService</wsa:Address>
> <wsa:Metadata>
>   <wsp:Policy>
>     <dpws:Profile
> xmlns:dpws='http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01'/>
>   </wsp:Policy>
> </wsa:Metadata>
> </wsa:EndpointReference>
>
>
> II. Editorial comments:
>
> It seems that the namespace used in schema import elements in several
> examples should be http://services.example.org/stockquote/schemas
> instead of http://services.example.org/stockquote
>
> Best regards,
>
> Antoine Mensch
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.421 / Virus Database: 270.14.15/2434 - Release Date: 10/13/09 19:11:00
>
>

Received on Wednesday, 14 October 2009 19:28:51 UTC