[glue-wg] New Endpoint and Service types

[Paul Millar]

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.