[glue-wg] New Endpoint and Service types

[Maria Alandes Pradillo]

Dear Paul,

Thanks very much for your answer. I agree with all what you have said. I will pass this information to my DPM colleagues and get back to you.

Regards,
Maria

> -----Original Message-----
> From: glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On Behalf
> Of Paul Millar
> Sent: 05 March 2014 18:30
> To: glue-wg at ogf.org
> Subject: Re: [glue-wg] New Endpoint and Service types
> 
> 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
> 
> 
> > 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.
> 
> 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.
> 
> 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.
> 
> ---
> 
> Cheers,
> 
> Paul.
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg