[glue-wg] New Endpoint and Service types

[Florido Paganelli]

Hi Paul,

On 2014-03-05 18:30, Paul Millar wrote:
> Hi Stephen, Maria, everyone else,
> 
> On 05/03/14 13:22, stephen.burke at stfc.ac.uk wrote:
>> Maria Alandes Pradillo [mailto:Maria.Alandes.Pradillo at cern.ch] said:
>>> On behalf of the DPM team, could you please also consider adding:
>>
>> I think these do need some more discussion ...
>>
>>> - "DPM" to ServiceType
>>
>> It isn't clear to me that DPM is a distinctive type - as far as I
>> know it only implements standard interfaces like SRM and xroot, so
>> why is it a different type of service to, say, dcache? What would you
>> propose as a definition? DPM as a product name is published
>> elsewhere. I think we probably need a type name that would be common
>> between, say, DPM, dcache and Castor since they provide basically the
>> same functionality.
> 
> For comparison, dCache currently publishes a Service.Type of
> 'org.dcache.storage'
> 
> I think we've already had a discussion on this point, without coming to
> a conclusion, as I recall.
> 
> The problem (IMHO) is the level of detail depends on who's asking the
> question.
> 
> Stephen, to you DPM, dCache and Castor provide the same functionality,
> so you would be happy with instances of all three published as
> Service.Type of 'storage' (or similar).
> 
> Somebody who needs some unique characteristic provided by dCache (or
> DPM, or ...) might want more detailed Type, specifically that the
> service provides the dCache-like facilities (or DPM-like or ...).
> 
> If all someone wants is to store some data using, say, WebDAV, then they
> can look for a WebDAV endpoint that they're authorised to use.  They
> wouldn't even look at the StorageService Type.
> 
> That isn't to say publishing DPM (or 'org.dcache.storage') is the
> correct approach, but that saying "they're all storage" also isn't
> necessarily correct.
> 
> So, in the absence of other compelling reasons, I would suggest going
> for a *more* specific Type: the generic features may be published
> elsewhere (e.g., as endpoints) and searched for as such.
> 
> The only thing I would suggest is that instead of publishing DPM, you
> publish a reasonable DNS name.  A three-letter acronym is perhaps
> generic enough that it might result in confusion.
> 
>>> - "org.webdav" and "org.xrootd" to InterfaceName
>>
>> xroot has already been discussed extensively and we made a decision -
>> I think the decision was to use "xroot" for the protocol name but we
>> should check.
> 
> For the xrootd protocol, dCache currently publishes
> 
>     Endpoint.URL: xroot://xrootd-door.example.org/
>     EndpointInterface.Name: xroot
> and StorageAccessProtocol.Type: xrootd
> 

that sounds correct to me

> 
>> For webdav I think the "org." prefix isn't adding much here -
>> probably we should just use "webdav" as it's a well-known protocol
>> defined in an RFC so there's no issue of a name clash, but there may
>> be other views. Anyway there are likely to be other interested
>> parties - dcache at least - who should express a view.
> 
> For WebDAV, dCache is currently publishing as either 'http' or 'https',
> depending on whether SSL/TLS tunnelling is enabled or not.  This is for
> Endpoint.URL ('http://' or 'https://'), Endpoint.InterfaceName and
> StorageAccessPoint.Type.  This is largely for historical reasons (dCache
> supported HTTP before WebDAV) -- not to say this is correct.
> 
> Since HTTP is a subset of WebDAV, it would be useful if someone
> searching for HTTP endpoints could also find any WebDAV endpoint.
> 

Paul, I think this is very bad. http is not webdav. If one searches for
http endpoints that should NOT be done with interfacename, but with
Capability or Technology. This http there is a very misleading thing --
in short, so how is an information consumer supposed to infer that
endpoint supports webdav?? I think we should simply add webdav.

If the thing is how to discover that webdav is based on http, this is
another kind of question... I think of webdav as a protcol itself.

If you think it as an extension of http, maybe you can play with
InterfaceExtension in the Endpoint... But I think one should have a
StorageAccessProtocol object just for that as well.

> Therefore, here's a concrete proposal:
> 
> ---
> 
> A service that supports HTTP or WebDAV protocols MAY publish
> StorageAccessProtocol objects to represent this.  If a
> StorageAccessProtocol object is published to represent HTTP access then
> the Type SHOULD be 'http'.  If a StorageAccessProtocol object is
> published to represent WebDAV access then the Type SHOULD be 'webdav'.
> Since HTTP is a subset of WebDAV, a service that publishes a WebDAV
> StorageAccessProtocol SHOULD publish a StorageAccessProtocol for HTTP.
> 

I don't like the above. One should tell what the protocol is, not what
are its close siblings. Type MUST be webdav. I am against giving such
misleading recommendation as the above, they only generate confusion.

> When publishing an Endpoint object the describes an HTTP or a WebDAV
> endpoint with unencrypted access then the URL SHOULD start 'http://' and
> the InterfaceName SHOULD be 'http'.  If the endpoint is encrypted then
> the URL SHOULD start 'https://' and the InterfaceName SHOULD be 'https'.
>  If the endpoint supports WebDAV then a SupportedProfile of
> 'http://webdav.org/' SHOULD be published.
> 

In such scenario, what algorithm should the consumer use to discover a
webdav endpoint?

I dislike this one as well -- for the same reasons as above.

Moreover would be nice to stick a domain name to those -- like
org.ieee.webdav.

I agree that for old standards like http there is no single
organization, and is hard to tell, so there can always be exceptions,
plain http and https can stay.

I agree with the SupportedProfile proposal.

Cheers,
Florido

-- 
==================================================
 Florido Paganelli
   ARC Middleware Developer - NorduGrid Collaboration
   System Administrator
 Lund University
 Department of Physics
 Division of Particle Physics
 BOX118
 221 00 Lund
 Office Location: Fysikum, Hus B, Rum B313
 Office Tel: 046-2220272
 Email: florido.paganelli at REMOVE_THIShep.lu.se
 Homepage: http://www.hep.lu.se/staff/paganelli
==================================================