Re: WS-RA issue 9700 disposition

Doug,

some (final?) comments inline.

Cheers

Antoine

Doug Davis a écrit :
>
> Antoine wrote on 05/13/2010 06:37:20 AM:
> > Hi Ram,
> >
> > I am still not convinced that the existing mechanisms will allow us to
> > profile out the Content attribute in DPWS servers: I agree that because
> > the attribute is optional and has a default value of ".../Any" it is
> > easy to profile out its use in DPWS clients, but it is not enough.
>
> You're correct that a service _will not_ be able to profile out the
> Content attribute.  The WG discussed this and it was felt that allowing
> a service to not support the Content attribute would revert the spec 
> back to its
> old state which wasn't optimal.
Maybe not for you, but it was perhaps optimal for device vendors who 
have been implementing this spec for 5 years in 512 KB of Flash and 96 
KB of RAM (and yes that's kilobytes, not megabytes, including OS, 
middleware and applications). I am not against making the life of the 
client easier, but it shouldn't be at the expense of making the life of 
the server impossible.
>  The notion of a service never being
> required to return the data in a format that the client would find useful
> is not a situation that we wanted to return to.  Remember that w/o the
> Content attribute the service is not required to return any particular
> format - even if it does have it.  And of course a possible answer to
> this is to just require the service to return all types it has, however
> if client isn't interested in a large amount of data (or in other format
> types) then it might be stuck.
>
> > Let's say a embedded device can only expose its service WSDLs as
> > references, for memory footprint reasons. This device may be 
> accessed by
> > DPWS clients, but there are use cases (for instance communications
> > between devices and enterprise applications) where the client will not
> > be a DPWS one. Such a client may want to use the Content attribute in
> > its GetMetadata requests, for convenience reasons.
>
> Yes and since its a required feature, all MEX services that support
> GetMetadata MUST support the Content attribute.  They may not support all
> Content forms for all data types, but they MUST understand the attribute.
> This can not be profiled out.
>
> The WG discussed some other points too:
> - if the client could live with more than one form then it could ask for
>   each one on the GetMetadata request - or just specify "All"
Or even Any to leave the choice to the server.
> - it seems that the one form that people might want to avoid is the
>   inlined one, so the overhead of people simply asking for the EPR
>   and URL forms seemed minimal.
>
> > What are the options of the device (or in fact any service not able to
> > expose its metadata in all possible formats) receiving a
> > GetMetadataRequest with the Content attribute having an unsupported 
> value:
> >
> > 1) Not return any value for the metadata: this is compliant with the
> > spec, but not very helpful for the client. How does it know that the
> > metadata is indeed available, but in a different format? Should it be
> > coded as to retry with a different @Content value until it succeeds
> > (which may never happen, if the metadata is indeed not available)?
>
> Right - if it can indeed live with other Content forms then it can 
> (should?)
> include those in the request - or specify "All".
>
> > Should it look at the WS-Policy assertion (thus making it kind of
> > mandatory, and also creating a bootstrap problem)?
>
> Ideally yes.  :-)  that's why its there.  If people choose not to use the
> recommended advertising approach there isn't much we can do.
Policy assertions are not always easy to get and extract from their 
enclosing document, especially in the case of WS-Mex policy assertions, 
as you need to figure out how to get them out-of-band (bootstrap problem).
>
>
> > If many servers
> > behave in this way, I think it will lead many clients not to use the
> > Content attribute at all, thus defeating the purpose of its 
> introduction
> > since the Submission version.
>
> Actually, I think what will happen is that people will just use "All" 
> - which
> is why its there.
>  
> > 2) Return a DPWS-specific fault: this has two drawbacks: (i) it is a 
> bit
> > drastic, as the complete request (possibly batching requests for 
> several
> > metadata dialects) will fail, while most of the request could be OK;
> > (ii) it will not be understood by a non-DPWS client, while in fact only
> > these non-DPWS clients will receive it (DPWS clients would know that
> > they should not use the Content attribute).
>
> Agreed - we didn't like #2 either.
>
> > So in fact only option 1) makes sense in the current version of the 
> spec.
> >
> > Adding a new response type (e.g. mex:AlternateContent) in case where 
> the
> > requested metadata is available in a different format would solve the
> > problem in an elegant way:
> > - It will not increase the complexity for clients not using the Content
> > attribute (e.g. DPWS clients): this response type will never be 
> returned
> > when using the ".../Any" Content value, so these clients will not have
> > to support it.
> > - It will provide enough information for the client to retry the 
> request
> > in an efficient way: only metadata for which this return value has been
> > provided will need to be requested again. Adding a @ContentHints as an
> > attribute or subelements to the returned element would allow the client
> > to use the appropriate content type (alternatively to keep things
> > simple, it could use the ".../Any" value in the second request).
>
> True, but there were a couple of concerns with this that the WG 
> discussed:
> - this is, in essence, creating another advertising mechanism.  Having 
> both
> policy and this seemed redundant.
It can also be called a redirection/negociation mechanism, a bit like 
the 3xx codes in HTTP, which some people find useful. Also, policy 
applies to each dialect (class-level information), while the 
mex:AlternateContent would apply to each individual instance 
(resource-level information), so I don't think it would be that redundant.
>
> - while this seems like a nice benefit for those clients that will 
> want to
> issue a secondary request, it creates a bit of noise for those clients 
> that
> do not want this information.  Akin to "why are you telling me you have
> oranges when I asked for apples?"
Well to expand on the metaphor, if you go to your grocer's shop and ask 
for apples, the guy is very likely to offer you oranges instead if he 
doesn't have apples, and if you're really hungry, you're going to buy 
them! ;)
Anyway, it's easier to ignore extraneous information than to make up 
missing information. Given the overall verbosity of the protocol (with 
all the dialect, contents etc. URIs embedded in all metadata sections), 
I wouldn't worry too much about an additional empty element.
>
>
> > Overall, because the Content attribute is a new feature that introduces
> > some non-trivial additional complexity in services supporting WS-Mex
> > (and this includes DPWS devices), I think it would be fair that the WG
> > introduces an associated mechanism allowing its removal in a convenient
> > way. I also think that this issue has a larger scope that DPWS only.
> >
> > I hope this explanation will allow the WG to reconsider its decision.
>
> -Doug
> ------------------------------------------------------------------------
>
>
> Ce message entrant est certifié sans virus connu.
> Analyse effectuée par AVG - www.avg.fr 
> Version: 9.0.819 / Base de données virale: 271.1.1/2871 - Date: 05/13/10 08:26:00
>
>

Received on Friday, 14 May 2010 07:44:49 UTC